Além do .NET

sábado, outubro 31, 2009

Vivendo e Aprendendo.

Um belo dia eu descobri que Analista de Sistemas realmente não existe.

Na semana desse mesmo dia, eu entendi que não se pode FABRICAR um software sob o paradigma de uma FÁBRICA.

Dentro desse mesmo contexto eu avaliei que especializar-se é necessário sim, mas que o excesso de especialistas e a ausência de generalistas acaba por criar células isoladas.

Analista de Requisitos, Analistas de Sistemas, Arquitetos, Programadores, DBA´s Gerentes, Analistas de Teste, Executores de Teste, Analistas de Qualidade, Analistas de Métricas - Penso que a esmagadora maioria dos projetos não precisa de um profissional para cada um desses papéis, e até acho que todos esses papéis se fundem dentro de uma equipe enxuta, coesa, auto-grenciável, e multidisciplinar.

Ainda em meio a essas "descobertas" todas, comecei a encarar o CÓDIGO FONTE de uma outra forma. Antes de mais nada, o código é uma DOCUMENTAÇÃO. E digo mais, é a única documentação viva, certamente atualizada e confiável de um sistema.

Sempre que argumento algo desse tipo para, normalmente um não-programador, escuto coisas do tipo:

"Mas Analista de Requisito não entende de código, e nem deveria entender." Dizem eles…

Bem, quanto a isso eu sou radical. Acho que um mínimo de conhecimento técnico é essencial para QUALQUER profissional de TI que esteja envolvido em um projeto de Desenvolvimento de Software.

Analista de <coloque-aqui-o-que-quiser> que não cohece OO, ou que não tenha condições de transcrever um modelo de classes na tecnologia que está sendo utilizada no projeto, torna-se TOTALMENTE inútil para o projeto.

É óbvio, mas vou destacar, que um "Analista" não precisa ser expert em C# ou em Visual Studio, mas precisa SIM ter uma certa desenvoltura para abrir, compilar, debuggar o projeto; Entender grande parte do que está sendo feito nas classes do projeto, saber sobre o básico da arquitetura do projeto, ter condições de criar um teste unitário simples para validar uma determinada regra ou criar um novo cenário para uma regra já implementada... enfim... até posso concordo que a função principal desse profissional não será ficar com a IDE aberta o tempo todo, mas sim, ele tem que ter condições para trabalhar com ela.

E nesse contexto onde o código fonte torna-se essencial para um projeto, e não apenas um monte de palavras que representam uma meia dúzia de modelos UML, nasce a necessidade do código legível, do código com expressividade. Nasce a necessidade de outra categoria de profissionais de TI. Profissionais esses que não podem ficar se escondendo atrás de papéis e de artefatos, mas sim fazer diferença na equipe. E eu vejo que o mercado está muito carente desse perfil de profissionais.