Cargos de TI: O Analista de Suporte

Dando continuidade aos tópicos sobre informática/TI – onde inicialmente foi passada uma visão sobre os cursos da área – para quem ainda está querendo se encontrar nesse mundo, inicio aqui uma coletânea de postagens com uma visão geral sobre os principais cargos da área de tecnologia e certificações para as suas diversas áreas de conhecimento. 
Cada cargo possui suas atribuições e peculiaridades, no entanto qualquer curso de tecnologia abre portas para todas as áreas de atuação, basta você se interessar e manter o foco nos estudos direcionados. 

Inicialmente, são abordados nessa coletânea os seguintes cargos: Analista de Suporte, Analista de Sistemas, 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.

Comecemos com o Analista de Suporte!

Esse profissional é o que vai estar sempre em contato com os problemas e dúvidas dos usuários ou com as mudanças realizadas no ambiente de TI. Conforme a idéia já passada no tópico sobre help-desk, ele geralmente começa atuando no primeiro nível, ou seja, atendendo todos os relatos dos usuários, resolvendo problemas mais conhecidos por telefone, ou registrando e direcionando os mais complexos para um profissional do próximo nível.

O analista de segundo nível é o que vai até o local, caso haja necessidade, para resolver problemas de complexidade intermediária ou problemas físicos, ou seja, relacionados ao hardware.

Quando o analista de segundo nível não consegue resolver o problema, ele encaminha todas as informações já levantadas para alguém da equipe de terceiro nível, compostas por profissionais especializados em diferentes competências: redes, sistemas operacionais, softwares ou hardware. O analista de suporte de terceiro nível pode atuar também em áreas mais voltadas para infraestrutura de redes, servidores, etc.

Problema do usuário resolvido, o primeiro nível é acionado para dar um retorno ao usuário e registrar um feedback sobre o atendimento. Perceba que o terceiro nível geralmente não faz contato direto com o usuário. Ele se concentra majoritariamente nos problemas já levantados pelos níveis anteriores. No caso de o problema ainda assim não ser resolvido, o mesmo já e enviado para outra esfera: os desenvolvedores do produto/serviço em questão (cargo que falaremos em outra postagem).

Apesar de ser um instrumento que pode ser utilizado em qualquer tipo de trabalho, o analista de suporte trabalha a todo o momento atualizando e consultando uma base de conhecimento (knowledge base), onde registra causas-raíz, ações, prevenções, investigações e soluções para problemas de diversas classes (rede, hardware, software, por exemplo), fazendo com que essa informação seja disseminada entre toda a equipe, independente do nível. Isso evita reincidências e agiliza o atendimento de um problema que, por mais complexo que seja, já possui sua solução conhecida.

Existem diversas certificações para o profissional que deseja ganhar visibilidade no mercado de suporte. O ITIL (Information Technology Infrastructure Library), por exemplo, é uma das principais certificações do mercado de tecnologia, e define as melhores práticas e processos para gestão, operação, manutenção e infraestrutura no ambiente de TI. A certificação possui 3 níveis: Foundation, Intermediate, Expert e Master.
As certificações costumam se adaptar às mudanças do mercado, e o ITIL por exemplo, está na sua 3ª versão. Portanto o profissional que consegue um certificado v3, é considerado mais atualizado que um profissional v2.

Outras certificações para a área de suporte são as da Microsoft, como a MCTS, MCITP e MCDST, detalhadas nesta página da empresa.

A área de Redes também possui boas certificações como CCNA, CCNP e CCIE (Cisco Certified Network Associate, Professional e InternetWork Expert, respectivamente) da gigante Cisco.

Estas certificações são muito valiosas e por outro lado são boas estratégias de empresas que já dominam o mercado, para fidelizar ainda mais seus profissionais. Assim eles se especializam e ganham status em cima da própria empresa. No final das contas, além de pagar para obter a certificação, ele vai promovê-la ainda mais, afinal foi a especialidade dela que o profissional desenvolveu.

É isso. Recordo que quando entrei na faculdade alguns professores menosprezavam a profissão de analista de suporte, infelizmente. Pois o que eu tenho visto é que é um profissional que, se especializando na área, pode sim ganhar excelentes salários, principalmente se trabalhar com infraestrutura.

Na próxima postagem será mostrado um pouco sobre o Analista de Sistemas, que apesar de ser o termo mais utilizado pelo mercado - muitas vezes de maneira errônea - possui atribuições específicas e que o diferenciam muito dos outros profissionais de tecnologia que muitas vezes são classificados como do mesmo cargo.

Comentem e acrescentem mais informações!

Os desafios do help-desk corporativo (spoc)

Há um tempo atrás, minha equipe foi convocada para uma reunião que visava melhorias no help-desk corporativo de onde estou trabalhando.
O chamado SPOC (single point of contact), conceito abordado em ITIL, até então parecia estar funcionando bem, com algumas exceções - isso na minha visão. Essa "certeza" durou pouco, e em menos de 5 minutos de conversa, entramos em várias questões e constatamos que havia muito o que evoluir.

Pra começar, e como o próprio nome já diz, o SPOC deve ser um ponto único de contato na resolução de incidentes ou no atendimento a serviços. Portanto, uma de suas premissas, é justamente o usuário receber atendimento de um mesmo ponto focal, sempre, até a conclusão do atendimento. Portanto, se o computador do Joaquim está travando, quem deverá ir em busca do solucionador para esse incidente é o atendente. O Joaquim deverá apenas relatar seu problema e aguardar a solução, não importa quantos departamentos se envolvam no caso.
Outro ponto que, justamente por estarmos falando de um help-desk corporativo, acaba acontecendo muito quando o atendimento está falho, é o usuário "ignorar" o help-desk e enviar e-mails diretamente para o departamento responsável, ou, no caso, no departamento que ele julga o responsável. O que pode acabar tornando-se muito comum e desgastante.

Para ilustrar, imaginemos que o sistema de folha de pagamento da empresa comece a apresentar erros desconhecidos justamente no dia do fechamento mensal. Como o usuário não tem visibilidade de toda a estrutura por trás de um sistema, é normal que imaginem que o incidente deverá ser resolvido pelo departamento que foi responsável pelo desenvolvimento desse sistema, e reclamar diretamente com os analistas do setor. Os analistas, mesmo orientando os usuários quanto ao procedimento correto, acabam sendo "obrigados" a se envolver e buscar uma solução, pois até então não há nada que evidencie que a causa do problema está desassociada do sistema. Os analistas perdem tempo analisando o incidente, e depois de algumas horas buscando a causa diretamente no sistema, pode concluir, por exemplo, acionando outras equipes dentro da área de TI, que ocorreram atualizações e redefinições de segurança - em meio a outras dezenas que ocorrem mensalmente - nos servidores onde o sistema está hospedado, e por algum motivo não previsto tal melhoria acabou impactando no funcionamento das aplicações hospedadas nesses servidores e que, portanto, não é de responsabilidade da equipe que desenvolveu o sistema.
Por consequência, a satisfação do usuário sobre o sistema diminui, o mesmo acaba responsabilizando a equipe de desenvolvimento e ainda fazendo com que os analistas invistam tempo desnecessário analisando um problema que jamais iria ser identificado dentro da aplicação.

Esse é um caso dentre vários outros que podem ser muito comuns, principalmente quando a área de tecnologia da empresa possui certo nível de maturidade e é, consequentemente, descentralizada, com diversos departamentos: sistemas, infraestrutura, operações, banco de dados, administração de usuários e redes, e etc.

O papel do SPOC é essencial em casos como esse, e uma boa prática para auxiliar nesse processo é a separação do atendimento do help-desk em 3 níveis:

- Atendimento 1º nível - É o atendimento realizado pelo analista que faz a interface inicial com o usuário, que possui menos conhecimento técnico do que os analistas de segundo nível, no entanto um conhecimento genérico maior. O papel do analista de 1º nível é resolver problemas básicos por telefone ou remotamente e, se não resolver, saber filtrar e encaminhar para o departamento correto o problema reportado.

- Atendimento 2º nível - É o atendimento prestado pelo analista com maior conhecimento no assunto em questão. Os procedimentos serão realizados junto ao usuário, se for o caso, ou, no exemplo dado anteriormente, no servidor do sistema que ocorreu o problema.

- Atendimento 3º nível - É o atendimento prestado por um especialista. Quando nenhum dos outros 2 níveis conseguirem encontrar a solução para o incidente, o mesmo é encaminhado para o terceiro nível.

Assim, os especialistas - que são menor número na empresa - envolvem-se apenas nos problemas com maior criticidade, enquanto o 1º nível envolve-se em todos, direcionando para os devidos analistas o que não for de sua competência.
Vale ressaltar que, mesmo havendo o envolvimento de todos os níveis no atendimento de um incidente ou solicitação de serviço, quem deverá ser a interface do usuário com o setor de TI, é o 1º nível, preferencialmente o mesmo analista, evitando assim de o problema ter que ser reportado e explicado mais de uma vez. Quem fará então a busca da solução junto aos outros níveis e aos setores envolvidos é o analista de 1º nível.

Com uso do SLA (service level agreement), mais um conceito de ITIL, o help-desk deverá estabelecer junto ao usuário um tempo para atendimento da solicitação em questão, levando em consideração severidade (relacionado aos impactos técnicos), prioridade (relacionado aos impactos no negócio) e, consequentemente, criticidade. Isso evita, por exemplo, as ligações para questionar se o problema já foi resolvido. É óbvio que o grande desafio aí, é o alinhamento de todas as áreas envolvidas para que o chamado seja realmente atendido respeitando o SLA.

Outro ponto abordado em ITIL, e que também aplica-se muito bem para o help-desk é a base de conhecimento (ou Knowledge Base). Todo o conhecimento adquirido, lições aprendidas, definição de conceitos técnicos e resolução de problemas devem ser inseridos no KB. A base de conhecimento poderá ser acessada e também abastecida pelos próprios usuários, facilitando a resolução de problemas sem envolvimento do help-desk e incentivando a cultura de compartilhar como resolver determinados incidentes. Reuniões semanais entre as equipes de analistas são importantes para organizar e induzir o compartilhamento dessas informações, fazendo com que problemas já conhecidos sejam atendidos com eficácia.

Ao fim da reunião, concluímos que o help-desk (ou service-desk, que tem um papel mais abrangente que o help-desk) precisa, diante desses conceitos, atentar para 3 fatores:

- Interpretação:
O atendente de 1º nível pode de repente não saber como resolver um assunto, mas ele tem que entender do que o usuário está falando. Dentro de um ambiente onde centenas de softwares/sistemas são utilizados, é comum surgirem requisições de serviços para sistemas específicos, em que o 1º nível jamais estará capacitado para resolver. No entanto, é extremamente importante que o atendente compreenda cada ferramenta e assim entenda de fato o que o usuário quer.
O grande desafio aí, é que geralmente o help-desk é operado por uma consultoria, que não tem conhecimento e nem proximidade às mudanças que ocorrem dentro da empresa. A comunicação entre ambas as partes é essencial para que o help-desk esteja alinhado a realidade e atualizações da empresa. A questão da base de conhecimento é importante nesse aspecto. Uma prática que ilustra bem, é a criação de um script de atendimento para cada sistema que entra no ar dentro da empresa. Supondo que um novo sistema de requisição de férias entrou no ar: o departamento de desenvolvimento deve ter como obrigatoriedade antes de implantar o sistema, criar um roteiro conceitual e de atendimento, citando os módulos do sistema, e como proceder diante de um problema ou mesmo uma requisição (de cadastro de novo usuário, por exemplo).

- Direcionamento:
O exemplo utilizado no início do texto, onde o usuário reclama que a aplicação de folha de pagamento apresenta um erro, serve para ilustrar esse fator. A princípio a solução do incidente parece ser de responsabilidade da equipe de desenvolvedores, e ninguém mais. No entanto, se o help-desk estiver alinhado com todas as equipes, ele conseguirá entender e enxergar que o erro só ocorreu depois de uma mudança, que, no caso exemplificado, foi realizado por uma outra equipe de TI. Assim, é possível ver que é maior a probabilidade dessa equipe (e não a de desenvolvedores) ser a solucionadora desse problema. Isso não iria impedir que o help-desk direcionasse o chamado para outras equipes que talvez sejam as solucionadoras, no entanto, sabendo quem pode influenciar no caso reportado, ele envolve as pessoas corretas e reduz o tempo no diagnóstico da causa; e consequentemente no atendimento do chamado.

- Retorno:
Isso todos nós desejamos em qualquer tipo de solicitação. Seja quando ligamos pra solicitar um serviço no banco ou fazemos uma reclamação online à uma empresa de telefonia. O retorno é crucial para que o cliente (interno ou externo) sinta-se seguro com relação ao atendimento. É melhor entrar em contato para dizer que ainda estão atuando, do que simplesmente ignorar e deixar de posicionar o solicitante.

Poderíamos evoluir ainda mais se continuássemos destrinxando cada um desses tópicos, mas, a princípio, foi isso que destacamos para um mundo ideal, (ou quase ideal). E que por sinal também se aplicaria muito bem em call centers que atendem o público em geral...

Aguardo comentários e novas abordagens sobre o assunto! Tweet