Não é segredo que os analistas são uma das profissões mais livres e multifacetadas. E, apesar da presença de até dois padrões profissionais, cada empresa descreve individualmente a gama de tarefas atribuídas ao especialista que ocupa esse cargo. No meu artigo, quero compartilhar minha experiência pessoal e dizer quais funções um analista pode combinar durante um projeto comum, quais tarefas encerrar e também onde desenvolver se o emprego principal do projeto se tornar completamente chato.
Espero que minha história o ajude com surpresa a descobrir o que seus irmãos são em mente e também a destacar possíveis pontos de crescimento e desenvolvimento.
Isenção de responsabilidade
Tudo o que será discutido mais adiante é uma experiência puramente pessoal em um tipo muito específico de atividade, consistindo no desenvolvimento e implementação de soluções personalizadas baseadas em um sistema específico com sua própria plataforma e linguagem de programação.
Além disso, essa atividade é adicionalmente limitada pelas especificidades do sistema implementado, bem como pelas tecnologias internas dos fornecedores que atuam como padrões locais.
Bem, como uma cereja no bolo - essa atividade é realizada para o benefício da empresa sangrenta. E quando falo sobre a sangrenta empresa, quero dizer projetos em empresas muito grandes - quase todo petróleo e gás, grandes bancos, industriais, varejo, etc.
Dessa forma, o analista, que será discutido no artigo, é uma pessoa que existe dentro de todo o paradigma mencionado acima. Além disso, esta é uma pessoa muito real e viva, não importa o quão esférico um cavalo no vácuo ele lhe parecesse durante a leitura.
Preliminares
Em geral, o tópico da autodeterminação do analista no espaço é bastante explosivo. Toda vez que a pergunta “quem são esses malditos analistas no final” é levantada em comunidades profissionais, fóruns, reuniões, conferências ou em salas de bate-papo com telegrama, começam holívoros ferozes, durante os quais alguns analistas provam para outros analistas que cada um deles deve e não deve fazer.
Torna-se ainda mais engraçado (ou mais triste) quando vários eychars ou metodologistas começam a discutir esse tópico.
Em todos esses holívoros, prefiro tomar uma posição, cuja essência está em uma única palavra - especificidade. Em outras palavras, todos precisam entender que o conjunto de funções e tarefas do analista sempre varia muito, dependendo do empregador final, do projeto e da equipe.
Talvez você esteja se perguntando - por que de repente eu decidi que poderia falar sobre isso? Tudo é simples. Basta listar os papéis que altero ao longo do meu projeto:
- analista de negócios;
- analista de sistemas;
- Designer de UI / UX;
- escritor técnico;
- testador;
- professor
- suporte.
Se estamos falando de projetos de maior complexidade e escala, com uma equipe de vários analistas, entre os quais podem haver iniciantes, funções adicionais são adicionadas:
- mentor;
- Líder técnico;
- Líder da equipe.
E em toda essa variedade de papéis, trabalho há quase oito anos.
O mercado
No entanto, vamos começar de longe. Ou melhor, com a situação que se desenvolveu no mercado agora.
Se você for, por exemplo, a um headhunter e direcionar a palavra "analista" para a linha de pesquisa, toda a riqueza de fantasias e interpretações sobre o assunto cairá sobre nós.
Obviamente, analistas comuns são os mais comuns. Sem qualquer esclarecimento, longe do pecado. Na descrição dessas vagas, você pode ver muitas funções, tarefas, responsabilidades e requisitos interessantes diferentes para os candidatos.
Alguns empregadores ousam expressar a categorização em analistas de negócios e de sistemas em suas vagas e, assim, praticamente abrem um buraco para si mesmos. Eles nem imaginam quantos analistas foram mortos nessa batalha sangrenta.
A categoria simplificada e ampla de analistas de TI é bastante popular. Em sua descrição, geralmente, todo o campo russo de experimentos com responsabilidades, limitado, de fato, apenas à esfera de TI. Essas vagas me lembram muitas histórias de tyzhprogrammers que são solicitados regularmente a consertar um aspirador de pó ou uma chaleira.
Honestamente, aqueles que pelo menos tentam indicar no título o que exatamente precisa ser "analisado" estão agindo. Como resultado, aparecem vagas completamente diferentes, como "Analista SQL", "Analista de processos de negócios", "Analista de requisitos", "Analista 1C", "Analista de vendas", "Analista de vendas", etc. No entanto, isso não salva a diferença de tarefas, mesmo em vagas com dois nomes idênticos.
Padrões
Parece que o ponto nesta história deveria ter sido definido por padrões profissionais, cuja tarefa é exatamente fixar os objetivos de uma atividade profissional específica e fornecer uma descrição exaustiva das funções trabalhistas de um especialista, as ações executadas no âmbito de sua implementação, bem como o conhecimento necessário e habilidades.
Mas lá estava.
Obviamente, você precisa se alegrar com o fato de os padrões ainda existirem, embora tenham aparecido relativamente recentemente. O padrão para analista de sistemas no outono terá cinco anos. Significativamente mais tarde, o padrão para análise de negócios foi reforçado - ele não tinha nem um ano de idade.
É interessante que esses padrões já estejam declarando a diferença entre um analista de negócios e de sistema no nível de códigos de área profissional: para um analista de sistemas, o código 06 é indicado e para um analista de negócios - 08. Em outras palavras, um analista de sistemas é classificado como profissional no campo de “comunicação, informação e comunicação”. tecnologia ”e analista de negócios - na área de“ finanças e economia ”. E sem TI para você.
Se avançarmos para os objetivos da atividade profissional, consagrados nos padrões, a diferença se tornará ainda mais óbvia e divertida. O analista de sistemas, por se referir à área de TI, é responsável por trabalhar com os requisitos com a consciência limpa, mencionando software, sistemas automatizados, em geral, tudo o que amamos. O analista de negócios, por sua vez, não trabalha com requisitos, mas com necessidades, mas seu objetivo é focado em mudanças benéficas na organização. E, lembre-se, nem uma palavra sobre sistemas ou sistemas de hardware e software.
Ao mesmo tempo, um grande número de pessoas envolvidas na criação de vários tipos de produtos de software possui uma entrada simples "analista de negócios" em sua pasta de trabalho. No entanto, por que ir longe, pessoalmente, durante oito anos, quem quer que fui chamado, desempenhando as mesmas funções. Portanto, para não me envolver em disputas terminológicas, na narração adicional usarei a palavra mais geral e neutra "analista".
Missões
Vamos passar para os detalhes.
Qualquer projeto em que nosso analista participe de uma maneira ou de outra passa por 4 missões globais, vamos chamá-las de pré-venda, pré-projeto, projeto e implementação. Obviamente, o analista pode não participar de todas as missões, mas conectar-se isoladamente a qualquer uma delas, mas, como estamos mudando para o modo super-herói, vamos falar em detalhes sobre cada uma. Farei uma reserva imediatamente; removi a escolta como uma missão deliberadamente, porque Considero inadequado manter um especialista de alto nível nessas tarefas.
Pré-venda
A primeira missão é, é claro, pré-venda.
Vale ressaltar que nem todos e nem sempre conectam analistas a essa missão, considerando a pré-venda do feudo de vendedores e gerentes de projetos. No entanto, com o tempo, os analistas conseguiram provar sua utilidade e viabilidade nesse estágio.
Antes de tudo, o analista da pré-venda é útil, é claro, com conhecimento. Além disso, sujeito e sistema. Ao viajar com um vendedor para reuniões e demonstrações, o analista fala o mesmo idioma com o assunto e ajuda o vendedor a resolver várias situações associadas ao vocabulário e terminologia profissionais característicos. Além disso, possuindo um conhecimento mais profundo do sistema que está sendo vendido e uma vasta experiência no projeto, o analista concentra-se de maneira rápida e precisa nas possibilidades de atender aos desejos do Cliente, além de falar de forma convincente sobre a experiência existente na solução de problemas semelhantes.
Após uma série de reuniões bem-sucedidas, o analista começa a trabalhar isoladamente do vendedor e parte para o cliente por conta própria, realizando um estudo expresso de processos, sistemas existentes que exigem substituição, a infraestrutura na qual será necessário integrar etc.
Os resultados de todas essas atividades são os contornos delineados do projeto futuro, bem como os requisitos técnicos preliminares, segundo os quais será possível realizar uma avaliação inicial do tempo, mão de obra e custo do trabalho.
Pré-design
Depois que a venda é concluída e as medidas organizacionais para assinar o contrato e as danças rituais para inicializar o projeto começam, o analista não pode mais ficar ocioso, mas começa o trabalho preliminar.
Nesse estágio, ele já pode ter à sua disposição muitas informações para pesquisa: estes são os resultados da análise expressa e as anotações das reuniões e o ToR final que a equipe assinou e, com alguma sorte, uma pilha de vários padrões e regulamentos do cliente, cujos requisitos precisará ser levado em consideração no design futuro. Em outras palavras, é uma montanha de dados não estruturados que precisam ser processados e formulados em sua cabeça um conceito para uma solução futura.
Na maioria das vezes, essa missão é típica para projetos de larga escala com uma grande equipe. É neles que o analista se torna um especialista técnico e decide o que, figurativamente falando, construiremos nesse projeto - um navio ou um avião. Ele também coordena a equipe durante todo o projeto, ajudando a escolher as melhores soluções técnicas e substantivas, além de garantir a consistência do sistema projetado.
Mergulhando gradualmente no contexto do projeto futuro, o analista desenha sua estrutura e determina quais componentes isolados condicionalmente podem ser divididos nela. Depois disso, já junto com o gerente de projeto, ele distribui a equipe entre os blocos alocados. É muito importante levar em consideração as interconexões dos módulos do futuro sistema e entender exatamente qual quantidade de trabalho pode ser alocada com segurança para uma unidade independente.
Tendo estudado todas as informações atualmente disponíveis, o analista constrói o conceito de automação, onde o esqueleto do futuro sistema é moldado com grandes traços. São essas decisões que formarão a base de todo o trabalho adicional e definirão a direção para os analistas resolverem seus problemas locais em blocos independentes. Além disso, além do conceito, os primeiros diagramas de processo, ainda de nível superior, já podem aparecer. Na maioria das vezes, isso é, de alguma forma, um efeito colateral da imersão do analista no projeto - o resultado da análise das informações disponíveis. Porém, no futuro, esses diagramas também poderão ser guiados pelos analistas nos blocos quando forem ao Cliente para um estudo detalhado.
Além disso, o conceito está intimamente relacionado à arquitetura da solução - aqui o analista já interage com o desenvolvedor líder, integrando o sistema futuro ao cenário existente do Cliente e identificando os volumes da integração e migração necessárias, tanto inicial quanto regular.
Ao mesmo tempo, o analista não apenas se prepara para o próximo projeto, mas também prepara para ele um grupo de trabalho do Cliente - aquelas pessoas que se tornarão as principais fontes de requisitos para o futuro sistema no futuro. O analista realiza reuniões com o grupo de trabalho e demonstra uma versão em caixa do sistema, prestando atenção especial aos módulos e funções que serão afetados pela próxima implementação. A principal tarefa aqui é mergulhar o Cliente no contexto do sistema, a fim de diminuir a barreira e alcançar uma atitude mais informada em relação à geração de requisitos. Nas demonstrações, o analista "ao vivo" mostra como os itens de TK se encaixam ou se encaixam no sistema existente. Os primeiros pontos de ancoragem da TK e as reais necessidades do Cliente ocorrem aqui.
Projeto
O trabalho principal, é claro, começa diretamente no projeto. É nesta fase que os papéis estão mudando constantemente.
Primeiro, o analista trabalha em estreita colaboração com o Cliente como analista de negócios. Ao mesmo tempo, ele pode ocasionalmente sair para reuniões e entrevistas, ou até mesmo estar no território do Cliente em tempo integral. Nesta fase, é realizado um estudo aprofundado dos processos da empresa, identificados gargalos e necessidades de automação, além de consultas sobre possíveis soluções para os problemas encontrados. Além disso, essas decisões podem ser não apenas sistêmicas, mas também administrativas e organizacionais. Com base nos resultados do estudo, nascem diagramas detalhados e descrições dos processos de negócios “como estão” e “sendo”, com todas as sutilezas e opções possíveis para o desenvolvimento de eventos. Ao longo do caminho, os requisitos para os objetos do futuro sistema são identificados e coletados.
Quando as informações são coletadas, o analista de negócios é transformado em analista de sistemas, colocando os requisitos do Cliente nas capacidades de um sistema específico. Nesta fase, o design dos módulos do sistema é realizado, enquanto um analista experiente avalia independentemente a viabilidade de implementar um requisito específico e procura maneiras de contornar possíveis limitações da plataforma. No entanto, a falta de experiência sempre pode ser compensada por consultas com o desenvolvedor principal do projeto.
No mesmo estágio, o analista se torna um designer, projetando e desenhando layouts de futuras interfaces do sistema. É importante considerar não apenas o componente visual, mas também os postulados básicos do UX, bem como a lógica dos processos nos quais os objetos projetados participarão. Todas as formas de tela, mais cedo ou mais tarde, terão que formar uma única imagem lógica e harmoniosa, e o sistema terá que responder igualmente a ações idênticas do usuário.
Um estágio separado é o design de todos os tipos de integrações e migrações. Tudo depende da experiência do analista e de suas competências em sistemas. Em geral, o analista deve entender o lugar do sistema no cenário geral e ter uma boa idéia de sua interação com outros sistemas do Cliente. Essa interação deve ser descrita pelo menos no nível de entidades sobrepostas, regras para dados transmitidos e mapeamento de detalhes. A parte técnica do design é geralmente realizada pelo desenvolvedor.
Depois que todas as soluções são projetadas, o analista se torna um escritor técnico e escreve um documento grande e bonito que fornece uma descrição detalhada do futuro sistema. Este documento inclui esquemas e descrições de processos e interfaces desenvolvidos anteriormente, com uma descrição detalhada da lógica aplicada dos elementos e outras descrições de modificações que devem ser executadas no sistema para implementar as soluções projetadas. Aqui, a análise é auxiliada pela estrutura verificada do documento e modelos prontos que permitem que você não perca nada.
Depois de concluir a fase de documentação, o trabalho fundamental passa por pelo menos duas revisões - o analista líder e o desenvolvedor líder da equipe. E se possível - também revisão por pares externos por colegas de outras equipes e projetos. Após a revisão, o documento é enviado para aprovação do Cliente. Além disso, ele não recai sobre ele em um incompreensível Talmud de várias páginas, mas é mostrado pela primeira vez na forma de uma apresentação com explicações, músicas, danças e fotos engraçadas. Além disso, o analista acompanha o processo de aprovação, respondendo às perguntas do Cliente, corrigindo certas formulações e, se necessário, requisitos e soluções. Após a conclusão bem-sucedida da aprovação, o documento é enviado ao desenvolvimento.
Neste momento, nosso analista tem uma pequena pausa. No curso do desenvolvimento, ele, é claro, está conectado ao trabalho no projeto, mas com uma carga visivelmente menor. Suas tarefas são principalmente respostas a perguntas de desenvolvedores e atualização periódica de requisitos com o Cliente.
Quando o desenvolvimento é concluído, o analista se torna um testador e realiza um teste longo, cuidadoso e rigoroso das soluções desenvolvidas. Observarei imediatamente que estamos falando sobre testes de usuários, mas isso não significa que seja superficial. Cada botão é verificado, todas as janelas, todas as ramificações da rota, todos os formulários de relatório são criados, todos os scripts são iniciados. Ao mesmo tempo, o teste é dividido em dois grandes estágios. O primeiro passo é verificar as funções básicas. Tudo aqui deve funcionar como está escrito na documentação e como se um usuário experiente e conhecedor estivesse sentado no computador. Após a verificação de todos os cenários de uso positivo, o analista começa a "quebrar" o sistema e testá-lo da perspectiva de um usuário inexperiente, com preguiça de ler as instruções. Gostaria também de chamar a atenção para o fato de que, nesta fase, podem ocorrer refinamentos adicionais e finalização de decisões. Quando o teste estiver finalmente concluído, estamos prontos para a próxima missão.
Implementação
Nesta fase, o analista está envolvido na implantação e configuração do sistema nos servidores do Cliente. Inicialmente, é montado um circuito de teste no qual o grupo de trabalho, juntamente com a equipe do projeto, executará o teste final da solução. Para garantir esse teste, o analista escreve casos de teste, considerando quais cenários o Cliente precisará realizar para cobrir um máximo de funções por um período limitado de testes e convencer o grupo de trabalho de que tudo funciona como deveria.
Obviamente, a fase de teste novamente leva a um ciclo de especificação de requisitos, melhorias no sistema e testes repetidos, mas os desejos inesgotáveis do Cliente devem ser significativamente limitados por tempo e trabalho, tentando levar apenas os momentos mais críticos para o trabalho. A principal tarefa é colocar rapidamente em operação usuários ativos, não importa o quão desumano possa parecer.
Nesse estágio, o analista se transforma em um instrutor, instruindo usuários comuns do futuro sistema. O treinamento pode ser realizado de várias maneiras: cursos em período integral com tarefas práticas e certificações finais, seminários, seminários on-line, vídeos, screencasts, etc. As instruções do usuário são escritas em paralelo (embora, em geral, seu desenvolvimento comece na fase de teste interno).
, , , . , – , .
, , , . , , , .
, , .
Bonus-level
, , .
– . 3-4 . , , , , .
, , . , , .
– . . – .
– , , ..
, , - , , .
Epic-fail
, . . – overqualified.
. , , . , , .
, -. , , , . , . – , . . , .
, . – !