Questão de nome

Durante os últimos anos trabalhei ocupando uma posição que o mercado convenciona chamar de “Analista de Sistemas”.

Essa nomenclatura deixava clara minha missão: Eu deveria analisar sistemas.

Para tanto o sistema deveria chegar até mim definido e meu papel seria daquele que aplica conhecimento de computação para transformar a definição em código e por fim, num software que atenderia as especificações do documento de definição.

Eu não conheço muito bem a realidade dos analistas de sistemas no mercado internacional, mas creio que esse cargo(ou papel) nunca chegou a existir no Brasil.

A realidade do analista de sistemas não é receber uma definição mas sim, receber uma inception. Eu explico.

O que a maioria dos profissionais enxergam como definição de software no mercado brasileiro é na realidade a semente de uma definição caprichosamente (e algumas vezes verborragicamente) descrita em um documento de definição de escopo que uma vez entregue ao analista de sistemas deve tomar forma e ser realizado.

Aqui vem a história do que considero um erro: intitular-me ou me deixar intitular Analista de Sistemas.

Levo meu trabalho muito a sério e para cobrir essa falha no processo de definição eu procuro mergulhar na realidade do domínio a que o software se destina.

Assim eu acabei aprendendo sobre regras médicas, sobre modelos financeiros, sobre marketing, arcadas dentárias(sim, arcadas dentárias), R.H., Administração de ativos digitais, gerenciamento de documentos e outros domínios para os quais escrevi algum tipo de aplicação para solucionar algum tipo de problema.

Eu tenho certeza que outros analistas de sistemas se vêem todos os dias tomando o mesmo tipo de atitude, desesperados que estão para realizar seu trabalho com o máximo possível de informações e evitar o maldito (re)trabalho de alterar conceitos cruciais na arquitetura do software por causa de uma falha de entendimento(A.K.A. comunicação/definição).

Acontece que na mesma medida com que aprendia sobre negócios eu precisava aprender sobre programação. Todos os dias. Vou repetir para reforçar: TODOS OS DIAS! surgiam melhores soluções para problemas velhos e novos. Todos os dias um workaround morria. Todos os dias nascia uma nova estrela na área de tecnologia que fazia a luz curvar-se sob efeito da sua massa de conhecimento e levava luz onde não havia e trevas onde não antes havia luz (poético, mas necessário).

E me vi sempre tendo que escolher entre mergulhar no conhecimento de negócios ou no conhecimento de desenvolvimento de software. 
 Eu decidi, de certa maneira inconscientemente, e passei a repetir um corolário para referir-me a essa escolha. Algo que vim a saber depois que era de autoria de Abraham Lincon. Eis a frase original:

“Give me six hours to chop down a tree and I will spend the first four shapening the axe.” Me dê seis horas para derrubar uma árvore e passarei as primeira quatro afiando o machado.

Eis como eu costumo utiliza-la em uma das zilhares variações do tema:

Passar 70% do tempo afiando o machado e somente 30% cortando.

De maneira que nos últimos anos 70% do meu tempo de trabalho era investido em analisar o domínio do problema e 30% somente era implementar a solução para ele, logo, passei 70% do meu tempo fazendo algo para o qual meus empregadores não me contrataram.

Bem, só me resta dizer: Me desculpem.

A parte boa é que muitas vezes consegui entender que a solução de um problema não estava únicamente na implementação de um sistema. Na realidade, na maioria das vezes o problema não era nem aquele que fora apresentado inicialmente(este era mais como um reflexo do que o problema em si) e que antes mesmo de começar a programar, a melhor coisa a se fazer era pensar e repensar e repensar o problema até esgotar ou suas forças ou as dele(isso durava 70% do tempo).

No final, claro que eu continuo a aceitar o título de analista de sistemas quando necessário. É o que tem pra hoje. Mas eu descobri que talvez eu tenha agido todos esses anos mais como analista de negócios do que de sistemas e se me perguntarem hoje como eu descreveria me papel nas empresas em que trabalhei eu responderia da seguinte maneira:
 “Analista de negócios com uma forte(e narcisistica) skill de analista de sistemas”.

E termino com uma pergunta.

Como você descreveria seu papel na empresa em que trabalha?