Saudações! Meu nome é Sergey e sou analista de negócios / sistemas. Trabalho no setor de TI há cerca de 8 anos, começando com o suporte que flui para os testes e continuando com a análise: comercial e sistema. Ainda não trabalhei separadamente como empresa e como analista de sistemas.No curso de minhas atividades profissionais em geral, incluindo entrevistas práticas e pessoais e, em particular, entrevistas com potenciais candidatos, fui gradualmente compreendendo as habilidades que o mercado espera do analista. Habr não via artigos novos sobre esse assunto há muito tempo, então decidi preparar o material pessoalmente.Para quem, na minha opinião, o artigo será útil:- Analistas de negócios / sistemas iniciantes;
- Analistas que querem continuar a bombear seus profissionais. Habilidades
- Talvez gerentes de recrutamento.
Devo dizer imediatamente que os pontos abaixo são minha visão subjetiva da especialização do analista , formada durante a prática. Se a sua empresa executa um scrum de pleno direito com um proprietário do produto a um metro de distância de você, com um designer e um arquiteto alocados para a equipe, algumas das opções acima podem não estar em demanda.No entanto, pelo menos todas essas habilidades não serão supérfluas e tornarão o analista ainda mais competente em suas perguntas. Obviamente, você precisa entender que eu não listei todas as habilidades do analista (as mesmas anotações, habilidades de negócios, sql e assim por diante).Analista de negócios
- Elimine requisitos ambíguos nos estágios iniciais
Ao conversar com um cliente comercial, você precisa estar ciente de que o idioma dele pode diferir significativamente do seu. Um requisito comercial pode ser expresso de forma que vários participantes no processo de aprovação tenham uma compreensão diferente do que esse requisito significa. A ambiguidade é gerada, o que é muito caro para a equipe nas fases posteriores do desenvolvimento.O problema é mais grave quando há vários clientes comerciais, cada um dos quais apresenta seus próprios requisitos. Por exemplo, ao integrar dois sistemas, cada um com seu próprio representante da empresa.Estudo de caso: um mês de desenvolvimento foi gasto na funcionalidade de transferir a lista de atividades do objeto nº 1 para o objeto nº 2. Na fase de teste de aceitação, descobriu-se que o cliente esperava uma funcionalidade completamente diferente - copiar, não transferir atividades. No processo de refazer a funcionalidade e detalhar a ambiguidade, a equipe de TI, em primeiro lugar, concordou com o cliente sobre o MVP e, em segundo lugar, a necessidade de trabalhar com a raiz do problema de negócios. Foi levantada a hipótese de que a funcionalidade de cópia em si é necessária apenas devido à funcionalidade insuficientemente implementada para carregar modelos de atividade.
- Não tenha medo de verificar com o cliente os requisitos do requisito
Encontrei casos em que resolvi quando a declaração de desenvolvimento foi descrita sem fixar uma meta de negócios: o que exatamente essa conclusão ajudaria os negócios? Que dor esse refinamento aliviará dos negócios?Freqüentemente, essas melhorias sem finalidade levavam a conseqüências desagradáveis já no estágio de teste, quando o desenvolvedor e o testador não entendiam por que projetamos essa funcionalidade. Pior ainda, o desenvolvedor e o testador não receberam respostas do analista e, se receberam, muitas vezes criaram o próprio analista: objetivos que o analista formou por conta própria.
Anote as metas junto com o cliente, para que absolutamente todos os participantes do processo, a qualquer momento, entendam por que estão realizando seu trabalho.- Exija a presença do cliente em reuniões de negócios
Na prática, deparei-me com diferentes clientes, alguns dos quais não estavam imediatamente prontos para convidar o analista para suas reuniões offline. O analista também terá que trabalhar com isso: concordar e mostrar o resultado de uma colaboração bem coordenada., — UX- — « », , . : , , windows-, . , .
Muitos analistas, inclusive eu, no processo de formulação de requisitos, confrontados com um prazo rígido, usaram a seguinte técnica: eles escreveram uma carta aos participantes do processo com um prazo pelo qual a carta deveria ser respondida e os requisitos / comentários acordados deveriam ser feitos. Caso contrário, os requisitos serão automaticamente reconhecidos conforme acordado.Como a prática demonstrou, não há nada de bom nessa abordagem. É claro que, trabalhando ao lado do fornecedor e tendo um acordo à mão, você precisa recorrer a esses métodos, mas ainda tenta evitar o consentimento tácito, tenta entender por que os participantes não querem lhe dar uma resposta agora e resolver o problema o mais rápido possível.É melhor documentar por escrito o fato de que a resposta não foi recebida de tais e de tais pessoas e você vê os seguintes riscos para o projeto. No entanto, o processo de trabalho não pode ficar parado; portanto, você é forçado a continuar seu trabalho analítico, enquanto os riscos definidos anteriormente devem ser claros para todos os participantes no processo.No processo de desenvolvimento da integração dos dois sistemas, fomos confrontados com a formação de requisitos pelo diretor, cobrindo as ações dos usuários nos dois sistemas, mas a falta de coordenação explícita desses mesmos requisitos por parte do chefe imediato da unidade, cujos funcionários eram usuários do sistema.
Como se viu mais tarde, o chefe da divisão não entendeu absolutamente por que todas essas melhorias e como elas ajudariam a otimizar os processos em sua área de responsabilidade.
Freqüentemente, os participantes do processo de aprovação simplesmente têm medo de assinar, porque não entendem completamente determinadas seções do processo comercial atualizado. Sua tarefa como analista de negócios é eliminar esse mal-entendido.
- Introduzir a área de assunto para desenvolvedores
Passe algumas horas, mas conte aos seus desenvolvedores sobre o cliente, processos de negócios atuais, problemas e planos de desenvolvimento. Como regra, desenvolvedores bem motivados não apenas realizam seu trabalho perfeitamente, entendendo para quem estão escrevendo o código, mas também fazem uma contribuição valiosa: oferecem otimização, soluções alternativas e estão mais dispostos a fazer perguntas esclarecedoras.Se necessário (e falta de scrum), atraia o cliente para essa reunião. Como regra, os representantes comerciais concordam de bom grado com essas iniciativas.- Ensine o cliente a responder à pergunta "O quê?" Em vez de formular requisitos no formato "Como"
O cliente não deve formular um requisito de negócios / usuário a partir da posição "Como": precisamos de um botão nesta tela para gerar um relatório; precisamos de um link para um sistema externo nesta seção; etc.No estágio da análise inicial do processo, antes do próprio design, o cliente não deve oferecer uma solução.Em vez disso, ensine o cliente a formular o problema, sua “dor”: precisamos gerar um relatório semanalmente, que é complementado manualmente por um funcionário e enviado à gerência; no processo de trabalho com o cliente, precisamos analisar informações adicionais e, como não estão disponíveis no sistema de CRM, precisamos abrir uma nova guia no navegador e fazer login no sistema adjacente.Tendo aprendido a dor do cliente, você, como especialista, pode oferecer opções para otimizar o processo e sua automação. Por exemplo, envie automaticamente o relatório gerado para o correio do funcionário, salve o funcionário do trabalho manual com o relatório em princípio, faça o download automático de dados de um sistema adjacente para o CRM e assim por diante.Em muitos casos, essa abordagem enfrentará a realidade: prazos e prioridades. Mas você, de qualquer forma, tentou honestamente.
- Certifique-se de dividir os usuários em classes
A aceitação de requisitos do usuário do sistema, sem falhas, leva em consideração sua função no processo de negócios. Na prática, muitas vezes há casos em que o chefe do departamento cria os requisitos para a função com a qual um funcionário comum trabalhará.Divida os usuários do sistema em funções e a funcionalidade aprimorada para uma função não "mancha" em outra função.Uma vez, na estrutura do sistema, implementamos a exibição de uma lista de transações com os clientes.
Supunha-se que tanto os gerentes quanto os funcionários comuns trabalhariam com a lista. Infelizmente, não conseguimos entender do cliente a necessidade de dividir a parte da interface do usuário da revisão em duas listas / telas: uma lista para o gerente para fins de análise e controle, a segunda lista para o funcionário com a finalidade de realizar atividades operacionais.
O resultado foi um certo monstro, que posteriormente teve que ser finalizado e finalizado.
Aplique as práticas recomendadas do UX: elabore caracteres - modelos de usuário. Convença o cliente a separar os requisitos para cada personagem.- Use ativamente o brainstorming analítico
É possível em conjunto com o segundo analista, é possível em conjunto com o designer de UX. No processo de assalto, tente duas funções: uma pessoa gera primeiro muitas idéias, viáveis e não muito, a segunda - critica essas idéias, decompõe-as, as escreve, as anota, pensa sobre elas; depois troque de função e faça o mesmo trabalho.Como mostra a prática, essa abordagem acelerará significativamente o processo de compilação de requisitos funcionais e melhorará sua qualidade. Mas há uma dificuldade em que ambos os especialistas devam estar no contexto da tarefa.- Se você está preso no Waterfall, não se desespere e vá para o Scrum
Em uma das empresas, literalmente em um ano, nossa equipe conseguiu transferir o processo de introdução de melhorias dos bem estabelecidos no nível de gerenciamento de gerentes para a Waterfall para algum tipo de Scrum. Sim, os prazos "claros" para o backlog altamente manchado, que o cliente exigia constantemente da equipe de TI, estavam recuando, enquanto a retórica foi gradualmente mitigada por lançamentos de duas semanas, soluções MVP e uma resposta rápida às mudanças.- Nunca demonize o cliente.
Sim, existem todos os tipos de clientes. Há quem esteja literalmente furioso. No entanto, um analista de negócios deve resolver esse problema por conta própria ou com o envolvimento de um gerente, e em nenhum caso ele deve "brigar da cabana" - na equipe.A equipe deve estar bem motivada para o trabalho, e o papel de um analista de negócios no processo de formação da motivação é uma das principais.A sério. Quando, no processo de comunicação com o cliente, ouço interrupções verbais ridículas do meu colega analítico, quando meu colega analítico interrompe o cliente sem ouvi-lo até o fim, quero enviá-lo para cursos de negociação ou ética elementar.Tente ouvir o interlocutor e ouvi-lo.- Livre-se das palavras parasitas
Tente evitar palavras parasitas e menos "moo" nas conversas. No começo, é difícil, mas, acredite, é duplamente difícil para o cliente ouvir um analista que não pode expressar seus pensamentos de maneira clara e clara. Um parasita pode ser afetado por um desenvolvedor, designer, testador, mas não por um analista de negócios que conecta a equipe de TI ao negócio. :
- " ".
- ", : ".
Análise do sistema
- Ao definir a tarefa para frente e para trás, tente descrever o diagrama de sequência
Ou, em russo, diagramas de sequência. Os diagramas serão úteis, mesmo não do ponto de vista do desenvolvimento, mas do ponto de vista da verificação de seus próprios requisitos. Muitas vezes, ao descrever um fluxo de mensagens, identifiquei “buracos” no meu próprio processo. Por exemplo, uma API irrelevante.Para "desenhar" rapidamente uma sequência de diagramas, use o plug-in PlantUML do Confluence. Pareceu-me que é mais rápido digitar código do que ajustar a localização de blocos e setas com canetas. Mas todos nesta parte têm sua própria experiência e suas próprias preferências.
Em termos de análise, o Swagger Editor permite que você feche seus próprios buracos nos requisitos. Em algum lugar eles perderam o atributo, em algum lugar eles esqueceram de criar uma tarefa no JIRA para finalizar o banco de dados. Não tente memorizar a sintaxe do Swagger, mas crie modelos para diferentes tipos de APIs (diretórios, filtros etc.) para simplificar sua vida no futuro.
- Use ativamente a ferramenta de desenvolvedor no navegador de destino para analisar solicitações e respostas do cliente do servidor
Em primeiro lugar, durante o processo de aceitação inicial, você pode verificar a API que você mesmo descreveu. Às vezes, é mais rápido verificar algumas das melhorias por solicitações de saída do que pela interface do usuário, a fim de entender a raiz do problema em um estágio inicial.Você, como analista, precisará de muito menos tempo para verificar a implementação do desenvolvedor: dados enviados, dados recebidos, o resultado na interface do usuário.
Em segundo lugar, você pode verificar a sequência de chamadas correta. Afinal, você mesmo o descreveu na estrutura do diagrama de seqüência.Essa abordagem permitiu à nossa equipe trazer melhorias bastante complicadas para os bailes como parte dos sprints sem demora. :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
além do que, além do mais
Você pode até gostar e querer evoluir para a análise de UX. De qualquer forma, estudar a literatura e as ferramentas de design relevantes se beneficiará pelo menos do ponto de vista de encontrar uma linguagem comum com o designer de UX da sua equipe.Muitas vezes, os requisitos que você, como analista, detalha e anota, serão posteriormente ajustados pelo designer. Afinal, você não está sozinho, de fato, está projetando a experiência do usuário.Para estar no mesmo comprimento de onda, pratique sua análise de UX. Por exemplo, no seu tempo livre no Sketch ou no Figma, de tempos em tempos, mostrando o resultado ao seu designer. Essa experiência de análise nunca será redundante. :
- " ".
- " ".
- ". ".
- ". ".
***Obrigado por ler o artigo! Ficaria agradecido, em primeiro lugar, pelo feedback. Em segundo lugar, para recomendações sobre literatura, fontes, melhores práticas, experiência pessoal e recomendações.