Estimativa de uma troca de API de terceiros
Como avaliar a troca por uma API de terceiros: lacunas semânticas, execução paralela e os pressupostos embutidos nas peculiaridades do antigo fornecedor. 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 “isso é uma string, mas na verdade é uma data no formato deles”, “isso retorna null quando significa zero”, “isso limita a taxa de acesso silenciosamente”. Uma troca limpa 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 em paralelo: o fornecedor antigo e o novo operando simultaneamente, com comparação de resultados, até que a equipe tenha certeza de que o novo fornecedor atende às expectativas. Essa fase costuma ser mais demorada 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 é dito 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 guardando 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 fornecedor anterior que precisem ser transferidos para nós?
- Diferenças na 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 é “suficiente” para fazer a transição?
- Limites de taxa e modelo de preços no novo fornecedor: serã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; o trabalho está na prova de equivalência. Se a execução dual e a movimentação de dados forem reais, isso já é mais do que uma história: separá-las e dimensionar 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 de estimativas já realizadas, ou inicie uma sessão gratuita de Planning Poker quando o plano de execução em duas etapas estiver esboçado.