Estimativa de uma integração de pagamentos
Como fazer uma estimativa para uma integração de pagamentos: ambiente de teste x ambiente de produção, reembolsos, webhooks, idempotência, escopo PCI. A conversa que precisa acontecer antes que qualquer valor seja definido.
O bilhete diz “adicionar Stripe”. O texto diz “meio quarto”.
Os pagamentos têm uma interface de API pública que cabe em uma página e uma interface de decisão privada que não cabe. Escolher um provedor é um pico de trabalho de um dia. Configurar o fluxo normal de checkout leva alguns dias. Tudo o que vem depois (o fluxo de reembolso, a política de repetição de webhooks, as chaves de idempotência, o relatório de reconciliação que o departamento financeiro vai solicitar no segundo mês) é o recurso em si, e nada disso está no ticket.
A tarefa que diz “integrar o Stripe” raramente é a tarefa que está sendo estimada. A tarefa que está sendo estimada é “podemos receber pagamentos, reembolsá-los, comprovar que os recebemos e lidar com uma cobrança contestada”. Até que a equipe vote sobre esse escopo, o número é apenas uma estimativa sobre algo diferente.
O que se fala na sala
Backend: “O Sandbox é simples. A biblioteca cuida da maior parte do trabalho.”
SRE: “Os webhooks precisam de idempotência. Qual é a nossa estratégia de repetição de tentativa caso o Stripe reenvie a solicitação?”
Finanças: “Como são feitas as reconciliações de reembolsos? E os reembolsos parciais?”
Conformidade: “Estamos lidando com números de cartão ou continuamos no SAQ-A?”
PM: “O que diz o e-mail sobre o pagamento não realizado e quem o redige?”
Perguntas que vale a pena fazer antes de votar
- Primeiro apenas no ambiente de teste, ou chaves de produção já incluídas desde o primeiro dia?
- Reembolsos e reembolsos parciais: UI, API ou apenas para administradores?
- Idempotência de webhooks e gerenciamento de novas tentativas: quem é o responsável pela tabela de deduplicação?
- Âmbito da PCI: estamos cumprindo o SAQ-A ao nunca acessar o PAN?
- Reconciliação: quem elabora o relatório e com base em qual fonte de verdade?
- Experiência do usuário em situações de falha: cartões recusados, cartões vencidos e desafios do 3DS estão todos incluídos no escopo?
A abordagem correta para uma situação como essa costuma ser dividi-la. “Receber dinheiro” é uma parte; “reembolsar dinheiro” é outra; “conciliar dinheiro” é uma terceira. Considerá-las como um único item é o que leva a integração a ser entregue na terceira semana e o departamento financeiro a perguntar onde está o relatório na oitava semana.
Vote em “provar que recebemos o dinheiro e superamos a disputa”, e não em “chamar a API de finalização de compra”.
Relacionado: erros comuns no Planning Poker ao dividir histórias tarde demais; técnicas de estimativa para trabalhos com esse grau de imprecisão. Veja os outros exemplos práticos de estimativa ou inicie uma sessão gratuita de Planning Poker quando o refinamento estiver pronto.