Product Crafter Emilio Carrión

Pasos pequeños

Un relato sobre acortar los feedback loops

Conseguir grandes cosas no es cosa de un instante. Requiere esfuerzo continuo, dedicación y constancia. Cuando construimos software no debemos intentar hacer todo de golpe. Hay una forma mejor de gestionar las cosas: hacerlas paso a paso.

Pasos pequeños, uno tras otro, que al final nos lleven hasta nuestro destino.

Qué pasa cuando hacemos pasos grandes

Este mes había habido muchas cosas planificadas: un cambio en el registro de usuarios para añadir un nuevo correo de bienvenida, un ajuste en el sistema de facturación para hacer más fácil la gestión a los clientes y un cambio en uno de los proveedores de pago.

La Sra. Código se hizo el primer café de la mañana y se sentó en su sitio. Se enfrascó rápidamente en el desarrollo. Había sido un mes largo y le quedaba nada para tener todo completado. Cambio aquí, nueva funcionalidad allá, refactor por este otro lado… Estaba quedando todo como ella quería, se fijó en el listado de tareas del sprint. Casi todas acabadas. Además todo parecía funcionar a las mil maravillas porque no había saltado ningún error en producción desde hacía un par de semanas…

Ah, claro, como iba a fallar nada si no había desplegado aún. ¿Cuándo era la última vez que había sacado una nueva versión a producción?

Bueno, no pasaba nada, preparó una nueva release: 32 archivos cambiados, 2000 líneas de código modificadas. Bastantes cambios… La desplegó.

Ocurrió lo esperado.

Slack empezó a sonar, saltaron notificaciones en varios canales avisando de errores. Algunos del sistema de pagos, otros de la facturación. Bueno, al menos no había pasado nada con el correo nuevo de los usuarios (aun).

Lanzó el rollback para volver a la versión anterior y las notificaciones de errores pararon. Tendría que haber hecho más pruebas, comprobar que todo funcionaba como debería… ¿Había hecho todo como tocaba?

Se terminó el café de golpe. Ahora se encontraba ante una situación difícil. Primero: no sabía cuáles de las modificaciones eran los que habían hecho fallar el sistema. Había mezclado muchos cambios de golpe e indagar que es lo que estaba fallando exactamente le llevaría un rato. Segundo: hasta que no solucionara todos los errores no podría sacar a producción los cambios que sí que funcionaban (o tendría que hacer el trabajo de separarlos del resto). No iba a ser algo fácil de gestionar.

Si hubiera sacado una versión cuando tuvo hecho el nuevo email para los usuarios, ya estaría en producción desde hacía dos semanas. Si hubiera desplegado la parte de facturación cuando la acabó la semana pasada, habría detectado los fallos antes y no estarían mezclados con los fallos en el sistema de pagos.

Si lo hubiera hecho paso a paso no estaría en esa situación.

Qué conseguimos con pasos pequeños

El Sr. PM estaba analizando unos datos cuando Sra. Código se acercó a su sitio para enseñarle los cambios sobre el registro de nuevos usuarios. ¿Ya lo tenía? Pero si habían hecho el planning hacía nada…

Resulta que no lo había terminado, pero había implementado parte así que él ya podía probar las nuevas funcionalidades. Dio de alta un nuevo usuario y recibió el nuevo email de bienvenida que habían definido. El contenido estaba todo correcto, pero… el texto de introducción no se acababa de entender. Sobre el diseño tenía todo el sentido del mundo, pero ahora, viendo el correo delante de él y poniéndose en la piel del usuario, puede que no estuviera del todo correcto.

Lo habló con la Sra. Diseño. En efecto era algo claramente mejorable. Una vez integrado en el producto completo la verdad es que podía expresarse de otra manera para aportar claridad al correo.

Gracias a poder haber probado de primera mano el desarrollo en una etapa tan inicial había podido validar que la solución no encajaba tan bien como esperaban y podían corregir a tiempo. Habían evitado confusión a sus usuarios y habían aprendido sobre su producto.

Fue a agradecer a la Sra. Código que le hubiese involucrado en el proceso de desarrollo antes de tenerlo todo acabado. Habían evitado muchos problemas con ello y él se había sentido parte más del ciclo de desarrollo del producto.

Encontró a la Sra. Código solucionando un error de la nueva funcionalidad: el correo no estaba llegando siempre a los nuevos usuarios. Sin embargo, parecía contenta, decía que darse cuenta antes hacía mucho más fácil arreglarlo con el contexto que tenía en ese momento y sin tener que cambiar mil cosas que vendrían después.

Haberlo hecho paso a paso había hecho las cosas más fáciles.

Pequeños pasos incrementales e iterativos

Como hemos podido observar, tanto la Sra. Código como el Sr. PM han podido aprovechar las ventajas de hacer pasos pequeños. Estas ventajas suelen aparecer en la forma de feedback loops cortos que ofrecen feedback temprano y recurrente que ayuda a reducir el riesgo, identificar posibles mejoras y refinar el producto.

Con pasos pequeños somos capaces de involucrar a todos miembros del equipo en el ciclo de desarrollo e incluso a nuestros usuarios que pueden empezar a validar nuestras funcionalidades antes de que estén totalmente acabadas.

También nos permite cazar errores antes de que se nos vayan de las manos y los hace más fáciles de corregir. Si nuestro cambio es pequeño y falla es más sencillo averiguar qué es lo que ha ido mal y solucionarlo.

Cuando desarrollemos software hemos de hacerlo en pasos pequeños y frecuentes. Los feedback loops cortos nos permitirán aprender más y mucho más rápido.

Algunos recursos

TL;DR

La clave para un desarrollo de software exitoso reside en dar pequeños pasos en lugar de intentar grandes avances de una sola vez. La historia de la Sra. Código ilustra cómo realizar cambios incrementales y desplegar funcionalidades de manera gradual no solo evita problemas significativos, sino que también permite obtener feedback valioso de manera temprana.

La adopción de este enfoque no solo facilita la identificación y corrección de errores, sino que también involucra a todos los miembros del equipo y a los usuarios en el proceso de desarrollo. Los feedback loops cortos son esenciales para aprender rápidamente, mejorar continuamente y garantizar que las funcionalidades se adapten de manera efectiva a las necesidades del usuario.