Junto com meu aluno de mestrado, Carlos Alberto Franco, coordenador de projetos de desenvolvimento na Petrobras e recém mestre pela UFRJ, fizemos uma análise comparando a lei brasileira com a americana e a britânica.
Recentemente tivemos um artigo publicado na Revista do TCU (nº 128) que reflete parte desse estudo.
Mais detalhes podem ser vistos lendo a tese de mestrado defendida em fevereiro de 2014:
“Análise da legislação para a terceirização do desenvolvimento de software na administração pública brasileira em relação à norte-americana e britânica”. Há também uma apresentação online em formato de linha do tempo.
Fig 1: Revista do TCU onde publicamos sobre o tema. Apresentação interativa com a linha do tempo incluindo leis e eventos.
Qual o maior problema?
A desconfiança!
Especialmente a desconfiança que o governo (e nós, contribuintes) tem em relação aos prestadores de serviços.
Essa desconfiança justifica boa parte do conteúdo das leis vigentes.
Pergunta provocativa: as leis resolveram os problemas brasileiros de fraude e corrupção?
Como tentar resolver?
Aumentar a confiança!
Como?
- Ciclos curtos
- Transparência
Há um exemplo de que isso é possível em escala menor, que é recorrentemente observado na adoção de métodos ágeis em empresas.
Os métodos ágeis trouxeram conceitos de auto-organização para dentro dos times. Isso só foi possível ao se restaurar uma confiança entre a gerência e o time. O modelo predominante até então era: o chefe desconfiava dos seus empregados e por isso fazia um micro-gerenciamento para ter certeza de que estavam trabalhando. No novo paradigma a transparência (ex: quadros na parede, burn-down charts, software como medida de progresso etc…) e os ciclos curtos (ex: sprints de 2 semanas, tarefas do time de no máximo 1 dia de duração, etc…) trouxeram a confiança, que foi a chave para conseguirmos novos patamares de resultados em desenvolvimento de software.
A IN04 e o recente Acórdão TCU 2314/2013 sobre metodologia ágil são bons exemplos de iniciativas que demonstram preocupação em fazermos com que as coisas melhorem.
Mas queremos mais! Vamos pensar em atualizar a Lei 8666?
Como os americanos e os britânicos fizeram?
Nos Estados Unidos, obrigaram, por lei, que os ciclos de desenvolvimento fossem curtos.
Por lá, está proibido demorar na entrega de software!
A Clinger-Cohen Act de 1996 já dizia que “O chefe de uma agência de execução deve, até ao limite máximo possível, utilizar contratação modular para a aquisição de um grande sistema de informações tecnológicas. Além disso, a lei acrescenta que “sob o processo de contratação modular, uma aquisição de um grande sistema de tecnologia da informação pode ser dividida em vários pequenos incrementos de aquisição”. Finalmente, quanto ao prazo, a lei estabelece que “um contrato para um incremento (…) deve ser entregue no prazo de 180 dias após a data da solicitação”.
Na Inglaterra, algo semelhante foi feito, mas a restrição máxima do módulo foi estipulada em valor, e não em prazo.
O que mudar no Brasil?
A lei não pode obrigar a seguir um método. Normalmente, a lei busca o que não pode ser feito. Quando o governo americano sinalizou que a contratação na área de TI deveria ser modular e incremental, foi natural que as empresas prestadoras de serviços buscassem, nos métodos ágeis, a solução. Mas a adoção de tais métodos não foi uma imposição do governo, apenas a restrição colocada é que conduziu a essa solução.
Processo de licitação mais curto
Segundo a Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, a realização entre demanda e entrega de produto/serviço, em média, dura 270 dias. Com a Lei 10520, Lei do Pregão, de 2002, o tempo mínimo para a realização da licitação caiu para 37 dias. A dificuldade de disparar o processo de terceirização acaba por promover o inverso da modularização, pois o esforço é muito grande para que haja uma entrega pequena. Talvez, seja interessante uma proposta diferenciada para o desenvolvimento de software.
Atenção diferenciada para TI
O Decreto Lei 2271, de 1997, detalha alguns contratos de serviços passíveis de terceirização. Porém, nenhuma atenção é dada à TI, a qual é listada junto com outros serviços de natureza bem diferentes “atividades de conservação, limpeza, segurança, vigilância, transportes, informática, copeiragem, recepção, reprografia, telecomunicações e manutenção de prédios, equipamentos e instalações“. Precisamos deixar claro que desenvolvimento de software é algo diferente, é um processo criativo e de importância estratégica para o crescimento do país.
Conclusão
Recentemente (2013/2014) tivemos contato com dois deputados federais para tratar desse assunto. Há uma consciência crescente de que algo deve ser feito. Uma mobilização reivindicando maior atenção para TI poderia ajudar.
É importante que haja uma união em torno desse assunto. O TCU é visto muitas vezes como inimigo e isso não é bom! O ideal é sermos todos aliados e alinhados com o mesmo propósito: que o desenvolvimento de software no Brasil seja cada vez mais eficiente e eficaz.
