Imagine a seguinte situação: É de manhã. São 09h00 e lá está você em pé para mais uma daily meeting com a sua equipe.
Vou criar alguns personagens e uma situação para explicar melhor.
Fabricio, que é um dos desenvolvedores, fala: “A emissão de cartão de crédito parou de funcionar. Olhei os commits e vi que Jorge mexeu nas classes de emissão de cartão e ferrou com a funcionalidade.”
Jorge, presente na daily meeting, engole em seco e responde:
“Eu só mexi nessas classes porque ouvi você dizendo que precisava refatorar e que o código estava um pouco confuso.”
Depois do bate-boca, o clima da reunião se assemelha a de um funeral.
Ao chegar na sua máquina, você abre a ferramenta de versionamento e, ao conferir o commit de Jorge, se depara com a mensagem no log: “Refatorando classes“.
Você percebe que 18 classes foram alteradas.
É então que o Gerente de Produto entra no escritório nervoso e pede para que a funcionalidade volte a funcionar antes do meio dia porque clientes estavam esperando.
Esse relato, foi um amontoado de situações pelas quais passei, durante 10 anos trabalhando com Desenvolvimento de Software.
Mas vamos raciocinar: é um pouco comum esse tipo de comportamento, certo? Na realidade, não.
Vamos estudar esse momento estressante e aprender como podemos remediar — ou pelo menos amenizar — situações assim usando a comunicação.
>>Leitura recomendada:
Como se destacar na carreira de desenvolvedor?
Como melhorar a comunicação em projetos de TI?
Criticar construtivamente em privado
‘”Elogie em público e corrija em particular. Um sábio orienta sem ofender e ensina sem humilhar.” – Mario Sergio Cortella.
Constranger publicamente alguém não deve ser uma ferramenta de ensino. Não deve ser ferramenta de nada, na verdade.
Isso causa desconforto nas pessoas que estão no grupo, deixando o clima pesado e baixando a moral da pessoa criticada, que automaticamente ficará na defensiva.
Os reais danos ao trabalho
O profissional atingido pode se esquivar como forma de defender suas habilidades frente aos colegas.
Em outros casos, o profissional também pode retrair-se, sentir-se inferior, desmotivar-se e ficar com medo de errar novamente para não ter que passar pela mesmo trauma.
Como criticar de maneira construtiva?
Alguns especialistas comportamentais recomendam que a crítica seja dada de maneira privada, podendo ser uma conversa informal no chat, ou pessoalmente, utilizando uma comunicação polida e sem ironias.
Uma boa técnica pode ser o feedback sanduíche, que começa com a apresentação de um ponto positivo, seguido do item que precisa ser melhorado e finalizando com um outro ponto positivo.
Esse tipo de técnica facilita a absorção do feedback sem abalar a moral.
Faça elogios em público (mas cuidado!)
Elogiar publicamente eleva a motivação e o sentimento de trabalho bem feito.
Ponto de atenção: o elogio deve ser utilizado com cautela (principalmente se o elogio é de um líder).
Isso porque caso um integrante esteja se esforçando e não esteja recebendo os ‘louros’, também pode se sentir desmotivado.
Não ser reconhecido(a) enquanto os colegas são pode gerar um efeito igualmente negativo.
Peça desculpas sempre
Assuma os erros e demonstre franqueza.
Se esquivar, trocar de assunto ou dar de ombros quando o problema foi gerado, pode demonstrar insegurança ou arrogância.
Membros da equipe poderão evitar trabalhar com essa pessoa.
Sempre que se deparar com um erro causado pelo seu trabalho, assuma o erro e tente aprender com ele.
É importante apontar como vai proceder com esse problema. Caso a solução seja grande e precise de muito reforço, alinhe com a equipe e crie um ticket com o problema para ser priorizado em algum momento.
>Leitura Recomendada:
Leia nosso artigo sobre CLT versus PJ e descubra qual método é o melhor para você!
Evitação/Gestão de crise no departamento de TI
1. Mensagens de commits explicativos
Mensagens de commit devem explicar claramente o que foi resolvido. Adicionar o número do ticket (caso possuir) para contextualizar também é muito importante.
Escrever mensagens que não agregam nenhuma informação ou mensagens extremamente curtas como: “Corrigido o erro”, “Alterado CSS painel”, não nos diz nada no momento que é commitado.
Imagina daqui 6 meses, quando alguém da equipe abrir a ferramenta de controle de versão e se deparar com esse tipo de mensagem?
>Leitura Recomendada:
Leia nosso artigo sobre programar em equipe
3. Investir em legibilidade de código/Linguagem ubiqua.
Legibilidade de código é uma hardskill.
E, claro, legibilidade de código facilita muito o trabalho em equipe, devido ao fato que o código-fonte é mantido pelo grupo. Um código de fácil leitura mostra muito mais rapidamente o seu conceito.
Todo desenvolvedor sabe o problemão que é enfrentar código mal escrito: Além da desmotivação de enfrentar um código aparentemente “escrito em grego”, um código sujo também impede a criação de testes automatizados.
É um verdadeiro pântano onde bugs adoram se esconder.
Divergência de linguagem pode ser considerado um code smell, um gerador de débito técnico.
O code smell é um grande problema na evolução do produto. Uma maneira de corrigir é analisar o impacto e, após isso, refatorar as camadas impactadas.
4. Reporting real
Trabalhar em equipe requer reportar o andamento das tarefas, isso porque os interessados ficam sabendo do status e a equipe ganha sincronia.
Quando um gerente de produto precisa de uma funcionalidade funcionando no início da tarde e você dificilmente finalizará até lá, não é legal falar: “Eu vou tentar resolver até o meio dia”.
Quase sempre, evitar um confronto não é o jeito correto de resolvê-lo. Dizer que vai “tentar” não resolve nada.
Ao utilizar essa narrativa, as pessoas gerarão expectativa e o resultado pode ser muito pior do que tivesse reportado que não conseguiria.
Como resolver, então?
Encare o conflito de frente, mostre que quer muito resolver um problema.
Que tal algo, como: “É um problema complexo, não considere pronto até o inicio da tarde“.
E se você receber uma resposta inflexível, então a tréplica que pode ser utilizada:
“O que podemos fazer é retornar para versão anterior, que está estável. Porém, não conseguiremos cumprir aquela task x no deadline combinado. Priorizar este problema e deixar outras coisas de lado pode ser a saída.”
Tente apresentar uma solução, mesmo que paliativa. Essa é uma maneira política e assertiva de resolver as coisas. É muito melhor do que ficar apenas dizendo: “Não, não tem como fazer até meio-dia.“. Mas, ainda assim, é melhor do que ser impreciso(a) e dizer que vai “tentar”.
A comunicação dos desenvolvedores
O estereótipo de programadores “poucos comunicativos” ainda vive. Somos considerados “nerds que só conversam com o computador” e, atualmente, isso não pode ser uma realidade.
Se quisermos atingir mais performance profissional, temos que dominar vários níveis de comunicação: desde o nível mais inicial, onde precisamos digitar mensagens nos commits, até alto nível comunicacional, onde há a necessidade de expor problemas e soluções para a diretoria/gerência e equipe.
A mensagem de hoje é: comunique-se SEMPRE.
>>Leitura Recomendada:
Leia nosso artigo sobre as principais habilidades do CTO
