Scotty: O Mestre do Gerenciamento de Expectativas no Século 23
Tenho passado um tempo considerável a bordo da USS Enterprise original ultimamente. Embora seja fácil se encantar pelo carisma caótico do Capitão Kirk ou pela lógica fria do Spock, a verdade precisa ser dita. O verdadeiro gênio daquela nave não veste dourado ou azul. Ele veste vermelho e tem um sotaque escocês questionável.
Estou falando de Montgomery “Scotty” Scott.
Muitos olham para o Engenheiro Chefe e veem alívio cômico ou um homem que gosta de reclamar que “os motores não aguentam” um pouco demais. Eles estão errados. Scotty é o único adulto na sala. Ele é o maior praticante da arte perdida do Gerenciamento de Expectativas.
O Trabalhador de Milagres Calculado
Há uma estrutura clássica em quase todos os episódios. Para onde quer que a Enterprise vá, algo terrível acontece. Os escudos caem. O motor de dobra morre. Os Klingons estão atacando.
Kirk, com a urgência de alguém que tem um roteiro para terminar em 45 minutos, grita pelo comunicador: “Scotty! Quanto tempo até termos energia de dobra?”
Scotty, com a voz trêmula de alguém testemunhando o apocalipse, responde: “Capitão! Os cristais estão fraturados. Preciso de pelo menos oito horas ou todos nós seremos poeira espacial!”
Kirk, inabalável, retruca: “Você tem duas.”
E o que acontece? Exatamente no minuto cento e cinquenta e nove, Scotty entrega o motor totalmente funcional. Kirk sorri e o chama de “trabalhador de milagres”.
Para um observador leigo, Scotty parece incompetente por errar tanto a estimativa ou desonesto por inflar os números. Mas isso não é desonestidade. Isso é Engenharia Defensiva.
A Psicologia do Comando
Scotty entende uma verdade fundamental sobre liderança e gerenciamento de projetos que muitos de nós ignoramos. O Comando (seja o Capitão Kirk ou seu Product Manager) não se importa com a termodinâmica. Eles não se importam com a complexidade do código ou com a dívida técnica. Eles se importam com o resultado.
Se Scotty dissesse a verdade honesta (“Capitão, isso leva duas horas se tudo der certo”), Kirk, sendo um gerente agressivo, exigiria que fosse feito em uma. E quando algo inevitavelmente desse errado no meio do caminho, a nave explodiria e a culpa cairia sobre o engenheiro.
Ao dizer “oito horas”, Scotty cria três coisas vitais:
- Margem de Segurança: Se algo quebrar (e sempre quebra), ele tem seis horas de “gordura” para resolver o problema sem que o Capitão entre em pânico.
- Controle da Narrativa: Ele define a gravidade da situação. Ele lembra ao comando que as leis da física não são sugestões.
- Valor Percebido: Quando ele entrega em duas horas, ele não apenas fez “seu trabalho”. Ele realizou um milagre.
Este é o conceito de “Prometer Menos e Entregar Mais” elevado ao nível de arte. Scotty não protege apenas sua reputação. Ele protege a integridade do sistema contra as demandas absurdas de pessoas que acham que resolver problemas complexos é apenas uma questão de “forçar mais”.
A Lição para Desenvolvedores Júnior
Se você está apenas começando no mundo do desenvolvimento, ouça o que estou dizendo.
Há um impulso natural de querer agradar. Seu Tech Lead ou seu PM virá até sua mesa e perguntará: “Quanto tempo para implementar esta API de pagamento?” Você olhará, pensará no melhor cenário possível onde o café está quente e o Stack Overflow (Agora a IA) tem todas as respostas, e dirá: “Ah, posso fazer isso em dois dias.”
Você acabou de assinar sua sentença de morte.
No momento em que você encontrar um bug em uma biblioteca de terceiros ou o servidor de teste cair, você estará atrasado. Você vai virar noites. Você vai enviar código sujo. E no final, ninguém vai agradecer pelo esforço. Eles só vão lembrar que você se atrasou.
Faça o que Scotty faz.
Se você acha que leva dois dias, diga quatro. Se o PM chorar, negocie para três. Use esse tempo extra para testar seu código, para documentar, para lidar com o imprevisto.
Se você terminar em dois dias? Ótimo. Entregue antes do prazo. Você será visto como eficiente e proativo. Você será o trabalhador de milagres que salvou a Sprint.
Não se trata de mentir. Trata-se de entender que o desenvolvimento de software, assim como manter um motor de dobra com cristais instáveis, é um processo caótico. Seu trabalho não é apenas escrever código. É gerenciar o caos para que seu Capitão não precise.
