Há quem veja a análise de negócios como algo pequenininho – uma breve e chata etapa que antecede a construção de uma solução. Outros temem que ela esteja se tornando um monstro imenso. Todos nós – praticantes, evangelistas e rolando leros – temos culpa no cartório. Especialmente no caso do monstro. A área nunca precisou dos exageros que foram cometidos. Nunca pediu por adendos meio esotéricos ao seu corpo de conhecimentos. Que tal um retorno ao básico?

Um Método

Não importa se sua empresa usa Scrum, DevOps, Kanban, um combo de boas práticas ou o velho conhecido go horse. A Análise de Negócios merece um método pra chamar de seu. Um método com três características principais:

  • Flexibilidade: para lidar com problemas de qualquer natureza. Ênfase em qualquer natureza, por favor. Não servimos apenas TI.
  • Interoperabilidade: a Análise de Negócios não existe por si só. Seu método deve combinar muito bem com qualquer outro utilizado pela organização.
  • Integridade: para fazer o serviço completo. A correta delimitação da Análise de Negócios é um problema recorrente. Mais sobre isso abaixo.

Quatro Etapas

Não precisamos reinventar rodas. Quais áreas mais avançaram quando o assunto é método de trabalho? Tem essa que você pensou. E tem o Design Thinking. Área que lida com uma variedade de problemas equivalente ou maior do que a nossa. Seu losango duplo (Double Diamond) nos serve como uma luva ao propor quatro etapas bem nítidas:

  • Descoberta: Houston, temos um problema!
    E a correta identificação do problema faz parte do problema. Assim como a descoberta e mapeamento de todos os envolvidos.
  • Exploração: Cabral não fazia ideia do que tinha descoberto.
    É explorando – estudando o contexto e desenvolvendo requisitos – que ganhamos a exata noção do que precisa e do que pode ser feito.
  • Desenvolvimento: A construção, enfim!
    Selecionada a melhor alternativa de solução, é hora de desenvolvê-la. E o bom analista de negócios participa da construção, como não?
  • Entrega: Ou o fatídico encontro com o mundo real.
    O ambiente deve ser preparado. Os afetados devem ser amparados. E nós devemos estar prontos para as inevitáveis mudanças. Falemos, portanto, de entregas – no plural.

Oito Trabalhos

Há tempo é uma guerra delimitar com precisão as responsabilidades do analista de negócios. De onde se esperava assertividade veio muita ambiguidade. E a confusão proliferou. Gerenciamento de Projetos, Análise de Sistemas e, pasmem, até Suporte são áreas “invadidas” por analistas de negócios sem bússola. Por isso é tão importante fixar os trabalhos essenciais da Análise de Negócios. Eles são oito, dois em cada etapa descrita acima:

Os 8 Trabalhos do Analista de Negócios

  • Entender os Objetivos do Projeto
    Conhecer o problema a ser resolvido ou a oportunidade a ser aproveitada. Enfim, buscar a resposta para a primeira grande pergunta: Por que o projeto é necessário? Sem resposta não há projeto. Sobra um papo de malucos… projeto não.
  • Conhecer as Pessoas Envolvidas
    Quem será afetado por aquela mudança? Quem poderá influenciar o projeto? O mapeamento é simples. E é crucial para o sucesso do projeto. Porque, no final das contas, são as pessoas que vão aprová-lo ou não.
  • Estudar o Contexto
    Quais áreas do negócio serão afetadas? Quais processos estão envolvidos? Há necessidade de mudanças em políticas e regras? É neste trabalho que desenhamos os mapas que vão orientar todo o desenvolvimento do projeto.
  • Desenvolver Requisitos
    Mapas em mãos, hora de traçar o caminho. E é sempre bom lembrar: requisitos são condições para alcançar determinado fim. O fim foi demarcado lá em cima, no primeiro trabalho. Agora estudamos as condições para alcançá-lo. Repare que o analista DESENVOLVE requisitos. Não coleta, não levanta nem elicita (sic).
  • Avaliar Alternativas de Solução
    Porque todo problema tem mais de uma solução. Inclusive a não solução! O analista facilita o debate. Rico e importante que é, difícil explicar a razão de ser tão negligenciado.
  • Apoiar o Desenvolvimento
    E isso não significa empurrar uma montanha de entregáveis (sic) para o time de construção. Analistas de negócios participam ativamente do desenvolvimento, testando a solução e gerando, diariamente, informações para todo o time.
  • Preparar o Ambiente
    Ajudar as pessoas que terão seu cotidiano afetado por aquela mudança. As treinamos, sim. Mas, em alguns casos, é a preparação emocional a que mais importa. Não são poucos os projetos que pecam nesse ponto. E depois ajudam a propagar a tal “resistência às mudanças”.
  • Acompanhar o Uso da Solução
    Porque alteramos o contexto e, inevitavelmente, mudanças ocorrerão. Dizer que o cliente não sabe o que quer é apelar para uma desculpa simples e quase sempre equivocada. O bom analista entende que entre a(s) entrega(s) e o término oficial de um projeto há mais coisas do que informa aquele bonito gráfico Gantt.

Que fique claro: os trabalhos acima não são exclusivos do analista de negócios. A cada etapa ele está apoiando alguém, trabalhando com alguém. Sejam os clientes e usuários, sejam gerentes de projetos ou desenvolvedores, não importa. O que interessa aqui é a afirmação: o bom analista de negócios domina os trabalhos acima.

Depois, claro, ele vai acrescentar outras responsabilidades. Se trabalha em empresa de prestação de serviços, por exemplo, lhe interessa aprender a Elaborar Propostas. Se está em uma startup desenvolvendo o próximo killer app, vai elaborar uma etapa de exploração bem diferente – livre para criar. Enfim, uma vez dominado o essencial, o analista vai agregar novas atribuições, técnicas e ferramentas.

Infinitas Técnicas e Ferramentas

JTBD¹ (Jobs to be Done) ou Trabalhos a Executar. É a ferramenta-conceito que norteou o desenvolvimento da sugestão apresentada acima. O analista deve dominar o que precisa ser feito. Ou seja, ele compreende a motivação para aquele trabalho e a teoria que o embala. E é um atento colecionador de técnicas e ferramentas que o ajudam a executar seus trabalhos. A riqueza de seu cinto de utilidades reflete a complexidade do nosso tempo. Porque, como ensina a Lei de Ashby, “só a variedade absorve variedade”.

O que não significa entulhar o corpo de conhecimentos com modelos e modas que só criam confusão. Antes de qualquer coisa, façamos BEM o essencial.

Notas

  1. JTBD é uma ferramenta-conceito apresentada por Clayton M. Christensen para provocar inovações. Serve para desenhar produtos e serviços. E serve para desenhar funções e profissões. A ideia combina bem com o que foi apresentado no artigo O Futuro das Profissões.
  2. Project Infinity é o nome da imagem utilizada. Compartilhada por woodleywonderworks via flickr.