Repensando o Papel do Analista de Negócios

Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido "pensá-lo"? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN's! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN's certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

Para começar, a forma muito legal que o Ambler apresenta o AN:

Na teoria, a idéia de ter AN's tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela "poluição informativa" - lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN's claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os "tech weenies" de TI e os "business morons" para os quais o sistema é construído.

Jóia né? Mas aí apareceram os "poréns". Comento abaixo cada um deles, na seqüência original:

1. AN's não apresentam as habilidades corretas
   pv: Natural, afinal ainda não temos um mínimo 'corpo de conhecimentos' consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
   AN's são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN's não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos "analistas-programadores". Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
   
   
2. AN's podem ter uma influência muito negativa no projeto
   pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN's que não funcionam como canais, mas sim como uma "parede" entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
   
   
3. AN's podem ficar desatualizados
   pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito... muito jeito.
   
   
4. AN's podem ser uma barreira para a comunicação
   pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a "tradução livre". Explico: o AN começa a contar apenas "boas notícias" para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
   
   
5. AN's podem reduzir a influência dos stakeholders
   pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de "firewall" para a equipe.
   
   
6. AN's analisam MUITO
   pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da "analysis-paralysis". Simplificando: se o AN for jogado em um processo baseado no ciclo "cascata" (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
   Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo [1]. Se ele resolver executar seu trampo "numa tacada só", só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
   * São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).
   
   
   
7. AN's reduzem o feedback
   pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers [2], um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
   
   
8. AN's reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
   pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue "tirar o pé da jaca". Ou, colocando d'uma forma menos agressiva: "não tira o boné de jeito nenhum". Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN's. E aprender muito com os bons AN's.
   

Notas:

1. Agility and Discipline made Easy: Practices from OpenUP and RUP
   Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
2. More About Software Requirements
   Karl Wiegers. Microsoft Press (2006).

Marcadores: analista_de_negócios, cursos_e_palestras, engenharia_de_requisitos, modelagem_de_negócios