Estimativa de uma integração de pagamentos
Como estimar uma integração de pagamentos: ambiente de teste x ambiente de produção, reembolsos, webhooks, idempotência, escopo do 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. A escolha de um provedor representa um pico de trabalho de um dia. A configuração do 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 valor é apenas uma estimativa sobre algo diferente.
O que é dito 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 os reembolsos são reconciliados? E os reembolsos parciais?”
Conformidade: “Estamos acessando números de cartão ou continuamos na categoria 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 com chaves de produção 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 do 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 referência?
- Experiência do usuário em situações de falha: cartões recusados, cartões vencidos e solicitações de 3DS estão todos incluídos no escopo?
A abordagem correta em uma situação como essa costuma ser dividi-la. “Receber dinheiro” é uma parte; “reembolsar dinheiro” é outra; “conciliar dinheiro” é uma terceira. Estimá-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”.
Veja também: erros comuns no Planning Poker relacionados à divisão tardia de histórias; técnicas de estimativa para trabalhos com esse grau de imprecisão. Confira os outros exemplos práticos de estimativa, ou participe de uma sessão gratuita de Planning Poker quando o refinamento estiver pronto.