Como melhorar a contratação pública de TI
05 May 2014Recentemente o Governo Federal abriu uma consulta pública para propostas de revisão da Instrução Normativa SLTI/MP Nº 4, de 12 de novembro de 2010, e suas atualizações. Isso é importante por que as regras atuais não estão proporcionado os resultados desejados. Nesse caso, isso significa que os sites e serviços de TI do governo não evoluem rápido o suficiente e não são adequados as necessidades dos usuários.
Eu acredito que, a medida que mais e mais cidadãos tem acesso a Internet, se torna cada vez mais importante oferecer serviços online de qualidade, e por isso colaborei com uma série de recomendações e estarei presente na audiência pública sobre o assunto. Compartilho aqui as 11 recomendações que eu fiz com base na IN04:
1
Contribuição: Estabelecer um tamanho máximo de equipe contratada ou um valor máximo do contrato.
Justificativa: Grandes projetos de TI oferecem maior risco para o contratante e reduzem o conjunto de possíveis contratados. Limitando a escala dos projetos – em combinação com uma simplificação das exigências para contratação – os órgãos conseguiriam ter acesso a serviços mais especializados e resultados mais rápidos.
2
Contribuição: Reduzir as exigências para contratações até um determinado valor (simplificação do estudo técnico preliminar e da análise de risco).
Justificativa: Uma das lamentações mais frequentes dos contratantes de software é o investimento necessário para fazer um edital (algumas estimativas falam de R$20.000,00 e meses de trabalho). Isso desestimula a realização de editais menores, e tem por consequência comprometer a agilidade do governo. Uma redução das exigências para contratos menores facilitaria este processo sem aumentar o risco para a União.
3
Contribuição: Utilizar resultados objetivos atingidos como critérios técnicos para seleção de fornecedores (por exemplo: aumento no número de cadastrados, taxa de retorno no site, diminuição nos número de pedidos de suporte).
Justificativa: Software público é feito para os cidadãos. A utilização de critérios que não são relacionados ao resultado gerado, cria uma série de incentivos perversos como a “compra” de certificações ou foco no processo em detrimento dos resultados.
4
Contribuição: Vedar a utilização de critérios técnicos que não são traduzidos em benefícios diretos ao usuário final nem dizem respeito a orientações estratégicas do governo (certificações, número de defeitos reportados em desenvolvimento).
Justificativa: Critérios técnicos indiretos estimulam o desperdício por não estarem vinculados a resultados e historicamente não tem gerado os resultados esperados de aumento da qualidade de entrega de software. Existem critérios que medem o resultado objetivo para o cidadão ou o comprometimento com políticas nacionais (como software livre). Estes devem ser estimulados.
5
Contribuição: Preferência por contratação de pequenas e médias empresas como critério de seleção.
Justificativa: Pequenas empresas de software tem mais condições de proverem inovação e de estarem comprometidas com o projeto para que foram contratadas (uma vez que representará uma grande parte no seu portfólio). Quaisquer risco adicional que a União sinta estar exposta deveria ser ponderado em relação ao benefício para o desenvolvimento do setor que este investimento virá a acarretar.
6
Contribuição: Exigência de utilização de software de código aberto e de padrões abertos em qualquer contratação que envolva o desenvolvimento ou adaptação de uma solução.
Justificativa: O CEGE prevê a adoção de uma política de Software Livre na administração pública. Assim, vemos como importante que a Instrução Normativa contemple esta orientação. Software livre torna a administração pública menos dependente de grandes empresas – normalmente estrangeiras – e permite uma adaptação mais rápida de novos fornecedores. Os padrões abertos também devem ser exigidos por permitirem uma maior democratização do acesso a tecnologia e reduzirem a dependência de soluções proprietárias.
7
Contribuição: Utilizar volume e tempo de contribuição de funcionários para projetos de código livre como um critério técnico.
Justificativa: Uma vez que a adoção de Software Livre é considerada estratégica para o Estado, é importante que a administração pública estimule um maior número de contribuições a essa comunidade. Além disso, ao valorizar desenvolvedores que já contribuem em projetos, estará medindo de maneira mais eficiente a experiência comprovada dos fornecedores (uma vez que ter o seu código aceito em uma base é uma medida mais objetiva do que ter passado em uma prova de certificação).
8
Contribuição: Exigir dedicação exclusiva do Fiscal Técnico do Contrato e do Fiscal Administrativo do Contrato para projetos maiores do que um determinado limite.
Justificativa: Uma das principais causas de fracasso de projetos de software é a falta de envolvimento do contratante e problemas de comunicação relacionados. Por outro lado, entendemos que os funcionários do serviço público são naturalmente sobrecarregados e talvez não tenham o tempo necessário para o projeto sem dedicação exclusiva. Portanto sugerimos que esta alocação seja obrigatória em projetos mais arriscados para aumentar a probabilidade de sucesso.
9
Contribuição: Oferecer para projetos até um determinado valor a possibilidade da análise da solução técnica ser incluída como um percentual do custo e tempo do trabalho a ser feito pelo contratado (permitindo que o contrato seja terminado sem dano às partes caso após esta fase qualquer uma das partes determine que o projeto não pode ser realizado nos parâmetros estabelecidos anteriormente).
Justificativa: Dado que a elaboração de um edital e o projeto técnico relacionado já demandam um investimento da União em horas de seus funcionários e utilização de materiais, sugerimos que para projetos até determinado valor esse esforço possa ser alocado como parte do trabalho contratado sem maiores riscos de perda do investimento. Se a regras para término deste contrato forem claras, no pior caso só se perderá o custo da elaboração do projeto, algo que acontece hoje em editais tanto em casos de reescrita quanto em casos de disputa judicial.
10
Contribuição: Substituir parte das exigências de documentação por exigência de testes automatizados desenvolvidos em colaboração com os fiscais administrativo e técnico.
Justificativa: Hoje em dia existem técnicas modernas de desenvolvimento de software que garantem a qualidade do software mesmo após alterações no código. Estas técnicas podem incluir artefatos que são legíveis por indivíduos sem formação técnica. Estes artefatos são mais valiosos que documentação estática – e normalmente são chamados de “documentação viva” - pois devem ser atualizados sempre que alguma funcionalidade do software for alterada.
11
Contribuição: Remover referencias a definição de processo/metodologia de trabalho e arquitetura da solução (isso deve ser parte do trabalho da contratada).
Justificativa: A arquitetura e a metodologia de trabalho não são tão importantes quanto o objetivo da área ao contratar um projeto de desenvolvimento de software e normalmente os contratados tem maior exposição ao estado-da-arte e podem sugerir soluções melhores. Já existem técnicas bem desenvolvidas para derivar trabalho de desenvolvimento de software a partir de objetivos de negócio e por tanto a União deveria concentrar seu esforço em definir e medir o resultado esperado.
Então? O que acham? Essas recomendações são implementáveis? Vão gerar o resultado desejado? Vão ter consequências inesperadas? Comente abaixo!