Reducir tiempos de desarrollo es una mala idea

Reducir tiempos de desarrollo

Existe un principio llamado Ley de Parkinson, muy aplicado en el trabajo del conocimiento en general y en el mundo del software en particular, que dice que el trabajo tiende a expandirse hasta llenar el tiempo disponible para terminarlo. Como ya comenté en este post titulado Vicios peligrosos en la gestión de proyectos, esta ley no es universal y no es aplicable en equipos altamente cualificados y comprometidos con su trabajo. A pesar de ello es inevitable pensar en el hecho de que sí es posible alargar deliberadamente una tarea más de la cuenta. Lo mostraré en el siguiente gráfico:

Reducir tiempos de desarrolloEl eje vertical indica el valor (v) aportado por la tarea o proyecto. En este eje se sitúa R, que es el requerimiento o definición del proyecto o tarea, es básicamente lo que nos piden que hagamos. En el eje horizontal tenemos el componente tiempo (t), en el que situamos T, que es el tiempo requerido para hacer la tarea R con la calidad adecuada.

Cuando comenzamos la tarea R rápidamente aportamos valor, ya que normalmente solemos implementar la funcionalidad principal al principio y lo más complicado es cerrar la tarea o proyecto, completando el último requerimiento menos prioritario, acabando la refactorización y dejándola libre de defectos. Una vez hemos logrado lo anterior, habremos alcanzado el punto (R, T). Hasta este punto el valor aportado es mayor que la inversión en tiempo. Al sobrepasarlo sucede lo contrario, es decir, la curva queda por debajo de la recta que pasa por el origen y (R, T). Esto significará que el valor no compensará el tiempo invertido, es decir, que estaremos simplemente buscando la perfección en detalles que no añaden un gran valor a la tarea. Sobrepasar el punto (R, T) es pues, algo que debemos evitar.

Es posible encontrar personas, sobre todo en el management tradicional, que piensan que es posible acortar T (reducir tiempos de desarrollo) sin impactar en el resultado de R. Esto es, reducir ese tiempo T deliberadamente para forzar al ingeniero a afrontar el reto de terminar el mismo trabajo en un tiempo menor del adecuado. Lo que sucede en este caso es que al ser T'<T, se genera una pérdida de valor que acaba traduciéndose en:

  • No cumplir el 100% de los requerimientos de la tarea o proyecto
  • Generar defectos
  • Generar deuda técnica

Algo que suele pasar también es que se asuma que T es igual a la estimación de la tarea R. La realidad es que nunca, ni siquiera cuando hemos terminado la tarea, sabemos el valor de T. El motivo es que entran en juego no solo criterios objetivos como por ejemplo si cumple o no los requerimientos y si tiene o no defectos, sino también criterios subjetivos como la excelencia técnica, el diseño y la usabilidad. Si al finalizar la tarea no es posible determinar T, es todavía menos posible determinarlo antes de empezar la tarea o proyecto, que es cuando se estima y cuando menos información tenemos.

Conclusión

Es una mala idea tanto reducir tiempos de desarrollo, como buscar el perfeccionismo extremo, como intentar determinar el tiempo de una tarea con precisión, sobre todo antes de realizarla. Teniendo en cuenta que el trabajo del conocimiento en general y el desarrollo de software en particular básicamente consiste en pensar más que producir, y que ni de lejos menos tiempo disponible implica pensar más rápido, lo mejor que podemos hacer es definir claramente los objetivos y restricciones de las tareas y proyectos, y dejar hacer su trabajo a los expertos sin presiones excesivas e innecesarias. Por supuesto tratándose de un trabajo tan intelectual, todo lo explicado anteriormente se va al carajo si el experto tiene el espacio mental necesario para encontrar la inspiración y parir una nueva idea que replantee una nueva y mejor solución simplificada.

También te puede interesar...

Resumen del libro Coaching Agile Teams de Lyssa Ad... El libro Coaching Agile Teams de Lyssa Adkins es una referencia obligada dentro del mundillo Agile. Prácticamente todo el mundo que conozco y se lo ha...
Resumen Agile Retrospectives de Esther Derby y Dia... El libro Agile Retrospectives de Esther Derby y Diana Larsen es un manual para Scrum Masters sobre cómo facilitar las retrospectivas en los equipos. ...
Cómo preparar una Sprint Review (Review Series II)... En el primer artículo de la serie vimos algunos antipatrones de Sprint Review comunes que restaban efectividad a esta sesión tan importante de Scrum. ...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

2 ideas sobre “Reducir tiempos de desarrollo es una mala idea

  • Alvaro Torres Tatis

    Excelente. Ese tiempo que se pierde tratando de reducir los tiempos es mejor invertirlo en definir y comunicar claramente los objetivos. Aporta más valor a la tarea.