Executando verificação de segurança...
20
gugadeschamps
1 min de leitura ·

Como se comunicar eficazmente como desenvolvedor

O artigo da fonte apresenta o conceito de "aumentar a resolução" do que se escreve, com exemplos específicos para desenvolvedores, para melhorar a comunicação dentro de uma organização.

Eu tive que aprender isso na marra quando eu trabalhei em QA em uma empresa de tecnologia.

A gente tem a tendência natural de supor que a outra pessoa tem o total contexto do que a gente está falando, mas nem sempre isso é verdade.

Eu sempre utilizava uma ideia de "blocos de informação" quando me comunicava com desenvolvedores, em especial no Slack, mantendo uma thread para cada problema, o que dava a oportunidado extra de outras pessoas contribuírem para a discussão sabendo de todo o contexto.

Fonte: https://www.karlsutt.com/articles/communicating-effectively-as-a-developer/

Carregando publicação patrocinada...
8
lucasoliveiracruz

Comunicação é muito importante para o desenvolvedor e é uma das principais soft skills.

Sempre tive muita dificuldade em me comunicar e expressar o que queria dizer por mensagens, e em reuniões isso me afetava muito também. Mas uma coisa que percebi é que a prática e o hábito de tentar ser melhor entendido, ajuda demais nisso e com o tempo vamos melhorando no sentido da comunicação.

O artigo faz muito sentido e todos devs deveriam ler e aplicar no dia a dia, isso ajuda a ir longe.

Uma coisa que utilizo também, é não esperar que a pessoa responda para enviar o que preciso, por exemplo:

Lucas:
10h40 - Ola fulano, tudo bem?
Fulano:
12h40 - Ola Lucas, estou bem e vc?
Lucas:
12h45 - Estou bem, preciso que me libere um acesso, consegue me ajudar?
Fulano:
16h40 - Qual é a ferramenta?
Lucas:
16h45 - Github
Fulano:
17h10 - Qual é usuário?
Lucas:
17h15 - lucaslegal123
Fulano:
17h10 - liberado!
...

Nota-se que acabei perdendo muitas horas até que o Fulano pudesse responder para somente conseguir uma liberação de acesso ao Github.

Agora vamos para uma outra comunicação, sendo mais direto ao ponto:

Lucas:
10h40 - Ola fulano, tudo bem?
10h41 - Você poderia me liberar acesso ao repositório do projeto x no github?
10h41 - Meu usuário é lucaslegal123?
Fulano:
12h40 - Ola Lucas, estou bem e vc?
12h40 - Acesso liberado!

Já na primeira interação com Fulano, já conseguiu resolver meu problema de acesso.

E vocês, quais dicas tem para dar sobre comunicação em desenvolvimento??

4
MoonHawlk

Um ponto muito bem colocado e destacado, é o fator "humano", cumprimentar o colega, e gerar uma interação sadia. Por vezes vejo colegas tentarem ser diretos de mais, e acabarem parecendo arrogantes ou sendo mal interpretados devido a comentários "secos".

Certamente um pouco de gentileza e afeto, ajudam a agregar valor nas relações interpessoais e melhoram o ambiente de trabalho.

 Bom dia! 
 Como você tem passado? Você poderia me mandar X arquivos?
 
 Opa fulano, na correria?
 Você poderia me dar uma ajuda nesse topico? Tentei X, Y e Z, mas nada.

Pequenas ações podem gerar grandes mudanças, principalmente com o tempo e consistencia.

Forte abraço, MoonHawlk.

1
JCarvalho

Concordo, mas tenho ressalvas pois a abordagem pode ser direta a depender da interação, comportamento e até cultura dos membros da equipe. Por exemplo:
Trabalho full remoto numa equipe 100% brasileira e que fica logada no Teams durante todo o expediente (isso não é obrigatório, mas nossa interação é bem boa assim e quem quer ficar fora pra focar e não se incomodar com os side talks não é mal visto). Dito isso, durante o dia eu só chamo direto pela pessoa pra peguntar pois já não temos a "barreira" dessa formalidade. A comunicação do dia-a-dia se assemelha muito a do trabalho presencial.
E sobre a assertividade, minutos atrás mandei mensagem para a PO pra tirar uma dúvida assim:

"Fulana, tal tipo de público tem que ter o filtro xpto?
Perguntando pra saber se esse filtro deve aparecer pra esse tipo de público tal. Atualmente só mostra pro tipo de público xyz."

e ela acabou de me responder:
"não tem. Só no tipo de público xyz mesmo."

Esse tipo de comunicação assertiva eu aprendi e já praticava no trabalho antigo, de outra área não tech, e apostei muito na minha boa comunicação e xp "de dia-a-dia" quando migrei de área.

MAS, em contraponto a primeira parte dessa mensagem, se a pessoa trabalha com outras de cultura diferente ou mesmo num modelo com menos tempo logado com a equipe, essa comunicação mais formal e menos direta pra perguntar algo talvez seja essencial pra "quebrar o gelo" da distância.

3
6
filipedeschamps

Se você veio deste vídeo, queria aproveitar para expandir um pouco o motivo da comunicação ser uma grande parte do que eu conquistei na minha carreira.

A idéia principal é perceber que, dentro de uma empresa:

  1. Ou você aprende a se comunicar bem;
  2. Ou alguém vai precisar abstrair você (representar você).

E ter alguém abstraindo você é mais complexo do que parece, pois se você sempre precisar de um representante para comunicar as suas idéias e deixar claro o que deseja, você pode se colocar numa posição onde provavelmente será alongado demais a vinda de uma promoção ou o reconhecimento que você merece.

Isso não significa que comunicação deveria ser a sua única habilidade, pois isso faz a pessoa cair na cilada de ser o figurante de uma situação e não o protagonista, onde o figurante fala muito mais do que faz e geralmente não toma nenhuma decisão com risco real (apesar de ficar horas e horas falando das decisões das outras pessoas).

Ser um bom programador e ser uma pessoa que consegue se comunicar com clareza é uma das combinações mais poderosas que existem nos dias de hoje, tanto se você é funcionário de uma empresa, quanto se você está montando o seu próprio negócio, pois ambos tem o poder (e o dever) de se comunicar e entender os clientes.

Então fica como dica: experimente não deixar outras pessoas se comunicarem por você. De alguma forma (que só você vai descobrir como fazer), reduza o circuito de comunicação entre você e as outras pessoas e você vai começar a ver coisas interessantes acontecendo (para o bem e para o mal).

1
p3drao

Sobre o vídeo, no exemplo dos comentários em PRs: Dentro de um time que tem x devs junior/pleno para 1 sênior, a prática de comentar "mastigadinho", por parte do sênior, não cria brechas para o resto do time ficar preguiçoso?

De repente um dev sentir um "estalo" e pensar: Eu posso subir PRs cada vez mais desleixados ou incorretos e sempre vou ter alguém para corrigir, daí vai ser copiar e colar.

Quando acontece comigo eu acho excelente porque paro momentâneamente de me preocupar com a implementação e passo a tentar entender porque a solução proposta é preferível a que foi implementada. Mas gostaria de ter percepção dessa prática vinda de dentro de outros times.

1
arcbueno

Na verdade, creio que seja dever do sênior como lider de corrigir seus juniores e exigir que eles melhorem nesse quesito. Se um dev sobe 10 PRs e desde o 3o o sênior ta pedindo pra ele ser mais claro, acaba ficando feio para ele como dev (e como profissional) que não tem atendido as necessidades de seus superiores.

Além de que deixar mastigado não é botar o código certo, por exemplo, mas indicar explicitamente como corrigir. Em vez de escrever "Esse código ta fora do padrão" pode ser "O código ta fora do padrão, verificar exemplo no arquivo teste_123.file a partir da linha 23"

3
vitorl30

Eu concordo plenamente com o autor do texto e com sua experiência em relação à importância de aumentar a resolução na comunicação. É fundamental fornecer contexto e detalhes suficientes para que a outra pessoa tenha uma compreensão completa do que está sendo discutido. Isso é especialmente importante em ambientes de trabalho, onde a comunicação clara e eficiente é crucial para o sucesso da equipe.

Além disso, a ideia de utilizar "blocos de informação" para organizar a comunicação e permitir que outras pessoas contribuam para a discussão é uma estratégia muito sensata. Isso pode ajudar a garantir que todos os envolvidos tenham uma compreensão clara do contexto e da situação, e também pode tornar mais fácil para as pessoas se envolver e contribuir para a solução de problemas.

3
CarlosGabriel

Acredito que para se comunicar de forma eficaz, além das técnicas mencionadas nos outros comentários e publicação principal, é importante observar a gramática aliada ao profissionalismo. É nesse momento que diversas pessoas começam a reclamar:

"Ah, mas na empresa/cliente não tem nenhum professor de português. Por que vou me preocupar?"

Muitas das convenções básicas do profissionalismo foram esquecidas, assim quem fizer o básico bem feito, já terá um destaque. Assim, da mesma forma que um desenvolvedor de software deve prezar pela qualidade do seu código, utilizando práticas como Clean Code, uma mensagem escrita pelo mesmo deve ser escrita com cuidado. Se você passa minutos para achar o melhor nome para uma variável, e preza para que seu código seja legível e de fácil manutenção, você deveria por o mesmo esforço na comunicação.

Assim como desenvolver, escrever é uma habilidade, que pode melhorar com a prática. Pequenos cuidados vão trazer benefícios tanto para o receptor das mensagens, quanto para quem as escreve.

Quais os tópicos de atenção que podem lhe ajudar desde já:

  • Não use palavrões, e evite utilizar gírias:
    Nossas atividades podem virar hábitos, ou no sentido negativo: vícios. Não seja a pessoa que para tudo manda um @!#$. Um palavrão despercebido em um email com o cliente pode custar o seu emprego.

  • Cuidado como lida com o superiores.
    Por exemplo, o canal de comunicação da empresa ser o discord não significa que você deve mandar mensagens como se estivesse mandando mensagens para colegas de jogos. É importante lembrar que por mais amigável e parceiro seja o seu chefe, ele está acima de você na hierarquia da empresa.

  • Releia o que você escreveu.
    Como dito no vídeo, o esforço para que a mensagem seja clara será traduzido em menos ruído na comunicação. Lembre de mencionar o contexto do que você está pedindo. Se nem você, que está escrevendo a mensagem, está conseguindo decifrar o que está perguntando, dificilmente a pessoa do outro lado conseguirá.

  • Demonstre o que já foi feito.
    O @filipedeschamps citou algo que foi um marco no início da minha carreira e me auxiliou imensamente a destravar problemas antes mesmo de enviar mensagens pedindo ajuda. Antes de simplesmente pedir ajuda com o que você está com dificuldade, elabore bem o que está acontecendo, descreva o que você já pesquisou sobre e o que já tentou fazer para solucionar. Essa "técnica" será similar ao rubber duck debugging :

Ao descrever o que o código deveria fazer e observar o que ele efetivamente faz, qualquer diferença entre esses processos fica mais visível.

Escrever um bom texto ou uma mensagem clara pode ser tão complexo quanto escrever funções e programas.
Mas lembrem é difícil !== impossível.

Se alguém tiver mais sugestões, posso criar um post sintetizando os comentários.
Keep coding

2
asyncGenerator

Estou em um projeto de desenvolvimento a um ano e dois meses, e a comunicação com o time de negócios é muito ruim.

O video do Filipe é muito claro mas tivemos varias formas de aborda isso e o time de negócio não consegue entender isso.
Engraçado sempre quando vem à tona comunicação assíncrona e escrever melhor as estórias de negocio ou bugs, eles encaram isso como um tipo de perseguição.

Hoje atuo em uma squad que o PO não escreve as estórias e nosso cliente interno não sabe dizer com clareza as regras de negocio a serem desenvolvidas.

Todos esses exemplos do artigo e o video foram usados. Até mesmo o no hello usamos como exemplo. Mas nada consegue mudar a cabeça deles.

1
mikaelmedeiros

Vendo essa situação, enxergo que talvez sejam pessoas acomodadas. Uma possibilidade seria fazer o trabalho deles, por mais que seja louco isso, vejo como uma solução. Mostrar como se faz, medir os resultados mostrar para eles a melhora, caso continuem "não entendendo", seria uma boa subir mais o nível dessa discussão.

PS.: Já fiz isso e funcionou. :

2
rodsfsantos

Olá, minha dica para aperfeiçoar sua comunicação é bem simples. Sempre que tiver oportunidade, converse com o time de suporte técnico da sua empresa. Eles são especialistas em se comunicar para resolver problemas rs.

Eu como iniciei no suporte e fiquei um tempo lá até migrar para o desenvolvimento, aprendi no meio do caos e da pressão a falar com convicção e isso me ajudou de uma forma que eu não sei explicar (logicamente).

Hoje a comunicação com certeza é uma skill que carrego comigo.

Então minha dica é essa, você dev, não seja inimigo do suporte. Seja amigo!

1
CarlosGabriel

Também trabalhei como suporte (estagiário), antes de atuar como dev, e concordo com o que comentou. Pela necessidade, aprendi a interpretar melhor as demandas dos clientes e também a ser mais claro, me preocupando se a pessoa que está escutando/lendo está conseguindo entender.

2
emanuelvictor

Olá a todos! Estou com um problema e preciso de ajuda.

Na minha empresa, adotamos as RFC's como melhoria contínua da nossa guideline, e consequente evolução técnica da nossa base de código. Ocorre que, quando uma RFC é escrita, ela muito provavelmente ficará lá para sempre, ad. eternum, ninguém lerá, não haverá um comentário, nem nada do tipo.

Eu digo a todos "Isso não está certo, é muito lento, isso quando não é parado", tem RFC lá de mais de 3 meses atrOz.

Será que uma idéia melhor, não seria uma reunião técnica semanal com os devs. E para essa reunião haveria uma agenda (uma fila de temas), onde o tema é apresentado em uma reunião, e é aprovado (ou reprovado) na próxima. E aí quem fosse apresentar o tema poderia apresentar uma POC, obviamente iria elencar os pontos positivos e negativos, e etc, etc, etc.?

Outra dúvida que tenho, RFC é pra toda e qualquer alteração na base de código? Eu tive que escrever uma RFC para utilizar a anotação @Nested nos testes por exemplo, e olha que essa anotação já estava no classpath (não tive que inserir nenhuma nova biblioteca nem nada do tipo). Mas me disseram que não estava conforme o padrão do código, e eu não poderia utilizar. Pra mim me parece que utilizaram a RFC como argumento para barrar a inovação e evolução do código. É uma forma de comodismo. Acredito que RFCs seriam para coisas maiores.

O que vcs acham?

2
potatowski

Olá, Guga
Tem um vídeo que eu acho super importante do Dias de Dev sobre como perguntar de forma eficaz e citar um dos conceitos chamado "don't tell ask, just ask" que acho super importante, que é basicamente, em vez de mandar uma mensagem pedindo ajuda para o problema, já mandar com o problema que está ocorrendo e o que você já tentou, aí a pessoa não vai ter um trabalho maior para saber o que ou já tem uma solução melhor, enfim, depois assiste

Link do Vídeo

2
2
1
andrelcnunes

primeiramente parabéns pelo conteúdo.

E realmente esse tipo de processo acaba causando mais processos, ainda mais que na época que vivemos que a comunicação corre na velocidade da luz.