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 num 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(os) em relação aos prestadores de serviço.
Essa desconfiança justifica boa parte do conteúdo das leis atuais.
Pergunta provocativa: as leis resolveram os problemas brasileiros de fraudes e corrupções?
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 visto na adoção de métodos ágeis dentro das 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 sobre metodologia ágil são bons exemplos de iniciativas que mostram uma preocupação em fazermos as coisas melhorarem.
Mas queremos mais! Vamos pensar em atualizar a lei 8666?
Como os americanos e britânicos fizeram?
Nos Estados Unidos, obrigaram por lei que os ciclos de desenvolvimento fossem curtos.
Por lá, está proibido demorar para entregar 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 uma aquisição de um grande sistema de informações tecnologia.“. Além disso, a lei ainda 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 diz 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 por valor e não por prazo.
O que mudar no Brasil?
A lei não pode obrigar a seguir um método. Normalmente a lei cerca 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ço 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.
