Desde mi experiencia, no pasaría un solo minuto desarrollando. Ni siquiera un pedacito de código. En esta etapa, donde el cliente no sabe lo que quiere, es realmente importante hacer un buen trabajo de consultoría . Es tan importante para ellos como lo es para ti.
Detrás de cada proyecto, hay una necesidad (a veces no obvia) relacionada con el negocio del cliente. Entonces, para aclarar la necesidad , primero debe aprender el negocio tanto como sea posible. Entonces podrá llevar al cliente a una solución funcional.
Durante el aprendizaje, tenga cuidado al momento de diferenciar necesidades y deseos . ¿Qué necesidad del cliente puede o no ser la misma que el cliente quiere?
Mientras realiza el análisis, si el cliente no toma decisiones, tómelas usted mismo. Como consultor, su trabajo es asesorar y liderar el proceso.
Como señaló @Ewan, es más fácil para los clientes tomar decisiones si hay alguna opción que hacer. Ofrecer varias alternativas (exponer sus pros / contras), facilita la toma de decisiones. Burlarse de prototipos es una buena manera de dar una visión general de lo que tiene en mente para ellos. El cliente tendrá el primer contacto (y sentimientos) sobre cómo van a ser las cosas. Al hacer este ejercicio de "creatividad", verá rápidamente las luces y las sombras del proyecto antes de que se conviertan en un problema.
Intente obtener la mayor cantidad de comentarios posible del usuario final . Muchas veces la persona a la que llamamos "el cliente", no es quién va a usar el sistema . En tal situación, obtendrá mejores comentarios del usuario final real. Le proporcionarán valiosos consejos sobre lo que necesitan. Identificar bien quién puede proporcionar las respuestas correctas a sus preguntas lo ayudará a cumplir con las expectativas del cliente.
Una vez que haya reunido un buen conjunto de requisitos, colóquelos en el prototipo. Las metodologías ágiles como SCRUM funcionan bien en esta etapa. Haciendo sprints sobre el prototipo.
Los prototipos serán descartados / modificados a lo largo de los sprints. También puede "guiar" al cliente al que más le convenga. ;-). Buscando un trato de ganar-ganar.
Intento evitar que los gerentes comiencen el desarrollo antes de que se haya aprobado cualquier requisito bien definido y medible . De lo contrario, comenzar con requisitos indefinidos está destinado a fallar gravemente. Se desperdiciará mucho dinero y tiempo (sin garantía de recuperarlo) porque alguien ha decidido implementar "el Caos". El Caos y la incertidumbre donde vive nuestro cliente tan querido y confundido en este momento.
Es impactante ver compañías cuyos empleados hacen su trabajo pero no son capaces de explicarle (razonablemente) cómo . También es impactante ver cuántos Gerentes de Proyecto no se preocupan por este problema, simplemente dicen "sí a todos" o "comencemos y veremos qué sucede".
Finalmente, @Ewan nuevamente señaló el punto más importante.
Haga que el cliente firme los que quiera e implemente.
No olvide definir claramente qué requisitos y condiciones deben cumplirse para decir que el proyecto está terminado . Las condiciones de aceptación
No hace falta decir por qué.