Problema: cultura de urgência e engenharia frágil, que vira retrabalho¶
Demandas viram retrabalho porque uma correção em um ponto costuma causar impacto em outros, e hoje a gente não tem barreiras confiáveis para detectar isso antes de publicar.
A gente está preso em um ciclo onde quase tudo vira urgente, a entrega sai na correria, e o problema aparece depois em outro lugar, exigindo mais correção e mais tempo perdido.
Este problema tem algumas peças que se reforçam. Quando elas se juntam, o resultado é previsível.
1) Urgência vira padrão, não exceção¶
Quando quase tudo chega como urgente, a decisão deixa de ser "como vamos fazer direito" e vira "como fazemos agora".
Isso pode até funcionar uma vez ou outra, mas no longo prazo o custo explode. A pressa não some. Ela vira retrabalho.
2) O sistema é muito interligado¶
O legado cresceu sem separar bem responsabilidades. Na prática, fluxos diferentes acabam compartilhando regras e rotinas, ou então repetem a mesma regra em lugares diferentes.
Então uma alteração feita para resolver um caso específico encosta em outro fluxo sem intenção.
3) Sem testes, a validação vira um palpite¶
Hoje a validação costuma ser manual, rápida e limitada ao que a pessoa lembra de testar.
Sem testes automatizados, a gente descobre impacto quando corretor e cliente já sentiram. Aí vira incidente, e o time larga o que estava fazendo para corrigir.
4) Sem documentação, a regra fica na cabeça de poucas pessoas¶
Sem documentação viva, dev novo precisa reconstruir contexto no susto. Cada demanda começa com investigação, e cada correção repete a mesma história.
5) Sem code review consistente, o risco passa despercebido¶
Code review não é burocracia. É o momento em que uma segunda pessoa faz as perguntas chatas que evitam problema.
Quando a urgência domina, esse filtro enfraquece. A chance de deixar passar um detalhe aumenta, e depois fica mais difícil achar a causa.
Como isso acontece hoje¶
O ciclo típico no legado costuma ser esse.
O ponto que mais desgasta não é só o erro existir.
É o custo invisível de troca de contexto, interrupção, investigação, correção e nova publicação.
E quanto mais consumidores diferentes a gente tem, maior o risco de uma mudança em um projeto quebrar outro sem ninguém perceber.
Exemplos reais que mostram o padrão¶
Os exemplos abaixo deixam bem visível o retrabalho por acoplamento, falta de visão do todo e falta de barreiras de qualidade.
Exemplo 1. Um ajuste no SCGP gerou erro no portal por link fixo¶
- Demanda original: TI-95
Objetivo: ao emitir a proposta de Aditivo de Alteração no SCGP, colocar um link abaixo do quadro de coberturas para o cliente consultar a descrição comercial.
- O erro que apareceu depois: TI-1523
O link foi atualizado no SCGP. No portal, a geração do PDF usava um link fixo no código. Esse link ficou antigo, e o portal passou a gerar proposta sem o acesso às descrições de cobertura.
O que isso escancara
- Existiam dois caminhos diferentes gerando a mesma proposta em PDF
- Um deles tinha regra fixada no código, o outro não
- A demanda foi feita olhando só para onde o solicitante opera, mas o impacto real atravessa canais
- Sem teste automatizado comparando o PDF gerado em cada canal, o erro só apareceu depois
- Sem uma revisão de código mais cuidadosa, ninguém fez a pergunta básica: onde mais esse PDF nasce
Resultado prático
- retrabalho para corrigir
- tempo perdido até achar a origem
- gente parada investigando em vez de evoluir produto
- cliente e corretor recebendo uma proposta pior do que antes
Exemplo 2. A tentativa de agilizar manutenção virou nova dor no Vidas¶
- Demanda original: TI-22
Objetivo: quando enviar uma manutenção por importação, até X vidas processar em tempo real. Acima disso seguir para a fila do Vidas.
- O que estourou depois: TI-164
O portal não fazia validação prévia das planilhas. Com o fluxo novo, dados ruins continuaram indo para o Vidas e viraram retrabalho operacional. A correção virou implementar validação no Vidas antes de importar.
O que isso escancara
- O portal empurra validação para o próximo sistema
- O Vidas vira a barreira final e também o lugar onde o erro aparece
- Quando a mudança entra na correria, validação vira detalhe que fica para depois
- Depois vira incidente, fila, e cobrança em cima do time
Resultado prático
- uma demanda vira duas em vez de uma
- suporte e operação gastam tempo corrigindo dados que poderiam ser barrados
- a confiança no processo cai, porque o corretor envia e só descobre problema depois
Exemplo 3. A mesma regra quebrando em dois lugares, por duplicação de lógica¶
-
Demanda: TI-1408
Contexto: ao importar planilha de relação de segurados, as situações ESTAGIÁRIO e PRESTADOR DE SERVIÇO não estavam salvando. -
O problema reapareceu: TI-1581
O ajuste foi feito na importação do Portal do Cliente. Só que existe importação também pelo Vidas. A dor voltou e exigiu outra correção.
O que isso escancara
- A mesma regra de negócio existe em mais de um lugar
- Uma correção feita só em um ponto não resolve o fluxo como um todo
- Isso é o tipo de coisa que um mapeamento simples evitaria: onde mais essa planilha entra
- Isso também é o tipo de coisa que teste automatizado pegaria, porque o cenário é repetível
Resultado prático
- uma demanda vira várias
- cada uma cai com uma pessoa diferente
- quatro desenvolvedores mexem na mesma funcionalidade espalhada
- todo mundo perde tempo entendendo o processo do zero
Exemplo 4. Projeto com escopo mudando toda semana, trabalho vira descartável¶
Caso: dashboard de campanhas
Toda semana o escopo muda. O que foi feito perde valor e precisa ser refeito. Além disso, quase sempre chega como urgente, então a entrega é feita com a corda no pescoço.
O que isso escancara
- sem escopo minimamente estabilizado, não existe planejamento real
- a gente investe tempo construindo e depois joga fora
- isso desorganiza o backlog inteiro, porque tudo concorre com urgência
Exemplo 5. Urgência que vira entrega em vão¶
Caso: descrição de coberturas para o superapp
Foi feito como urgente em agosto de 2025 porque o lançamento dependeria disso. Depois descobrimos que não foi usado e que o app nem lançou até hoje.
O aprendizado é direto
- urgência sem validação vira desperdício
- o desperdício rouba tempo das dores que estão acontecendo agora
O que piora o cenário no dia a dia¶
Interrupção constante¶
Além do backlog, existe a pressão diária de demanda chegando direto na sala.
Isso quebra foco. A gente fica trabalhando em várias coisas em paralelo, perde contexto e aumenta a chance de errar em detalhe pequeno.
No fim, o time vira um funil de urgência. Tudo entra. Nada tem espaço para ser feito com cuidado.
Falta de visão de projeto e de voz para TI¶
As demandas chegam para resolver um contexto específico, mas sem espaço para discutir impacto em outros fluxos.
Quando tudo é urgente, não existe o momento de parar e perguntar:
- isso vai mexer em quais canais
- onde essa regra também existe
- qual é a definição de pronto
- como a gente garante que não piorou o que já funciona
Um ponto positivo que precisa ser reconhecido¶
A gestão que a Michelle vem fazendo ajuda muito.
Ela tenta organizar fluxo, conversar com os outros setores e dar visibilidade do que cada um está fazendo. A daily também ajuda o time a se alinhar e se apoiar.
O problema é que isso está muito concentrado. Uma pessoa não consegue segurar a casa inteira sozinha.
Impactos no negócio¶
Tempo e retrabalho¶
Sem uma trilha consistente, cada erro vira investigação artesanal.
Isso consome tempo de desenvolvimento, suporte e operação.
Risco operacional¶
Quando não é claro qual canal gerou o comportamento, e por que, decisões acabam sendo tomadas por suposição.
Isso aumenta chance de correção errada, reincidência e desgaste com as áreas.
Risco de segurança¶
O legado já tem fragilidades conhecidas. Quando a cultura é correria, esses riscos ficam vivos por mais tempo, porque sempre tem outra urgência na frente.
Experiência do corretor e do cliente¶
- cliente recebe uma proposta sem contexto e abre chamado para entender cobertura
- corretor sente inconsistência entre portal, SCGP e outros canais
- áreas internas gastam tempo explicando e corrigindo em vez de evoluir produto
Como esse problema se conecta com os outros problemas do legado¶
Esse tema é o pano de fundo de quase todos os outros problemas que a gente está mapeando.
Em resumo, sem barreiras de qualidade, cada problema vira mais fácil de acontecer, mais difícil de detectar, e mais caro de corrigir.
O que a API Nova muda para reduzir isso e por quê¶
A API Nova não resolve cultura por mágica. Mas ela permite construir um jeito de trabalhar com proteção, com governança e com clareza.
Os pilares que quebram o ciclo são simples e precisam funcionar juntos: testes automatizados, code review e documentação.
E a arquitetura ajuda a tornar isso viável no dia a dia, porque reduz duplicação e deixa o caminho de mudança mais previsível.
1) Separação por consumidor, sem duplicar regra¶
Com BFFs por canal, cada consumidor pode ter seu formato de dados e suas telas, mas as regras de negócio ficam centralizadas.
Isso reduz o risco de existir uma regra em um canal e outra regra diferente em outro.
2) Contratos mais claros entre quem chama e quem responde¶
Quando o contrato é bem definido, fica mais fácil comparar comportamento entre canais e evitar divergência silenciosa.
3) Publicar com proteção, não no susto¶
Com entrega automatizada e testes desde o início, a gente para erro antes de chegar no corretor e no cliente.
4) Rastreabilidade para achar a causa sem virar caça ao tesouro¶
Quando dá para identificar de onde veio, o tempo de investigação cai. A correção fica mais direta.
5) Definição de pronto que inclui qualidade¶
Teste, code review e documentação deixam de ser opcional quando sobra tempo. Eles viram parte do trabalho.