Producto debe entregar con calidad y en tiempos, ¿por qué cuesta tanto?
Producto debe entregar con calidad y en tiempos, ¿por qué cuesta tanto?
Uno de los principales cambios que debes implementar en tu equipo es el concepto de «accountability». Veamos cómo utilizarlo para subir el nivel de tu equipo.
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
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.
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.
¿Te resulta familiar? ¿Por qué sucede tanto? ¿Qué podemos hacer para entregar constantemente con calidad y en tiempos? Veamos los problemas aparentes, sus causas raíz y las soluciones que a mí me han funcionado.
Los ingenieros dan por terminadas user stories con fallos
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.
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.
¿Qué causas raíz hay detrás de tener user stories con fallos?
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.
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.
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:
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.
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.
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.
La solución completa falla en la integración entre back-end y front-end o mobile. Varias ideas:
Si los ingenieros participan del diseño de la solución, ayudará a reducir todos estos problemas porque esto se habrá hablado antes.
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.
Si un sprint se hace back-end y en otro sprint se hacen los frontales, es probable que haya desconexión y provoque retrasos. Es mejor ir acompasados.
Lo ideal es que sea la misma persona quien haga el back-end y el frontal. En Ontruck tenemos el valor de «versatility», que promueve ingenieros full-stack. Hemos invertido mucho en que los frontends y mobile puedan hacer pequeñas tareas de backend, liberando a los backend para las tareas más complejas.
Mi consejo es que marquéis que una user story solo está «Done» cuando está en producción. Así os aseguráis que los ingenieros hablen y se ayuden entre ellos para hacer bien la integración.
Los ingenieros suben su parte sin probar bien la solución, esperando que el QA o Producto la pruebe. Mi principal consejo es que cortéis la red de seguridad de ingeniería. Las pruebas manuales de QA o Producto son como la droga. Es muy difícil dejar de hacerlas. Los ingenieros se acostumbran y acaban programando con peor calidad. Ellos deben estar seguros de subir a producción sin que el resto valide la solución. Los ingenieros deben tener esa «accountability». Mis consejos:
Los ingenieros deben asegurar que lo que han programado está perfecto. Para ello, deben probar todos los casos por su cuenta. Porque si no prueban, ¿cómo saben que han hecho un buen trabajo? Cuando un ingeniero me entrega algo y tiene fallos, pierde muchos puntos de golpe. Puedo entender las dudas y el retraso, pero no acepto la falta de detalle y de «accountability».
Si un ingeniero necesita ayuda, puede levantar la mano y pedir un Team Testing conjunto con QA o Producto. Muchas veces es necesario en funcionalidades más complejas o partes del sistema más delicadas. La clave es que el ingeniero lidere esa sesión. Él es el responsable de la calidad de lo que programa.
Los ingenieros deben programar tests automáticos. No lo consideréis como un extra, consideradlo como una necesidad para asegurar la calidad ahora y en el futuro. Los tests forman parte de la tarea.
La empresa debe tener una buena cobertura de tests automáticos, unitarios e integración. Tristemente, las falsas prisas y la falta de experiencia nos acaban llevando a tener bases de código sin casi cobertura de tests. Es un grave error. Siempre debemos tener una cobertura de tests razonable que permita a los equipos tener tranquilidad cuando programan una funcionalidad.
QA debe dejar de ser una red de seguridad. Moveros a un modelo de Quality Assistance en vez de Quality Assurance. QA debe ayudar a ingeniería a desarrollar con más calidad, a preparar los productos para las pruebas automáticas y a programar las más complejas.
PM y PD deben dejar de hacer los acceptance. Los PMs deben estar haciendo Discovery, hablando con clientes. Los PDs deben estar haciendo Research y probando prototipos con clientes. Si eres PM o PD y estás haciendo pruebas manuales, deja de hacerlas hoy mismo. Mueva esa responsabilidad a ingeniería.
La User Story es muy grande. Cuanto más grande sea, más probable es que haya fallos. Mi recomendación es que tengáis User Stories muy pequeñitas, con un foco claro.
Los ingenieros tardan más de lo que pensaban
Cumplir los sprints y alcanzar los deadlines forman parte de ese «accountability» que estamos hablando. Es muy importante que un equipo de producto sea predecible, que sepa cuánto avanza normalmente y que se pueda confiar en que llegue a sus objetivos.
¿Qué causas raíz hay detrás de no cumplir los sprints?
Se han planificado demasiadas User Stories. El PM debe priorizar, pero los ingenieros deben decidir cuánto pueden asumir y por tanto, a qué se comprometen a acabar. Este compromiso es crítico. Pueden fallar de vez en cuando, pero lo normal debe ser que los sprints se cumplan.
Se han estimado mal las User Stories. Esto normalmente sucede porque no se ha hecho un buen refinement; y porque ingeniería no tenía totalmente claro el impacto de la User Story. Si los ingenieros diseñan la solución, tendrán más clara la estimación.
Los ingenieros dan por acabada las User Stories pero tardan en subir a producción. Mi principal consejo es que consideréis una tarea como «Done» solo cuando esté en producción. Por tanto, debéis desplegar durante el sprint. Si no, hay un alto riesgo de que se encuentre un fallo el siguiente sprint y los ingenieros deban seguir trabajando en esa tarea.
La solución es más compleja técnicamente de lo que pensaban. Esto normalmente sucede porque ingeniería no ha invertido tiempo en el diseño de la solución. Se piensa solo en diseño de interfaz, pero no en el diseño de la arquitectura. No esperéis a tener Arquitectos de Software para invertir tiempo en el diseño de la soluciones antes de estimarlas y priorizarlas.
La solución no estaba 100% definida, hubo que definir o diseñar entre medias del desarrollo. Producto e Ingeniería deben diseñar juntos las soluciones; y deben hacer mejores refinements.
Ha habido cambios de definición en mitad del desarrollo. Producto e Ingeniería deben diseñar juntos las soluciones; y deben hacer mejores refinements. Si el cambio viene por negocio, se debe trabajar con ellos en el diseño de la solución.
La solución fue programada por un ingeniero sin mucha experiencia en ese código, y necesitó ayuda del senior. A veces hay que invertir para que ese ingeniero coja experiencia y ganemos rapidez y versatilidad en el futuro. Sin embargo, hay que ser realista en las estimaciones y en lo que uno puede asumir en función de su experiencia.
Los ingenieros han tenido muchas interrupciones por soporte, reuniones o tickets de BAU urgentes. Debéis reducir al mínimo las interrupciones. Podéis tener una figura de soporte por semana para que solo impacte en una persona. Debéis reducir las reuniones que no aporten. Producto debe planificar ese BAU evitando que se convierta en urgente.
¿Cómo trabaja un equipo de producto que entrega con calidad y en tiempos?
Una de las áreas donde estoy orgulloso de los diversos equipos de producto que he liderado es que hemos conseguido los procesos y las dinámicas que nos han permitido entregar con calidad y en tiempos. En Ontruck llegamos a tener cinco squads con sprints semanales que iban entregando valor a toda velocidad sin prácticamente fallos y sin tener que hacer pruebas manuales desde Producto.
Haciendo resumen de todos los consejos anteriores, un equipo de producto high-performing se caracteriza en este aspecto por:
Los ingenieros participan del diseño de la solución junto a Producto. Incluso la lideran si es una solución más técnica. Si la solución es compleja, invierten tiempo en el diseño técnico de la solución y cogen feedback del resto de ingeniería.
Producto e Ingeniería escriben las User Stories en base a la solución que han decidido. Ingeniería se asegura tener todo lo que necesitan.
El squad hace una buena sesión de refinement donde se aseguran que todas las User Stories están claras y completas; y donde las estiman conjuntamente con realismo.
Ingeniería planifica su sprint con la priorización del PM, y con su criterio para asumir compromisos.
Los ingenieros levantan la mano en cuanto tengan alguna duda o bloqueo; para resolverlo en seguida y conseguir completar el sprint.
Los ingenieros se aseguran que las User Stories que han programado están bien hechas, usando los tests automáticos y sus propios pruebas manuales. Si necesitan ayuda, organizan un Team Testing con QA y Producto.
Los ingenieros suben a producción las User Stories antes de que termine el sprint para que se consideren como hechas, y por tanto, haber cumplido el compromiso.
Como puede que estés pensando, no parece tan complicado. Y sin embargo, se requiere de mucho trabajo para llegar a ese nivel. Cada uno de los puntos anteriores esconde un cambio de mentalidad en el equipo, y un nivel de exigencia que hay que cumplir uno mismo, y pedir al resto. Es tu responsabilidad como líder de producto o ingeniería llegar a ese nivel.
Espero que este artículo os haya aportado ideas para subir el nivel de vuestro equipo, y evitar la frustración de entregar con fallos y a destiempo. Si tienes otro caso que no he cubierto aquí, coméntamelo.
Para terminar, te animo a darme feedback sobre este artículo y sugerirme temas que debería profundizar o tratar en siguientes artículos.