Sustentação não é castigo. É estratégia.

A área de sustentação é aquele lugar da empresa que ninguém coloca no LinkedIn.

É onde os roadmaps morrem temporariamente, os clientes ligam exaltados e o código legado revela decisões tomadas em 2014 que ninguém mais lembra por quê.

É também onde a tecnologia ganha fama de “não resolve nada na causa raiz” — apenas remenda.

Quando eu assumi a área, o cenário era simples de explicar e difícil de viver: 160 chamados por dia, aplicação praticamente bloqueada, usuários insatisfeitos e uma área inteira desacreditada.

E não, não era exagero.

A sensação era de estar se afogando — e a correnteza não dava nenhum sinal de que ia diminuir.

A primeira decisão não teve nada de inspiradora. Foi operacional: montar uma força-tarefa. Quase 15 desenvolvedores dedicados exclusivamente a estabilizar a plataforma. Nenhum deles tinha histórico profundo no sistema. Documentação inexistente. A lógica do negócio era descoberta no debug, linha por linha, como se estivéssemos traduzindo um dialeto antigo.

Ali eu precisei assumir um papel que não me diverte: general.

Foco absoluto. Priorização centralizada. Nada de “rapidinhas no roadmap”. Nada de inovação. Nada de feature charmosa para agradar stakeholder.

Porque inovação com a base quebrada é só ilusão bem diagramada.

Foram três meses assim.

Três meses vendo o número de chamados cair lentamente. Quase ofensivamente lento.

Enquanto isso, todas as outras squads estavam praticamente congeladas. Zero evolução relevante de produto. E todo profissional de produto sabe o que significa backlog parado: pressão diária com cheiro de urgência estratégica.

Todavia produto é um eterno exercício de trade-off. E negociação com diretoria não é reunião pontual — é repetição disciplinada do acordo feito. Todos os dias.

Ou estabilizávamos a plataforma, ou não existiria futuro para evoluir nada.

Depois de três meses, a plataforma estava estável. Não perfeita. Estável. Já era uma vitória.

Reduzimos o time dedicado à sustentação e redistribuímos desenvolvedores para as squads; mas eu sabia que, se nada estrutural mudasse, em pouco tempo voltaríamos ao modo sobrevivência.

Até então, ticket era sinônimo de resolver e seguir para o próximo. Eu comecei a olhar diferente. Passei a me perguntar o que aqueles tickets representavam. Qual era o padrão? Como priorizar sem depender do barulho do N1 ou da interpretação subjetiva do N2? Como tornar a decisão incontestável, independentemente do cargo de quem estivesse pressionando?

Eu precisava de algo que não dependesse de barulho. Precisava de lógica. Precisava ser incontestável.

Fiquei semanas com uma pergunta simples na cabeça: o que nunca é contestado?

Número.

Comecei a testar fórmulas até chegar em um modelo que combinava quatro variáveis:

impacto na receita, volume proporcional de tickets, criticidade para o usuário e esforço de implementação.

A equação ficou assim:

(Impacto × Volume × Criticidade) – Esforço

Cada variável variava de 0 a 1.

• Impacto era direto: está afetando receita ou não?

• Volume colocava proporcionalidade na discussão — não era sobre quem gritava mais, era sobre quem aparecia mais.

• Criticidade avaliava se o usuário conseguia continuar usando a plataforma ou estava totalmente bloqueado.

• E o esforço, estimado junto ao líder técnico, impedia que a gente romantizasse soluções gigantes para problemas pequenos.

Objetivo. Sem espaço para drama.

Criar a fórmula foi a parte fácil. Implementar o processo foi outra história.

Eu não podia simplesmente impor SLAs agressivos de um dia para o outro. O time precisava se adaptar.

No primeiro mês, batemos apenas 60% dos SLAs — isso considerando tickets de baixa criticidade com prazo de aproximadamente três dias.

Três dias.

Senti uma leve derrota. Pensei que minha fórmula não era efetiva. Quis mudar o formato.

Bati a cabeça por alguns dias — e quem trabalha com Produto sabe que não temos o luxo de passar semanas desenhando alternativas perfeitas.

Então eu fiz um teste diferente: e se a meta deixasse de ser minha cobrança e virasse responsabilidade coletiva?

O time não teve muita escolha e comprou o desafio do quarter: 90% de atendimento dentro do SLA.

O acompanhamento passou a ser semanal. E as conversas mudaram.

• Onde estamos falhando?

• Que tipo de criticidade mais estoura prazo?

• Esse problema é recorrente?

• Quem tem mais domínio sobre esse tema?

Os tickets começaram a ser distribuídos de forma estratégica. O time passou a discutir causa raiz com mais frequência.

Sustentação deixou de ser apenas reação e começou a gerar inteligência sobre o produto.

O grande insight não foi a fórmula em si.

Foi perceber que o caos não vinha da quantidade de chamados.Vinha da ausência de critério.

Enquanto a priorização era emocional, a área vivia no modo sobrevivência. Quando virou matemática, virou gestão.

E isso mudou completamente a conversa.

Sustentação deixou de ser “o lugar onde nada evolui” e passou a ser a base que permite evolução com segurança.

Porque no fim do dia, produto não é sobre lançar feature nova.

É sobre assumir consequência.

Inclusive a consequência de parar tudo por três meses para arrumar a base — enquanto todo mundo pergunta quando sai a próxima novidade.