No soy partidario de basar los equipos de desarrollo en verticales técnicas, como backend o mobile. Si bien esto tiene sus ventajas, en mi experiencia, estos equipos siempre terminan convirtiéndose en silos aislados de la organización, que se “enamoran” de su tecnología sin pensar en el valor que debemos dar a los usuarios. De nada sirve, tener el código más lindo, bello, hermoso y digno de un paper, si no da valor a quien lo usa y al negocio que paga por él.

Es por esto que en Muni estructuramos el área de producto y tecnología principalmente en base a verticales alineadas a nuestros usuarios, bien sean externos o internos.

Cada vertical, que internamente llamábamos dominios, estaba relacionada al usuario al cual debía aportar valor.

Concretamente en Muni, contábamos con los siguientes dominios:

• Líder de comunidad. Usuario, el core de nuestro negocio, los líderes de comunidad. Su función, construir y mantener el software necesario para hacer cada vez mejor la experiencia de los líderes.
• Usuario final. Usuario, los clientes de nuestros líderes. Su función, construir y mantener el software necesario para hacer cada vez mejor la experiencia de los clientes de nuestros líderes.
• Operaciones. Usuario, el equipo interno encargado de nuestra operación diaria. Su función, construir y mantener el software necesario para hacer cada vez más eficiente nuestros procesos operativos.
• Pagos: Usuario, los equipos de desarrollo. Su función, proveer la plataforma y herramientas para que los demás equipos puedan interactuar con pagos, sin entrar en los detalles.
• QA: Usuario, los equipos de desarrollo. Su función, conocer a detalles todos los productos de Muni desde la perspectiva del usuario, y apoyar a los equipos en definiciones y pruebas.
• DevOps: Usuario, los equipos de desarrollo. Su función, construir plataformas y herramientas que faciliten a los demás equipos operar y monitorear el software que construyen.
• Engineering: Usuario, los equipos de desarrollo. Su función, construir plataformas, herramientas, y estándares, para problemas comunes y principalmente técnicos, que permitan a los demás equipos de desarrollo ser más eficientes al responder a las necesidades de negocio.

Es importante destacar que cada uno de estos dominios podía contar con uno o más equipos de desarrollo, y que cada equipo buscaba contar con todos los perfiles necesarios, para lograr su función, de tal manera que cada equipo pudiera ser los más independiente posible para, tomar decisiones, planear, diseñar, construir y operar sus soluciones, sin depender de otros equipos, logrando así, mayor velocidad en su entrega de valor.

Esto se resume en que cada equipo contaba con developers backend, frontend, product owners, diseñadores, etc…, todos con el mismo objetivo, hacer feliz a su usuario.

Esta estructura esta fuertemente inspirada en lo expuesto por el libro Team Topologies. Dave Farley hace un buen resumen/cheat-cheat de este libro, aqui: https://continuous-delivery.co.uk/downloads/How To Organise SW Dev Teams 21-08-22.pdf?utm_source=newsletter&utm_medium=email&utm_campaign=your_free_guide_is_here_how_to_organise_software_teams&utm_term=2023-04-22