¿Cuándo fue la última vez que su proyecto finalizó dentro del plazo y del coste? ¿Hizo el equipo muchas horas extras? ¿Responde todo al objetivo del proyecto? En este artículo hablaremos sobre la ilusión de seguridad que tenemos en proyectos con un objetivo cerrado y cómo salir de esa trampa.
La gestión de proyectos de software, así como el modelo cascada de ingeniería de software, se encuentran muy influidos por las ingenierías tradicionales. En ellas hay una amplísima etapa de análisis en la se construye, analiza y detalla “todo” el objetivo del proyecto. En base a esto, se crea el cronograma del proyecto, se estiman los recursos, se presupuesta el coste, se transmite al cliente y, tras algunas idas y venidas, se aprueba finalmente.
La gran ventaja de este tipo de contratación es que proporciona comodidad al contratista y al contratado. El alcance es conocido, el plazo y el coste también. “Sabemos” quién y qué actividades se realizarán el martes de la segunda semana de dentro de 10 meses.
Triángulo de gestión de proyectos de las limitaciones de la gestión de proyectos
¿Y cuál es el problema?
Comenzamos con el problema de la metáfora de la construcción en ingeniería civil para la construcción de software.
En ingeniería, si desea construir una carretera que va desde el punto A hasta el punto B, usted puede hacer todo un estudio previo para saber cuál es la distancia entre los dos puntos, análisis del terreno, tipo de materiales, entre otros. Al final, podrá hacer una estimación de coste y plazo basándose en esas variables. Además, la forma en que se construyen carreteras es relativamente estable, es decir, el contexto de la construcción no cambia a menudo, y el proceso de construcción puede también replicarse con mayor facilidad.
En proyectos de desarrollo de software, el punto de llegada es desconocido. Usted puede partir del punto A, descubrir que no tiene sentido llegar al punto B, ir al punto C, desviarse hacia el D. Puede que tenga que subir montañas, atravesar mares o descubrir que en los primeros 100 metros no tiene sentido construir el resto del camino. La “carretera” del software está mal definida y su producto probablemente nunca llegue a terminarse. Siempre puede mejorar, evolucionar y adaptarse a las necesidades cambiantes del negocio.
Pregúntese: Si tuviera que comenzar un proyecto de software hoy, ¿sabría exactamente qué tecnologías emplear?, ¿a qué personas involucrar en el proyecto?, ¿qué funcionalidades proporcionarán a la empresa?, ¿cuál será la reacción de los usuarios al emplear el producto? Si no sabe exactamente lo que hará dentro de un año, ¿cómo esperar esto de un proyecto?
Asumiendo riesgos muy elevados
Habida cuenta de que el inicio y el final de la construcción del software son inciertas, ¿es consciente del riesgo que está asumiendo al cerrar el objetivo de un proyecto en las fases iniciales?
Cuando Boehm escribió sobre el Cono de la Incertidumbre Aplicada a Proyectos de Software en 1981, consideraba que el error de la estimación al inicio acerca del alcance de un proyecto puede ser de hasta 8x. Este error se va reduciendo conforme vamos conociendo más el problema y la solución que estamos proponiendo.
Cono de la Incertidumbre (Boehm, 1981)
En términos prácticos, digamos que usted es el responsable de un proyecto de software. Su cliente hace un briefing sobre lo que él desea y usted, muy competente, hace un espléndido trabajo de análisis, planificación y medición de la dimensión del proyecto. Basándose en esa medición, estima el coste total del proyecto en R $ 1 millón y el plazo en 1 año. En su visión es todo tan concreto que usted se compromete a una fecha exacta. El día 25/06 del año siguiente, el cliente tendrá su proyecto entre las manos.
Desafortunadamente, independientemente del trabajo arduo de planificación, medición y previsión que usted efectuó, el Cono de la Incertidumbre influirá en su proyecto y le dirá que cerró su objetivo demasiado pronto y que su proyecto puede costar hasta R $ 4 millones y durar 4 años.
El cliente no sabe lo que quiere
“Pero la culpa no es mía, el problema es que el cliente no sabe lo que quiere y cambia el objetivo del proyecto cada hora”.
Libérese de principios que no son válidos. ¡El cliente no sabe lo que quiere y eso es un HECHO! Trabajamos en la economía del conocimiento y cada vez que usted crea algo y lo pone en las manos de sus clientes / usuarios hay una reacción a su producto. Se produce un impacto en el negocio y sus estrategias, surgen nuevas ideas, se altera el comportamiento de las personas con relación al problema que el software soluciona y el objetivo cambia.
Además, ¿quién dijo que el cliente es el más indicado para describirle a usted el software? Él es la persona que tiene un problema y espera que usted se lo solucione.
Cuando usted va al médico, ¿se receta usted el tratamiento o le cuenta el problema y espera a que él le proporcione un tratamiento?
Y los contratos de “fábricas” de software
Pero ahí tenemos un problema. Hoy contrato a las “fábricas” de software con el objetivo cerrado. Hay varias formas de contratar proyectos de software sin necesidad de cerrar el objetivo. Vea en este vídeo de Marcos Garrido uno de los modelos para escapar del objetivo cerrado.
Puntos importantes para escapar de este problema
Sea ágil, pero no un ágil cualquiera, alguien que emplea paradigmas tradicionales disfrazados de ágil. Sea #TrueAgile:
● utilice ciclos cortos de retroalimentación (planificación, construcción y entrega);
● priorice y construya en primer lugar lo más importante;
● valide lo que haga todo el tiempo, mida los resultados de lo que se entrega;
● medir su producto y saber lo que da fruto y lo que no resulta fundamental para definir en qué funcionalidades vamos a invertir.
Lo más importante, no lo olvide nunca: “Responder a cambios más que seguir un plan” (Manifiesto Ágil, 2001)
