He visto proyectos en los que los cambios de requisitos se gestionan mediante un sistema de control de cambios muy pesado. Esto es malo. Muchos cambios importantes no ocurren porque el cliente no quiere pasar por la molestia de presentar un control de cambio, por lo que el software no satisface sus necesidades. Algunos pequeños cambios se deslizan "por debajo del radar" para evitar el proceso, por lo que el software ni siquiera coincide con lo que crees que hace.
Por el contrario, también he visto proyectos en los que el gerente de proyecto piensa que "reactivo" significa hacer que los codificadores respondan a cada solicitud de los usuarios, lo que significa que nunca se realiza ningún desarrollo central y su código se convierte en un gran lío de pirateo. cortar. Esencialmente, ahora no tiene ningún desarrollador, tiene un equipo de ingenieros de ventas sobrecalificados.
Por lo tanto, uno podría esperar que haya una situación entre estos dos polos que funcione bien, y espero que lo que funcione mejor para usted sea tanto una elección personal como una ubicación. Definitivamente hay valor en capturar el costo de cada cambio. En un marco como Scrum, puede expresar el costo en puntos de historia, y el equipo puede intercambiar el trabajo que realizan en cada iteración versus el esfuerzo total disponible. Si tiene un gerente de producto, puede hacer que esa persona cuantifique el beneficio esperado de un cambio o solicitud de función. Esto generalmente se hace en términos de ingresos protegidos (cuántos clientes se irían si usted no hiciera esto) y los ingresos atraídos (cuántos clientes llegarán si lo hace). Eso puede ayudar con la priorización, pero también puede reflejar el sesgo o la preferencia personal del gerente de producto.
los principios: