Una de las áreas básicas donde la mayoría de equipos de producto fallan es en entregar con calidad y en tiempos. Dan múltiples excusas pero no toman acciones para resolver los problemas. Falta responsabilidad en el equipo y sobre todo en los líderes. (View Highlight)
Supongamos un squad de producto con su Product Manager, Product Designer, Engineering Manager e ingenieros. Tienen sprints de dos semanas, pero casi nunca terminan las user stories planificadas. Lo normal es que haya un ping-pong entre Ingeniería, QA y Producto probando y arreglando las user stories. Se habla en las retros y se piensan acciones pero el equipo no acaba de mejorar. Negocio se frustra porque Producto siempre lanza tarde. (View Highlight)
Uno de los principales cambios que debes implementar en tu equipo es el concepto de responsabilidad. En Ontruck tenemos «accountability» como uno de los valores de empresa. Para mí, es un valor fundamental que llevaré a todos los equipos en los que trabaje. Ser «accountable» o responsable implica tener cero excusas. Eres responsable de conseguir lo que está en tu mesa, y coordinarte con el resto para que suceda. (View Highlight)
En Ontruck el “mi parte ya está hecha” no vale. Si eres Product Designer, eres responsable de tu diseño hasta llegar a producción. Si eres una Product Engineer, eres responsable de trabajar en el diseño de la solución, programarla y subir a producción sin fallos. (View Highlight)
Los ingenieros no preguntan sus dudas según programan. Tenéis que trabajar en dos aspectos:
• Por un lado, los ingenieros deben ser pro-activos y levantar la mano pronto. Ya sea asíncrono o en los dailies. No puede suceder que dejen las dudas para el final, que programen sin estar seguros o que directamente no se aseguren que la solución tenga sentido (View Highlight)
Por otro lado, debéis involucrar a los ingenieros en el diseño de la solución. La mayoría de equipos trabajan en modo waterfall. El PM pasa al PD los requisitos, y éste pasa a ingeniería los diseños a programar. En ese modo, es normal que los ingenieros tengan dudas y que la solución planteada esté incompleta y no sea la mejor. (View Highlight)
La user story no está bien definida o no cubre todos los flujos (happy and unhappy paths, edge cases). Tenéis que trabajar en dos aspectos: (View Highlight)
Por un lado, debéis refinar las user stories con el equipo. Merece la pena organizar una sesión semanal de refinement donde se ven todas las historias y entre todos se sacan las posibles dudas y agujeros para completarlas. (View Highlight)
Por otro lado, como he dicho antes, debéis involucrar a los ingenieros en el diseño de la solución. Ellos mejor que nadie van a sacar todos esos unhappy y edge cases. (View Highlight)
Si hacéis ambas cosas, lo que acabará sucediendo es que sean los propios ingenieros y Product Designers quienes crean las user stories en vez del PM. Es un cambio muy positivo, ya que el PM debe estar más en el Discovery que en el Delivery. (View Highlight)
Si los ingenieros participan del diseño de la solución, ayudará a reducir todos estos problemas porque esto se habrá hablado antes. (View Highlight)
En el refinement, los ingenieros deben tener claro cómo va a ser la integración entre productos. Si esta conversación se espera a tener después de planificar las user stories, es posible que haya retrasos. (View Highlight)
