¿Cómo lidiar con los frecuentes cambios de requisitos?

Estoy lidiando con una situación bastante estresante (en mi opinión) en mi lugar de trabajo actual.

Comenzamos a desarrollar un nuevo proyecto, obtenemos algunos requisitos, lo implementamos y luego mostramos a alguien que puede llamar un 'asesor comercial' (persona que conoce los requisitos comerciales pero no usará el programa). Se supone que esa persona debe evaluar la aplicación desde el punto de vista del cliente, probarla, etc.

Aquí se ve el 'proceso':

1. El asesor de negocios habla por la tarde con mi jefe durante una o dos horas en Windows Messenger
2. Al día siguiente recibo un correo electrónico con una copia de esa conversación. Se supone que debo elegir tareas de eso, verificar los errores reportados (que a menudo no son errores, solo pruebas deficientes y olvido de establecimientos anteriores)
3. Implemento cambios, la implementación es aceptada y luego, en una o dos semanas, resulta que no quieren lo que quieren (conversaron con algún cliente potencial que ha visto software durante 5 minutos y él sugirió cambios). Tengo que hacer nuevos cambios.

No me malinterpreten, entiendo que a veces los requisitos cambian. Lo que me molesta es la frecuencia con la que se produce el cambio en mi lugar de trabajo y cuán fácil es para la 'gestión' dos requisitos nuevos o, a veces, cambios fundamentales en las características existentes.

Al mismo tiempo, trabajamos en plazos ajustados y tengo la impresión de que, en lugar de seguir adelante con nuestro software, estamos ejecutando círculos.

¿Busco consejo de usted para enfrentar esta situación? ¿Es esta una situación normal y soy hipersensible?

Si es posible, tome la conversación que le enviamos por correo electrónico y conviértala en un documento de requisitos. Haga una lista de las tareas que puede extraer de ella y ordénelas según lo que perciba como la prioridad y asigne una estimación a cada una. Luego pregunte qué características desean para la próxima versión.

Básicamente, forzar algún tipo de bucle de retroalimentación donde la administración sepa qué es lo que va a construir. Escriba sus propios documentos de requisitos hasta que reciban el mensaje.

Tarjetas de historia

Creo que su situación es muy adecuada para presentar historias de usuarios . Son realmente útiles para proporcionar una forma continua e interactiva para que su gerente establezca prioridades e incluso puede tirarlas cuando vuelva a la idea una semana después y se dé cuenta de que no es viable.

En el mundo real, los requisitos cambian habitualmente. En el lado positivo, lo descubres antes de terminar de compilar el software y enviarlo: tienes un ciclo de retroalimentación estricto del usuario directo del software, lo cual es realmente genial.

Parece que el mayor problema aquí es la forma muy ad-hoc de gestionar el cambio. Usted tiene lo que ágil / Scrum considera un "propietario del producto", que da su opinión, pero el proceso está mal documentado y mal pensado.

Probablemente desee ver los modelos en Scrum , y su visión de lo que es un propietario efectivo del producto , para ayudar a informar sus próximos pasos.

Por lo tanto, en lugar de tener este proceso ad-hoc, intente trasladarse a un mundo en el que tenga una relación más estrecha y útil con el "asesor comercial", y donde todos estén en la misma página sobre los resultados de los cambios que están discutiendo .

Su proceso actual hace que sea demasiado fácil para estas personas simplemente hacer una lluvia de ideas sin tener en cuenta los recursos y el dinero que esto consumirá. Si quieren todas estas características, necesitan obtener un "aspecto en el juego".

Tome ese correo electrónico de la conversación y póngalo en algún tipo de aplicación de seguimiento de características / errores, incluso si es solo una hoja de cálculo. Envíe las nuevas adiciones al asesor comercial y pídale que firme cada elemento o proporcione correcciones. Junto con el cierre de sesión, deben priorizar (¿Cuáles quieres primero?).

Después de que lo aprueben, envíelos de regreso a su horario sobre cuándo se completarán los elementos para la prueba y haga que se comprometan a un momento para hacer la prueba / aprobación de finalización.

Sé que crear este tipo de documentación no es la razón por la que te convertiste en programador, pero puedes arriesgarte a tirar estas listas o seguir desechando el código que tanto te costó ganar.

Hacer retroceder. Los responsables necesitan ver cuánto cuestan estas solicitudes.

Los cambios de requisitos no siempre son malos. La clave es recordar a su cliente. Probablemente su jefe sea su cliente en este caso. Debe notificar a su jefe que considera que estos cambios constantes en los requisitos están limitando su capacidad de producir el producto que le es más útil. Es completamente posible que el negocio se beneficie de usted constantemente reaccionando a los cambios. Si es así, ese es su modelo de negocio, y no está haciendo nada malo, ¡aunque recomiendo correr por las colinas en ese caso!

Las personas que están frustradas con los cambios de requisitos a menudo son valoradas por lo bien que manejan cada cambio. Esta métrica de "número de cambios suficientemente manejados" es probablemente la fuente de su verdadero problema. Considere discutir mejores métricas con su jefe. Cuando me enfrento a requisitos en constante cambio, me esfuerzo por escribir contenido que me permita adaptarme a los requisitos en constante cambio. En lugar de ejecutar una simulación y analizar los datos todos los días, escribiré herramientas que hacen que el proceso de ejecutar la simulación y analizar los datos sea más económico, y cosechar las recompensas con el tiempo. Si eso sigue siendo una locura, ¡incluso podría escribir una herramienta para escribir herramientas!

Su proceso podría beneficiarse de algunos principios ágiles, como bloquearse en iteraciones. Creo que una semana es razonable con los cambios tan rápidos que estás describiendo. 2 semanas podrían funcionar mejor eventualmente.

Una vez que se hayan identificado los requisitos lo suficientemente importantes, haga que la persona que está en el Project Ownerrol los apruebe y los encierre por un período de una semana mientras los construye. Asigne suficiente trabajo para usted donde estará ocupado y deje que los poderes conozcan su asignación. es decir, si por semana puedes producir trabajo de 16 puntos y tienes 16 puntos de trabajo, entonces estás totalmente utilizado para esa semana. (El concepto de puntos proviene de un flujo de trabajo ágil)

Si se producen cambios a mediados de la semana, pronuncie estas palabras mágicas:

Puedo hacer [esta nueva función], [este nuevo cambio], [etc.], pero ¿qué no quieres que haga ?

Es decir, usted es un recurso limitado, solo puede tomar tanto trabajo. Si entra un nuevo elemento de trabajo, se le permite ser el recurso limitado que es y asignar puntos al nuevo elemento y soltar / cambiar otros elementos en lugar de este nuevo cambio entrante. Vuelva a priorizar su lista de iteraciones junto con el propietario del proyecto y debería ser mejor para lidiar con el cambio.

Si los requisitos cambian con más frecuencia que eso, es posible que deba negociar más estabilidad en su entorno.

La frase "Cambio de requisitos" a veces es utilizada por personas de TI. Lo que está describiendo es un cambio de requisitos, pero esto puede deberse a uno o más de los siguientes (no sé lo suficiente sobre su caso, por lo que lo siguiente puede o no aplicarse):

1. La ambición de la gerencia es hacer feliz al usuario final lo más rápido posible y mostrar un progreso rápido.

2. Falta de análisis detallado. Recuerde que los analistas deben hacer preguntas sobre por qué no solo qué. Los analistas necesitan "pensar" con el usuario final sobre una "solución" no solo tomar pedidos.

3. Falta de un proceso formal para la verificación y confirmación de requisitos, seguido de aprobación.

4. Pedirle a la persona incorrecta que desempeñe uno o más roles para los que no está necesariamente capacitada, como los roles de Analista de negocios o Analista de sistemas.

5. Prototipos limitados.

6. La suposición / miedo de que debe hacerse rápidamente y si no es su culpa la TI.

A menos que uno aborde todo lo anterior correctamente, la relación entre TI y el negocio / usuario final será estresante. Tenga en cuenta que esto no implica que los puntos anteriores sean concluyentes. Hay otros factores que conducen a situaciones estresantes similares a su situación, pero creo que esta lista debería ayudarlo.

Creo que deberías abordar esto desde algunas direcciones:

1. Haga que todas las partes interesadas (incluido todo el equipo de desarrollo) se reúnan (fuera de línea / en línea) con el asesor comercial e intenten comprender el dominio, la visión y luego intercambiar ideas sobre los requisitos.

2. Formalizar requisitos / historias de usuarios, calificando cada uno:
   a. Prioridad (urgencia / importancia)
   b. Vencimiento (qué tan bien definido está, entendido y acordado por la mayoría de los interesados ​​*)
   c. Complejidad (estimación aproximada)
   
   Al elegir en qué requisito / historia de usuario trabajar a continuación, tenga en cuenta los tres factores. Si el requisito tiene baja madurez, agregue una misión de investigación antes, en la que se contacte con todos los interesados, investigue el razonamiento detrás del requisito y defina mejor el requisito (escriba casos de uso y / o cree marcos de alambre y preséntelos) antes de actuar sobre ella

3. Intente pensar algunos pasos hacia adelante mientras diseña antes de cada implementación: diseñe una arquitectura flexible que tenga espacio para adaptarse a los cambios.

4. Intente adaptar un proceso de desarrollo ágil, por ejemplo, SCRUM o Kanban; esto le proporcionará un kit de herramientas para desarrollar un producto con requisitos cambiantes.

También debe considerar pedirles a los moderadores que trasladen esta pregunta a PM.stackexchange.com (marcándola) ya que aunque esta pregunta encaja aquí, encajaría mejor allí.

(*) Accionistas para el acuerdo: negocios, marketing, gestión de proyectos, desarrollo y control de calidad.