Executando verificação de segurança...
7

Comemore o progresso com seus clientes e mostre o valor do que foi feito

Os seus clientes sabem o que você fez? Pode parecer uma pergunta estranha, mas ela é importante porque a percepção do valor de uma mudança se torna diferente quando ela é mais explícita ao seu cliente, mesmo que o cliente seja alguém da sua própria empresa.

Lendo uma discussão no Hacker News, encontrei alguns comentários valiosos que abordam essa reflexão. Primeiro, um comentário do ByteCode_dev, traduzido:

Essa é uma lição que sempre repito aos nossos juniores: quando você fizer algo notável, comemore e certifique-se de incluir toda a equipe, os usuários e o chefe na comemoração.
Pode ser tão simples quanto um e-mail, mas às vezes, fazer algumas mensagens de bate-papo ou até mesmo ligações. Leva tempo, parece bobo, mas você obtém um ROI (retorno sobre o investimento) fantástico com isso.

Porque agora as pessoas veem seu trabalho como valioso. É concreto para elas. Elas entendem o seu valor. E isso tem muitas consequências positivas na sua vida.

Isso, é claro, só funciona se a celebração evitar termos técnicos, for curta, direta ao ponto e explicar qual é o benefício para eles e para a organização e quanto custou para isso.

As pessoas devem saber que você está fazendo um bom trabalho e você é o único que está em posição de informá-las. Elas não vão sair de seu caminho para aprender sobre isso.

Exemplo de uma mensagem de chat que eu enviaria para o chefe de equipe do meu cliente:

"Olá <primeiro nome>, demorou 3 semanas, mas finalmente terminamos de melhorar o <sistema x>. Isso deve nos poupar <y> de <z> no futuro. Nós nos esforçamos para garantir que seu trabalho não seja perturbado pela mudança, por isso deve ser transparente para você. Mas deixe-me saber se você notar algo fora do comum."

Acredite ou não, as pessoas realmente gostam disso. Isso as mantém informadas, fornece contexto e perspectiva e as ajuda a tomar melhores decisões. Portanto, não hesite em fazê-lo.

Além de apenas compartilhar o que foi feito, tenha em mente que a escolha de palavras é importante nessa comunicação. Veja a diferença entre dois exemplos que o usuário ByteCode_dev deu:

Eu estava trabalhando por vários meses para um cliente e tive uma tarde lenta, então decidi converter alguns cálculos para numpy, ver se ganhamos algum ganho de desempenho.

Conseguimos um aumento de velocidade local de 100x, o que foi muito suspeito. Ganhar velocidade é comum com a vetorização, mas duas ordens de grandeza é demais.

Então eu olhei para o algoritmo original. Houve um erro flagrante nele, que consertei pelo meu código numpy sem perceber, e apenas mudar isso no algoritmo Python puro, sem usar numpy, tornou 50x mais rápido.

Eu poderia então ligar para o meu cliente e comemorar a boa notícia. Não "houve um erro", não. Mas "encontramos margem para progredir".

Pensando sobre como implementar isso no seu dia a dia, talvez você tenha vergonha de algo que fez. Algo que parece não ter valor, ou que levou mais tempo do que valeria. Esse tipo de reflexão pode trazer uma nova visão para você sobre o negócio, e o usuário Ntrails compartilhou isso:

O outro lado da moeda: "Acabei de passar 2 semanas otimizando um processo diário para ser duas vezes mais rápido" pode muito bem acabar em eu me perguntando por que alguém se importaria com a redução de 1 minuto no tempo de entrega dos dados de cadência diária. Isso também pode resultar em eu ser insatisfeito com o trabalho que não consigo obter recursos que tenham um valor monetário óbvio.

Mas isso também é uma vitória para o negócio. Ou estou errado e sou convencido do valor, ou estou certo e fico mais engajado com a priorização das partes interessadas (stakeholders) e estabelecemos algo mais eficaz.

Talvez você não veja um valor claro em tudo o que faz, como gastar algumas horas atualizando dependências, mas é importante trabalhar nesse tipo de visualização sobre as tarefas.

1

Super interessante! Muitas vezes a gente fica louco pra resolver um bug, mas e depois disso? Outro bug, fim do projeto?

Temos que ter uma visão ampla do projeto e como ele vai ser no futuro, as coisas vão mudar, o projeto pode mudar 10 vezes ou mais ao longo do tempo e principalmente por causa de bugs.

Gostei demais desse post! Vou aplicar essa comemoração de progresso na empresa que eu trabalho hoje (não é da área de TI) e seguir com isso pra nossa área!! Sensacional, rafael!