Quando a gestão sente que a equipe está lenta

Mais cedo ou mais tarde chega a mesma frase, em algum comitê, dita em palavras diferentes: por que a equipe de desenvolvimento é tão lenta?

É um sentimento legítimo. A administração vê o mercado se movimentando, vê o lançamento da concorrência e não vê o produto avançando no ritmo esperado. O instinto é quase sempre o mesmo: mais pressão, mais gente, mais urgência. E é aí que a maioria das organizações diagnostica erroneamente.

O erro de diagnóstico

Desenvolvimento não é uma torneira que você abre com mais força. É um sistema com capacidade limitada. Nove mulheres grávidas não engravidam num mês. Você pode adicionar pessoas, pode pressionar, pode exigir “mais urgência” e, mesmo assim, o sistema tem um limite de quanto pode processar bem por vez. Colocar mais num sistema saturado não o acelera: satura-o mais, gera mais mudanças de contexto, mais dívidas, mais incidentes. Frederick Brooks documentou isso décadas atrás com Mythical Man-Month e é tão verdadeiro quanto era então.

This doesn't mean there are no levers within the system (there are, and I know them well because I've touched them all in 17 years of leading teams): good engineering practices, architecture that doesn't collapse under its own weight, trained people, correct tools. All of that matters. But it has diminishing marginal returns. You can optimize the system by 20-30%. You are not going to triple the speed by optimizing how what enters is processed.

A verdadeira vantagem está em outro lugar: o que decidimos entra no sistema.

As duas verdadeiras alavancas

Todo problema de “lentidão” pode ser separado em dois eixos:

Oferecer (como processamos): engenharia, equipamentos, tecnologia, treinamento.
Demanda (o que permitimos entrar): os riscos de negócios e produtos que comprometem essa capacidade escassa.

A maioria das organizações investe toda a sua energia na oferta e quase nenhuma na procura. Eles contratam, reorganizam, mudam sua metodologia e ainda não se perguntam se as apostas que estão fazendo no sistema fazem sentido para os negócios. Foi aí que vi o maior desperdício de capacidade em minha carreira: não linhas de código ruins, mas boas linhas de código construindo coisas que ainda não deveriam ser construídas, ou não deveriam ser construídas dessa maneira.

Quando a aposta não tem business case

Na Creditas vivi de perto o que significa estabelecer uma operação do zero em um novo mercado: contratar, formar equipes de alta performance e, acima de tudo, decidir o que construir primeiro quando tudo parece urgente. Com Creditas Store, Creditas Benefícios e Creditas Auto na mesa, a disciplina não estava em programar rapidamente, mas em ter claro qual aposta merecia capacidade de engenharia e qual não merecia, com objetivos e OKRs que exigiam justificar o porquê antes do como. Quando existe essa disciplina, “ir devagar” deixa de ser o problema, pois o que entra no sistema já está filtrado pelo senso empresarial.

Quando algo não aumenta e te pega

Na Enterticket o desafio era outro: um produto legado que precisava se modernizar e abrir para novos mercados, sem parar o negócio. A tentação fácil é reescrever totalmente, passar meses ou anos “consertando tudo por dentro” enquanto o negócio espera. Escolhemos o oposto: modernização evolutiva, arquitetura hexagonal e microsserviços onde proporcionassem valor real, e foco no lançamento do novo portal de compras e expansão para o México com Product-Led Growth. A governança do produto era a chave, decidir o que merecia investimento arquitetônico e o que não merecia, em vez de ficar preso indefinidamente refatorando algo que o negócio não precisava mais daquela forma.

Quando o crescimento acelerado exige filtragem, não apenas execução

Em fases de alto crescimento, algo que vivi de perto na RD Station, tudo parece urgente ao mesmo tempo. O risco aí não é a falta de execução, é a falta de filtro: quando alguma iniciativa parece razoável, o sistema fica cheio de apostas medíocres concorrendo pela mesma escassa capacidade. A cultura Lean é demonstrada ali mesmo: meça antes de escalar, valide antes de comprometer meses de engenharia e use Kanban não como decoração, mas como uma forma real de tornar visível o quanto está “em vôo” de cada vez, porque o que não é visto não é gerenciado, e o que não tem limite de WIP acumula silenciosamente até “tudo ficar lento”.

O que realmente muda a percepção da velocidade

Tendo isso em mente, a lista do que realmente move a agulha não é técnica em primeiro lugar, é negócio, cultura e governança:

Metas e objetivos claros: sem um objetivo comercial claro, qualquer iniciativa parece igualmente urgente e é aí que se perde capacidade.
Boas apostas com business case: Toda grande iniciativa deve justificar por que merece capacidade de desenvolvimento antes de cometê-la, e não depois.
Pensamento e valores Lean: valide antes de escalar, avalie antes de se comprometer, elimine rapidamente o que não funciona.
Evidencie o trabalho, Kanban: deixe visível o quanto está em andamento, onde está travado e quanto custa cada coisa em capacidade real.
Ajustar a cultura: a velocidade percebida também é uma questão de confiança e alinhamento, não apenas de entrega.
Recompense o bom, demita o tóxico: A baixa capacidade é destruída mais rapidamente por uma má atitude tolerada do que por uma má decisão técnica.
Treinar a equipe: Investir nas pessoas é investir na única parte do sistema que melhora com o tempo se for bem cuidada.

Lista de verificação prática para a alta administração

Antes de perguntar “por que somos lentos?”, pergunte-se o seguinte:

1. Toda grande aposta tem um caso de negócio explícito antes de comprometer a capacidade de desenvolvimento?
2. Sabemos, em determinado momento, quanto temos “em voo” por vez (WIP)?
3. Revisamos as apostas em andamento (não apenas as novas) e eliminamos aquelas que não estão funcionando?
4. Quem tem autoridade real para dizer não a uma iniciativa, e essa autoridade é utilizada?
5. Estamos recompensando aqueles que contribuem e sendo honestos com aqueles que não se enquadram na cultura?
6. Investimos na capacitação da equipe ou apenas em exigir mais dela?
7. Medimos a capacidade de desenvolvimento como uma restrição empresarial e não como uma falha de engenharia?

Se a maioria dessas respostas for “não”, o problema nunca foi a velocidade do computador. Foi o que decidimos colocar em um sistema que, por definição, nunca seria capaz de lidar com tudo de uma vez.