Você é desenvolvedor, e recebeu uma especificação para trabalhar, e enquanto está codificando percebe que algum detalhe passou despercebido durante a análise do requisito. Ou seja, você não consegue prosseguir enquanto não esclarecer este detalhe, esta dúvida. O que você faz?
Normalmente você vai procurar o analista ou a pessoa responsável por aquela especificação (ou pelo menos deveria fazer isto), e vai questionar esta pessoa a respeito da dúvida que te impede de avançar no código com a certeza de que estás seguindo na direção correta.
Quando isto ocorre, você espera que o analista saiba responder suas dúvidas e te conduza de volta ao caminho correto a ser seguido. O problema é que as pessoas não sabem tudo, você não sabe tudo, e o seu analista também não sabe. É normal que em alguns casos o analista não consiga te responder, pelo menos não de forma imediata. E aí, o que fazer?
Quando as dúvidas surgem e ninguém da equipe sabe o que fazer, a melhor decisão é falar com o cliente, seja através de uma reunião, telefone, skype, e-mail, ou qualquer outra forma de comunicação. Mas precisamos falar com o cliente!
Ficar praticando tentativa/erro/tentativa/erro, ou adivinhação são péssimas alternativas, você até pode acertar de vez em quando, mas na média, esta atitude vai gerar retrabalho lá na frente, além de frustrar o cliente e posteriormente frustrar a equipe.
Mas sabemos que nem sempre o cliente estará disponível, mesmo que o cliente esteja fisicamente próximo de você e sua equipe, ele pode simplesmente não estar livre ou interessado em te atender, ou seja, ele não quer se envolver, até porque ele pagou uma boa grana para sua empresa fazer o software dele, e ele espera que você e sua equipe saibam como fazer isto.
Este cenário é o que chamamos de cliente distante, e acredite, projetos com cliente distante tem uma grande tendência de serem entregues com atraso, ou estourarem o orçamento, ou frustrarem o cliente entregando funcionalidades que não atendem suas expectativas, ou todas as alternativas anteriores (o que é um fracasso tremendo).
Mas como evitar que isto ocorra? Aproximando o cliente desde o início do projeto e deixando bem claro para ele que a qualquer momento ele poderá ser acionado para tirar dúvidas, e também deixar claro que a cada funcionalidade ele poderá ser chamado para realizar uma validação, ou seja, dar um aceite de que aquele recurso ficou de acordo com o que ele esperava, ou nos indicar o que precisa ser ajustado para atendê-lo, caso o resultado não tenha ficado de acordo com suas expectativas.
Mas tome cuidado, pedir o aceite do cliente não significa pedir para o cliente testar. O teste do software é sua responsabilidade, e acredite em mim, os clientes não gostam de testar software, e principalmente, os clientes não ficam muito felizes quando encontram bugs.
Quando você pede para o cliente validar a funcionalidade, você está na verdade buscando feedback. Você está buscando confirmar que aquela funcionalidade que acabou de sair do forno está de acordo com a expectativa do seu cliente. Você está buscando segurança para continuar o desenvolvimento do projeto, tendo certeza que os passos dados até agora foram realizados seguindo na direção correta.
E se o cliente odiar a funcionalidade que você entregou, dizendo que está totalmente fora do que ele esperava? Ótimo! Você conseguiu falhar rápido, e terá tempo para corrigir, adaptar ou até mesmo refazer a funcionalidade, conseguindo assim finalmente entregar algo de valor para seu cliente. Imagine como seria desagradável se somente no final do projeto você descobrisse que algumas (ou várias) funcionalidades não ficaram de acordo com a expectativa do seu cliente. Seria terrível!
* Rafael Helm é Agile Coach, Instrutor e Consultor na Wildtech.