5 dicas de comunicação para diminuir o abismo entre a área de tecnologia e o público estratégico

[Nota da editora: A Mariana Esposito - ou Nana, como gosta de ser chamada - é Product Owner da área de Tecnologia na Printi. Isso significa que ela cuida da parte de operações do site. Formada em jornalismo, ela escreveu um texto incrível com dicas de comunicação para diminuir o abismo entre a área de tecnologia e o público estratégico - um grande desafio nessa área.

O texto originalmente está no Medium , mas ela cedeu seus conhecimentos para o Blog da Printi. Como nem todo mundo está familiarizado com os termos usados, por isso, no final você encontra um glossário. Boa leitura!]

Conforme já comentei em outro texto sobre a razão de TI ter uma imagem ruim nas empresas, várias têm dificuldade em estabelecer uma comunicação efetiva entre tecnologia e outras áreas. Tenho algumas dicas e experiências que deram certo comigo e que você pode começar a fazer HOJE para ajudar a sua equipe.

1. Não adianta tentar esconder os erros

Se deu ruim em um deploy ou existe um bug conhecido, comunique isso aos usuários pertinentes. Aqui o objetivo não é ficar enchendo caixa de e-mail com bugzinhos, mas sim ser transparente e antecipar a ação sobre os problemas.

Nada pior do que gastar horas tentando fazer algo no sistema para depois descobrir que o problema já era conhecido, mas ninguém quis admitir. Não há elevação espiritual que perdoe.

É melhor assumir a responsabilidade sobre os erros, preferencialmente já com plano de ação para resolvê-los. Além de honesto, você ainda ganha credibilidade, olha que legal.

2. Comunique o que foi feito periodicamente

As pessoas muitas vezes não têm ideia de tudo o que Tech faz. Mesmo em uma squad pequena, é difícil manter o foco estritamente em tarefas pré-definidas. Muitas vezes as prioridades mudam e o planejado não é entregue, o que gera a impressão de que a equipe não entregou nada.

A verdade é que muitas vezes surgem surpresas no meio do caminho, desde demandas top down (“porque o fulano de tal que pediu”) até imprevistos de infraestrutura (“atingimos o limite de endpoints na AWS”), que fazem com que o time tenha que se dedicar a outras demandas.

Não vou entrar no mérito do porquê isso acontece ou como poderia ser evitado (isso é uma discussão abrangente por si só), mas a responsabilidade de ser transparente e evidenciar isso é nossa.

Mande uma comunicação semanal ou quinzenal para todos os stakeholders (talvez até todos os funcionários!) falando sobre o que o time fez. Deixe explícito o porquê de o combinado não ter sido feito e que outras coisas foram entregues - coisas até mais importantes do que o plano original para aquele período.

Onde trabalho hoje [na Printi], enviamos newsletter toda semana e ainda fazemos uma reunião mensal para apresentar aos stakeholders tudo que fizemos de forma simples e descontraída. Um scrum master com quem trabalhei enviava por e-mail o resultado de cada sprint em três categorias: ‘planejado e entregue’, ‘planejado e não entregue’, e ‘não planejado e entregue’.

Independente do formato, o importante é comunicar de forma pró-ativa, que vá até onde seu usuário está e consistente. É que nem canal do YouTube: não adianta mandar vídeo uma semana e depois passar um mês sem novo conteúdo, se não você perde seguidores.

3. Explique as entregas para que qualquer criança de 5 anos consiga entender

Quando eu falo de comunicar a todos o que está sendo feito no sistema eu digo realmente comunicar, ou seja, se fazer entender. Não tem muito sentido um comunicado que quase ninguém compreende.

O desafio aqui é explicar da forma mais simples e clara possível o que foi feito e qual valor aquilo traz para a empresa. A ideia é que qualquer pessoa, de qualquer área, consiga minimamente entender o que foi entregue e porque aquilo é importante.

Seja criativo, coloque prints, imagens, setas, gráficos, enfim, o que puder ajudar na comunicação. Assim não só você será entendido e sua equipe reconhecida, como todos vão desenvolver uma visão mais ampla do sistema e do negócio da empresa. A gente só consegue ter noção do quão complexas (e interessantes) as coisas são, quando temos a capacidade de entendê-las.

4. Faça as pessoas se interessarem pelo o que você tem a dizer

Também é sua missão tornar esse conteúdo atrativo. Já trabalhei em empresa que parecia spam de tanto e-mail de comunicação que mandava - sendo que quase nenhum era interessante. Ou então são enviadas apresentações infinitas. Gente, o spam médio de atenção das pessoas está cada vez menor! Vamos falar menos e ser mais relevantes!

O time de produtos em que trabalho, que elabora a newsletter semanal de Tech, tem um brainstorming para fazer o comunicado, com referências aos acontecimentos (e piadas) da semana.

Para a gente, o que funciona é a transparência e a capacidade de rir de si mesmo, mas cada empresa tem o seu perfil e o seu jeito de comunicar. O importante é fazer o pessoal se interessar e querer gastar aqueles 5 minutinhos para ver o que o time fez.

5. Dê clareza sobre o processo

Sabe aquela pessoa que todo o dia te pergunta se já começou o desenvolvimento, se está pronto, se já subiu? Já parou para pensar por que ela faz isso? Ora, pois, muito simples: porque ela não consegue saber sozinha.

Percebi que a ansiedade dos usuários está diretamente relacionada ao sentimento de caixa preta que Tech às vezes provoca. Especialmente quando a gente trabalha sem SLA, as pessoas têm a impressão que pedem algo à Tech e só Deus sabe quando vai sair.

Cada equipe tem o seu processo. Contanto que você seja transparente e consiga transmitir o valor de por que faz as coisas do jeito que faz, é possível que o stakeholder entenda e abrace a ideia. Acredite!

Já participei de workshop para construir processo de forma colaborativa, fiz reunião para explicar como funciona ou mandei apresentação com o passo a passo. Tem empresa que tem site explicando todos os processos. Aí vai do seu tamanho e complexidade.

Dica bônus:

Seja transparente! Tudo o que comentei acima apenas reforça o pilar da transparência. Nem sempre vai ser legal, muitas vezes temos que ter ousadia e alegria para fazer acontecer. Mas pode ter certeza que quando a empresa criar essa cultura os resultados serão incríveis.

GLOSSÁRIO:

deploy: disponibilizar uma nova versão de um software para o público
bug: erro no sistema (normalmente sem explicação óbvia)
squad: time de desenvolvimento
endpoints na AWS: recurso usado por alguns sistemas que permite a comunicação entre a tela (frontend) e o sistema (backend)
stakeholders: usuários e pessoas interessadas em um projeto
scrum master: facilitador das reuniões e processos em metogologias ágeis
sprint: período fixo para um ciclo de desenvolvimento
SLA: Service Level Agreement ou Acordo de Nível de Serviço
top down: ordens superiores