Decide tan tarde como puedas...o te atrevas...

Enmarcado dentro del pensamiento Lean, este principio nos incita a tomar determinadas decisiones críticas tan tarde como, responsablemente, nos sea posible. Simple de explicar (como acostumbra a ser el pensamiento Lean) pero tremendamente difícil de llevar a la práctica (sí, también típicamente Lean).

Cortesía de Mikel Ortega bajo licencia Creative Commons

Puede ser una decisión de diseño -cuya implicación en el resto del sistema es elevada-, una decisión de compra de componentes a un tercero -con importantes costes-, tal vez que la elevada interacción con el resto del sistema hace difícil su marcha atrás... o una decisión que debe satisfacer las necesidades de un determinado interesado clave... sea como fuere, existe un gran número de cuestiones sobre las que es recomendable retrasar su definición, implantación o adquisición... tanto como puedas (dentro de lo razonable).

El ejemplo de libro en estos casos es el famoso Prius de Toyota: Inicialmente no se habían planteado la decisión de crear un motor híbrido; la definición inicial era un coche de muy bajo consumo y finalmente acabó con un motor revolucionario que satisfacía dicha definición. Si durante el diseño de un coche se puede aplicar este principio (recordemos que todo lo Lean viene de dicha industria y en particular de la marca de los óvalos) en IT deberíamos ser capaces de llevarlo a cabo incluso con las tensiones de calendario habituales en nuestros proyectos.

La clave radica en apoyarse en una información con las suficientes garantías como para no "pasarse de frenada". En el Método Kanban (propuesto por David J. Anderson) nos basaremos en la predicción probabilística de nuestro proceso de desarrollo para calcular, con la suficiente antelación, cuándo es el momento responsable más tardío posible para iniciar determinada tarea. Otras metodologías ágiles como Scrum se apoyan en la estimación relativa (generalmente en puntos de historia) sumado al conocimiento previo de la velocidad del equipo de desarrollo junto con el plan de release, generando un mix de información que te permita retrasar dicha decisión sin comprometer la finalización del resto del proyecto.

Me temo que no existe fórmula en ninguna metodología que nos libere de determinado grado de incertidumbre pero lo que tienen en común todas ellas es que debes basarte en el rendimiento de tu proceso/equipo para tomar dichas decisiones lo más tarde posible. De modo que si desconoces dicho rendimiento, ya sea por un medio o por otro, es altamente recomendable que inviertas en averiguarlo.

La ventaja de asumir dicho riesgo (controlado) y no avanzar por tierras desconocidas, antes de la estrictamente necesario, es evitar que tu proyecto encalle por una mala decisión obligándote a seguir evolucionándolo con una pesada carga o deshacer trabajo terminado debido a una decisión precipitada. La solución (si se puede llamar así) pasa por conocer al máximo el rendimiento de tu proceso basado principalmente en un conocimiento empírico (tan nombrado en entornos ágiles) lo que te permitirá tomar estas decisiones con menor riesgo/incertidumbre.