Hoy he ido a prepararme un vaso de leche con chocolate y mis pasos han sido lo siguientes ya que me parecieron los mas obvios:
1º He ido a la estantería de los vasos, he cogido un vaso y lo he dejado sobre la mesa que esta debajo de la estantería.
2º He ido a la estantería del chocolate, he cogido el chocolate y lo he dejado sobre la mesa que esta debajo de la estantería del chocolate (a unos dos metros de la estantería de los vasos).
3º He cogido una cuchara, he ido donde estaba el chocolate, he cogido una cucharada de chocolate y he ido a verterlo en la leche.
Cuando me lo estaba bebiendo se me ha pasado por la cabeza: QUE MAL LO HE HECHO!!! He recorrido dos metros con una cuchara llena de chocolate (se podría haber vertido) cuando si hubiese dejado el chocolate al lado del vaso verter el chocolate en el vaso habría sido inmediato (gano tiempo y esfuerzo).
Es una tontería pero si analizamos cuantas veces lo haber hecho en un año te das cuenta la de tiempo y fiabilidad que he perdido.
Este ejemplo tan sencillo ilustra perfectamente lo que pasa en muchos desarrollos de software. Para establecer una dinámica en el proyecto, se empieza con procesos obvios ya que son fáciles de entender y solucionan rápido un problema. Lo malo es que, con el tiempo, la costumbre se traduce en "para que cambiarlo si ya tenemos un procedimiento" y no vemos la posible gran perdida de tiempo y esfuerzo.
Merece la pena, cuando nos da la impresión de que estamos malgastando tiempo y esfuerzo, en analizar la complejidad de los procesos para ver si pequeños cambios suponen un ahorro.
No hay comentarios:
Publicar un comentario