En el post anterior mencioné una alternativa diferente para entregar los proyectos en tiempo y coste.
Ahora voy a tratar de explicar en qué consiste de la forma más sencilla posible.
I. Las tres variables del proyecto
En todos los proyectos hay 3 elementos fundamentales:
- La fecha de entrega
- El conjunto de funcionalidades
- Los recursos necesarios para ejecutar el proyecto
II. El enfoque tradicional
Hasta ahora, en casi todos los proyectos se ha seguido el procedimiento tradicional, que pasa por fijar la funcionalidad y dejar que el equipo técnico (interno o externo) se pelee con las otras dos variables: fecha y recursos.
III. El resultado
El resultado final de esta forma de actuar suele ser el que sigue:
A. Los proyectos se retrasan (la opción más común)
B. Los recursos superan los inicialmente previstos
Es evidente que ninguna de las dos opciones resulta satisfactoria. Lo más usual es que los proyectos se retrasen, y que casi todas las previsiones iniciales acaben en la papelera, incluido, por supuesto, el documento de especificaciones.
Lo peor de todo es que habremos malgastado tiempo y esfuerzo tratando de ajustarnos a un plan que no tenía futuro.
IV. El problema está en la pregunta
Como tantas otras veces ocurre, el problema no está en la respuesta. El problema es la pregunta.
La pregunta no es: ¿Cómo se hace todo esto en plazo y tiempo?
La pregunta adecuada es la siguiente: ¿Cómo hacemos un proyecto que sirva a mis objetivos de negocio y que pueda entregar en fecha ajustándome a los recursos planificados?
V. El nuevo método
El método que propongo -y que nosotros ya estamos utilizando- pasa por aceptar que el proyecto es un objetivo en movimiento constante. No tiene sentido malgastar esfuerzos intentando fijar la funcionalidad porque la funcionalidad va a cambiar conforme el proyecto avanza.
Por eso, la clave está en:
- Determinar nuestro objetivo: qué proyecto necesitamos para mejorar nuestro negocio
- Fijar el plazo: cuándo lo necesitamos. Esta variable sigue siendo crítica, porque no sirve de nada llegar tarde al mercado.
- Analizar los recursos disponibles.
- Determinar qué es lo que podemos hacer con esos recursos para esa fecha. Tendremos que asumir que bastantes de nuestros presupuestos irán cambiando a medida que descubramos cosas nuevas sobre el proyecto y conozcamos mejor el mercado. Lo importante es gestionar esos cambios necesarios con agilidad.
- Asignar y reasignar prioridades para “atacar” primero aquellas funcionalidades que realmente son esenciales para el negocio.
De esta forma, al llegar al plazo de entrega habremos construido el mejor proyecto posible, con los recursos de los que disponemos, y con las funcionalidades esenciales para nuestro negocio.
.
La realidad cambia (y es algo que no debería pillarte por sorpresa)
Antes de construir un puente, el ingeniero tiene que realizar un análisis muy detallado. Después de tomar medidas, va a su oficina y proyecta. Cuando vuelve al lugar en el que se va a construir el puente, todo sigue igual. Nada ha cambiado. Ni el entorno ni las medidas. Es algo que la mentalidad de un ingeniero tradicional tiene perfectamente asumido.
Pero en el mundo del desarrollo web esto nunca ocurre.
Todo cambia respecto a lo inicialmente previsto, y lo hace por varias razones:
1. El cliente no sabe lo que quiere
En muchas ocasiones, ni siquiera el cliente sabe muy bien lo que quiere. Tiene una idea de cuál es su problema, es verdad, pero a menudo desconoce sus necesidades reales. Y en muchos casos, cuando estamos diseñando un sistema nuevo, solo tenemos una idea aproximada en nuestra imaginación.
Por eso el “diagnóstico” no resulta sencillo, y los primeros pasos del proyecto no siempre avanzan en la dirección adecuada. Más tarde o más temprano, esto nos obliga a rectificar.
¿Como podemos hacer un plan para construir un sistema que no sabemos como es?
Un proverbio árabe dice que “cuando no sabes donde vas cualquier camino te llevará al lugar equivocado”.
2. La comunicación es imperfecta
El proceso de comunicación siempre es imperfecto. El cliente no puede proporcionar una imagen completa sobre sus procesos y las necesidades de su empresa. Es inevitable que deje de contar cosas: porque no las conoce, porque las olvida, o incluso porque no cree oportuno contarlas.
Y, también de forma inevitable, el informático no es capaz de interiorizar todo lo que oye: hay cosas que no entiende bien, y otras a las que no es capaz de asignar la relevancia que merecen.
La información correcta y precisa no aparece hasta más adelante, como fruto de las diferentes iteraciones. Y cuando aparece, se traduce en cambios.
3. Al principio sabemos muy poco sobre el proyecto
Al inicio del proyecto, nuestro nivel de conocimiento de la realidad es muy limitado.
Conforme el trabajo avanza, vamos descubriendo cosas nuevas que antes no sabíamos, obtenemos información muy valiosa -está basada en situaciones reales, no en previsiones- y podemos tomar por tanto decisiones mejor informadas.
Estas decisiones se traducen en cambios frente a lo inicialmente previsto.
4. La realidad cambia
Además de que la realidad que tenemos en frente es distinta de la que sería posible construir en un mundo con información completa, y comunicación perfecta. La realidad cambia de verdad, con cosas como:
Conclusión
Podemos extraer un conclusión muy clara: la realidad cambia, y no queda más remedio que aprender a cambiar con la realidad.
A estas alturas no debería ser ninguna sorpresa. Pero parece que muchas empresas de desarrollo todavía no lo han asumido. Por eso siguen aferradas a los métodos de ingeniería tradicionales.