A computação evoluiu muito nos últimos 35 anos…
De profissionais altamente técnicos que trabalhavam em gigantescos (e caríssimos) mainframes com cartões perfurados, terminais burros ou disquete a indianos trabalhando do outro lado do mundo, usando notebooks e Internet wireless.
Enquanto que há 35 anos só alguns nerds, estatísticos loucos, matemáticos pirados e técnicos de eletrônica curiosos mexiam (e pareciam entender) o desconhecido e promissor mundo da computação, hoje qualquer adolescente de 15 anos consegue programar, criar vírus, programas opensource, mexer com Linux ou configurar uma rede doméstica com compartilhamento de Internet banda larga…
Enquanto que de 1955 a 1971 programava-se apenas em Fortran, COBOL, ALGOL, Lisp, APL, BASIC, PL/1, Simula e Pascal, hoje temos mais de 110 linguagens de programação em uso.
Nessa verdadeira torre de babel criou-se a "análise de sistemas" e a "engenharia de software" no intuito de conseguir definir, planejar, implementar, testar, implantar, gerenciar e mantar um software, o que não vem acontecendo tão bem assim…
Surgiram padrões, métricas, entidades reguladores, ferramentas, técnicas, métodos, normas, indicadores de qualidade… mas mesmo assim o desenvolvimento de sistemas continuou sendo algo tão imprevisível que se parece mais com o desenvolvimento de um organismo vivo que com a construção de um prédio.
Programação orientada a objetos (OO), arquitetura orientada a serviços (SOA), padrões de desenvolvimento (Design Patterns) e qualidade de serviços (QoS) são alguns hypes que estão em voga para tentar arrumar tudo isso.
A necessidade atual da computação é capacitar profissionais para melhorar a qualidade de processos, produtos e serviços, buscando atingir padrões tanto nacionais quanto internacionais de qualidade e produtividade, no intuito de ser competitivo (competividade) e confiável (confiabilidade) no mercado globalizado.
Num caos tão grande que se tornou a computação, com necessidades tão urgentes de racionalização e controle, somos "obrigados" a burocratizar o trabalho: mantendo rastreabilidade, visibilidade, manutenabilidade do sistema, gerando métricas, evidências de testes, seguindo processos, utilizando frameworks, buscando CMM/CMMI, ISO9001…
O trabalho do desenvolvedor, do tester, do analista, do arquiteto, do líder, do gerente são burocratizados para manter uma "qualidade de processo" para chegar a uma "qualidade total". Algo importante, há de se admitir, mas que está, paradoxalmente, diminuindo a produtividade e a creatividade desses profissionais.
As organizações precisam de profissionais ABC: Analistas de Burocracia Computacional. São as pessoas que farão o "tramite legal" dos processos, acompanhando o trabalho dos profissionais técnicos e fazendo para eles as tarefas que não são técnicas, mas do processo. Praticamente um despachante!
Isso depende muito do projeto… trabalhei na criação do sistema de garantias da Clearing de Ativos e foram mais de dois anos de desenvolvimento, chegando a ter 30 programadores trabalhando.
Houve muito retrabalho, algum trabalho não aproveitado e muitas correções…
Como justificar o atraso, o gasto com pessoal e com hora extra para o diretor da área de tecnologia? Sem métricas, sem planejamento, sem um cronograma factível isso é impossível.
E mesmo com pequenos projetos, utilizando WebServices para serem reaproveitados ao máximo precisam seguir alguns padrões para conseguir interoperabilidade com outros sistemas…
Henrique, e onde é ensinado isso na faculdade? Na matéria que ninguém presta atenção e que é dada de forma instantânea: Engenharia de Software.
Sério, será que essa visão de querer departamentalizar tudo, não está errada?
Um analista de negócios, um de sistemas, um para modelar o BD, outro pra levantar requisitos, pra jogar tudo na mão de um programador que é o que recebe menos destes todos?
Um grupo pequeno, coeso, desempenhando múltiplas funções não é o mais indicado?
Não é melhor que um despachante que está ali no meio apenas para conferir se requisitos estão preenchidos?
Não sei..