#AgileBackToBasics [1]

La gestión tradicional. El Proyecto Alpha

Como buen profesional del Project Management, tienes claro el reto que se te plantea y los pasos a seguir: te esperan unas primeras jornadas con el área funcional para negociar la creación un documento que contenga exactamente la información que necesitas para que el área de Desarrollo pueda crear el producto que el cliente te ha dicho que necesita: The Alpha App.

Lo habéis logrado: el documento funcional es extenso y rico, con los requerimientos funcionales bien detallados y apoyados por unos buenos flujogramas con los que podréis diseñar un buen documento técnico.

Una vez aprobado el Funcional, es hora de crear el Documento Técnico. Apoyándose en el Funcional, trabajáis duro para documentar exactamente cómo será el desarrollo de Alpha, con más flujos, modelos, pantallazos, propuestas de diseño, el plan de pruebas, todo apoyado por UX y QA. Tenéis claros los procesos y el lenguaje, así como las herramientas que utilizaréis.

Una vez aprobado el Documento Técnico, hablas con el responsable de Desarrollo para afinar la planificación y la estimación de costes. Todo queda plasmado convenientemente en el Project Plan que seguiréis y cuyos hitos cumpliréis puntualmente.

Negociados plazo, costes y alcance (lo que se da en llamar “Triángulo de Hierro”), habéis llegado a un acuerdo, materializado en el contrato que regulará vuestra relación y os proporcionará a ambas partes la seguridad que necesitáis. Es hora de planificar el Kick-off y las reuniones de seguimiento internas y externas, la matriz de riesgos… y empezar. 

Han pasado dos meses desde el inicio y tenéis por delante 7 meses más de intenso trabajo para crear el Alpha que vuestros clientes quieren…

¿Realmente este modelo nos conduce al éxito?

LLegados a este punto, seguramente tu cerebro te está diciendo que me dejo algo… y tiene razón. Hay muchos factores que se dan por sentados en el modelo tradicional y muchas batallas que librar porque la realidad se empeña en alejarnos de la situación ideal.

Uno de los factores más importantes es que se da por sentado que las necesidades del día en el que se firme el contrato van a ser las mismas que el día de la entrega. Y, en el entorno cambiante en el que nos encontramos hoy en día, eso es mucho decir. En la visión tradicional, esas necesidades expresadas por el cliente y a las que se compromete el equipo son inamovibles o, como mínimo, muy difícilmente gestionables… al fin y al cabo, debemos mantener el proyecto bajo control en cuanto a plazos y costes. El proceso de renegociación del alcance suele ser arduo y requiere casi de un nuevo proceso contractual… ¿Qué sucede si el producto final ya no se adapta a las nuevas necesidades del cliente? ¿No es lo que firmamos? ¿El cumplimiento de lo pactado nos garantiza la satisfacción del cliente?

Una de las cuestiones que pueden llevarnos a esta situación es el tiempo que transcurre desde que se detecta la necesidad hasta que se finaliza el proyecto. El proyecto inicia siempre aportando una absoluta claridad sobre esas necesidades iniciales, lo que requiere un valioso tiempo invertido en documentar el producto en su totalidad… ¿Qué porcentaje del tiempo total del proyecto lo pasamos documentando unas necesidades estáticas?

Siempre se tiene claro el lenguaje, las herramientas y los procesos que se van a seguir para realizar un desarrollo eficaz, pero… ¿Qué sucede con el equipo? ¿De verdad es prioritario que la inteligencia resida en el proceso y no en el individuo?

Otro de los factores críticos por los que se evalúa la marcha del proyecto es el cumplimiento de plazos y la adherencia al plan de proyecto… ¿Estamos seguros de que la suma de hitos cumplidos y fechas respetadas nos garantiza exactamente la satisfacción de las necesidades de los clientes? ¿Qué necesidades? ¿Las del primer día del proyecto o las del día de la entrega?

Entonces, la respuesta a la pregunta que encabeza esta sección es sí, pero, ¿a qué precio?. Este modelo nos ha traído hasta la situación actual y nos ha ayudado a gestionar en el pasado pero, ¿nos seguirá sirviendo de ayuda en un entorno cambiante e incierto como el actual?.

Como hemos visto en el ejemplo del Proyecto Alpha y en los siguientes párrafos, hay una serie de cuestiones que la visión tradicional no cubre.

El Manifiesto Ágil propone centrar la atención en:

Lo cual no quiere decir que los aspectos de la derecha no sean importantes, pero inciden en que los de la izquierda lo son más.

En la próxima entrega hablaremos en detalle sobre estos cuatro valores del Agile Manifesto con algún ejemplo de la vida real que estoy seguro de que a más de uno le recordará alguna historia propia.

Como siempre, estaremos encantados de atender vuestros comentarios, anécdotas, sugerencias… a través de este Blog, de Twitter, Facebook  y LinkedIn.

.