Segundo o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, em algum momento do planejamento de qualquer projeto de software de média ou alta complexidade, alguém lista os riscos do projeto. Atrasos no desenvolvimento, mudança de requisitos, saída de membros do time, instabilidade da infraestrutura. A lista é extensa, a reunião é longa, e ao final ninguém mencionou o risco que, estatisticamente, é um dos mais frequentes e um dos mais disruptivos de todos: a dependência de sistemas, APIs e serviços de terceiros que o time não controla, não pode acelerar e raramente consegue prever com precisão.
Se você já passou pela experiência de ter uma entrega bloqueada por uma integração que deveria ter sido simples, por uma documentação de API que estava desatualizada ou por um parceiro tecnológico que prometeu um prazo e não cumpriu, este artigo vai oferecer um framework de gestão que poderia ter mudado o desfecho daquela situação.
Por que dependências externas são tão frequentemente ignoradas no planejamento de projetos de software?
A subestimação de dependências externas tem raízes tanto cognitivas quanto estruturais. Do ponto de vista cognitivo, há uma tendência natural a planejar o que se controla e a tratar como variável menor o que está fora do controle direto. Quando o gerente de projeto ou o tech lead monta o cronograma, o foco está no esforço interno de desenvolvimento, nas estimativas das histórias de usuário, na alocação de capacidade do time. As dependências externas aparecem, quando aparecem, como uma linha genérica no plano que diz algo como “integração com sistema X”, sem qualquer detalhamento sobre o que essa integração realmente implica em termos de esforço, prazo de resposta e potencial de bloqueio.
Do ponto de vista estrutural, Jean Pierre Lessa e Santos Ferreira explica que o problema é agravado pela forma como as organizações tratam as relações com parceiros tecnológicos e fornecedores de serviços. Contratos são negociados por times comerciais, acordos de nível de serviço são estabelecidos em termos genéricos, e as equipes técnicas que precisam trabalhar diariamente dentro dessas restrições frequentemente não têm visibilidade sobre o que foi ou não acordado antes de o projeto começar. Quando a integração falha, quando o tempo de resposta da API é maior do que o previsto ou quando uma mudança de versão do sistema de terceiro quebra a integração existente, o time de desenvolvimento descobre na pior hora possível que não existe mecanismo claro de escalação e que o SLA acordado não inclui o tipo específico de problema que está enfrentando.
Há ainda uma terceira dimensão que raramente é discutida: a assimetria de incentivos entre o fornecedor da dependência externa e o time que a consome. Para o fornecedor de uma API ou serviço, o projeto do cliente é mais um entre muitos. Para o time de desenvolvimento do cliente, aquela dependência pode ser o caminho crítico de uma entrega que tem data pública, compromisso com stakeholder ou impacto financeiro direto. Essa assimetria não desaparece com contratos mais detalhados, mas pode ser gerenciada com estratégias que reduzem a exposição ao risco antes que ele se materialize como bloqueio.
Quais são as formas mais comuns em que dependências externas se tornam gargalos de entrega em projetos de software?
A documentação desatualizada ou incompleta é o primeiro e mais frequente vetor de problema com dependências externas. Times de desenvolvimento que iniciam a integração com um sistema de terceiro com base em documentação que não reflete a versão atual da API invariavelmente descobrem discrepâncias que exigem comunicação com o fornecedor, testes adicionais e revisão do código já escrito. Esse ciclo pode se repetir múltiplas vezes em integrações complexas, e cada ciclo adiciona dias ou semanas ao cronograma que não estavam planejados. A lição que poucos times internalizam é que o primeiro investimento em qualquer integração deve ser a validação da documentação contra o ambiente real, antes de escrever uma linha de código de integração.
Os ambientes de sandbox e homologação de fornecedores são outro ponto de falha recorrente. De acordo com o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, é comum que o ambiente de teste disponibilizado pelo fornecedor não represente fielmente o comportamento do ambiente de produção, seja em termos de desempenho, seja em termos de comportamento em cenários de erro, seja em termos de limitações de taxa de requisição. O time de desenvolvimento integra, testa, valida no sandbox e libera para produção apenas para descobrir que o comportamento real é significativamente diferente do que foi testado. Esse tipo de problema é particularmente insidioso porque a equipe cumpriu todas as etapas formais do processo de desenvolvimento e ainda assim chegou a produção com uma integração que não funciona como esperado.
Quais estratégias permitem gerenciar dependências externas sem que elas se tornem o fator de atraso mais frequente do projeto?
A estratégia mais eficaz de gerenciamento de dependências externas começa antes do projeto: na fase de discovery e planejamento técnico. Mapear todas as dependências externas com o mesmo nível de detalhamento que se dedica ao design interno do sistema, incluindo avaliação do histórico de estabilidade do fornecedor, análise do contrato de nível de serviço, identificação do canal de suporte técnico e avaliação do esforço real de integração com base em projetos anteriores similares, transforma dependências de pontos cegos em variáveis gerenciadas. Esse mapeamento deve resultar em um risco documentado com probabilidade, impacto e plano de mitigação específico para cada dependência identificada como crítica.
Conforme destaca Jean Pierre Lessa e Santos Ferreira, a técnica de anticorrupção por meio de camadas de abstração é uma das ferramentas de engenharia mais valiosas para reduzir a exposição a mudanças externas. Quando o código de negócio do sistema é completamente isolado dos detalhes de implementação da dependência externa por meio de interfaces bem definidas, uma mudança na API do fornecedor impacta apenas a camada de adaptação e não o código de negócio. Essa separação reduz drasticamente o esforço de adaptação quando mudanças externas ocorrem e cria um ponto único de controle que facilita o monitoramento e o teste das integrações.
Por fim, o planejamento explícito de buffers para dependências externas críticas é uma prática de gestão de projetos que a maioria dos times evita por pressão de cronograma e que todos os times que já sofreram com esse tipo de problema reconhecem como necessária. Quando uma entrega depende de uma integração com um sistema externo que o time nunca integrou antes, um buffer de pelo menos trinta por cento sobre a estimativa inicial de esforço é conservador, não excessivo. A alternativa é absorver esse tempo de qualquer forma, mas sem planejamento, o que significa absorvê-lo sob pressão, em sprint de outros itens ou causando atraso na entrega final.
Autor: Diego Rodríguez Velázquez
