Antes de adentrarnos en el concepto de Ágil propiamente dicho, vamos a conceptualizar el término “Proyecto”, esto así dado que vamos a responder las preguntas desde la óptica de la gestión de proyectos. Un Proyecto es un esfuerzo temporal realizado para crear un producto, servicio o resultado único. La naturaleza “temporal” de un proyecto denota que éste tiene un inicio y un fin claramente delimitado (estas definiciones las podemos encontrar en el PMBOK 5ta Edición). El hecho de tener un inicio y un fin claramente definidos, nos indica que un proyecto cuenta con un Alcance (lo que se debe hacer), un Tiempo (el tiempo que disponemos para hacerlo) y unos Recursos asignados (con cuantos y cuales recursos tenemos que hacerlo) desde su fase de planificación. Esta forma de definir, conceptualizar y gestionar un proyecto es la que “tradicionalmente” conocemos, es decir, desde los años 1950 y 1960, las diferentes organizaciones formales destinadas a organizar y dictar las mejores prácticas en materia de gestión de proyectos (PMI e IPMA) recomiendan (y con sobrada razón) que los proyectos sean gestionados usando este enfoque “Tradicional” al cual también le llamamos “Secuencial”, “Predictivo” o “En Cascada” como le llaman la mayoría de los autores de libros sobre gestión ágil.
Un proyecto gestionado En Cascada regularmente cuenta con una o varias de las siguientes características:
- Problemas y Procesos bien definidos.
- Pocos o ningún cambio en los Productos y Procesos.
- Se dispone de toda la información al principio del proyecto.
- Los Procesos son predecibles.
- Los Proceso son secuenciados.
Para poner un ejemplo de lo que es una gestión de proyectos en cascada, imaginemos que vamos a construir un puente (no es mi área de conocimiento, así que si notan algo fuera de lugar no se enojen, al fin es solo un ejemplo :P ), para hacerlo necesitamos una fase del proyecto donde levantaremos los requerimientos del cliente (cantidad de carriles, en qué lugar exacto va el puente, si se requiere que tenga algún aspecto visual especial, etc.), una vez que tenemos lo que el cliente quiere pasamos a una fase donde analizamos eso que el cliente pidió y evaluamos si es posible hacerlo, aquí se crean varios documentos y se hacen estudios diversos (de suelo, la fuerza del viento, etc.), luego se hacen los diseños arquitectónicos y estructurales del puente, una vez aprobados estos diseños se pasará a la fase de construcción de las partes y del propio puente y por último (estoy inventándome todo esto eh) se hace alguna especie de certificación de que todo quedó como se planificó al principio. Si se fijan, una vez que se ha pasado de una fase a otra resulta sumamente costoso (y en algunos casos imposible) volver a las fases anteriores. Imagine por un momento que usted necesitó realizar algunas explosiones en los extremos (donde iría el puente) para romper rocas y suelo que no supone estar ahí según los diseños y que luego le informen que el puente no va ahí, que el cliente ha decidió que quiere el puente un kilómetro más al sur, esas explosiones son irreversibles. De la misma manera imagine que después de que el puente está casi terminado el cliente le pidiera que remueva dos carriles, que realmente el no necesita 8 carriles, que ahora son 6. Seamos menos drásticos, imagine que ya tiene todo el diseño terminado (no ha iniciado la construcción) y el cliente le pide el doble de carriles (usted ya había diseñado todo para 4 carriles y ahora le piden 8), todos sus análisis previos y el mismo diseño que ha realizado probablemente tendría que tirarlos a la basura.
Para nuestra suerte, estos proyectos no suelen pedir cambios (al menos de alcance) porque toda la información la tenemos al principio del proyecto, los procesos de construir un puente están claramente definidos y conocidos y siempre se hace todo en secuencia (algunas tareas pueden hacerse en paralelo para optimizar el cronograma aplicando Fast Track, pero eso es otro tema).
La gestión de Proyectos en Cascada es muy utilizada en una enorme cantidad de proyectos que cumplen con las características que ya citamos hace un momento, de hecho existen organizaciones que cuentan con mejores prácticas para gestionar proyectos de este tipo, como por ejemplo el Project Management Institute (PMI) que cuenta con el PMBOK y otros libros que dictan mejores prácticas para gestionar proyectos, programas y portafolios, tenemos el IPMA que cuenta con su ICB3, también esta PRINCE2 que tiene el PRINCE2 2009 Refresh y así sucesivamente.
Ahora bien, que pasa con los proyectos que tienen las siguientes características?
- Poca definición de los procesos.
- Poco detalle del producto.
- Alta posibilidad de cambios en los procesos.
- Alta posibilidad de cambios en los productos.
- Poca información del producto y de los procesos al inicio del proyecto.
- Creación incremental de las características del producto.
- Procesos complejos.
- Resultados intermedios pueden cambiar el objetivo original del proyecto.
Para estos proyectos debemos utilizar un enfoque “Ágil” para gestionarlos.
Hasta ahora sabemos porque es que surge esto de “Ágil” en la gestión de proyectos, básicamente para dar respuesta a la gestión de los proyectos que tienen características como las citadas hace un momento y que gestionarlos de la manera “Tradicional” o “En Cascada” resultaría en un caos total (perdida de dinero, de tiempo, incumplimiento del alcance, derroche de recursos, etc.).
Pero, todavía no sabemos que es “Ágil”, aquí les dejo algunas definiciones:
“Habilidad de moverse de manera rápida y fácil.” http://www.oxforddictionaries.com/, 2014
“Se refiere a una forma de gestión de proyectos, la cual está caracterizada por la división de tareas en pequeñas partes de trabajo y una frecuente reevaluación y adaptación de los planes.” http://www.oxforddictionaries.com/, 2014
“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.” Agile Software Development Ecosystems, Jim Highsmith, Page 10
Como hemos podido ver, Ágil no es más que la forma de gestionar proyectos pensando en la revisión, adaptación y rápida respuesta ante los inminentes cambios que pueden surgir en un Proyecto.
La gestión ágil de proyectos responde a las necesidades que la gestión en cascada simplemente no puede. Nos referimos a proyectos:
- Con alto nivel de incertidumbre, en el proceso a seguir y en el producto o servicio que se espera como resultado del proyecto.
- Con un mediano o alto nivel de complejidad, estos son los que requieren que sean creados elementos inexistentes y que por esa razón no sabemos qué tiempo tomara ni cuántos recursos se necesitaran.
- Con necesidad de que sean adaptados procesos y características del servicio o producto a medida que estos son desarrollados.
- Que requieren una retroalimentación muy temprana y recurrente de todo lo que sucede, con el objetivo de poder tomar decisiones que implican cambios en el rumbo del proyecto, sus procesos, sus asignaciones de recursos, de tiempo y hasta en las características del producto o servicio resultante.
- Que necesitan ser flexibles en cuanto a lo que se puede o no hacer (el alcance), en cuanto a lo que se tardara en lograr los resultados (el tiempo) y en cuanto a los recursos que serán utilizados para lograr los objetivos (recursos).
Los proyectos que por excelencia son gestionados (o deberían ser gestionados) usando el enfoque Ágil son los proyectos de desarrollo de software. De hecho todo este tema de gestión de proyectos agiles surgió desde la industria del desarrollo de software (de eso hablaremos en nuestro próximo post).
Existen otros criterios que deben ser tomados en cuenta antes de decidir si gestionar un proyecto usando el enfoque “En Cascada” o el enfoque “Ágil”, sin embargo, los más usados son los que hemos presentado aquí.
Espero haber dejado en su mente algunas dudas con respecto al tema, de esa forma podrá investigar un poco mas sobre todo esto de ágil y podrá verificar por sus propios medios lo interesante que es la Zona Ágil.
No hay comentarios:
Publicar un comentario