Dica de comunicação

Hoje resolvi falar sobre comunicação. Há inúmeras estatísticas que citam a comunicação como uma das principais vilãs nos fracassos de projetos diversos, inclusive os de engenharia de software.
É evidente que comunicação é um tema amplo e, por isso, vou focar num ponto, que vou chamar de gap de comunicação.

O gap de comunicação, nesse contexto, é a diferença entre o que o emissor da mensagem quis dizer e o que o receptor efetivamente entendeu.

Imagine a fase de elicitação (levantamento) de requisitos. Independente do processo adotado ou técnica empregada, todo software precisa partir de requisitos (ou histórias de usuário, ou use cases, ou o que quer que seja). Cada stakeholder (envolvido ou afetado) que participar dessa etapa irá se comunicar com o time técnico e poderão acontecer várias coisas, a saber:

  • A pessoa pode pensar alguma coisa, mas ter dificuldade de se expressar e comunicar algo diferente;
  • Haver um pensamento complexo, mas transmitir uma explicação simplista, insuficiente;
  • Ser usado um vocabulário técnico ou específico, não compreensível para o receptor da mensagem;
  • A pessoa que estiver recebendo a mensagem pode deixar escapar detalhes significativos, por ter sido negligente ou mesmo sem querer;
  • O receptor ter uma interpretação completamente diferente do que foi pensado pelo transmissor;
  • Algum ruído na comunicação, ou uma combinação das opções anteriores.
Enfim, gaps de comunicação ocorrem a todo momento, em diversas situações. No caso específico dele acontecer no momento da definição dos requisitos, pode acontecer do software construído não ser o solicitado, ou ter características muito diferentes do esperado.

Como é mais barato resolver o problema na fase em que o mesmo é gerado, não podemos pensar em arquitetar, ou criar planos de testes, ou mesmo codificar, sem ter certeza do requisito. Quer uma dica? Dê feedback sobre a interpretação do requisito. Depois que você conversou com o seu cliente a respeito dos requisitos, apresente para ele o que você entendeu. Explique, com suas palavras, o que você conseguiu captar como necessidades do cliente e suas motivações. Nesse processo de tentar reproduzir a essência da mensagem, ainda que com palavras diferentes, é possível captar gaps. Vão surgir coisas do tipo "você entendeu errado", "não foi isso que eu quis dizer", "acho que não me expressei bem", "esse ponto está OK, mas aquele outro precisamos rever"...

Uma característica interessante aqui é o desenvolvimento da empatia, que é colocar-se no lugar do outro. Quando o time técnico tenta reproduzir a mensagem original, está justamente se colocando no lugar do cliente, e exercitando cenários e possibilidades. Além de ajudar na comunicação, fomenta ideias. Claro que essa técnica não serve só para software, mas para qualquer comunicação. Que tal?

Provocações finais

Será que eu fui claro o suficiente nesse artigo? Você conseguiria me explicar o que eu sugeri? Aliás, o que eu sugeri?
Como anda a comunicação na sua empresa, no seu departamento e/ou no seu time?
Você quer ser entendido? Você observa sua audiência para selecionar seu vocabulário e forma de comunicação?

Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Requisitos conflitantes e dilemas no projeto de software

Levantamento de requisitos