Baseline de Bilhetagem Digital: Reverse Engineering de Produto Sem Acesso ao Legado

Uma operadora pública de transporte de uma grande metrópole brasileira opera canais digitais de bilhetagem (cadastro, login, compra de créditos, recarga, segunda via, bloqueio de cartão, gratuidades) usados diariamente pelos passageiros da rede. Por trás desses canais, um front-end moderno convive com um back-end legado de mais de uma geração: páginas server-side, sessão opaca, sem APIs versionadas, sem idempotência e com mensagens de erro genéricas.

O risco mais sensível dessa arquitetura tem nome: pago sem creditar. Timeouts entre gateway de pagamento, checkout e núcleo transacional, sem retry nem conciliação explícita, abrem espaço para cobrança sem crédito, pedidos duplicados e conciliação manual em planilha. Somam-se duplicidade cadastral entre sistemas, autenticação frágil (sessão presa a cookie de servidor, sem MFA padronizado nem revogação de tokens) e experiência inconsistente entre canais, sem catálogo único de mensagens de erro nem padrão de acessibilidade.

O agravante: não existia baseline confiável de como o produto realmente funcionava. E a avaliação precisava acontecer sem acesso direto aos ambientes legados, ao código-fonte ou aos bancos de dados. Qualquer afirmação teria que ser sustentada por evidência observável de fora.

Conduzi uma avaliação técnica independente dos canais digitais de bilhetagem, na perspectiva de Product Owner, ao longo de 8 semanas. O método central foi reverse engineering de produto UI-first: naveguei os fluxos reais como usuário, capturei evidências (telas, rotas, tráfego de rede) e inferi contratos, regras de negócio e estados de domínio a partir do comportamento observado. Cada laudo declara sua premissa inferencial e atribui nível de confiança (alto, médio ou baixo) a cada achado.

A cobertura fechou em 9 frentes: 7 jornadas digitais de usuário (cadastro de passageiro identificado, login/SSO, compra web de créditos, recarga via app, segunda via, bloqueio/estorno e gratuidade para idosos) mais 2 diagnósticos de área, um sobre atendimento e comercialização, outro sobre a tecnologia central de bilhetagem. O resultado se materializou em 16 laudos técnicos, todos com a mesma estrutura de 5 seções: contexto, metodologia, evidências, diagnóstico e recomendações priorizadas.

Cada jornada começou por uma matriz de cenários em 5 categorias (caminho feliz, erro comum, exceção, offline/retry e timeout/autenticação); nos fluxos centrais, 64 cenários ganharam ID único e rastreável. Os cenários viraram critérios de aceite em Gherkin, com requisitos não funcionais anexados: latência P95 por operação, disponibilidade e acessibilidade WCAG AA como padrão de canal.

Para destravar a convivência entre o front novo e o legado, prototipei contratos OpenAPI v0.1 para 4 domínios (autenticação sobre OIDC/OAuth2, cadastro, compra e recarga), acompanhados de um delta novo↔legado com as diferenças qualificadas por impacto. Cada fluxo ganhou 3 mini-ADRs (limites, fallback e tratamento de erros), totalizando 12 ADRs como guardrails de decisão para o time que construir a próxima geração.

A espinha dorsal do método foi a rastreabilidade de ponta a ponta: premissa → evidência → cenário → endpoint → ADR. Nenhuma recomendação ficou solta; todas apontam para a evidência que as sustenta. Nos diagnósticos de área, 20 requisitos formais foram priorizados com RICE, e as hipóteses de evolução receberam metas quantificadas, propostas como alvo a validar e não como resultado: retries com backoff, push de status em menos de 30 segundos, conciliação com mínimo de intervenção manual.

O fechamento converteu diagnóstico em plano: 12 itens de backlog em formato PBB (Problema–Benefício–Behavior), cada um com cenários, NFRs, ADRs, dependências e DoR/DoD explícitos. Um time novo consegue pegar qualquer item e saber exatamente qual evidência o originou e qual decisão de arquitetura o restringe.

• 16 laudos técnicos entregues em 8 semanas, com estrutura padronizada e governança documental versionada
• 9 frentes cobertas: 7 jornadas digitais de usuário + 2 diagnósticos de área
• 64 cenários de aceite em Gherkin, com IDs rastreáveis por fluxo
• 4 contratos OpenAPI v0.1, 12 ADRs e 12 itens de backlog PBB priorizados, além de 20 requisitos avaliados com RICE

O aprendizado central: dá para construir baseline de produto confiável sem uma linha de acesso ao código legado, desde que cada afirmação declare sua premissa, carregue evidência e assuma um nível de confiança. Rastreabilidade não é burocracia; é o que transforma opinião técnica em documento que sustenta decisão.