Durante la tercera semana de una renovación del sitio web prevista para seis semanas, el asesor legal contacta al gestor del proyecto para informar que una nueva normativa modifica el flujo obligatorio de consentimiento de cookies. El equipo de diseño ya ha aprobado los esquemas visuales (wireframes), el de ingeniería ha comenzado el desarrollo y el de marketing ya ha programado el anuncio del lanzamiento. El equipo se encuentra bloqueado ante una decisión: ¿se detienen para replanificar o continúan y añaden el cambio más adelante? Cada día que se pospone la decisión, se acumula el retrabajo y disminuye la confianza, ya que nadie puede determinar qué implica la nueva fecha de lanzamiento. Este curso te proporciona las herramientas prácticas para superar este tipo de bloqueos. Aprenderás cómo funcionan los ciclos cortos de retroalimentación, cómo utilizar un backlog y un sprint para establecer compromisos semanales realistas, cómo mantener a las partes interesadas alineadas mediante elementos transparentes y cómo gestionar los cambios sin convertir cada solicitud en una crisis.
Para comprender qué falla cuando la retroalimentación es lenta, trabajarás con la cronología de un proyecto sencillo en el que un requisito cambia a mitad del proceso y el equipo debe adaptarse a dicha modificación.
No se trata de que los planes sean malos. El problema surge cuando el aprendizaje llega tras semanas de trabajo: actualizar el plan resulta costoso.
Un plan que asume requisitos estables se convierte en una gran apuesta única. Se definen todos los requisitos al inicio, se estima el proyecto completo y se trabaja con la vista puesta en una entrega final. Cuando en la tercera semana surge un requisito legal, el equipo se enfrenta a dos malas opciones. La primera es congelar el cambio y entregar un trabajo que no cumple con la normativa, lo que genera riesgos operativos y trabajo adicional bajo presión. La segunda es aceptar el cambio y replantear decisiones anteriores, lo que conlleva rehacer tareas, ya que la interfaz de usuario, el seguimiento, el contenido y los scripts de prueba se habían diseñado para el flujo original. El fallo no reside en el esfuerzo, sino en el aprendizaje tardío: el proyecto descubre algo real, pero demasiado tarde para que el plan lo asuma a bajo coste.
Error común Tratar un cambio a mitad del proyecto como una excepción puntual conduce a trabajo oculto que debe rehacerse y, posteriormente, a un retraso en el cronograma que parece una mala ejecución en lugar de un desajuste en la planificación.
La metodología Agile responde abaratando el aprendizaje. Lo logra mediante ciclos cortos en los que se planifica una pequeña parte, se construye, se revisa con las partes interesadas y se adapta antes de añadir más trabajo.
Agile no es un manual de reglas, sino un conjunto de valores que fomentan comportamientos orientados a reducir las sorpresas. La transparencia implica que el estado real sea visible en elementos como el backlog, el tablero del sprint y un incremento revisable, y no solo en actualizaciones de diapositivas. La colaboración significa que quienes toman decisiones y quienes ejecutan el trabajo colaboran frecuentemente, permitiendo que las decisiones se adopten cuando el cambio aún resulta económico. La adaptación implica prever la evolución de los requisitos y establecer una forma controlada de replanificar sin perder la responsabilidad sobre los resultados.
Antes de aplicar estos valores a tu propio contexto, intenta determinar qué comportamiento habría evitado la mayor cantidad de trabajo de rectificación ante el cambio legal de la tercera semana.
Un enfoque predictivo —a menudo denominado Waterfall (cascada)— funciona cuando los requisitos son estables y la gobernanza exige establecer una línea base de alcance fijo desde las primeras etapas. El enfoque ágil es adecuado cuando existe una gran incertidumbre, la frecuencia de las entregas es importante y las partes interesadas pueden ofrecer retroalimentación rápida. El enfoque híbrido combina ambos; por ejemplo, estableciendo hitos fijos para el cumplimiento normativo, pero utilizando entregas ágiles dentro de cada hito.
Un gestor de proyectos toma esta decisión evaluando las restricciones, no basándose en preferencias. Considere factores como la incertidumbre de los requisitos, la frecuencia de las entregas, las necesidades de cumplimiento normativo, la disponibilidad de las partes interesadas para las revisiones y la estabilidad del equipo. Si las partes interesadas no pueden realizar revisiones semanales, las ceremonias ágiles se convierten en reuniones sin toma de decisiones. Si el cumplimiento normativo exige aprobaciones detalladas previas, un enfoque ágil puro puede contravenir las normas de gobernanza, a menos que se incorporen controles predictivos.
Utilice los indicadores de idoneidad para tomar una decisión y, posteriormente, identifique qué restricción fue la que determinó dicha elección.