Regulamentação de profissões na área de TI

Há alguns dias recebi por email um link apontando para um projeto de lei (PLS – PROJETO DE LEI DO SENADO, Nº 607 de 2007)tramitando em nosso senado. O texto inicial é de autoria do senador Expedito Júnior,  com relatórios subseqüentes por Eduardo Azeredo e Marconi Perillo.

Meu ponto de vista, compartilhada por muitos, é de que é uma lei desnecessária. Inútil.

Imagino que o objetivo do projeto de lei, ao regulamentar a área, seja de atribuir responsabilidades à alguns tipos de pessoas.  Para isso precisamos:

  1. identificar as responsabilidades;
  2. identificar as pessoas.

Estas responsabilidades,  ao menos até o último texto, são descritas como:

É privativa de Analista de Sistemas a responsabilidade técnica por projetos e sistemas para processamento de dados, informática e automação, assim como a emissão de laudos, relatórios ou pareceres técnicos.

E as pessoas descritas como (grifo meu):

Art. 1º É livre, em todo o território nacional, o exercício das
atividades de análise de sistemas e demais atividades relacionadas com a Informática, observadas as disposições desta Lei.

O grande  problema é de tentar atribuir uma ampla gama de responsabilidades a um espectro imenso de profissionais.  Contornando este último  problema define-se Analista de Sistemas, profisisonal apto a exercer análise de sistemas e demais atividades relacionadas com a Informática, como a pessoa formada nos cursos superiores de Análise de Sistemas, Ciência da Computação ou Processamento de Dados.

Isto não leva em conta muitas questões, levantadas por pessoas mais aptas que nossos representantes no legislativo: a ACM, a IEEE e a SBC, como cita Phillip Calçado. O resultado a que chegaram:

ACM e IEEE:

“ACM is opposed to the licensing of software engineers at this time because ACM believes it is premature and would not be effective at addressing the problems of software quality and reliability.

SBC:

  1. Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal.
    1. Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima.
    2. A área deve ser Auto-Regulada.

Sabemos que na prática esta lei não mudará nada, a não ser a necessidade de,  em orgãos públicos ou que prestam serviços ao governo,  existir algum Analista de Sistemas para assinar e se responsabilizar por um sistema de informação.

Acredite, se quiser

Muita gente clama pela lei e espera que ela seja selada, registrada, carimbada, avaliada, rotulada, aprovada. Acreditam que uma lei diferenciaria os profissionais entre competentes e não-competentes. Acreditam que é necessária uma lei para distinguir entre competentes e não-competentes. Acreditam que este é um bom modo de justificar o tempo e dinheiro gasto para se formarem.  Acreditam que empresas que não sabem contratar, vão passar a saber depois da lei.  Acreditam que seus salários vão subir. Acreditam que a profissão está banalizada, e este é um passo para torná-la séria.

É muita coisa para se acreditar.  Sinto muito, mas não acredito em nenhuma delas.  Acredito que produzir melhor e com mais eficiência seja mais importante. Uma graduação não te garante isto. Uma boa graduação ajuda. Bastante. Ou inteligência, habilidade  e perseverança. Deixe o *mercado *separar o joio do trigo. Ele tem mais prática e competência neste jogo.

Contramão

Enquanto nossos políticos se preocupam em regulamentar uma profissão, há quem diga que ela está morta.  O controle é ilusão, ao menos nos projetos que importam:

Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We’ve been rather successful at transformation, often while operating outside our control envelope. Software development is and always will be somewhat experimental.

Regulamentar, controlar, guiar. Parece não ser o caminho para obtermos melhores resultados.