Autonomía vs. Iniciativa
Para continuar con la serie sobre autonomía de equipos, después de Autonomía vs. Mandato quiero añadir este aspecto importante al tema. Se trata de las implicaciones que tienen las grandes iniciativas con muchos equipos en la práctica.
¿Qué es una iniciativa?
Cuando digo “iniciativa”, me refiero al esfuerzo de trabajo para un producto en el que muchos equipos están involucrados. Podría ser algo como: la revisión de la usabilidad de un sitio web, el cambio a diseño responsivo, una internacionalización o la entrada en nuevos mercados significativos como China. Todas estas son cosas fundamentalmente importantes que normalmente requieren el esfuerzo conjunto de varios – si no de todos – los equipos de producto.
En principio, la reestructuración de una plataforma por razones de escalabilidad o rendimiento – como una nueva arquitectura o nuevas bases tecnológicas – también es un tipo de iniciativa. Sin embargo, la deuda técnica se gestiona de manera diferente, por lo que no entraré en ello en este artículo.
Dejemos a un lado si es una buena o mala idea llevar a cabo una determinada iniciativa. Este tema ya lo he tratado en otro artículo. Aquí simplemente asumamos que la iniciativa es algo bueno e importante. Quiero explicar las tres formas en que los equipos pueden manejar estas grandes y complejas iniciativas.
Se trata de lo siguiente: Por definición, tenemos un proyecto complejo del que debemos ocuparnos y en el que muchos equipos están involucrados. Cada equipo tiene sus propios detalles que resolver, pero la pregunta es quién dirige todo esto y cómo. Si la iniciativa consiste en adaptar la oferta de productos al mercado chino, ¿enviamos a cada equipo individual a China para averiguar qué hay que hacer? Eso no sería muy sensato y lo más probable es que cada equipo encontraría una solución diferente.
Estrategia 1: Un equipo líder
En la mayoría de los casos, se selecciona uno de los equipos para asumir el papel principal y liderar la iniciativa, es decir, asumir la dirección de Discovery y Delivery. Naturalmente, este equipo depende del trabajo de los otros equipos, pero también dirige y coordina esos trabajos. Por ejemplo, identificaría un grupo de clientes para determinar con ellos los cambios necesarios en el producto, y luego ayudaría a dividir y abordar los trabajos necesarios (Discovery y Delivery).
Las ventajas de este enfoque son el área de responsabilidad clara y el ownership. Naturalmente, se debería intentar seleccionar un equipo líder sobre el que este trabajo tenga un fuerte impacto.
Pero también hay una desventaja en este enfoque. Si el equipo líder no informa permanentemente a los otros equipos sobre nuevos hallazgos y decisiones, estos no podrán entender esas decisiones o se opondrán cuando llegue el momento de repartir el trabajo. Y es en ese punto donde la autonomía se convierte realmente en un desafío.
Estrategia 2: Un equipo temporal
En este enfoque, ningún equipo existente es encargado de liderar la iniciativa. En su lugar, se forma expresamente (por la duración de esta iniciativa) un equipo temporal de Discovery que se ocupa al menos de los trabajos de Discovery. Normalmente, este equipo está formado por un Product Owner, un diseñador UX líder y al menos un desarrollador líder. Una vez que este grupo ha identificado los trabajos de Delivery necesarios y ha creado Backlog Items, los miembros de este equipo temporal regresan a sus equipos originales.
La ventaja aquí es que tienes un equipo fuerte con personas comprometidas que pueden concentrarse en este trabajo. La desventaja es que estas personas regresan relativamente rápido a sus propios equipos. Eso es en realidad algo bueno, porque pueden comunicar a sus equipos lo que han aprendido y decidido. Sin embargo, ya no hay áreas de responsabilidad claras ni ownership. Y también existe el riesgo de que los otros equipos no entiendan o no estén de acuerdo con lo que se les comunica. Otra desventaja es que al sacar personas de sus equipos, se socava el objetivo de la estabilidad de los equipos.
Estrategia 3: Un equipo unificado
La tercera forma de abordar estas iniciativas es algo que normalmente no recomiendo. Sin embargo, debo mencionarlo porque ocurre de vez en cuando. En este enfoque, varios equipos (no necesariamente todos) se unen para realizar el trabajo de Discovery de forma conjunta.
La gran ventaja es que toda la nueva información se comparte, y eso tiene un valor enorme.
Sin embargo, la mayor desventaja es que hay muchas personas involucradas en la toma de decisiones y, como se dice, demasiados cocineros estropean el caldo.
Conclusión sobre Autonomía vs. Iniciativa
Elijas lo que elijas, debes encontrar una solución para la iniciativa y también ejecutarla. Estas son las tres formas en que los equipos pueden manejar esto. Es difícil decir que una de ellas sea mejor que las otras en cuanto a autonomía, porque en una iniciativa se trata de hacer algo bueno para la organización, y no necesariamente de cuánta libertad de decisión tienen los equipos individuales. Quizás sea más acertado decir que puedes elegir uno de estos enfoques para minimizar la sensación de pérdida de autonomía.
Recuerda que estas iniciativas a menudo son extremadamente valiosas para nuestros clientes y nuestra empresa, así que hay mucho de lo que sentirse orgulloso cuando completas exitosamente la iniciativa.
Este texto proviene del Blog de Marty Cagan y fue traducido por nosotros al alemán.