Uma licença indisponível. Um cronograma a cumprir. 30 mil euros economizados. Veja como uma equipe ágil transforma um bloqueio em valor entregue.
O cenário que ninguém quer viver
Janeiro de 2026. O projeto começa.
O objetivo: modernizar a gestão dos contratos coletivos de Saúde e Previdência de um grande player de saúde suplementar. Trocar uma gestão 100% manual por uma ferramenta de interface centralizada, rastreável, conectada ao Datahub. Três lotes, sprints de duas semanas, um roadmap até o T3 de 2026.
Tudo encaixado. A equipe está no lugar: Product Owner, Data Engineer, CTO, sponsors do lado do cliente. A governança está definida. As cerimônias ágeis estão no calendário.
E então, logo na partida: a licença PIMCORE, identificada como pré-requisito central de toda a ingestão de dados, não está disponível.
Sem licença. Sem ambiente. Sem base para trabalhar.
Num projeto em cascata clássico, é bloqueio total. A gente espera. A gente escala. A gente adia o cronograma. A gente volta ao comitê de direção com um slide vermelho.
Não foi o que aconteceu.
O que a equipe fez no lugar
A equipe da Bomzai desenvolveu um script de ingestão de dados sob medida para contornar a dependência da licença.
Não um contorno improvisado. Uma ferramenta funcional, em produção, capaz de ingerir os dados necessários para começar o lote 1 sem passar pelo PIMCORE.
Resultado: o ritmo dos sprints de duas semanas se mantém. O cronograma não é adiado. O cliente não precisa financiar uma licença que ainda não usa, nem esperar que ela fique disponível para começar a ver valor.
30 mil euros economizados. Cronograma cumprido. Valor entregue já no primeiro sprint.
Esse número pede uma pausa. Não porque impressione por si. Porque mostra exatamente o que a agilidade deve produzir: uma equipe que absorve um obstáculo e segue criando valor, sem esperar a permissão do pré-requisito.
Projeto Bomzai - Ferramenta de gestão de contrato coletivo Saúde & Previdência, 2026
O que o Manifesto Ágil realmente diz sobre isso
O Manifesto Ágil tem 24 anos. Fala-se muito nele. Aplica-se menos do que se pensa.
Aqui vão dois princípios fundadores, lidos à luz deste projeto:
Princípio 2: "Acolha favoravelmente as mudanças de necessidades, mesmo tarde no desenvolvimento."
A licença indisponível não é uma mudança de necessidade no sentido estrito. É uma restrição externa, não prevista, que muda o campo de jogo desde o início. O espírito do princípio é o mesmo: não tratar o obstáculo como uma anomalia que invalida o plano, e sim como um dado que a equipe absorve e contorna.
Princípio 11: "As melhores arquiteturas, especificações e concepções emergem de equipes auto-organizadas."
Foi exatamente o que aconteceu. Ninguém pediu à equipe que desenvolvesse um script de ingestão. Não estava no backlog inicial. A equipe viu o problema, identificou uma solução técnica e colocou em prática. Sem escalada inútil. Sem esperar um aval do comitê.
É isso, uma equipe auto-organizada. Não uma equipe que preenche as colunas do Jira direitinho.
Agilidade real versus agilidade de fachada
Neste ponto, vale ser honesto.
Muitos projetos se dizem ágeis porque fazem stand-ups diários, retrospectivas na sexta e sprint reviews com PowerPoint. Isso é a forma. Não é o fundo.
Agilidade real é o que acontece quando o pré-requisito some no sprint 1.
A equipe espera? Escala na hora, jogando a responsabilidade na restrição? Ou muda o caminho, acha uma solução e mantém o rumo no valor a entregar?
O Manifesto Ágil coloca "responder à mudança" acima de "seguir um plano". Não porque os planos sejam inúteis. O kick-off deste projeto tinha um roadmap preciso, marcos claros, uma governança documentada. Mas porque a capacidade de se adaptar vale mais do que a capacidade de cumprir um plano num mundo que não muda.
Projetos de Data e IA vivem num mundo que muda. As licenças não estão disponíveis. As fontes de dados não estão prontas. Os filtros de negócio são mais complexos do que o previsto. Os sponsors mudam de prioridade. Não é a exceção. É a regra.
O que isso exige, na prática, de uma equipe
Fazer uma equipe reagir como a deste projeto não se decreta. Constrói-se.
01. Uma cultura do "entregar mesmo assim"
O objetivo do sprint não muda só porque uma ferramenta não está disponível. A gente busca outro caminho. Se ele não existe, a gente constrói. O valor a entregar segue como bússola.
02. A proximidade técnica do Product Owner
Neste projeto, a governança incluía o PO nos sprint plannings e nas revisões. Um PO que entende as restrições técnicas valida rápido uma solução de contorno, sem esperar uma reunião de comitê.
03. Sprints curtos como redes de segurança
Duas semanas. Não quatro, não seis. Sprints curtos obrigam a decidir rápido. Se uma solução não funciona, a gente descobre em duas semanas, não em dois meses. O erro fica contido. O aprendizado é imediato.
04. A confiança como infraestrutura
O cliente não pediu um relatório de incidente quando a licença PIMCORE se mostrou indisponível. Confiou na equipe. Essa confiança não vem de fábrica. Ganha-se sprint após sprint, entrega após entrega.
O risco que já constava no registro desde o início
Um último ponto, e não é detalhe.
No kick-off de janeiro de 2026, o registro de riscos dizia:
R1 · Probabilidade 5/5 · Severidade 5/5: "Dificuldade de instalar o PIMCORE via Docker em ambiente local." Meio de mitigação: tratar na fase de init.
Esse risco estava classificado como crítico. A equipe o gerenciou. Na fase de init. Exatamente como previsto, só que não do jeito previsto.
É isso também, gestão de risco ágil. Não cuidar do risco na esperança de que ele não se concretize. Cuidar dele construindo a capacidade de responder quando ele se concretiza.
O que fica deste projeto
Agilidade não é uma metodologia de gestão de projeto. É uma postura diante da incerteza.
Neste projeto, essa postura produziu um resultado mensurável: 30 mil euros economizados, um cronograma cumprido, uma equipe que transformou um bloqueio em decisão técnica em menos de um sprint.
Não é sorte. É o resultado de uma equipe que incorporou o que o Manifesto Ágil diz desde 2001: o valor não vem de cumprir o plano. Vem da capacidade de se adaptar quando o plano encontra a realidade.
A Bomzai acompanha seus clientes da estratégia de Data e IA até a entrada em produção. Parceira operacional, não prestadora pontual.
