¿Cómo dividir los equipos de producto?

El enfoque de la división de equipos de Producto: un dilema necesario

Cualquier organización que se enfrente a desafíos de crecimiento inevitablemente se dividirá con el tiempo en diferentes equipos, cada uno con su propio ámbito de responsabilidad. Esto también se aplica a las organizaciones de Producto, lo que plantea la cuestión de cómo dividir estos equipos (que llamaremos squads).

Nos centraremos en una preocupación clave de los CPO: la distribución de habilidades en los equipos y el alcance funcional asociado a ellos.

Recordemos las dos primeras leyes de una buena Organización de Producto.

• La Ley del Doble Impacto: la obsesión por el retorno de la inversión (ROI) tanto para el usuario como para la empresa es la razón de ser de la organización. Se habla del tiempo para obtener resultados.
• La Ley del Equipo Pequeño: se presume que el trabajo debe ser llevado a cabo por equipos pequeños, autónomos y responsables, que trabajan en ciclos cortos (en la medida de lo posible) y siguen la Ley del Doble Impacto.

Uno de los criterios principales para cualquier división es, por supuesto, el tamaño máximo de cada squad. La Ley del Equipo Pequeño establece que estos squads deben ser de tamaño reducido, y parece haber un consenso en torno a un número ideal de 8 personas: el famoso "equipo de pizza", que puede compartir dos pizzas margarita cómodamente en un ambiente amigable. Por supuesto, es aceptable desviarse de este número mágico y formar equipos de 5 a 12 personas, pero debemos tener en cuenta que a medida que los squads crecen, el número de conexiones entre individuos se multiplica (de 10 en un equipo de 5 a 66 en un equipo de 12). La comunicación se vuelve inevitablemente más difícil, los rituales se alargan y la productividad individual y colectiva disminuye. Además de ser proporcionalmente más lentos que los equipos más pequeños, los squads demasiado grandes tienden a subestimar la dificultad de las tareas, mostrándose a menudo excesivamente optimistas en sus estimaciones. Es más difícil mantener discusiones de calidad y lograr alinear a todos dentro de un equipo de gran tamaño.

Construir pequeños equipos es una necesidad para facilitar la comunicación, pero también es importante limitar las dependencias y superposiciones entre estos equipos para evitar reproducir los problemas de comunicación mencionados anteriormente a nivel colectivo. Los equipos deben ser lo más autónomos posible y su alcance debe ser coherente para evitar el trabajo duplicado, interminables reuniones de alineación y conflictos territoriales.

La estructura del equipo es solo uno de varios elementos en la organización. Independientemente del enfoque elegido, también es importante asegurar la coherencia metodológica (Lean Startup, Design Thinking), establecer procesos (como diseño, user research, growth, etc.) y una gobernanza adecuada (consulte el capítulo 2 "Cómo dirigir los objetivos de un equipo de producto").

Sin embargo, incluso si tu organización es ejemplar en todos estos otros aspectos, un mal diseño del equipo puede plantear problemas graves.

A continuación, se enumeran las 4 características de un mal diseño del equipo y sus posibles consecuencias. Si reconoce alguno de estos problemas en su organización, es probable que sea hora de cambiar la estructura de sus equipos.

Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto

La buena noticia es que la mayoría de estos problemas se pueden evitar al elegir el modelo de estructura adecuado. La mala noticia es que no existe una única estructura ideal (al igual que no existe una organización ideal): todo depende de tu producto, contexto y características de tu organización.

Los 4 modelos de estructura

Hay 4 modelos de estructura de equipos que se pueden distinguir de manera esquemática.

Component Team (Equipo por componentes)

Los equipos se estructuran según la lógica de los componentes tecnológicos, a menudo dividiendo los equipos en "front-end" y "back-end", creando equipos por canal (web, móvil, IoT, etc.) o formando equipos dedicados a una capa de aplicación específica (por ejemplo: plataforma de pagos, servicio de correo electrónico).

La versión más básica, que se encuentra con mayor frecuencia en productos simples, es una estructura de 4 equipos: uno para front-end, otro para back-end, un equipo iOS y un equipo Android.

Las organizaciones de productos más maduras tienden a alejarse de este tipo de estructura, ya que presenta la desventaja de tener un enfoque muy limitado en el "impacto en el usuario" (según la Ley del Doble Impacto, es difícil garantizar una obsesión por el retorno de inversión (ROI) tanto para el usuario como para la empresa con equipos organizados por componentes tecnológicos). En cualquier caso, se utiliza puntualmente en el marco de una organización híbrida (ver más abajo).

Feature Teams o Impact Teams (Equipos por funcionalidad o impacto)

En este modelo, los equipos se organizan según la lógica de negocio y orientada al usuario. A menudo se organizan por funcionalidad (Feature Teams, popularizadas por Spotify), pero también pueden organizarse por etapa del recorrido del usuario, persona u objetivo (Impact Teams).

Independientemente del modelo de estructura elegido, cada equipo es:

• multidisciplinar: reúne todas las habilidades necesarias para desarrollar un producto completo y cumplir su misión de manera autónoma.
• multicomponente: es capaz de trabajar en todas las capas técnicas del producto (especialmente front-end y back-end) y su alcance abarca una parte vertical del producto, independientemente de la arquitectura técnica.
• estable y duradera: se considera consensuadamente que debe tener una duración mínima de un año, para que el equipo tenga tiempo de encontrar su ritmo de trabajo. Si los temas en los que trabaja el equipo dejan de ser prioritarios para la organización, es preferible cambiar el enfoque del equipo hacia un nuevo alcance en lugar de desmantelarlo por completo.
• aprendizaje continuo: cada miembro del equipo debe ir más allá de su especialidad original para que las tareas puedan ser realizadas por varias personas y para que cada miembro sienta que está progresando a nivel individual.

El modelo de Feature Teams permite integrar en la estructura misma de la organización de producto su misión: brindar valor a los usuarios. Todo esto fomentando la autonomía y la creatividad de cada squad. Es el modelo más coherente con la Ley del Doble Impacto.

Por naturaleza, este tipo de división plantea la cuestión de cómo gestionar los problemas transversales y garantizar la coherencia entre el trabajo realizado por cada squad. ¿Cómo asegurarse de que la experiencia del usuario final sea coherente? ¿Cómo manejar el hecho de que cada equipo puede modificar cualquier parte del código del producto y afectar el trabajo de todos los demás (especialmente en el caso de los Impact Teams)?

Para abordar este problema, las empresas que utilizan la división vertical a menudo crean un nivel intermedio. Spotify, que ha comunicado mucho sobre este tema, propone un sistema de tribus que agrupa a varios squads. Este nivel aporta coherencia, asegura la sincronización de los diferentes squads y promueve iniciativas transversales.

También se implementan los chapters (comunidades de práctica): estas comunidades son transversales a los squads y se organizan por competencia. De esta manera, los Product Managers de cada squad se reúnen periódicamente para compartir buenas prácticas y discutir sobre sus backlogs. Del mismo modo, los Product Designers pueden compartir el Product Discovery realizado en cada squad o ponerse de acuerdo sobre principios de interfaz o flujo de trabajo.

Por último, los guilds reproducen el modelo de los chapters, pero a nivel de toda la organización de producto y se dedican a problemas transversales que requieren diversas habilidades y que constituyen importantes áreas de trabajo para la empresa (por ejemplo, seguridad, aprendizaje automático, diseño atómico).

El enfoque SAFe (Scaled Agile Framework)

Casi todos los marcos ágiles, como SAFe, LeSS o Scrum@Scale, recomiendan la formación de equipos multidisciplinares siguiendo el modelo vertical (compuestos por desarrolladores, Product Designers, Product Owners / Product Managers, testers, entre otros), pero sin necesariamente restringirlos a un ámbito específico.

El marco SAFe propone la implementación de 3 niveles y 3 niveles de granularidad:

• El portfolio, que agrupa a Epic Owners y Portfolio Managers, quienes manejan un backlog de épicas asociadas a grandes prioridades estratégicas y comerciales.
• El programa, que agrupa a Business Owners y Product Managers, quienes manejan un backlog de funcionalidades planificadas a través de incrementos de producto (generalmente, 5 sprints de 2 semanas).
• Los squads, que toman las funcionalidades, las convierten en historias de usuario e integran estas historias en sprints.

Si bien los squads pueden especializarse gradualmente en ciertos temas o temáticas a medida que avanzan los Program Increments (PI), por naturaleza no están especializados y pueden abordar cualquier funcionalidad. Cada 5 sprints, una sesión de PI Planning permite planificar los próximos 5 sprints asignando las prioridades a los diferentes squads, y también anticipando posibles interdependencias. Sin embargo, es posible que los squads estén vinculados a un Value Stream, que puede ser un área completa de la empresa (unidad de negocio, producto, etc.)

Aquí tienes un ejemplo de posible división de equipos para un servicio de viajes compartidos (como BlaBlaCar o iDVROOM):

La distribución híbrida

En realidad, son pocas las organizaciones de equipos de productos que adoptan exclusivamente un modelo horizontal o vertical; a menudo, las organizaciones mezclan ambos enfoques. Por ejemplo, en una organización con equipos de características o de impacto en una aplicación móvil, lo ideal sería que cada squad tuviera sus propios desarrolladores de iOS y Android para cumplir con el principio de autonomía de los equipos y poder ofrecer valor independientemente del canal considerado. Sin embargo, en la práctica, esto no siempre es posible debido a restricciones de coste o eficiencia.

Por lo tanto, algunas empresas optan por combinar el enfoque de equipos de características o de impacto (para parte de los equipos) y equipos de componentes para canales específicos que tienen restricciones especiales (como móviles, IPTV para una empresa de medios) o para aplicaciones fundamentales de importancia crítica (como el backend de gestión de transferencias para un banco).

Si tu organización se asemeja a una combinación de estos diferentes modelos, no te preocupes, es completamente normal. La clave será gestionar adecuadamente las dependencias entre estos equipos.

¿Qué modelo será el mejor para tu organización de Producto?

Como se mencionó anteriormente, no hay un modelo de división ideal; sin embargo, cada tipo de división tiene sus fortalezas y debilidades, que pueden ser más o menos adecuadas según el contexto. Hemos realizado el ejercicio de evaluar estos diferentes modelos según los criterios que consideramos importantes para una organización de Producto, basándonos en las experiencias prácticas de los profesionales de Thiga y los CPO entrevistados.

* + =más costoso, - = menos costoso

Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto

Imagen de Freepik