O que um Dev aprendeu em reuniões e apresentações de projetos com clientes

O que minha experiência em apresentações de projetos no papel de desenvolvedor de software me ensinou.

À medida em que vamos alcançando novos patamares na nossa carreira, vamos encarando desafios cada vez maiores e com riscos crescentes também. Um destes desafios é a comunicação com líderes de projeto, stakeholders e clientes em geral durante reuniões e apresentações de resultados.

Em projetos em equipe, temos pessoas atuando em funções especificas — ou pelo menos deveria ser assim, em um mundo ideal — e geralmente existe uma pessoa na equipe que apresenta os resultados do projeto, responde perguntas do cliente e gerencia change requests feitas por ele, tudo isso tendo em vista o prazo estimado de implementação, custo, recursos, etc.

Mas e quando essa pessoa não encontra uma forma de mediar a situação? O que deveríamos fazer para ajudar? E quando somos nós, colaboradores com perfil mais técnico, que temos que apresentar os resultados no final da sprint? É sempre importante ter uma noção de como fazer isso da melhor forma possível.

Vou te dar algumas dicas, baseadas na minha experiência, que você pode usar para apoiar sua equipe nestas situações!

Saber o momento certo de entrar em ação

Existem momentos em que não encontramos as palavras certas para explicar alguma coisa e acabamos por embaralhar mais um assunto do que resolvê-lo, o que é algo comum no aprendizado em qualquer área. Quando esta situação ocorre em reuniões e apresentações com clientes, um outro colega pode entrar em cena para dar uma ajudinha.

Para isso, basta que você esteja prestando atenção no assunto que está sendo discutido, saiba como explicar o assunto de uma forma “entendível” e claro, peça licença para tomar o lugar do colega.

Isso foi a primeira coisa que aprendi nas reuniões semanais onde eu e minha equipe apresentávamos o progresso do projeto. Já aconteceu de eu me atrapalhar tentando explicar algum assunto ou ao responder uma pergunta do cliente, e nesse momento um outro colega entrava em cena para ajudar; o inverso já aconteceu várias vezes também.

As vezes temos medo de ficar na frente para explicar algo ou responder uma pergunta, mas fazemos parte de uma equipe, e não podemos deixar a peteca cair.

Entrar em ação dessa forma demonstra muito sobre você e vai te fazer ganhar muitos pontos dentro da sua equipe e até fora dela. Só esteja ciente de que você vai entrar para resolver, então use as palavras certas para isso.

Tente se comunicar na língua que o cliente entende

Esta dica é complementar à dica anterior. Sua explicação pode fazer total sentido na sua mente, mas precisa fazer sentido na mente da pessoa que está recebendo a informação também, senão pode ocorrer uma falha de comunicação — o que eu acredito que seja a o problema mais comum de todos, ao mesmo tempo que é o mais simples de se resolver.

Se você vai explicar algo e a pessoa chama “grid” ao invés de “tabela”, use “grid” quando conversar com ela; se ela chama “celular” ao invés de “smartphone”, use “celular” com ela. Desta forma, vocês estarão no mesmo passo e a conversa será mais fácil. Preste atenção na forma como seu cliente fala e usa as palavras, isto é crucial.

Eu considero essa a dica mais importante de todas aqui, de uma forma que nem consigo mensurar.

Construir um bom relacionamento com o cliente

Essa dica vai para qualquer cargo em qualquer lugar. Bons relacionamentos são construídos com o tempo e com a boa comunicação entre as partes. Trate seu cliente bem, entenda suas dores e os problemas que ele quer resolver e então você terá cada vez mais abertura com ele.

Quanto mais reuniões você participar e mais situações você puder entrar em ação, mais seu relacionamento com ele vai melhorar também!

Entender o contexto geral do projeto o que está sendo discutido

Para que você entre em ação e ajude seus colegas nas reuniões e apresentações, você precisa entender o que está sendo discutido naquele determinado momento.

Por exemplo, se estão falando sobre uma funcionalidade de dashboard de usuários e o cliente faz uma pergunta que ninguém está sabendo responder, você tem que entender como aquele dashboard funciona, de onde vêm aqueles usuários, quem são eles, etc. Quanto mais informações você tiver, melhor será sua explicação.

Ter uma ideia do contexto geral do seu projeto também é essencial. Isso vai fazer com que sua explicação seja mais rica e você vai conseguir linkar outras partes do projeto mais facilmente, caso necessário.

Explicar de forma clara

Já existiram muitas situações onde eu fui o apresentador dos resultados do projetos e uma das primeiras coisas que aprendi durante estas apresentações foi explicar de forma clara.

Uma funcionalidade, uma ideia, uma informação ou o que quer que seja que você está explicando, faça isso de uma forma que o seu cliente possa entender sem nenhuma sombra de dúvidas, ou o mais próximo disto.

Um exercício que você pode fazer é tentar se colocar no lugar dele, como se fosse você quem estivesse assistindo à apresentação. Eu, como Dev, tendo a falar muito sobre o aspecto técnico da coisa e de forma menos clara, visto que já vi a funcionalidade tantas vezes que tudo me parece óbvio; mas para o cliente tudo é novo e ele precisa entender com clareza do que se trata, como foi feito e pra que serve tudo aquilo.

Como você pode perceber, este tópico anda de mãos dadas com o de tentar se comunicar na língua do cliente.

Saber falar quando algo pode ser melhorado e saber quando NÃO falar

Têm muitas coisas que eu, como desenvolvedor de software, gostaria de fazer e que traria um valor enorme para o meu cliente. Uma funcionalidade incrível, uma abordagem fascinante, uma página web com animações de encher os olhos… Mas tudo isso vêm com um preço.

Por vezes eu me peguei em uma situação onde, no espirito de ajudar minha equipe, me comunicar melhor com o cliente e trazer mais valor pra ele, falei mais do que deveria e dei ideias que, embora agregassem muito, aumentaram bastante o tempo em que uma funcionalidade tomaria inicialmente para ser desenvolvida.

Por exemplo, imagina que você tem um grid com informações de vendas. Você e sua equipe criaram aquele grid padrão com as informações, mas você sugeriu que cada informação de venda, quando clicada, redirecionasse pra uma página nova com informações mais detalhadas. Enquanto que isto traz um valor enorme para o seu cliente, também traz um custo e um tempo de desenvolvimento associado!

Já dei muita ideia boa que contribuiu com o projeto, na maior boa vontade, mas eu tive que ficar uma horinhas a mais no trabalho pra cumprir com o prometido. 😅

Nós, no papel de Dev, sabemos o que pode ser melhorado e também sabemos dar opções de melhoria para o meu cliente, mas antes é necessário alinhar expectativas, discutir com e equipe e, só depois de estar tudo certo, dar a sugestão.

Mas ei, não fica desanimado! Não estou te dizendo para você parar de dar sugestões, estou te dizendo para analisar bem o contexto antes de tomar essa decisão. Dar mais opções para o seu cliente é sempre bem vindo, até porque ele pode não conhecer o contexto geral e/ou pode não conhecer outras abordagens.

Não ter medo de falar quando algo sugerido pode ficar “ruim”

A palavra “ruim” aqui é mais para causar um impacto, mas é claro que você não vai dizer que algo está ruim em uma reunião ou apresentação, pois isso pega muito mal! Isto está mais associado ao que passa na sua mente quando você escuta uma sugestão ou abordagem que você tem certeza que não vai funcionar — do ponto de vista técnico, pelo menos.

Geralmente, quando algo assim acontece, o apresentador abre a conversa para que um membro da equipe técnica explique se aquele sugestão é possível de ser concretizada ou não, mas quando essa abertura não acontece, é importante que você traga o assunto à tona.

Nessas situações, eu aprendi que a melhor forma de resolver é pedir um tempo para que a equipe se reúna e discuta sobre o assunto. Isso vai te dar tempo para analisar melhor o problema do ponto de vista técnico e também lhe dará um tempo para construir uma resposta melhor e até alternativas mais viáveis.

Dar mais opções

Não adianta também apenas criticar e dizer que está “ruim”, também é necessário mostrar o seu ponto de vista e dar outras opções também.

Problemas no mundo da TI geralmente têm mais de uma solução. Quanto mais opções você dá, mais discussões em torno do assunto serão geradas e mais métodos serão descobertos pra resolver um mesmo problema.

Geralmente essas múltiplas opções e caminhos diferentes aparecem naturalmente na sua mente quando você entende o problema, o que ele quer resolver e o contexto geral.

Eu e minha equipe já recebemos diversos elogios quanto ao fato de darmos varias opções e saídas para um problema para nossos clientes. Foi ficando natural com o tempo. Recomendo que você faça o mesmo, sempre que possível.

Em um dos projetos em que participei, tivemos que recriar uma aplicação já existente em uma tecnologia nova e melhorar suas funcionalidades. À princípio, o cliente queria que a aplicação fosse igual à sua versão anterior, o que traria pouco valor para ele. Com o passar do tempo, tivemos abertura para dar mais opções, mudar algumas abordagens para melhor e otimizar rotinas. Isso trouxe uma grande melhoria para os usuários da aplicação e visibilidade para nós, tanto no lado do cliente quanto de outras equipes no trabalho.

Conclusão

No papel de um colaborador de perfil mais técnico, nem sempre sabemos a melhor forma de nos comunicarmos com o cliente e mostrar para ele o que a gente sabe. As reuniões e apresentações com os clientes me ajudaram a melhorar minha comunicação e ajudá-los nos seus objetivos, assim como deram mais abertura com eles e, ao mesmo tempo, ajudaram minha equipe de alguma forma a crescer.

Espero que a minha experiência e essas dicas te ajudem de alguma forma, melhore seu relacionamento com seu cliente e traga bons frutos para sua equipe!