Uma das coisas que mais me preocupavam no inicio da minha carreira como manager (e preocupa até hoje 🙂 ) é a gestão de contratos e fornecedores. Ao contratar um produto de software ou serviços de desenvolvimento de uma consultoria, o engineer manager do time assume, muitas vezes, a responsabilidade de validar o contrato juntamente com o jurídico da empresa. É uma grande responsabilidade.
Como engineer manager, você será responsável por aplicar da melhor forma possível o budget que foi direcionado para esta contratação. É preciso garantir que os interesses da empresa estão assegurados no contrato e, para isso, é preciso detalhá-los nas cláusulas do contrato.
Logo, a ideia deste post é compartilhar alguns itens que você deveria estar atento(a) neste processo de validação de contrato. Não é uma receita de bolo pois cada produto, cada negociação, cada fornecedor tem as suas especificidades. Mas acredito que pelo menos ter consciência destes itens vai ajudar. Se eles não estiverem no contrato ou não forem realizados antes da assinatura, será porque você escolheu conscientemente não incluir/fazer.
Avaliação pelo time de segurança da informação
Ao contratar os serviços de software de um fornecedor, é preciso ter certeza de que o mesmo possui ambiente seguro compatível com as exigências da sua empresa. Um fornecedor com risco de vazamento de dados pode ser um risco muito alto para a imagem. Logo, peça ajuda para o time de segurança da informação para avaliar o software do fornecedor antes de fechar qualquer contrato. Atente-se aos processos exigidos pela LGPD também.
Non Disclosure Agreement (NDA)
É importante que você esteja protegido por um NDA antes de compartilhar com o fornecedor detalhes do projeto, da sua infraestrutura ou da sua arquitetura. Estas informações podem ser sensíveis que, se vazadas, podem comprometer o lançamento de um novo produto ou expor vulnerabilidades. Para compartilhar as informações sem medo, use o NDA.
Nível de disponibilidade
Se sua empresa adota níveis de disponibilidade mínimos que seus sistemas precisam garantir, não faz sentido contratar um serviço de software terceiro que tenha disponibilidade abaixo destes níveis. A experiência dos seus usuários/clientes será impactada. Por isso, considero muito importante ter este nível registrado como cláusula do contrato e combinar um possível ônus para o fornecedor caso este nível não seja mantido.
Janela de atendimento, incidentes e tempo de resposta
Nenhum software está imune a falhas. Elas vão acontecer em algum momento e como tratá-las precisa estar previsto no contrato. Sua empresa precisa saber como entrar em contato com o fornecedor e em qual janela de atendimento. Você precisa entender o seu cenário e decidir se o fornecedor precisa estar disponível para te atender 24×7 ou apenas de segunda à sexta no horário comercial. E isso precisa estar no contrato.
Além da janela de atendimento, é preciso combinar qual será o tempo de resposta. Uma vez que o sistema está fora do ar, qual é o tempo máximo para restabelecer o serviço? Caso este tempo máximo não seja respeitado, quais as consequências? É muito importante que tudo isso esteja claro para ambas as partes.
E por fim, como será a dinâmica entre as duas empresas na comunicação de incidentes/bugs. Uma vez que a sua empresa reportou um bug no sistema, em quanto tempo o fornecedor vai te retornar? Esta cláusula no contrato vai ser tão complexa quanto o nível dos processos da sua organização. Se sua organização tem tempo de resposta associado à criticidade, o fornecedor precisa acompanhar estes prazos também para que o processo funcione de ponta a ponta. Imagine que seu tempo de resposta para bugs de criticidade alta é 4 horas e o fornecedor tem um prazo de 8. Você não vai conseguir manter o compromisso de atendimento com seu cliente.
Posso te garantir que isso não é só burocracia. Se você não acordar isso antes de fechar o contrato, você pode se frustrar e muito quando um problema ocorrer. E conforme o tempo passa, sua relação com o fornecedor vai se desgastando.
É importante lembrar que a janela de atendimento e tempo de resposta tem um impacto grande no preço negociado. Não adianta pedir uma janela de 8×5 que é mais barato e depois querer suporte do fornecedor no final de semana. Se você precisa de maior disponibilidade, isso vai refletir no preço.
Atrasos
Este é um item importante para quando você está substituindo um fornecedor por outro. Vamos supor que você está trocando o software A da empresa X pelo software B da empresa Y. No planejamento deste projeto, você tem quando o software B vai estar disponível e já calculou o quanto precisa para manter o software A até ser desligado. Porém, se a empresa Y atrasa, você precisará manter o software A mais tempo do que você orçou. E ai? Quem assumirá os custos deste atraso? Se isso não estiver no contrato, será a sua empresa sem dúvida nenhuma.
Especificidades de integração
Não é raro que um serviço de software seja contratado e depois descobre-se que as opções de integração fornecidas não são compatíveis com o padrão da sua empresa. Pode ser desde uma api que trabalha com xml enquanto você trabalha com json até incompatibilidade na estruturação da rede para separação de ambientes de desenvolvimento e produção. Isso pode inviabilizar um projeto. Logo, explore um pouco mais as formas de integração para fechar o contrato.
Propriedade do código, documentação, treinamento
Caso o software do fornecedor precise de algumas customizações para atender às suas necessidades, qual empresa terá a propriedade do código? Quem será responsável pela manutenção deste código? Caso seja a sua empresa, documentações/manuais serão fornecidos pela empresa contratada?
Caso seja um software de uso interno como para atendimento ou processos financeiros, os colaboradores da sua empresa precisarão saber como utilizá-lo, correto? Um treinamento está previsto em contrato?
Garantia e suporte à usuários
Para cenários onde se trabalha com empresas de consultoria de desenvolvimento de software, este é um item bastante importante. Após o termino do desenvolvimento do projeto e disponibilização em produção, qual o tempo de garantia que a empresa oferece para bugs/incidentes?
Em contratos de desenvolvimento de software, é comum ter um custo pela sustentação do mesmo. Caso não haja nenhum período de garantia acordado, sua empresa pode ser cobrada pela resolução de bugs/incidentes de um software que acabou de ser disponibilizado em produção.
Outro ponto importante neste tipo de contrato é o suporte ao usuário em período de homologação. Algumas empresas adotam uma fase de homologação do software por usuários com o objetivo de aprovar ou não o software para ser disponibilizado em produção. Durante este período, é comum que usuários tenham dúvidas ou reportem bugs. Quem vai ser responsável por suportar os usuários neste processo? Seu time ou o time da consultoria? Isso é algo que pode estar em contrato também.
Licenças
Caso você esteja comprando um software que exige licenças, é importante que você se atente para as cláusulas que explicam como será esta dinâmica. Coisas como:
- Quantas licenças estão inclusas no contrato?
- Qual é o valor de cada uma?
- Caso você utilize mais licenças do que o contratado, como este excedente será cobrado? A licença terá o mesmo preço das inclusas no contrato? Algumas empresas cobram mais caro pelo excedente.
- Caso eu não utilize todas as licenças contratadas, eu posso acumular este crédito? Trocar por outras funcionalidades/módulos?
- Como é feita a apuração do uso de licenças? É mensal? É anual? Isso é importante para você fazer o planejamento do seu budget.
- O contrato garante o preço das licenças até o término ou prevê aumento por algum índice (ex: IGPM)?
Espero que esta lista possa te ajudar neste momento de discussão de contratos e diminua sua sensação de insegurança e/ou a sensação de “será que eu estou esquecendo algo?”. Sentiu falta de alguma coisa, comenta aqui no post para eu adicionar. Salva nos seus favoritos para você consultar quando precisar.

Deixe um comentário