O que examinar num fornecedor de software antes de assinar o contrato

Três propostas na mesa e nenhuma diferença técnica visível

Uma diretoria que recebe três propostas de desenvolvimento consegue comparar preço, prazo e a lista de tecnologias que cada fornecedor promete usar. O que ela não consegue comparar, com os documentos que tem em mãos, é quem vai efetivamente escrever o código, o que acontece quando o sistema cai numa sexta-feira à noite e quanto custará trocar de prestador dois anos depois da entrega. Essas três informações determinam boa parte do resultado do contrato, e nenhuma delas aparece numa proposta comercial, porque quem negocia preço raramente pede para ver o pipeline de deploy.

Nossa posição sobre isso é direta: acima de um certo porte de contrato, escolher fornecedor sem ter lido uma linha do código que ele já escreveu é uma decisão de compra tomada às cegas. A análise que corrige essa cegueira, conduzida por alguém com formação em engenharia, consome de três a cinco dias de trabalho e cobre leitura de código, entrevista técnica com quem vai executar e checagem de referência com cliente anterior. É pouco perto do que custa descobrir a mesma informação no primeiro incidente grave ou na primeira tentativa de trocar de fornecedor.

O que pedir para ver antes da assinatura

Três materiais dizem mais sobre um fornecedor do que qualquer apresentação comercial. O primeiro é um trecho representativo de código escrito para outro cliente, entregue sob acordo de confidencialidade quando o contrato anterior exigir. O segundo é a lista de dependências e serviços de terceiros usados nos projetos recentes, que revela ao mesmo tempo o critério técnico da equipe e o tamanho da superfície de risco que ela aceita sem hesitar. O terceiro é a descrição de como o fornecedor opera o sistema depois do go-live: como faz deploy, como desfaz um deploy que deu errado e o que monitora enquanto ninguém está olhando.

Esse terceiro item merece insistência. Um fornecedor que hospeda o sistema do cliente sem plano de rollback já exercitado está transferindo um risco de operação para quem contrata, e isso normalmente não é dito em voz alta durante a venda. Perguntar quando foi a última vez que o rollback foi executado, em qual projeto e quanto tempo levou produz uma resposta bem mais informativa do que perguntar se existe processo de rollback.

Quantas pessoas realmente escrevem o código

A proposta comercial lista uma equipe; o projeto é tocado por outra, quase sempre menor. Cinco nomes no documento podem significar dois engenheiros em dedicação parcial, com o restante alocado em contratos simultâneos. Isso, por si só, não desqualifica ninguém, mas altera a avaliação de risco de forma relevante quando o prazo é apertado ou quando a demanda se concentra numa janela curta, como uma virada fiscal ou uma campanha sazonal. Pedir o percentual de dedicação de cada pessoa, e pedir que ele apareça no contrato, separa quem está dimensionando um time de quem está montando um documento.

Quem responde pelo incidente e em quanto tempo

Fornecedor que vai tocar dado financeiro ou dado de saúde precisa demonstrar, antes da assinatura, como trata controle de acesso, criptografia de dado em repouso e trilha de auditoria, o mesmo tipo de decisão que a frente de LGPD & Privacidade trata como arquitetura desde o início do projeto. A afirmação de que o sistema é seguro não substitui o desenho técnico que a sustenta, e esse desenho pode ser pedido, lido e questionado por qualquer engenheiro que a empresa contratante convide para a conversa.

Há uma segunda pergunta, menos técnica e mais contratual, que costuma ficar sem resposta: quem assume o quê quando o incidente acontece. O artigo 48 da LGPD atribui ao controlador o dever de comunicar à autoridade nacional e ao titular a ocorrência de incidente de segurança capaz de acarretar risco ou dano relevante, em prazo que a própria lei delega à autoridade definir. Na maioria dos arranjos, o controlador é a empresa contratante e o fornecedor figura como operador. A obrigação legal recai, portanto, sobre quem contratou, enquanto a informação necessária para cumpri-la está inteira do lado de quem opera o sistema. Contrato que não fixa prazo de notificação do operador ao controlador, nem define quem conduz a investigação técnica, deixa a empresa contratante com o dever e sem os dados para exercê-lo.

O que a diligência não cobre

Diligência técnica reduz risco de execução e nada faz contra escopo mal definido. Fornecedor tecnicamente competente entrega o produto errado com a mesma facilidade que qualquer outro quando o escopo não foi acordado com precisão suficiente para distinguir mudança de requisito de erro de execução. Os dois trabalhos são independentes, e nenhum dispensa o outro.

Há também o custo da própria análise, que nem toda empresa contratante absorve internamente, por falta de alguém com repertório técnico e agenda disponível para conduzi-la. Para contrato pequeno e de curto prazo, esse custo raramente se justifica, e existe um arranjo mais barato com efeito parecido: escopo curto, revisão intermediária antes do desembolso total e nenhuma cláusula de exclusividade até o fornecedor mostrar consistência em entregas menores. A diligência completa fica reservada aos contratos em que o custo de errar na escolha supera com folga o custo de investigar antes.

Como testar a portabilidade antes de assinar

O ponto mais ignorado numa negociação é a propriedade do repositório depois que o contrato termina. Fornecedor que mantém o código em conta própria cria uma dependência que só se torna visível no momento em que o cliente decide trocar, e por isso o contrato precisa dizer de quem é o repositório, quando o acesso é transferido e em que estado a documentação é entregue. Quando o modelo é alocação de equipe, o arranjo mais simples é o desenvolvimento acontecer desde o início na infraestrutura e no repositório do próprio cliente. O mesmo vale para a infraestrutura como código: se os scripts de provisionamento, as chaves de acesso e o desenho da arquitetura vivem apenas na estrutura do fornecedor, a portabilidade prometida em cláusula existe só no papel, a mesma exigência de arquitetura documentada que aplicamos na frente de Desenvolvimento Full-Stack.

O teste prático é pedir para ver como ficou a transição num projeto anterior já encerrado. Quem tem acesso ao repositório hoje, se a documentação de arquitetura existe fora da cabeça de quem escreveu o código, e quanto tempo uma equipe nova levou para fazer o primeiro deploy sozinha depois do fim do contrato original. Fornecedor que já passou por essa transição responde com datas, nomes e detalhes verificáveis. Quem nunca entregou de fato o que construiu responde no condicional, e a diferença entre as duas respostas é audível na primeira reunião.