Existe uma mentira que todas as empresas contam: a inovação acontece nos "Labs", nas "frentes".

A verdade? A verdadeira inovação, aquela que salva o produto e a sanidade do time acontece nas sombras. Ela é suja e no início completamente clandestina.

Se você é um desenvolvedor que sente que virou um "movimentador de cards no Jira", este texto é para você.

Vamos falar sobre como fazer P&D (Pesquisa e Desenvolvimento) real enquanto entrega suas tasks. Vamos falar sobre como "lavar tempo", implantar "POCs de Troia" e transformar um script sujo em um Épico patrocinado pela diretoria.

O Problema do "Roadmap Orientado a Entregas"

O cenário é clássico: O Backlog está cheio. O PM quer a feature X para ontem. O Tech Lead está preocupado com o débito técnico da feature Y lançada mês passado. E você? Você está vendo uma oportunidade gigante que ninguém mais vê.

Talvez seja uma ferramenta interna para automatizar processos manuais que consomem 24 horas da equipe por semana. Talvez seja uma funcionalidade nova. Talvez seja uma refatoração na camada de processamento que economizaria 40% da conta da AWS..

Mas quando você sugere isso, a resposta é sempre igual:

"Boa ideia! Cria um card no backlog e avaliamos quando der."

Tradução: Não vai acontecer.

O sistema é desenhado para a previsibilidade, não para a eficiência técnica. Se você esperar permissão para melhorar algo que ainda não está quebrado ou construir a infraestrutura que ainda não é necessária, você vai morrer esperando. Mesmo que todo mundo no time concorda que aquilo ia economizar milhão, diminuir downtime em 99%, abolir o on-call de madrugada. Mas concordar não é priorizar.

Inovar na empresa é igual votação no condomínio: todo mundo é a favor de trocar o elevador, mas ninguém quer pagar a taxa extra este mês.

Então você faz o que define um líder. Para de pedir e começa a fazer. Simples assim.

Fase 1: Lavagem de Tempo (Time Laundering)

Não se assuste com o termo. "Lavagem de tempo" não é roubar a empresa. É, na verdade a forma mais ética de trabalhar.

Se você sabe que tarefa leva 4 horas para ser feita "do jeito básico", mas 6 horas para ser feita "com excelência", você estima 8. Por quê?

1. Porque estimativas são sempre otimistas e você precisa de margem de erro.
2. Porque, se você for eficiente e terminar em 5, sobram 3 horas.

Parabéns, você acabou de fundar seu laboratório de P&D, sem pedir permissão e nem orçamento. Simples assim.

Horas que não estão no seu contrato, em nenhum documento. Mas enquanto você continuar entregando coisa bem feita e nunca perder um prazo, essas horas existem. São mais reais que o mítico "Google 20% Time" que todo RH prafrentex vende no LinkedIn.

O erro é terminar a tarefa cedo e puxar o próximo card do Jira imediatamente. Isso é recompensar o trabalho com mais trabalho.

Fase 2: A POC de Troia (metendo Rust na produção igual contrabando de pasta base em Leite Condensado)

Você tem o tempo. Você tem a ideia. Agora, como você coloca isso em produção sem passar pelo comitê que levaria 3 meses para aprovar um "Hello World"?

Vamos tangibilizar com um exemplo real.

Você sabe que a empresa roda uma Lambda em Node.js que redimensiona dezenas de milhares de imagem em batch diariamente.

Você também sabe que Node.js é fantástico para problemas (IO-bound), mas quando você precisa parelelizar poder de processamento bruto (CPU-bound) a coisa é triste.

O serviço é caro, mas a margem do produto é alta. O faturamento cobre a ineficiência. Para a diretoria, esse é o clássico problema de "não está quebrado". Para você é uma ofensa pessoal.

Você sabe que Rust resolveria isso com uma mão nas costas. Mas a empresa é uma "Node Shop", o CTO tem "TypeScript" tatuado no braço.

• O jeito errado: Você marca uma reunião e propõe: "Vamos reescrever o serviço de thumbor em Rust para economizar infra".

  • A resposta: "Não. O custo de engenharia para reescrever supera a economia. Ninguém aqui sabe Rust. Foco em entregar a feature nova." Você perdeu antes de começar.

• O jeito raiz: Você pega um card do backlog: "Bug: Timeout na Lambda de Processamento de Imagem (Redimensionamento de Thumbnails)".

E entrega um Cavalo de Troia.

Uma Trojan POC é uma solução técnica disruptiva, só que: disfarçada de minor bug fix ou feature trivial.

O PR não se chama "Migração para Rust". O PR se chama "Fix: Timeout no processamento de imagem".

diff +22 −17. 2 aquivos. Um deles é um um blob .so que o PO não sabe o que é.

E as 13.000 linhas de TypeScript originais? Elas continuam lá.

Se você deletasse, o diff ficaria vermelho sangue. O Tech Lead ia parar o mundo para fazer Code Review. O Arquiteto ia marcar reunião. "Que merda é essa?"

Então você deixa elas lá. Código morto. Você altera apenas o entrypoint do serviço para ignorar a lógica legada e invocar o seu binário.

Visualmente o projeto parece o mesmo TypeScript de sempre. Na prática, você trocou o motor de um Fusca por uma Ferrari V12 e manteve a carcaça enferrujada em cima para não chamar a atenção.

O Tech Lead aprova porque “resolveu o bug, o diff era pequeno e os testes passaram então LGTM ;).

Fase 3: A Armadilha do Valor Concreto

Você lavou o tempo. Você infiltrou a POC. Ela está rodando em staging (ou produção, se você tiver coragem e feature flags) e coletando dados.

Na semana seguinte, os gráficos mostram algo bizarro:

• Duração média: Caiu de 420ms para 69ms.
• Memória total: Caiu de 2GB para 128MB.
• 7742 imagens processadas: Faça a conta de padaria da nuvem. O custo da Lambda é Tempo x Memória.

Agora você precisa sair da sombra.

Procure os líderes que estão sangrando. Quem está perdendo bônus porque o sistema cai na Black Friday? Quem está sendo cobrado pelo CEO porque o a conta da AWS está uma fortuna?

Este é o seu alvo. Você chega com o problema resolvido.

Você (no corredor, casualmente): "Fulano, lembra que o board estava reclamando da fatura da AWS ter subido 33%?" "Então... eu estava investigando como parte das minhas atribuições e fiz um teste isolado na lambda de imagens, se aplicarmos em todo o sistema a conta cai pela metade."

Algumas horas depois o cara te liga. No dia seguinte CTO chega com a tattoo atualizada: "TypeScript & Deno & Rust".

Aquele código sujo, aquele .so que você comitou escondido torcendo para ninguém perguntar o que era, agora precisa virar oficial.

Do Subsolo ao Épico (A Legitimação)

Uma vez que você tem o buy-in do Sponsor a mágica acontece.

Ele vira para a gestão de produto e diz: "Precisamos priorizar a produtização da solução do Claúdio em toda a base de código. É crítico para as metas do departamento."

Agora, meu amigo, o jogo virou.

• O PM, aquele mesmo que disse que nunca ia ter tempo para "débito técnico", vai abrir o Jira e criar o card.

• Título: Rust Migration for ALL CPU Bound Services

• Prioridade: Highest

• Estimativa: 13 Sprints

• Tech Lead: Você.

Aquilo que era "perda de tempo", "devaneio técnico" ou "viagem de dev", agora é o roadmap oficial da empresa.

E o mais importante: você parou de reclamar que a empresa não inova e fez ela inovar.

Interlúdio Histórico: Os Magos do Unix e o "Telefone Melhor"

Deixe-me contar a história do maior "Time Laundering" e "Trojan PoC" da humanidade.

Anos 70. O lendário Bell Labs. A gestão queria uma coisa: melhorar o sistema de telefonia. O business goal era claro.

Mas Ken Thompson, Dennis Ritchie e sua trupe não queriam fazer telefones. Eles queriam um ambiente decente para programar.

Quando o projeto oficial de sistema operacional deles (Multics) foi cancelado por ser caro e complexo demais. Eles encontraram um computador PDP-7 abandonado num canto e clandestinamente continuram a desenvolver o Unix.

Quando precisaram de mais hardware e tempo eles não venderam o SO. Eles proposeram para a gerência uma ferramenta de processamento de texto para o departamento de patentes.

A Bell Labs "comprou" a máquina de escrever digital. Eles ganharam o Unix e a linguagem C de brinde sem nem saber. A diretoria da AT&T queria um telefone melhor. Como o Unix se tornou a espinha dorsal de toda a Internet, tecnicamente eles entregaram exatamente isso!

Conclusão: O Código é a Única Verdade

O mundo tech é cheio de reuniões, slides, roadmaps coloridos e promessas vazias. É fácil se tornar cínico, sentar na cadeira reclinável e apenas "fazer o que mandam" enquanto o sistema apodrece e sua carreira estagna.

Mas o desenvolvedor que realmente cresce, aquele que se torna uma lenda, é aquele que entende que código rodando ganha de qualquer argumento.

PowerPoint aceita tudo; o compilador e o boleto da AWS não.

P&D nas trincheiras não é insubordinação. É Ownership extremo.
É a encarnação real daquele papo de "Sentimento de Dono" que o RH adora colocar em slides institucionais. A ironia é que para salvar o produto às vezes você precisa ignorar os processos. Você precisa se importar tanto com o resultado que está disposto a quebrar algumas regras para alcançá-lo.

O resumo da ópera:

1. Garanta suas entregas oficiais.
2. Encontre as brechas de tempo.
3. Construa o que é necessário não o que é pedido.
4. Esconda a complexidade mostre o valor.
5. Encontre quem sente a dor e mostre a cura.

Não peça permissão para inovar.

Agora, feche essa aba, olhe para o seu Jira e pergunte-se: Qual card eu vou usar para proteger a próxima inovação?