Ser ágil de verdad reduce los costes de tu proyecto

Hace algunas semanas escribí acerca de nuestro método ágil de trabajo en el que descubría cuál es la “pócima mágica ” que añadimos a todos nuestros proyectos. En esta ocasión subiremos a diez mil pies de altura para dar una visión mucho más ejecutiva: veremos cómo la aplicación de un método ágil (verdadero) puede reducir los costes de tu proyecto.

No voy a profundizar más en qué es o no es “agile”. Si estás leyendo este artículo es muy probable que esos conceptos los tengas muy asumidos. Por el contrario, voy a demostrar cómo una estrategia de desarrollo ágil repercute de manera muy significativa en la eficiencia del proyecto y, ya sabemos todos, que una mayor eficiencia repercute en una reducción de costes. Para ello, enumeraré una serie de actividades desde el punto de vista ágil y las compararé con su “homólogo” en un modelo clásico o en cascada, siempre desde un punto de vista de eficiencia y reducción de costes.

Ser agile o la paradoja del CEO cabreado

Comenzamos haciendo visible una situación que, por evidente, en muchas ocasiones se deja pasar por alto o incluso se considera “normal” dentro de un contexto de desarrollo de proyecto software. Esta situación relaciona la efectividad – y por tanto los costes de un proyecto – con el  nivel de satisfacción de los usuarios de la aplicación que estamos desarrollando. A esta situación la he llamado “paradoja del CEO cabreado” y queda claramente representada en la siguiente tabla.

En la tabla anterior muestro el estado anímico de un supuesto CEO. Este directivo ha contratado el desarrollo de un proyecto software y su estado anímico se extrapola según la relación que hay entre el coste de su proyecto y el nivel de satisfacción de los usuarios del aplicativo que se está desarrollando.

• Cuadrante 1-1:
  • Los usuarios están tristes, enfadados o una mezcla de ambas. El nuevo aplicativo no satisface sus necesidades, no se ha contado con ellos, a los problemas habituales de su trabajo, ahora tienen que añadir utilizar un software que no sirve.
  • El proyecto ha soportado un sobrecoste excepcional debido a los constantes retrasos, cambios de alcance y generación de toneladas de papel.
  • Nuestro CEO está francamente cabreado, no solo el proyecto le ha costado mucho más dinero del que tenía previsto, además va a tener que gestionar el “calentón” que el nuevo sistema ha generado en sus usuarios.

• Cuadrante 1-2:
  • Los usuarios están contentos, el nuevo aplicativo les va a suponer mejoras en su día a día, les va a hacer más felices.
  • El proyecto ha finalizado con un excesivo sobrecoste respecto a la previsión original.
  • El CEO, tiene sentimientos encontrados, por un lado los usuarios le felicitan, les gusta el nuevo aplicativo, pero por otro lado, se ha gastado bastante más dinero del que tenía previsto y probablemente cuando tenga que llevar a cabo un nuevo proyecto se lo pensará dos veces.

• Cuadrante 2-1:
  • En este caso, el aplicativo desarrollado no cumple con las expectativas de los usuarios.
  • Sin embargo, el coste ha sido reducido.
  • La sensación de nuestro CEO será agridulce, ya que el proyecto ha costado poco, pero probablemente no sirva para nada, los usuarios probablemente no lo utilicen y lo que en principio parecía un ahorro de costes, ha significado tirar el dinero a la basura, como se suele decir, “lo barato sale caro”.

• Cuadrante 2-2:
  • Los usuarios están felices, tienen lo que querían y esperaban tener.
  • Los costes están controlados y dentro de las previsiones.
  • La satisfacción de los usuarios está alineada con los costes esperados del proyecto.

Concluyendo, aunque la historia de nuestro particular CEO parece bastante evidente y a priori podríamos pensar que ya nada de esto puede ocurrir, la realidad es que una gran mayoría de los proyectos de desarrollo de software que se están llevando a cabo en la actualidad se alejan bastante del cuadrante “objetivo” que ilustrábamos en la imagen anterior. Entonces, ¿por qué no aplicar metodologías ágiles de verdad en cualquier proyecto software? Los motivos que se suelen escuchar son muy variados:

• Es más fácil y se asumen “menos riesgos” trabajando como lo he hecho siempre.
• La cultura de la empresa “no admite” cambios de mentalidad a ese nivel.
• Tienes que “enseñar” a la organización una nueva forma de afrontar proyectos.
• etc…

O peor aún, decimos que seguimos una metodología ágil cuando realmente no se hace. No obstante, el porqué de estos motivos y cómo podemos mitigarlos serán temas que iremos desgranando en sucesivas entradas del blog.

Sistemas ágil: iteraciones cortas “vs” etapa de análisis larga previa al desarrollo

En un modelo clásico de método de trabajo existiría una toma de requisitos y análisis más o menos larga que, tras una validación por parte del usuario, pasaría a implementación. Cuando la etapa de implementación esté finalizada, entraríamos en el ciclo de validación con usuarios. En el mejor de los casos, esta validación se haría en ciclos (validación – cambios – ejecución – validación). El incremento de costes radica precisamente en esta última parte, como el usuario ha pasado de su aplicación “modelada en papel” a su aplicación terminada. No es hasta este último punto donde realmente aparece un nuevo personaje en escena, al que podríamos llamar “Isi”: “y si al confirmar el pedido me muestra una pantalla de validación previa”, “y si un pedido entra por email…”, “y si…”. Todos estos “Isis” provocan dos situaciones coincidentes y contrapuestas:

• Yo – project manager – pelearé y buscaré las justificaciones que sean necesarias para cambiar lo menos posible de lo que ya he programado.
• Yo – cliente – intentaré que lo que me están enseñando, se parezca cada vez más a lo que realmente necesito.

El resultado de todo esto es la ejecución de un número de horas gastadas en reuniones de revisión, reuniones para discutir los acuerdos, reuniones para presupuestar cambios de alcance, programación, pruebas, etc… Por supuesto, estas horas las tiene que pagar alguien: que sea el cliente o la empresa de desarrollo dependerá de muchas circunstancias, pero lo que está claro es que nunca serán gratis.

Por el contrario, trabajando en interacciones cortas, el aplicativo se va desarrollando según el cliente lo está viendo. La funcionalidad estará mucho más acertada y, sobre todo, el orden de desarrollo vendrá impuesto por los requisitos de negocio. Es decir, programaremos lo más importante primero y la experiencia nos dice que, en incontables ocasiones, lo menos importante termina siendo irrelevante y probablemente prescindible, convirtiéndose en algo que o no se hará o simplemente se hará en el futuro, dentro de otro contexto de proyecto. En resumen, una orientación ágil supondrá un considerable ahorro en horas de trabajo y, consecuentemente, una reducción efectiva de costes.

(Imagen: Management Plaza)

Requisitos emergentes vs extensa fase de análisis de requisitos:

En un modelo clásico, existiría una fase de toma de requisitos más o menos extensa. La idea de esta fase será identificar todos los requisitos que el usuario necesita llevar a cabo para poder modelar el sistema antes de pasar a la construcción del mismo. Esto suena muy bien, pero la realidad dice que modelar un requisito en una fase tan temprana, requiere de muchas toma de decisiones del usuario cuando todavía no está preparado para ello.

Desde luego, se podrá estrujar cerebro del cliente y conseguir extraer hasta la última línea de información que necesitamos para modelar el sistema. Pero de ser así, ocurrirán dos posibles cosas:

• que el grado de detalle de los requisitos sea tan bajo como para que no sirva demasiado a la hora de pasar a programación.
• que el grado de detalle sea tan alto como que al programador no se le deje ser creativo.

En ambos casos, el consumo de horas será elevado. En el primero, habremos “desperdiciado” un número considerable de horas modelando unos requisitos que son insuficientes para el equipo de programación, con el consiguiente sobresfuerzo de re-analizar y re-programar. Y en el segundo caso, habremos afinado tanto los requisitos que, con toda seguridad, se habrá quemado un buen montón de horas y desaprovechado considerablemente la creatividad de nuestros programadores. Por no contar con que el problema de que el usuario no sabe lo que quiere hasta que lo ve, continuaría latente. En resumen, más horas a pagar.

Con una orientación ágil, los requisitos partirán de “historias de usuario” que se llevarán a la programación y que iremos afinando y modelando junto al cliente de manera cíclica. Así los requisitos emergerán de manera natural, según el momento y necesidad del cliente, a medida que este vaya viendo su aplicación construida.

Entregas de funcionalidad frecuentes vs largos periodos entre entregas

Con una estrategia de “entrega continua” de software, el cliente podrá visualizar y probar su aplicación al mismo ritmo que se está desarrollando. Los cambios podrán ser validados de una manera tan ágil que supondrá un ahorro de horas de trabajo considerable, además de la entrega continua sobre entornos de validación. Llegado el momento, y si el proyecto así lo requiriera, los cambios validados podrían pasar a producción tan rápidamente como se están aceptando. Muchas de las plataformas web más conocidas en la actualidad tienen uno (o incluso varios) despliegues de funcionalidad en producción diarios.

Indudablemente, la agilidad en los ciclos de programación-entrega-validación-publicación, suponen un ahorro significativo en el número de horas a ejecutar y, en consecuencia, una reducción considerable de costes en el proyecto.