Si un pintor va a tu casa y te dice lo que tarda, ¿Por qué en software no lo hacemos?

Durante mi carrera profesional he trabajado en muchos sitios y en diferentes ciudades. He visto muchos sectores diferentes: seguros, banca tradicional, pymes o sectores públicos. También he tenido la suerte de acompañar a equipos de otros sectores como retail, telefonía o multimedia. Hay algo común en todos ellos ¡Se gestionan por estimaciones!

Gestión basada en la estimación

El concepto es simple, antes de empezar a trabajar se realiza una estimación de cuánto tiempo y dinero nos llevará el trabajo que nos han pedido. Esto se conoce como “Estimation Based Management” (EsBM) y es el modelo que se aplica en casi todos los sectores. El motivo, querer tener control antes de empezar a trabajar. Los motivos son diversos: saber lo que me va a costar, estudiar viabilidad, ajustar presupuestos, coordinar proveedores o garantizar que llegamos a una fecha concreta.
<modo irónico: on> El EsBM es maravilloso, nos permite saber antes de empezar todo lo que va a ocurrir, porque como todo el mundo sabe las estimaciones nunca fallan <modo irónico off>.

Si estimar es jugársela, le sumamos presiones como “esto tiene que estar en navidad”, o “no le podemos decir al cliente otra cosa que no sea que llegamos” o “si cobramos eso perdemos dinero” entonces la receta para el fracaso está garantizada.

Los pintores estiman

Cuando entramos en el debate sobre las estimaciones y su importancia siempre hay alguien que se saca de la manga el ejemplo del pintor con frases parecidas a estas: “Cuando un pintor va a pintar tu casa, te dice cuanto va a tardar y te da un presupuesto, ¿Por qué nosotros no?”
Acabemos con la falacia del pintor:

• El pintor va a tu casa y ve el problema, en software muchas veces no podemos ver los sistemas del cliente.
• El pintor no tiene dependencias de terceros más allá de la pintura por lo que no hay que perder tiempo en eso.
• Un pintor suele ver una casa normal en un tiempo corto, cuando nosotros vemos el código que vamos a crear/sustituir pueden ser decenas de miles de líneas de código, es imposible hacerse una idea.
• Cuando contratas un pintor, si a mitad del trabajo le pides un color diferente, tu (como cliente) asumes ese coste, esto en software muchas veces no está tan claro. Igual pasaría si le dijeses que tiene que pintar n-habitaciones más que no se había tenido en cuenta en el presupuesto inicial.
• Un pintor suele trabajar solo o como mucho en pareja, la cantidad de interacciones entre ambos es baja comparado con un equipo de software de muchas personas.
• El pintor trabaja en un mundo mucho más predictivo que el software que al ser complejo no se puede predecir.
• El trabajo del pintor no es un trabajo creativo, el pintor tiene siempre el mismo problema, pintar algo, y la misma solución, aplicar pintura. Esto no pasa con el desarrollo.

Si aún así no te he convencido, te animo a que contrates un pintor para tu nueva web con microservicios, seguro que la tiene a tiempo y sin desviaciones económicas. No tengo nada en contra de la profesión de pintor, es más, no es fácil encontrar uno bueno, sin embargo, es el típico ejemplo simplista que realmente no es comparable con un desarrollo software. La pintura como mucho se mueve en el mundo complicado, esto lo hace predecible. Por contra, el software se mueve en el mundo complejo, lo que impide que podamos estimar.

¿Qué alternativa tenemos entonces para tratar de ser predecibles? 

La alternativa la encontré gracias a scrum.org a través de su paper Evidence Based Management (EvBM). La gestión basada en la evidencia se sustenta en la esencia de Scrum. Gestionamos en función de la experiencia que acumulamos. Si queremos compararnos con alguna profesión, pensemos en los científicos. Ellos se basan en la evidencia que encuentran para tomar decisiones y no se basan en la estimación. Sí, usan hipótesis, pero no son estimaciones son suposiciones de lo que podría ocurrir ¡Nadie sufre porque no se cumplan! En EvBM proponen 12 medidores de un producto software dividido en tres grandes áreas: valor directo, time-to-market y capacidad de innovación. De esta manera sabremos el estado de nuestro producto, más allá del simple medidor de % de avance. 

A la hora de aplicar la evidencia a una Sprint Planning os doy una alternativa. En vez de estimar en horas o puntos de historia, no estimes, ponte a trabajar. Cuando lleves tres Sprints mira cuantos elementos del Product Backlog has completado y calcula la media y la desviación. Por ejemplo, un equipo podría tener una medición de 10 +- 3 elementos. Lo que supone esto es que en el mejor de los casos hará 13 y en el peor 7. ¡Empezamos a ser predecibles! 

Si hacemos esto empezaremos a tener menos tiempo dedicado a estimar y más tiempo dedicado a hablar sobre cómo nos vamos a organizar. ¿Qué vamos a hacer cuando Pablo se vaya la semana dos de vacaciones? ¿Y si a Rosa finalmente le operan de la pierna? ¿Qué hacemos con Pedro que es junior? Todo esto entra dentro del debate que debería tener un Scrum Team en vez de estar sacando cartas para “jugar” al planning poker. 

El gran problema del EvBM es que requiere romper el paradigma de dar siempre fechas y de que si eso no ocurre es que no estamos comprometidos. ¿Qué mejor manera de comprometernos que ser capaces de decir “no se lo que voy a tardar”? Porque señores, esa es la verdad. Por muchos intereses económicos que tengamos, decir que se puede hacer algo sin haber “picado” una línea de código es mentirnos a nosotros, a nuestro cliente y a nuestra profesión. 

Esto no quiere decir que nunca hablemos de fecha, solo que hablaremos de ellas cuando tengamos experiencia en este contexto con el equipo que tenemos. Se que es difícil porque muchas veces aceptamos o no tenemos negocio, esto requiere de una estrategia clara de venta y también de la imagen que queramos tener en el mercado. 

Finalmente, y si nos encontramos con un pintor que en vez de estimar nos diga que no sabe lo que va a tardar ¿Qué haremos?