Por muitos anos vimos o boom do software livre no setor público. Era nítido o movimento de órgãos governamentais buscando soluções “gratuitas” para substituir softwares proprietários. Na prática, porém, logo ficou claro que software livre não é sinônimo de custo zero. Manter um sistema aberto em produção exige uma equipe altamente capacitada, dedicada e estável, exatamente o tipo de profissional que é disputado (e bem pago) pelo mercado privado.
Quando essas pessoas saem (sim, acredite, bons servidores públicos da área de TI não são caveira, eles pedem pra sair), aquele software livre começa a perder fôlego. O projeto original é descontinuado, a comunidade passa a ter menos tempo para iniciativas que não pagam as contas, surgem dificuldades para atualizar versões, corrigir falhas, integrar com novas tecnologias… e, pouco a pouco, a solução que já foi estratégica vira “legado”, sinônimo de velha e desatualizada.
Diante desse cenário, os governos passaram a adotar novas estratégias de contratação, sempre fundamentadas na legislação vigente. Em linhas gerais, o servidor responsável elabora os Estudos Técnicos Preliminares (o famoso ETP), levanta as necessidades da administração, pesquisa o mercado em busca de soluções aderentes, prepara o termo de referência (sim, ele, o TR), estrutura e publica o edital, conduz o pregão conforme as normas legais aplicáveis e, ao final desse percurso, efetiva a contratação.
É exatamente aqui que os problemas começam.
Grandes empresas, muitas vezes, não se interessam tanto quanto as pequenas. E não é por falta de potencial de contrato, mas pelo modelo. A administração pública quase nunca quer “apenas” o que está na prateleira. Sempre existe uma particularidade: uma exigência da legislação local, um ajuste por cultura organizacional, um pedido específico fruto de lobby interno (e às vezes externo), política ou até consequência de um erro de origem no processo de informatização.
E aqui entra um ponto sensível: é raro, mas acontece com frequência, de um processo analógico ser simplesmente convertido em digital sem agregar valor. O formulário em papel vira um formulário na tela, com as mesmas dores, filas e retrabalho, só que agora com login e senha com um CSS bonito.
Quando a administração exige personalizações excessivas, o desafio para as empresas de tecnologia explode:
como construir software como produto (modelo de prateleira) e, ao mesmo tempo, atender a enorme variedade de exigências dos órgãos públicos?
Na prática, só existe um caminho saudável: o software precisa nascer (ou ser evoluído) como produto modular e parametrizável.
As regras de negócio não podem estar todas “engessadas” no código. Quanto mais a solução depender de alteração de código para cada cidade, órgão ou estado, mais ela deixa de ser produto e vira projeto sob medida (caro, lento, difícil de manter e pouco escalável).
Em vez disso, regras, fluxos, prazos, formatos de documento, formas de autenticação e integrações precisam estar em parâmetros, configurações e módulos plugáveis. Assim, a mesma base de produto atende municípios diferentes, respeita legislações diversas e permite ajustes finos sem destruir o roadmap.
É claro que, no mundo real, o caminho “normal” de muitas empresas é outro: alguém tem uma ideia, transforma em sistema, lança, fecha com um cliente, adapta o que o cliente pede, replica o modelo pro próximo, e assim por diante. Depois de consolidado, quando o cliente pede algo muito específico ou que não agrega valor para os demais, a resposta ideal seria: “não vamos implementar isso” “vamos avaliar sua sugestão” . Mas no setor público essa escolha é bem mais delicada, principalmente em municípios, onde leis locais e pressões políticas fazem parte do contexto.
Por isso, fica o conselho direto para empresas que querem fornecer para o governo: não caiam na armadilha de enxergar apenas “software como serviço sob demanda”.
Pensem produto desde o primeiro commit. Serviço é como você entrega, negocia, suporta. Produto é como você garante qualidade, continuidade, evolução e previsibilidade, para você e para o cliente.
Com arquitetura modular, parametrização inteligente e visão de longo prazo, dá para chegar num meio termo bom: um produto sólido, flexível o suficiente para respeitar as particularidades do setor público, sem virar um Frankenstein de contratos, exceções e gambiarras.
E antes de aprofundar essa discussão, vale olhar para trás: por causa da burocracia, do tamanho da máquina pública e da forma como os órgãos são estruturados, os serviços públicos foram os últimos a se informatizar. Até hoje não é raro encontrar atendimento em papel, exigência de presença física para algo simples, ou fluxos digitais que só reproduzem velhos carimbos.
É justamente aí que tratar software como produto, e não só como um “sistema feito pra resolver esse edital específico”, deixa de ser filosofia bonita e passa a ser necessidade.
Em resumo, governos precisam aprender a olhar primeiro para softwares pensados como produto (sustentáveis, evolutivos e parametrizáveis) e só depois discutir o serviço que os acompanha (suporte, implantação, capacitação, integrações). E as empresas de tecnologia precisam resistir à sedução dos contratos governamentais longos e gorduchinhos. Eles acabam, mudam de gestão, trocam prioridades, atrasam pagamento, criam passivos técnicos e engessam o time em demandas que não viram valor reutilizável. O jogo inteligente, para os dois lados, é construir relações em torno de produtos sólidos, com visão de longo prazo, onde cada customização conversa com a estratégia e não com a agenda do próximo contrato.
É utopia imaginar um software totalmente de prateleira para governo? Com certeza, mas dizer que é um sonho impossível, nem de longe.
Deixe um comentário