Regulamentação da nossa profissão
Postado por Osvaldo Santana
Esse é o assunto polêmico do momento. Parece que se fala disso em todos os sites de tecnologia do momento mas acredito que a minha opinião sobre esse assunto ainda não apareceu em nenhum deles.
Por essa razão vou escrever a minha opinião sobre o tema aqui no meu blog para que as pessoas que pensam o mesmo que eu possam se manifestar sobre o assunto.
A minha opinião sobre a tentativa de regulamentar as profissões ligadas à informática é: eu não me importo.
Sério. Eu não me importo se a profissão na qual eu trabalho vai ser regulamentada ou não. Porque eu não me importo com isso? Porque eu estou me formando e já trabalho a mais de 5 anos na área. Para as pessoas nessa situação nada vai mudar.
O cenário onde nossa profissão não é regulamentada é o que vivemos hoje, logo, não vou me alongar muito nas explicações sobre ele e falarei mais sobre o cenário hipotético onde a regulamentação exista.
Hoje um profissional da área que busca o seu lugar no mercado de trabalho se apresenta aos pretensos contratantes munido de todo o seu histórico profissional, ‘luta’ contra os outros candidatos e, no final, ganha ou perde a batalha (ou emprego).
Na ponta do contratante as variáveis usadas para escolher um candidato para a vaga aberta são muitas. Tem empresa que pede diploma, outras pedem *um bom diploma* e outras nem pedem um diploma. Algumas outras pedem certificações caras, outras pedem certificações baratas e algumas não pedem certificação. Algumas pedem experiência, outras pedem exageros de experiência e outros exigem inexperiência(!).
Mas tem algo que o contratante pede que é sempre uma constante: qualidade. A qualidade é uma característica ortogonal à todas as outras já mencionadas. A falta dela também. Então existem profissionais bons diplomados e não diplomados, Profissionais ruins certificados e não certificados e todas as outras combinações possíveis.
No cenário onde a regulamentação existe teríamos um grupo só com os profissionais diplomados ou com algum tempo de experiência que seriam carimbados com o selo “Regulamentado!”.
Pois bem, em que isso mudaria a vida dos contratados? Se eu não sou ‘regulamentado’ eu só conseguiria empregos onde a ‘regulamentação’ não é necessária restringindo aí as suas chances de ser contratado. Se ele for um bom profissional ele vai numa dessas ‘uniníquel’ estuda uns 2 ou 3 anos lá, pega um ‘canudo’ e grampeia junto com o Curriculum e tudo está resolvido. Só não pode esquecer de pagar a mesada para o órgão da categoria que seria criado à reboque da regulamentação.
Se o profissional não-regulamentado for muito bom *mesmo* e uma empresa o recusa por essa razão o azar é da empresa. Ela que se dane sozinha. Sorte do profissional também por não ter que trabalhar em uma empresa que considere o carimbo de “Regulamentado!” mais importante do que as qualidades do profissional.
Os profissionais regulamentados tem a ilusão de que com a regulamentação deixará de existir a concorrência desleal dos “Sobrinhos do Tio” que fazem um trabalho meia-boca por ‘délão’. Se fosse assim não teríamos mais abortos clandestinos no país, muito menos venda de medicamento sem receita, etc.
Não podemos nos esquecer que as empresas que querem pagar pouco sempre vão pagar pouco não importando se o profissional é regulamentado ou não ou se a qualidade do trabalho será boa ou não (Vale lembrar que a regulamentação também não garante a qualidade do serviço).
E na vida dos empresários, o que mudaria? Pouca coisa também. Se ele contratar um profissional regulamentado e o serviço for ruim o que acontece? Denunciá-lo por maus serviços é o mesmo que denunciar um médico por erro médico: você pode até ganhar alguma recompensa, mas o estrago já foi feito.
E se ele não faz questão de ter um profissional regulamentado ele vai contratar essa pessoa de qualquer jeito. Mesmo que seja para registrá-lo como ‘lavador de pratos’. Se eu fosse empresário eu não daria a mínima importância para o carimbo de “Regulamentado!” de um profissional porque estaria restringindo as minhas alternativas de contratação e fazendo isso quantos bons profissionais não-regulamentados eu estaria perdendo?
Eu faço faculdade e sei que isso não atesta a qualidade de um profissional. Também já fiz certificação e sei que isso também não atesta a qualidade de um profissional. Não vai ser um carimbo “Regulamentado!” que fará isso ser diferente.
E se a regulamentação não vai mudar em nada porque eu deveria me preocupar com ela?
Programação Extrema Explicada (Extreme Programming Explained)
Postado por Osvaldo Santana
Nunca gostei de estudar metodologias de desenvolvimento. Também não gostava das chatíssimas aulas de “Análise de Sistemas” que costumava assistir no curso de Processamento de Dados que fiz. E eu nunca gostei de estudar isso porque tudo que as metodologias diziam nunca se aplicava ao universo onde eu trabalhava.
Eu não trabalhava com coisas muito especiais. O tipo de software que eu costumava desenvolver era tão comum quanto os atuais sistemas de gestão para os quais essas metodologias de desenvolvimento dizem servir.
Um exemplo da minha experiência com essas metodologias ‘tradicionais’ tem relação com a análise de requisitos. Eu estudava tudo o que era dito sobre análise de requisitos e tentava aplicar no meu dia-a-dia mas nada funcionava. Eu me sentia o mais burro dos programadores por não conseguir fazer isso dar certo. Achava que o problema era comigo até perceber que o problema era do cliente.
A análise de requisitos ensinada pelos métodos convencionais não funciona porque nenhum cliente tem noção do que realmente precisa em um sistema. Eu percebi que o cliente sabe o que é o problema mas não sabe como resolvê-lo e em alguns casos ele sequer tem uma noção exata do problema a ser resolvido.
Se nem o cliente sabe do que precisa, para que serviria a melhor das análise de requisitos? De nada. E esse é o caso que se aplica apenas à análise de requisitos. Acredite em mim: eu tenho um caso desses para cada uma das etapas do desenvolvimento de uma aplicação.
Uma coisa que as metodologias de desenvolvimento atuais também assumem, de maneira errada, é que um software é algo estático. Isso é uma visão extremamente equivocada do que é software. Software é flexível, software muda (o tempo todo), software evolui, software cresce…
E é nessa diferença fundamental que a metodologia XP (eXtreme Programming) se difere das outras. Ela assume que software muda.
A algum tempo atrás, comecei a trabalhar em uma empresa que utilizava a metodologia XP para desenvolver alguns projetos. Por curiosidade fui dar uma olhada nessa metodologia e descobri que finalmente alguém, que trabalhou com desenvolvimento de software, tinha criado uma metodologia que reflete a realidade de um ambiente de desenvolvimento de software.
O livro “Programação Extrema Explicada” foi escrito por Kent Beck que é o idealizador dessa metodologia e que é o ponto de partida para muitos outros livros que detalham essa metodologia. É um livro curto, de leitura leve, e que fala direto com o desenvolvedor utilizando histórias reais no lugar de usar documentos formais e densos e chatos.
Ao mesmo tempo é um livro que ‘cutuca’ o desenvolvedor e levanta polêmicas sobre assuntos que deveriam ser debatidos por todos os desenvolvedores que já trabalharam em projetos que fracassaram.
Atualmente estou lendo a versão em português, traduzido pela editora Bookman, mesmo já tendo lido a versão original em inglês. Usando XP e relendo o livro estou confirmando que aquela sensação agradável que tive ao ler essa obra pela primeira vez é verdadeira.
Por essa razão considero a leitura desse trabalho obrigatória para todos os desenvolvedores, mesmo para aqueles que já conhecem XP e não gostam de algumas de suas propostas.
Para comprar: Programação Extrema Explicada - Acolha as mudanças ou Extreme Programming - Embrace Change
Leitura Obrigatória (Refatoração / Refactoring)
Postado por Osvaldo Santana
Quem me conhece sabe que adoro livros. Compro eles aos montes e quase sempre tenho uma fila interminável de leitura que nunca diminui.
Gosto de livros porque encontrei neles a melhor forma de aprender as coisas. Nunca gostei de salas de aulas e treinamentos mas sempre fui muito curioso e graças ao meu pai, que sempre lia muito, descobri que, no meu caso, a melhor forma de aprender algo novo é através dos livros.
Tendo lido vários livros eu consegui montar uma lista de livros que todos os desenvolvedores de software deveriam ler ou ao menos ter em suas prateleiras para uma rápida consulta. Sei que o Google é uma excelente ferramenta de ajuda, mas em certas situações o bom e velho livrinho repousado ao lado do teclado nos inspira para o trabalho como se fosse alguém lhe dizendo o que deve ser feito.
Como a lista é razoavelmente grande e pode crescer ainda mais vou adotar a tática de postar um de cada vez (talvez dois, quando tiver mais inspirado) aqui no blog. Assim que um novo post surgir eu irei fazer uma cópia do conteúdo dele para na página de resenhas que ficará permanentemente nos links da barra lateral.
A lista que será apresentada não é definitiva e é formada por livros que eu li e por alguns que eu ainda não li mas sei que são indispensáveis. Também tenho livros que não servem para serem lidos de ponta-a-ponta, mas simplesmente para uma rápida referência.
Refatoração (Refactoring) - Martin Fowler
Esse livro é fundamental para aqueles programadores que começaram há pouco tempo a trabalhar mas que já possuem alguns sistemas desenvolvidos. Refatorar um sistema é o nome que o autor dá à prática de aprimorar e/ou mudar o código da aplicação sem que o comportamento visível dela se altere. O funcionamento da refatoração é assegurado pela construção de testes para o sistema que será refatorado. Esses testes servem justamente para garantir que o funcionamento do sistema não será modificado pela refatoração.
O capítulo que fala sobre ‘bad smells‘ já vale a compra do livro. É um dos melhores apanhados de problemas encontrados em código fontes existentes. Depois de falar sobre os ‘bad smells‘ do código um amplo catálogo de táticas e técnicas para refatorar o sistema é fornecido.
Este livro pode ser usado para a leitura de ponta-a-ponta e deve ser guardado para referências futuras. A tradução para o português foi feita pela editora Bookman e é muito caprichosa (como quase todas as traduções da editora).
Para comprar: Refactoring e Refatoração
