3 plataformas. 1 janela de release. R$ 22M em transações protegidas.
Atuei na Dimensa como Product Owner de um squad de 9 pessoas (UX, QA, iOS, Android e backend), responsável por aplicativos mobile (iOS e Android), internet banking e painéis de controle de instituições financeiras, integrados a um parceiro de BaaS (Pix, TED e boleto).
Em janeiro, a Receita Federal anunciou: a partir de julho de 2026, CNPJs passariam a ter letras. Para as plataformas de instituições financeiras que processaram R$ 22M em transações (PIX + TED) entre janeiro e agosto, isso era risco direto — CNPJs alfanuméricos seriam rejeitados pelas validações existentes, travando a operação.
Dependências externas: BaaS, Receita Federal e Bacen. Qualquer leitura errada virava bug em produção, sem margem para reverter.
Priorizei o painel de controle antes dos apps para reaproveitar a estrutura de endpoints nos demais clientes e reduzir retrabalho de engenharia — e também por ser onde estava a maior complexidade (20+ endpoints). Mapeei documentação de BaaS, Receita Federal e Bacen antes de abrir qualquer chamado. Conduzi refinamento de backend e frontend em paralelo. Trouxe QA para desenhar cenários de teste antes do desenvolvimento começar.
Documentação mapeada → painel de controle definido como ponto de partida → back e front refinando em paralelo → QA com cenários prontos antes do código → release única, sem rollback.
Começar pelo painel de controle, não pelos apps.
Por quêReaproveitar a estrutura de endpoints nos demais clientes reduzia retrabalho de engenharia; além disso, ali estava a maior complexidade (20+ endpoints) e validar primeiro reduzia risco no mobile.
ImpactoMenos retrabalho de engenharia e comportamento mobile mais previsível de estimar e testar.
Mapear toda a documentação externa antes do refinamento.
Por quêTrês fontes regulatórias distintas, fora do controle direto do time; erro de leitura vira requisito errado.
ImpactoRefinamento partiu de requisitos verificados, não de suposições.
QA desenhando cenários antes do desenvolvimento.
Por quêRelease única, sem rollback; o que não fosse mapeado antes só apareceria em produção.
Impacto100% de conformidade, sem impacto na operação.
Chamar as pessoas certas para desenhar cenários antes do desenvolvimento tornou previsível mapear impedimentos que só apareceriam depois: necessidade de remessa de boletos, dependências entre plataformas, comportamento no internet banking e nos aplicativos.
Alinhar os times antes de construir deixou de ser prática pontual e virou o raciocínio que carrego para qualquer projeto novo.