Um bom contrato de desenvolvimento de software deixa claro o escopo de cada etapa e o que está fora dele, como cada entrega é aceita, a quem pertence o código-fonte, como funcionam suporte e evolução depois da entrega, como os dados são tratados e como acontece a transição se a parceria terminar.
Checklist do contrato
| Item | O que precisa estar escrito |
|---|---|
| Escopo | O que entra em cada etapa e, tão importante quanto, o que não entra |
| Entregas e aceite | Como a entrega é demonstrada e o que conta como aceita |
| Mudanças de escopo | Como pedidos novos são avaliados, priorizados e cobrados |
| Código-fonte | Quem é o dono e em qual repositório o código fica durante o projeto |
| Acessos | Servidores, domínios e contas de serviço em nome da empresa contratante |
| Documentação | O mínimo para outra equipe conseguir assumir o sistema |
| Sustentação | Tempo de resposta, o que está coberto e como é cobrada a evolução |
| Dados e LGPD | Papéis de cada parte, segurança e confidencialidade |
| Saída | Prazo e forma de transição se o contrato terminar |
Escopo fechado ou aberto
Escopo fechado dá previsibilidade quando o que será construído está claro. Escopo aberto, com prioridades revistas a cada ciclo, funciona melhor quando o sistema vai sendo descoberto com o uso. Muitos contratos combinam os dois: etapa inicial fechada e evolução em ciclos.
Sinais de alerta
- Contrato sem nenhuma linha sobre propriedade do código: veja quem é dono do código-fonte.
- Servidores e domínios registrados em nome do fornecedor.
- Nenhum critério de aceite: a entrega vira questão de opinião.
- Multa de saída que torna impossível trocar de fornecedor.