9 min leitura • Guide 774 of 877
Integração com Fornecedores e Terceiros
Integrações de terceiros adicionam complexidade e dependências. O GitScrum ajuda equipes a planejar trabalho de integração, gerenciar relacionamentos com fornecedores e rastrear dependências externas.
Planejamento de Integração
Avaliação da Integração
AVALIAÇÃO DE INTEGRAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DE COMEÇAR INTEGRAÇÃO: │
│ │
│ AVALIAÇÃO DO FORNECEDOR: │
│ ☐ Qualidade da documentação da API? │
│ ☐ Ambiente sandbox/teste disponível? │
│ ☐ Responsividade do suporte? │
│ ☐ SLA e histórico de uptime? │
│ ☐ Histórico de breaking changes? │
│ ☐ Bibliotecas client disponíveis? │
│ │
│ AVALIAÇÃO TÉCNICA: │
│ ☐ Método de autenticação (OAuth, API key, etc.) │
│ ☐ Rate limits e quotas? │
│ ☐ Formato de dados (REST, GraphQL, SOAP)? │
│ ☐ Suporte a webhooks? │
│ ☐ Suporte a idempotência? │
│ │
│ AVALIAÇÃO DE RISCO: │
│ ☐ E se o fornecedor ficar fora do ar? │
│ ☐ E se a API mudar? │
│ ☐ E se atingir rate limit? │
│ ☐ Implicações de privacidade de dados? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TAREFA DE AVALIAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INT-001: Avaliar Integração Stripe ││
│ │ ││
│ │ Propósito: Processamento de pagamentos ││
│ │ ││
│ │ Descobertas: ││
│ │ ✅ Documentação excelente ││
│ │ ✅ Modo teste com comportamento realista ││
│ │ ✅ SDKs oficiais para nossa stack ││
│ │ ⚠️ Verificação de webhook necessária ││
│ │ ⚠️ Considerações de PCI compliance ││
│ │ ││
│ │ Estimativa: 2-3 semanas para integração completa ││
│ │ Risco: Baixo (API madura, bom suporte) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Épico de Integração
BREAKDOWN DE TRABALHO DE INTEGRAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ÉPICO DE INTEGRAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INT-010: Integração de Pagamento Stripe ││
│ │ ││
│ │ Objetivo: Aceitar pagamentos com cartão de crédito ││
│ │ Fornecedor: Stripe ││
│ │ Timeline: Sprint 5-6 ││
│ │ ││
│ │ SETUP: ││
│ │ ├── INT-011: Configuração da conta Stripe ││
│ │ ├── INT-012: Gerenciamento de chaves API ││
│ │ └── INT-013: Setup de endpoint de webhook ││
│ │ ││
│ │ INTEGRAÇÃO CORE: ││
│ │ ├── INT-014: Criação de payment intent ││
│ │ ├── INT-015: Fluxo de checkout ││
│ │ ├── INT-016: Confirmação de pagamento ││
│ │ └── INT-017: Tratamento de reembolso ││
│ │ ││
│ │ CONFIABILIDADE: ││
│ │ ├── INT-018: Tratamento de erros ││
│ │ ├── INT-019: Lógica de retry ││
│ │ ├── INT-020: Verificação de webhook ││
│ │ └── INT-021: Idempotência ││
│ │ ││
│ │ MONITORAMENTO: ││
│ │ ├── INT-022: Métricas de pagamento ││
│ │ ├── INT-023: Alertas de falha ││
│ │ └── INT-024: Reconciliação ││
│ │ ││
│ │ TESTES: ││
│ │ ├── INT-025: Verificação em modo teste ││
│ │ └── INT-026: Testes de edge cases ││
│ │ ││
│ │ DOCUMENTAÇÃO: ││
│ │ └── INT-027: Documentação da integração ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Dependências de Fornecedor
Rastreando Bloqueios Externos
GERENCIAMENTO DE DEPENDÊNCIA DE FORNECEDOR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BLOQUEADO POR FORNECEDOR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 INT-014: Criação de payment intent ││
│ │ ││
│ │ Status: BLOQUEADO ││
│ │ Bloqueio: Aguardando credenciais API do fornecedor ││
│ │ Solicitado: 15 Jan ││
│ │ Follow-up: 18 Jan ││
│ │ Prazo: 22 Jan ││
│ │ Contato: suporte@stripe.com ││
│ │ ││
│ │ Histórico: ││
│ │ 15 Jan: Solicitação inicial enviada ││
│ │ 17 Jan: Auto-reply recebido ││
│ │ 18 Jan: Follow-up enviado ││
│ │ 19 Jan: Resposta - precisa aprovação interna ││
│ │ 20 Jan: Aprovação concedida, aguardando setup ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RASTREAMENTO DE COMUNICAÇÃO: │
│ ├── Log de todos os contatos com fornecedor │
│ ├── Datas e responsáveis │
│ ├── Próximos passos acordados │
│ ├── Escalation path se necessário │
│ └── Plano B se não responder │
└─────────────────────────────────────────────────────────────┘
Gerenciando Múltiplas Dependências
MATRIZ DE DEPENDÊNCIAS EXTERNAS
═══════════════════════════════
VISÃO GERAL:
─────────────────────────────────────
┌───────────────────────────────────────────────────────┐
│ Fornecedor │ Status │ Prazo │ Impacto │
├───────────────────────────────────────────────────────┤
│ Stripe │ 🟡 Em prog│ 22 Jan │ Crítico │
│ SendGrid │ 🟢 OK │ N/A │ Médio │
│ AWS S3 │ 🟢 OK │ N/A │ Alto │
│ Twilio │ 🔴 Atraso │ 15 Jan │ Baixo │
│ Auth0 │ 🟡 Em prog│ 25 Jan │ Crítico │
└───────────────────────────────────────────────────────┘
DETALHAMENTO POR FORNECEDOR:
─────────────────────────────────────
STRIPE (Pagamentos):
├── Dependência: Credenciais de produção
├── Status: Aguardando aprovação
├── Impacto se atrasar: Release atrasada 1 sprint
├── Plano B: Usar outro gateway (PayPal)
└── Responsável: João (Tech Lead)
AUTH0 (Autenticação):
├── Dependência: Configuração de tenant
├── Status: Em andamento com suporte
├── Impacto se atrasar: Features de login bloqueadas
├── Plano B: Auth próprio temporário
└── Responsável: Maria (Backend)
TWILIO (SMS):
├── Dependência: Número verificado
├── Status: Atrasado - em review legal
├── Impacto se atrasar: SMS notifications desabilitados
├── Plano B: Apenas email (aceitável)
└── Responsável: Carlos (DevOps)
Estratégias de Integração
Abordagem por Fases
INTEGRAÇÃO EM FASES
═══════════════════
FASE 1: SANDBOX/TESTE
─────────────────────────────────────
Objetivo: Provar que funciona
Tarefas:
├── Criar conta de teste
├── Configurar ambiente dev
├── Implementar happy path
├── Testar fluxo básico
└── Documentar aprendizados
Critério de sucesso:
├── Transação de teste funciona
├── Dados corretos retornados
├── Logs apropriados
└── Time entende a API
FASE 2: CASOS DE BORDA
─────────────────────────────────────
Objetivo: Tratamento robusto
Tarefas:
├── Erro de rede
├── Timeout handling
├── Rate limiting
├── Dados inválidos
├── Respostas parciais
└── Retry logic
Critério de sucesso:
├── Nenhum crash em erros
├── Mensagens claras ao usuário
├── Logs para debugging
└── Métricas de falha
FASE 3: PRODUÇÃO
─────────────────────────────────────
Objetivo: Ready for real use
Tarefas:
├── Credenciais de produção
├── Configuração segura
├── Monitoramento
├── Alertas configurados
├── Runbook documentado
└── Rollback plan
Critério de sucesso:
├── Funciona em produção
├── Métricas visíveis
├── Alertas funcionando
├── Equipe sabe responder
Padrões de Resiliência
PADRÕES PARA INTEGRAÇÕES CONFIÁVEIS
═══════════════════════════════════
CIRCUIT BREAKER:
─────────────────────────────────────
Problema: Fornecedor fora do ar causa cascata
Solução:
┌─────────────────────────────────────────┐
│ [Closed] → Erros < threshold │
│ │ │
│ ▼ (erros > threshold) │
│ [Open] → Rejeita imediatamente │
│ │ │
│ ▼ (timeout) │
│ [Half-Open] → Testa uma requisição │
│ │ │
│ ▼ (sucesso) │
│ [Closed] → Normal │
└─────────────────────────────────────────┘
RETRY COM BACKOFF:
─────────────────────────────────────
Problema: Falhas temporárias
Solução:
├── Tentativa 1: Imediata
├── Tentativa 2: Espera 1s
├── Tentativa 3: Espera 2s
├── Tentativa 4: Espera 4s
├── Máximo: 5 tentativas
└── Depois: Falha com erro
TIMEOUT ADEQUADO:
─────────────────────────────────────
Problema: Requisições que nunca terminam
Configuração:
├── Connect timeout: 5s
├── Read timeout: 30s
├── Total timeout: 60s
└── Cancela e retorna erro
FALLBACK:
─────────────────────────────────────
Problema: Serviço crítico fora
Opções:
├── Cache local (dados stale)
├── Serviço alternativo
├── Degradação graciosa
├── Mensagem amigável
└── Retry assíncrono
Implementação no GitScrum
Configurando Board de Integração
BOARD ESPECIALIZADO
═══════════════════
COLUNAS RECOMENDADAS:
─────────────────────────────────────
Backlog → Em Análise → Aguardando Vendor →
Em Dev → Em Review → Em QA → Done
COLUNA ESPECIAL: AGUARDANDO VENDOR
─────────────────────────────────────
Para itens bloqueados por terceiros:
├── Visibilidade clara de bloqueios
├── Não conta como "em progresso"
├── Trigger para follow-up
├── Métricas de tempo bloqueado
└── Alertas de itens parados
LABELS PARA INTEGRAÇÕES:
─────────────────────────────────────
├── vendor:stripe
├── vendor:sendgrid
├── vendor:aws
├── integration:payment
├── integration:email
├── integration:storage
├── blocked:external
└── risk:high
CAMPOS CUSTOMIZADOS:
─────────────────────────────────────
├── Vendor Contact
├── Ticket ID (do fornecedor)
├── SLA Date
├── Escalation Date
└── Fallback Plan
Relatórios de Integração
MÉTRICAS DE INTEGRAÇÃO
══════════════════════
TEMPO BLOQUEADO POR VENDOR:
─────────────────────────────────────
Dashboard mostrando:
├── Tempo médio aguardando vendor
├── Vendor mais problemático
├── Tarefas bloqueadas há mais tempo
├── Impacto em releases
└── Tendência ao longo do tempo
SUCESSO DE INTEGRAÇÕES:
─────────────────────────────────────
├── Integrações completadas no prazo
├── Integrações atrasadas
├── Causa dos atrasos
├── Lições aprendidas
└── Melhoria ao longo do tempo
DEPENDÊNCIAS CRÍTICAS:
─────────────────────────────────────
Alertas para:
├── Tarefas bloqueadas > 3 dias
├── Prazo de vendor chegando
├── Sem resposta > 2 dias
├── Risco de impacto em release
└── Escalation necessário
Boas Práticas
Comunicação com Fornecedores
BOAS PRÁTICAS DE COMUNICAÇÃO
════════════════════════════
DOCUMENTAR TUDO:
─────────────────────────────────────
├── Cada email/chat registrado
├── Acordos por escrito
├── Datas e responsáveis
├── Próximos passos claros
└── Referenciável depois
SER PROATIVO:
─────────────────────────────────────
├── Follow-up antes do prazo
├── Não assumir que está ok
├── Perguntar status regularmente
├── Antecipar problemas
└── Ter sempre plano B
ESCALAR APROPRIADAMENTE:
─────────────────────────────────────
├── Começar com canal normal
├── Se sem resposta em 48h → escalar
├── Usar gerente de conta se disponível
├── Documentar tentativas de contato
└── Considerar alternativas
CONSTRUIR RELACIONAMENTO:
─────────────────────────────────────
├── Conhecer contatos por nome
├── Agradecer quando ajudam
├── Dar feedback construtivo
├── Compartilhar roadmap quando apropriado
└── Criar canal direto quando possível
Gestão de Riscos
MITIGAÇÃO DE RISCOS DE INTEGRAÇÃO
═════════════════════════════════
IDENTIFICAÇÃO:
─────────────────────────────────────
Para cada integração, documentar:
├── O que pode dar errado?
├── Qual a probabilidade?
├── Qual o impacto?
├── Como detectar?
└── Como responder?
PLANOS DE CONTINGÊNCIA:
─────────────────────────────────────
Fornecedor fora do ar:
├── Circuit breaker implementado
├── Cache para leitura
├── Queue para escrita
├── Mensagem ao usuário
└── Alerta para time
Fornecedor descontinua serviço:
├── Alternativas identificadas
├── Abstração no código
├── Dados exportáveis
├── Timeline de migração
└── Custo estimado
Breaking change na API:
├── Monitorar changelog
├── Testar em sandbox primeiro
├── Versionamento de API
├── Testes de contrato
└── Rollback plan