No vayas al super con hambre

O cómo convivir con deadlines y el #noEstimaras

“The Dev Estimate”. Oil on Canvas. Munch, Edvard. 1987

Antes del boom de las metodologías ágiles, la industria ponía esfuerzo en perfeccionar las técnicas que (en teoría) generaban como resultado estimaciones más “precisas”. Desde principios del 2000 con el manifiesto ágil como puntapié inicial la situación pegó un giro de 180°. De poner foco a tener planes más precisos, pasamos a asumir que dado que es tan difícil anticipar cuanto va a llevar en tiempo y esfuerzo un desarrollo, lo mejor era bajar las expectativas y hacer estimaciones más chicas, más reales. Ésta idea se fue extendiendo a tal punto que llegamos a pensar que la estimación en sí, no tenía ningún valor. Con analogías clásicas como: que a un pastelero le podés pedir que te diga cuanto le lleva hacer una torta, pero no cuanto le lleva hacer una receta; o que armar el cubo rubik puede llevarte 30 segundos si sabes el algoritmo o 4 días si lo tenés que aprender. O con lo que pasó con el hashtag #noEstimates que generó bastante revuelo en la industria.

Ahora bien, hasta acá historia/teoría. En la realidad, por más ágiles que seamos, el negocio va a necesitar estimaciones. Sean desarrollos sencillos y repetitivos o complejos y únicos. En definitiva nos guste o no nos guste, somos una industria y no vendemos arte (y la gran mayoría no trabajamos haciendo rocket science tampoco). Los desarrollos tienen valor según su time to market y no podemos ser ajenos a esta problemática. Entonces, ¿Cómo hacemos para dar visibilidad de tiempos cuando el equipo no está en condiciones de predecir cuanto le va a insumir resolver un determinado problema?

Algo que me gusta fomentar es que las estimaciones “pasen” sin tanto revuelo. No hacer de la estimación un evento en particular, que sea una pregunta y ya. Que el desarrollador no sienta que está asumiendo un compromiso por lo que te va a responder, que si le pifia le pifia. De esta forma surgen las estimaciones más precisas. Con esta práctica arranca un circulo de confianza donde el dev no siente la estimación como un compromiso, ni el interesado como algo grabado en piedra. Si la relación entre IT-cliente se da en un contexto de confianza, en mi experiencia el 80% de las veces se habla de prioridades y no de deadlines. Con que ambas partes estén de acuerdo con las prioridades, solo se terminan pidiendo estimaciones en casos particulares.

Hay una situación muy particular que se da cuando las papas queman. Negocio, producto, el stakeholder o el mismo líder del equipo/proyecto preguntan por tiempos, el dev se da cuenta de la presión y ante esto pueden pasar 2 cosas:

  1. El dev tira una fecha menor de la que hubiera tirado, rebajando la calidad (consciente o inconscientemente) de lo que produce.
  2. El dev se cubre y tira una fecha mucho mayor a la que hubiera tirado para evitar trabajar con una presión que nadie desea tener arriba. En este caso en general la tarea termina ocupando todo el tiempo estimado, inclusive ese delta que se le sumó a lo que hubiera estimado de forma original (ver ley de Parkinson)

Los 2 escenarios son negativos, pasar la presión al desarrollador nunca da buenos frutos. Desde ya que algunos manejan el tema mejor que otros y por su puesto que los dev se pueden bancar esa presión, pero la pregunta que deberíamos hacernos es ¿Para qué?. NADIE trabaja mejor bajo presión, es un mito completamente sin fundamentos y más aun cuando las tareas a desarrollar implican creatividad y pensamiento.

Para la conclusión vuelvo al titulo, así como dicen que si tenes hambre no vayas al super, si tenes urgencia por saber cuando un desarrollo va a llegar a producción no lo preguntes. Hace primero que el dev se sienta lo más cómodo posible en relación a la tarea que tiene que realizar, dejalo tranquilo un tiempo para que gane una mirada global de la situación y cuando esté super concentrado en la tarea que tiene que realizar, ahí preguntale como quien no quiere la cosa:

¿Che, cuánto pensas que les va a llevar esto, 1 día, 1 semana, 1 mes o 3 meses?

Probablemente la respuesta sea “Nah, esto no creo que me lleve más de x tiempo” y esa va a ser la estimación más precisa que vas a poder obtener.