Cargos de TI: O Analista de Sistemas

Na postagem anterior passei um pouco da minha visão sobre as atribuições do Analista de Suporte, e agora chegou a vez de falar do cargo que é o mais utilizado de forma errônea no mercado: o Analista de Sistemas.

Muitos profissionais - que apesar de serem sim analistas – recebem essa nomenclatura mas executam tarefas que muitas vezes passam longe da atribuição real de um Analista de Sistemas.  E isso se dá pelo fato de não existir um curso de graduação em “Análise de Suporte” ou “Análise de Processos”, por exemplo, que são áreas de atuação específicas mas que recebem muitos profissionais do curso de Análise de Sistemas.

O Analista de Sistemas, teoricamente, é o profissional que estará envolvido em projetos de desenvolvimento ou manutenção de sistemas, mas não necessariamente irá programar, ou seja, manipular diretamente os códigos-fontes que fazem um sistema 'rodar'. Essa é a atribuição do Desenvolvedor (ou Analista Desenvolvedor), cargo que será abordado em outra postagem. O Analista de Sistemas, no entanto, talvez seja o profissional que tenha mais interação com o Desenvolvedor (programador), pois é ele quem projeta o sistema, ao mesmo tempo que tem uma visão mais próxima à do usuário. Antes de um sistema começar a ser codificado, ou seja, construído, muitas informações são levantadas, no intuito de garantir que as necessidades do cliente vão ser atendidas, e de que os riscos (de erros ou da construção de um sistema pouco aderente) durante o projeto sejam minimizados.

Cabe ao Analista de Sistemas analisar os requisitos funcionais e não funcionais, ou seja, requisitos de funções que o sistema deverá ter, e requisitos de qualidade: performance do sistema, facilidade em seu uso (usabilidade!), proteção das informações, etc. Com essa frente junto ao usuário – ou ao Analista de Negócios, outro cargo que veremos mais para frente – o Analista de Sistemas deve interpretar de forma correta a necessidade do usuário, e mais importante, deve ter a capacidade de entender se o que o usuário está solicitando é coerente: praticamente todos os usuários não conseguem expressar tudo o que desejam, e quase sempre descrevem suas necessidades de maneira “traiçoeira”, pois, por já terem uma visão voltada para o negócio, não conseguem ter uma visão mais sistêmica para explicar o que realmente precisam.

Esses requisitos são coletados de diversas maneiras: por meio de questionários, por meio de estórias de usuários (uma tarefa dentro do processo de trabalho do usuário do sistema a ser construído), ou mesmo acompanhando o dia a dia do usuário, vendo de perto como o processo de trabalho dele é conduzido, ou seja, levantando o que chamamos de “as is”.

Além dos requisitos, que é a língua do usuário, o Analista de Sistemas desenha (modela) diagramas que facilitam o entendimento de quem vai desenvolver o sistema e focar na parte técnica: códigos, configurações, testes e lógica de programação. Alguns desses diagramas são:

Caso de Uso - onde são definidos todos os perfis de usuários e o papel de cada um dentro do sistema. Exemplo: Num sistema de hospital podem existir dois perfis: secretária e médico, onde a secretária vai agendar os pacientes para os médicos e os médicos por sua vez registrar o diagnóstico de cada paciente.

Diagrama de Classes – onde são definidos os conceitos do negócio e a relação entre eles. Exemplo: O sistema deverá guardar dados de Usuários, que podem ser médicos ou secretárias; deverá guardar dados do paciente, que só será vinculado a um médico após a geração de uma Ficha de Atendimento, que deverá conter informações pré-definidas de diagnóstico e assim por diante.

Diagrama de Atividades – onde são definidos fluxos de atividades (interações) a serem realizadas no sistema. Exemplo: Secretária agenda paciente para Médico (a), que gera Ficha de Atendimento (b) com determinado diagnóstico (c) e finaliza consulta (d) com a opção de imprimir uma receita (e).

Entre outros como Diagrama de Implantação, Diagrama de Fluxo de Dados, Diagrama de Componentes, etc.

O padrão mais difundido para modelagem desses diagramas é a UML (Unified Modeling Language), que possui duas categorias mais genéricas de diagramas: Os comportamentais e os Estruturais. Uma das ferramentas freeware (grátis!) mais conhecidas para modelagem em UML é o Astah Community, que possui interface amigável e ótima usabilidade.
A UML é definida pela OMG, que oferece certificações na área em três níveis: fundamental, intermediate e advanced.

Bom pessoal, procurei descrever de forma mais ilustrativa e abrangente as reais atribuições de um Analista de Sistemas, com uma abordagem diferente do que estamos já acostumados a ler em Wikipedias da vida. Essa é uma visão que eu tenho da atualidade, que pode continuar sofrendo alterações afinal TI é um mercado que sofre constantes mudanças. Pelo que leio, muitas das atribuições acima são conduzidas em várias situações pelos próprios Desenvolvedores; consequência da difusão de novas práticas, padrões de projetos e metodologias adotadas no mercado.

Quem for da área deixe sua opinião, e quem não for aponte no caso de algo não ter ficado claro!

Mais pra frente falarei um pouco dos seguintes cargos: Desenvolvedor, Analista de Teste, Analista de Implantação, Analista de Banco de Dados (DBA), Analista de Negócios, Analista de Projetos, Analista de Processos, Analista de Arquitetura de TI e Auditor de Sistemas.

Um abraço!

Analista de Processos ou Analista de Negócios?

No meio dessa obscuridade que é o mundo da análise de sistemas e da tecnologia em geral (pelo menos pra mim na data em que eu fiz esse post e pra massa), essa e outras perguntas são exemplos do que fazem com que nossa área ainda seja um pouco incompreendida pelos clientes.
E no meio de tantos títulos e cargos, aparecem estes 2 mencionados no título. E como entender, dentro desse contexto, esses termos tão genéricos, como "processo" e "negócio"?!

Negócio nada mais é que a atividade dentro empresa. Definição ainda muito genérica, pois não podemos dizer que o negócio da Pepsi é vender bebidas e ponto. Dentro da empresa, cada setor tem seus processos e rotinas, e cada um desses representam um negócio. Por exemplo, um dos negócios do RH da Pepsi é contratar profissionais capacitados e com o perfil que a empresa procura. Um dos negócios do setor de almoxarifado da TV Globo é controlar a saída de equipamentos de produção para estúdios e gravações externas. Ou seja, nesse ponto de vista, negócio é um objetivo alcançado por meio de processos.

E processos? Dentro de um processo temos basicamente:
- ATORES, que são os que participam do processo (ex.: vendedor, emissor de boletos, coordenador financeiro)
- PAPÉIS, que são assumidos por atores, dependendo da fase do processo (ex.: um emissor de boletos pode assumir o papel de "solicitante" quando pede uma autorização à um coordenador financeiro, mas pode assumir também o papel de "solucionador" ou "solicitado" (a nomenclatura é definida de acordo com a realidade do negócio, não tem regras) quando recebe uma solicitação do vendedor.
- AÇÕES, que são o que os atores executam (ex.: Abrir solicitação, Emitir boleto, Delegar tarefa, Aprovar solicitação, etc).
- STATUS, que significa o estado em que o processo se encontra (ex.: Aguardando emissão, Aguardando aprovação, Boleto emitido, Boleto cancelado, etc).
- ETAPAS, que são as atividades que compõem o processo (ex.: Reserva de produtos, Emissão de boleto, Aprovação de venda, etc).

Ou seja: Um ator assume um papel ao executar (ou executarem) uma ação dentro de uma etapa do processo, que faz com que o status referente a esse processo mude, até que o mesmo se conclua.
Um processo tem um caminho principal, mas não um único caminho. Se um coordenador financeiro não aprova uma venda, por exemplo, o processo direciona-se por outro caminho, e pode chegar a outro fim, diferente do fim principal que é o de "Entregar produto vendido", por exemplo.

Por fim, e chegando ao ponto, o analista de processos geralmente é um consultor, que não necessariamente é um profissional de TI. Mas podemos dizer que 90% deles trabalhará para o TI ou em conjunto com a TI., afinal o que gerencia ou otimiza processos são sistemas corporativos.
Sua função é mapear processos corporativos existentes e encontrar falhas nos mesmos para propor melhorias e consequentemente aumentar a produtividade dos setores envolvidos. Ou também criar um processo inexistente / formalizar um processo sem maturidade, onde um conjunto de tarefas é realizada de maneira sequencial dentro de uma empresa, só que de forma desorganizada.

"Desenhando": um processo de admissão de uma empresa e suas etapas (recrutamento, seleção, definição de salários, cargos e benefícios, contratação, e etc) pode ser organizado/otimizado dentro de uma sequência, onde cada setor do RH possui seu papel e suas ações possíveis dentro de suas respectivas responsabilidades, visando maior produtividade e confiabilidade. E o que vai garantir a integridade em cada uma das etapas desse processo é um sistema corporativo.

O analista de negócios também não é necessariamente um profissional de TI, mas que precisa estar atualizado e inteirado sobre as novas tecnologias. Seu papel é ter uma visão crítica tanto com a TI, quanto com o negócio (área cliente). E assim saber dosar as necessidades de negócio de uma empresa e influenciar nas decisões tomadas pelo TI.
Em um projeto de desenvolvimento de um sistema por exemplo, cabe ao analista de negócios entender qual a real necessidade da área cliente (informatizar processos, otimizar a gestão sobre atividades de um setor, ou coisas do tipo)  e tomar decisões em conjunto com a TI (áreas técnicas/especialistas em informática) sobre as melhores soluções para atender as necessidades do cliente, levando em consideração os delimitadores que existem no cenário de qualquer empresa, como custo e prazo de entrega.

Simplificando, o analista de negócios deixa o desenvolvedor do sistema focar nas tarefas e desafios técnicos, enquanto ele faz a interface com o cliente traduzindo de maneira clara as demandas para o desenvolvedor. Muitas empresas que não são de TI, deixaram de contratar profissionais técnicos (desenvolvedores e etc), para contratar analistas de negócios. Estes, por sua vez, representam a empresa e fazem a gestão/contratação de empresas terceiras para executar as atividades mais técnicas (como a análise de um processo, por exemplo) :-)

Alguma consideração? Alguma aresta? Deixe seu comentário!


* Este tópico foi postado em 19/03/2011 e editado e atualizado em 09/03/2012, com uma explicação mais clara e mais coerente sobre cada um dos cargos em discussão, que, inicialmente, não foram definidos e diferenciados entre si.