¿Cómo convencer a un cliente no técnico de que sus especificaciones de aplicación deben simplificarse?

Muchas veces me enfrento a la situación en la que un nuevo cliente viene a mí con una aplicación que tiene literalmente cientos de características innecesarias y está bastante claro que las cosas deben simplificarse drásticamente para que el proyecto tenga alguna posibilidad de tener éxito. ¿Cómo convencer al cliente para que adopte un enfoque de Producto mínimo viable (MVP) y simplifique?

editar:

Por lo tanto, la respuesta principal actual es proporcionar al cliente una estimación de tiempo / costo para la gran aplicación. No me gusta mucho esta respuesta porque no aborda el problema real con esta situación. Y eso es: es una mala práctica especificar una aplicación masiva y luego intentar construirla desde el principio. Inicialmente me siento mucho más cómodo construyendo una base MVP pequeña y simple. Y luego agregando pequeñas características a esa base una por una. Entonces, ¿cómo puedo convencer al cliente para que aborde la creación de software de esta manera?

Al estimar cuánto dinero / tiempo costará hacer esas cientos de funciones con alta calidad. Muy, muy pocos clientes pondrán su dinero donde está su boca.

Dos palabras: Historias de usuarios.

Aprendí que la forma más rápida de ayudar a un cliente a obtener una pista es hacer que me cuenten una historia de usuario para cada característica o página que deseen. Suceden varias cosas, que incluyen:

1. Tienen que pensar qué demonios se supone que debe hacer la página / función.
2. A medida que pides más y más detalles ("¿y luego? ... y luego? ...") comienzan a comprender que todo esto no va a surgir al hacer que Magic Space Monkeys ™ vuele y lo haga durante el fin de semana
3. Se convierten en verdaderos socios en el proceso de creación. Lo que significa que entenderán por qué cambiar de opinión acerca de algo que ya está completo al 80% causará a) retraso en el cronograma yb) aumento de costos.

Seriamente. Las Historias de usuarios de los propietarios son una de las mejores herramientas que conozco para aportar al menos algo de cordura al proceso.

Mientras discute el costo y el tiempo de producción, solicite una clasificación de los requisitos ("debe tener", "debería tener" y "bueno tener") para que el conjunto mínimo de características viables del producto que son esenciales sean "must have" en la versión 1, luego ponga el resto de los requisitos en conjuntos de backlogs que podrían realizarse como sprints posteriores a la primera versión. Esperemos que los no esenciales "agradables para tener" se encuentren en la parte posterior del paquete y para cuando llegue a esos sprints, los nuevos que son más esenciales (por experiencia real con el producto) habrán flotado a la cima.

El cliente debe apreciar que está considerando el costo de su negocio y la importancia de obtener un producto rápidamente y no está descartando directamente su "agradable tener" al incluirlos en la cartera de pedidos.

Editar para responder a la edición de OP: Para convencer al cliente de por qué es una buena idea lanzar temprano un producto mínimo viable, explique que hasta que el producto sea utilizado por usuarios reales es difícil saber si será exitoso (especialmente en términos de usabilidad). Si el cliente duda en presentar un producto inicial a toda su base de usuarios, recomiende hacer una "beta limitada" donde esté disponible solo para un subconjunto específico de sus clientes. Dígales que la otra cara de este enfoque es un ciclo de desarrollo largo y costoso con una determinación tardía de que el producto no se puede usar. 37 Signals ha producido un par de buenas referencias sobre esto: Getting Real y Rework . Getting Real está disponible en la web de forma gratuita.

La causa principal de su frustración con la situación es probablemente la percepción y los términos engañosos / incorrectos utilizados por el cliente. El cliente no suele acudir a usted con una lista de requisitos , pero puede ser útil para ellos una lista de deseos de cada cosa que se les ocurra . Esos no son todos los requisitos porque el cliente aún no ha pasado el tiempo para pensar realmente si cada característica es realmente necesaria .

Esto no siempre es necesariamente un problema

Si su cliente tiene el dinero para todas esas características y está dispuesto a deshacerse de él, y realmente no le importa resolver los problemas reales y reales que tiene el cliente, entonces este podría ser un proyecto muy lucrativo. Ocurre, muy, muy raramente, y para la mayoría de los desarrolladores es un trabajo que mata el alma porque puede sentir de antemano que el proyecto no tendrá éxito para el cliente al final (incluso si es financieramente exitoso para usted como desarrollador). También es de alto riesgo porque es probable que termine con un proyecto de costo fijo con mucha incertidumbre, y realmente es un problema juzgar mal el riesgo en proyectos grandes.

¿Qué pasa si es un problema?

Supongamos que no estás en esa situación rara. En este caso, tendrá que abordar las dos principales deficiencias de la lista de deseos como se indica a continuación:

1. Es poco probable que el cliente tenga una idea correcta de los costos de desarrollar una lista tan grande de requisitos, por lo que es poco probable que obtenga el contrato por la cantidad de dinero que realmente necesita para hacerlo.
2. Es poco probable que esta lista de deseos describa de manera precisa y sucinta el problema real que el cliente tiene y quiere resolver.

En mi experiencia, necesita abordar el 2 para corregir el 1. Profundizar en el problema real significa que usted, el desarrollador, ahora tiene la información necesaria para dar saltos creativos para resolver el problema de una manera que el cliente nunca pensó. Es probable que estas soluciones sean mucho más baratas y rápidas que la implementación de la lista de deseos completa.

¿Cómo arreglas eso?
Como dice Matthew Flynn en su respuesta: comience por hacer que el cliente priorice los requisitos. Esto no siempre es fácil, pero obligarlos a hacerlo. Si es necesario, use la frase "Si alguien le apuntara con un arma a la cabeza, ¿qué requisito individual cumpliría?" A menudo encontrará durante este proceso que el cliente realmente no tiene una idea muy clara de lo que significan los requisitos individuales. En ese caso, haga lo que Peter Rowell sugiere y haga que el cliente trabaje a través de User Stories. Usted y el cliente comenzarán a comprender el problema y los requisitos mucho mejor, y luego podrán volver a priorizar. Repita esos pasos tantas veces como sea necesario hasta que se sienta cómodo y sepa lo suficiente como para resolver el problema del cliente .

¿Cómo responde eso a la pregunta de desarrollar una solución? Una vez que tenga una lista de requisitos priorizados, tiene la información que necesita para sugerir un proceso de desarrollo incremental a su cliente. No tiene que llamarlo Ágil, pero puede sugerir dividir el contrato en partes más pequeñas para cada requisito (o conjunto de requisitos indivisible) y entregarlos uno por uno con la validación del cliente. O puede hacer todo lo posible y utilizar los numerosos recursos disponibles en línea y fuera de línea para convencer al cliente de que lo mejor para ellos es cooperar en uno de los estilos de desarrollo ágiles. En cualquier caso, puede proporcionar su propuesta de contrato / proyecto en una forma que sugiera claramente estos componentes básicos de los requisitos en orden de prioridad, cada uno con su propio costo y conclusión. Sostén esa zanahoria frente al cliente,

Primero trataría de explicarles que sus requisitos no son realistas y les presentaría un conjunto de requisitos de contador. Explique que esto resolverá su problema de manera más simple y más rápida, con menos costos y riesgos. No intente convertir esto en una discusión técnica, al cliente no le importa eso. Al cliente le importa obtener un buen producto a tiempo, resolviendo su caso de negocios. Si el cliente no se mueve, acepte el contrato y haga el trabajo, o rechace y explique al cliente por qué no puede tomar responsabilidad por el proyecto en este formulario.

Similar a lo que han sugerido las otras personas, pero ligeramente diferente, sugeriría que todo lo que el cliente puede ser válido, pero tienen que PRIORIZAR. Qué elemento debe hacerse primero. Qué elemento debe hacerse en segundo lugar. Lo que es más importante, si te quedas sin tiempo, qué elementos te dolerá menos no tener. Priorice cada elemento del 1 al 732 (o lo que sea) y complételos en ese orden.

Un ejemplo histórico de una aplicación que terminó por encima del presupuesto y atrasado debido a requisitos excesivos es el Archivo de Caso Virtual del FBI. Estaba destinado a reemplazar varias docenas de aplicaciones existentes, y todas tenían que funcionar completamente, a la vez, en el cambio. El proyecto fue finalmente cancelado. Lo que habría tenido éxito fue diseñar un marco y reemplazar gradualmente las aplicaciones individuales en el nuevo sistema. En cambio, la política y las luchas internas llevan a cada parte interesada en la aplicación a declarar que su aplicación es la más importante, y cada uno de ellos usó sus especificaciones con "must haves" de todas las características que querían agregar a la aplicación existente. Al final, el volumen de solicitudes de cambio escritas cada día excedía la cantidad de código realmente escrito cada día.

He visto el trabajo "Tengo que tenerlo todo" en 2 casos. En uno, el gran cliente financiero (usando una cascada de todas las cosas), tenía 40 sistemas diferentes (nuestra compañía hizo uno de los 40) que se reemplazaron y se pusieron en funcionamiento de una sola vez. Las pruebas de integración y la comunicación fueron grandes problemas. Mi estimación es que quemaron alrededor de $ 100k / día en llamadas de conferencia (cuando se cuenta la tasa de facturación de todos los que están en las llamadas). En ambos casos, se necesitaron fuertes negociadores para elaborar una lista de lo que se entregaría y luego clavaron los pies de todos al suelo. No hubo movimiento de postes, ni renegociación. Ambos trabajos terminaron a tiempo y según las especificaciones. Uno estaba muy por encima del presupuesto, el otro estaba dentro del presupuesto. Para esto, necesita gerentes de proyecto muy buenos que sepan qué pueden ofrecer sus equipos (del tipo que puede decir que la característica Q toma 3).

Al carecer de excelentes PM, negociadores y métricas, recomendaría empujar al cliente hacia entregas incrementales. Si todavía quieren todo el ladrillo de oro a la vez, podrían estar mejor atendidos ayudándoles a encontrar otra consultoría. A veces la mejor respuesta es "no podemos ayudarlo".

Respuesta corta: escucharía a mi cliente y encontraría el enfoque intermedio con ellos.

Sugeriría escuchar al cliente y, dependiendo de su presupuesto y tiempo, dividir el proyecto en fases (lanzamiento, lanzamiento2, etc.).

Luego, puede continuar la estimación de cada fase de entregable, presupuesto y priorización de las características requeridas que la aplicación debe ofrecer.

Por lo tanto, definir el alcance del trabajo y los entregables es el camino a seguir :)

Como dicen otras respuestas, la priorización es muy importante. Una forma práctica de hacerlo es a través del método MoSCoW . Pero es posible que desee comenzar dividiendo toda la lista, de lo contrario, la lista de características en sí misma le dará (o su cliente) problemas de comprensión :)

Además de esto, tiene el problema de mirar el problema como un todo. Probablemente pueda resolver esto si se sienta con su cliente y siga los siguientes pasos:

• Ir globalmente a través de las características y destilar categorías
• Priorice (usando MoSCoW) las categorías, y tal vez defina una jerarquía (una categoría básica con características predeterminadas, categorías para temas principales, categorías para variaciones específicas de los temas principales). Esto podría alterar las categorías que definió en el paso anterior (gracias a nuevos conocimientos).
• Revise cada función una por una y asígnelas a una categoría.
• Priorice (usando MoSCoW) los elementos en las categorías top-x.

Esto le dará una vista de arriba hacia abajo agradable y condensada de las funciones solicitadas, y le dará manillares para definir diferentes iteraciones para comenzar con una base y ampliarla con otras funciones.