El crecimiento de un Producto generalmente conlleva un aumento en la cantidad de personal. Nos encontramos organizando un primer squad y luego tenemos que crear un segundo, luego un quinto, un décimo y así sucesivamente. Las dificultades comienzan a surgir a partir de los dos equipos, aunque en esta etapa se pueden resolver relativamente rápido. Pero cada paso o cambio en la organización puede dar lugar a nuevos problemas o amplificar los problemas existentes.
Entre la falta de visión, las dependencias técnicas u organizativas y los solapamientos involuntarios, los squads se encuentran teniendo que lidiar con situaciones que los ralentizan y hacen que su día a día sea desagradable. Como resultado, el Time to Market se alarga, la previsibilidad disminuye, los equipos se desaniman y, en el peor de los casos, la calidad de su Producto se deteriora.
En este artículo, te ofreceremos sugerencias para todos los tipos de dependencias que puede encontrar.
Una organización vertical no resolverá mágicamente la coordinación entre los equipos. Es necesario accionar una serie de palancas para garantizar que el Producto se mantenga coherente en su conjunto y que la colaboración entre los squads sea fluida y no esté aislada.
Existen muchas dependencias con los equipos transversales en la empresa y claramente son servicios y roles que no pueden integrarse en cada squad.
Las dependencias que hemos observado en nuestras diversas misiones están relacionadas con necesidades de contratación o refuerzo de equipos con una fuerte dependencia de los servicios de Recursos Humanos y Compras (contratación interna o externa) o con necesidades de experiencia legal o ad hoc.
El precio a pagar es el mismo que para otras dependencias: el time to market se alarga y la previsibilidad de entrega disminuye cuando una squad carece de recursos y no tiene control sobre ese parámetro.
Proponemos diferentes soluciones para gestionar estas dependencias inherentes a cualquier organización.
Para saber más descarga el libro Las Organizaciones Orientadas a Producto
No siempre es posible integrar todas las competencias necesarias en cada squad para brindarles total autonomía. En algunas organizaciones, por razones prácticas o presupuestarias, se mantienen competencias de manera transversal, ya sea a nivel de la tribu o a nivel de la propia organización de Producto: Product Designers, Data Analytics, Testers, Data Scientists, desarrolladores móviles, etc…
A menudo encontramos en los proyectos con clientes, organizaciones híbridas que presentan algunas o todas las características, alineamientos y dependencias descritas a continuación:
Esta situación crea automáticamente una fuerte dependencia entre los squads y las entidades transversales, lo que prolonga el Time to Market cuando todas los squads de Producto solicitan simultáneamente el mismo equipo transversal. Los niveles presentados anteriormente son aplicables en la mayoría de los casos y le permitirán resolver parte de las dependencias que encontrará. Sin embargo, tenemos recomendaciones específicas para estas situaciones, según la tipología de su organización.
Aunque consideramos que es un antipatrón, sigue siendo común ver equipos de back-end independientes con la misión de servir a squads de Producto muy orientadas al front-end.
El equipo de back-end debe crear APIs que sirvan a varios squads y no puede adaptarse completamente a las demandas de cada uno y al ritmo de desarrollo necesario en el front-end. Al no saber cuándo estará lista la funcionalidad proporcionada por el back-end, los squads a menudo se frustran al depender de otros equipos para alcanzar sus objetivos, mientras que los equipos de back-end tienen que equilibrar prioridades externas que no controlan, lo que puede generar una alta rotación en última instancia.
Sin embargo, no todo está perdido. Además de las soluciones mencionadas anteriormente, puede probar diferentes medidas paliativas para abordar estos problemas.
Es importante tener en cuenta que con una arquitectura de este tipo, se crearán nuevas dependencias entre cada uno de los Feature Team (ya que cada uno será responsable de sus propios servicios), pero estas dependencias son más fáciles de manejar que la relación cliente-proveedor entre un único equipo de backend y varios equipos de frontend.
Al igual que en el enfoque descrito anteriormente, es común ver que el equipo de "Ops" trabaje de forma independiente a los squads y no esté directamente integrado en ellos.
Esta dependencia se refiere principalmente a la implementación de herramientas de desarrollo y, sobre todo, a la puesta en producción de nuevas features. Después de desarrollar un conjunto de features, los squads deben enviar su entregable para que el equipo de "Ops" lo implemente en los diferentes entornos apropiados. Este equipo de "Ops" recibe las solicitudes de implementación de producción de los diferentes equipos y las prioriza. Mientras que la dependencia anterior con los equipos de backend se puede sortear fácilmente, la dependencia con los equipos de Ops puede ser perjudicial para los equipos.
Además de los efectos mencionados anteriormente, como el aumento del Time to Market, la disminución de la predictibilidad y la fatiga de los miembros de los squads, también se corre el riesgo de poner en peligro las entregas.
No pretendemos ser expertos técnicos ni expertos en DevOps, por lo que nos limitaremos a resumir las soluciones de Ops y DevOps que hemos encontrado en nuestras diversas intervenciones.
Sin embargo, seguimos convencidos de que la mejor solución para promover la agilidad y facilitar el proceso de desarrollo de productos es implementar una verdadera cultura DevOps dentro de la organización.
Hemos observado en muchas organizaciones la presencia de un equipo móvil independiente de los squads. De hecho, las especificidades técnicas de las herramientas y plataformas de desarrollo móvil suelen llevar a agrupar a los desarrolladores con estas habilidades en el mismo equipo. Del mismo modo, los Mobile Product Managers y Product Designers deben dominar las pautas de Google (Android) y Apple (iOS), que cambian con frecuencia, y conocer las particularidades del diseño de productos móviles.
Además, dado que la mayoría de los productos se desarrollan tanto para iOS como para Android, no siempre es pertinente o posible, en términos de costes, integrar en cada squad un desarrollador móvil especializado en cada sistema operativo.
Las estrategias que proponemos para gestionar esta situación son:
Por las mismas razones expuestas anteriormente sobre los equipos móviles, no siempre es posible distribuir todas las skills necesarias en cada squad: debido a la falta de talento disponible, Product Design, Data Science o QA a veces se agrupan a nivel de la tribu o incluso de la organización de producto, y trabajan para todos los squads. Aunque a veces es inevitable, este esquema genera muchas interdependencias que a menudo perjudican la eficiencia de los squads. Recomendamos las siguientes soluciones para limitar las fricciones y los cuellos de botella:
Los alineamientos y dependencias son inherentes a cualquier modelo de organización, ya sea entre squads tipo Feature Teams o entre equipos transversales en organizaciones híbridas.
Para nosotros, lo más importante sigue siendo encontrar los mecanismos para limitar los efectos de las dependencias en términos de retraso en el time to market, disminución de la previsibilidad y desmotivación de los equipos. Sin embargo, seguimos convencidos de que las organizaciones verticales con equipos multidisciplinares y autónomos no solo son más compatibles con nuestra visión de la Gestión de Producto, sino que también conducen a una mejor toma de decisiones y una gestión más fácil de las relaciones entre equipos: los alineamientos ciertamente se multiplican, pero las dependencias se minimizan, y son estas últimas las que plantean los mayores problemas.
Creemos que es importante que una organización se acerque gradualmente a este modelo invirtiendo en la contratación de perfiles multidisciplinares, reclutando Product Managers y desarrolladores full-stack, capacitándolos constantemente para mantener o crear esa cultura multidisciplinar y enfatizando la necesidad de una mentalidad abierta al cambio y la iteración organizativa. Cuanto más valore la multidisciplinariedad, más fácil será gestionar las dependencias.
Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto
Imagen de Google Deepmap en Unsplash