“... E o computador da loteria, que estragou tudo, é um de todos, em vez de se desculpar e dar desculpas, não apenas
admitiu o erro, mas até claramente orgulhoso dele.
"Eu sou feito", anunciou o Computador, "com tolerâncias mínimas". Fui projetado para executar operações complexas e precisas que não permitem mais do que
um erro por cinco bilhões de ações.
"Então o que?" O funcionário perguntou.
- A conclusão é clara: fui programado para um erro e fiz o que foi programado. Você deve se lembrar dos senhores que, para o carro
o erro é ético, sim, exclusivamente ético. Uma máquina ideal é impossível, e qualquer tentativa de criar essa máquina seria blasfêmia ... "
Robert Sheckley, "Coordenadas de Milagres" (1968)
Olá pessoal. Meu nome é Svyatoslav Shcherbatyuk, trabalho com o escritório de EPAM da Dnipro no cargo de Analista de Negócios Líder. Entrei nessa profissão há mais de quatro anos, na esfera do apoio jurídico a projetos de investimento, nos quais estou envolvido há dez anos.
Hoje, a questão do papel de um analista de negócios em um projeto é considerada em detalhes suficientes: sabe-se quais qualidades ele deve possuir, como é melhor desenvolver uma carreira, quais habilidades desenvolver. Basta usar uma pesquisa no Google para encontrar respostas adequadas.
Neste artigo, proponho considerar os erros mais comuns cometidos pela maioria dos analistas de negócios iniciantes. Talvez as coisas que serão discutidas pareçam óbvias para você, mas acredite: este artigo foi escrito com base no material coletado na prática e esses erros são encontrados regularmente no trabalho de analistas de negócios experientes.
Então, em ordem
1. idioma inglês Um dos principais e mais significativos é a atenção insuficiente ao nível do inglês. Nas entrevistas, é comum encontrar candidatos com um alto nível de conhecimento na área de estudo e uma impressionante experiência de trabalho, mas inglês fraco. Deve-se ter em mente que a maioria das empresas e projetos de TI está focada em clientes estrangeiros. A necessidade de inglês gratuito é determinada pelo local do analista de negócios na interseção do produto e pela equipe de engenharia (o papel e o local do VA na equipe Scrum é um tópico para uma guerra santa separada) e pelas tarefas que o enfrentam (comunicação eficaz entre essas equipes).
Um aspecto específico da questão do idioma é a gíria profissional, que é prestada atenção por empregadores, clientes e membros da equipe. A tarefa de um analista de negócios é estabelecer uma comunicação eficaz, e isso só é possível se você puder falar o mesmo idioma com todos os membros da equipe. Além disso, a grande maioria da literatura e treinamentos profissionais é apresentada em inglês. Em geral, sem o conhecimento de uma língua estrangeira, o desenvolvimento profissional completo é impossível.
2. Seguir cegamente a estrutura. Da questão da comunicação eficaz, segue outro erro bastante sério cometido pelos iniciantes - o seguimento dogmático das abordagens da estrutura escolhida. É necessário levar em conta que a TI é uma indústria em desenvolvimento dinâmico e o segredo do sucesso é a capacidade de se adaptar às circunstâncias em rápida mudança.
Você pode dizer à equipe o quanto quiser: “trabalhamos de acordo com o clássico Scrum / lean / Kanban”, mas se as tarefas e os processos não são claros para ela ou levam mais tempo e recursos do que poderiam se usassem uma abordagem diferente da do livro didático, então não faz sentido. . Nesse caso, não seria profissional dizer "essa é uma equipe ruim, eles não estão seguindo minha abordagem ideal da metodologia incorretamente". A tarefa de um analista de negócios é estudar diferentes abordagens e escolher a que será mais eficaz para uma equipe em particular em um projeto específico. Percebo que, durante a minha prática, não vi um único projeto com processos absolutamente "livro".
3. Ignorando a cultura e as políticas corporativas do cliente. Fechando o tópico da importância de uma comunicação eficaz para um analista de negócios, faz sentido mencionar a necessidade de considerar a cultura e as políticas corporativas do cliente ao planejar seu trabalho.
Apesar da certa obviedade desse problema e do fato de ele já ter rompido muitos, alguns analistas de negócios não prestam a devida atenção ao aspecto cultural da interação com o cliente. No entanto, esse ponto, combinado com a proficiência em inglês insuficiente, pode levar a situações em que um cliente pode perceber um analista de negócios como "rude, não educado". Isso afeta negativamente o trabalho da VA em um dos aspectos mais importantes - interação com as partes interessadas.
Portanto, por exemplo, é melhor não esquecer que os representantes das culturas asiáticas nem sempre podem dizer "não" diretamente e, ao trabalhar com americanos ou canadenses, você deve gastar 5 minutos conversando sobre os sucessos de sua equipe esportiva local. O fato de que muitas vezes representantes da cultura eslava da Europa Oriental por representantes da cultura ocidental são vistos como rudes, ouvi várias vezes (por exemplo, as pessoas usam o "você pode" em vez do "você pode" e se esquece de adicionar "por favor"). Em um dos projetos, o interessado perguntou diretamente por que a equipe o odiava tanto. No final, descobriu-se que a dificuldade está na diferença de culturas e na proficiência inadequada em inglês.
É importante entender que, para um analista de negócios, esse erro é inaceitável, porque a probabilidade de descobrir detalhes que o cliente não menciona diretamente por algum motivo depende da qualidade de sua comunicação com o cliente.
Para melhorar as habilidades de comunicação com o cliente:
- reabastecer o vocabulário com sutilezas e sinônimos;
- aprender condicionais;
- Trabalhar na pronúncia
- Aprenda as regras para usar os artigos "a" e "the".
Dicas mais práticas podem ser encontradas neste
artigo .
4. Ignorando alterações no domínio do cliente. No trabalho direto do projeto, um dos erros pode ser o término do estudo do domínio do domínio e as especificidades dos negócios do cliente. Há situações em que mesmo analistas de negócios experientes, que trabalham no projeto há muito tempo, não conseguem responder à pergunta de como exatamente o produto funciona em cenários bastante simples. A perda de interesse em tendências e tendências na área de domínio e uma interrupção no estudo dos negócios do cliente podem ser um truque no projeto, especialmente em áreas de negócios dinâmicas e em rápida mudança. Quase todos os especialistas mencionam a necessidade de estudar e mergulhar constantemente nos negócios do cliente quando se trata dos prós e contras da profissão de analista de negócios.
5. Falta de roteiro adequado. Uma das sérias dificuldades pode ser a ausência de documentos básicos, como visão e roteiro do projeto, com base nos planos de vendas do cliente. Talvez esse problema seja mais importante para grandes projetos e pertença à esfera de responsabilidades dos gerentes de produto, mas um analista de negócios, em qualquer caso, pode e deve iniciar e facilitar o processo de criação desses documentos. Se o VA planeja se desenvolver na direção do gerenciamento de produtos, vale a pena considerar.
Como exemplo da minha experiência pessoal, posso citar a situação em que o grupo VA desenvolveu um projeto de roteiro para sua consideração e aprovação pela equipe de gerenciamento de produtos. Especialistas, em particular, analisaram a funcionalidade das aplicações de concorrentes em potencial, os planos de vendas da empresa para o próximo ano, os planos de desenvolvimento de módulos relacionados e as histórias de pendências, que por algum motivo foram há muito rejeitadas pelos gerentes de produtos. Com base em toda essa pesquisa, nasceu o roteiro aprovado pelos clientes.
6. Não há plano de comunicação nem mapa de partes interessadas. Se você se aprofundar nos detalhes do trabalho de um analista de negócios, os erros dos iniciantes podem ser a falta de um plano de comunicação e uma matriz de partes interessadas. Você deve acostumar o cliente a realizar reuniões regulares e a si mesmo - com antecedência para preparar uma lista de questões para discussão. O cancelamento frequente de chamadas devido à falta de tópicos ou à falta de diálogo construtivo pode levar ao fato de que as partes interessadas simplesmente não chegam a uma reunião aparentemente planejada no momento mais crucial. Em um momento chave, ele pode não lhes parecer muito importante e urgente.
No planejamento da comunicação, é importante considerar não apenas a essência do problema, mas também como ele é formulado. Muitas vezes acontece que a resposta do cliente também depende da pergunta. Isso é extremamente importante quando um analista de negócios, como representante da equipe executora, precisa defender as decisões da equipe de engenharia, em particular durante o teste de aceitação do usuário e a entrega do trabalho ao cliente. Para construir uma matriz funcional de influência e interesse, podemos distribuir as partes interessadas em quatro quadrantes. Um bom exemplo prático pode ser encontrado neste artigo em
dou.ua.7. Os arranjos não são fixos. Na continuação, pode-se notar um erro como a ausência de notas de reunião compiladas a partir dos resultados da comunicação com as partes interessadas. Escrever notas de reunião é uma excelente forma de defesa de equipe, especialmente em projetos dinâmicos com grande mobilidade de gerentes.
Eu tive que lidar com situações em que, depois de um tempo, o cliente esqueceu os acordos alcançados ou, em conexão com a mudança da equipe do produto, tais acordos foram perdidos e tivemos que convencer o cliente de que certas alterações, por exemplo, no plano de liberação, não eram um erro de cálculo, mas um negócio real.
8. Falta de visibilidade. Vale a pena notar o formato das stand-ups diárias. É extremamente importante que o cliente tenha um nível de visibilidade suficiente, para saber onde e com que eficiência seu dinheiro foi gasto. Os analistas de negócios iniciantes (embora muitas vezes não sejam apenas eles) nem sempre conseguem explicar de forma sucinta e informativa ao cliente o trabalho realizado.
Lembre-se de que o cliente não vai gostar de saber que, por exemplo, durante toda a semana passada um dos membros da equipe estava no bloqueador e não fez nada. Eu conheci situações em que um cliente, com o argumento de que alguém estava bloqueado por alguma coisa, perguntou: “E o que você fez pessoalmente para superar o bloqueador / o que você fez enquanto estava bloqueado?”. Use o tempo em que estiver no bloqueador para melhorar os processos existentes no projeto. Felizmente, há muito trabalho desse tipo (especialmente em novos projetos). E quando você informar o cliente sobre as tarefas concluídas, prossiga com uma atitude proativa, pense em quais problemas de contador você pode antecipar.
9. Muito tempo é gasto em peças. Como um erro para iniciantes, pode-se enfatizar o foco excessivo nos detalhes do ticket e / ou nos meandros da implementação em sua descrição. Em projetos de longo prazo, é necessário levar em consideração que os detalhes da implementação podem mudar com a transição para uma nova tecnologia, enquanto os negócios do cliente permanecerão os mesmos. Critérios de aceitação preparados incorretamente com muitos detalhes de implementação (por exemplo, descrevendo métodos específicos ou APIs de solicitação / resposta) resultarão na necessidade de reescrever o backlog do produto.
Caso contrário, do ponto de vista do teste de regressão, o comportamento real do sistema será diferente dos requisitos existentes: é tecnicamente necessário iniciar um ticket de bug, a lista de pendências se torna "desatualizada" (ou seja, a descrição do estado do sistema se torna irrelevante). Ao mesmo tempo, não há motivos formais para reescrever os requisitos se os processos de negócios do cliente não foram alterados.
10. Você não tem uma visão para todo o projeto. Também um erro típico para projetos grandes e de longo prazo pode ser a falta de entendimento do “quadro geral”, vínculos com outros elementos do ecossistema e falta de “visão de helicóptero”.
Compreender as conexões do seu módulo com outras pessoas e saber como um sistema conectado se desenvolve permite que você desenvolva seu próprio produto de maneira correta e oportuna, evitando "despejar os detalhes da implementação". Além disso, dessa forma, você pode melhorar significativamente o nível de requisitos de gravação. Nesses casos, a elaboração de um
diagrama de contexto ajuda muito bem.
11. Você vai do oposto. Associado ao anterior, está o erro de escrever requisitos "do contrário" - que o sistema não deve fazer. O resultado é um acúmulo de requisitos, do qual fica claro o que o sistema não fará, mas não está claro o que fará. Isso pode ser devido ao fato de que o foco nos negócios do cliente foi perdido. Deve-se lembrar que o VA pensa em primeiro lugar diretamente sobre o que o sistema faz para atender às necessidades comerciais do cliente.
12. Avaliação incorreta. Mas o erro mais comum que nenhum analista de negócios iniciante pode evitar é subestimar ou superestimar o escopo das tarefas do projeto, bem como suas habilidades profissionais. Esses são dois extremos do mesmo fenômeno, que naturalmente surge da falta de experiência e compreensão do nível real das habilidades de uma pessoa.
Talvez o conselho mais eficaz seja não ter medo de nada, mas também não atestar em nome da equipe por algum tempo e trabalhar na frente do cliente / partes interessadas. É passo a passo realizar todas as ações esperadas de um novo projeto de análise de negócios. Não esqueça que o mesmo BABoK contém todo o plano de ação que você precisa. É normal que, no início do projeto, nada esteja claro.
Lembre-se de que a principal ferramenta de inteligência de negócios é a comunicação. Mesmo que você não saiba nada, identificar as partes interessadas é um bom começo para descobrir o objetivo do projeto, os negócios do cliente e elaborar o contexto inicial e diagramas de fluxo de trabalho que darão respostas a todas as perguntas do projeto. E colegas mais experientes que trabalham com esse cliente ou projeto por mais tempo o ajudarão a evitar a criação de expectativas incorretas do cliente a partir do produto.
13. Medo de erro. Ele paralisa e, em vez de começar a agir e ajustar o curso do projeto, o analista de negócios iniciante começa a "se preparar para a ação" por um longo tempo: escreva cuidadosamente cartas ao cliente, concentre-se em descrever cenários extremos, fluxos de trabalho improváveis que, nos primeiros estágios do projeto, geralmente negligenciado. Não há problema em cometer erros: o Agile e o Scrum tratam de cometer erros rapidamente e reagir a erros com a mesma rapidez.
Desejo a todos os recém-chegados ao VA que não tenham medo de erros e que corajosamente avancem. Boa sorte