Um programador deve "pensar" no cliente?

Cheguei ao ponto em que odeio a coleta de requisitos. O cliente é muito vago para o seu próprio bem. Em um ambiente ágil, onde podemos mostrar ao cliente um trabalho completo, não é tão ruim, pois podemos fazer pequenas correções / atualizações regulares na funcionalidade.

Em um ambiente "tipo cascata" (primeiro requisitos, produto quase completo a seguir), as coisas podem ficar feias. Esse tipo de ambiente me levou a questionar constantemente os requisitos. Por exemplo, o cliente deseja "converter automaticamente a entrada no número 1" (referindo-se a um Qty em um pedido). Mas o que eles não pensam é que "entrada" poderia ser um tipo simples. Um "x" em uma caixa de texto pode ser um "woops", não quero um desses produtos "creme dental". Mas há tanta coisa no ar com requisitos que eu poderia suportar e corrigir por horas a fio destruindo o que eles queriam. Isso simplesmente não é saudável.

Trabalhando para uma corporação, eu poderia tentar ajustar a cultura para se ajustar ao modelo ágil que nos ajudaria (sem trabalho pequeno, acima da minha nota de pagamento). Ou varrer detalhes feios para debaixo do tapete e esperar o melhor. Talvez meu cliente esteja tentando se aproximar demais do código?

Como alguém lida com o problema de "pensar pelo cliente" sem irritá-lo com muitas perguntas?

Na maioria dos casos, o cliente não está ciente do que mais pode ser feito. Eles nunca tiveram que descrever o que precisam de uma maneira que a torne inequívoca para nós. Na mente deles, está claro. Mesmo o fato de estarem pensando em converter a entrada do usuário no número 1 está realmente indo além do modo como estão acostumados a pensar.

É realmente como deveria ser. Se eles realmente sabem como descrever exatamente o que querem, não precisam que escrevamos para eles. Como resultado, nossa responsabilidade é ajudá-los no processo. O processo exige que as decisões sejam tomadas, portanto elas também precisam de nossas recomendações para facilitar o processo de decisão.

Portanto, deixe o cliente ser vago e conversar em alto nível. Eles conhecem seus negócios, e é nisso que eles são bons (espero, ou eles não poderão pagar suas contas ...). Pegue o que eles falaram e pense por um tempo. Eventualmente, você obtém ótimas idéias para obter o que elas querem e precisam, enquanto asseguram que o que você precisa é testável e consistente.

Eu recomendo trabalhar em pedaços. Quando você se encontrar com o cliente, tenha um conjunto de requisitos relacionados entre si e explique como você pretende fazer o que ele deseja. Explique também por que você fez as escolhas que fez. O cliente pode analisar o que você forneceu e ajustá-lo. Se você receber uma resposta como "Nunca pensei nisso, mas isso realmente ajudaria", você sabe que sabe como o cliente pensa. NOTA: como isso não é uma característica, está selecionando os recursos certos para melhor atender ao problema comercial que o cliente possui.

Se você tem algo que parece contradizer o que o cliente lhe disse explicitamente, é hora de explicar o porquê. Você precisará trazer à tona alguns problemas que o cliente nunca imaginou e como sua alternativa ainda oferece a eles o que eles querem / precisam, mas também evita esses problemas em potencial. Você pode receber um pequeno empurrão, mas isso também aumenta a confiança do cliente, à medida que eles percebem que você está tentando oferecer a eles um produto que eles realmente podem usar. Se eles dão alguma resposta, isso os obriga a explicar por que eles queriam algo de uma certa maneira. Isso ajuda você a entender melhor seu cliente e adaptar os requisitos conforme necessário.

A maneira mais rápida de desgastar seu cliente é fazer todas as pequenas perguntas uma após a outra. Você deseja planejar e agendar uma série de reuniões para revisar sua abordagem. Desde que você possua os requisitos técnicos (o que sua equipe usa para criar o produto) e o seu cliente possua os requisitos de negócios, e você possa relacioná-los, você terá uma maneira de preencher essa lacuna.

Se você está 'irritando-os' com muitas perguntas, consiga um cliente melhor.

Os clientes não sabem o que querem. Eles não necessariamente reconhecerão sua solução quando a virem. Isso é um problema e esse é o trabalho que você está resolvendo: traduzir os requisitos deles em algo que pode ser entregue como um pacote de software.

Para fazer isso, você precisa aprender sobre o que está fazendo. Você não deve estar perguntando "o que deve acontecer quando eles colocam um número em uma caixa de texto", você deve estar perguntando "por que esse número é importante? Para que ele é usado?" Peça que eles lhe ensinem como eles fazem o trabalho deles. E não ouça o que eles dizem, porque não sabem o que querem, mas observe o que fazem e para onde vão os olhos .

Leia isto para obter mais informações: http://www.joelonsoftware.com/articles/fog0000000356.html

Supondo que você seja um funcionário de algum tipo de empresa, parece que você precisa de um bom analista de negócios para ajudar a mediar esses detalhes entre o cliente e você. Acho que você não tem influência suficiente para que isso aconteça. Portanto, meu próximo melhor conselho seria aprender mais sobre o domínio em que seus clientes estão trabalhando. Ao entender os negócios e os processos com os quais eles trabalham, você ' Terei uma idéia melhor do que eles realmente querem, apesar da maneira vaga e possivelmente errada de descrevê-lo. Isso permite analisar o que eles pediram e você pode voltar mais tarde em uma reunião separada com uma interpretação do que eles querem e uma possível sugestão para dar a eles o que realmente querem. Se você trabalha consistentemente com os mesmos clientes, você '

Se isso parecer muito difícil, doloroso, extremamente desagradável ou irrealista, meu conselho final seria começar a procurar um novo emprego em algum lugar onde eles tenham analistas de negócios, porque isso não ficará mais fácil para você sem se esforçar.

Se você está reunindo requisitos, é seu trabalho fazer essas perguntas.

Sim, o cliente pode ficar irritado, mas, nesse caso, você precisa explicar por que está fazendo "todas essas perguntas". Você precisa entender os negócios deles antes de poder escrever o código que os automatizará. O argumento decisivo seria que, se não o fizesse, eles gastariam muito dinheiro desenvolvendo um sistema que realmente não faz o que quer.

O efeito colateral disso é que você deve ajudar o cliente a refinar seus requisitos.

Isso se aplica se você estiver executando o Big Design Up Front ou Agile.

Infelizmente, é seu trabalho pensar no cliente se ele não pode ou não faz isso sozinho.

Eu tive os dois resultados possíveis:

• o cliente está feliz por estar pensando no que ele diz, sente que está nas mãos certas ou

• o cliente fica irritado porque você o força a pensar novamente em seus requisitos. Mas esse tipo de cliente ficará irritado com você de qualquer maneira, mais cedo ou mais tarde. Ele certamente ficará muito irritado se descobrir tarde demais que você não pensou nele no começo. Eu diria: evite esse tipo de cliente, se possível :-)

Um RAD (Rapid Application Development) lida bem com esse problema.

Comece a "pensar no cliente" criando uma interface do usuário não funcional muito grosseira para o programa, com base no seu melhor palpite sobre o que ele precisa. Em seguida, mostre a eles e trabalhe iterativamente até atender às necessidades reais deles.

Não é que eles não saibam o que querem. É que eles não sabem o que querem até vê-lo e, às vezes, você pode determinar o que quer por exclusão. Ou seja, mostrando a eles algo que NÃO querem e prestando atenção em como o criticam.

O principal problema com o BFUD (design da Big Up Front) é que isola o desenvolvedor da culpa, forçando o cliente a assinar um contrato que descreve explicitamente o que ele receberá. E, infelizmente, isso é feito no momento em que ninguém no projeto tem uma boa idéia do que é realmente necessário. No final, isso faz com que o cliente aceite o que você criou porque ele assinou, mas de má vontade.

Se o cliente não estiver satisfeito com a entrega, é apenas uma vitória pirânica.

O trabalho do cliente é transmitir a você o que eles precisam. Seu trabalho é entender o que eles precisam o suficiente para poder programar o que precisam. Uma pergunta óbvia para a questão de alterar todas as entradas para uma seria dizer "Por que você deseja alterar todas as entradas para 1?" Em seguida, o cliente pode explicar o raciocínio por trás dele, para que você entenda a necessidade e possa fornecer não necessariamente o que eles pedem, mas o que eles precisam. Se você está confiante de que sabe o que eles precisam, não acho que você precise "corrigir" a linha de pensamento deles. Eles vão usar o produto e a coisa "Oh! Isso é perfeito". Mas, a menos que você esteja confiante de que sabe o que eles precisam, explique o que está pensando e resolva o problema com o cliente. Infelizmente existe ' Não há como executar essa parte do processo sem muita comunicação, o que envolve uma escuta real das duas partes. Tenha cuidado para ficar irritado com a situação e dizer coisas que você pode ou não querer realmente dizer.

Sinceramente: a menos que seja uma "grande funcionalidade", faça com que a pessoa com mais conhecimento de domínio adivinhe o que deve acontecer e implemente isso. Isso será aprofundado nos testes de aceitação - e é para isso que serve.