Trabalhando com clientes que não sabem o que querem

Recentemente, iniciei um trabalho que me faz trabalhar em um sistema existente. Requer ajustes e atualizações, bem como novo código. Eu já fiz vários projetos de manutenção / recurso adicionando agora, e vários deles acabaram sendo significativamente diferentes do que foi realmente solicitado. Portanto, tive que programar o item várias vezes para chegar ao local desejado pelo solicitante.

Agora, não me importo de reprogramar o recurso se é isso que precisa ser feito. No entanto, gostaria de diminuir o tempo de resposta dos meus projetos. O gargalo parece estar na percepção do solicitante sobre o que precisa ser feito. Você tem alguma idéia do que eu poderia fazer para descobrir o que o solicitante precisa mais rapidamente?

Alguns conselhos:

• Escute problemas, não soluções . Muitos clientes gostam de lhe dizer como resolver seus problemas. Não dê ouvidos a eles. Você é o programador e é seu trabalho encontrar soluções para os problemas. Em vez disso, ouça os problemas que os clientes estão enfrentando e descubra a melhor maneira de resolvê-los. como outros já disseram, os clientes realmente não sabem o que querem, às vezes você precisa mostrá-lo primeiro.

• Faça perguntas . Quando terminar de fazer perguntas, faça mais algumas. Os clientes raramente são apresentados com detalhes, pois realmente não pensam nisso. A única maneira de obter as informações necessárias é extraí-las delas.

• Faça as coisas por escrito Dependendo da situação do cliente, isso pode ser realmente importante mais tarde, quando eles começarem a reclamar sobre como o que você entregou "não é o que eles pediram". e, se nada mais, escrever especificações detalhadas pode ajudar a garantir que você tenha todas as informações necessárias e a esclarecer ambiguidades entre você e o cliente.

• A comunicação é fundamental . não basta falar com o cliente, obter informações, digitar algum código e não conversar com ele até que esteja pronto. Sempre mantenha contato com o cliente. Faça perguntas durante todo o processo. mostre o progresso que você fez e obtenha feedback. Isso facilitará a vida de todos a longo prazo.

Praticamente qualquer livro de auto-ajuda que você capta sobre comunicação oferece uma variação disso:

• Procure primeiro entender, depois entender

Isso vem do livro dos 7 hábitos, mas são todas algumas variações do método de " escuta ativa ". O objetivo não é apenas entender, mas comunicar a eles que você entendeu.

Depois que penso ter uma boa idéia do que eles precisam (fique longe do que eles querem, principalmente se começarem a descrever os detalhes da implementação - esse é o seu trabalho, não o deles), dou-lhes exemplos de histórias de várias pessoas que usam o sistema e ver se que brinca com eles.

Então eu implemento isso, esperando que, uma vez que eles vejam o recurso, eles realmente percebam que não é exatamente isso que eles querem. Mantenha tudo flexível. A única constante é a mudança. Normalmente, trabalho com a maioria das arestas ásperas após a segunda atualização rápida após a inicial, mas sempre acho que estou me aproximando assintoticamente de algum ideal que nunca consigo alcançar. Eventualmente, você precisa deixar as coisas sem importância passarem para metas de maior valor.

Eu sinto sua dor....

A má notícia é: dependendo exatamente de que tipo de clientes você está lidando, isso pode ser normal.

Um problema geral comum é basicamente que os clientes não sabem o que querem . Eles geralmente sabem o que desejam ser alcançados, em termos de uma meta de negócios, mas geralmente não têm idéia de como deve ser a aparência da solução de software. Portanto, em muitos casos, você se encontrará nesse ciclo iterativo, em que um projeto alterna cinco vezes mais do que a estimativa inicial, porque o cliente continua mudando de idéia e deseja que a solução seja alterada e alterada novamente. E sim, não é incomum o resultado final se transformar em algo completamente diferente do que o objetivo inicial parecia.

Eu tive um exemplo épico disso acontecer alguns anos atrás - um projeto que inicialmente levou 10 semanas para codificar se transformou em uma rotina de re-iteração de 15 meses. Nesse caso, era principalmente porque diferentes gerentes e departamentos da empresa cliente queriam coisas diferentes, então eles continuavam enviando o trabalho de volta, para serem aprimorados e aprimorados (nosso software é baseado em assinatura e esse era um cliente importante, não havia uma pele financeira nas nossas costas - apenas um grande aborrecimento técnico).

Então, basicamente, meu conselho é este:

Se é assim que o seu setor em particular e esses clientes são (esse é um grande FI), basta se acostumar. Pense nisso como um trabalho ágil, orientado à manutenção (é assim que meu show atual é, mais ou menos). :)

Se não é assim que as coisas devem ser feitas, e você está sendo responsabilizado pelas longas reviravoltas, fale com seus chefes. Explique a eles que existem problemas de comunicação e que as especificações que chegam dos clientes não são claras o suficiente para você implementar a solução desejada. Você não quer se encontrar na situação em que está culpando por não dar aos clientes o que eles querem, se você não estiver obtendo todas as informações necessárias para dar o que eles querem.

Primeiro de tudo, você deve aceitar o fato de que os clientes realmente não sabem o que estão procurando até vê-lo. Eles podem dizer agora que precisam do recurso X. Mostre a eles o recurso X e perceberão que o que realmente precisam é do recurso Y ou de outra variação do recurso X.

Uma boa maneira de descobrir o que o cliente realmente deseja mais rapidamente é abraçar e seguir o Agile Manifesto , que se concentra na comunicação e na colaboração do cliente. Divida o ciclo de desenvolvimento em iterações e mostre ao cliente um protótipo do recurso em cada extremidade da iteração. Dessa forma, você receberá feedback imediato e o alterará, de acordo com o feedback do cliente, sem ter que investir muito recurso no recurso. Dessa forma, você e o cliente ficarão felizes com o resultado do produto.

Tenho certeza de que a transição será difícil para sua equipe ou sua empresa, mas é uma das melhores maneiras de lidar com os requisitos que mudam rapidamente.

Muitas e muitas histórias semelhantes podem ser encontradas aqui . Eu nunca, mesmo trabalhando como subempreiteiro de outra empresa de desenvolvimento, encontrei um cliente que sabia exatamente o que queria.

Estou feliz o suficiente por trabalhar com alguém que tem uma ideia muito boa do que não quer ou deseja evitar. Normalmente, eu posso trabalhar a partir daí para algo que eles estão felizes.

Porém, minha experiência é principalmente no desenvolvimento de aplicativos / plataformas. Felizmente, raramente tenho que lidar com questões estéticas, como os designers da web.

Depois de muitas reescritas irritantes, agora opero o que chamo de divulgação completa.

Portanto, depois de discutir os requisitos e desejos dos clientes, sempre escreverei o que percebi que eles desejam e como proceder para cumprir esse requisito. Depois enviarei o que escrevi e esperarei até que respondam afirmativamente antes de começar o trabalho.

Se for um projeto grande (mais do que dizer 5 dias de trabalho), eu também protótipo. Isso lhes dá a chance de mudar de idéia sem grandes alterações de código no meu final.

Nem sempre funciona, mas pelo menos estou em uma posição em que o cliente sabe que são eles que estão mudando de idéia e não eu implementando incorretamente.