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

14

Esta pregunta debe haberse formulado mil veces, pero parece que hay poco progreso en esta área:

  • Le he preguntado al cliente qué le gustaría que hiciera el sistema, ¡para poco!

  • Le he preguntado al cliente sobre el sistema que se supone que debe reemplazar el software, pero el sistema es demasiado complejo o no conoce el sistema o no hay un sistema que reemplazar.

  • He pasado por decirle al cliente lo que quiere, solo para encontrar el cambio de requisitos en una fecha posterior, etc.

  • He intentado usar un lenguaje común, pero luego me he dado cuenta de que el cliente no conoce la diferencia entre un cuadro de texto y una etiqueta.

La lista continúa y se da demasiado por sentado en metodologías como DDD. Le sugiero esto aquí: ¿Qué capas deben reflejar el idioma del dominio (si un idioma del dominio puede existir estrictamente)?

¡Vamos a encajar esto en algún tipo de algoritmo!

EDIT

Este es el mal cliente clásico y no es uno que yo quisiera.

Una actitud prevaleciente sobre si un desarrollador debe visitar a un cliente se consideraría costosa. Se supone que un desarrollador escribe software; Un día fuera de la oficina, lejos del trabajo de desarrollo y los gastos, a menudo puede ser mayor que el beneficio en el trabajo que se realizará.

Usted puede proporcionar maquetas y estructuras alámbricas, pero si esta no es la persona que va a usar el sistema, su entrada no será de mucha utilidad.

    
pregunta CarneyCode 10.04.2011 - 10:31

7 respuestas

11

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.
respondido por el apoorv020 10.04.2011 - 10:44
6

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.

    
respondido por el Matthew Frederick 10.04.2011 - 13:11
2
  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.

respondido por el m5ba 10.04.2011 - 12:00
2

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.

    
respondido por el maxim1000 10.04.2011 - 14:43
2

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.

    
respondido por el Martin Wickman 10.04.2011 - 15:21
1

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).

    
respondido por el Stephen Bailey 10.04.2011 - 10:47
1

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.

    
respondido por el Steve Haigh 10.04.2011 - 11:04

Lea otras preguntas en las etiquetas