Medir el Tiempo de Desarrollo

Medir el tiempo que tardamos en desarrollar una tarea parece una obviedad. Queremos prever y planificar. Pero el problema no es medir el tiempo, es creer que medir el tiempo siempre sirve para lo mismo.

Usar métricas para medir el tiempo que tardamos para crear algo, como el LeadTime* o el CycleTime**, no existen para prometer fechas ni presionar a los equipos. Existen para entender cómo funciona un sistema de trabajo y aprender de él. Y eso sólo es posible cuando el propio sistema puede reaccionar a lo que la métrica muestra.

*LeadTime: el tiempo que se tarda desde que surge una idea hasta que se da por realizada. **CycleTime: el tiempo que se tarda desde que se empieza a trabajar en la idea hasta que se da por realizada.

Hay contextos en los que medir tiempo aporta claridad, y otros en los que sólo genera ruido. Este post no va de defender o atacar a una métrica concreta, sino de algo un poco más incómodo: la coherencia entre cómo trabajamos, qué medimos y qué decisiones podemos tomar con ello.

Situaciones en las que no sirve medir el tiempo de desarrollo

Medir el tiempo que nos acarrea desarrollar una funcionalidad es importante para tener futuras previsiones en acciones similares. Pero no siempre sirve. Sólo lo podremos usar cuando tengamos libertad de lanzar un producto sin una fecha impuesta. Estas son algunas situaciones en las que me he encontrado y en las que vas a pensar que estas midiendo en vano:

Proyectos con fechas fijas. Proyectos en los que, por ejemplo, un tema legal que entra en vigor en una fecha concreta, o campañas cerradas por temporada. En este caso vas a poder gestionar el alcance o el coste (invertir por ejemplo en más personas), no el tiempo.
Sistemas de escalado con cadencia fija. Por ejemplo cuando tu desarrollo forma parte de un proyecto mucho más grande y tienen establecidas entregas trimestrales.
Organizaciones donde este tipo de métricas se usa para exigir mejorarla, no para aprender del sistema.

Podrías estar pensando que entonces sólo medimos el tiempo de desarrollo cuando nos conviene. No es así. Estas métricas se usan cuando el sistema puede responder a lo que mide.

Te podría decir que esto lo he deducido fácilmente, pero no es así 🙂 Me ha supuesto varias conversaciones con propietarios de producto. Para mí tenía sentido medirlo siempre. Básicamente para tener referencias que evitaran tener que poner al equipo en un compromiso cada vez que desde la línea de Management preguntan si es viable X para el día D. Que no se sintieran obligados a acceder si en otras ocasiones habían vivido situaciones complicadas (muchas horas extra) para entregar. Pero también me he dado cuenta que hay equipos a los que les gusta ser partícipes desde el planteamiento y entrar en la decisión. Así que, una vez más, todo depende del contexto en el que te encuentres.

En qué ocasiones si aporta valor medirlo

Cuando trabajas en una situación que te permite medirlo, no existe un tiempo de desarrollo bueno o malo en términos absolutos. Todo depende de las expectativas iniciales que tengamos sobre nuestro producto, nuestros usuarios o sobre nuestros competidores. Estos son algunos casos en los que aporta valor medir el tiempo de desarrollo:

Trabajo con flujo contínuo
Capacidad de decidir cuándo lanzar
Prioridades que pueden cambiar
Necesidad de aprender del sistema, no de justificar retrasos.

¿Te puedes clasificar en alguno de estos casos? Entonces tienes una oportunidad fantástica para aprender de tu sistema, y estas son tres ideas clave que no te puedes perder:

MEDIR TIEMPO TIENE SENTIDO PORQUE EL SISTEMA PUEDE REACCIONAR A LO QUE MIDE
MEDIR EL TIEMO DE DESARROLLO NO ES UN OBJETIVO NI UNA PROMESA, ES UN ESPEJO DEL SISTEMA
MEDIR TIEMPO TE DARÁ AUTONOMÍA, DIRECCIÓN Y CRITERIOS DE PRIORIZACIÓN

Situaciones en las que se puede medir y no se hace

Respuesta corta

COMODIDAD

Respuesta elaborada

En equipos de desarrollo se suele trabajar con entidades más grandes que una sola tarea (o Historia de Usuario). Estas entidades más grandes que solemos llamar Épicas contienen las tareas necesarias para cubrir una hipótesis que queremos entregar al usuario y medir si funciona tal y como habíamos previsto. Bien, esta es la idealidad. A la práctica, estas entidades «Épicas» no siempre se usan correctamente, y eso provoca que luego medir lo que se tarda en desarrollar un producto también carezca de sentido.

En este caso, durante mi carrera profesional me he encontrado con equipos, y más concretamente con propietarios de producto, que usaban estas entidades como un saco de cosas por hacer. En ningún momento se lo planteaban como un alcance cerrado. ¿Por qué? Sus explicaciones son variadas, pero la más común era tener todas las tareas relacionadas con el mismo tema dentro de una misma Épica con el fin de tener visibilidad de qué estaba hecho hasta el momento y qué no. ¿Qué provoca esto?

Que nunca se cierre esta Épica como hipótesis a probar, porque siempre voy añadiendo pequeñas mejoras que van surgiendo.
Que usemos una herramienta de gestión de trabajo para documentar o dar visibilidad.

Medir tiempo no nos hace más rápidos por sí mismo ni elimina la responsabilidad de cumplir compromisos temporales. Nos hace más conscientes. Y esa conciencia sólo sirve si estamos dispuestos a cambiar algo cuando los datos nos incomodan.

Un número aislado no dice nada. Una tendencia sí. Un aumento del tiempo no es un fallo, es una señal de que el sistema ha cambiado: más trabajo en paralelo, más dependencias, más deuda, más ambigüedad… Ignorar eso es perpetuar quejas que no llegan a ninguna parte.

¿Cómo y por qué estás midiendo tu el tiempo de desarrollo si lo haces? ¿O por qué no? Deja tus comentarios, me encantaría conocer otras situaciones y otros puntos de vista.

5 (1 votos)