Uma das reclamações mais frequentes que eu escuto de gestores de times de engenharia fala um pouco da falta de controle sobre o que acontece no dia a dia. De como existe muito débito técnico e pouco tempo para resolver, e também como o dia a dia atropela qualquer planejamento que tenham feito para o time. Será que tem solução?
Existem muitos frameworks para lidar com essa priorização quando se trata de produto, porém para questões não funcionais de engenharia, a não ser que vire uma crise, os times tendem a sofrer em silêncio e aceitar que a realidade se resume a responder chamados, e fazer as coisas aleatórias que são demandadas no dia a dia. Com isso, acumula-se débito técnico, insatisfação e o risco de burn out no time cresce.
E como sair desse caos?
Trate interrupções como parte do trabalho.
Foque o resto do tempo em poucas coisas importantes.
Aprenda a dizer não.
Tratando interrupções como parte do trabalho
Quando eu comecei a trabalhar no Facebook, eu tinha um time de exatamente 3 pessoas para dar suporte a infraestrutura de caching da empresa. O time passava o tempo inteiro apagando incêndio. Um dos engenheiros do time, que não sabia dizer não, trabalhava dia e noite resolvendo problemas aleatórios de produção, mas além dele, todo mundo passava uma boa parte do seu tempo sendo interrompido em seus projetos para ajudar a resolver problemas aleatórios.
O que eu fiz? Eu estabeleci uma escala de suporte no time. Cada semana teríamos uma pessoa prestando suporte, full time, e as duas outras pessoas engenheiras poderiam então focar nos seus projetos.
“Ah Fernanda, mas nem todo mundo é capaz de resolver qualquer problema aleatório que chega no time!” — tenho certeza que você está pensando isso. Sim, isso é verdade, mas somente temporariamente.
Depois de uns 3 meses, todas as pessoas do time serão capazes de responder 99% das requisições sem precisar de ajuda, desde que todos sejam responsáveis por ajudar a pessoa em escala de suporte a resolver os problemas (e não mais resolver as coisas elas mesmas, como antes).
Quando o time vai planejar, a pessoa gestora do time precisa então contar que 1 pessoa full time vai sempre estar resolvendo interrupções, para deixar o resto do time trabalhar nos projetos de longo prazo. O que nos leva ao próximo ítem…
Focando no que é importante
Focar em projetos de longo prazo é uma maravilha, todos concordarão. Mas o que nem todo mundo concorda é como selecionar o que é mais importante.
Eu tenho um método bem simples para equipes que tem muita carga de interrupções e débito técnico: um dos projetos mais prioritários do time deve ser o projeto que reduza tempo dedicado a tarefas repetitivas.
Voltando ao meu exemplo lá do Facebook, existiam alguns fatores que criavam esses “incêndios” que o time passava muito do seu tempo resolvendo: a) novas versões sendo lançadas em produção, e como esse processo não tinha controle nenhum, haviam MUITAS versões em produção; b) alteração de configuração em produção quebrava o ambiente; e c) shards muito quente causavam instabilidade no ambiente.
O que nós fizemos? Investimos em três coisas. Adivinhem? Automação de deployment para que fossem feitos de forma gradual (e fácil). Melhoria da cobertura de teste do script que criava e distribuía configurações em produção, e criação de mecanismos para fazer “split” de “shards” que eram detectados como ficando muito quentes.
Seis meses depois o time era irreconhecível. Tínhamos conseguido contratar mais 3 pessoas, os projetos já estavam dando muito retorno e diminuíram muito a quantidade de incidentes que tínhamos, e também a quantidade de tickets.
Dizendo não
Tendo nossas prioridades claras fez com que a conversa sobre pedidos aleatórios diminuísse, porque não dizíamos simplesmente não, nós mostrávamos o que estávamos fazendo e porque, e na grande maioria das vezes, era óbvio o que estarmos priorizando isso versus outras coisas. Algumas vezes obviamente existiam outras urgências e adaptávamos o que o time estava fazendo.
O time foi de lugar de “burn out” para um dos times onde as pessoas queriam trabalhar. Fazíamos eventos sociais juntos, nos divertíamos muito, e o time de Production Engineering passou a brigar muito menos com o time de Software Engineering.
Cacheville, como chamávamos a organização, progrediu muito com relação a excelência operacional, empoderamento do time, e também satisfação no trabalho. Aprendi muito tecnicamente, e também como gestora.
Confesso que foi um dos momentos “de ouro” da minha carreira, e sempre me lembrarei com carinho.
Muitas vezes nós gestores pegamos a realidade e aceitamos ela como fato da vida, sem lembrar que é nossa responsabilidade mudar essa realidade, e sair do caos. Sair do caos é possível, é gratificante, e é parte do que faz gestão tão significativa nas organizações: é o nosso trabalho.
Post extremamente inspirador! 👏🏾 Obrigada por compartilhar, Fernanda.