Quando me perguntam por aí qual a minha profissão, ou quando preciso responder isso em algum formulário “genérico”, costumo responder: Analista de Sistemas. É uma resposta também “genérica”, rápida, que não exige maiores explicações e satisfaz a maioria das perguntas - normalmente feitas apenas por obrigação.
Embora seja um termo meio “genérico” demais - e até obsoleto sob certos pontos de vista - ainda o utilizamos em muitos contextos, como no debate sobre a regulamentação da profissão. Não pretendo aqui entrar no mérito dessa discussão, mas refletir sobre o significado do termo em si, questão um pouco mais fundamental, cuja reflexão pode alimentar e influenciar opniões sobre o assunto.
Afinal, o que faz um analista de sistemas? Ora, se interpretarmos ao pé da letra, deve ser alguém que estuda sistemas e o divide (corta, quebra) em outros menores, mais simples, para que se possa compreendê-los mais facilmente. Não é difícil encaixar nessa definição alguns papeis e funções que costumamos ver em projetos de software tradicionais.
O “analista de requisitos” esclarece os detalhes de um dado domínio, através de modelos, diagramas e descrições. Seu “sistema” são os processos do cliente. O arquiteto analisa o problema em módulos, componentes, camadas, e outros recortes. Seu “sistema” é um programa, (ou vários) visto como um todo. O programador divide cada funcionalidade e operação em funções, procedimentos, estruturas de dados e instruções.
A visão tradicional de um analista de sistemas passa, de um modo ou de outro, por um desses aspectos. Ou por todos ao mesmo tempo, considerando-os especializações, ou rumos a se seguir dentro da profissão. Enxerga “o sistema”, portanto, como toda essa “coisa” que automatiza (informatiza) os processos do cliente.
Em metodologias ágeis costumamos identificar um número menor de papéis, ou especializações, criado uma visão mais holística de equipe, que ressalta valores como interdisciplinaridade, auto-organização, habilidades sociais, lideranças, etc.
Mas, se por um lado tem-se menos tipos de “analistas”, por outro enxergamos mais “sistemas” a serem analisados, compreendidos e geridos. Ou pelo menos um sistema mais completo, que vai além dos saberes técnicos que são ensinados nas faculdades de tecnologia - cursos focados em teorias e técnicas matemáticas, exatas, objetivas.
Essas metodologias reconhecem outros sistemas extremamente relevantes aos processos de desenvolvimento. Aspectos humanos e organizacionais, jogos de intenções e interesses, forças políticas, estruturas sociais e questões motivacionais. Um emaranhado de fatores que compõem o ambiente e a cultura da empresa, e que fazem parte do inconsciente coletivo da equipe. Questões importantíssimas e determinantes para o sucesso de qualquer projeto.
Um arquiteto pode estar mais preocupado com seu ego do que com o bom andamento do projeto, ao propor uma solução complexa demais; um gestor pode estar mais interessado em seguir uma tendência de pensamento com que sua gestão já se comprometeu; um programador pode não tirar uma dúvida importante de projeto com o cliente pela estrutura de comunicação que se criou; ou pode não sinalizar sobre um problema que identificou no design por causa de sua baixa auto-estima junto à equipe.
O desenvolvimento de software é acima de tudo uma atividade criativa, de aprendizado coletivo e de auto-conhecimento para todos: clientes, usuários, programadores. Ao mesmo tempo que a equipe está aprendendo os detalhes tecnológicos envolvidos na solução, usuários estão aprendendo a ver de forma mais clara seus processos de trabalho. A equipe como um todo (incluindo cliente e usuário) está aprendendo a se comunicar e a colaborar para desenvolver uma visão única e coesa do “sistema”, aprimorando seu processo de trabalho a cada dia (melhoria contínua).
Sob esse novo ponto de vista, a expressão “analista de sistemas” ganha uma conotação integral, levando em conta um sistema mais âmplo, que precisa ser não apenas analisado, mas percebido, compreendido, refletido e gerido.
Embora seja um termo meio “genérico” demais - e até obsoleto sob certos pontos de vista - ainda o utilizamos em muitos contextos, como no debate sobre a regulamentação da profissão. Não pretendo aqui entrar no mérito dessa discussão, mas refletir sobre o significado do termo em si, questão um pouco mais fundamental, cuja reflexão pode alimentar e influenciar opniões sobre o assunto.
Afinal, o que faz um analista de sistemas? Ora, se interpretarmos ao pé da letra, deve ser alguém que estuda sistemas e o divide (corta, quebra) em outros menores, mais simples, para que se possa compreendê-los mais facilmente. Não é difícil encaixar nessa definição alguns papeis e funções que costumamos ver em projetos de software tradicionais.
O “analista de requisitos” esclarece os detalhes de um dado domínio, através de modelos, diagramas e descrições. Seu “sistema” são os processos do cliente. O arquiteto analisa o problema em módulos, componentes, camadas, e outros recortes. Seu “sistema” é um programa, (ou vários) visto como um todo. O programador divide cada funcionalidade e operação em funções, procedimentos, estruturas de dados e instruções.
A visão tradicional de um analista de sistemas passa, de um modo ou de outro, por um desses aspectos. Ou por todos ao mesmo tempo, considerando-os especializações, ou rumos a se seguir dentro da profissão. Enxerga “o sistema”, portanto, como toda essa “coisa” que automatiza (informatiza) os processos do cliente.
Em metodologias ágeis costumamos identificar um número menor de papéis, ou especializações, criado uma visão mais holística de equipe, que ressalta valores como interdisciplinaridade, auto-organização, habilidades sociais, lideranças, etc.
Mas, se por um lado tem-se menos tipos de “analistas”, por outro enxergamos mais “sistemas” a serem analisados, compreendidos e geridos. Ou pelo menos um sistema mais completo, que vai além dos saberes técnicos que são ensinados nas faculdades de tecnologia - cursos focados em teorias e técnicas matemáticas, exatas, objetivas.
Essas metodologias reconhecem outros sistemas extremamente relevantes aos processos de desenvolvimento. Aspectos humanos e organizacionais, jogos de intenções e interesses, forças políticas, estruturas sociais e questões motivacionais. Um emaranhado de fatores que compõem o ambiente e a cultura da empresa, e que fazem parte do inconsciente coletivo da equipe. Questões importantíssimas e determinantes para o sucesso de qualquer projeto.
Um arquiteto pode estar mais preocupado com seu ego do que com o bom andamento do projeto, ao propor uma solução complexa demais; um gestor pode estar mais interessado em seguir uma tendência de pensamento com que sua gestão já se comprometeu; um programador pode não tirar uma dúvida importante de projeto com o cliente pela estrutura de comunicação que se criou; ou pode não sinalizar sobre um problema que identificou no design por causa de sua baixa auto-estima junto à equipe.
O desenvolvimento de software é acima de tudo uma atividade criativa, de aprendizado coletivo e de auto-conhecimento para todos: clientes, usuários, programadores. Ao mesmo tempo que a equipe está aprendendo os detalhes tecnológicos envolvidos na solução, usuários estão aprendendo a ver de forma mais clara seus processos de trabalho. A equipe como um todo (incluindo cliente e usuário) está aprendendo a se comunicar e a colaborar para desenvolver uma visão única e coesa do “sistema”, aprimorando seu processo de trabalho a cada dia (melhoria contínua).
Sob esse novo ponto de vista, a expressão “analista de sistemas” ganha uma conotação integral, levando em conta um sistema mais âmplo, que precisa ser não apenas analisado, mas percebido, compreendido, refletido e gerido.
