¿Preferimos una mentira (ilusión) para apoyar el inicio del proyecto, o deseamos realmente tener entregas de software con valor en el inicio del mismo? Esta pregunta debe ser la guía principal cuando nos preguntan sobre plazos para un proyecto, sobre todo si asumimos con conciencia la incertidumbre, la imprevisibilidad y la intangilibidad que es el desarrollo de software. O sea, la respuesta a la pregunta depende de enfocar todo a la forma de trabajo y principalmente a los resultados generados por el proyecto.
La cuestión principal no es sólo tener un plazo para finalizar el proyecto, sino que normalmente en función de esa necesidad, la cultura corporativa en la que estamos inmersos nos exige los famosos "cronogramas detallados" con cada tema de requisito o actividad, conteniendo su respectiva estimación de esfuerzo, su debida fecha de comienzo y de fin de la ejecución. Para generar ese cronograma detallado es necesario un conocimiento también detallado, lo que ocurre muchas de las veces a través de una especie de congelamiento de alcance luego del inicio del proyecto.
Este tipo de situación estimula una serie de efectos indeseables a un proyecto de software, y para explicar mejor esto, siga la siguiente imagen (click para ampliar), que muestra un razonamiento muy simple (basado en la TOC - Teoría de las Limitaciones) sobre las causas y efectos (leer primero de arriba hacia abajo) relacionados al cobro de plazos detallados en un projecto de software (incluso podes ayudarnos a evolucionar este árbol de razonamiento).
La cuestión principal no es el uso o no uso de metodologías ágiles, sino una cuestión de racionalidad. Si sabemos que la visión de tiempo, esfuerzo y alcance cambiará durante el proyecto, ¿por qué motivo vamos a malgastar recursos tratando de generar una ilusión en el comienzo del proyecto? Es decir, sinceramente no veo que sea muy inteligente que una organización gaste mucho dinero para crear esta falsa idea de control y gestión acerca del desarrollo de software.
Creo firmemente que esta falsa idea de control impuesta en los proyectos sucede en función de la falta de confianza entre la empresa contratante (cliente) y la empresa contratada (proveedor). Esto no ocurre sólo en el mundo de los proyectos, sino que es una cuestión cultural y sistémica muy fuerte que vivimos en la mayoría de los modelos sociales conocidos.
Por supuesto que romper este paradigma de falta de confianza no es algo simple de hacer y sobre todo se necesita mucho tiempo para crear relaciones comerciales basadas en la confianza entre las partes.
Podemos notar entonces que las metodologías ágiles no ofrecen una solución definitiva sobre este tema, sino que promueven la construcción de forma paulatina de relaciones confiables y también estimula una reflexión de esa racionalización de recursos cuando se trata de la creación de un software para una organización.
Esta reflexión está fuertemente apoyada en los pilares de visibilidad, inspección y adaptación del proceso, para ofrecernos el inicio de este ejercicio cultural a través de prácticas e ideas como entregas constantes de alto valor agregado, alcance iteractivo e incremental, pequeños pasos (baby steps), simplicidad y mejora continua.
Así que en respuesta a este pseudo "control financiero" que proporciona la visión de tiempos a una organización, las prácticas e ideas expuestas arriba, están fuertemente basadas en la solución. Al dejar libres los conceptos de alcance y calidad, se pueden controlar las variables de tiempo y costo en el comienzo de un proyecto (Contrato de alcance negociable), y podemos ver que las respuestas a ¿Cuándo terminará? y ¿Cuánto costará? un proyecto no es el problema, pues en ese modelo, fijamos exactamente la duración y el costo y lo que dejamos deslizante es exactamente lo que va a caber como alcance de valor agregado en ese tiempo contratado.
De hecho, la metodologías ágiles sugieren una manera más honesta de tratar el plazo, donde tenemos el coraje de asumir que los cambios en el alcance son importantes para el cliente y, principalmente, tenemos la valentía y la humildad de reconocer/admitir que no somos capaces de aprender, estimar y planificar todo lo relacionado al alcance luego del comienzo de un proyecto. Entonces, aceptando esta incapacidad, ¿por qué razón hemos de gastar dinero para tratar de dominar el alcance en el comienzo de un proyecto (y, con eso, crear una ilusión) con el fin de generar estimaciones de plazos y costes?
Para terminar, volvamos al título de este simple artículo, que sin querer hacer apología de Maquiavelo, la gran realidad que yo traigo, es que la inmensa mayoría de las personas prefiere la mentira de los plazos detallados al inicio del proyecto. Ttal vez esto ocurra debido a la naturaleza humana de necesitar las ilusiones (incluso para justificar nuestra existencia), es decir, a pesar de hermoso y factible, infelizmente ese modelo de gestión estimulado por Ágil no está al alcance de todas las empresas. Por eso, la próxima vez que te pregunten sobre la duración de un proyecto, hacé esta pregunta mágica: ¿Qué es lo que preferís? ¿Una mentira o valor agregado al comienzo de un proyecto?
