A resposta curta
Pela Lei 14.133/2021, a contratação de software por um órgão público começa no planejamento: um estudo técnico preliminar que justifica a necessidade e compara soluções, seguido de um termo de referência que descreve o que será entregue e como será aceito. Depois vem a seleção do fornecedor e a fiscalização do contrato.
Nos projetos de software, o que mais decide o resultado é a qualidade desse planejamento. Um termo de referência que define requisitos de acessibilidade, proteção de dados, registro de movimentação, ritos de entrega e critérios de aceite dá ao fiscal o que medir e ao fornecedor o que cumprir. Este texto é um guia geral: os detalhes de cada órgão seguem as normas internas e a orientação da assessoria jurídica.
Como funciona a contratação pública de software pela Lei 14.133/2021
A nova lei de licitações organiza a contratação em fases. A primeira, preparatória, é onde o órgão planeja: descreve a necessidade, estuda as alternativas, estima o valor, avalia os riscos e define as regras da disputa. Em seguida vêm a seleção do fornecedor e, depois da assinatura, a execução do contrato, acompanhada por gestor e fiscais designados.
A lei também valoriza o plano de contratações anual, a gestão de riscos e a segregação de funções, para que quem planeja, quem julga e quem fiscaliza não sejam sempre a mesma pessoa. A modalidade e o critério de julgamento dependem do objeto e são definidos pela área de licitações com o apoio da assessoria jurídica.
Em software, há duas situações bem diferentes. Uma é contratar o uso de um sistema que já existe, como licença ou serviço em nuvem. A outra é contratar o desenvolvimento de um sistema sob medida para o órgão. O planejamento muda bastante de uma para outra, e o estudo técnico preliminar é o lugar certo para fazer essa escolha.
O estudo técnico preliminar vem antes de tudo
O estudo técnico preliminar, o ETP, é o documento que mostra que a contratação faz sentido. Ele descreve o problema a resolver, levanta as soluções possíveis no mercado, compara os caminhos e justifica a escolha. É também onde o órgão estima quantidades e identifica os requisitos que vão orientar o termo de referência.
Para software, um bom ETP responde perguntas práticas: qual rotina o sistema precisa atender, quem vai usar (servidor, cidadão, gestão), com quais sistemas ele precisa conversar, que dados pessoais vai tratar e se uma solução de mercado resolve ou se o caso pede desenvolvimento. Ouvir quem executa o processo no dia a dia, nessa fase, evita um termo de referência escrito só a partir da ferramenta que alguém já conhece.
Esse levantamento tem muito em comum com o que fazemos no estudo inicial de um projeto privado, e o raciocínio de como definir o escopo de um software também serve aqui.
O que o termo de referência de software precisa ter
O termo de referência é o documento que o fornecedor vai cumprir e o fiscal vai medir. Para um sistema, ele precisa cobrir pelo menos:
- Objeto e necessidade. O que será contratado e qual problema da administração ele resolve, ligado ao que o ETP concluiu.
- Requisitos funcionais. As rotinas que o sistema precisa atender, descritas pelo que o usuário faz, e não pela tecnologia.
- Requisitos não funcionais. Acessibilidade, segurança, proteção de dados, desempenho, disponibilidade e registro de movimentação.
- Modelo de execução. Como o trabalho será organizado em entregas, com que ritmo e com quais ambientes de teste e de produção.
- Critérios de aceite e de medição. O que precisa estar funcionando para cada entrega ser recebida e como a qualidade será avaliada.
- Propriedade e transição. De quem é o código e a documentação, como os dados são devolvidos e como o sistema passa a outra equipe no fim do contrato.
- Garantia e suporte. Por quanto tempo o fornecedor corrige defeitos e como funcionam os chamados depois da entrega.
O item da propriedade merece atenção especial. A Lei 14.133/2021 prevê, como regra, que nas contratações de desenvolvimento de software os direitos patrimoniais sejam cedidos à administração, e o termo de referência deve tratar disso junto com a entrega do código e da documentação. O tema está detalhado em de quem é o código do software sob medida.
Acessibilidade, LGPD e registro de movimentação
Três exigências aparecem em praticamente todo sistema público e devem estar no termo de referência como requisito, e não como recomendação.
A primeira é a acessibilidade. A Lei Brasileira de Inclusão torna obrigatória a acessibilidade nos sites mantidos por órgãos de governo. Na prática, os sistemas seguem o eMAG, o Modelo de Acessibilidade em Governo Eletrônico, e as diretrizes internacionais WCAG, do W3C. Vale pedir que o fornecedor revise a acessibilidade no design, antes de virar código, e teste com leitor de tela e navegação por teclado antes de cada entrega.
A segunda é a LGPD, a Lei Geral de Proteção de Dados, que tem regras específicas para o tratamento de dados pelo poder público. O sistema precisa tratar só os dados necessários à finalidade, com controle de acesso por perfil, e o contrato precisa definir o papel do fornecedor no tratamento desses dados.
A terceira é o registro de movimentação: quem fez o quê, quando e em qual registro. Em um sistema público, esse histórico é o que permite responder a um pedido de informação, a um questionamento do controle interno ou a uma reclamação do cidadão.
No Ágil Cidadão, o nosso sistema de atendimento ao cidadão, cada movimentação de um pedido fica registrada com autor, data, mensagem e anexo, a gestão define por perfil quem enxerga cada serviço e a interface usa componentes acessíveis. São exemplos de como esses requisitos viram funcionalidade concreta.
Ritos de entrega e aceite do sistema
Software contratado em uma única entrega no fim do prazo é o cenário de maior risco para o órgão: o problema só aparece quando já não há tempo de corrigir. A lei prevê o recebimento provisório e o definitivo do objeto, e o termo de referência pode organizar o desenvolvimento em entregas parciais, cada uma com o seu aceite.
Um rito que funciona bem tem quatro momentos: planejar o que entra no ciclo e qual o critério de aceite de cada item, mostrar o sistema funcionando ao fim do ciclo, deixar a equipe do órgão testar em um ambiente de homologação e registrar formalmente o aceite ou as pendências. É a mesma lógica das sprints com demonstração que descrevemos em como trabalhamos.
Quanto mais claro o critério de aceite, menos espaço para discussão no recebimento. "O cidadão consegue abrir uma solicitação pelo celular, anexar documentos e receber um número de protocolo" é verificável. "Sistema de protocolo moderno e intuitivo" não é.
Documentação para a fiscalização do contrato
O fiscal do contrato precisa de evidência para atestar cada entrega, e essa evidência deve ser produzida durante a execução, e não montada às pressas no fim. O termo de referência pode exigir do fornecedor, a cada entrega:
| Documento | O que mostra | Por que importa ao fiscal |
|---|---|---|
| Relatório da entrega | O que foi feito no ciclo, ligado aos itens do termo de referência | Permite conferir o que foi executado contra o que foi contratado |
| Registro do aceite | Itens aprovados, pendências e quem aprovou | Sustenta o recebimento e a liberação do pagamento |
| Notas de versão | O que mudou no sistema em cada publicação | Ajuda a rastrear defeitos e responder a questionamentos |
| Documentação técnica | Arquitetura, instalação, integrações e acessos | Garante a continuidade do sistema no fim do contrato |
| Relatório de acessibilidade e segurança | Testes feitos e problemas corrigidos | Comprova o atendimento aos requisitos não funcionais |
Fornecedores que já documentam decisões, versões e riscos como parte do método entregam essa evidência sem esforço extra. Ao avaliar propostas e na reunião inicial do contrato, vale pedir exemplos desse material. Se a dúvida for sobre o que um sistema sob medida envolve, a página de desenvolvimento de software sob medida resume as frentes de trabalho de um projeto.