Comprar software para a prefeitura costuma terminar em dois extremos: um edital que lista centenas de funcionalidades ou uma contratação que entrega um sistema que ninguém usa. A cidade de Boston (Estados Unidos) tentou um terceiro caminho ao adquirir um sistema para gerenciar suas obras. O Government Performance Lab (GPL), da Harvard Kennedy School (HKS), relatou o processo em um Project Feature de março de 2018. O foco é a contratação de um sistema de gestão de obras descrito por problemas e entregue por fases.
A ideia em resumo
Segundo o GPL, Boston gasta mais de US$ 120 milhões por ano em obras nas secretarias de obras públicas, instalações públicas, parques e recreação e transportes. Os projetos eram controlados por bancos de dados caseiros, papéis e planilhas, o que dificultava a colaboração e o compartilhamento de informações. O departamento de inovação e tecnologia liderou a compra de um sistema único de gestão de projetos de capital, com o objetivo de padronizar processos, ampliar o fluxo de dados e melhorar o serviço dentro e entre as áreas. O trabalho foi feito com apoio técnico voluntário na iniciativa What Works Cities.
O que a pesquisa mostrou
- Pesquisa de mercado de verdade. A cidade entrevistou universidades e outros órgãos que usam esse tipo de sistema, analisou seus editais e visitou instalações para ver o software funcionando.
- Consulta ao mercado sobre escopo e preço. A prefeitura publicou um rascunho do escopo como pedido de informações, para ouvir fornecedores sobre o enquadramento, o nível de detalhe e a estrutura de preços, que costuma ser complexa nesses sistemas. Um formulário digital facilitou as respostas e permitiu obter preços por componente.
- Edital por problema. Em vez de listar requisitos técnicos, a cidade descreveu os principais problemas e metas gerais, como “promover a transparência dos projetos por meio da centralização de dados” e “facilitar a colaboração”. Deixou o edital aberto para que as empresas sugerissem métodos, incluindo boas práticas de outros governos.
- Entrega por fases. Só as funções essenciais deveriam ser desenvolvidas no primeiro ano, e servidores-chave testariam o sistema na fase inicial, o que permite ajustar o desenho com a opinião dos usuários. Funcionalidades avançadas deveriam ser propostas e precificadas à parte, para a cidade incorporar módulos no segundo ano ou depois.
O GPL informa que a cidade recebeu 13 propostas, contra as seis que costuma receber em compras de TI semelhantes. Segundo o relato, a compra conjunta por quatro secretarias facilitou o compartilhamento de práticas e já gerou melhoria de processos e coordenação, e a implantação enxuta custa menos, acelera prazos e dá ênfase à experiência do usuário. O relato não mostra resultados de uso do sistema.
Como aplicar no Brasil
- Faça o levantamento de mercado com visitas e conversas com outros órgãos. O art. 18, § 1º, V, da Lei 14.133/2021 pede a análise das alternativas possíveis e a justificativa técnica e econômica da solução escolhida.
- Abra o rascunho à consulta pública. O art. 21, parágrafo único, permite submeter a licitação a prévia consulta pública, com disponibilização dos elementos a todos os interessados, que podem formular sugestões no prazo fixado.
- Descreva o problema e as metas no estudo técnico preliminar e no termo de referência, e deixe os requisitos realmente obrigatórios separados dos desejáveis.
- Peça entrega por módulos e preço separado dos itens avançados. O art. 18, § 1º, VIII, trata das justificativas para o parcelamento ou não da contratação.
- Use prova de conceito se couber: o art. 17, § 3º, permite, se previsto no edital, avaliar a proposta do provisoriamente vencedor por amostras e prova de conceito.
- Una áreas com o mesmo problema (obras, planejamento, fazenda) na mesma contratação, com usuários-chave desde o começo.
Cuidados e limites
O relato descreve o processo de compra e a resposta do mercado, não o uso do sistema depois de implantado. Mais propostas não garantem melhor software. No Brasil, o objeto precisa ser definido de modo suficiente para julgamento objetivo, e a descrição por problemas não elimina a necessidade de requisitos mínimos, critérios de aceite e matriz de riscos. Sistemas que tratam dados de cidadãos e fornecedores exigem cláusulas de proteção de dados, portabilidade e propriedade da informação. Contatos com fornecedores devem ser abertos e igualitários, e a decisão sobre o instrumento (licitação, registro de preços, adesão) cabe à análise jurídica local. Este texto é uma leitura própria da Evoluta, feita por profissionais com formação pela Harvard Kennedy School, sem vínculo da empresa com a HKS.
