ya escribí otras veces sobre la importancia de la velocidad y creo que a veces en tecnología le pedimos a los equipos de producto velocidad en el vacío. pensamos que la velocidad es un tema de orden o de voluntad pero lo cierto es que muchas veces la velocidad del equipo es resultado de decisiones técnicas que se tomaron en el pasado y revertirlo toma tiempo.
en esta nota me gustaría contar el proceso que vivimos en atlas para pasar de releases casi inexistentes a varios releases semanales (entre 4 y 5 releases por semana por las últimas 6 semanas). quiero contar mi diagnóstico de por qué cuando yo comencé a trabajar con este equipo no era posible hacer releases rápidos y por qué ahora sí y qué hicimos para llegar hasta acá.
todo lo que voy a contar a continuación fue un aprendizaje para mí. nunca había vivido un proceso así antes y no tenía un plan cuando comencé. tenía una idea clara de a dónde quería llegar y me fui guiando por intuiciones a lo largo del camino.
quiero contar este proceso para documentarlo y no olvidármelo y por que puede ser útil para otros. por esta razón esta nota va a ser larga y no busco que sea entretenida. mi plan es que sea un catálogo de todo lo que hicimos y todo lo que ahora sé que habría que hacer para llegar hasta acá.
por qué antes nuestro proceso de release era lento
me tomó un tiempo identificar por qué a nuestro equipo de producto le costaba hacer releases a producción. podía ver los síntomas de un equipo que tenía problemas (poca interacción, muchos bugs, solución reactiva de problemas, ningún roadmap o proyectos en progreso con prioridad bajísima) pero no entendía las causas.
estas son algunas las razones que ahora veo que causaban que los releases fueran lentos:
- codebase con mucho tech debt. nuestro equipo venía de muchos cambios de dirección en producto y negocio. esto sumado a velocidad de la mala (shortcuts por todas partes, funciones de 900 líneas), ausencia completa de tests y typescript hicieron que el codebase sea algo realmente inmantenible.
- modelo de datos no escalable. muchos meses de cambios de dirección y poca estrategia hicieron que el modelo de datos fuera igual de malo que el codebase. el problema de esto es que los datos que almacenábamos no eran confiables y había casos básicos para nuestro modelo de negocios que no era posible reflejar en el modelo de datos (todo era un parche; mucha info duplicada, inconsistente).
- un equipo muy desmotivado. creo que los dos puntos anteriores explican cómo se sentía el equipo en este momento. cualquier feature que quisiéramos sumar era muy traumático, el 80% del día era solucionar bugs (tampoco había un proceso claro para esto), había muy poca comunicación (literalmente muy pocos mensajes en slack) y mucha desconexión con el resto del equipo/con los equipos enfocados en el negocio.
- falta de estrategia. este sin duda es mi gran aprendizaje de este proceso y voy a hablar mucho sobre esto más adelante. en resumen no había una estrategia clara de producto ni a corto ni a mediano plazo. esto no era responsabilidad del equipo de producto. ahora sé que para poder crear una estrategia hay un norte que tiene que estar definido desde el negocio. los síntomas de que nos faltaba estrategia eran que el resto equipo nos pedía un roadmap que no existía o nos preguntábamos si necesitábamos un head de producto. creo que lo que faltaba en realidad eran un objetivo y estrategias claros para el producto.
los primeros meses de trabajo
los cuatro puntos que mencioné antes eran iguales de frustrantes para mí que para el equipo. tenía ganas de pensar en features nuevos pero me daba cuenta de que había que hacer mucho trabajo por atrás para llegar ahí. estas son algunas de las cosas que hicimos en los primeros meses para mejorar nuestra velocidad de release:
1. el equipo necesitaba un win. lo primero que hicimos fue un proyecto de cero: una app nueva para suppliers. el objetivo de esta app era claro: nuestro product designer venía de meses de diseñar pantallas que nadie programaba. nuestro equipo de front estaba agotado de agregarle parches a una aplicación que no daba para más. necesitábamos un blank canvas. una nueva app, una nueva librería de componentes, un proyecto que nos diera orgullo. también necesitábamos darle tiempo a backend para los cambios grandes que tenía que hacer. empezamos por acá y un par de semanas después tuvimos una app diseña y con front 100% implementado. esto fue una primera prueba de la velocidad que podía tener el equipo trabajando con mejores herramientas. este proyecto nunca tuvo integración de back y nunca vio la luz pero cumplimos ese objetivo y tuvimos una app con mejor diseño y mejor ux hecha 100% por este equipo.
mientras tanto el equipo de backend necesitaba cambiar algo para que pudiéramos hacer proyectos más ambiciosos.
2. necesitábamos rehacer nuestro modelo de datos. los problemas en el modelo de datos eran claros. mi indicador era que la información que estábamos almacenando era errónea y muchas veces contradictoria (i.e. dos queries distintas que deberían dar el mismo resultado daban resultados distintos). también era una intuición: mi sensación al ver las tablas de la db era que cada dev había agregado columnas para lo que necesitaba desarrollar sin tener en cuenta el todo (el resultado era mucha info duplicada inconsistente). cambiar el modelo de datos es un proyecto inmenso y creo que muchas cosas en este proyecto estuvieron mal. la primera es que no supimos recortar el scope. necesitábamos pensar un mejor modelo, implementarlo, migrar la data vieja y deployarlo. las 4 cosas eran extremendamente desafiantes y lamentablemente este proyecto duró 6 meses (habíamos planificado 1). los resultados fueron gigantes cuando estuvo terminado: ahora los datos reflejan la forma en que pensamos el modelo de negocios. nuestro modelo de datos soporta realmente los datos que tiene que almacenar, sin hotfixes, sin parches, sin columnas nuevas cada vez que no sabemos dónde va algo. (también tengo aprendizajes de las decisiones que tomamos: priorizamos que el modelo de datos fuera claro a la hora de la escritura pero nunca pensamos en la lectura).
3. necesitábamos más y mejor talento. este es el punto más sensible de esta nota pero quiero ser transparente. nuestro equipo tenía algunas personas fantásticas y algunas que no. para mí, una paracaidista total en este equipo, el desafío estaba en entender quién estaba de un lado y quién de otro. yo tiendo a pensar que cuando hay un problema con las personas las razones pueden ser dos: contexto (es decir: esta persona es brillante pero las condiciones en las que está hacen que no pueda brillar) o individuales (esta persona no trabaja bien por falta de seniority o agency). este equipo tenía muchos problemas de ‘contexto’ por eso para entender cómo trabajaban las personas de verdad mi solución fue darle a casi todos proyectos desde cero donde pudieran pensar y proponer como si no hubiera más nada. algunxs brillaron y para otros fue un infierno.
la parte feliz de este proceso para mí fue aprender a contratar. escribí sobre eso acá. con un equipo armado nos pusimos a trabajar en el próximo milestone.
3. era necesario reescribir de cero el backend. esto no fue una decisión obvia ni fácil. nuestro backend era lo que describí antes: un nido de ratas. funciones inmensas (900 líneas o más para hacer cosas muy simples), parches para resolver casos específicos en todas partes, 0% de test coverage, no usábamos typescript y no teníamos buenas maneras de hacer testing o qa. decidir reescribir el backend fue el resultado de preguntarnos qué tomaba más tiempo: que este equipo nuevo le dedicara tiempo a entender todo lo que ya estaba hecho o escribirlo de cero. nos inclinamos por lo segundo por pura suerte y fue una decisión super acertada. hoy nuestro backend tiene 100% de test coverage varios meses después de tenerlo productivo y la arquitectura es escalable (siempre hay problemas y cosas a mejorar pero estamos parados en un lugar muy diferente). hicimos esto de manera gradual y el tiempo que nos tomó esto vs. agregar tests y reescribir lo viejo finalmente fue claramente menor.
4. un proceso claro para reportar y corregir bugs. todo esto tenía que suceder en simultáneo con seguir operando en el día a día. eso significaba que íbamos a seguir teniendo bugs que resolver. recuerdo que en ese momento todo nuestro equipo no técnico estaba muy frustrado con el equipo de producto. estaban frustrados porque las cosas estaban rotas y el equipo era muy poco responsive. hay dos cosas que hicimos acá: la primera fue literalmente bajar de slack todos los pedidos que llegaban para los devs, ordenarlos en prioridad y solucionar de fondo los 5 que más aparecían. esto era importante porque si los devs seguían teniendo que ocupar el 90% de su tiempo en solucionar bugs no iban a poder trabajar en proyectos más grandes. la segunda cosa que hicimos fue poner devs on-call cada semana, rotativos. el goal de esto es que hubiera un owner claro cuando llegaba un pedido. creo que esto nos ordenó un poco pero este punto sigue siendo un dolor hoy en día y creo que todavía no aprendí cuál es el ideal de cómo hay que organizar el trabajo en features vs. bugs.
5. el equipo necesitaba expectativas claras y un career path. más allá de la motivación que te da trabajar en proyectos que te dan orgullo lo otro que es importante para mí es que los equipos tengan un norte claro. me parecía importante que este equipo supiera qué era lo que se esperaba de ellos a nivel técnico y a nivel de negocio: era importante que fueran devs de primer nivel en lo técnico y que estuvieran muy involucrados en decisiones de negocio. marcar las reglas de juego fue importante para dos cosas: poder tener un framework para analizar quiénes no entraban ahí y para poder establecer reglas claras para premiar a los que sí (en nuestro caso: performance reviews una vez al mes y oportunidades de moverse hacia adelante en la escalera cada 6 meses).
con todas estas cosas arriba y comenzando a dar algunos frutos llegó mi gran aprendizaje de este año. necesitábamos un/a (o unos/as) PMs aunque yo en ese momento todavía no lo sabía.
por qué empezamos a tener PMs
la idea de que el equipo necesitaba un/a PM nació de un lugar inesperado. cuando pasaron algunos meses y el equipo funcionaba de manera mucho más aceitada de repente tuvimos tiempo para pensar features. además veníamos de no tener releases hace mucho tiempo (porque estábamos haciendo mucho trabajo por atrás para que las cosas estuvieran bien). la idea de que necesitábamos un/a PM nació de la necesidad de pensar en qué queríamos hacer con el producto, es decir, cuál era la estrategia de producto.
quiero contar de donde vengo: programé durante 10 años y nunca jamás tuve una buena experiencia con un PM. en los equipos en los que yo estuve la PM era una persona que bajaba una lista de tareas sin ningún contexto y te pusheaba para que las termines en una fecha. yo me opuse durante toda la vida de Atlas a que tuviéramos PMs y creo que esto es porque no entendía la importancia de este rol.
la otra cosa que noté es que cuando no hay PMs alguien más hace ese trabajo igual. en nuestro caso eran los devs: planificando, estimando, etc. esto no está mal pero creo que no es el mejor uso de su tiempo. por otro lado aunque pueden planificar y estimar no conocen o no elaboran la estrategia así que igual falta un pedazo.
me convencí de que lo que nos faltaba era una PM escuchando el podcast de Lenny y porque me empecé a hacer una pregunta: hacia dónde quiero que vaya el producto y cómo hago que lleguemos ahí. investigando aprendí que un buen PM uno ambas cosas y se encarga de lo más importante de todo: la estrategia.
cómo empezamos a pensar estrategia
pensar en estrategia es de las cosas lindas que me ha dado este año. voy a definir a la estrategia de producto como creo que más se entiende: una estrategia es una serie de pasos consecutivos que si se cumplen nos permiten cumplir una meta.
el mejor ejemplo para mí son el objetivo y la estrategia de Tesla:
Goal: Tesla’s mission is to accelerate the world’s transition to sustainable energy
Strategy: Build a high-priced sports car → Use that revenue to build an affordable car → Use that revenue to build an even more affordable car → While doing so, also provide zero-emission electric power
el momento en que de verdad pivoteamos la forma de pensar producto en Atlas fue cuando dejamos de hacer cosas porque sí y ordenamos nuestros features e ideas detrás de un goal grande.
a raíz de esto empezamos a escribir documentos (i.e. PRDs) con 4 secciones: misión y visión del proyecto, estrategia y features. lo importante para mí de esto es que las cuatro secciones son consecutivas. la visión se desprende de la misión, la estrategia de la visión y los features son el resultado natural de ejecutar la estrategia.
podría escribir una nota entera sobre esta parte pero creo que el aprendizaje importante para compartir es que ordenamos qué hacer desde producto detrás de un objetivo claro y eso nos dio más orden y sentido.
cómo recuperamos los releases semanales
después de muchos meses el equipo empezó a trabajar de forma más ordenada. todo lo que describí antes nos ayudó a recuperar la velocidad de releases y aunque ahora tenemos desafíos nuevos y la calma siempre está en peligro (porque los negocios crecen y nada es inmutable) hoy tenemos bases sobre las que podemos construir y recuperamos nuestra velocidad de release. hoy el equipo manda a producción entre 4 y 5 features nuevos (importantes) por semana.
no creo que haya un silver bullet en lo que respecta a trabajar con personas. los procesos son complejos y los aprendizajes de hoy seguramente no se puedan replicar mañana. lo importante para mí en esta nota es contar cómo mejoramos un proceso que se sentía muy caótico con la aclaración de que este proceso tomó muchos meses y en todas las cosas cometimos muchos errores.
espero que les sirva si están pasando por algo parecido y que recuerden que siempre hay luz al final del tunel :)