BANK FACTORY ENGINEERING

Fluxo de Engenharia
& Qualidade

Um guia estruturado sobre como transformamos ideias vagas em software bancário confiável.

Objetivo Eliminar retrabalho e riscos não mapeados.
Público Produto, Negócios e Tech.

Por que precisamos de processo?

A Ilusão da Simplicidade

"É só um botão de pagar boleto."

Na prática, isso envolve:

  • Integração com BaaS (Matera/Dock)
  • Tratamento de timeout
  • Comprovantes e conciliação

O Custo do "Faz logo"

Quando pulamos etapas, o time de tech descobre a complexidade durante o desenvolvimento.

Resultado: Prazos estourados e software com bugs.

O Princípio da Descoberta

Nenhuma demanda ganha prazo de entrega antes de ser totalmente compreendida tecnicamente.

Incerteza = Sem Prazo

O Ciclo de Vida da Demanda

Entenda o que acontece em cada etapa e qual é a saída esperada.

Fase 1

Intake

O pedido chega (Slack, Reunião). Ainda é apenas uma ideia bruta.

Saída:
Card na Triagem
Fase 2

Discovery

PM e Tech validam APIs, regras de negócio e viabilidade.

Saída:
Doc de Escopo
Fase 3

Sizing

Time técnico avalia o esforço baseado no Discovery pronto.

Saída:
Tamanho (P/M/G)
Fase 4

Priorização

Negócio decide o que fazer agora sabendo o "preço" (tamanho).

Saída:
Posição na Fila
Fase 5

Ready

História refinada, quebrada e pronta para Dev.

Saída:
Sprint Backlog

"Só damos prazos após a fase 3 (Sizing). Antes disso, tudo é estimativa de ordem de grandeza."

Estrutura de uma User Story

Por que escrevemos cada seção? (Passe o mouse ou toque para entender)

Título

[Ação] + [Objeto] + [Contexto]
Didática: Ajuda qualquer um a bater o olho no board e saber do que se trata sem abrir o card.

1. O Porquê (Problema)

Explique a dor original.
Ex: "O cliente não sabe por que o pagamento falhou."

2. Para Quem (Persona)

Quem vai usar? O gerente? O cliente final? O suporte?

3. O que acontece (Fluxo)

Descreva a interação passo a passo, linguagem natural.

1. Usuário clica em 'Pagar'
2. Sistema valida saldo
3. Sistema chama API externa

4. Dependências (BaaS)

A parte mais crítica. Liste o endpoint exato.

Endpoint Status
POST /transfers Testado OK

5. Critérios de Aceite

Como sei que acabou? Lista binária (Sim/Não).

  • Mensagem de erro amigável aparece?
  • Saldo atualiza em < 2s?

DoR: O Checklist de Entrada

Para entrar na Sprint, a tarefa deve cumprir todos os requisitos abaixo.
Faltou um? Volta para o Backlog.

Negócio & Produto

  • Problema está claro (não só a solução).
  • Existe um "Dono" para tirar dúvidas.
  • Critérios de aceite são testáveis.

Engenharia

  • Viabilidade técnica confirmada.
  • Estimativa (Size) realizada.
  • Sem dúvidas pendentes.

Integrações & Terceiros (Obrigatório)

  • Endpoints documentados.
  • Credenciais de Sandbox disponíveis.
Regra de Ouro:
Se não testamos o endpoint no Sandbox do parceiro, a tarefa não está Ready.

Resumo das Regras

01

Sobre Prazos

Só existe prazo após o Sizing. Antes disso, estamos em Discovery e trabalhamos com janelas de tempo, não datas fixas.

02

Sobre BaaS

Não assumimos que a documentação do parceiro está certa. Validamos no código antes de prometer entrega.

03

Sobre Qualidade

Se a User Story não está clara ou falta critério de aceite, ela não entra na Sprint. Melhor atrasar o início do que o fim.