O Pedro tirou férias — e os builds pararam
Três semanas na vida de uma empresa onde um processo crítico se apoiava numa pessoa só, e essa pessoa foi fazer churrasco na casa dos pais. O que eu aprendi, e o que faço agora com essas situações.
Era agosto, calor, temporada de férias. Me ligou um cliente com quem eu tinha trabalhado seis meses antes. "Estamos em pânico", disse num tom de voz particular que as pessoas usam quando o pânico é da empresa inteira, não só delas. "Nossos builds de produção não estão compilando."
— O que aconteceu?
— O Pedro foi embora.
— Para onde?
— Para o sítio. No interior. Na casa dos pais.
— Tem sinal lá?
— Tem sinal. Mas o Pedro está de férias.
— E sem ele não dá?
Pausa. Não uma pausa telefônica. Uma pausa existencial.
O Pedro nessa empresa era engenheiro de suporte sênior, forte. Na lista informal de atribuições dele havia a linha "monta os builds de produção às sextas de noite". O Pedro montou esses builds seis anos. Primeiro — porque era um de sete que sabia como. Depois — porque era o único que sabia onde ficam os certificados e em que ordem aplicá-los. Depois — porque escreveu um script que automatizava parte do processo. O resto ficou na cabeça dele, no formato "aqui espera 30 segundos porque se não, a API da Apple não responde".
Quando o Pedro foi para o sítio dos pais, descobriu-se que ele não tinha documentação. Nem README. Nem vídeo. Nem anotação no Jira. Porque ele nunca planejou entregar essa parte. Nem passou pela cabeça dele que ia ser preciso.
Ele, aliás, até hoje não entende o alarido. "Eu estava acessível", diz. "Vocês podiam ter ligado." Sim. Podíamos. Mas o Pedro estava de férias. E ligar para alguém no sítio com a churrasqueira acesa é má prática de gestão, cujo preço costuma ser algo imaterial — tipo o Pedro pedir demissão seis meses depois para ir pro concorrente.
Ao longo daqueles três dias de agosto consegui montar a release — liguei pro Pedro duas vezes (ele não ficou bravo, levamos uma garrafa de conhaque pra ele em setembro como pedido de desculpas), e ele ditou os passos pelo telefone. Depois disso falei pro cliente: "A gente precisa consertar isso antes de eu sair do projeto. Senão em seis meses a um ano isso se repete, e eu vou ser culpado por não ter consertado quando dava."
O cliente aceitou. A gente consertou. Duas semanas.
O fato de o seu time ter um Pedro é, em regra, resultado de otimização local, não de decisão consciente.
Ninguém projeta processo pra depender de uma pessoa. Acumula naturalmente. Pedro fez a task mais rápido. Pedro fez de novo. Na terceira, todo mundo sabe que é Pedro. Na quarta, é mais fácil ele fazer que explicar. Na décima quinta, só rola via Pedro, porque os passos não estão escritos. Não é culpa do Pedro. É erosão sistêmica do processo.
Pedros vêm em vários formatos. Às vezes é engenheiro. Às vezes — contador que é o único que sabe lançar no sistema tributário local sem tomar multa. Às vezes — vendedor sênior que é o único com o funil no formato dele. Às vezes — o próprio fundador, que é a única pessoa na empresa que entende por que a estratégia é essa e não outra.
Se sua empresa tem um Pedro, dá pra viver. Todo mundo convive com um. Três Pedros já é vulnerabilidade estrutural. Cinco — você não tem processo, tem cinco pessoas autônomas trabalhando lado a lado e às vezes conversando.
Quatro métodos que aplico quando acho um Pedro.
Primeiro — runbook mínimo. Não "escreva um wiki de cem páginas". Ninguém lê. Pedro não escreve, acha chato. Você não revisa, está ocupado.
Funciona uma página. Um processo — uma página. O que faz, entrada, saída, comandos-chave, o que fazer se quebrar. Dez minutos pra escrever. Cinco pra validar.
A validação é simples: uma semana depois de escrito, dê a página pra alguém que nunca fez o processo e peça pra seguir. A pessoa vai tropeçar em três pontos. Adicione esses três pontos. Agora o processo está documentado.
Segundo — pareamento, duas semanas. Pedro faz a task. Ao lado dele (fisicamente ou no Zoom) senta a Maria e observa. Não pergunta. Anota decisões e nuances.
Na semana seguinte a Maria faz, Pedro observa. Mais uma semana — Maria sozinha, Pedro em stand-by.
Depois disso o Pedro pode adoecer, casar ou ir pro sítio dos pais — o negócio não para. Não porque a documentação está perfeita. Porque há um segundo portador de contexto.
Terceiro — automatizar o que se automatiza. Se o Pedro faz esse processo à mão três vezes por semana — é candidato a script. Até um script ruim que cobre 80% dos casos libera 80% do tempo do Pedro. Os 20% restantes realmente precisam do especialista.
O inverso também vale: não automatize o que acontece uma vez por trimestre. O custo de escrever e manter automação passa o custo de fazer à mão. Tive um cliente exatamente assim — um relatório financeiro montado quatro vezes por ano. Passaram meio ano construindo automação. A automação não pegou. Agora o relatório volta a ser feito à mão, como antes.
Quarto — rotação. O método mais doloroso e o mais eficaz. Uma vez por trimestre outra pessoa assume o que o Pedro faz. Pedro vai pra uma área vizinha.
Primeiro o time reclama. Depois o Pedro reclama, porque a expertise dele "se diluiu". Depois ninguém reclama, porque o conhecimento está distribuído.
Funciona em times de quatro ou mais. Menor — rotação não ajuda, não há pra quem passar.
O que não funciona:
"Ah, ele pede demissão — aí a gente resolve". Documentação não aparece por mágica no dia da demissão. Em geral a demissão acontece mais rápido do que dá pra reagir, e o Pedro leva seis anos de contexto junto. Tive cliente que perdeu o time de vendas numa semana depois que uma pessoa saiu, porque essa pessoa guardava na cabeça a estrutura das relações com quinze clientes-chave. Semana cara.
"Vamos contratar outro Pedro". Dobra o recurso, mas não muda a estrutura. Dois Pedros continuam sendo Pedros. A fragilidade sistêmica fica. Só dividida por dois.
"Contexto humano importa, não dá pra documentar". Às vezes verdade. Mais frequentemente desculpa pra não gastar duas horas num runbook. Tenta gastar. Vê o que sai.
Tem uma piada antiga de engenharia: "o único servidor sem backup é o prod". Pra times serve a mesma lógica: o único processo sem redundância é o processo que você não está disposto a perder.
"Está tudo apoiado no Pedro" não é virtude do time. É indicador de imaturidade de processo. Pedros são ótimos. A empresa precisa sobreviver quando o Pedro tira férias. Ou sai. Ou cansa.
A pergunta não é o que fazer com o Pedro. É como crescer pra não depender de um Pedro. A resposta costuma ser quatro horas de trabalho e duas semanas de pareamento.
O Pedro, inclusive, não sai perdendo. Se for um bom Pedro — vai ficar até feliz de ter umas férias sem ligação.