Você está na página 1de 36

BABoK: Uma Leitura Crítica | finito Page 1 of 36

finito

 Home
 Sobre
 Serviços
 Engenharia de Processos
 Administração de Ativos
 Suporte a Projetos
 Treinamento
 Formação de Analistas de Negócios
 O Jogo dos 7 Erros para Líderes de Projetos
 O Jogo dos 7 Erros para Analistas de Negócios
 Downloads
 Contato

BABoK: Uma Leitura Crítica


20/08/2009

in Análise de Negócios,Biblioteca

Antes de mais nada, um alerta: se seu interesse pelo BABoK limita-se à obtenção da certificação, então
este artigo não vai ajudá-lo muito. Poupe seu tempo. Eu sei, é chato, mas este artigo também merece um
prólogo-escudo: não tenho interesse nenhum em depreciar o IIBA (International Institute of Business
Analysis) ou seu principal produto, o BABoK® Guide (A Guide to the Business Analysis Body of
Knowledge). Há tempos apresento, aqui e ali, críticas àquela que deveria ser a principal referência para a
formação de analistas de negócios (AN’s), o BABoK. Meus objetivos sempre foram apenas dois: i)
ajudar os AN’s em seu processo de formação; e ii) contribuir para a evolução do BABoK. Ressalvas e
alertas devidamente colocados, vamos ao que interessa. Este artigo trata da última versão do BABoK, a
2.0, publicada em 2009.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 2 of 36

A Estrutura do BABoK
Alguma coisa muito estranha aconteceu entre a liberação da versão para revisão pública, em março/2008,
e a versão definitiva publicada agora. A estrutura básica do BABoK foi mantida, com suas 6 disciplinas
(KA’s ou Knowledge Areas), mas a ordem de apresentação sofreu consideráveis alterações. Se alguma
justificativa para tal foi apresentada, não percebi. O fato é que complicaram a leitura. Em meu
entendimento, desnecessariamente.

Na versão 2.0 liberada para revisão as duas primeiras disciplinas apresentadas eram aquelas de perfil mais
gerencial e tático: “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e
Comunicação dos Requisitos”. Era uma alteração necessária em relação à versão anterior, a 1.6, que
começava pela “Análise da Organização” (ou “Enterprise Analysis”). Necessária por agrupar, mesmo
que de maneira implícita, as disciplinas cuja aplicação se diferencia substancialmente das outras quatro.
(Mais sobre elas no decorrer do artigo).

A versão atual do BABoK inseriu “Elicitação” entre as duas, comprometendo uma certa lógica de leitura.
E a “Análise da Organização”, que um dia foi a primeira disciplina apresentada, agora aparece apenas no
quinto capítulo. Uma estrutura que parecia bem resolvida, como ilustra o gráfico abaixo, virou um
diagrama de difícil entendimento.

As disciplinas no BABoK 2 (public review)

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 3 of 36

A nova estrutura do BABoK

No primeiro diagrama percebemos claramente uma sequência lógica de 4 disciplinas, além da informação
de que outras duas guiam e/ou dão suporte à análise de negócios. O segundo desenho quebra essa lógica e
não faz nada mais do que confundir. Realmente é incompreensível a mudança.

Além disso, ainda sobre a estrutura do BABoK, é preciso dizer que a forma como as disciplinas são
apresentadas é boa. Destacam-se as entradas, tarefas e saídas principais de cada disciplina. Depois, para
cada tarefa, são descritos: entradas, elementos (que são específicos para cada tipo de tarefa), técnicas,
partes interessadas (stakeholders) e saídas. A sequência é lógica e didática, apesar dos deslizes que serão
discutidos abaixo.

Armadilhas
Saca aquele sujeito que, aéreo e desastrado, acaba caindo em armadilhas que ele próprio armou? Essa
imagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia do
IEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definição de
requisitos. Logo depois, ainda no capítulo 1, alerta que “é vital que o termo ‘requisito’ seja compreendido
no mais amplo sentido possível”. Ao tentar ilustrar o que seria essa amplitude toda, confundem: “em uma
iniciativa BPM, requisitos podem ser uma descrição dos processos de negócio atualmente em uso pela
organização”. Além de comprometer a definição do IEEE utilizada na página anterior, criam um tipo de
saco sem fundo onde tudo é ou pode ser um requisito. Armadilha armada no primeiro capítulo faz vítimas
no decorrer de todo o BoK. Quando apresentando a técnica de “Análise de Regras de Negócios”, por
exemplo, é dito que “regras de negócios devem ser separadas de outros requisitos…”. Ou seja, dão a
entender que regras de negócios também seriam um tipo de requisito.

Um analista de negócios deve aprender cedo que a distinção entre elementos do negócio (recursos,
processos, eventos e regras) e elementos da solução (requisitos) é crucial para o bom desenvolvimento de
seu trabalho. Ele sabe que há uma única interseção entre esses dois conjuntos e ela atende pelo nome de
Requisitos do Negócio. O BABoK os define corretamente, como “grandes objetivos, metas e
necessidades de um negócio”. De tão importantes, mereceram uma disciplina só para eles, a “Análise da
Organização”. O que torna ainda mais indecifrável a bagunça apontada no parágrafo anterior.

A segunda armadilha bastante notável no BABoK é a necessidade de manutenção de uma certa


“compatibilidade retroativa”. O BABoK tenta colocar e manter os pés em dois mundos muito distantes.
Ele os chama de “Plan-driven” e “Change-Driven” – nomenclatura criativa usada para diferenciar o
mundo clássico¹ de projetos daquele universo que surgiu após o big-bang do Manifesto Ágil. Se num
primeiro momento – no capítulo 2, que trata do “Planejamento e Monitoramento da Análise de Negócios”
– ele se mostra muito atencioso com o enfoque “change-driven”, na parte que seria mais cara e
necessária tal atenção evaporou. Em “Gerenciamento e Comunicação de Requisitos” (capítulo 4), por
exemplo, quase nada é falado sobre a forma como requisitos são gerenciados quando é adotado um
processo ágil qualquer (Scrum, XP etc).

O referido capítulo é repleto de procedimentos para revisão e aprovação de requisitos, baselines,


documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar de
clássico. Se mantido o mesmo balanceamento (de preocupações) apresentado no capítulo 2, aqui
deveríamos ver no mínimo uma vez a expressão “software rodando”, ou “solução rodando” ou algo do
tipo. Não vemos. O que permite dizer que o BABoK firma o pé mesmo é no mundo clássico, a exemplo
de seu primo não muito distante, o PMBoK. E por falar nele…

O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 4 of 36

ainda se mete a falar sobre elicitação de requisitos? Acho que nunca saberemos. Mas é importante
destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas,
“Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos
Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se
preocupar em fixar fronteiras. Criaram pelo menos duas ‘faixas de Gaza’ e o risco de conflito é alto.
Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa
“Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e muito menos
do gerente de projetos. Deveria ser só do arquiteto e ponto. Mas isso é tema para outra hora. Aliás,
atenção piratas! Vou lançar o FAS – Formação de Arquitetos de Soluções. Preparem suas copiadoras!
hehe..

Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crítica ao BABoK é o
fato dele ignorar por completo a disciplina conhecida como Modelagem de Negócios. O problema se
torna mais perceptível na versão 2.0. Porque de fato ele não ignora a necessidade da modelagem.
Sugestões para o uso de técnicas de modelagem aparecem a todo momento, em diversas disciplinas. Mas
elas surgem de forma tão solta e desestruturada que é difícil imaginar que sejam utilizadas em sua
plenitude. Pior: é difícil imaginar que gerem algum valor. Aos fatos.

Ainda na primeira disciplina, “Planejamento e Monitoramento da Análise de Negócios”², são


apresentadas como técnicas gerais a “Modelagem da Organização” e a “Modelagem de Processos”. Em
“Análise da Organização”, o 5º capítulo, são elencadas as técnicas “Benchmarking”, “Análise de Regras
de Negócios”, “Decomposição Funcional” e “Análise SWOT”. No sexto capítulo, “Análise de
Requisitos”, o assombro: além de diversas das técnicas acima, sugerem inclusive o uso de “Diagramas de
Fluxo de Dados” na tarefa que deveria ser apenas “Organizar Requisitos”. Dentre os elementos desta
tarefa aparece uma breve explanação sobre cada um dos 5 conceitos que, segundo o BoK, “garantem a
total cobertura do domínio do negócio”. Aliás, os 5 conceitos são: 1) Classes de Usuário, Perfis e Papéis;
2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.

Nada mais é necessário para confirmar que a Modelagem de Negócios é fundamental para o
entendimento de um negócio. Colocando de outra maneira: é fundamental para a Análise de Negócios. O
BABoK sabe disso. Acontece que, ao invés de tratá-a como uma disciplina – como um corpo – preferiu
esquartejá-la e distribuí-la em pedacinhos em diversas de suas KA’s. É grave quando percebemos que a
Análise de Requisitos, uma disciplina por si só complexa e crítica, vira uma espécie de monstro de
Frankestein no BABoK.

Essa armadilha se torna mais visível quando percebemos que em outros pontos do BoK é apresentada
como entrada para determinadas tarefas uma tal “Arquitetura Corporativa” (um documento que, segundo
o BABoK, “descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos de
negócio, sistemas, informação etc”). Esse input já existiria de alguma maneira na organização. Duas
coisinhas: 1) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou
deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é factível
supor que seu desenvolvimento e manutenção, mesmo que parcial, sejam atribuições dos analistas de
negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na Análise de
Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a compor uma
“Arquitetura Corporativa”. Vai entender…

Conclusão
No final das contas o grande problema com o BABoK é esse: entendê-lo. Se por um lado sua estrutura

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 5 of 36

geral é desenhada com esse fim, e é bem desenhada, por outro o conteúdo ainda apresenta inconsistências
demais. Pouco adianta o reuso de conhecimentos bem consolidados, como definições do IEEE e
diagramas UML, se eles são contraditos ou diluídos de tal forma que perdem seu sabor e valor.

Joe Gollner publicou em julho último um artigo chamado “O Curioso Caso da Análise de Negócios“.
Brinca com o título do filme estrelado por Brad Pitt, “O Curioso Caso de Benjamin Button”. Joe erra feio
ao dizer que não estaríamos prontos para definir um corpo de conhecimentos para a análise de negócios.
Tenho certeza de que já temos conhecimento e maturidade suficientes para delinear um BoK. Mas ele
acerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.

A necessidade de manutenção de uma “compatibilidade retroativa” é, sem sombra de dúvidas, a grande


culpada. Como justificar, em 2009, o uso de técnicas como a elaboração de DFD’s e diagramas de
contexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim o
BABoK só faz confirmar uma fama dos AN’s: seriam consumidores vorazes de papel. Não digo com isso
que ele deveria se ater aos princípios pregados no Manifesto Ágil. Afinal, a análise de negócios não se
limita a projetos de software. Mas é imperdoável que um BoK para análise de negócios se lembre de
DFD’s e ignore por completo balanced scorecards, mapas estratégicos, conceitos Lean etc etc etc.

Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obtenção da
certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar o
BABoK. Além de ter boa experiência prática. Mas o analista deve ter consciência de todas as armadilhas
e inconsistências que o BABoK apresenta em sua versão atual. Para não correr o risco de comprometer
seu trabalho e até sua carreira.

.:.

Nota aberta ao IIBA


A lei de imprensa morreu, o finito não é imprensa, mas ética e educação não precisam ser regidas por
leis. Caso o instituto julgue necessária uma resposta ao artigo acima, eu garanto o mesmo espaço e
mesmo destaque. E reafirmo: não tenho interesse nenhum em criticá-los por criticar. Muito pelo
contrário. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com um
BABoK forte e consistente. Todos sabemos que um debate franco e aberto é o melhor caminho para a
realização desses objetivos.

.:.

Serviço:

 O BABoK pode ser obtido diretamente no site do IIBA, em


http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge

Outras Notas:

1. Entenda como “Mundo Clássico de Projetos” aquele que brotou e cresceu no século passado.
Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ou
waterfall e que sustenta seus métodos e práticas em diferentes níveis de comando e controle. Não
há nada de pejorativo nessa definição. E não há nada de errado com esse modelo, desde que ele não
seja utilizado em projetos de software.
2. O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 6 of 36

suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework
do SEI?

Bookmark / compartilhe

The BABoK: Uma Leitura Crítica by finito, unless otherwise expressly stated, is licensed
under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.

Artigos relacionados:

1. BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios


2. O Analista de Negócios e o tal BABoK
3. O BABoK e a Disciplina “Enterprise Analysis”
4. O Mundo Ágil precisa de Analistas de Negócios?
5. O Giro em Falso das Rodas Reinventadas

Tagged as: Agile, Análise de Negócios, BABoK, Engenharia de Requisitos, Gerenciamento de Projetos,
IIBA, Iterativo e Incremental, Modelagem de Negócios, PMBoK, Scrum, UML

{ 43 comments… read them below or add one }

1 Bruno Torquato August 20, 2009 at 13:34

Achei honestas, construtivas e saudáveis tuas ideias. Claro que com as “ressalvas e alertas” fica
ainda melhor =D

2 admin August 20, 2009 at 15:13

Oi Bruno,

muito obrigado pelo retorno. Abraços,

Paulo

3 Constantino August 21, 2009 at 02:13

Pezado Paulo!

Ainda não li o BABoK, e não tenho um juízo de valor que me permita tecer comentário ou críticas
mais profunda e com a mesma autoridade como você o faz. Mas, fico com algum dos seus
comentários e sobre os quais faço as seguintes considerações.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 7 of 36

Você disse:

(1) ” … Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e
muito menos do gerente de projetos …”.

Obviamente que nenhum artefato pertence a nenhum dos atores do processo, exclusivamente. No
caso do Escopo, ele é parte integrante do ciclo de vida do projeto e pertence à área de
Gerenciamento de Integração do Projeto e deve ser continuamente acompanhado pelo gerente do
projeto que poderá até mesmo alterá-lo. Então, nesse sentido o Escopo é da alçada do Gerente de
Projetos sim, a quem cabe fazer o acompanhamento progressivo do projeto além de desenvolver a
declaração do escopo preliminar do projeto.

Veja o que diz o PMBOK/2004 que sob sua referência trabalham milhares de profissionais em todo
o mundo, inclusive no Pentágono e na NASA: “O gerente de projetos gerencia o escopo, o
cronograma, o custo e a qualidade dos produtos dos pacotes de trabalho …”.

Você disse:

(2) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou
deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é
factível supor que seu desenvolvimento e manutenção, mesmo que parcial, sejam atribuições dos
analistas de negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na
Análise de Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a
compor uma “Arquitetura Corporativa”. Vai entender …”.

Pois é, nesse caso do BABoK, não posso inferir, mas posso informar que no Processo Unificado da
Rational, conhecido como RUP, existe absoluta clareza sobre essa Arquitetura Corporativa,
compreendida analogamente pelo Documento Avaliação da Organização Alvo, descreve o status
atual da organização em que um futuro sistema deverá ser implantado. A descrição se dá em termos
de processos atuais, organogramas, ferramentas, competências de pessoas, atitudes de pessoas,
clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria. Isto é a Arquitetura
Corporativa com suas instâncias de negócio e os elementos que lhes são constituintes. O
responsável aqui é o Analista do Processo de Negócios.

Você disse:

(3) “… Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a
obtenção da certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA,
ele deve decorar o BABoK …”.

Aqui você falou bem, se o Profissional deseja a certificação deverá mesmo “decorar” o BABoK,
lamentavelmente.

A meu juízo, uma pessoa para atuar como Analista de Negócios, não o fará apenas pelo fato de ter
uma certificação – obtida pelo método “decoreba” – em baixo do braço, mas sim por ter as
habilidades requeridas, avaliadas por um processo de avaliação de competências que evidencie
aquelas áreas de desempenho que necessitem ser fortalecidas mediante uma “formação” e não
simplesmente uma certificação. A avaliação de competência para esses profissionais deveria
compreender um conjunto de competências básicas, específicas e inclusive de gestão, dado o
contexto atual das relações de trabalho, em que a maioria desses profissionais são consultores, não
raro autônomos .

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 8 of 36

Que contribuição plena poderá dar um Analista de Negócios, certificado por esse método, para
liderar uma equipe de desenvolvimento de um ERP, por exemplo? Acho que antes precisa ter um
desenho curricular que lhe dê capacidade para lidar com Gestão de Materiais, Compras, Contas a
Pagar, Contas a Receber, etc., sem falar no setor de governo, com suas Gestões Orçamentárias,
Licitações, Contratos, etc.

Importa, neste caso do Analista de Negócio, ter comunicação, ter conhecimento do domínio do
negócio, e o que é fundamental, ser um bom facilitador e agregador, para as suas relações
interpessoais com o cliente e o ambiente onde está inserido. Um analista de negócios deve estar
preparado para avaliar a situação da organização na qual o produto final do projeto será
implantado, entender as necessidades do cliente e do usuário, suas estratégias e metas, discutir e
facilitar um esforço da engenharia de negócios, se necessário, realizar uma análise de
custo/benefício de quaisquer mudanças sugeridas, e por ai vai.

Enfim, os analistas de negócios “certificados por esses meios”, no máximo só irão engrossar as
estatísticas do Gartner de projeto de TI mal sucedidos, sem falar no prejuízo do cliente.

Um grande e fraterno abraço

4 Constantino August 21, 2009 at 02:25

Retificando, este parágrafo fica melhor assim:


“A meu juízo, uma pessoa para atuar como Analista de Negócios, não o fará apenas pelo fato de ter
uma certificação – obtida pelo método “decoreba” – debaixo do braço, mas sim por ter as
habilidades requeridas, avaliadas por um processo de avaliação de competências que evidencie
aquelas áreas de desempenho que necessitem ser fortalecidas mediante uma “formação” e não
simplesmente uma certificação”.

Abração Paulo.

5 Marcelo Neves - IIBA-RJ August 21, 2009 at 22:08

Paulo,

Acei no mínimo interessante seus comentários. Realmente o BABOK tem vários problemas, mas
para falar a verdade o PMBOK até hoje possui problemas clássicos e outros que foram
“adicionados” na última versão. Por exemplo, no último PMBOK o processo de criação da
declaração de escopo preliminar simplesmente DESAPARECEU. Alguém sabe onde esse proceso
foi parar? Se alguém achou, por favor, me avise!!! hehehehe

Tanto o PMBOK quanto o BABOK possuem coisas boas e ruins, porém, acho também que o
profissional de Análise de Negócios NÃO deve se limitar apenas ao BABOK. Tem que ir além! E,
muito além!

Contudo, achei interessante quando você disse o seguinte:

“Há tempos apresento, aqui e ali, críticas àquela que deveria ser a principal referência para a

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 9 of 36

formação de analistas de negócios (AN’s), o BABoK.”

Você diz acima que o BABOK “deveria”, ou seja, ele não é sua principal referência para a
formação dos AN´s. Conte aí para nós: quais são as suas principais referência para a formação dos
AN´s? Vamos compartilhar suas fontes. Hehehehe

Vou citar apenas alguns livros interessantes que considero como referência em AN:

- The Business Analyst´s Handbook


- Software Requirements

e vários outros.

Abraço,

6 Constantino August 22, 2009 at 00:00

Marcelo Neves – IIBA-RJ, a propósito quando estará funcionando o IIAB-RJ. Já está? Por favor
me envie um e-mail sobre: jcmsilva04@gmail.com.

Também posso sugerir um livro muito interssante: Software Project Management, Royce, Walker –
Adisson Wesley, 2003. USA.

Abraços

7 Fabrício Laguna, CBAP, PMP August 22, 2009 at 10:40

Olá Paulo,

como ninguém do IIBA ainda o fez, sou obrigado a sair em defesa do BABOK 2.0.
Aproveitando o gancho do Marcelo, acredito que o BABOK 2.0 já seja sim a principal referência
para a formação de analistas de negócios (AN’s). Pelo menos, ao meu ver é um guia que contempla
os principais conceitos e técnicas utilizados nesta área e pode orientar bastante na formação de
profissionais indicando quais assuntos merecem um estudo detalhado, e que pode ser encontrado
em outras publicações.

Aumentando a lista indico mais alguns livros:


– Seven Steps to Mastering Business Analysis, Barbara A. Carkenord
– The Business Analyst as Strategist, Kathleen B. Hass
– UML for the IT Business Analyst, Howard Podeswa

Contudo nenhum destes, nem dos citados anteriormente abraçam o objetivo de compilar um Corpo
de Conhecimentos. E o BABOK encara a parada e nesta versão acredito que faz bem feito.
Vou comentar seu artigo por tópicos:

A ESTRUTURA DO BABOK

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 10 of 36

As principais inconsistências do PMBOK se dão por utilizar Processos para a Gestão de Projetos
sem definir uma Metodologia. Não dá para dissociar as coisas. E um dos principais objetivos de um
BOK é ser genérico e aplicável a qualquer metodologia. Entendo que o BABOK escapou desta
armadilha definindo as áreas de conhecimento em Tarefas em vez de Processos. Uma tarefa pode
ser executada em várias etapas de um processo e em diferentes metodologias. Por isso a figura das
áreas de conhecimento mudou. Para deixar claro que o guia não apresenta uma sequência de fases
de um processo, mas sim um conjunto de tarefas que oferecem produtos umas às outras.
Um exemplo: A elicitação não ocorre somente em uma etapa do processo. Ela é uma tarefa com
técnicas específicas que são executadas iterativamente em vários processos e que oferece
informações para todas as demais.

ARMADILHAS

A definição do IEEE não foi surrupiada, o BABOK fez a devida referência bibliográfica na nota de
rodapé.
Também não vejo uma inconsistência com esta definição quando o BABOK diz que requisitos
“podem ser uma descrição dos processos de negócio atualmente em uso pela organização” ele
justifica mais adiante com “requisitos que descrevem a situação atual da organização são, por
definição, soluções para um problema de negócio passado”. Descrevê-los antes de dar uma nova
solução pode ser interessante num modelo de análise As-Is e To-Be, além de serem extremamente
úteis num ambiente de gestão de requisitos com rastreabilidade entre diferentes tipos de requisitos.

COMPATIBILIDADE RETROATIVA

É importante considerar que o modelo Tradicional (Cascata) não está morto e nem vai morrer.
Ainda é provavelmente o mais utilizado nas organizações e o mais adequado para um grande
número de projetos e por isso não poderia ficar fora do BoK.
Na minha opinião, achei genial a distinção que o BABOK fez em modelos orientados ao
Planejamento (“Plan-driven”) e orientados a Mudança (“Change-Driven” ). Em vez de defender
uma ou outra abordagem, o BABOK apresenta considerações sobre cada uma delas, o que ajuda a
identificar em qual situação cada uma é melhor aplicada e o que a sua adoção impacta nas tarefas
da análise de negócios. Uma grande ajuda para quem deseja entender estas diferenças.

ESCOPO

O PMBOK faz uma distinção clara entre escopo do produto e escopo do projeto. O primeiro trata
dos requisitos e o segundo do trabalho que deve ser executado para criar os requisitos.
Entendo que o Escopo do Produto (da Solução) deva ser de responsabilidade do Analista de
Negócio e o Escopo do Projeto do Gerente de Projeto.
Claro que ambos são resultado de um trabalho de equipe e o principal responsável por toda a gestão
do Projeto é o Gerente do Projeto. Quando se faz esta distinção é apenas em relação a qual função
possui as competências necessárias para definir cada escopo.

MODELAGEM DE NEGÓCIOS

Aqui sou obrigado a concordar com você. A versão 1.6 do BABOK possuía a tarefa 2.2 “Criar e
Manter a Arquitetura de Negócios” que foi suprimida da versão 2.0. No apêndice do guia que
detalha essas mudanças é dito que “A Análise de Negócio em um nível mais amplamente
corporativo e estratégico será direcionado em uma extensão de área de aplicação separada.”
Não sei ao certo o que isso quer dizer, mas entendi algo do tipo: “Aguarde novidades para a versão
3″ ou então “Faremos um guia diferente para o Analista de Negócios Estratégico e assim podemos

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 11 of 36

lançar mais uma Certificação para aumentar a nossa gama de produtos”.


Não sei qual é a estratégia do IIBA mas me cheira a uma distinção semelhante a do PMI do
Gerenciamento de Projetos e o Gerenciamento de Programas.
A Modelagem de Negócios deve mesmo ser feita por um esforço de Análise de Negócios e deixá-la
de fora do guia foi realmente um passo para trás.

CONCLUSÃO

Discordo de sua posição de que o BABOK nasceu velho e que técnicas que não fazem parte das
preferidas pelos analistas ágeis deveriam estar fora do guia. São ainda extremamente úteis e devem
fazer parte do canivete suíço de ferramentas dominadas por um bom analista. O importante é saber
seus prós e contras para decidir quando e para que utilizá-las. Salientando ainda que o guia foca na
análise de negócios para um universo de soluções mais amplo do que apenas o desenvolvimento de
software.

Concordo com você de que o debate é produtivo e de que as críticas são um bom modo de evoluir.

8 José Constantino August 22, 2009 at 12:16

Bom, para minha sorte, tudo que foi falado aqui até agora, está amplamente contemplado no RUP,
“since” 1999.

Então temos o nosso RUPBOK. hehehehehe. RUP vai mais longe, ele sugere uma “formação” e
não uma certificação, com base em um desenho curricular, para o que chama de maneira
completiva, de Analista de Processos de Negócios, acertadamente, porque nem sempre você analisa
o negócio, mas os processos do negócios, em suas partes. Um absurdo você ler nas ofertas dos
cursos de Analistas de Negócios, que não há pré-requisitos para fazer o curso. Mas… vá lá que
seja!

Uma pessoa que quer atuar como um Analista do Processo de Negócios deve ser um bom
facilitador e ter excelentes habilidades de comunicação e ser holístico.
Ter conhecimento do domínio do negócio é fundamental para aqueles que desempenham este
papel.
Um analista do processo de negócios deve estar preparado para:
Avaliar a situação da organização-alvo na qual o produto final do projeto será implantado, entender
as necessidades do cliente e do usuário, suas estratégias e metas. (Aqui é que está a parede onde a
maioria bate e cai, pois aqui a tecnologia não é a ênfase).
Facilitar a modelagem da organização-alvo, discutir e facilitar um esforço da engenharia de
negócios, se necessário, realizar uma análise de custo/benefício de quaisquer mudanças sugeridas
na organização-alvo. (Também aqui objetiva avaliar até por questão ética se a organização
realmente precisa da solução sistematizada, o que é muito raro alguém dar o aconselhamento de
não fazer).
Analisar e auxiliar aqueles que comercializam e vendem o produto final do projeto.

Abraços para todos!

9 Leandro Mendonça August 23, 2009 at 14:34

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 12 of 36

Paulo,

Parabéns pelo artigo e principalmente pela coragem em escrevê-lo. Textos como esse são como
estacas fixadas por verdadeiros desbravadores para auxiliar alpinistas iniciantes como eu.

Você sabe que vai tomar cacetada de todo lado, né? Mas, como diz o chavão: “faz parte”…

Agora, vamos aos comentários:

1 – Concordo com a sua crítica à estrutura do BABOK. Mas aqui proponho uma reflexão: seria
possível estabelecer uma estrutura única para um “corpo de conhecimento” com uma proposta tão
ampla, uma vez que se recomendam diferentes abordagens para diferentes contextos?
Para esse problema, enxergo duas possibilidades:

a) Desistirmos dos BOKs e passarmos a adotar apenas publicações mais “especializadas” (menos
generalistas)

b) Os BOKs assumirem que esse tipo de estruturação (sequencia lógica) é impossível. Nessa caso,
todos poderiam começar com uma disciplina do tipo: “Estruturando o seu corpo de conhecimento”.
Nesse capítulo eles poderiam apresentar alguns “exemplos de receitas” (estruturas) que levam os
“ingredientes” (KA, processos, tarefas, etc.), fechando com um “Como montar a sua própria
receita”.

c) …ops, eram 3 possibilidades… Escritores independentes poderiam criar os seus próprios


“roteiros de viagem” pelo BABOK. (olha aqui uma sugestão de apêndice para o seu livro!).

2 – Sobre a forma como o BABOK define requisitos, concordo com ele e discordo de você.
Conceitualmente, tudo pode ser interpretado como requisito. Se você deseja classificar os seus
requisitos em “de negócio”, “de usuário”, “funcional”, “não funcional”, “de arquitetura”, “de
usabilidade”, “bonito”, “feio”, “cheiroso”, tudo bem, cada um sabe o que faz com os seus
requisitos. Para mim, um requisito é um problema que deve ser resolvido e quando isso acontece
ele passa a ser um “requisito atendido”. Os critérios de classificação de requisitos ainda são muito
subjetivos. Prefiro definir isso com a equipe de acordo com a necessidade do projeto ao invés de
adotar um padrão de mercado, até porque acho que esse padrão não existe. Já cansei de ver
discussões (estúpidas) do tipo: “isso é um requisito de negócio”… “não, isso é um requisito de
usuário”… “não, isso é uma regra de negócio”… “é caso de uso”… “sei não, isso parece mais uma
tarefa, no máximo uma atividade”… “e qual é a diferença entre tarefa e atividade”… “ah,
depende”…

3 – Sobre “Arquitetura Corporativa”, concordo plenamente. Todo mundo diz que existe, mas
ninguém nunca viu.

Abraços,

Leandro Mendonça

10 admin August 24, 2009 at 11:40

Olá,

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 13 of 36

Como, por motivo de força maior (15º FAN em Sampa), deixei acumular alguns comentários,
tentarei respondê-los numa tacada só. Ou seja, a resposta será longa!

===

Prezado Constantino,

(1) Pois é, o PMBoK diz que o escopo é do gerente de projetos. E sim, várias organizações e
empresas o utilizam como base para o gerenciamento de projetos. O questionamento que faço, não
é de hoje, é sobre a eficácia de uma disciplina que deve ser genérica o suficiente para acomodar
projetos de plataformas de petróleo e projetos de lojas virtuais, com toda a infinita gama de tipos de
projetos que existe entre esses dois exemplos.

Uma indústria que cito com mais frequência para ilustrar minha sugestão é a de cinema: lá existem
o diretor (o arquiteto – o criativo) e o produtor (o gerente do projeto – o administrador). O escopo é
do diretor. Quando não é, o filme geralmente fracassa!

(2) Você já viu essa ‘Arquitetura Corporativa’ proposta no RUP? Já viu uma sendo elaborada e
entregue? E como um Analista de *Processos* cuida das outras três partes fundamentais
(Objetivos, Estrutura e Regras) de um negócio? Se ele não cuida delas, como a ‘Arquitetura
Corporativa’ é completa? Perdão querido Constantino, mas sigo pagando para ver a cabeça desse
bacalhau.

(3) Eu disse no texto que, além da ‘decoreba’, o analista deve comprovar experiência. Aliás, o
IIBA exige a comprovação dessa experiência. E ela deve contemplar os aspectos muito bem
apresentados por ti.

===

Olá Marcelo Naves,

O fato do PMBoK apresentar sérios problemas não isenta o BABoK dos seus. E todo mundo
deveria estar ciente de que um BoK, qualquer BoK, não encerra assunto nenhum. Minha
preocupação específica com o BABoK é que suas ‘armadilhas’ podem tornar o “ir além” uma
viagem bastante acidentada.

Vou dar outro exemplo, que ignorei no artigo. Ainda na introdução, o BABoK lista uma série de
áreas não cobertas por ele que um AN deveria estudar. Estão lá: BI, SOA, CMMI, Gerenciamento
de Projetos, ITIL, Arquitetura Corporativa (Zachman Framework e TOGAF), Engenharia de
Software (particularmente Engenharia de Requisitos) etc.

Nada de contabilidade, matemática financeira, administração, marketing… Sinceramente,


considero essas disciplinas tão ou mais importantes do que *todas* listadas por ele. “É o Negócio,
Beócio!” – é meu grito. Nossas equipes já têm gente demais preocupadas com ITIL, BI, SOA…

Em algum lugar já falei que consultei centenas de livros e artigos no desenvolvimento de meu
trabalho. Acho que aqui não é o local mais indicado para essa lista. Mas não vou esconder minhas
fontes não. Em breve as divulgo em um local mais indicado, ok?

===

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 14 of 36

Olá Fabrício Laguna,

Reforçando o que eu disse para o Marcelo, o BABoK é uma referência muito perigosa – porque em
sua versão atual é inconsistente e incompleta, como ilustro em meu artigo. Ao contrário de ti, não
acho que ele contemple “os principais conceitos e técnicas utilizados nesta área”. A quarta
armadilha citada no artigo, e que mereceu sua concordância, é uma prova disso.

Antes de responder os demais pontos destacados por ti, um alerta: considero o livro do Howard
Podeswa, que você listou, um perigo. Aquela UML sugerida por ele (que é a mesma do RUP e do
Scott Ambler), não contempla todas as necessidades que temos quando de fato *modelamos um
negócio*.

A Estrutura do BABoK

Eu disse lá no artigo, a estrutura é boa. Mas a sequência de apresentação das disciplinas estava
melhor resolvida na versão disponibilizada para revisão pública no ano passado. Acho que os dois
diagramas que utilizei falam por si. É uma questão matemática: se o maior número de entradas de
uma disciplina tem origem em um mesmo lugar, logicamente esse lugar deve ter sido apresentado
antes da disciplina em questão. Exemplificando: 3 das 6 entradas da disciplina “Elicitação” são
geradas pela “Análise da Organização”. “Elicitação” é o capítulo 3, e “Análise..” é o capítulo 5. Me
perdoe, mas tá errado! Atente para o fato de que apenas 2 das 7 entradas de “Análise..” terem
origem em “Elicitação”. Como eu disse, é uma questão matemática. Que em sua simplicidade,
facilitaria a leitura do BABoK.

Armadilhas

Mil perdões. Uso o termo “surrupiar” a todo momento, inclusive para indicar citações que faço. Eu
não quis dizer que o IIBA utilizou indevidamente as definições do IEEE. Mas fui infeliz na
redação.

Mas sua afirmação, junto com o comentário do Leandro, me deixam preocupado. A descrição de
um processo de negócio *não* pode ser considerada um requisito ou um conjunto deles.

Muito do que encontro por aí, em empresas e turmas abertas, é uma imensa dificuldade em
entender e diferenciar requisitos. Essa colocação de que “tudo é ou pode ser requisito” não
contribuirá em nada para um melhor entendimento.

Karl Wiegers, em livro citado pelo Marcelo, surrupia (com créditos) a definição que Ian
Sommerville e Pete Sawyer publicaram em “Requirements Engineering” (Wiley, 1997). Requisitos
podem ser:

. Uma funcionalidade específica;


. Uma propriedade do sistema;
. Uma restrição específica (do sistema);
. Uma restrição ao desenvolvimento (do sistema).

A lista acima já representa responsabilidade demais para uma palavrinha (requisito) só. Não
precisamos de mais complicações. E o BABoK confunde sim, como mostrei. E confundir regras de
negócios com requisitos é armadilha das mais perigosas. Afinal, regras são mais voláteis que
requisitos e merecem tratamento muito especial.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 15 of 36

Compatibilidade Retroativa

Eu não disse que o BABoK não deveria contemplar o modelo clássico de projetos (ou cascata).
Apenas alerto que nos momentos em que uma boa apresentação do “change-driven” seria mais
cara (Gestão de Requisitos e Escopo, por exemplo), ele é ignorado ou tratado com uma enorme
displicência. Assim, a boa idéia da apresentação e distinção dos dois mundos vai por água abaixo.

Escopo

Já reforcei minha opinião, no início deste comentário. É muito dono pra pouca coisa. Sigo
apostando no modelo Toyota, com um Engenheiro-Chefe (arquiteto) tendo a palavra final sobre o
escopo (que na minha opinião, é um só! Sua divisão só faz confundir e criar ‘faixas de Gaza’.).

Modelagem de Negócios

Considerar a modelagem de negócios uma disciplina ou tarefa de finalidade exclusivamente


estratégica seria um equívoco ainda mais comprometedor. Torço para que o IIBA não cometa
tamanha bobagem. Modelamos um negócio para entendê-lo. E todo projeto demanda tarefas para
que tal entendimento aconteça. Portanto, a modelagem é, antes de estratégica, operacional.

Conclusão

Perdão meu caro Fabrício, mas DFD’s e afins são velhos sim. E isso não tem nada a ver com ser ou
não simpático ao Manifesto Ágil. E uma publicação de 2009, que queira falar para Analistas de
Negócios e ignore BSC’s, Mapas Estratégicos, System Maps, PUCS e uma cacetada de outras
técnicas e ferramentas – que são modernas mas que também já estão bem consolidadas – é um
documento que nasce sem noção de seu tempo. O BABoK Guide 2.0, infelizmente, nasceu velho.

Mas, tenho certeza, nossos papos aqui podem contribuir para que as próximas versões sigam os
passos de Benjamin Button. Pelo menos no que se refere ao rejuvenescimento.

===

Enfim, meu caro Leandro, chego aos seus comentários.

Meu caro, como já dizia o saudoso Vicente Matheus, “quem sai na chuva é pra se queimar!” )

(1) Como eu disse em outro fórum (no BPM-Forum), acredito sim na possibilidade de um BoK
para a Análise de Negócios. O BABoK, apesar de suas armadilhas e inconsistências, é uma prova
disso. Considero graves seus enganos mas reforço: a estrutura é boa. O que não significa que ela
não pode ser melhorada. Pode. E muito!

As alternativas ‘b’ e ‘c’ sugeridas por ti são legais, mas não sei até que ponto seriam aceitas.
Infelizmente os BoK’s (todos eles) costumam nascer com jeitinho de ‘imexíveis’ – de intocáveis.
Porque muita coisa depende deles (provas de certificação e, em última instância, o faturamento de
quem os cria).

Particularmente, eu gostaria muito de ver BoK’s (principalmente o PM e o BA) verticalizados –


por tipo de projeto ou organização. Mas sei que partirei desta para uma melhor sem testemunhar a
realização desse requisito tão bobo e óbvio.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 16 of 36

(2) E por falar em requisitos, espero ter respondido esse ponto lá no trecho onde converso com o
Fabrício.

===

Ufa! Resta agradecer a quem chegou até aqui. E, principalmente, ao Constantino, Marcelo,
Fabrício e Leandro, pelo papo tão bom e rico: Muito obrigado!

Abraços,

Paulo Vasconcellos

11 Marcelo Neves August 24, 2009 at 14:52

Oi Paulo,

A discussão tá ficando boa … tá ficando quente! hehehehe

Quando eu disse que o PMBOK apresenta sérios problemas sem dúvida que isso não isenta o
BABOK dos seus. Mas, digo que faz parte do amadurecimento natural dos BOK´s todo esse
processo de discussão e aprimoramente. E, na verdade o BABOK já nasceu muito mas maduro que
o PMBOK. Basta comparar a versão 1.0 do PMBOK com a versão inicial do BABOK.

De qualquer forma, também concordo contigo que o Analista de Negócios tem que se aprofundar
em muitos outros assuntos. Mas, sinceramente você acha que um BOK conseguiria compilar todos
os assuntos necessários para a formação de um AN? Eu considero os BOK´s um pontapé inicial e
NÃO uma compilação completa e totalmente abrangente de um assunto específico.

Discordo plenamente de você com relação a sua afirmação de que o “BABOK é uma referência
perigosa”, pois é claro que o BABOK está incompleto. Eu diria que NUNCA teremos um BABOK
completo. Atualmente NÃO temos um PMBOK completo. A completude dos BOK´s é uma
verdadeira falácia. Mas, sem dúvida que é imperdoável o IIBA não abranger modelagem de
negócios entre outros.

Enfim, a estrada a frente é longa. Os desafios são enormes. E, é isso que me instiga a continuar.

Até a próxima!

12 José Constantino August 24, 2009 at 15:40

Marcelo!

Voce disse: “… Mas, sinceramente você acha que um BOK conseguiria compilar todos os assuntos
necessários para a formação de um AN? …”

Acho que não precisaria ser “todos os assuntos necessários”, mas os indispensáveis, por meio de
uma matriz curricular mínima para a profissão de AN, com o propósito de identificar aquelas áreas

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 17 of 36

de desempenho que necessitam ser fortalecidas mediante uma “formação” para alcançar o nível de
competência requerido.

Se eu decorar todo o BABoK, e passar na prova de certificação, o que eu adquiro, uma certificação
ou uma formação?

O que vai definir meu desempenho para modelar um negócio, sugerir melhorias para uma empresa,
é minha certificação decorada, ou o meu arcabouço de conhecimentos, tecnológicos inclusive?

Como eu vou coordenar uma equipe de modelagem, ter as habilidades de comunicação e


organização necessárias, definir e delimitar a organização alvo, aplicar as técnicas de brainstorms
necessários, ouvir equipe e cliente, discutir e facilitar um esforço para engenharia de negócios, etc?

Ou Analista de negócios não precisa conhecer nada disso?

Creio que o AN, deve ir muito além de uma ferramenta CASE, muito além de identificar e modelar
casos de uso de negócios e os respectivos diagramas.

Um grande e fraterno abraço!

13 admin August 24, 2009 at 16:13

Olá Marcelo,

eu diria que o BABoK aprendeu com vários erros do PMBoK e nasceu sim melhor que ele. Mas
esse é o preço do ineditismo, certo? O problema com o PMBoK é que ele agora parece
amarradíssimo em sua estrutura original. Um dia tentaram um ‘workaround’ e inventaram a 9ª
disciplina, “Integração”. Mais recentemente, na edição de junho/julho da MundoPM, Paulo Yazigi
Sabbag sugere em um artigo que “Gestão do Conhecimento” passe a integrar o PMBoK, na forma
de 4 processos de gestão. Definitivamente, IMHO, não é por aí. Mas voltemos ao BoK em questão,
o BA.

Você pergunta se eu acho “que um BOK conseguiria compilar todos os assuntos necessários para a
formação de um AN?”. Não! E não foi isso que eu quis dizer quando listei aquelas disciplinas.
Aquilo lá é só um comentário sobre a lista de “estudos complementares” sugeridos no BABoK. Eu
disse que a lista deles é “TI” demais e “negócio” de menos, só isso.

Um BoK, como bem disse o Constantino, deve se concentrar no essencial. E o essencial, em minha
opinião, é formado por duas grandes disciplinas: Modelagem de Negócios (que usamos para
*entender o negócio*) e Engenharia de Requisitos (que utilizamos para *entender os usuários*).
Nem mais, nem menos.

O BABoK, em sua versão atual, é perigoso não só por estar incompleto, mas por apresentar
conceitos de maneira não muito acertada. Sobre requisitos, por exemplo. Daí o perigo.

Mesmo entendendo que o BABoK não é para “iniciantes”, julgo seus equívocos bastante perigosos.
Não só para os estudos visando certificações, mas principalmente para o dia-a-dia de um analista.

Marcelo e Constantino, muito obrigado pela participação.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 18 of 36

Forte abraço,

Paulo Vasconcellos

14 José Constantino August 24, 2009 at 16:37

Só uma adendo a mais, para não ser chato!

Atualmente estou no final de uma empreitada de modelar o negócio para a construção de um ERP
para uma empresa de serviços, com mais de 4.000 funcionários e duas filiais no exterior. Está
sendo entregue as últimas iterações.

Então, foi necessário primeiro montar, sugerir, testar uma arquitetura, vender idéia toda em BPM e
devidamente prototipada para o conselho aprovar, de modo que, o que fosse desenvolvido refletisse
“ipsis literis’ o fluxo de trabalho da empresa e mais uma infindável regras de negócios, que
envolvem suas atividades fim, gestão de compras, gestão de materiais, logística de distribuição,
fornecedores, contas a pagar, tesouraria, faturamento, legislação tributária, etc.

Se eu chegasse lá apenas com as minhas certificações, RUP, Pós -graduação, ITIL, etc., tinha caído
do cavalo, pois trata-se de uma empresa familiar que queria apenas melhorias, não mudanças
radicais nos seus processos. Todos os produtos de prateleira que foram oferecidos e mostrados, não
foram aceitos, não por serem ruins, ou caros, mas por não ter aderência, não refletir o negócio deles
e de extensa adaptabilidade.

Enfim, acho que essas coisas contam e não devem ser desprezadas para considerar um Analista de
Negócios.

15 Fabrício Laguna, CBAP, PMP August 24, 2009 at 17:39

Constantino,

para obter a certificação CBAP do IIBA você deve comprovar 7500 horas em atividades
relacionadas a análise de negócios e experiência em pelo menos 4 das 6 áreas de conhecimento
propostas pelo BABOK.
O isso indica é que sua experiência não é desprezada, mas exigida pelo processo de certificação do
IIBA. Além de poder comprovar em um exame que sabe escolher a melhor alternativa de como
aplicar os conhecimentos listados no BABOK em situações problema.
Boa sorte.
Inté

16 Marcelo Neves August 24, 2009 at 17:57

Constantino,

Concordo plenamente com você. O meu único porém é o seguinte: vamos deixar de usar o BABOK
apenas por que ele está incompleto? No meu caso não! Sem dúvida que o BABOK ainda tem que

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 19 of 36

“comer muito feijão”.

Sem dúvida que a certificação CBAP deve ser muito mais do que decoreba. Infelizmente o IIBA
ainda não acertou a mão no BABOK. Mas, acredito que chegará lá em breve!

Paulo,

Agora entendi o que você quis dizer com perigoso. Concordo em parte. Concordo quando você diz
que falta a modelagem que é fundamental. Não me pergunte o porquê deles não terem incluído,
mas é mais do que necessário. E, para quem é Analista de Negócios, concordo que ler o BABOK e
não encontrar esse assunto, fica no mínimo confuso.

17 José Constantino August 24, 2009 at 18:11

Fabrício Laguna, CBAP, PMP 24/08/2009 at 17:39

Valeu Fabríco!

Muito grato meu amigo, agradeço e estou mais reflexivo.

Um abração

18 José Constantino August 24, 2009 at 18:12

Fabrício Laguna, CBAP, PMP 24/08/2009 at 17:39

Valeu Fabrício!

Muito grato meu amigo, agradeço e estou mais reflexivo.

Um abração

19 Leandro Mendonça August 25, 2009 at 15:42

Olá Paulo,

Sigo discordando no seguinte ponto:

“… confundir regras de negócios com requisitos é armadilha das mais perigosas. Afinal, regras são
mais voláteis que requisitos e merecem tratamento muito especial.”

Dúvida: mais voláteis quanto? 50%… 20%… 200%… 1,6 anos?

Acho essa confusão de definições (atividades, processos, casos de uso, regras, objetivos, metas…)
tão natural que prefiro tratá-la em primeiro plano do que supor que existam convenções de mercado

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 20 of 36

suficientemente claras sobre os termos.

Gosto da forma como o BABOK apresenta suas definições… algo do tipo: “para os propósitos
desta publicação foi adotado o seguinte esquema de classificação…”

Pronto, tudo muito simples e sem pretensão. Acho que assim é que conseguimos fugir dessa
armadilha.

Abs.,

Leandro.

20 admin August 25, 2009 at 17:08

Ah meu caro Leandro,

Se esse tipo de estatística existisse o mundo seria um lugar bem melhor para se viver

Mas as regras são mais voláteis sim. Uma que determine um desconto em uma transação comercial,
por exemplo, pode mudar várias vezes em um período relativamente curto, de 2 ou 3 meses. Mas o
requisito “Calcular Desconto” permanece o mesmo – por décadas ou séculos! Em seguradoras as
regras que determinam os cálculos mudam mensalmente. Mas os requisitos são os mesmos há anos.
Olhe ao seu redor: garanto que você encontrará diversos exemplos, mais ilustrativos que os meus.

Quando começamos a achar que determinado tipo de “confusão é natural” é porque estamos prestes
a esconder o problema debaixo do tapete. Existem sim convenções suficientemente claras que nos
permitem diferenciar todos os elementos de um negócio e da “voz do usuário”. Para ficar em duas
referências:

.Software Requirements – Karl Wiegers (MS Press, 1999).


.Requirements-Led Project Management – Suzanne Robertson e James Robertson (Addison-
Wesley, 2005).

Respeito sua opinião sobre o BABoK. Na minha, ele foi escorregadio e preguiçoso.

Obrigado por mais uma participação nesta thread.

Abraços,

Paulo

21 Leandro Mendonça August 25, 2009 at 18:25

Oi Paulo,

Seus exemplos são perfeitos, mas considero que essa classificação já faça parte do processo de
tratamento dos requisitos. Mais um pouquinho e um AN desavisado cai na armadilha de definir a

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 21 of 36

solução, mandando Regra de Negócio pra turma do Banco de Dados e os requisitos pra turma do
código. Prefiro evitar essa discriminação inicial.

O fato é que, como você colocou, é difícil encontrar consenso na diferenciação de requisitos.
Talvez seja porque isso é subjetivo mesmo.

No momento não me vem nenhum exemplo a mente, mas sei que dependendo do contexto, do
escopo ou da arquitetura da solução um requisito pode ser tratado como regra de negócio e vice-
versa. Logo, acho que essa questão da classificação deve ser tratada explicitamente pelo AN no
início do projeto, do modo como o BABOK tratou. Algo do tipo: “… para este projeto adotaremos
a seguinte classificação de requisitos…”.

Isso é particularmente útil para projetos mais amplos do que os de desenvolvimento de software. E
como o BABOK trata a Análise de Negócio de uma forma mais ampla, faz todo o sentido eles
abstrairem o conceito de requisitos.

Sei que essa amplitude da abordagem do IIBA é uma das causas-raiz das suas críticas, mas isso é
fato e acho que você deveria considerar esse fator na sua análise.

Não vou me estender (ainda mais) para não desviar a discussão, mas espero ter colaborado com
alguns argumentos para aquele artigo sobre regras de negócio que você prometeu ; ).

Abraços,

Leandro

22 admin August 25, 2009 at 21:50

Opa… peraí Leandro,

Requisito é requisito, independente do tipo de projeto. Aliás, quando eles ‘nascem’, nem sabemos
ainda qual tipo de solução melhor os atenderá. Se em algum momento passei a impressão de que
meu entendimento aplica-se exclusivamente a projetos de software, me perdoe. Como eu disse,
requisito é requisito. Ponto.

Acho importante que o analista estruture a voz do usuário exatamente porque ele é o mais
preparado para tal. Aliás, acho essa uma de suas principais atribuições.

Senão – e agora vou falar especificamente de software – vira o balaio de gato que vemos por tudo
quanto é canto: regras de negócio ‘cimentadas’ no meio do código, tornando sua manutenção mais
difícil e lenta e, principalmente, aumentando consideravelmente o custo de propriedade do sistema.

Insisto na diferenciação entre requisitos e regras porque a considero a mais básica e aquela que gera
retorno bastante perceptível. Mas lembro que o BABoK não peca só nesse quesito.

Cara, meu backlog de artigos tá tão grande que periga o prometido artigo demorar um pouco. Mas
sairá, eu prometo.

Abraços,

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 22 of 36

Paulo

23 Gisele August 26, 2009 at 10:08

Olá!

Concordo com você Paulo. Essas definições genéricas de requisitos dificultam até mesmo a
elaboração de uma documentação bem estruturada e organizada.
De certa forma as regras de negócios separadas despertam a atenção da equipe de desenvolvimento
para implementção das mesmas de forma isolada a fim de facilitar a manutenção, inclusive
pensando em reaproveitamento de código.
Com relação aos diagramas do processo atual da organização, também não considero como
requisitos, afinal estamos entendendo o processo atual do negócio justamente para assegurar que
aquilo que o usuário requisitar não esteja em desencontro com os objetivos e as soluções propostas
para os problemas encontrados.

[]s
Gisele

24 admin August 26, 2009 at 10:26

Olá Gisele,

Puxa, muito obrigado pelo comentário. Já começava a ficar com medo de estar sozinho com essa
preocupação. Valeu!

Abraços,

Paulo

25 Fabrício Laguna, CBAP, PMP August 26, 2009 at 12:01

Entendo que existe a diferenciação entre cada termo e sua importância.


É importante diferenciar as coisas para não confundir.

Mas também entendo a proposta do BABOK e acho interessante ter um nome genérico para
chamar todas estas coisas. O BABOK decidiu chamá-las genericamente de requisitos. E cada tipo
específico de requisito com um termo mais completo como requisito de negócio ou requisito
funcional por exemplo.

Nas tarefas propostas pelo BABOK onde o termo requisito aparece estão embutidos ali as regras de
negócio, processos, casos de uso, protótipos além dos requisitos de negócio, requisitos de
stakeholder, requisitos funcionais, requisitos não funcionais e requisitos de implementação.

Veja pelas tarefas como faz sentido pensar em requisitos de uma forma mais ampla:
– Manter a rastreabilidade de requisitos

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 23 of 36

– Manter requisitos para reuso


– Preparar o pacote de requisitos
– Comunicar requisitos
– Organizar requisitos
– Especificar e Modelar requisitos
– Verificar requisitos
– Validar requisitos

Todas estas tarefas se aplicam ao termo genérico e não a um tipo de requisito específico. Assim
elimina-se a necessidade de criar tarefas específicas para cada tipo de requisito como Verificar
Regras de Negócio ou Manter Processos de Negócio para Reúso ou Validar Glossário de Termos.

Pode ser, Paulo, que o termo requisito sendo usado desta forma genérica cause confusão e que
talvez outro termo genérico fosse mais apropriado, como “Ativo de informação”. Exemplo:
“Organizar Ativos de Informação”. Mas o termo mais utilizado no mercado é mesmo requisito.

Por favor considere este ponto de vista antes de responder.


Talvez você possa sugerir um termo mais adequado e quem sabe o IIBA o utiliza na versão 3 do
BABOK.

Inté

Fabrício

26 admin August 26, 2009 at 13:09

Olá Fabrício,

Há 10 anos, em “Software Requirements”, Karl Wiegers sugeriu o termo “Voz do Usuário”. O


utilizo com certa frequência, mas não sei se é realmente o melhor.

Requisitos se relacionam direta ou indiretamente com diversos outros elementos, inclusive outros
requisitos. Por isso, não vejo problemas em seu uso genérico, como bem ilustrado por ti.

Os pontos que critico no BABoK são outros: aquelas confusões com definições de processos de
negócio e regras de negócio. Nada justifica a confusão.

Muito obrigado pela valiosa colaboração.

Inté,

Paulo

27 José Constantino August 26, 2009 at 13:44

Nossa! Show isso aqui, não é mesmo?

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 24 of 36

Estou adorando participar desta que pode ser assim, uma “comunidade de prática virtual”, se me
permitem. Huuummm os puristas de KM não vão gostar disso. Mas só essa vez, tá?

Bom… Quanto a essa questão de requisitos, creio que ela só é persistente, se desprezados o
arcabouço metodológico necessário a todo projeto de qualidade, tanto do projeto em si, quanto do
produto do projeto, pois creio que a metodologia, na medida em que ela propõe uma norma, é que
vai alinhar no âmbito do projeto e dos envolvidos o que é considerado requisito no domínio do meu
negócio e dos problemas que estou a resolver.

Creio que o importante é não abrir mão das chamadas “Diretrizes”, dos “Casos de
Desenvolvimento” e também do “Glossário” porque ai você não só alinha os principais itens do seu
gerenciamento, como também pode dar a definição de requisitos no domínio do projeto, sem
prejuízo do que se denomina “as melhores práticas”.

O RUP é um processo, cuja meta é garantir a produção de software de alta qualidade, de forma que
estas possam ser ADAPTADAS para uma grande variedade de projetos e de organizações, diz que:
“Requisito é uma condição ou uma capacidade com a qual o sistema deve estar de acordo”.

Abraços para todos!

28 admin August 26, 2009 at 13:57

Pois é, Constantino,

Também estou gostando muito do bate-papo. Só confesso um certo frio na barriga toda vez que
vejo a sugestão de que a definição do que é um requisito seria feita por projeto. Sinceramente,
gostaria de ver uma boa justificativa para isso.

Obrigado pela participação.

Abraços,

Paulo

29 Fabrício Laguna, CBAP, PMP August 26, 2009 at 14:32

Paulo e Constantino,

entendo que a definição não muda por projeto. A definição do que é um requisito funcional, por
exemplo, é sempre a mesma.
O que muda por projeto (ou por metodologia) é se vamos usar este tipo de requisito em nossa
especificação, se ele deve ser descrito como texto puro, casos de uso, matriz CRUD… se deve estar
rastreado às regras de negócio e aos modelos de dados… se vão ser subdivididos em sub-categorias
etc.

30 Leandro Mendonça August 26, 2009 at 20:16

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 25 of 36

Oi Paulo,

Como o artigo sobre regras de negócio não tem previsão, vou abusar dessa thread.

Sabemos que requisito representa um desejo ou necessidade do cliente. Isso é claro e não precisa
ser definido para cada projeto. Agora “o como” esses desejos/necessidades serão organizados, isso
sim precisa ser definido. E essa organização pode variar de acordo com a amplitude do projeto, do
vocabulário (linguagem) da equipe envolvida (não só de TI), dos possíveis desdobramentos, etc.
Enfim, depende de “n” fatores.

Pergunto: como você classificaria requisitos do tipo “Treinar equipe”, “Reformar escritório”,
“Modelar processo”, “Divulgar produto”, etc? Sei que você dificilmente se depararia com esse tipo
de requisito uma vez que o seu foco de trabalho é bem definido, mas do ponto de vista de uma
organização que quer ter uma visão mais integrada dos seus problemas essa distinção não faz tanta
diferença. Em outras palavras, estabelecer relações entre os diferentes requisitos é mais importante
do que classificá-los.

Agora se podemos ter um único “arcabouço metodológico” (gostei dessa) para tratar requisitos de
todos os tipos sem discriminação, como sugere o BABOK, ótimo! Estaremos no caminho certo
para o exercício de uma Análise de Negócio efetiva.

Sobre a relação regras de negócio x requisitos, no meu entendimento uma regra de negócio é um
tipo de requisito. Um tipo de requisito cuja principal caracterísitca é a maior volatilidade e que
provavelmente será tratado pelo sistema de uma forma menos engessada, como você falou. Mas só
chegarei a essa conclusão após analisar os requisitos, o que já faz parte do processo de Análise de
Negócio. Antes disso ele é só um requisito mesmo, desses bem genéricos e escorregadios como
define o IIBA.

Abraços,

Leandro.

31 admin August 26, 2009 at 21:08

Leandro,

Eu sei que não vou te convencer. E nem era esta a minha intenção. Seguirei achando o BABoK
deveras (Cony já proibiu essa palavra) perigoso, escorregadio e preguiçoso. Já citei fontes que
trataram melhor a distinção entre requisitos, regras etc.

Concordo contigo e com o Fabrício: cada organização ou projeto definirá um método mais
adequado para o desenvolvimento de requisitos. Mas acho que não era isso que estava em questão.

Abraços e obrigado pela participação.

Paulo

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 26 of 36

32 Leandro Mendonça August 26, 2009 at 22:15

Paulo,

Agradeço a atenção dispesada aos comentários. Sinto que estamos gerando conteúdo bastante
relevante para discussões futuras, neste e em outros fóruns.

Apesar dos diversos comentários, não acho que desviamos a questão central do artigo que é a
crítica (construtiva) ao BABOK. Independente de estar cero ou errado, o fato é que o BABOK trata
os requisitos dessa forma mais genérica e esse entendimento é fundamental para aqueles que vão
realizar a leitura.

Para as demais questões apontadas por ti, reforço o meu apoio.

Abraços,

Leandro Mendonça.

33 admin August 27, 2009 at 09:32

Leandro,

Não há o que agradecer. Estou aqui é pra isso mesmo. E não tenho dúvidas de que a conversa aqui
registrada é muito rica. Como eu disse lá no nosso grupo de discussão, os comentários
multiplicaram por 30 e tantos o valor do artigo.

Entendo e respeito seu ponto, que é o mesmo defendido pelo Fabrício, sobre a forma como o
BABoK tratou essa questão (requisitos). “Certo ou errado”, como você bem colocou, o fato é que
vira uma definição formal – que deve ser estudada por todos que queiram se aprofundar em análise
de negócios, particularmente aqueles que visam a certificação.

Acho que nossa conversa, no mínimo, deixará as partes interessadas com uma “pulga atrás da
orelha”. E isso é bom.

Abraços e muito obrigado pela oportunidade.

Paulo

34 Marcel Fleming August 29, 2009 at 12:35

Ah… as faixas de Gaza dos BoKs (ainda tem o SwEBoK, mas este pelo menos é razoável e cita o
PMBoK em uma de suas KAs). Naquele dia do FAN eu brinquei que não sabia se era AN ou GP…

Na verdade, os BoKs estão só refletindo a confusão do mercado. O que, se pensarmos no que deve
ser um BoK, em sua essência, talvez estejam corretos

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 27 of 36

Outro dia vi uma grande empresa, de quem se esperaria uma profissionalização maior, pedir um
“Analista de Projetos” que era 60% GP, 40% AN, 30% Gerente de Vendas e 20% Arquiteto… Não
enlouqueci não. Pelo que pediam, acho que o cara tinha que ser 1,5 FTE

E ainda outro dia, fique sabendo de um tal AgileUP, que define o papel de um “Agile Modeler”
que vai causar arrepios no Paulo, por quê mistura o papel do AN com o Arquiteto, e substitui as
disciplinas do RUP, Modelagem de Negócios, Requisitos e Análise e Design pela genérica
“Modelagem” (???). Obs.: Não estou julgando o mérito da proposta, apenas descrevendo.

Gostei da idéia do “arcabouço metodólogico”, but I wander se não devemos começar a pensar em
“Padrões de Processos”, sem a definição de papéis, mas de Competências, Habilidades e
Atitudes para os papéis em vez de papéis (roles) definidos de maneira “fundamentalista”.

Em tempo: acho que a idéia geral do PMBoK e a definição do que é atribuição do GP faz sentido,
se as empresas entendessem e injetassem na veia o que de fato o GP deve fazer: gerenciar. Mas
concordo que a inclusão do Coletar Requisitos no novo PMBoK tá meio difícil de engolir… fiquei
meio fora de contexto (ou estou com limitações mentais, o que não discarto).

Abraços.

35 Juliane Bentivoglio August 31, 2009 at 00:17

Olá todos!

Vale a pena combater a falta de tempo e a correria do trabalho para ler estas discussões. É
realmente enriquecedor.

Abraços,
Juliane

36 Suzandeise Thomé August 31, 2009 at 14:13

ESTRUTURA DO BABOK 2.0

Concordo com a sua avaliação da estrutura do BABOK 2.0 quando diz que a “forma como as
disciplinas são apresentadas é boa,” mas que o diagrama da interação entre as áreas de
conhecimento deixa a desejar. O diagrama atual é útil para entender como estão relacionadas as
entradas e saídas de cada conjunto de atividades. Mas ele não deveria ser o único diagrama, pois a
primeira impressão de quem o vê é de que ele é complicado demais. Seria mais didático introduzir
primeiramente um diagrama simplificado (mais parecido com o do DRAFT) para depois complicá-
lo com as setas que indicam todas as entradas e as saídas. O tanto de setas no diagrama atual
causou até essa nova ordenação dos capítulos que, como você colocou, não é intuitiva pra quem lê
o documento pela primeira vez. Vale a pena ressaltar que esse diagrama com todas as setas traz à
tona a natureza iterativa das atividades de análise de negócios, ponto com o qual concordo
plenamente.

AMBIGUIDADE NA DEFINIÇÃO DO TERMO “REQUISITOS”

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 28 of 36

O número de comentários neste thread discutindo a definição de “requisitos” é preocupante. Um


documento como o BABOK 2.0 não deveria dar margem a interpretações. (Aliás, comunicação
clara e livre de ambiguidade é uma habilidade crucial para analistas de negócios).

Admiro a sua maneira apurada e academicamente embasada de definir termos. Entendo a sua
crítica de inconsistência na definição do termo “requisitos”. Mas teremos que conversar sobre isso
por mais algumas horas (sem a cerveja e talvez com um flip-chart) para que eu possa chegar a uma
conclusão sobre esse assunto. Os pensamentos que me vêm à mente agora resumo aqui…

Análise de Negócios acontece quando temos um problema ou uma oportunidade e precisamos


encontrar uma solução. Esta solução tem que resolver o gap entre a capacidade atual da
organização (processos, sistemas ou produto/serviços atuais) e onde ela quer chegar. Uma coisa é
modelar o estado atual da organização (para entendê-la), outra coisa é descrever o ponto onde ela
quer chegar (os requisitos da solução). Este “ponto onde a organização quer chegar” inclui tudo o
que queremos manter da capacidade atual (inclusive processos e regras de negócios) + novos
processos/regras/funcionalidades/etc. Então os requisitos das novas capacidades se confundem com
os requisitos para se manter a capacidade atual… de qualquer forma são os “requisitos da solução”
e a meu ver incluem, sim, processos e regras de negócio.

Toda essa discussão tem que ser resolvida e documentada a ponto de não dar margem para
interpretações. Taí um desafio pro BABOK v3.

COMPATIBILIDADE RETROATIVA

O que você chama de “compatibilidade retroativa” é, na minha opinião, consequência da


experiência daqueles que se juntaram para escrever o BABOK 2.0. A maioria dos envolvidos
provavelmente veio de TI, portanto o texto que por um lado defende que Análise de Negócios
abrange atividades muito além dos projetos de sistemas de software, cita muitos exemplos de TI e
não deixa clara a aplicabilidade a outras áreas. Na minha opinião este é um dos maiores problemas
desta versão do BABOK. É genérico demais em alguns aspectos (vide a confusão que gerou na
definição de “requisitos”) e específico demais em outros (nos exemplos de TI).

Mas tudo depende da perspectiva de quem lê. Alias, quase todo o texto do BABOK tem que ser
interpretado baseado na experiência de quem lê. Este não é um texto para iniciantes. (E acredito ser
impossível passar na prova de certificação CBAP decorando o BABOK 2.0 sem ter a experiência
requerida…)

Concordo com a diferenciação que o BABOK 2.0 faz entre “change-driven” e “plan-driven”. A
deferenciação entre essas duas abordagens realmente é clara e consistente no capítulo 2
(“Planejamento e Monitoramento de Análise de Negócios”), como você indicou. Sua crítica ao
capítulo 4 (“Gerenciamento e Comunicação de Requisitos”) faz sentido. Dada a natureza da
abordagem “plan-driven”, é bem mais fácil entender os exemplos citados no capítulo 4 tendo em
mente vivências dos projetos “cascata.” Mas ele também se aplica aos projetos que utilizam um
processo ágil, ou a abordagem “change-driven”. Mesmo quando se utiliza um processo ágil, é
necessário gerenciar requisitos, comunicá-los e aprová-los. A maneira como se faz isso é que deve
ser diferente, menos demorada ou burocrática. Será que incluir exemplos disso no capítulo 4 é o
melhor caminho? Se formos nessa direção deveríamos incluir exemplos de projetos que envolvem
melhorias de processo, definição de novos produtos, e outros mais…

BABOK 2.0 vs. PMBOK

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 29 of 36

Eu te provoquei a ler o BABOK 2.0 e o seu artigo me fez estudar a quarta versão do PMBOK. Nos
últimos dez dias despendi muito tempo analisando os textos, trocando emails, enfim… Não vou
nem começar a destrinchar esta aparente falta de alinhamento entre o IIBA e o PMI. Daria um
livro. Se eu conseguir respostas aos meus questionamentos, voltarei a esse tópico.

MODELAGEM DE NEGÓCIOS

Esta disciplina realmente foi dividida em vários capítulos. Não tenho opinião formada sobre como
seria melhor abordar isso dentro do BABOK. Isso e a maneira como foi tratada a Arquitetura
Corporativa estão entre os meus questionamentos também…

ESCOPO

A pergunta não deveria ser “quem é dono do escopo”, e sim quais são as responsabilidades de cada
profissional em relação ao escopo. Ao gerente do projeto cabe gerenciar o escopo, isto é, não
deixar que as atividades do projeto envolvam um escopo maior do que o combinado inicialmente
para que não aconteçam impactos negativos no prazo nem no orçamento (o gerente de projetos só
consegue fazer isso direito se ele também executar as atividades de análise de negócios ou se tiver
no seu time um analista de negócios.) Ao analista de negócios cabe elicitar requisitos respeitando a
delimitação de escopo definida no início do projeto (aqui assumo que isso foi feito direito no início
do projeto, é claro.) Durante as atividades de elicitação de requisitos, é muito comum surgirem
assuntos fora de escopo. Cabe ao analista de negócios não permitir que os “stakeholders” saiam
pela tangente e incluam pedidos fora do escopo.

Escopo deveria ser do arquiteto? Você quis dizer o escopo da solução? Fiquei curiosa…

37 admin August 31, 2009 at 15:09

Olá Suzandeise,

Tardou um pouquinho, mas eu sabia que não falharia, né? Antes de mais nada, muito obrigado pela
consideração e pela participação neste debate.

Eu seria redundante demais se reafirmasse minhas opiniões. Acho que elas ficaram claras no artigo
e nos comentários que publiquei. Então, me limitarei aos fatos novos:

Requisitos
A mudança de uma regra de negócio é um requisito. A regra não. A mudança de um processo
também é um requisito. O processo não.

Essa distinção, que parece bobinha, faz toda a diferença. Onde? Na qualidade das informações do
projeto – na qualidade da documentação!

Suzanne Robertson, co-autora do “Volere” (http://www.volere.co.uk/), é uma das experts


consultadas pelo IIBA durante a elaboração do BABoK. Se tivessem “surrupiado” um pouquinho
deste modelo, a definição de requisitos não estaria tão vaga. O “Volere” está bem documentado no
apêndice A de “Requirements-Led Project Management”, livro que ela escreveu com James
Robertson (Addison-Wesley, 2005). Não concordo 100% com ele, mas é bem melhor que o
BABoK no assunto em questão.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 30 of 36

Compatibilidade Retroativa

Eu entendo as origens, prezada Suzandeise. Basta ver a lista de experts consultados para se ter uma
ideia: Scott Ambler, Meilir Page-Jones… O que não entendo e o critério de seleção de algumas
práticas sugeridas.

Me causa espanto (e agora me baseio também na resposta oficial publicada em


http://www.pfvasconcellos.eti.br/blog/2009/08/31/a-resposta-do-iiba/) saber que muita gente,
mundo afora, ainda utiliza DFD’s e diagramas de contexto… Aliás, se a gente pudesse ver os
resultados da pesquisa… Será que o IIBA pode fornecê-la?

Escopo

Sim, o Escopo da Solução deveria ter um único dono: o Arquiteto. O profissional que guia o
desenho e a construção da solução – que orienta o trabalho de toda a equipe técnica. E que cuida da
manutenção da Integridade Arquitetônica da solução.

Fred Brooks, no longínquo 1975 (em “O Mítico Homem-Mês”, Elsevier-Campus, 2009), já dizia:

“Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos!”

O arquiteto não se envolve com questões administrativas do projeto. O gerente do projeto não se
envolve com o desenho técnico e a implementação da solução. Simples assim: um pensador e um
executor.

Facilitamos a delimitação de fronteiras se eliminarmos algumas definições ambíguas, como


“escopo do projeto” e “escopo da solução”.

Escopo, segundo o Houaiss, é “1. ponto em que se mira; alvo 2. intenção; objetivo.” Para nós, esse
objetivo é o conjunto de requisitos que um projeto deve atender, certo? Então, IMHO, ele pertence
ao cara que desenhou a forma pela qual os requisitos serão atendidos.

Próximo debate sem cerveja? Ah…

Obrigado. Abraços,

Paulo

38 Suzandeise Thomé August 31, 2009 at 15:22

Oi Paulo.

A distinção que vc fez entre a regra vs. a mudança da regra ou o processo vs. a mudança do
processo faz total sentido.

Estou tentando conseguir liberação da pesquisa do ano passado… eu sabia que vc iria pedir. Não é
só vc que está espantado com o critério de seleção das técnicas…

Quanto à discussão sobre escopo, vai ter que ser ao vivo mesmo

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 31 of 36

-Suzandeise

39 admin August 31, 2009 at 15:28

Olá Suzandeise,

Ok: ao vivo, com cerveja e num local com uma bela chaminé que disperse meu fumacê!

Paulo

40 Leandro Mendonça September 1, 2009 at 10:27

Oi Paulo,

Não sei se entendi essa parte: “o Escopo da Solução deveria ter um único dono: o Arquiteto. ”

Esse “Escopo da Solução” seria o produto final do projeto, composto, por exemplo, pelo software
funcional, suas especificações e demais artefatos que se façam necessários. É esse “Escopo da
Solução” que pertence ao Arquiteto, certo? Nesse caso o conceito parece com o de “Escopo do
Produto” do PMBOK.

Quanto ao “Escopo do Projeto”, esse é de responsabilidade do Gerente de Projetos e englobaria as


demais disciplinas de gestão (riscos, aquisições, prazo, qualidade, integração, comunicação, etc.).

Penso que também exista um “Escopo do Problema” composto pelo conjunto de requisitos
(necessidades). Esse conceito se aproximaria mais do “Product Backlog” do SCRUM do que da
abordagem PMI para o gerenciamento de projetos. E o “dono” desse “Escopo do Problema” seria o
Analista de Negócio (ou o Product Owner) e não o Gerente de Projetos ou o Arquiteto.

Na verdade tratam-se de 3 perspectivas cheias de intersecções sobre o mesmo objeto, no caso o


projeto (problema + solução), mas a distinção me parece pertinente e necessária.

Pensei que você concordava com essas definições, mas fiquei confuso com seus últimos
comentários.

Abraços,

Leandro.

41 Leandro Mendonça September 1, 2009 at 10:50

Oi Suzandeise,

Primeiramente gostaria de parabenizá-lo pelo post “A Resposta do IIBA”. É bom saber que o
Instituto está realmente disposto ao diálogo aberto com a comunidade.

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 32 of 36

Sobre o seu comentário nesse artigo, mais precisamente na parte do Escopo, discordo do final:

“… Ao analista de negócios cabe elicitar requisitos respeitando a delimitação de escopo definida


no início do projeto (aqui assumo que isso foi feito direito no início do projeto, é claro.) Durante
as atividades de elicitação de requisitos, é muito comum surgirem assuntos fora de escopo. Cabe
ao analista de negócios não permitir que os “stakeholders” saiam pela tangente e incluam pedidos
fora do escopo.”

Na verdade, cabe ao AN gerenciar o escopo de modo que requisitos prioritários sejam tratados
como tal, independente do momento em que surgem. É claro que existem “n” restrições que
interferem nessa priorização, mas é justamente aí que entram o AN e o GP, na negociação dos
requisitos x restrições.

Abraços,

Leandro Mendonça

42 admin September 1, 2009 at 11:00

Oi Leandro,

Fiquei mesmo com medo de confundir quando publiquei meu comentário. Tentei simplificar a
coisa – e por isso não deveria ter falado em “Escopo da Solução”. Afinal, um pouco antes eu estava
falando em “Escopo” – que a gente deveria ver um único “Escopo”.

Mas talvez a palavra não seja adequada. “Escopo”, “Requisitos”… estamos repletos de palavras
que carregam mais responsabilidades do que deveriam. Eu sei que você não concorda, mas seguirei
defendendo uma simplificação – um uso mais racional e direto dessas palavrinhas.

Segundo o PMBoK o gerente de projetos tem 9 “áreas” para cuidar. Não acho correto chamar esse
conjunto de “escopo”. Até porque “Escopo” é uma delas. Exatamente aquela que, insisto, não
deveria pertencer ao gerente de projetos.

Um projeto é iniciado para dar origem a um produto, uma solução, certo? A coisa mais importante
de um projeto, independente do tipo ou natureza, é o seu produto. Concorda?

O que defendo, seguindo ensinamentos de Brooks e vários outros, além de minhas próprias
cicatrizes, é que o gerente de projeto cuide da parte administrativa (Gerencial!) do projeto: custos,
prazos, riscos, contratos… A parte criativa do projeto (o desenho da solução – algo que
equivocadamente chamarei novamente de “Escopo”) deve ser de outra pessoa. Deve ser de um
profissional que domine técnicas e tecnologias que serão utilizadas no desenvolvimento daquele
produto. Gosto de chamar esse cara de “Arquiteto”. Por razões óbvias.

Será que deixei a coisa mais clara agora? Você diz.

Obrigado. Abraços,

Paulo

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 33 of 36

43 Suzandeise Thomé September 1, 2009 at 11:09

Oi Leandro.

Muito bem lembrado! Por descuido, ignorei priorização nesse parágrafo que escrevi. Aí entra em
jogo justamente essa interação entre o AN e o GP, a estratégia da empresa, enfim… O assunto
“escopo” é tão extenso que discutir isso num thread é, na minha opinião, totalmente impraticável.
Por isso prefiro as discussões ao vivo

-Suzandeise

Leave a Comment

Name *

E-mail *

Website

Me envie novos comentários via email

Submit

Spam Protection by WP-SpamFree

{ 2 trackbacks }

 A Resposta do IIBA | finito


 O Mundo Mudou | finito

Additional comments powered by BackType

Previous post: Modelagem de Negócios: Os Diagramas

Next post: FAN @ Sampa – 16ª Edição

 Acompanhe & Participe

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 34 of 36

 Busca

To search, type and hit enter

 Categorias

Análise de Negócios
(88)
Arquitetura
(28)
Biblioteca
(60)
Cursos e Palestras
(78)
Engenharia de Software
(27)
Gerenciamento de Proj...
(55)
Gestão do Conhecimento
(18)
Outros Assuntos
(2)
Pessoas
(1)
 Mais Lidos

 Morte e Vida UML


 Como Priorizar Projetos, Influenciar Decisões e não Fazer (muitos) Inimigos
 Agile Product Management with Scrum
 Modelagem de Negócios: Os Diagramas
 Times
 Últimos Comentários

 Priorizar
admin Olá Danilo, A plena realização do grande objetivo da nossa empresa...
 Priorizar
Danilo Carlos Avante Paulo, Uma dúvida quanto a ordem de execução. Não...
 Seminário Engenharia de Software
pfvasconcellos {finito} Seminário Engenharia de...
 Formação de Analistas de Negócios
admin Claro Leandro, Aviso sim. Mas preciso alertar...
 Formação de Analistas de Negócios
Leandro Pimentel Poderia avisar quando ter turmas para...

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 35 of 36

 Tags

Administração de Ativos Agile Alinhamento Análise de Negócios Arquitetura Corporativa Ativos de Software BABoK Casos de Uso
Engenharia de Requisitos Engenharia de Software EPBE Evento FAN Formação de Equipes Fred Brooks Gerenciamento
de Projetos Gestão do Conhecimento IIBA Iterativo e Incremental Livro Modelagem de Negócios Priorização Reuso Scott
Berkun Scrum SOA Tempo Real Eventos The Art of Project Management The Mythical Man-Month UML

 Agenda

 28/08/2010:
 Seminário Engenharia de Software (09:00)
 17/09/2010:
 FAN em Curitiba (09:00)
 24/09/2010:
 FAN em Sampa - 21ª Edição (e contando...) (09:00)
 30/09/2010:
 FAN in Rio (09:00)

 Calendário

« Jul Sep »
August 2009
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
 What I'm Doing...

 De partida para a 3ª edição do FAN em BH. Turma lotada. O que sempre gera um saudável
frio na barriga. #FAN #finito 1 week ago
 Concordo @ccalmendra. Mas toda a apresentação é ridícula. Uma vergonha. Uma pena...
#pmi #fail 1 week ago
 Eu desisto. Uma vez quadrado, sempre quadrado. http://bit.ly/9zP6yV 1 week ago
 Valeu @raphalbino, obrigado pela força! 2 weeks ago
 Where I’ve Been…

 Links

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010
BABoK: Uma Leitura Crítica | finito Page 36 of 36

Blogroll
Grupos de Discussão
Referências

Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.


Imagens que aparecem nas descrições dos serviços são de Tanakawho.
O finito utiliza Wordpress com o tema Thesis. |

http://www.pfvasconcellos.eti.br/blog/2009/08/20/babok-uma-leitura-critica/ 20/08/2010