Somos terríveis em conversação
Muitas vezes ao se lidar com projetos com multiplas pessoas e equipes precisamos ficar constantemente nos comunicando entre pesssoas e eficiência na comunicação é primordial.
Apenas pergunte
Porém, muitas das vezes a comunicação sai tão chula quanto:
- Pessoa A: Oiiii!
- Pessoa B: Eae
- Pessoa A: Posso te perguntar uma coisa?
- Pessoa B: Pergunte?
- Pessoa A: Ocorreu um erro no servidor, poderia resolver?
- Pessoa B: Claro
Viu que coisa chula, e se levarmos em conta que cada mensagem levou pelo menos 1 minuto para ser notificada e uns 5 para ser realmente lida perdemos toda a eficiência. No espirito de aumentar a comunicatividade foi criada uma Convenção da comunicação se é que eu posso falar assim chamada Dont Ask to Ask.
A comunicação entre Pessoa A e Pessoa B poderia ser melhor reduzida a:
+ Pessoa A: Bom dia! Ocorreu um erro {especifique o erro} no servidor, poderia resolver?
+ Pessoa B: Claro, estarei por aí antes das 14h
Comunicação feita, clara, e assertiva.
Outro Exemplo de comunicação chula:
- Pessoa A: Oi, você está ocupado?
- Pessoa B: Não muito, o que você precisa?
- Pessoa A: Você poderia me enviar o relatório da semana passada?
- Pessoa B: Claro, vou procurar e te envio.
Poderia ser reescrita como
+ Pessoa A: Olá! Você poderia me enviar o relatório da semana passada? Preciso dele para a reunião das 15h. Obrigado!
+ Pessoa B: Claro, vou enviar em alguns minutos.
Veja que a comunicação não ficou mais eficiente por que você enviou menos firula, mas, ficou mais eficiente porque você enviou as informações necessárias de forma que eles sejam encaminhados todos ao mesmo tempo.
Problema XY
Existe outros problemas comunicativos com o problema do XY que é o pior problema que um programador enfrenta.
Basicamente esse problema funciona assim:
O problema XY pergunta sobre sua tentativa de solução, e não sobre seu problema real.
Isto leva a enormes quantidades de desperdício de tempo e energia, tanto por parte das pessoas que pedem ajuda, como por parte daqueles que prestam ajuda.
O usuário deseja fazer X.
O usuário não sabe como fazer X, mas acha que pode encontrar uma solução se conseguir fazer Y.
O usuário também não sabe fazer Y.
O usuário pede ajuda para Y.
Outros tentam ajudar o usuário com Y, mas ficam confusos porque Y parece um problema estranho
para se querer resolver.
Depois de muita interação e perda de tempo, finalmente fica claro que o usuário realmente quer ajuda com X, e que Y nem era uma solução adequada para X.
O problema ocorre quando as pessoas ficam presas naquilo que acreditam ser a solução e não conseguem recuar e explicar o problema por completo.
Veja que normalmente esse é um problema bem comum de se encontrar em nossa área e a solução é bem simples, apenas dê um contexto mais amplo para sua pergunta:
Veja o que normalmente ocorre
- <bob> Como posso repetir os três últimos caracteres de um nome de arquivo?
- <feline> Se estiverem em uma variável: echo ${foo: -3}
- <feline> Por que 3 caracteres? O que você realmente quer?
- <feline> Você quer a extensão?
- <bob> Sim.
- <feline> Não há garantia de que todo nome de arquivo terá uma extensão de três letras.
- <feline> então pegar cegamente três caracteres não resolve o problema.
- <feline> echo ${foo##*.}
Imagine o quanto tempo teria durado a conversa se fosse assim
+ <bob> Como posso pegar a extensão de um arquivo?
+ <feline> echo ${foo##*.}
Veja que a comunicação é mais rápida e mais assertiva quando contruídas dessa forma. Sendo solucionadores de problemas devemos escrever o mínimo que consegue resolver o problema na regra dos 20/80. Vinte porcento do que escrevo resolve oitenta porcento do que preciso.
Existem diversas convenções de comunicação mas, sinceramente essas duas são as que mais fico me monitorando para escrever melhor afinal somente com boa comunicação conseguimos resolver nossos problemas corretamente.
Deixo aqui em baixo dois posts que devem ajudar a melhor a comunicação entre pessoas:
Ótimo artigo, eu insisto com meus amigos e familiares constantemente para aplicar essas medidas para serem mais eficientes. e em comunidades online, pessoas que pedem ajuda mas já não descrevem o problema ou que focam em Y quando o problema real é X é uma praga endêmica. Vou salvar esse post para enviar para colegas dev que não sabem inglês já que pode ajudar eles a entender.
Olá KitSuni!! (kkk), beleza!? Em algumas culturas regionais ou organizacionais uma comunicação assertiva pode ser entendida como grosseria. Por exemplo, quando numa única frase já comprimento e levanto o problema algumas pessoas podem entender que não dei o "timing" entre o início do diálogo e a solução dos problemas. Não que eu não goste de uma comunicação assertiva, mas essa só consigo com meus colegas mais próximos; pessoal de outros departamentos parecem demandar um rodeio maior.