Cómo diseñar el enfoque híbrido más óptimo para tu proyecto

Cuando pienso en los enfoques de Dirección de Proyectos híbridos, inicial pienso en el contraste actual entre waterfall (cascada) y agile. Sin embargo, estos son los dos enfoques corrientes, y hay muchos matices intermedios dependiendo de la estructura del proyecto o programa en el que estés trabajando.

Hay mucha controversia, sobre qué método es mejor, pero desde mi punto de vista, creo que prácticamente todos los proyectos son híbridos. ¡No necesitas elegir una metodología específica! Me gustaría enseñarte cómo puedes aprovechar lo mejor de cada uno, es decir, utilizar fragmentos y piezas cuidadosamente seleccionados de diversas metodologías reunidas en un todo. Todo depende de cosas como la experiencia de las partes interesadas, el medio y el conocimiento de cada miembro del equipo de gestión del proyecto en su contexto.

Primero, un poco de historia

Los orígenes del método de cascada se remontan a Winston W. Royce (y algunos más antes de él) en la década de 1960. Royce comenzó a trabajar como ingeniero aeroespacial a principios de la década de los 60, pero poco después se encontró trabajando en sistemas de software grandes y complejos y, comenzó a desarrollar nuevas metodologías para mejorar la administración de proyectos de software. En 1970, publicó su artículo influyente " Managing the development of large software systems" Administración de desarrollo de software en grandes sistemas, que generalmente se considera el papel que definió el modelo de "cascada" del proceso de software.

Royce incorporó la creación de prototipos como un paso esencial compatible con el modelo de cascada. Afirmó que el desarrollo de grandes sistemas de software requiere un enfoque exhaustivo, pero también que existe un riesgo inherente en un enfoque secuencial de un solo paso. Para remediar esto, propuso un enfoque iterativo e incremental por el que los proyectos deberían pasar al menos dos veces. También abogó por el desarrollo incremental, donde cada paso siguiente se vincula con el paso anterior, con ciclos de retroalimentación desde las pruebas hasta el análisis y el diseño.

Desde entonces, se han introducido muchos modelos de cascada modificados para solucionar problemas con el modelo de cascada "pura". Solo algunos de estos incluyen los modelos de Desarrollo Rápido que Steve McConnell llama "cascadas modificadas", el "modelo de sashimi" de Peter DeGrace (cascada con fases superpuestas), cascada con subproyectos y cascada con reducción de riesgo.

Con todos esos modelos, tendencias y experiencia, el movimiento agile surgió en la comunidad de software. Y en lugar de ser prescriptivo, el Manifiesto Ágil (publicado en 2001) estableció cuatro preferencias clave sobre cómo abordar un proyecto de software:

*.- Individuos e interacciones sobre procesos y herramientas: los procesos y las herramientas no son condenados por inservibles, pero existe la preferencia de interactuar en equipo para resolver problemas.

*.- Software de trabajo sobre documentación completa: una vez más, la documentación en sí no está condenada, sino que los resultados funcionales se enfatizan más.

*.- Colaboración con el cliente en la negociación del contrato: el enfoque es "trabajar en equipo" con el cliente en lugar de residir a ambos lados de un contrato fijo.

*.- Responde al cambio sobre el siguiente plan: es más importante (y realista y práctico) ser flexible que seguir un plan estricto.

Por lo tanto, en sus raíces, Agile en sí es una especie de "híbrido": no especifica dónde debe estar en el espectro, sino que describe una preferencia y una tendencia, y luego lo deja a los participantes que lo decidan.

Cascada, ágil, y enfoques híbridos en la práctica

Hay muchos tipos de proyectos. Aquí hay tres que caen a lo largo del espectro de cascada a ágil:

*.- Diseño de barcos: Diseñar un barco es ciertamente una tarea grande y compleja. Hay millones de piezas, un programa detallado a largo plazo con un horizonte temporal de tal vez cinco años, los clientes planifican sus propios horarios y negocios en torno a los plazos de entrega, un alto costo de creación de prototipos y reprocesamiento, un alto costo de que algo esté mal (especialmente si llega al campo, los problemas son difíciles de solucionar porque hay mucho hardware). Tal proyecto aprovechará fuertemente los principios de la cascada.

*.- Proyecto de control de procesos de la firma de biotecnología: este es un tipo de proyecto muy diferente. Hay factores regulatorios que determinarán algo de lo que debe hacerse. Pero también hay factores de "eficiencia" que pueden ser dejados a la empresa para permitirle competir y obtener una ventaja competitiva (y eso dará mejores resultados con algo de creatividad). Al mismo tiempo, los clientes cuentan con esto y hay poco margen para errores en los productos. Tal proyecto aprovechará alguna combinación de cascada y principios ágiles.

*.- Proyecto de software comercial: si se diseña de manera modular, el costo de retrabajo es incremental. Es probable que sea fácil de crear prototipos, demoler y reconstruir. Por otro lado, debe haber programas, y si bien las mejoras pueden proporcionar mejoras incrementales que pueden introducirse rápidamente en el producto, también deben ser altamente controladas. Tal proyecto tenderá a apalancar mucho más en el lado ágil, pero aún necesitará algo del enfoque de cascada para gestionar los entregables generales.

Cada uno de estos proyectos tiene elementos de cascada y ágil ... y creo que cada proyecto reside en algún lugar del espectro entre los dos, y que hay fortalezas que derivar de cada uno que contribuirán directamente al éxito del proyecto. Es el trabajo del director de proyecto y del equipo de dirección de proyecto el encontrar el enfoque apropiado.

 

Cómo encontrar el “híbrido” óptimo para tus proyectos

Creo que puede identificar los proyectos en función de varios factores clave que se relacionan con las herramientas y técnicas ágiles y de cascada más apropiadas para el proyecto. Lo he resumido en los cinco factores:

1.- Tamaño: los proyectos más grandes tienden a requerir una planificación más finalizada por adelantado, ya que el costo de los errores tenderá a ser alto. Los proyectos más pequeños son más indulgentes y permiten más fácilmente las correcciones de cursos. Tenga en cuenta que los proyectos grandes a menudo se pueden descomponer en proyectos más pequeños.

2.- Duración: todos los proyectos requieren planificación por adelantado, antes de que comience el trabajo de implementación real. Sin embargo, los proyectos más largos generalmente requieren una planificación previa más completa, ya que el costo de los errores tiende a ser alto.

3.- Tecnología y modularidad: las dependencias hacen que un proyecto sea menos flexible, por lo que un proyecto puede ser sustancialmente más flexible y ágil (por supuesto, cada proyecto es único) si las dependencias entre las partes se minimizan al dividir el proyecto en proyectos componentes.

4.- Madurez versus flexibilidad (o evolución de los requisitos): algunos proyectos tienen requisitos muy maduros, mientras que otros se basan en el desarrollo de requisitos a medida que avanza el proyecto. El primero funciona mejor con un enfoque de cascada, el segundo con ágil.

5.- Costes por error y retrabajo: este es probablemente el factor más importante, ya que los proyectos donde el coste es alto requerirán la mayor planificación posible. Algunos proyectos tienen un bajo coste por error y reprocesado (o un retorno muy alto), por lo que pueden permitirse ser más ágiles.

Es casi como tener un objeto de cinco dimensiones y mover las escalas en cada uno de los cinco factores para identificar ese lugar único en el espectro para su proyecto híbrido. Puede elegir con más intuición qué elementos de cascada y ágil puede emplear su proyecto.

Elija sabiamente del buffet de herramientas de la Dirección de Proyectos

Recuerda que, en última instancia, debes entregar el producto de tu proyecto, sujeto a los parámetros de coste, rendimiento y programación. No hay una solución perfecta, solo mejores maneras de llegar allí. Pero la mayoría de las veces querrás ...

… Colabora más con los clientes.

... estar abierto a cambios de alcance ... pero mantener el control de ellos.

… Defender los valores más altos, … independientemente de la metodología..

... ser un " líder de servicio".

Creo que el truco es triple:

1.- Liderar con valores fuertes.

2.-Mantener una mente abierta.

3.- Tener herramientas y técnicas en tu caja de herramientas.

De esta manera, tu equipo podrá desarrollar su propio enfoque híbrido a la medida a partir de un menú buffet como el siguiente:

Técnicas Cascada	Técnicas Agiles
·         Requisitos detallados por adelantado. ·         No se permiten cambios a los requisitos. ·         Horario fijo y detallado al frente. ·         Documentación pesada. ·         Contratos de rendimiento fijos. ·         Desarrollo por etapas. ·         Secuencia de fases predefinidas. ·         Cada fase se completa antes de la siguiente. ·         Gestión del valor ganado	·         Scrum. ·         Kanban. ·         Desarrollo de Producto Lean. ·         Extreme Programming (XP). ·         Desarrollo basado en características (FDD). ·         Método de desarrollo de sistemas dinámicos (DSDM). ·         Crystal. ·         Programación emparejada. ·         Sprints, iteraciones, demostraciones, comentarios de los usuarios. ·         Potenciador del equipo.

Por supuesto, hay muchas más herramientas y técnicas que las que se enumeran en la tabla, incluida la elección del software y los sistemas que admiten tus procesos. El objetivo es elegir los que trabajarán bien juntos y producirán el resultado deseado. Sus opciones pueden pesar más hacia el lado de la cascada o más hacia el lado ágil, pero es muy probable que tenga un enfoque híbrido con elementos de ambos.

¿Cuáles son las métricas de los factores clave en tu proyecto? ¿Qué técnicas ágiles y de cascada serán más útiles? ¿Cómo los combinarás de una manera que produzca los mejores resultados? ¡Comparte tus pensamientos en la sección de comentarios!