¿Cuál es la mejor práctica para reunir requisitos cuando un cliente no sabe lo que quiere? [duplicar]

Parece que su problema se debe a que el "cliente" es probablemente una persona que no va a utilizar el sistema. Algunas cosas que recuerdo de la clase SE:

• Intente visitar a las personas que realmente usarán el sistema y observarlas en las condiciones reales de trabajo. Esto puede ser importante debido a las diferencias de dominio entre los usuarios y los desarrolladores, los dos grupos pueden hacer suposiciones de las diferencias. Si esto no es posible, al menos incluya a uno de los usuarios finales directamente en el proceso de requisitos.
• Use algún tipo de software de diseño de interfaz de usuario para mostrarles las capturas de pantalla de la interfaz de usuario que puede diseñar según sus requisitos actuales. Esto evita el problema de los términos técnicos y la representación gráfica que a menudo resalta los problemas que de otra manera podrían pasarse por alto.

Sé que esta es una frase fea en el mundo del desarrollo, pero aquí es donde realmente entra en juego la consultoría de negocios . Si el cliente no sabe realmente cuáles son sus problemas y qué tipo de soluciones puede desear, realmente no puede diseñar software para ayudarlos.

Agile es excelente y el diseño funcional se lleva bien a la revisión durante el proceso de desarrollo. El análisis de negocios, al menos la mayor parte de él, se maneja mejor en forma de cascada (ooh, una palabra aún más fea hoy), con los requisitos comerciales reales resueltos antes de que comience cualquier diseño de software funcional.

Eso sí, este trabajo no tiene que hacerse por un consultor de negocios (aunque para muchos proyectos le ahorrará mucho tiempo y dolor), pero el mismo tipo de esfuerzo Se requieren si lo haces. Según sus comentarios, no parece que este trabajo se haya presupuestado, pero realmente es importante dar un paso atrás con su cliente y averiguar cómo funciona su negocio, al menos las partes que el software tocará directamente. Si no lo hace, casi se garantiza un proyecto fallido.

1. Identifique a sus partes interesadas. Por lo general, hay pocos de ellos, no solo un cliente.

2. Pregunte a cada uno de ellos qué quieren del proyecto. Cualquier proyecto debe entregar nueva "Calidad". "Reemplazar software existente" no tiene sentido sin explicación ¿Por qué? El método de los 5 por qué podría ser aplicable en esta situación para comprender lo que realmente necesita el cliente.

3. usar un diccionario como "etiqueta", "cuadro de texto" cuando habla con las partes interesadas en la fase temprana de recopilación de requisitos es una mala idea. Debe mantener su mente y la mente de las partes interesadas limpias de las Ideas de diseño hasta que no comprenda los requisitos.

Los clientes no tienen requisitos. Tienen problemas.

La selección de problemas a resolver y su conversión a requisitos es un rol separado que requiere conocimiento en el dominio del cliente y conocimiento de lo que se puede hacer con la tecnología y lo que no se puede hacer.

A veces, el cliente puede asumir este rol si tiene conocimiento de la tecnología, pero es poco probable que ocurra aquí.

Entonces, debes estudiar el dominio del cliente o encontrar a la persona adecuada que estará en el medio.

Me gusta pensar en los requisitos como decisiones sobre el futuro. El futuro está en proceso de cambio, y también lo son las decisiones al respecto. Cuando la nueva información sale a la luz, debemos revisar nuestras decisiones en consecuencia.

La mejor manera de recopilar información es lanzar su software con la mayor frecuencia posible para que el cliente pueda probarlo. A partir de ese comentario, cambia tus decisiones.

En otras palabras: experimenta, observa y adapta.

La asignación de personas como grupo a un algoritmo (estudios sociales / estadísticas) puede llevar a un gran aprendizaje. intentar mapear personas individuales a un algoritmo (alquimia) solo puede llevar a la locura.

Suponiendo que haya intentado lo anterior, entonces la única opción que veo para usted (dado que el proyecto aún tiene que seguir adelante y usted todavía está empleado) es configurar el proyecto como ágil, y costará característica entregada.

Ofrezca solo las características más obvias y esenciales, y deje que crezca orgánicamente.

Es muy posible que todo el sistema sea demasiado complejo para que su cliente lo tenga en mente. Entonces, cuando haces la sugerencia A, suena razonable y él dice "Sí", pero cuando regresas con una pregunta, la respuesta contradecirá la decisión A, simplemente porque la relación de estos dos no está clara para él.

Nota al margen: si le está preguntando sobre cuadros de texto y etiquetas, le está haciendo las preguntas equivocadas. Es probable que solo esté interesado en que funcione, no en cómo funciona. Eso es para que usted decida (con la entrada del usuario).

Como Stephan Bailey dice que la única forma en que esto puede funcionar es si adopta un enfoque ágil.

Comenzaría a crear prototipos de la interfaz de usuario y se los mostraría al cliente, eso debería al menos enfocarlos un poco, incluso si odian su primer intento, espero que esto al menos los lleve a decirle lo que hace querer.

Hay un riesgo importante al mostrar un prototipo de UI, y es que el cliente verá "pantallas" y asumirá que el trabajo está completo porque pueden verlo. Se requiere mucho trabajo para persuadirlos de que algunos botones no son una aplicación. Por esta razón, no haga que el prototipo esté demasiado pulido, manténgalo en bruto y no intente simular demasiada funcionalidad.