A mitad del desarrollo, el negocio cambia un requisito central. ¿Qué haces?

Averigua qué cambió en el negocio antes de evaluar el cambio en sí, porque eso te dice si vienen más. Luego haz el análisis de impacto: qué está construido, qué está diseñado, qué está probado y qué hay que rehacer. Presenta opciones costeadas y deja que decida el sponsor, y actualiza la trazabilidad para que el cambio no deje detrás pruebas huérfanas y documentos obsoletos.

Mi primera pregunta no es sobre el cambio, es sobre por qué ha cambiado, porque eso me dice si es puntual o el primero de varios. Si se movió una regulación o perdieron un cliente grande, vienen más y debería planificarlo en vez de tratarlo como una petición aislada. Luego hago el análisis de impacto en condiciones: qué está ya construido, qué está diseñado pero no empezado, qué casos de prueba se mueren, qué documentación queda obsoleta y qué hay que rehacer. Ese número suele ser mayor de lo que la gente espera, y la parte de pruebas es la que nadie cuenta. Lo llevo de vuelta como opciones con costes, para que el sponsor pueda absorberlo, aplazarlo o dejar caer otra cosa, y entonces volvemos a fijar la línea base. El último paso es el aburrido: repaso la trazabilidad y limpio, porque si no acabas probando contra un requisito que ya no existe.