O desaparecimento do Analista de Sistemas deixou uma lacuna nas empresas?

Durante muitos anos, existiu nas equipes de tecnologia um profissional chamado Analista de Sistemas.

Hoje, tenho a impressão de que esse cargo praticamente desapareceu, e em seu lugar surgiram desenvolvedores, especialistas em UX, scrum masters, testadores, arquitetos de soluções, product owners e uma infinidade de outras especializações.

Basta procurar no LinkedIn. Encontramos vagas para desenvolvedor, analista-desenvolvedor, engenheiro de software e arquiteto. Mas dificilmente encontramos uma vaga para Analista de Sistemas com esse nome.

A especialização, evidentemente, trouxe muitos benefícios. O problema é que, sempre que trabalhei em equipes formadas por tantos papéis diferentes, uma pergunta continuava voltando: Quem é a pessoa, nessa equipe, que realmente conhece a área de negócio atendida pelo sistema ou pelo projeto?

O elo entre o negócio e a tecnologia

Estou falando de alguém que consegue conversar com o usuário, compreender seu problema e traduzir essa necessidade para a equipe técnica de maneira que ela possa, finalmente, transformá-la em software.

Algumas pessoas pensam que a principal função do Analista de Sistemas era produzir documentação. Não era. A documentação era uma consequência do trabalho, influenciada pela metodologia adotada pela empresa.

O verdadeiro trabalho do analista começava antes da solução. Era preciso entender profundamente o problema. O analista fazia perguntas, investigava exceções, identificava inconsistências e descobria onde uma regra de negócio poderia interferir em outra.

Também precisava conhecer o sistema suficientemente bem para avaliar os efeitos de uma mudança. Uma alteração aparentemente simples poderia afetar programas, arquivos, processos batch, integrações, relatórios e rotinas executadas em outros pontos do sistema.

Trabalhei com excelentes analistas que não programavam muito bem, mas ainda assim eram extraordinários naquilo que mais importava: descobrir o que precisava ser feito e traduzir esse conhecimento para a equipe que ia realmente meter a mão na massa.

O Analista de Sistemas ligava dois mundos diferentes: o mundo do negócio e o mundo da tecnologia.

O conhecimento não desapareceu, mas foi pulverizado

O sistema continua funcionando. Os desenvolvedores continuam implementando ou alterando funcionalidades. Os testadores continuam testando. Os arquitetos continuam definindo soluções. O product owner continua priorizando o backlog. E o conhecimento de negócio está distribuído entre esses agentes.

Algumas pessoas podem ponderar que o product owner assumiu a função que era do analista de sistemas. Mas tenho dificuldade em acreditar nisso.

O product owner conhece as prioridades, as solicitações dos usuários e aquilo que deve entrar em cada entrega. Mas será que ele enxerga o sistema como um todo e sabe associar seus diferentes componentes às regras da área de negócio que ele está atendendo? Será que ele sabe explicar por que determinada rotina existe em um sistema que está na empresa há mais tempo do que ele?

Ou… ele acredita que o dev, o arquiteto, o testador, o scrum master ou quem quer que seja saibam?

A terceirização agravou o problema

Dito por alguém que passou praticamente a vida inteira prestando serviço para empresas, essa afirmação pode soar demagógica.

Mas a busca pela máxima eficiência no uso de recursos (inclusive humanos) levou gradativamente ao fim dos especialistas em processos de negócio. Aquele analista que tinha décadas de experiência em sistemas de tarifação, faturamento, cobrança, empréstimo, arrecadação, benefícios ou mercado futuro deu lugar a técnicos com perfeito domínio de linguagens de programação, frameworks e patterns mas que não têm tempo para entender como o sistema atende o negócio de seu usuário.

Profissionais entram e saem das equipes constantemente. Com frequência, são contratados para fazer alterações pontuais em sistemas que levaram décadas para serem construídos. A pessoa recebe uma tarefa, implementa a mudança e segue para outro projeto.

Pouco a pouco, a entropia toma conta do sistema: código morto, funcionalidades duplicadas, regras implementadas no lugar errado, validações cuja finalidade ninguém conhece, rotinas executadas em pontos inadequados do processamento, componentes que ninguém se sente seguro para alterar etc.

Isso não acontece necessariamente porque faltam bons programadores. Muitas vezes, acontece porque falta alguém que faça a ligação entre as necessidades do negócio e o sistema que está em produção.

A função continua sendo necessária

Talvez o Analista de Sistemas não tenha simplesmente desaparecido. Talvez sua responsabilidade tenha sido fragmentada entre vários papéis. A rigor, não há nenhum problema em realizar uma reunião com oito pessoas para tentar entender o que, antes, um único analista conseguiria explicar.

O problema só começa a ficar evidente quando processos de due diligence se tornam necessários e mais longos, projetos ficam mais caros e as intervenções botam o negócio em risco.

Porque programas mudam. Linguagens mudam. Metodologias mudam. Arquiteturas mudam. A terminologia técnica muda. Mas a empresa continua existindo, e o negócio muda mais lentamente.

Ter alguém que saiba como um sistema de suprimentos, faturamento, arrecadação ou benefícios costuma ser organizado continua sendo essencial para intervir em sistemas com dezenas de milhares de programas e milhões de linhas de código.

Mesmo que seja apenas para orientar o próximo terceirizado que entrar na equipe para alterar o sistema.