Como convencer um cliente não técnico de que suas especificações de aplicativos precisam ser simplificadas?

Muitas vezes me deparo com a situação em que um novo cliente chega a mim com um aplicativo que possui literalmente centenas de recursos desnecessários e é bastante claro que as coisas precisam ser drasticamente simplificadas para que o projeto tenha alguma chance de sucesso. Como convencer o cliente a adotar uma abordagem mais mínima do produto viável (MVP) e simplificar?

editar:

Portanto, a principal resposta atual é fornecer ao cliente uma estimativa de tempo / custo para o grande aplicativo. Não gosto muito dessa resposta porque ela não resolve o problema real dessa situação. E isso é - é uma prática ruim especificar um aplicativo massivo e tentar construí-lo desde o início. Eu me sinto muito mais confortável inicialmente construindo uma base MVP pequena e simples. E adicionando pequenos recursos a essa base, um por um. Então, como convencer o cliente a abordar a criação de software dessa maneira?

Ao estimar quanto dinheiro / tempo custará para executar centenas de recursos com alta qualidade. Muito, muito poucos clientes colocam seu dinheiro onde está a boca.

Duas palavras: Histórias de usuários.

Aprendi que a maneira mais rápida de ajudar um cliente a obter uma dica é fazer com que eles me contem uma história de usuário para cada recurso ou página que eles desejam. Várias coisas acontecem, incluindo:

1. Eles precisam pensar no que diabos a página / recurso deve fazer.
2. À medida que você pede mais e mais detalhes ("e então? ... e depois? ..."), eles começam a entender que tudo não vai surgir com o Magic Space Monkeys ™ voando e fazendo no fim de semana.
3. Eles se tornam verdadeiros parceiros no processo de criação. O que significa que eles entenderão por que mudar de idéia sobre algo que já está 80% completo causará a) atraso no cronograma eb) aumento de custo.

Seriamente. Histórias de usuários pelos proprietários é uma das melhores ferramentas que conheço para trazer pelo menos alguma sanidade ao processo.

Ao discutir o aspecto do custo e do tempo de produção, solicite uma classificação dos requisitos ("deve ter", "deveria ter" e "é bom ter") para que o conjunto mínimo viável de recursos essenciais do produto seja "must have" na versão 1 e, em seguida, coloque o restante dos requisitos em conjuntos de pendências que podem ser realizadas como sprints subsequentes à primeira versão. Esperamos que os itens não essenciais "agradáveis ​​de ter" estejam na parte de trás do pacote e, quando você chegar a esses sprints, novos itens mais essenciais (da experiência real com o produto) terão flutuado para o topo.

O cliente deve entender que você está considerando o custo dos negócios e a importância de obter o produto rapidamente e não está descartando diretamente o "prazer de ter" colocando-os na lista de pendências.

Editar para responder à edição do OP: para convencer o cliente por que é uma boa ideia lançar cedo um produto mínimo viável, explique que, até que o produto seja usado por usuários reais, é difícil saber se será bem-sucedido (principalmente em termos de usabilidade). Se o cliente hesitar em lançar um produto antecipado para toda a sua base de usuários, recomende fazer uma "versão beta limitada" onde esteja disponível apenas para um subconjunto direcionado de seus clientes. Diga-lhes que o outro lado dessa abordagem é um ciclo de desenvolvimento longo e caro, com uma determinação tardia de que o produto não pode ser utilizado. 37 A Signals produziu algumas boas referências sobre isso: Getting Real and Reework . O Getting Real está disponível na web gratuitamente.

A principal causa de sua frustração com a situação é provavelmente a percepção e os termos enganosos / errados usados ​​pelo cliente. O cliente geralmente não vem com uma lista de requisitos , mas uma lista de desejos de tudo o que eles pensam que pode ser útil para eles. Esses não são todos os requisitos, porque o cliente ainda não gastou tempo para realmente pensar se cada recurso é realmente necessário .

Isso nem sempre é necessariamente um problema

Se o seu cliente tem o dinheiro para todos esses recursos e está disposto a participar, e você realmente não se importa em resolver os problemas reais e reais que o cliente possui, esse pode ser um projeto muito lucrativo. Isso acontece, muito, muito raramente, e para a maioria dos desenvolvedores é um trabalho de matar a alma, porque você pode sentir antecipadamente que o projeto não será bem-sucedido para o cliente no final (mesmo que seja financeiramente bem-sucedido para você como desenvolvedor). Também é de alto risco, porque é provável que você acabe com um projeto de custo fixo com muita incerteza, e é realmente um problema avaliar incorretamente o risco em grandes projetos.

E se for um problema?

Vamos supor que você não esteja nessa situação rara. Nesse caso, você desejará abordar as duas principais deficiências da lista de desejos, conforme indicado:

1. É improvável que o cliente tenha uma idéia correta dos custos do desenvolvimento de uma lista tão grande de requisitos; portanto, é improvável que você obtenha o contrato pela quantidade de dinheiro que realmente precisa.
2. É improvável que esta lista de desejos descreva de forma precisa e sucinta o verdadeiro problema que o cliente tem e deseja resolver.

Na minha experiência, você precisa abordar 2 para corrigir 1. Pesquisar detalhadamente o problema real significa que você, o desenvolvedor, agora tem a entrada necessária para dar saltos criativos na solução do problema de uma maneira que o próprio cliente nunca pensou. É provável que essas soluções sejam muito mais baratas e rápidas do que a implementação da lista de desejos completa.

como você conserta aquilo?
Como Matthew Flynn diz em sua resposta - comece fazendo o cliente priorizar os requisitos. Isso nem sempre é fácil, mas force-os a fazê-lo. Se necessário, use a frase "Se alguém apontasse uma arma para sua cabeça, qual único requisito você manteria?". Você encontrará frequentemente durante esse processo que o cliente realmente não tem uma ideia muito clara do que os requisitos individuais significam. Nesse caso, faça o que Peter Rowell sugere e faça com que o cliente trabalhe nas Histórias de Usuários. Você e o cliente começarão a entender o problema e os requisitos muito melhor e, em seguida, poderá voltar à priorização. Repita essas etapas quantas vezes for necessário até que você se sinta à vontade e saiba o suficiente para resolver o problema do cliente .

Como isso responde à questão do desenvolvimento de uma solução? Depois de ter uma lista priorizada de requisitos, você tem a entrada necessária para sugerir um processo de desenvolvimento incremental ao seu cliente. Você não precisa chamá-lo de Agile, mas pode sugerir a quebra do contrato em partes menores para cada requisito (ou conjunto indivisível de requisitos) e entregá-los um por um com validação pelo cliente. Ou você pode usar todos os recursos disponíveis online e offline para convencer o cliente de que é do seu interesse cooperar em um dos estilos de desenvolvimento Agile. Em qualquer caso, você pode fornecer sua proposta de contrato / projeto de uma forma que sugira claramente esses blocos de requisitos em ordem de prioridade, cada um com seu próprio custo e conclusão. Segure essa cenoura na frente do cliente,

Primeiro, tentaria explicar que seus requisitos não são realistas e apresentá-los com um conjunto de requisitos contrários. Explique que isso resolverá o problema deles de maneira mais simples e rápida, com menos custos e riscos. Não tente fazer disso uma discussão técnica, o cliente não se importa com isso. O cliente se preocupa em obter um bom produto a tempo, resolvendo seu caso de negócios. Se o cliente não se mover, aceite o contrato e faça o trabalho ou rejeite e explique ao cliente por que você não pode assumir a responsabilidade pelo projeto neste formulário.

Semelhante ao que as outras pessoas sugeriram, mas um pouco diferente, eu sugeriria que tudo o que o cliente pode ser válido, mas ele precisa PRIORIZAR. Qual item precisa ser feito primeiro. Qual item precisa ser feito em segundo. Mais importante, se você ficar sem tempo, quais itens serão menos prejudiciais para não ter. Priorize cada item de 1 a 732 (ou o que for) e conclua-os nessa ordem.

Um exemplo histórico de um aplicativo que ficou acima do orçamento e atrasado devido a requisitos excessivos é o Arquivo Virtual de Casos do FBI. O objetivo era substituir várias dezenas de aplicativos existentes, e todos tinham que trabalhar completamente, ao mesmo tempo, na troca. O projeto foi finalmente cancelado. O que teria sido bem-sucedido foi arquitetar uma estrutura e substituir cada vez mais aplicativos individuais no novo sistema. Em vez disso, a política e as lutas internas levam todos os interessados ​​a declarar que o aplicativo é o mais importante, e todos usam suas especificações com "deve ter" de todos os recursos que desejam adicionar ao aplicativo existente. No final, o volume de solicitações de mudança escritas a cada dia excedia a quantidade de código realmente escrita a cada dia.

Eu vi o trabalho "Eu tenho que ter tudo" em 2 casos. Em um, o grande cliente financeiro (que usa cascata de todas as coisas) tinha 40 sistemas diferentes (nossa empresa fez um dos 40) ser substituídos e operacionalizados de uma só vez. Teste de integração e comunicação foram grandes problemas. Minha estimativa é que eles gastaram cerca de US $ 100 mil / dia em chamadas em conferência (quando você conta a taxa de cobrança de todos nas chamadas). Nos dois casos, foram necessários fortes negociadores para elaborar uma lista do que seria entregue e depois pregar os pés de todos no chão. Não houve movimentação de postes, nem renegociação. Ambos os trabalhos foram pontuais e dentro do prazo. Um estava acima do orçamento, o outro estava dentro do orçamento. Para isso, você precisa de gerentes de projeto muito bons que sabem o que suas equipes podem oferecer (o tipo de pessoa que pode dizer que o recurso Q leva 3).

Na falta de excelentes PMs, negociadores e métricas, aconselho empurrar o cliente para entregas incrementais. Se eles ainda quiserem todo o tijolo de ouro de uma só vez, poderão ser melhor atendidos, ajudando-os a encontrar outra consultoria. Às vezes, a melhor resposta é "não podemos ajudá-lo".

Resposta curta: eu ouvia meu cliente e encontrava o caminho do meio com ele.

Eu sugeriria ouvir o cliente e, dependendo do orçamento e do tempo, dividir o projeto em fases (release, release2, etc.).

Em seguida, você pode continuar a estimativa de cada fase da entrega, orçamento e priorização dos recursos necessários que o aplicativo deve entregar.

Assim, definir o escopo do trabalho e dos resultados finais é o caminho a seguir :)

Como outras respostas indicam, a priorização é muito importante. Uma maneira prática de fazer isso é através do método MoSCoW . Mas você pode começar dividindo a lista inteira, caso contrário, a própria lista de recursos fornecerá a você (ou ao seu cliente) problemas de compreensão :)

Além disso, você tem o problema de analisar o problema como um todo. Provavelmente, você pode resolver isso sentado com seu cliente e seguindo as seguintes etapas:

• Acesse globalmente os recursos e destile categorias deles
• Priorize (usando MoSCoW) as categorias e talvez defina uma hierarquia (uma categoria básica com recursos padrão, categorias para assuntos principais, categorias para variações específicas dos assuntos principais). Isso pode alterar as categorias definidas na etapa anterior (graças a novas informações).
• Percorra cada recurso um por um e atribua-os a uma categoria
• Priorize (usando o MoSCoW) os itens nas principais categorias x.

Isso fornecerá uma visão agradável e condensada de cima para baixo dos recursos solicitados e um guidão para definir diferentes iterações para começar com uma base e estendê-lo com outros recursos.