Autonomía vs. Mandato

En mi último artículo escribí sobre los compromisos entre los diferentes objetivos de la autonomía y la determinación externa en los equipos. Recibí algunos correos en los que se decía que este es un gran tema en las empresas y algunas personas querían saber algo más al respecto – pero más desde una perspectiva de producto y diseño que desde el punto de vista del desarrollo. El tema es muy variado y por eso pensé que merece la pena profundizar.

Estas son algunas cuestiones que quiero abordar:

• ¿Qué pasa si un equipo ve una oportunidad aún mejor y decide enfocarse en un tipo de cliente diferente?
• ¿Qué pasa si un equipo no quiere realizar el trabajo que debería apoyar una gran iniciativa empresarial (p. ej., internacionalización del producto)?
• ¿Qué pasa si un equipo está convencido de que necesita cambiar de rumbo para aprovechar las oportunidades del mercado móvil, aunque el equipo solo es responsable de una parte del todo?
• ¿Qué pasa si un equipo está convencido de que necesita cambiar a otro diseño de User Experience, aunque entonces sería diferente al de los otros equipos?

En cada uno de estos casos, el equipo y la dirección probablemente tienen puntos de vista muy diferentes. Muchos equipos afirman que – si realmente se les permite trabajar de forma autónoma – pueden tomar tales decisiones.

La problemática

En equipos y organizaciones saludables, normalmente se llega a un compromiso entre estas dos visiones, dando a la dirección el control sobre dos puntos clave en el proceso de toma de decisiones. El primero es la visión general del producto y el segundo son los objetivos empresariales específicos que se asignan a cada equipo.

Sin embargo, pueden surgir problemas cuando la dirección no formula estos dos puntos clave con suficiente claridad, porque entonces se crea una zona gris y ya no queda claro qué puede decidir el equipo por sí mismo y qué no.

La visión del producto describe el panorama general de los clientes objetivo y los servicios que se quieren ofrecer a cada tipo de cliente. Esta visión del producto debe apoyar la estrategia empresarial. Si, por ejemplo, tienes una estrategia empresarial basada en un modelo de ventas Low-Touch (poco contacto personal con el cliente), esto fomenta un tipo muy específico de visión del producto. Si un equipo quiere desarrollar un producto que se desvía de la visión y de este modelo, será bastante difícil comercializar el producto.

Los objetivos empresariales específicos se presentan a los equipos ya sea en forma de KPI (Key Performance Indicators – indicadores clave de rendimiento) priorizados – también llamados Product Scorecards – o en forma de OKR (Objectives and Key Results) que también se traducen en distintos KPI. Si el objetivo empresarial es, por ejemplo, reducir significativamente la tasa de abandono de clientes, ese es el mandato para el equipo.

Los equipos reciben la visión del producto y los KPI de la dirección, pero no se les dice cómo deben realizarlos. Ese es el punto en el que el equipo puede trabajar de forma autónoma y flexible. Me gusta describir a los equipos de producto fuertes como comunidades de trabajo para resolver problemas difíciles. Reducir la tasa de abandono puede ser sin duda un gran desafío y probablemente hay innumerables formas de lograr ese objetivo. Lo mismo aplica para aumentar el "Customer Lifetime Value" (valor que un cliente genera a lo largo de toda su relación con la empresa) o reducir los costes de adquisición de clientes, etc.

Cuando se establecen la visión del producto y los KPI, la diferencia entre equipos autónomos y todos los demás es si existe o no una roadmap para la empresa. Si la dirección o los stakeholders le presentan al equipo una lista de funcionalidades obligatorias con las que los clientes y stakeholders ya cuentan firmemente, el equipo tiene poco margen para encontrar la mejor solución para las cuestiones empresariales subyacentes (por no hablar de temas realmente fundamentales).

Y es exactamente por eso que me alegra tanto el resurgimiento de los OKR. Cuando se aplican correctamente, ayudan a reorientar esta situación del output (funcionalidades en las roadmaps) hacia el outcome (resultados de negocio).

2 casos especiales

Hay dos casos especiales que vale la pena mencionar, porque a menudo causan mucho estrés en la empresa.

El primer caso especial tiene que ver con el diseño. No hay duda de que tener un diseñador en cada equipo (que se encargue de funciones orientadas al cliente) es un gran logro para el equipo y los clientes. Estos diseñadores establecen una conexión realmente estrecha con su producto y los desarrolladores y son miembros de primera clase del equipo. Además, no intentan trabajar según un modelo similar a una agencia de diseño interna. Pero, ¿cómo asegurarnos de que los diseñadores quieren mejorar la experiencia para todos los usuarios y no solo para los objetivos de su propio equipo? A los usuarios no les importa tu estructura de equipos. Pero, ¿cómo se fomenta la autonomía y al mismo tiempo se garantiza la coherencia?

Para ello existen varios métodos – desde establecer un "Design Manager" (o Senior Designer) que revise y apruebe el trabajo de todos los diseñadores, hasta una automatización máxima con "Pattern Libraries", "Style Guides" y "Stylesheets".

En lo que respecta a la autonomía y la rapidez, prefiero la automatización, porque el equipo puede lograr un buen diseño (Interaction y Visual) de forma relativamente sencilla. Naturalmente, ocasionalmente también hay "Design Debt", es decir, descubrimos que el diseño necesita ser revisado, y eso se hace en cuanto se detecta el problema. Me gusta este enfoque porque el Design Manager sigue reuniendo un grupo de buenos diseñadores pero ya no tiene que estar presente en cada pequeña revisión (eso lo ralentiza todo y socava la autonomía).

El segundo caso especial son las iniciativas empresariales. Son esos proyectos que siempre abarcan múltiples equipos. Un caso bastante común es la internacionalización. Otro es el llamado "Responsive Design". Otro más es tomarse en serio el mercado móvil. Creo que entiendes lo que quiero decir. En el mejor de los casos, estas iniciativas encajan bien con los KPI priorizados de cada equipo y a menudo hay un objetivo OKR concreto para esta iniciativa. Pero hay que ser consciente de que una iniciativa importante no siempre es una ganancia evidente para cada equipo individual. Sin embargo, cada equipo debe cumplir su tarea, porque de lo contrario la iniciativa fracasará. Siempre les digo a los equipos que a veces simplemente hay que cumplir con tu tarea como parte del todo. Lo bueno es que estas iniciativas son realmente excelentes para el producto y el cliente, así que al menos podemos estar satisfechos con eso.

Conclusión sobre Autonomía vs. Mandato

Si tus equipos no sienten que tienen suficiente autonomía, entonces debes darle a cada equipo una visión del producto clara e inequívoca y objetivos de negocio priorizados e inconfundibles. El contexto contenido en ellos es el mandato del equipo. Asegúrate de que los equipos entiendan este mandato y dales tanto margen como sea posible para cumplirlo.

Este texto proviene del Blog de Marty Cagan y fue traducido por nosotros al alemán.

Crear una visión de producto

=> Product Vision Canvas - La guía para la visión del producto.

Formación Scrum Master

=> ¡Conviértete en Certified Scrum Master en Agile Academy!

Usar métricas ágiles correctamente

=> ¿Qué indicadores deberías conocer como Scrum Master?