Es martes por la tarde y el gestor del proyecto está reunido con el responsable de cumplimiento normativo, el propietario del producto y el equipo del proveedor que está desarrollando un portal para pacientes para una red hospitalaria. El área de cumplimiento necesita la aprobación formal de una serie de controles antes de una fecha de auditoría fija. El propietario del producto presenta una nueva serie de cambios solicitados por el personal clínico esa misma mañana; se trata de modificaciones sustanciales, no de simples ajustes de redacción. Por su parte, el proveedor solicita un documento de requisitos estable para poder finalizar las fases de desarrollo y pruebas. Todas las partes plantean peticiones razonables, pero es imposible satisfacerlas todas simultáneamente. Cada semana, el equipo congela los requisitos para obtener la aprobación, pero luego los vuelve a abrir para incorporar los comentarios de los usuarios reales. El trabajo de rehacer tareas se acumula, el tiempo para las pruebas se reduce y el registro de auditoría se vuelve caótico, ya que se retoman decisiones sin contar con registros de aprobación claros.
Antes de elegir un método de entrega, pronostica dónde fracasará primero este proyecto si no se interviene.
La trampa consiste en pensar que el equipo debe elegir entre la rapidez y el cumplimiento normativo. El verdadero problema es que el proyecto combina dos tipos de trabajo distintos. Una parte requiere trazabilidad, lo que significa poder demostrar cómo un requisito se convirtió en diseño, luego en desarrollo, después en pruebas y finalmente en aprobación. Otra parte requiere un aprendizaje rápido, lo que implica que esperamos modificar lo que construimos a medida que aprendemos de los usuarios. Cuando se fuerza un aprendizaje rápido dentro de un proceso de aprobación complejo y lento, surgen cuellos de botella. Cuando se impone la trazabilidad en un ciclo rápido sin controles claros, se generan hallazgos de auditoría. El instinto de un principiante es pedir a todos que se alineen y congelen el alcance. Esto parece liderazgo porque reduce el ruido inmediato, pero a menudo provoca una explosión posterior de solicitudes de cambio cuando la realidad se impone.
Realidad de la gestión de proyectos En entornos regulados, no se negocia la fecha de la auditoría. Se negocia qué entra en el alcance para esa fecha y cómo fluyen los cambios a través de las aprobaciones.
Cuando se habla de Agile o Waterfall, a menudo se hace referencia a un conjunto de decisiones. En este curso, dividiremos ese conjunto en tres palancas prácticas que usted puede diseñar deliberadamente.
La primera palanca es el ciclo de retroalimentación (o feedback loop): la frecuencia con la que se recibe información real de usuarios o partes interesadas y se traduce en cambios en lo que se está construyendo. Los ciclos cortos facilitan un aprendizaje rápido, pero también generan un mayor volumen de cambios que deben gestionarse.
La segunda palanca es el horizonte de planificación: cuánto tiempo se planifica con detalle antes de comprometerse a construir y probar. Un horizonte amplio puede aumentar la previsibilidad, pero asume que los requisitos permanecerán estables. Un horizonte corto acepta la incertidumbre, pero requiere que las partes interesadas se mantengan involucradas para que el equipo no tenga que trabajar basándose en suposiciones.
La tercera palanca son los puntos de control: momentos en los que el trabajo debe cumplir criterios definidos antes de poder avanzar. Un punto de control puede ser una aprobación formal, una revisión de seguridad o una etapa de validación previa a las pruebas. Los puntos de control reducen el riesgo, pero añaden carga administrativa de gobernanza y tiempos de espera.
Relacione estas tres palancas con los resultados del proyecto y observe las compensaciones (o trade-offs) que implican.