Aqui está a única via pela qual os business analysts dão retorno do investimento aos clientes. Não é por produzirmos deliverables sofisticados que o cliente pode vender mas sim por facilitarmos o investimento nas coisas certas e a execução enxuta. Um só analista de negócio experiente é suficiente para garantir o alinhamento entre dezenas de pessoas numa iniciativa de grande âmbito.
Aqui está porque é que não vai ser a última grande fad tecnológica ou receita de gestão que vai resolver os problemas nos projetos.
Os business analysts são “só” os responsáveis primários pelos fatores que sempre estiveram no topo desta lista. Os gestores de projeto são accountable mas os BAs são responsible por esses fatores. Essa é a razão pela qual os business analysts são os profissionais melhor posicionados para gestão de projeto bem sucedida, de entre aqueles vindos de outras funções.
Desde a década de 90 que se sabe que isto é assim:
– Chaos Report (Standish Group, 1995)
– Canada Survey (KPMG, 1997)
– Return on Investment from More Effective Requirements Management (American Programmer magazine, 1997)
– Insights into Software Project Management (Proceedings of the Applications of Software Measurement Conference, 1999)
Todos estes estudos independentes concordaram com a tabela acima.
Aqueles que ainda hoje defendem que os BAs perdem o tempo deles em vão a documentar o negócio (e o mesmo vale para a documentação técnica pelos developers), demonstram não só não saber o que é gestão de projeto como também não saber o que é análise de negócio. Como é impossível criar documentação nova sem analisar o tema que é documentado, é impossível afirmar que gerir artefactos de âmbito de projeto não é fazer análise de negócio (já quanto à qualidade dessa documentação, isso é outro assunto). Quem assim pensa não se lembra que a única maneira de provar que sabia o que quer que fosse quando estava na sua faculdade de referência, era documentando o que sabia. Porque será?
Aqueles que acham que só precisam de user stories para fazer “agile” demonstram total desconhecimento de gestão agile porque não sabem que o agile que preconizam foi criado há 25 anos, e apenas para gerir uma equipa de developers (e uma apenas, não várias). Por isso é que não precisam de mais nada a não ser user stories. Mas acima do âmbito dessa equipa existem outras equipas com dependências entre si, existe uma gestão de produto e de portfolio, existe uma estratégia organizacional, que para servir de alguma coisa para as centenas e às vezes milhares de pessoas que trabalham nos value streams, necessita dos seus próprios artefactos.
Por isto é que no Disciplined Agile do PMI, a moeda de câmbio para a optimização do fluxo de valor à escala empresarial é um artefacto que documenta o âmbito que se quer atingir (e mais qualquer coisa).
Quem não sabe isto não sabe gestão. Não há outra forma de dizer o óbvio.
O leitor inteligente poderia perguntar: se os business analysts são os responsáveis primários pelos fatores que sempre estiveram no topo desta lista, então isso não quer dizer que os BAs são os principais responsáveis por projetos falhados? A resposta a isto é dupla: por um lado é verdade que há BAs que não sabem que têm esta responsabilidade ou que não são competentes, por outro e relacionado com isto temos o principal fator causal de projetos falhados, a causa destas causas — gestores de projeto que não fazem gestão de projeto. Mas fazem política, fazem o bidding do sponsor, posam para a fotografia… pelo menos até que o produto é entregue e as pessoas começam a utilizá-lo e mantê-lo.
Quando eu há uns anos fiz entrevistas de validação técnica de BAs, vários dos cenários que eu lhes colocava eram destinados a perceber como é que o BA via o seu papel como BA e o seu nível de responsabilidade. A maioria deles, quando questionado sobre conflitos entre o seu papel e diretivas do gestor de projeto, responderam que fariam o que o gestor de projeto lhes mandava fazer. Ora para isso os nossos clientes não precisam de gastar o dinheiro deles com BAs… e claro que depois vão gastar muito mais sem eles.
Compliments of the Author 