Me he decidido a escribir este artículo sabiendo que voy a tratar un tema delicado y que muchos lectores ya tienen en su cabeza una idea formada a favor total y fervorosamente de uno de los dos tipos de metodologías de gestión de proyectos…. y en contra del otro tipo.
Llevo varios años hablando con personas pertenecientes a las dos corrientes. Voy a intentar dar mi opinión en este artículo, aún a riesgo de saber que mis opiniones quizás incomoden a unos o a otros, o a ambos colectivos.
Tipos de proyectos
Actualmente existen dos metodologías principales para gestionar proyectos:
- Proyectos en cascada (“Waterfall” en inglés), es la manera clásica de hacer proyectos por etapas secuenciales (requerimientos, análisis funcional, diseño técnico, desarrollo, pruebas, arranque). Es lo “antiguo” que se ha venido haciendo desde 1960 o antes con diversas variaciones (espiral, iterativa…).
- Proyectos ágiles (SCRUM, por ejemplo), que se realizan siguiendo patrones ágiles (sprints de dos semanas, product backlog, Product Owner, Scrum Master, desarrolladores…). Es lo “moderno” que apareció a finales de los años 1990 y que se oficializó tras la publicación del “Manifesto for Agile Software Development” en el año 2001.
Los que ya tenemos una edad nos ha costado un poco entender la forma ágil de desarrollar proyectos. Fuimos “educados” en que no se podía empezar un proyecto hasta que tuviéramos claro (o creyéramos tenerlo) su alcance, coste, y plazo… y un buen/largo contrato (¡firmado, por supuesto!) especificándolo todo.
A las personas que defienden los proyectos en cascada, se les llama como que son los del “lado oscuro” por que parece que defienden más los intereses propios de su empresa proveedora que los intereses del Usuario…. y que generan mucha burocracia.
Al final estas personas clásicas han entendido lo de hacer proyectos de forma ágil (el alcance va cambiando y se va refinando a medida que avanzan los sprints). De hecho, explican que son más sencillos de gestionar ya que apenas hay conflictos contractuales y menos papeleo. Algunos de mis compañeros de edad avanzada les llaman proyectos “happy happy” ya que el alcance se va definiendo sobre la marcha y nunca hay discusiones con el Cliente… y lo que si que hay son muchas reuniones.
En mi experiencia, creo que ni unos son el lado oscuro inmóvil y burocrático, ni que hacer un proyecto de forma ágil nos desentienda de presiones y tensiones de plazos, costes, alcance, y calidad.
También hemos aprendido, nosotros y muchos de nuestros Clientes, que en ocasiones es bueno hacer un proyecto en cascada y otras veces es bueno hacerlo en modo ágil.
Personalmente creo que ambas formas de hacer proyectos son correctas dependiendo de las características del aplicativo de software a realizar, del time to market necesario, y de la organización de la empresa en su totalidad. Todas estas dimensiones son igual de importantes.
Por ejemplo, y usando dos ejemplos muy extremos, la forma ideal de desarrollar las diferentes versiones de una app de teléfonos móviles debe ser ágil ya que lo que interesa es salir al mercado lo antes posible, adaptarse muy bien a las necesidades cambiantes de los Usuarios, y ofrecer más que la competencia. Sin embargo, el método en cascada es la mejor forma de construir una planta de producción de coches o un sistema corporativo de backoffice bancario con infinitas interfaces con sistemas externos, hardware que ha de ser diseñado y fabricado…. y siguiendo las directrices de seguridad o confidencialidad de la UE (o similar) que no se pueden cambiar.
No tiene sentido pedirle un proyecto ágil a un proveedor externo cuando el Departamento de Compras exige plazos, alcance, y costes concretos con penalizaciones dentro de un contrato de 100 páginas que tiene anexado una lista de requerimientos fija e indiscutible. Si además el departamento de Negocio “no tiene tiempo” para participar en el proyecto salvo las pruebas de aceptación finales….
De igual forma no tiene sentido hacer un proyecto en cascada cuando el alcance no está completamente claro al inicio del proyecto, y éste se va definiendo por el departamento de Negocio (a través del Product Owner) a medida que el proyecto avanza ya que la competencia en el mercado es feroz y cambiante cada semana o mes. Si lo intentamos hacer por cascada (aunque sea iterativo), el Project Manager va a invertir la mayor parte de su tiempo gestionando los cambios en el alcance y plazos sin ofrecer valor añadido al Negocio del Cliente. Además, manteniendo eternas discusiones sobre costes, y plazo que al final destruyen el espíritu de equipo entre Cliente y Proveedor (sea interno o externo).
Clientes híbridos
Existen clientes/empresas jóvenes que nacieron y son ágiles de forma completa y pura, y otros clientes más antiguos o clásicos que son puros en cascada, aunque es bien cierto que estos últimos están lógicamente desapareciendo a gran velocidad.
Como ya comenté en un post anterior www.kiteris.com/team-as-a-service-taas, existen muchos clientes que empezaron haciéndolo todo en cascada, pero que se han tenido que ir adaptando (presiones de mercado, desarrollo de apps…) y ahora combinan la realización de proyectos en cascada con proyectos ágiles. Ahora bien, todos los participantes y stakeholders de cada uno de los proyectos deben tener claro las “reglas del juego” a aplicar en cada uno de los proyectos…. desde el CEO y el CFO hasta el departamento de IT y el de Negocio.
Retos
Existen una serie de retos que la situación actual plantea a nuestros Clientes y a nosotros mismos cuando les estamos ayudando a gestionar sus proyectos o realizando tareas de Oficina de Proyectos (PMO) con visión global.
El primer reto que debe abordar un cliente es decidir qué forma de gestionar y hacer proyectos debe ejecutar para llegar a sus objetivos de Negocio o de sus accionistas: sólo proyectos en cascada, solo proyectos ágiles, o ir decidiendo caso a caso dependiendo de las necesidades. Esta decisión implica o arrastra decisiones de qué metodología y herramientas de gestión se debe disponer, qué formación debo darle a mi equipo, que involucración y coordinación necesito entre Negocio e IT,…
El segundo reto es explicar a toda la organización (Legal, Compras, Finanzas…) que no es lo mismo contratar ni gestionar un proyecto en cascada que un proyecto Agile. Estos departamentos deben ser capaces de aceptar y proponer soluciones contractuales para ambos tipos de proyectos y no únicamente para los históricos proyectos en cascada.
El tercer reto es crear un mecanismo de reporting y gestión a la Dirección que permita incluir tanto proyectos en cascada como proyectos ágiles en la visión de alto nivel. Esto se puede hacer mediante la creación de una “PMO híbrida”.
Hay otros aspectos más especializados a solucionar pero que también son importantes y se deben tener en cuenta en clientes grandes o ya maduros:
- ¿qué herramienta (única, si es posible) de gestión de proyectos y de programas (grupos de proyectos) se debe usar? Hasta hace muy poco había herramientas que gestionaban muy bien el mundo de proyectos en cascada (Project Online de MS y sus “clones”, Clarity PPM de CA…), y otras herramientas que han nacido para gestionar proyectos ágiles (Trello, Rally, Asana…), En los últimos dos o tres años están habiendo movimientos de adquisiciones e integraciones de ambos mundos.
- Existen clientes muy grandes que nacieron ágiles y que todos sus proyectos son ágiles pero que se encuentran con el reto de tener que gestionar multitud de proyectos ágiles independientes de forma coordinada. Aquí aparecen metodologías con SAFe, Spotify, Scrum@Scale (S@S)… que intentan extender el concepto ágil a la gestión de múltiples proyectos pero que, a cambio, añaden complejidad al concepto agile. Estas metodologías a veces no son aceptadas por los puristas Agile.
- Las tendencias actuales dentro del mundo ágil llevan a la siguiente evolución. Se trata de las metodologías DevOps y TDD (con herramientas de pruebas automatizadas) cuya penetración está siendo muy fuerte actualmente, especialmente la primera. Estas metodologías intentan unificar en un equipo de proyecto los mundos hasta ahora separados de infraestructura y de testing. El objetivo es tener un equipo único multidisciplinar que permita llevar a cabo todo el ciclo de vida del software y así reaccionar de la forma más flexible posible.
- Dentro de los proyectos en cascada se pueden aplicar parcialmente ideas y formas de trabajo del mundo ágil que pueden ser una forma de romper las estanqueidades y silos de especialistas que suelen aparece en dichos proyectos. Por ejemplo, la realización de daily meetings es una muy buena idea.
Lo que si veo claro es que el mundo de la gestión de proyectos cada vez es más ágil, e híbrido en algunos casos. Desde Kiteris hemos de estar preparados para ello. Es por ello por lo que debemos estar formados y experimentados tanto en metodologías ágiles como en aquellas metodologías y marcos clásicos de cascada pero que se están abriendo al mundo ágil como puede ser PM2 (ver www.kiteris.com/open-pm²-para-pymes) o la reciente 7ª edición del PMBok del PMI®.
