¿Permitir a los usuarios reunir los requisitos por su cuenta o guiarlos?

Estoy seguro de que todos han experimentado algo como esto. Entras en una reunión con un cliente que tiene un proyecto. No tienen / pocos requisitos en mente y la comprensión más vaga de lo que quieren / necesitan. En este punto, parece haber dos opciones:

1) Diga a los usuarios: "Ok, entonces no puedo construir algo para ustedes si ni siquiera pueden describirlo. ¿Por qué no nos reunimos en unas pocas semanas cuando saben lo que quieren?".

2) Reúnase con los usuarios varias veces y ayúdelos a descubrir lo que quieren guiándolos con el buen método socrático. "¿Necesita rastrear X?", "¿Qué tal Y?", "¿Necesita funcionalidad Z?"

Con la primera opción, no te quedas atascado haciendo el trabajo de otra persona, o habiendo obtenido poderes psíquicos, sin embargo, los usuarios podrían nunca presentarte una especificación coherente, o podrían tardar una eternidad a medida que se acerca la fecha límite. Con la segunda opción, pierdes mucho tiempo convirtiéndote en analista de negocios y tienes que meter un montón de conocimiento de negocios en tu cabeza que probablemente nunca volverás a usar, pero es mucho más probable que salgas con una especificación que tiene sentido

Para mí, este es uno de los aspectos más desafiantes del desarrollo, y tengo la sensación de que no estoy solo en este sentimiento. En su experiencia, ¿cuál de estas opciones tiende a funcionar mejor?

Tengo que admitir que a veces elijo la opción 3)

3) Escuche las ideas vagas de los clientes, palidezca ante la idea de pasar semanas ayudándoles a descubrir exactamente lo que quieren ... así que descubra qué es lo que necesitan, construya eso y refactorice según sea necesario.

Esto funciona, particularmente para trabajos pequeños, porque ayuda a evitar aquellas situaciones en las que los clientes tienen esta brillante idea en mente, lo cual no es práctico en el mundo real.

Me pasa todo el tiempo; "seguramente podríamos hacer ..." es una frase muy aterradora. Especialmente porque las cosas que se mencionan casi siempre son las campanas, los silbatos y las características "agradables de tener". No entienden eso en la afirmación "bueno, obviamente, un rastreador de errores, y luego ..." la mayor parte del trabajo potencial se basa en las primeras cuatro palabras.

Entonces, a veces es bueno tener una visión de los clientes , aplicar una dosis decente de sentido común de los programadores y crear algo que se ajuste a sus necesidades.

En términos de la pregunta original; Creo que depende mucho del contexto. Si está atrapado con el cliente (es decir, es a través de un contrato de trabajo al que estoy atado, o no hay otro trabajo alternativo), entonces el # 2 es el enfoque más sensato. De lo contrario, existe una alta probabilidad de que en una semana se le presente una especificación maravillosa y detallada ... que es completamente inútil para usted como programador.

Es el mismo problema mencionado anteriormente (# 3) y uno que te obliga a hacer el # 2 de todos modos.

si quiere ser solo un programador, espere hasta que otra persona descubra lo que necesita el cliente y luego codifique

si quieres ser desarrollador , y este es tu cliente, entonces toma la mano de tu cliente y camina suavemente a través del denso bosque de posibilidades hasta que juntos encuentres la feliz pradera llena de conejos en la intersección de deseos y necesidades.

APÉNDICE: este proceso se llama "análisis y diseño de sistemas", también conocido como Consultoría, y nunca debe hacerse de forma gratuita

La programación es preliminarmente para resolver los problemas de los usuarios. Entonces, para mí, tener un esfuerzo y un esfuerzo "extra" para obtener una solución funcional y satisfactoria para nuestros usuarios casi siempre gana por evitar la molestia "extra" y no ofrecer nada útil al final.

(Por supuesto, hay usuarios reales que realmente no tienen idea de lo que quieren, y ningún esfuerzo puede llevarlos a un estado en el que puedan tomar una decisión significativa. Pero creo que en la mayoría de los casos tienen un problema real, están dispuestos a gastar esfuerzo y dinero en efectivo para resolverlo, y estarán felices si podemos ayudarlos a encontrar una solución que funcione).

En resumen, nuestro enfoque debe ser resolver los problemas de los usuarios. Esto a veces puede requerir hacer algunas preguntas específicas y darles más tiempo para descubrir las respuestas. A veces requiere trazar el dominio juntos, en estrecha cooperación. A veces requiere pasar un tiempo haciendo bocetos / prototipos / maquetas simples, luego mostrándoles el resultado y preguntando "¿esto se parece a lo que tenía en mente?" (luego tirando el prototipo cuando dicen "en realidad, estaba pensando en algo completamente diferente ..." y comenzando de nuevo ... :-)

La verdadera habilidad está en elegir el enfoque correcto para el momento adecuado.

Por último, pero no menos importante, en mi experiencia, las buenas soluciones casi siempre requieren al menos algún conocimiento de dominio por parte del desarrollador. Sin esto, no tiene un lenguaje común real con el usuario, por lo tanto, no hay garantía alguna de que lo que entregue realmente les sea útil. Los usuarios generalmente no tienen mucha idea sobre la tecnología, por lo que no tienen idea de qué es y qué no es posible, y cuál es el costo de los diferentes enfoques / características. Dado que no podemos esperar razonablemente que aprendan tecnología con suficiente detalle, debemos dar ese paso adicional desde nuestro extremo del puente.

Esto podría verse como un esfuerzo "extra" que no paga, sin embargo, prefiero verlo como una inversión, por dos razones:

• me ayuda a ofrecer buenas soluciones, lo que a la larga aumenta mi valor de mercado como desarrollador, y
• diferentes dominios no son completamente distintos, por lo que al menos parte de ese conocimiento de dominio será probablemente reutilizable en futuros conciertos.

Como desarrollador de software, parte de su tarea es obtener una comprensión suficiente del dominio en el que se utilizará el software. Por lo tanto, ser parte de la fase inicial de un proyecto es extremadamente valioso (en términos de tiempo y experiencia del cliente) . Sí, esto significa hacer un análisis exhaustivo de dominio y requisitos. Es el momento perfecto para incorporar a los usuarios objetivo, entrevistarlos o caminar por la ubicación donde se utilizará su software.

Pero obtener esta habilidad es casi una forma de arte, especialmente cuando el dominio no está conectado a una disciplina de ingeniería. Sus preguntas obvias pueden parecer desalentadoras para el cliente, su presencia in situ puede no ser deseada, su falta de comprensión de la estructura social de su público objetivo puede desmoronar las conexiones aún frágiles.

No comprender las complejidades de esta fase a menudo conduce a la decepción, tanto con los desarrolladores de software como con el cliente. Nos gustaría superar esta fase cada vez más rápido o eliminarla por completo. Los resultados a menudo son desastrosos: después del inicio acelerado, durante el desarrollo, las apuestas para tener éxito son cada vez más altas y cada vez es más difícil volver al tablero de dibujo. Cuando el sistema finalmente está terminado y se han gastado millones, ni el cliente ni la empresa de ingeniería están dispuestos a admitir su falla, lo que lleva a la introducción forzada de un sistema fallido.

Una alternativa es dejar que un analista de negocios haga el trabajo por usted. Esto puede ser sensato para algunos productos, y el analista a menudo puede ser un intermediario, pero solo creará más canales de comunicación (y, por lo tanto, una mayor probabilidad de error).

En cualquier caso: reescribir un fragmento de código nunca supera reescribir un requisito.

PD: tal vez crees que estoy abogando por el método de la cascada. No creo en el "gran diseño inicial", pero sí creo que el esfuerzo de análisis de dominio debe ser proporcional al esfuerzo de implementación. Se pueden realizar múltiples ciclos (prototipo, lanzamiento de candidatos, etc.).

Definitivamente la opción 2 a menos que sus usuarios sean desarrolladores (incluso entonces, la opción 2 podría ser necesaria).

La mayoría de los ciclos de vida de desarrollo de software se centran en la recopilación de requisitos. La mayoría de los usuarios no solo no saben lo que quieren, sino que tampoco saben lo que es posible, por lo que trabajar con el usuario para comprender lo que necesita es una tarea crítica de desarrollo de software.

Creo que necesitas ir con ambas opciones. Deja que se vayan y decidan lo que quieren. Luego, cuando haya una idea concreta para usar como punto de partida, guíelos para ayudar a refinar los requisitos a algo útil.

No desea saltar a la Opción # 2 cuando apenas pueden articular lo que quieren, ya que hará que todo el proceso sea más lento y frustrante (a menos que ya tengan una idea muy clara de lo que quieren cuando se acerquen a usted, pero en mi experiencia esto es muy raro). Haz que junten sus ideas. Pídales que escriban algo en papel, que describan lo que quieren en términos de sistemas existentes si es posible (por ejemplo, "queremos un sitio web como blahblah.com pero con estas diferencias ... queremos una herramienta que haga la Tarea A como el Producto X" , pero la IU también debe hacer la Tarea B ... "). Entonces es un buen momento para comenzar a refinar lo que quieren en requisitos muy específicos que puede usar para construir el sistema.

En general, los clientes acudirán a usted sabiendo exactamente qué es lo que creen que necesitan. Desafortunadamente, esto es lo que le dirán, en lugar de describir los problemas que conducen a la solución que creen que proporcionará.

Para diseñar algo que satisfaga sus necesidades, debe identificar esas necesidades y, para hacerlo, alguien tendrá que mantener al cliente presionado y extraer esas necesidades. Si nadie más puede hacerlo, entonces debes hacerlo. (Si alguien más cree que puede hacerlo, es posible que tenga que sentarse con ellos y extraer las necesidades reales más adelante ...)

Con la opción 2, en varias reuniones, es de esperar que pueda capacitar al cliente para compartir problemas con usted en lugar de soluciones. (Incluso si el cliente tiene capacidad técnica, por ejemplo, no tiene disponibilidad para hacer este trabajo y necesita que lo haga en su lugar, puede que todavía se esté centrando en una implementación que no es ideal para el cliente final). importa mucho el proceso de desarrollo que use, aún tendrá que ir y venir varias veces hasta que puedan responder preguntas de manera que definan las especificaciones para usted.

Recuerde que desea detectar defectos lo más temprano posible en el ciclo de desarrollo. Si puede atraparlos durante los requisitos en lugar de durante la codificación o las pruebas, se ahorrará mucho tiempo.

La opción 1 es una excelente manera de evitar hacer algún trabajo. Lo usé cuando creía que el trabajo era innecesario o tenía cosas más importantes que hacer.

Primero, los usuarios no saben lo que pueden hacer las computadoras. La mayoría de nosotros hemos pasado años aprendiendo a entender las computadoras y la computación, y lo que es obvio para nosotros podría no ser fácilmente comprensible para alguien que ha pasado esos años aprendiendo otras cosas.

En segundo lugar, los usuarios no necesariamente saben lo que necesitan, y generalmente no saben lo que quieren, en ningún sentido procesable.

Para dar una analogía, cuando compré mi casa actual, un diseñador de interiores seleccionó los colores de las paredes de las habitaciones en la planta principal (primera planta de EE. UU., Reino Unido). Nunca hubiera elegido esos colores yo mismo. Quería una casa que se viera bien, y la obtuve. Si el diseñador me hubiera escuchado y me hubiera dado algo que pudiera articular, no habría salido tan bien.

La única forma de dar a los usuarios algo que haga lo que necesitan de la manera que les gusta es trabajar con ellos.