Existe saída pro caos?

Como priorizar e sair do modo reativo de trabalho em times de engenharia

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?

1. Trate interrupções como parte do trabalho.

2. Foque o resto do tempo em poucas coisas importantes.

3. 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.