Las metodologías iterativas para el desarrollo de proyectos son una buena estrategia para conseguir que el resultado de un proyecto tienda a cubrir adecuadamente las necesidades de un cliente, pero que nadie se lleve a engaño: requiere de condiciones vitales sin las cuales la catástrofe está asegurada por las dos partes. Pueden ser un lobo con piel de cordero…

Escenarios en los que es una estrategia adecuada.

En las organizaciones acostumbramos a encontrar a quien tiene la necesidad, generalmente “negocio”, y a quien lidera el desarrollo tecnológico, que generalmente es el departamento de IT. Es negocio quien tiene la necesidad, quien realmente conoce las necesidades y los detalles particulares a nivel funcional. En cambio, es IT quien conoce de tecnologías, de proveedores, de soluciones, etc.. pero no necesariamente todo el detalle funcional. Por ello, el único que puede describir el problema y la solución, funcionalmente hablando, es negocio, pero generalmente no dispone del tiempo para hacerlo, por lo que no hay un funcional claro, preciso y conciso sobre el que trabajar, donde trabajar, y trabajar = presupuestar + ejecutar. En ocasiones el escenario es cambiante, o la mejor solución no está completamente clara por variables que no vienen al caso.

En este caso, un esquema iterativo puede ser muy interesante ya que quien tiene la necesidad dispone de la capacidad de irse acercando a la herramienta que necesita evaluando en cada caso los pasos que se han dado según sus indicaciones y habilitando cambios según se valida el producto.

Metodologías iterativas

La idea de fondo es: me explicas, yo trabajo, tu revisas, me explicas, yo trabajo, tu revisas… hasta que se acaba el tiempo o el presupuesto. De esta forma se espera conseguir un mejor resultado que con la metodología clásica de:  tu me explicas, en X meses no me ves, y luego te enseño cual va a ser tu herramienta.. parece evidente que la aproximación iterativa es mas susceptible de acercarnos a un escenario de éxito.

¿Quién no ha vivido eso de “.. cariño, quiero pintar esta pared de marrón chocolate… ummm! queda muy oscuro, un poco más clara… hmmmm!.. y la acabas pintando blanca, tal como estaba al principio… “? pues eso… cuidado, que si quien pide no es consciente del coste que representan sus cambios fácilmente podemos caer en un despilfarro.

De forma un poco más rigurosa, el esquema de trabajo que se suele adoptar suele ser cercana al siguiente esquema:

1 – negocio explica sus necesidades
2 – se plantea un prototipo no funcional que de cobertura a las necesidades.
3 – negocio e IT, junto con el equipo de desarrollo, revisan el prototipo, se plantean las enmienas convenientes y se vuelve al punto 2 hasta que todos están de acuerdo.
4 – se formaliza el acuerdo, y se planifica el desarrollo de lo acordado.
5 – a medida que se tienen unidades funcionales disponibles se plantean revisiones a negocio y IT,
6 – se revisan as unidades funcionales que se consideran válidas y negocio y IT plantean evoluciones o la dan por buena.
7 – cuando se ha dado todo por bueno el proyecto está acabado.

Genial, no? esto parece ser un éxito asegurado.. o catástrofe asegurada… depende.

Requisitos para poder trabajar con una metodología iterativa.

Para trabajar con una metodología iterativa es preciso que las organizaciones estén preparadas, no sólo a nivel de personas, sino también a nivel de procesos internos, a nivel de gestión presupuestaria, a nivel de flexibilidad y confianza, etc.. En este esquema resaltan un conjunto de aspectos:

• Uno de los aspectos que resalta es que al principio, no se ha acotado el esfuerzo total necesario para llegar a una solución completa, por que no se conoce!!!!.. pero, ¿Cómo que no se sabe?, cuando el que mayor conocimiento tiene de los aspectos funcionales no ha podido describir con detalle lo que necesita, difícilmente nadie será capaz de decirle lo que vale… parece bastante claro..
• Al no saberse el el esfuerzo, tampoco se conoce el plazo con detalle. Si el proveedor dispone de músculo suficiente, se podrá intentar reducir los plazos, si el proveedor no dispone de músculo, habrá menos maniobrabilidad en este aspecto.
• El cliente debe integrarse en el equipo de trabajo como un miembro más, probablemente, como el miembro más importante, si el cual será difícil que se cubran sus necesidades.
• Si el cliente sabe lo que necesita, genial! vamos por buen camino. Si no lo sabe, el proyecto va a salir caro. Todo el mundo debe ser consciente de esto. No es una ironía, sus pruebas tendrán un coste: las de todo el equipo de desarrollo trabajando, el personal de IT y su propio tiempo en el mejor de los casos.

Muchas organizaciones desean trabajar con un esquema iterativo, por su atractivo potencial, en cambio, a nivel de presupuestario, el equipo de finanzas requiere de proyectos claramente acotados, y a la vez ajustados.. todo lo contrario.. Aquí es donde la flexibilidad juega un papel clave, el cliente debe saber que con el monto asignado puede no llegarse a la situación ideal sin que se haya cometido ningún error por ninguna de las partes, por lo que podrá ser necesario efectuar ampliaciones del proyecto. A la vez, el proveedor deberá ser flexible para no cortar el proyecto y desmontar el equipo de trabajo – que es la muerte de la eficiencia del proyecto – si hay un acuerdo de ampliación para avanzar las horas al cliente. El tema central es que debe existir un acuerdo por las dos partes de no dejar el proyecto colgado, uno por que no tiene flexibilidad presupuestaria, y el otro por que hasta dentro de X meses no se podrá facturar.

Es muy importante que haya una elevada transparencia en el proceso de desarrollo con el cliente para evitar, no sólo que el proceso iterativo oculte ineficiencias, sino también que se evite generar esta impresión por el simple hecho de emplear este tipo de metodología. Una de las mejoras formas de evitar críticas por falta de eficiencia es que el proveedor ofrezca una seniority importante, y el proceso de documentación – tanto del proyecto como de las reuniones efectuadas – sea muy estricto.

No se debe confundir un proceso iterativo, con un proceso no formalizado ni sistematizado, no tiene nada que ver. Se puede implementar un sistema iterativo absolutamente formalizado y sistematizado. Este es un aspecto de elevada importancia, ya que ofrece al cliente la tranquilidad que se precisa ante un entorno deliberadamente incierto en cuanto al objetivo final del proyecto.

En resumen, si se desea abordar un proyecto con una metodología iterativa debemos cumplir todos con:

Cliente:

• Negocio y compras deben saber que la metodología es iterativa y sus implicaciones presupuestarias, de plazos y de dedicación.
• Negocio deberá participar activamente en el proyecto, no podrá ser un mero observador. Sus retrasos en las aportaciones al proyecto tendrán un, si cabe, impacto superior al de las metodologías clásicas, pues sus decisiones son siempre vinculantes para todo el equipo de trabajo.
• Todo el equipo debe ser consciente que deberá pactar una combinación de funcionalidades y fechas después de haber iniciado el proyecto.
• IT deberá ser estricto en el seguimiento del consumo de horas por parte del proveedor, para evitar que un esquema iterativo oculte un sistema ineficiente.
• IT y Negocio deberá ser consciente que el monto destinado inicialmente puede no ser suficiente ya que la estimación inicial del monto total se basaba en estimaciones, no en el conocimiento exhaustivo de las necesidades. Esto no debe ser la excusa para transformar el proyecto en un pozo sin fondo, cosa evitable con un riguroso seguimiento por parte de IT.

Proveedor:

• Debe ofrecer experiencia en la gestión de este tipo de proyectos, las reuniones funcionales deben tener objetivos claros y precisos, deben existir actas, planificaciones, etc..
• Personal senior, para que las problemáticas sean de negocio, no tecnológicas y haya agilidad de desarrollo.
• Los perfiles involucrados en el proyecto deberán tener disponibilidad a corto plazo, pues sus tareas tendrán una elevada probabilidad de ser bloqueantes.
• Disponer de un equipo de UX competente. Es decir, cuando se crea la maqueta de la aplicación, en realidad se está diseñando el producto y especificando campos de entrada y salida, flujos de trabajo, perfiles de usuarios que emplearán el sistema, etc.. Esto es una toma de requerimientos en toda regla, no se puede dejar este trabajo en manos de un maquetador, es preciso que haya un diseñador de producto como la copa de un pino. Si no es así, simplemente será una etapa de pintado de pantallas y no ofrecerá mucho más valor añadido para negocio.

Si no cumplimos…

Dando por supuesto que el proveedor trabaja de forma perfecta e intachable – un escenario idílico – donde dispone de los recursos que necesita perfectamente formados en el momento exacto que los necesita, los riesgos que se asumen son:

• Falta de involucración por parte de negocio: no se cerrarán de forma clara los objetivos del proyecto, se tendrá al equipo técnico a la espera de la concreción de las necesidades, por lo que el coste aumentará y en el proceso de validación aparecerán las desviaciones respecto a lo deseado, junto con la protesta del tiempo, consecuente coste, invertido en la dirección errónea.
• Falta de formalidad y sistemática en la dirección del proyecto: estos proyectos no van “en linea recta”, sino en “espiral”. Si no se es sistemático a la hora de controlar el proyecto, corremos el riesgo de trazar un “zig-zag” en lugar de una espiral.
• Desalineación entre el cliente de negocio y compras. Hay organizaciones que compras requiere de una justificación para dedicar una parte de su presupuesto a algo – cosa que parece muy razonable -. Si no es consciente que se pueden dedicar varias partidas al mismo proyecto puede suceder que nos quedemos sin budget a medio proyecto o – lo que no se si es peor – generar la sensación que este proveedor siempre se pasa de presupuesto, cuando en realidad en comparación con el método clásico esto es más eficiente.
• Si el departamento de IT no controla bien al proveedor, esto puede ser un coladero de fallos e imperfecciones, por lo que el papel del gestor es básico para evitar despilfarros.
• Si el proveedor sobreestima sus capacidades, se obtendrán desviamientos presupuestarios y de calendario.

Resumen

• Todos debemos saber que nos acercaremos paulatinamente a la solución,
• que calcular el coste final es difícil al no conocer el punto final exacto,
• todos debemos arrimar el hombro, y el impacto de que falte cualquiera de los hombros es elevado,
• requiere de flexibilidad por las partes,
• que compras sepa que hacemos,
• pongamos gente buena con experiencia, ¡vale la pena!

Si piensas que tu cliente no cumple con los requisitos, o que tu organización no está madura como para abordar un proyecto de estas características, ¡no lo hagas! ¡no se lo vendas! que será peor… parecerá un cordero hasta el final, ¡que saldrá el lobo!

Enlaces de interés:

https://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
http://www.ibm.com/developerworks/rational/library/may05/bittner-spence/
http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf