El día que abandonamos los roadmaps
El equipo de Tienda Nube viene creciendo de forma vertiginosa en los últimos meses, sobre todo a partir del segundo semestre del 2017, en el que recibimos una fuerte inversión para continuar acelerando el e-commerce en la región.
Esta inyección de capital nos permitió casi duplicar el equipo, y a la vez poder servir a cada vez más clientes, con necesidades cada vez más diversas.
Todo este crecimiento adicionó una capa de complejidad a la hora de planificar, ejecutar y comunicar. Y fue en el medio de ese cambio que nos dimos cuenta de que algo estábamos haciendo mal.
Cómo solíamos planificar y ejecutar en el equipo de Producto
Si bien modificamos varias veces nuestra forma de trabajar, siempre hicimos las cosas de una manera bastante “tradicional” (para el mundo de las startups).
Por un lado, cada equipo de Producto escuchaba a los diferentes stakeholders en tiempo real (o sea, todo el tiempo), y agregaba a su backlog los problemas a resolver y/o las propuestas de soluciones.
Una vez que reuníamos toda esa información sobre la mesa, construíamos un roadmap a corto plazo (próximas semanas), uno a mediano plazo (por trimestre), y uno a largo plazo (por semestre).
Pero para poder construir este roadmap, el equipo debía estimar cuánto tiempo llevaría terminar cada tarea…
¿Qué problemas nos traía esta forma de hacer las cosas?
Notamos que existía una gran diferencia entre nuestras estimaciones y la realidad. El primer sentimiento que nos invadió fue la frustración, y el primer pensamiento que tuvimos fue: “somos pésimos estimando”.
Esta falta de capacidad de estimar nos hacía muy poco predecibles para el resto de la compañía (Growth, Customer Success, Talent, Branding, etc.) y para nuestros clientes. Era muy difícil confiar en una fecha del equipo de Producto.
Como si eso fuese poco, el roadmap cambiaba constantemente y cuanto más lejano era el objetivo, menos chances tenía de ocurrir. Además, para cuando nos dábamos cuenta que no llegábamos con la fecha prometida, ya era demasiado tarde como para hacer una corrección.
Entonces fue cuando paramos la pelota y nos hicimos la siguiente pregunta:
¿Somos pésimos estimando o es imposible estimar cuánto lleva resolver un problema, si todavía no hicimos nada al respecto?
Por suerte, no éramos los únicos con este problema. El fenomenal equipo de Basecamp se había encontrado con el mismo desafío, y lo había resuelto de una manera genial.
Básicamente el problema reside en estimar de manera lineal trabajos que no son para nada lineales, ya que tienen una porción de incertidumbre muy grande.
El desarrollo de software no es como mover una pila de rocas:
El trabajo que requiere resolver problemas es más parecido a una colina, en donde hay una fase cuesta arriba en la que uno va descubriendo de qué se trata y, recién cuando llegas al tope de esa colina, se puede observar hacia abajo y estimar cuánto falta para terminar.
Entonces, ¿Qué cambios hicimos?
Inspirados en la dinámica de ciclos de seis semanas que había implementado Basecamp (y que por otro lado Intercom apoyaba), decidimos dejar de armar roadmaps y comenzamos a construir ciclos.
En nuestra adaptación, tenemos ciclos de 6 semanas, con 2 semanas de separación entre uno y otro para planificar. Además, tenemos una demo interna de Producto en la semana 4, y una demo para toda la compañía en la semana 6.
Por otro lado, en esas 2 semanas de planificación, nuestro equipo cuenta con dos semanas de free roaming, o sea que tienen la libertad de elegir qué batallas atacar y en qué orden. Por lo general esos días se utilizan para hacer refactors de código, arreglar algún bug secundario o incluir alguna funcionalidad extra.
En esas semanas de planificación, el equipo de Product Owners trabaja codo a codo junto con clientes, el equipo de Customer Success, y el equipo de Research. Este equipo de Research está en contacto directo con los clientes y utiliza herramientas de Jobs To Be Done para entender las necesidades de fondo, o en términos de JTBD, los Jobs. Esto nos proporciona de valiosos insights al equipo de Producto.
En Tienda Nube nos tomamos muy en serio las necesidades de nuestros clientes, y es por eso que son nuestros principales aliados a la hora de entender y crear.
Una vez que tenemos claros cuáles son los problemas más importantes que deberíamos resolver en el corto plazo, nos hacemos la siguiente pregunta:
¿Cuál es la versión de seis semanas de esta solución?
Y una vez que tenemos claras todas esas soluciones, las compilamos en un documento en el que explicamos detalladamente todos los problemas que vamos a resolver y cómo lo vamos a hacer, y lo compartimos con toda la compañía. Pero esta vez con un horizonte muy claro: seis semanas.
Luego, durante la ejecución de ese ciclo, abandonamos la forma tradicional de reportar el estado de los proyectos del tipo “Avanzamos un 46%”, y comenzamos a utilizar los hill charts de Basecamp.
¿Qué beneficios trajo todo esto?
Ya llevamos tres ciclos de seis semanas, y dentro del equipo de Producto pudimos observar mejoras de todo tipo:
- El equipo se siente menos presionado, o sea más feliz. No hay más compromisos auto impuestos de deadlines ya que están preestablecidos y fijos para todos. Esto quitó una presión enorme que cargaban nuestros individual contributors (programadores y diseñadores en su mayoría).
- Dejamos de discutir fechas y pasamos a discutir scopes (alcances). De golpe la charla se centró en definir el MVP o “cuál es la mejor versión de seis semanas de esto”.
- Esta separación en ciclos fijos nos obligó a partir las soluciones complejas en diferentes releases, y así logramos entregar valor mucho más rápido.
- Al separar las tareas de un proyecto dentro del hill chart, nos damos cuenta a tiempo cuando hay que hacer una corrección. Ya que podemos diferenciar entre las tareas que pertenecen al camino crítico de un proyecto y ver en qué segmento de la colina se encuentran. Si en la semana 2 una tarea crítica se encuentra de la izquierda (“Figuring things out”): Houston, we have a problem.
- La tarea de nuestros Product Owners se vio inmensamente simplificada. Pasamos de estimar y planificar todos los días, a hacerlo solamente cada 6 semanas.
Además, puertas afuera también vimos varias mejoras. Nos volvimos más predecibles, el resto de la compañía tiene mucho más claro que vamos a hacer y por qué, y sobre todo cuándo va a estar listo.
La prosa del documento que describe qué se va a hacer en el ciclo comunica mucho mejor que cualquier Gantt. Para darse una idea, acá pueden ver un ejemplo de Basecamp.
Para, para, para… ¿vos me estás diciendo que resolvieron todos los problemas de planificación y ejecución?
¡No! Pero casi. Todavía nos quedan muchos desafíos por desenredar, pero cada día estamos más cerca de tener un equipo más saludable, predecible y que entrega la mayor cantidad de valor posible a nuestros clientes.
Si llegaste hasta acá, te encantan los desafíos y sos de los/las que se enamoran de los problemas y no de las soluciones: animate y sumate a cambiar la vida de nuestros clientes con nosotros.
