no te encariñes con un monstruo

Requerimientos relativamente simples pueden convertirse en monstros horribles.

Tal vez el título completo debería ser: no te encariñes con un monstruo sólo porque lo conoces desde que era chiquito.

Cuando se realiza un tarea y al verla terminada no cumple con lo esperado hay generalmente dos caminos:

1. Rehacerla completamente.
2. Hacer observaciones y corregirla.

Hacer observaciones y corregir es generalmente el camino más intuitivo por varios factores:

• Generalmente es optimizar o hacer un fine tunning de lo existente.
• Ya se ha invertido tiempo en la entrega existente.
• Si existe una fecha de entrega cercana se percibe que es más simple “resanar” lo existente que “construirlo de nuevo”.

El punto fino es cuando se realiza una segunda revisión y aún la entrega no es aceptable.

Para entonces se la ha invertido más tiempo y seguramente el tiempo de entrega es más urgente ó, cuando menos, más cercano.

Esto puede repetirse en una tercera revisión. O cuarta. O quinta, etc.

Tristemente, en lugar de que sea claro que hay que replantear el requerimiento/desarrollo/diseño/o hasta proyecto completo, en la práctica continuamos trabajando sobre esta versión por el tiempo invertido y la presión de los tiempos.

Luego entonces: no te encariñes con un monstruo sólo porque lo conoces desde que era chiquito.

Cuando algo que parecía simple toma estos niveles de complejidad seguramente es un problema de definición de estructura o especificación de requerimientos. Consideremos hacer un alto en el camino, volver al papel y decir:

-Creímos que esta tarea tomaría x días.

-Ha tomado varías revisiones y extensiones de tiempo y aún no es entregable.

-Es claro que corregir y corregir no está garantizando la entrega.

-Tomemos algunas horas para replantearlo y lograr que se haga en y días de la manera correcta.

Algunos punto para apoyar la reconstrucción total.

• Aunque se pierde el producto en si, se conserva la experiencia de lo realizado y las revisiones.
• Replanteando se puede asegurar que desde la base cumplirá con los requerimientos finales deseados.
• Se asegura que la versión final no estará “parchada” y “re-parchada” con la presión del tiempo.
• El mantenimiento y reuso de la misma seguramente será más eficiente.

Obviamente no es una regla escrita en piedra “No corrijas. Reconstruye”; pero es importante tenerlo como alternativa a correcciones iterativas sin fin (léase: monstruos).