Estimativa da substituição de uma API de terceiros
Como avaliar a substituição de uma API de terceiros: lacunas semânticas, execução paralela e os pressupostos embutidos nas peculiaridades do fornecedor anterior. A nova API apenas parece idêntica.
A API do novo fornecedor parece idêntica até você começar a migrar os dados.
O argumento para trocar de fornecedor é sempre o mesmo: a nova API é mais limpa, mais rápida e mais barata. A armadilha é que as peculiaridades da API antiga são fundamentais para o funcionamento do sistema. A base de código acumula dois anos de casos como “isso é uma string, mas na verdade é uma data no formato deles”, “isso retorna null quando significa zero”, “isso limita a taxa de acesso silenciosamente” — e uma troca completa significa reproduzir cada uma dessas peculiaridades de acordo com o comportamento do novo fornecedor, que é diferente de maneiras que ninguém documentou.
A estimativa deve levar em conta a operação paralela: o fornecedor antigo e o novo funcionando lado a lado, com comparação de resultados, até que a equipe tenha certeza de que o novo fornecedor está à altura. Essa fase costuma ser mais longa do que a implementação. As histórias que não levam isso em conta lançam o novo fornecedor e só descobrem as falhas na próxima vez que os dados de um cliente se depararem com um caso extremo.
O que se fala na sala
Backend: “O novo SDK é melhor. As chamadas básicas levam um dia cada.”
Líder: “E quanto aos dados históricos que eles estão mantendo para nós?”
SRE: “Vamos operar com os dois fornecedores ao mesmo tempo ou faremos a migração?”
Backend: “O formato do webhook deles é diferente. O mesmo vale para a autenticação.”
QA: “Como verificamos a equivalência — comparando as respostas ao longo de uma semana?”
Perguntas que vale a pena fazer antes de votar
- Existem dados históricos no antigo fornecedor que precisem ser transferidos para nós?
- Diferenças de autenticação — chaves de API, OAuth, solicitações assinadas?
- Webhooks: os eventos se mapeiam diretamente ou precisamos fazer uma conversão?
- Período de operação dupla: quanto tempo dura e o que é considerado “suficiente” para fazer a transição?
- Limites de taxa e modelo de preços do novo fornecedor — são iguais ou diferentes?
- Reverta: será que podemos voltar atrás caso o novo fornecedor se mostre pior?
As chamadas básicas são fáceis; a prova de equivalência é que dá trabalho. Se a execução dual e a movimentação de dados forem reais, isso já é mais do que uma história — separem-nas e dimensionem a verificação separadamente da implementação.
Faça um orçamento para a execução dupla e a verificação de equivalência. A API de aparência limpa é a parte mais barata.
Assim como estimar uma migração de banco de dados, o código é rápido e o trabalho está na implementação. Confira os outros exemplos práticos de estimativa, ou inicie uma sessão gratuita de Planning Poker quando o plano de execução em duas etapas estiver esboçado.