Se ha creado un poco de polémica debido a este tweet que escribí sobre estimar y creo que en buena medida es debido a que me explique bastante mal, en ningún momento quería ligar estimar con la calidad porque tiene cero sentido.
Estoy escribiendo un post para la newsletter sobre estimaciones y buscando info me he encontrado ésto. Y me pregunto cuánto está la gente fuera de la realidad. ¿Cuánto importa la calidad sino hay producto? ¿Cuánto importa la calidad si la empresa cierra pq no llegas?Era en respuesta a un comentario de una persona que hacía eso precisamente, y decía que la estimación les llevaba bajar la calidad. En cualquier caso, vamos al lío. Estimar o no.
A pesar del título voy a empezar negando la mayor y dejándolo bastante claro, creo que las estimaciones no funcionan para lo que la mayoría las usa. No se puede decir lo que se va a tardar en hacer algo. Me da igual cómo se estime, horas, puntos de historia, tallas de camisa, etc. Por no hablar de que pocas, muy pocas veces he visto que un 3, un 8, una xs o una s signifique lo mismo para dos personas, e incluso peor, más de una vez he visto herramientas que mapean esas tallas o puntos a semanas :D Y cuando los equipos estimaban en puntos, luego la dirección mapeaba esos puntos a semanas… Y no acaba aquí… luego ponían como objetivo cumplir el roadmap al 80%, pero oye las estimaciones no son compromisos blabla blabla.
Las estimaciones tal cual se usan en muchas empresas no son más que una fuente de frustración para unos y una fuente para meter presión para otros. Sirva como ejemplo esta anécdota, en una empresa nos pidieron estimar cuanto tardaríamos para entregar un proyecto, el proyecto era muy muy complejo porque era refactorizar una parte clave del monolito que tenía cientos de dependencias con otros equipos (más de 10 equipos), además ese refactor incluía una nueva arquitectura, un nuevo lenguaje, nuevo protocolo de comunicación de servicios, pasaba de modelo relacional a NOSQL, etc.., y pretendían que estimáramos lo que iba a llevar todo el proyecto… :D, pero ojo que es mejor, cuando se dio la estimación se dijo al equipo desde la dirección que eso era mucho y que había que entregarlo en Marzo, así que había que volver a estimar pero a la baja xDDD.
Lo repito de nuevo: las estimaciones para establecer cuándo tendremos algo no funcionan. Dicho esto, creo que tristemente son necesarias. Porque mucha gente confunde no estimar con anarquía. Y lo que quieren es ponerse a programar en cada issue día a día y ya se llegará. Pretenden llegar al objetivo simplemente haciendo eso y sin analizar el proyecto/funcionalidad al empezar, cada sprint o cada x semanas… Y por desgracia muchos equipos solo hacen ese análisis cuando estiman.
Ese análisis de lo que tenemos delante, de su complejidad y demás, es crítico para entender si es viable. Y entre otras muchas cosas nos sirve para priorizar, para alinear objetivos, para entender si tenemos la gente necesaria para poder llevarlo a cabo, para ver si tenemos la información necesaria para la iteración que tenemos delante, etc…obviamente entendiendo que jamás podremos predecir con qué llegaremos y en que fecha con precisión, hay que verlo como algo orientativo. Y por supuesto, no tiene que ser solo estimar un día y listo, sino que este análisis tiene que ser recurrente para poder entender qué necesitamos quitar o que ayuda necesitamos para poder sacarlo a producción, aunque sea con lo mínimo. Es decir, este análisis sirve para podar el árbol, para identificar que ramas no es necesario que se cuiden en lugar de tratar de tener todas las ramas bonitas y bien cuidadas.
Una cosa sobre dead lines. Creo que hay que bajar a la realidad y entender que en muchas ocasiones los deadlines existen por buenas razones, cosas como un evento clave para la empresa como podría ser lanzar una funcionalidad en un momento concreto (por ejemplo, el mobile world congress), también podría ser porque un cliente lo pide y no nos quede otra, podría ser que necesitamos llegar a un quarter con una funcionalidad, etc. Es muy comprensible que gente de ventas o de marketing quieran tener alguna idea de cuándo van a poder tener algo. Creo que nos falta empatía a veces a los técnicos con esta gente. No tenemos que comprometernos a tener todo en X fecha pero entre eso y decir que no hay nada que hacer hay un trecho. Perfectamente se puede dar algo orientativo, dejando claro que no es un compromiso (aunque esto muchas veces requiere que la cultura de la empresa sea la adecuada) y luego en cada iteración ir ajustando para ver con qué se puede llegar. Lo mismo se llega con un MVP en lugar de todo lo que se esperaba, pues que sea así. Es más, desde mi punto de vista deberíamos plantear estas cosas así desde el principio, en lugar de poner un horizonte lejano con un montón de funcionalidades, vamos a hacer primero que funcione con el mínimo esfuerzo, después ya iteraremos e irá mejorando, muy en la línea que tenemos en Tinybird…
Pero repito eso no significa que las estimaciones garanticen llegar, no va a pasar. Lo que va hacer que se llegue o no, es ese análisis inicial, esa revisión constante de dónde estamos, de lo que queda, etc, es decir, esa poda que mencionaba arriba.
Otra cosa interesante de poner límites temporales (no tiene porque ser una fecha concreta, puede ser querer salir con algo al final del quarter) es que te obliga a analizar teniendo en cuenta restricciones y eso te obliga a pensar que deberías quitar para llegar, a pensar en que es lo importante y que es prescindible aunque deseable.
Me encantaría que se cambiara el nombre de estimaciones a análisis de complejidad e incluso a “vamos a ver si podemos hacerlo” que creo que es más real.
Gracias a los que lo habéis revisado ❤️
¿qué opinas a tener iniciativas que impactan KRs
en vez de estimaciones "clásicas" (story points,
tallas de camisetas)?
Yo creo que podría ser una buena alternativa
siempre y cuando:
- el equipo sea un "strong product team"
(ownership di un problema específico)
- la iniciativa sea impulsada por el equipo (cross functional team si viene al caso y incluyo el PM)
- la iniciativa no tenga "deadline" (rollo para finales
de este Q nos comprometemos a entregar X)