BABoK - Uma Leitura Crítica

8/8/2019 BABoK - Uma Leitura Crtica

1/36

finito

Home Sobre Servios

Engenharia de Processos Administrao de Ativos Suporte a Projetos

Treinamento Formao de Analistas de Negcios O Jogo dos 7 Erros para Lderes de Projetos O Jogo dos 7 Erros para Analistas de Negcios

Downloads Contato

BABoK: Uma Leitura Crtica

20/08/2009

in Anlise de Negcios,Biblioteca

Antes de mais nada, um alerta: se seu interesse pelo BABoK limita-se obteno da certificao, entoeste artigo no vai ajud-lo muito. Poupe seu tempo. Eu sei, chato, mas este artigo tambm merece umprlogo-escudo: no tenho interesse nenhum em depreciar o IIBA (International Institute of BusinessAnalysis) ou seu principal produto, o BABoK Guide (A Guide to the Business Analysis Body ofKnowledge). H tempos apresento, aqui e ali, crticas quela que deveria ser a principal referncia para aformao de analistas de negcios (ANs), o BABoK. Meus objetivos sempre foram apenas dois: i)ajudar os ANs em seu processo de formao; e ii) contribuir para a evoluo do BABoK. Ressalvas ealertas devidamente colocados, vamos ao que interessa. Este artigo trata da ltima verso do BABoK, a2.0, publicada em 2009.

Page 1 of 36BABoK: Uma Leitura Crtica | finito

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


2/36

A Estrutura do BABoK

Alguma coisa muito estranha aconteceu entre a liberao da verso para reviso pblica, em maro/2008,e a verso definitiva publicada agora. A estrutura bsica do BABoK foi mantida, com suas 6 disciplinas(KAs ou Knowledge Areas), mas a ordem de apresentao sofreu considerveis alteraes. Se algumaustificativa para tal foi apresentada, no percebi. O fato que complicaram a leitura. Em meu

entendimento, desnecessariamente.Na verso 2.0 liberada para reviso as duas primeiras disciplinas apresentadas eram aquelas de perfil maisgerencial e ttico: Planejamento e Monitoramento da Anlise de Negcios e Gerenciamento eComunicao dos Requisitos. Era uma alterao necessria em relao verso anterior, a 1.6, quecomeava pela Anlise da Organizao (ou Enterprise Analysis). Necessria por agrupar, mesmoque de maneira implcita, as disciplinas cuja aplicao se diferencia substancialmente das outras quatro.(Mais sobre elas no decorrer do artigo).

A verso atual do BABoK inseriu Elicitao entre as duas, comprometendo uma certa lgica de leitura.E a Anlise da Organizao, que um dia foi a primeira disciplina apresentada, agora aparece apenas noquinto captulo. Uma estrutura que parecia bem resolvida, como ilustra o grfico abaixo, virou um

diagrama de difcil entendimento.

As disciplinas no BABoK 2 (public review)




3/36

No primeiro diagrama percebemos claramente uma sequncia lgica de 4 disciplinas, alm da informaode que outras duas guiam e/ou do suporte anlise de negcios. O segundo desenho quebra essa lgica eno faz nada mais do que confundir. Realmente incompreensvel a mudana.

Alm disso, ainda sobre a estrutura do BABoK, preciso dizer que a forma como as disciplinas so

apresentadas boa. Destacam-se as entradas, tarefas e sadas principais de cada disciplina. Depois, paracada tarefa, so descritos: entradas, elementos (que so especficos para cada tipo de tarefa), tcnicas,partes interessadas (stakeholders) e sadas. A sequncia lgica e didtica, apesar dos deslizes que serodiscutidos abaixo.

Armadilhas

Saca aquele sujeito que, areo e desastrado, acaba caindo em armadilhas que ele prprio armou? Essaimagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia doIEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definio derequisitos. Logo depois, ainda no captulo 1, alerta que vital que o termo requisito seja compreendidono mais amplo sentido possvel. Ao tentar ilustrar o que seria essa amplitude toda, confundem: em umainiciativa BPM, requisitos podem ser uma descrio dos processos de negcio atualmente em uso pelaorganizao. Alm de comprometer a definio do IEEE utilizada na pgina anterior, criam um tipo desaco sem fundo onde tudo ou pode ser um requisito. Armadilha armada no primeiro captulo faz vtimasno decorrer de todo o BoK. Quando apresentando a tcnica de Anlise de Regras de Negcios, porexemplo, dito que regras de negcios devem ser separadas de outros requisitos. Ou seja, do aentender que regras de negcios tambm seriam um tipo de requisito.

Um analista de negcios deve aprender cedo que a distino entre elementos do negcio (recursos,processos, eventos e regras) e elementos da soluo (requisitos) crucial para o bom desenvolvimento deseu trabalho. Ele sabe que h uma nica interseo entre esses dois conjuntos e ela atende pelo nome de

Requisitos do Negcio. O BABoK os define corretamente, como grandes objetivos, metas enecessidades de um negcio. De to importantes, mereceram uma disciplina s para eles, a Anlise daOrganizao. O que torna ainda mais indecifrvel a baguna apontada no pargrafo anterior.

A segunda armadilha bastante notvel no BABoK a necessidade de manuteno de uma certacompatibilidade retroativa. O BABoK tenta colocar e manter os ps em dois mundos muito distantes.Ele os chama de Plan-driven e Change-Driven nomenclatura criativa usada para diferenciar omundo clssico de projetos daquele universo que surgiu aps o big-bang do Manifesto gil. Se numprimeiro momento no captulo 2, que trata do Planejamento e Monitoramento da Anlise de Negcios ele se mostra muito atencioso com o enfoque change-driven, na parte que seria mais cara enecessria tal ateno evaporou. Em Gerenciamento e Comunicao de Requisitos (captulo 4), porexemplo, quase nada falado sobre a forma como requisitos so gerenciados quando adotado umprocesso gil qualquer (Scrum, XP etc).

O referido captulo repleto de procedimentos para reviso e aprovao de requisitos, baselines,documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar declssico. Se mantido o mesmo balanceamento (de preocupaes) apresentado no captulo 2, aquideveramos ver no mnimo uma vez a expresso software rodando, ou soluo rodando ou algo dotipo. No vemos. O que permite dizer que o BABoK firma o p mesmo no mundo clssico, a exemplode seu primo no muito distante, o PMBoK. E por falar nele

O PMBoK sumariamente ignorado pelo BABoK. Troco, j que o primeiro tambm ignora o segundo e

A nova estrutura do BABoK




4/36

ainda se mete a falar sobre elicitao de requisitos? Acho que nunca saberemos. Mas importantedestacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas,Planejamento e Monitoramento da Anlise de Negcios e Gerenciamento e Comunicao dosRequisitos, de perfil mais gerencial. Ambas invadem o domnio do gerenciamento de projetos sem sepreocupar em fixar fronteiras. Criaram pelo menos duas faixas de Gaza e o risco de conflito alto.Particularmente no que se refere ao gerenciamento e comunicao de requisitos (que inclui a tarefaGerenciar Requisitos e o Escopo da Soluo). Viu a palavrinha mgica ali? Escopo!

Por essa e muitas outras eu vivo defendendo que Escopo no do analista de negcios e muito menosdo gerente de projetos. Deveria ser s do arquiteto e ponto. Mas isso tema para outra hora. Alis,ateno piratas! Vou lanar o FAS Formao de Arquitetos de Solues. Preparem suas copiadoras!hehe..

Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crtica ao BABoK ofato dele ignorar por completo a disciplina conhecida como Modelagem de Negcios. O problema setorna mais perceptvel na verso 2.0. Porque de fato ele no ignora a necessidade da modelagem.Sugestes para o uso de tcnicas de modelagem aparecem a todo momento, em diversas disciplinas. Maselas surgem de forma to solta e desestruturada que difcil imaginar que sejam utilizadas em sua

plenitude. Pior: difcil imaginar que gerem algum valor. Aos fatos.Ainda na primeira disciplina, Planejamento e Monitoramento da Anlise de Negcios, soapresentadas como tcnicas gerais a Modelagem da Organizao e a Modelagem de Processos. EmAnlise da Organizao, o 5 captulo, so elencadas as tcnicas Benchmarking, Anlise de Regrasde Negcios, Decomposio Funcional e Anlise SWOT. No sexto captulo, Anlise deRequisitos, o assombro: alm de diversas das tcnicas acima, sugerem inclusive o uso de Diagramas deFluxo de Dados na tarefa que deveria ser apenas Organizar Requisitos. Dentre os elementos destatarefa aparece uma breve explanao sobre cada um dos 5 conceitos que, segundo o BoK, garantem atotal cobertura do domnio do negcio. Alis, os 5 conceitos so: 1) Classes de Usurio, Perfis e Papis;2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.

Nada mais necessrio para confirmar que a Modelagem de Negcios fundamental para oentendimento de um negcio. Colocando de outra maneira: fundamental para a Anlise de Negcios. OBABoK sabe disso. Acontece que, ao invs de trat-a como uma disciplina como um corpo preferiuesquartej-la e distribu-la em pedacinhos em diversas de suas KAs. grave quando percebemos que aAnlise de Requisitos, uma disciplina por si s complexa e crtica, vira uma espcie de monstro deFrankestein no BABoK.

Essa armadilha se torna mais visvel quando percebemos que em outros pontos do BoK apresentadacomo entrada para determinadas tarefas uma tal Arquitetura Corporativa (um documento que, segundoo BABoK, descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos denegcio, sistemas, informao etc). Esse inputj existiria de alguma maneira na organizao. Duas

coisinhas: 1) Essa Arquitetura Corporativa igual cabea de bacalhau todo mundo sabe que existe oudeveria existir mas ningum nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? No factvelsupor que seu desenvolvimento e manuteno, mesmo que parcial, sejam atribuies dos analistas denegcios? Tem hora que o BABoK finge que no com ele. Em outros momentos (na Anlise deRequisitos!?!), sugere que o analista desenvolva vrios artefatos que ajudariam a compor umaArquitetura Corporativa. Vai entender

Concluso

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




5/36

geral desenhada com esse fim, e bem desenhada, por outro o contedo ainda apresenta inconsistnciasdemais. Pouco adianta o reuso de conhecimentos bem consolidados, como definies do IEEE ediagramas UML, se eles so contraditos ou diludos de tal forma que perdem seu sabor e valor.

Joe Gollner publicou em julho ltimo um artigo chamado O Curioso Caso da Anlise de Negcios.Brinca com o ttulo do filme estrelado por Brad Pitt, O Curioso Caso de Benjamin Button. Joe erra feioao dizer que no estaramos prontos para definir um corpo de conhecimentos para a anlise de negcios.

Tenho certeza de que j temos conhecimento e maturidade suficientes para delinear um BoK. Mas eleacerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.

A necessidade de manuteno de uma compatibilidade retroativa , sem sombra de dvidas, a grandeculpada. Como justificar, em 2009, o uso de tcnicas como a elaborao de DFDs e diagramas decontexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim oBABoK s faz confirmar uma fama dos ANs: seriam consumidores vorazes de papel. No digo com issoque ele deveria se ater aos princpios pregados no Manifesto gil. Afinal, a anlise de negcios no selimita a projetos de software. Mas imperdovel que um BoK para anlise de negcios se lembre deDFDs e ignore por completo balanced scorecards, mapas estratgicos, conceitosLean etc etc etc.

Ento um analista de negcios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obteno dacertificao CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar oBABoK. Alm de ter boa experincia prtica. Mas o analista deve ter conscincia de todas as armadilhase inconsistncias que o BABoK apresenta em sua verso atual. Para no correr o risco de comprometerseu trabalho e at sua carreira.

.:.

Nota aberta ao IIBA

A lei de imprensa morreu, o finito no imprensa, mas tica e educao no precisam ser regidas por

leis. Caso o instituto julgue necessria uma resposta ao artigo acima, eu garanto o mesmo espao emesmo destaque. E reafirmo: no tenho interesse nenhum em critic-los por criticar. Muito pelocontrrio. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com umBABoK forte e consistente. Todos sabemos que um debate franco e aberto o melhor caminho para arealizao desses objetivos.

.:.

Servio:

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

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

1. Entenda como Mundo Clssico de Projetos aquele que brotou e cresceu no sculo passado.Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ouwaterfall e que sustenta seus mtodos e prticas em diferentes nveis de comando e controle. Noh nada de pejorativo nessa definio. E no h nada de errado com esse modelo, desde que ele noseja utilizado em projetos de software.

2. O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de




6/36

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

Bookmark / compartilhe

Artigos relacionados:

1. BABoK = REBoK? Conversando sobre Anlise e Modelagem de Negcios2. O Analista de Negcios e o tal BABoK3. O BABoK e a Disciplina Enterprise Analysis4. O Mundo gil precisa de Analistas de Negcios?5. O Giro em Falso das Rodas Reinventadas

Tagged as: Agile, Anlise de Negcios, BABoK, Engenharia de Requisitos, Gerenciamento de Projetos,IIBA, Iterativo e Incremental, Modelagem de Negcios, PMBoK, Scrum, UML

{ 43 comments read them below or add one }

1 Bruno Torquato August 20, 2009 at 13:34

Achei honestas, construtivas e saudveis 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. Abraos,

Paulo

3 Constantino August 21, 2009 at 02:13

Pezado Paulo!

Ainda no li o BABoK, e no tenho um juzo de valor que me permita tecer comentrio ou crticasmais profunda e com a mesma autoridade como voc o faz. Mas, fico com algum dos seuscomentrios e sobre os quais fao as seguintes consideraes.

TheBABoK: Uma Leitura Crtica byfinito, unless otherwise expressly stated, is licensedunder a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.




7/36

Voc disse:

(1) Por essa e muitas outras eu vivo defendendo que Escopo no do analista de negcios emuito menos do gerente de projetos .

Obviamente que nenhum artefato pertence a nenhum dos atores do processo, exclusivamente. Nocaso do Escopo, ele parte integrante do ciclo de vida do projeto e pertence rea de

Gerenciamento de Integrao do Projeto e deve ser continuamente acompanhado pelo gerente doprojeto que poder at mesmo alter-lo. Ento, nesse sentido o Escopo da alada do Gerente deProjetos sim, a quem cabe fazer o acompanhamento progressivo do projeto alm de desenvolver adeclarao do escopo preliminar do projeto.

Veja o que diz o PMBOK/2004 que sob sua referncia trabalham milhares de profissionais em todoo mundo, inclusive no Pentgono e na NASA: O gerente de projetos gerencia o escopo, ocronograma, o custo e a qualidade dos produtos dos pacotes de trabalho .

Voc disse:

(2) Essa Arquitetura Corporativa igual cabea de bacalhau todo mundo sabe que existe oudeveria existir mas ningum nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? No factvel supor que seu desenvolvimento e manuteno, mesmo que parcial, sejam atribuies dosanalistas de negcios? Tem hora que o BABoK finge que no com ele. Em outros momentos (naAnlise de Requisitos!?!), sugere que o analista desenvolva vrios artefatos que ajudariam acompor uma Arquitetura Corporativa. Vai entender .

Pois , nesse caso do BABoK, no posso inferir, mas posso informar que no Processo Unificado daRational, conhecido como RUP, existe absoluta clareza sobre essa Arquitetura Corporativa,compreendida analogamente pelo Documento Avaliao da Organizao Alvo, descreve o statusatual da organizao em que um futuro sistema dever ser implantado. A descrio se d em termosde processos atuais, organogramas, ferramentas, competncias de pessoas, atitudes de pessoas,clientes, concorrentes, tendncias tcnicas, problemas e reas de melhoria. Isto a ArquiteturaCorporativa com suas instncias de negcio e os elementos que lhes so constituintes. Oresponsvel aqui o Analista do Processo de Negcios.

Voc disse:

(3) Ento um analista de negcios deveria ignorar o BABoK? De jeito nenhum. Se almeja aobteno da certificao CBAP (Certified Business Analysis Professional), fornecida pelo IIBA,ele deve decorar o BABoK .

Aqui voc falou bem, se o Profissional deseja a certificao dever mesmo decorar o BABoK,

lamentavelmente.

A meu juzo, uma pessoa para atuar como Analista de Negcios, no o far apenas pelo fato de teruma certificao obtida pelo mtodo decoreba em baixo do brao, mas sim por ter ashabilidades requeridas, avaliadas por um processo de avaliao de competncias que evidencieaquelas reas de desempenho que necessitem ser fortalecidas mediante uma formao e nosimplesmente uma certificao. A avaliao de competncia para esses profissionais deveriacompreender um conjunto de competncias bsicas, especficas e inclusive de gesto, dado ocontexto atual das relaes de trabalho, em que a maioria desses profissionais so consultores, noraro autnomos .




8/36

Que contribuio plena poder dar um Analista de Negcios, certificado por esse mtodo, paraliderar uma equipe de desenvolvimento de um ERP, por exemplo? Acho que antes precisa ter umdesenho curricular que lhe d capacidade para lidar com Gesto de Materiais, Compras, Contas aPagar, Contas a Receber, etc., sem falar no setor de governo, com suas Gestes Oramentrias,Licitaes, Contratos, etc.

Importa, neste caso do Analista de Negcio, ter comunicao, ter conhecimento do domnio do

negcio, e o que fundamental, ser um bom facilitador e agregador, para as suas relaesinterpessoais com o cliente e o ambiente onde est inserido. Um analista de negcios deve estarpreparado para avaliar a situao da organizao na qual o produto final do projeto serimplantado, entender as necessidades do cliente e do usurio, suas estratgias e metas, discutir efacilitar um esforo da engenharia de negcios, se necessrio, realizar uma anlise decusto/benefcio de quaisquer mudanas sugeridas, e por ai vai.

Enfim, os analistas de negcios certificados por esses meios, no mximo s iro engrossar asestatsticas do Gartner de projeto de TI mal sucedidos, sem falar no prejuzo do cliente.

Um grande e fraterno abrao


Retificando, este pargrafo fica melhor assim:A meu juzo, uma pessoa para atuar como Analista de Negcios, no o far apenas pelo fato de teruma certificao obtida pelo mtodo decoreba debaixo do brao, mas sim por ter ashabilidades requeridas, avaliadas por um processo de avaliao de competncias que evidencieaquelas reas de desempenho que necessitem ser fortalecidas mediante uma formao e nosimplesmente uma certificao.

Abrao Paulo.

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

Paulo,

Acei no mnimo interessante seus comentrios. Realmente o BABOK tem vrios problemas, maspara falar a verdade o PMBOK at hoje possui problemas clssicos e outros que foramadicionados na ltima verso. Por exemplo, no ltimo PMBOK o processo de criao da

declarao de escopo preliminar simplesmente DESAPARECEU. Algum sabe onde esse procesofoi parar? Se algum achou, por favor, me avise!!! hehehehe

Tanto o PMBOK quanto o BABOK possuem coisas boas e ruins, porm, acho tambm que oprofissional de Anlise de Negcios NO deve se limitar apenas ao BABOK. Tem que ir alm! E,muito alm!

Contudo, achei interessante quando voc disse o seguinte:

H tempos apresento, aqui e ali, crticas quela quedeveria ser a principal referncia para a




9/36

formao de analistas de negcios (ANs), o BABoK.

Voc diz acima que o BABOK deveria, ou seja, ele no sua principal referncia para aformao dos ANs. Conte a para ns: quais so as suas principais referncia para a formao dosANs? Vamos compartilhar suas fontes. Hehehehe

Vou citar apenas alguns livros interessantes que considero como referncia em AN:

- The Business Analysts Handbook- Software Requirements

e vrios outros.

Abrao,


Marcelo Neves IIBA-RJ, a propsito quando estar funcionando o IIAB-RJ. J est? Por favorme envie um e-mail sobre:[email protected].

Tambm posso sugerir um livro muito interssante: Software Project Management, Royce, Walker Adisson Wesley, 2003. USA.

Abraos

7 Fabrcio Laguna, CBAP, PMP August 22, 2009 at 10:40

Ol Paulo,

como ningum 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 refernciapara a formao de analistas de negcios (ANs). Pelo menos, ao meu ver um guia que contemplaos principais conceitos e tcnicas utilizados nesta rea e pode orientar bastante na formao deprofissionais indicando quais assuntos merecem um estudo detalhado, e que pode ser encontradoem outras publicaes.

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 abraam o objetivo de compilar um Corpode Conhecimentos. E o BABOK encara a parada e nesta verso acredito que faz bem feito.Vou comentar seu artigo por tpicos:

A ESTRUTURA DO BABOK




10/36

As principais inconsistncias do PMBOK se do por utilizar Processos para a Gesto de Projetossem definir uma Metodologia. No d para dissociar as coisas. E um dos principais objetivos de umBOK ser genrico e aplicvel a qualquer metodologia. Entendo que o BABOK escapou destaarmadilha definindo as reas de conhecimento em Tarefas em vez de Processos. Uma tarefa podeser executada em vrias etapas de um processo e em diferentes metodologias. Por isso a figura dasreas de conhecimento mudou. Para deixar claro que o guia no apresenta uma sequncia de fasesde um processo, mas sim um conjunto de tarefas que oferecem produtos umas s outras.

Um exemplo: A elicitao no ocorre somente em uma etapa do processo. Ela uma tarefa comtcnicas especficas que so executadas iterativamente em vrios processos e que ofereceinformaes para todas as demais.

ARMADILHAS

A definio do IEEE no foi surrupiada, o BABOK fez a devida referncia bibliogrfica na nota derodap.Tambm no vejo uma inconsistncia com esta definio quando o BABOK diz que requisitospodem ser uma descrio dos processos de negcio atualmente em uso pela organizao elejustifica mais adiante com requisitos que descrevem a situao atual da organizao so, por

definio, solues para um problema de negcio passado. Descrev-los antes de dar uma novasoluo pode ser interessante num modelo de anlise As-Is e To-Be, alm de serem extremamenteteis num ambiente de gesto de requisitos com rastreabilidade entre diferentes tipos de requisitos.

COMPATIBILIDADE RETROATIVA

importante considerar que o modelo Tradicional (Cascata) no est morto e nem vai morrer.Ainda provavelmente o mais utilizado nas organizaes e o mais adequado para um grandenmero de projetos e por isso no poderia ficar fora do BoK.Na minha opinio, achei genial a distino que o BABOK fez em modelos orientados aoPlanejamento (Plan-driven) e orientados a Mudana (Change-Driven ). Em vez de defenderuma ou outra abordagem, o BABOK apresenta consideraes sobre cada uma delas, o que ajuda aidentificar em qual situao cada uma melhor aplicada e o que a sua adoo impacta nas tarefasda anlise de negcios. Uma grande ajuda para quem deseja entender estas diferenas.

ESCOPO

O PMBOK faz uma distino clara entre escopo do produto e escopo do projeto. O primeiro tratados requisitos e o segundo do trabalho que deve ser executado para criar os requisitos.Entendo que o Escopo do Produto (da Soluo) deva ser de responsabilidade do Analista deNegcio e o Escopo do Projeto do Gerente de Projeto.Claro que ambos so resultado de um trabalho de equipe e o principal responsvel por toda a gestodo Projeto o Gerente do Projeto. Quando se faz esta distino apenas em relao a qual funo

possui as competncias necessrias para definir cada escopo.

MODELAGEM DE NEGCIOS

Aqui sou obrigado a concordar com voc. A verso 1.6 do BABOK possua a tarefa 2.2 Criar eManter a Arquitetura de Negcios que foi suprimida da verso 2.0. No apndice do guia quedetalha essas mudanas dito que A Anlise de Negcio em um nvel mais amplamentecorporativo e estratgico ser direcionado em uma extenso de rea de aplicao separada.No sei ao certo o que isso quer dizer, mas entendi algo do tipo: Aguarde novidades para a verso3 ou ento Faremos um guia diferente para o Analista de Negcios Estratgico e assim podemos




11/36

lanar mais uma Certificao para aumentar a nossa gama de produtos.No sei qual a estratgia do IIBA mas me cheira a uma distino semelhante a do PMI doGerenciamento de Projetos e o Gerenciamento de Programas.A Modelagem de Negcios deve mesmo ser feita por um esforo de Anlise de Negcios e deix-lade fora do guia foi realmente um passo para trs.

CONCLUSO

Discordo de sua posio de que o BABOK nasceu velho e que tcnicas que no fazem parte daspreferidas pelos analistas geis deveriam estar fora do guia. So ainda extremamente teis e devemfazer parte do canivete suo de ferramentas dominadas por um bom analista. O importante saberseus prs e contras para decidir quando e para que utiliz-las. Salientando ainda que o guia foca naanlise de negcios para um universo de solues mais amplo do que apenas o desenvolvimento desoftware.

Concordo com voc de que o debate produtivo e de que as crticas so 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.

Ento temos o nosso RUPBOK. hehehehehe. RUP vai mais longe, ele sugere uma formao eno uma certificao, com base em um desenho curricular, para o que chama de maneiracompletiva, de Analista de Processos de Negcios, acertadamente, porque nem sempre voc analisao negcio, mas os processos do negcios, em suas partes. Um absurdo voc ler nas ofertas doscursos de Analistas de Negcios, que no h pr-requisitos para fazer o curso. Mas v l queseja!

Uma pessoa que quer atuar como um Analista do Processo de Negcios deve ser um bomfacilitador e ter excelentes habilidades de comunicao e ser holstico.Ter conhecimento do domnio do negcio fundamental para aqueles que desempenham estepapel.Um analista do processo de negcios deve estar preparado para:Avaliar a situao da organizao-alvo na qual o produto final do projeto ser implantado, entenderas necessidades do cliente e do usurio, suas estratgias e metas. (Aqui que est a parede onde amaioria bate e cai, pois aqui a tecnologia no a nfase).Facilitar a modelagem da organizao-alvo, discutir e facilitar um esforo da engenharia denegcios, se necessrio, realizar uma anlise de custo/benefcio de quaisquer mudanas sugeridas

na organizao-alvo. (Tambm aqui objetiva avaliar at por questo tica se a organizaorealmente precisa da soluo sistematizada, o que muito raro algum dar o aconselhamento deno fazer).Analisar e auxiliar aqueles que comercializam e vendem o produto final do projeto.

Abraos para todos!

9 Leandro Mendona August 23, 2009 at 14:34




12/36

Paulo,

Parabns pelo artigo e principalmente pela coragem em escrev-lo. Textos como esse so comoestacas fixadas por verdadeiros desbravadores para auxiliar alpinistas iniciantes como eu.

Voc sabe que vai tomar cacetada de todo lado, n? Mas, como diz o chavo: faz parte

Agora, vamos aos comentrios:

1 Concordo com a sua crtica estrutura do BABOK. Mas aqui proponho uma reflexo: seriapossvel estabelecer uma estrutura nica para um corpo de conhecimento com uma proposta toampla, 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 publicaes mais especializadas (menosgeneralistas)

b) Os BOKs assumirem que esse tipo de estruturao (sequencia lgica) impossvel. Nessa caso,

todos poderiam comear com uma disciplina do tipo: Estruturando o seu corpo de conhecimento.Nesse captulo eles poderiam apresentar alguns exemplos de receitas (estruturas) que levam osingredientes (KA, processos, tarefas, etc.), fechando com um Como montar a sua prpriareceita.

c) ops, eram 3 possibilidades Escritores independentes poderiam criar os seus prpriosroteiros de viagem pelo BABOK. (olha aqui uma sugesto de apndice 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 seusrequisitos em de negcio, de usurio, funcional, no funcional, de arquitetura, deusabilidade, bonito, feio, cheiroso, tudo bem, cada um sabe o que faz com os seusrequisitos. Para mim, um requisito um problema que deve ser resolvido e quando isso aconteceele passa a ser um requisito atendido. Os critrios de classificao de requisitos ainda so muitosubjetivos. Prefiro definir isso com a equipe de acordo com a necessidade do projeto ao invs deadotar um padro de mercado, at porque acho que esse padro no existe. J cansei de verdiscusses (estpidas) do tipo: isso um requisito de negcio no, isso um requisito deusurio no, isso uma regra de negcio caso de uso sei no, isso parece mais umatarefa, no mximo uma atividade e qual a diferena entre tarefa e atividade ah,depende

3 Sobre Arquitetura Corporativa, concordo plenamente. Todo mundo diz que existe, masningum nunca viu.

Abraos,

Leandro Mendona

10 admin August 24, 2009 at 11:40

Ol,




13/36

Como, por motivo de fora maior (15 FAN em Sampa), deixei acumular alguns comentrios,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, vrias organizaes eempresas o utilizam como base para o gerenciamento de projetos. O questionamento que fao, no de hoje, sobre a eficcia de uma disciplina que deve ser genrica o suficiente para acomodarprojetos de plataformas de petrleo e projetos de lojas virtuais, com toda a infinita gama de tipos deprojetos que existe entre esses dois exemplos.

Uma indstria que cito com mais frequncia para ilustrar minha sugesto a de cinema: l existemo diretor (o arquiteto o criativo) e o produtor (o gerente do projeto o administrador). O escopo do diretor. Quando no , 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 trs partes fundamentais(Objetivos, Estrutura e Regras) de um negcio? Se ele no cuida delas, como a ArquiteturaCorporativa completa? Perdo querido Constantino, mas sigo pagando para ver a cabea dessebacalhau.

(3) Eu disse no texto que, alm da decoreba, o analista deve comprovar experincia. Alis, oIIBA exige a comprovao dessa experincia. E ela deve contemplar os aspectos muito bemapresentados por ti.

===

Ol Marcelo Naves,

O fato do PMBoK apresentar srios problemas no isenta o BABoK dos seus. E todo mundodeveria estar ciente de que um BoK, qualquer BoK, no encerra assunto nenhum. Minhapreocupao especfica com o BABoK que suas armadilhas podem tornar o ir alm umaviagem bastante acidentada.

Vou dar outro exemplo, que ignorei no artigo. Ainda na introduo, o BABoK lista uma srie dereas no cobertas por ele que um AN deveria estudar. Esto l: BI, SOA, CMMI, Gerenciamentode Projetos, ITIL, Arquitetura Corporativa (Zachman Framework e TOGAF), Engenharia deSoftware (particularmente Engenharia de Requisitos) etc.

Nada de contabilidade, matemtica financeira, administrao, marketing Sinceramente,considero essas disciplinas to ou mais importantes do que *todas* listadas por ele. o Negcio,Becio! meu grito. Nossas equipes j tm gente demais preocupadas com ITIL, BI, SOA

Em algum lugar j falei que consultei centenas de livros e artigos no desenvolvimento de meutrabalho. Acho que aqui no o local mais indicado para essa lista. Mas no vou esconder minhasfontes no. Em breve as divulgo em um local mais indicado, ok?

===




14/36

Ol Fabrcio Laguna,

Reforando o que eu disse para o Marcelo, o BABoK uma referncia muito perigosa porque emsua verso atual inconsistente e incompleta, como ilustro em meu artigo. Ao contrrio de ti, noacho que ele contemple os principais conceitos e tcnicas utilizados nesta rea. A quartaarmadilha citada no artigo, e que mereceu sua concordncia, uma prova disso.

Antes de responder os demais pontos destacados por ti, um alerta: considero o livro do HowardPodeswa, que voc listou, um perigo. Aquela UML sugerida por ele (que a mesma do RUP e doScott Ambler), no contempla todas as necessidades que temos quando de fato *modelamos umnegcio*.

A Estrutura do BABoK

Eu disse l no artigo, a estrutura boa. Mas a sequncia de apresentao das disciplinas estavamelhor resolvida na verso disponibilizada para reviso pblica no ano passado. Acho que os doisdiagramas que utilizei falam por si. uma questo matemtica: se o maior nmero de entradas deuma disciplina tem origem em um mesmo lugar, logicamente esse lugar deve ter sido apresentado

antes da disciplina em questo. Exemplificando: 3 das 6 entradas da disciplina Elicitao sogeradas pela Anlise da Organizao. Elicitao o captulo 3, e Anlise.. o captulo 5. Meperdoe, mas t errado! Atente para o fato de que apenas 2 das 7 entradas de Anlise.. teremorigem em Elicitao. Como eu disse, uma questo matemtica. Que em sua simplicidade,facilitaria a leitura do BABoK.

Armadilhas

Mil perdes. Uso o termo surrupiar a todo momento, inclusive para indicar citaes que fao. Euno quis dizer que o IIBA utilizou indevidamente as definies do IEEE. Mas fui infeliz naredao.

Mas sua afirmao, junto com o comentrio do Leandro, me deixam preocupado. A descrio deum processo de negcio *no* pode ser considerada um requisito ou um conjunto deles.

Muito do que encontro por a, em empresas e turmas abertas, uma imensa dificuldade ementender e diferenciar requisitos. Essa colocao de que tudo ou pode ser requisito nocontribuir em nada para um melhor entendimento.

Karl Wiegers, em livro citado pelo Marcelo, surrupia (com crditos) a definio que IanSommerville e Pete Sawyer publicaram em Requirements Engineering (Wiley, 1997). Requisitospodem ser:

. Uma funcionalidade especfica;

. Uma propriedade do sistema;

. Uma restrio especfica (do sistema);

. Uma restrio ao desenvolvimento (do sistema).

A lista acima j representa responsabilidade demais para uma palavrinha (requisito) s. Noprecisamos de mais complicaes. E o BABoK confunde sim, como mostrei. E confundir regras denegcios com requisitos armadilha das mais perigosas. Afinal, regras so mais volteis querequisitos e merecem tratamento muito especial.




15/36

Compatibilidade Retroativa

Eu no disse que o BABoK no deveria contemplar o modelo clssico de projetos (ou cascata).Apenas alerto que nos momentos em que uma boa apresentao do change-driven seria maiscara (Gesto de Requisitos e Escopo, por exemplo), ele ignorado ou tratado com uma enormedisplicncia. Assim, a boa idia da apresentao e distino dos dois mundos vai por gua abaixo.

Escopo

J reforcei minha opinio, no incio deste comentrio. muito dono pra pouca coisa. Sigoapostando no modelo Toyota, com um Engenheiro-Chefe (arquiteto) tendo a palavra final sobre oescopo (que na minha opinio, um s! Sua diviso s faz confundir e criar faixas de Gaza.).

Modelagem de Negcios

Considerar a modelagem de negcios uma disciplina ou tarefa de finalidade exclusivamenteestratgica seria um equvoco ainda mais comprometedor. Toro para que o IIBA no cometatamanha bobagem. Modelamos um negcio para entend-lo. E todo projeto demanda tarefas para

que tal entendimento acontea. Portanto, a modelagem , antes de estratgica, operacional.

Concluso

Perdo meu caro Fabrcio, mas DFDs e afins so velhos sim. E isso no tem nada a ver com ser ouno simptico ao Manifesto gil. E uma publicao de 2009, que queira falar para Analistas deNegcios e ignore BSCs, Mapas Estratgicos, System Maps, PUCS e uma cacetada de outrastcnicas e ferramentas que so modernas mas que tambm j esto bem consolidadas umdocumento que nasce sem noo de seu tempo. O BABoK Guide 2.0, infelizmente, nasceu velho.

Mas, tenho certeza, nossos papos aqui podem contribuir para que as prximas verses sigam ospassos de Benjamin Button. Pelo menos no que se refere ao rejuvenescimento.

===

Enfim, meu caro Leandro, chego aos seus comentrios.

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

(1) Como eu disse em outro frum (no BPM-Forum), acredito sim na possibilidade de um BoKpara a Anlise de Negcios. O BABoK, apesar de suas armadilhas e inconsistncias, uma provadisso. Considero graves seus enganos mas reforo: a estrutura boa. O que no significa que elano pode ser melhorada. Pode. E muito!

As alternativas b e c sugeridas por ti so legais, mas no sei at que ponto seriam aceitas.Infelizmente os BoKs (todos eles) costumam nascer com jeitinho de imexveis de intocveis.Porque muita coisa depende deles (provas de certificao e, em ltima instncia, o faturamento dequem os cria).

Particularmente, eu gostaria muito de ver BoKs (principalmente o PM e o BA) verticalizados por tipo de projeto ou organizao. Mas sei que partirei desta para uma melhor sem testemunhar arealizao desse requisito to bobo e bvio.




16/36

(2) E por falar em requisitos, espero ter respondido esse ponto l no trecho onde converso com oFabrcio.

===

Ufa! Resta agradecer a quem chegou at aqui. E, principalmente, ao Constantino, Marcelo,Fabrcio e Leandro, pelo papo to bom e rico: Muito obrigado!

Abraos,

Paulo Vasconcellos

11Marcelo Neves August 24, 2009 at 14:52

Oi Paulo,

A discusso t ficando boa t ficando quente! hehehehe

Quando eu disse que o PMBOK apresenta srios problemas sem dvida que isso no isenta oBABOK dos seus. Mas, digo que faz parte do amadurecimento natural dos BOKs todo esseprocesso de discusso e aprimoramente. E, na verdade o BABOK j nasceu muito mas maduro queo PMBOK. Basta comparar a verso 1.0 do PMBOK com a verso inicial do BABOK.

De qualquer forma, tambm concordo contigo que o Analista de Negcios tem que se aprofundarem muitos outros assuntos. Mas, sinceramente voc acha que um BOK conseguiria compilar todosos assuntos necessrios para a formao de um AN? Eu considero os BOKs um pontap inicial eNO uma compilao completa e totalmente abrangente de um assunto especfico.

Discordo plenamente de voc com relao a sua afirmao de que o BABOK uma refernciaperigosa, pois claro que o BABOK est incompleto. Eu diria que NUNCA teremos um BABOKcompleto. Atualmente NO temos um PMBOK completo. A completude dos BOKs umaverdadeira falcia. Mas, sem dvida que imperdovel o IIBA no abranger modelagem denegcios entre outros.

Enfim, a estrada a frente longa. Os desafios so enormes. E, isso que me instiga a continuar.

At a prxima!


Marcelo!

Voce disse: Mas, sinceramente voc acha que um BOK conseguiria compilar todos os assuntosnecessrios para a formao de um AN?

Acho que no precisaria ser todos os assuntos necessrios, mas os indispensveis, por meio deuma matriz curricular mnima para a profisso de AN, com o propsito de identificar aquelas reas




17/36

de desempenho que necessitam ser fortalecidas mediante uma formao para alcanar o nvel decompetncia requerido.

Se eu decorar todo o BABoK, e passar na prova de certificao, o que eu adquiro, uma certificaoou uma formao?

O que vai definir meu desempenho para modelar um negcio, sugerir melhorias para uma empresa,

minha certificao decorada, ou o meu arcabouo de conhecimentos, tecnolgicos inclusive?

Como eu vou coordenar uma equipe de modelagem, ter as habilidades de comunicao eorganizao necessrias, definir e delimitar a organizao alvo, aplicar as tcnicas de brainstormsnecessrios, ouvir equipe e cliente, discutir e facilitar um esforo para engenharia de negcios, etc?

Ou Analista de negcios no precisa conhecer nada disso?

Creio que o AN, deve ir muito alm de uma ferramenta CASE, muito alm de identificar e modelarcasos de uso de negcios e os respectivos diagramas.

Um grande e fraterno abrao!

13 admin August 24, 2009 at 16:13

Ol Marcelo,

eu diria que o BABoK aprendeu com vrios erros do PMBoK e nasceu sim melhor que ele. Masesse o preo do ineditismo, certo? O problema com o PMBoK que ele agora pareceamarradssimo em sua estrutura original. Um dia tentaram um workaround e inventaram a 9disciplina, Integrao. Mais recentemente, na edio de junho/julho da MundoPM, Paulo Yazigi

Sabbag sugere em um artigo que Gesto do Conhecimento passe a integrar o PMBoK, na formade 4 processos de gesto. Definitivamente, IMHO, no por a. Mas voltemos ao BoK em questo,o BA.

Voc pergunta se eu acho que um BOK conseguiria compilar todos os assuntos necessrios para aformao de um AN?. No! E no foi isso que eu quis dizer quando listei aquelas disciplinas.Aquilo l s um comentrio sobre a lista de estudos complementares sugeridos no BABoK. Eudisse que a lista deles TI demais e negcio de menos, s isso.

Um BoK, como bem disse o Constantino, deve se concentrar no essencial. E o essencial, em minhaopinio, formado por duas grandes disciplinas: Modelagem de Negcios (que usamos para

*entender o negcio*) e Engenharia de Requisitos (que utilizamos para *entender os usurios*).Nem mais, nem menos.

O BABoK, em sua verso atual, perigoso no s por estar incompleto, mas por apresentarconceitos de maneira no muito acertada. Sobre requisitos, por exemplo. Da o perigo.

Mesmo entendendo que o BABoK no para iniciantes, julgo seus equvocos bastante perigosos.No s para os estudos visando certificaes, mas principalmente para o dia-a-dia de um analista.

Marcelo e Constantino, muito obrigado pela participao.




18/36

Forte abrao,

Paulo Vasconcellos


S uma adendo a mais, para no ser chato!

Atualmente estou no final de uma empreitada de modelar o negcio para a construo de um ERPpara uma empresa de servios, com mais de 4.000 funcionrios e duas filiais no exterior. Estsendo entregue as ltimas iteraes.

Ento, foi necessrio primeiro montar, sugerir, testar uma arquitetura, vender idia toda em BPM edevidamente prototipada para o conselho aprovar, de modo que, o que fosse desenvolvido refletisseipsis literis o fluxo de trabalho da empresa e mais uma infindvel regras de negcios, queenvolvem suas atividades fim, gesto de compras, gesto de materiais, logstica de distribuio,

fornecedores, contas a pagar, tesouraria, faturamento, legislao tributria, etc.Se eu chegasse l apenas com as minhas certificaes, RUP, Ps -graduao, ITIL, etc., tinha cadodo cavalo, pois trata-se de uma empresa familiar que queria apenas melhorias, no mudanasradicais nos seus processos. Todos os produtos de prateleira que foram oferecidos e mostrados, noforam aceitos, no por serem ruins, ou caros, mas por no ter aderncia, no refletir o negcio delese de extensa adaptabilidade.

Enfim, acho que essas coisas contam e no devem ser desprezadas para considerar um Analista deNegcios.


Constantino,

para obter a certificao CBAP do IIBA voc deve comprovar 7500 horas em atividadesrelacionadas a anlise de negcios e experincia em pelo menos 4 das 6 reas de conhecimentopropostas pelo BABOK.O isso indica que sua experincia no desprezada, mas exigida pelo processo de certificao doIIBA. Alm de poder comprovar em um exame que sabe escolher a melhor alternativa de comoaplicar os conhecimentos listados no BABOK em situaes problema.Boa sorte.Int

16Marcelo Neves August 24, 2009 at 17:57

Constantino,

Concordo plenamente com voc. O meu nico porm o seguinte: vamos deixar de usar o BABOKapenas por que ele est incompleto? No meu caso no! Sem dvida que o BABOK ainda tem que




19/36

comer muito feijo.

Sem dvida que a certificao CBAP deve ser muito mais do que decoreba. Infelizmente o IIBAainda no acertou a mo 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 dizque falta a modelagem que fundamental. No me pergunte o porqu deles no terem includo,mas mais do que necessrio. E, para quem Analista de Negcios, concordo que ler o BABOK eno encontrar esse assunto, fica no mnimo confuso.


Fabrcio Laguna, CBAP, PMP 24/08/2009 at 17:39

Valeu Fabrco!Muito grato meu amigo, agradeo e estou mais reflexivo.

Um abrao


Fabrcio Laguna, CBAP, PMP 24/08/2009 at 17:39

Valeu Fabrcio!

Muito grato meu amigo, agradeo e estou mais reflexivo.

Um abrao


Ol Paulo,

Sigo discordando no seguinte ponto:

confundir regras de negcios com requisitos armadilha das mais perigosas. Afinal, regras somais volteis que requisitos e merecem tratamento muito especial.

Dvida: mais volteis quanto? 50% 20% 200% 1,6 anos?

Acho essa confuso de definies (atividades, processos, casos de uso, regras, objetivos, metas)to natural que prefiro trat-la em primeiro plano do que supor que existam convenes de mercado




20/36

suficientemente claras sobre os termos.

Gosto da forma como o BABOK apresenta suas definies algo do tipo: para os propsitosdesta publicao foi adotado o seguinte esquema de classificao

Pronto, tudo muito simples e sem pretenso. Acho que assim que conseguimos fugir dessaarmadilha.

Abs.,

Leandro.

20 admin August 25, 2009 at 17:08

Ah meu caro Leandro,

Se esse tipo de estatstica existisse o mundo seria um lugar bem melhor para se viverMas as regras so mais volteis sim. Uma que determine um desconto em uma transao comercial,por exemplo, pode mudar vrias vezes em um perodo relativamente curto, de 2 ou 3 meses. Mas orequisito Calcular Desconto permanece o mesmo por dcadas ou sculos! Em seguradoras asregras que determinam os clculos mudam mensalmente. Mas os requisitos so os mesmos h anos.Olhe ao seu redor: garanto que voc encontrar diversos exemplos, mais ilustrativos que os meus.

Quando comeamos a achar que determinado tipo de confuso natural porque estamos prestesa esconder o problema debaixo do tapete. Existem sim convenes suficientemente claras que nospermitem diferenciar todos os elementos de um negcio e da voz do usurio. Para ficar em duasreferncias:

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

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

Respeito sua opinio sobre o BABoK. Na minha, ele foi escorregadio e preguioso.

Obrigado por mais uma participao nesta thread.

Abraos,

Paulo


Oi Paulo,

Seus exemplos so perfeitos, mas considero que essa classificao j faa parte do processo detratamento dos requisitos. Mais um pouquinho e um AN desavisado cai na armadilha de definir a




21/36

soluo, mandando Regra de Negcio pra turma do Banco de Dados e os requisitos pra turma docdigo. Prefiro evitar essa discriminao inicial.

O fato que, como voc colocou, difcil encontrar consenso na diferenciao de requisitos.Talvez seja porque isso subjetivo mesmo.

No momento no me vem nenhum exemplo a mente, mas sei que dependendo do contexto, do

escopo ou da arquitetura da soluo um requisito pode ser tratado como regra de negcio e vice-versa. Logo, acho que essa questo da classificao deve ser tratada explicitamente pelo AN noincio do projeto, do modo como o BABOK tratou. Algo do tipo: para este projeto adotaremosa seguinte classificao de requisitos.

Isso particularmente til para projetos mais amplos do que os de desenvolvimento de software. Ecomo o BABOK trata a Anlise de Negcio de uma forma mais ampla, faz todo o sentido elesabstrairem o conceito de requisitos.

Sei que essa amplitude da abordagem do IIBA uma das causas-raiz das suas crticas, mas isso fato e acho que voc deveria considerar esse fator na sua anlise.

No vou me estender (ainda mais) para no desviar a discusso, mas espero ter colaborado comalguns argumentos para aquele artigo sobre regras de negcio que voc prometeu ; ).

Abraos,

Leandro

22 admin August 25, 2009 at 21:50

Opa pera Leandro,

Requisito requisito, independente do tipo de projeto. Alis, quando eles nascem, nem sabemosainda qual tipo de soluo melhor os atender. Se em algum momento passei a impresso de quemeu 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 usurio exatamente porque ele o maispreparado para tal. Alis, acho essa uma de suas principais atribuies.

Seno e agora vou falar especificamente de software vira o balaio de gato que vemos por tudo

quanto canto: regras de negcio cimentadas no meio do cdigo, tornando sua manuteno maisdifcil e lenta e, principalmente, aumentando consideravelmente o custo de propriedade do sistema.

Insisto na diferenciao entre requisitos e regras porque a considero a mais bsica e aquela que geraretorno bastante perceptvel. Mas lembro que o BABoK no peca s nesse quesito.

Cara, meu backlog de artigos t to grande que periga o prometido artigo demorar um pouco. Massair, eu prometo.

Abraos,




22/36


23/36


24/36

Estou adorando participar desta que pode ser assim, uma comunidade de prtica virtual, se mepermitem. Huuummm os puristas de KM no vo gostar disso. Mas s essa vez, t?

Bom Quanto a essa questo de requisitos, creio que ela s persistente, se desprezados oarcabouo metodolgico necessrio a todo projeto de qualidade, tanto do projeto em si, quanto doproduto do projeto, pois creio que a metodologia, na medida em que ela prope uma norma, quevai alinhar no mbito do projeto e dos envolvidos o que considerado requisito no domnio do meu

negcio e dos problemas que estou a resolver.

Creio que o importante no abrir mo das chamadas Diretrizes, dos Casos deDesenvolvimento e tambm do Glossrio porque ai voc no s alinha os principais itens do seugerenciamento, como tambm pode dar a definio de requisitos no domnio do projeto, semprejuzo do que se denomina as melhores prticas.

O RUP um processo, cuja meta garantir a produo de software de alta qualidade, de forma queestas possam ser ADAPTADAS para uma grande variedade de projetos e de organizaes, diz que:Requisito uma condio ou uma capacidade com a qual o sistema deve estar de acordo.

Abraos para todos!

28 admin August 26, 2009 at 13:57

Pois , Constantino,

Tambm estou gostando muito do bate-papo. S confesso um certo frio na barriga toda vez quevejo a sugesto de que a definio do que um requisito seria feita por projeto. Sinceramente,gostaria de ver uma boa justificativa para isso.

Obrigado pela participao.

Abraos,

Paulo


Paulo e Constantino,

entendo que a definio no muda por projeto. A definio do que um requisito funcional, porexemplo, sempre a mesma.O que muda por projeto (ou por metodologia) se vamos usar este tipo de requisito em nossaespecificao, se ele deve ser descrito como texto puro, casos de uso, matriz CRUD se deve estarrastreado s regras de negcio e aos modelos de dados se vo ser subdivididos em sub-categoriasetc.





25/36

Oi Paulo,

Como o artigo sobre regras de negcio no tem previso, vou abusar dessa thread.

Sabemos que requisito representa um desejo ou necessidade do cliente. Isso claro e no precisaser definido para cada projeto. Agora o como esses desejos/necessidades sero organizados, issosim precisa ser definido. E essa organizao pode variar de acordo com a amplitude do projeto, do

vocabulrio (linguagem) da equipe envolvida (no s de TI), dos possveis desdobramentos, etc.Enfim, depende de n fatores.

Pergunto: como voc classificaria requisitos do tipo Treinar equipe, Reformar escritrio,Modelar processo, Divulgar produto, etc? Sei que voc dificilmente se depararia com esse tipode requisito uma vez que o seu foco de trabalho bem definido, mas do ponto de vista de umaorganizao que quer ter uma viso mais integrada dos seus problemas essa distino no faz tantadiferena. Em outras palavras, estabelecer relaes entre os diferentes requisitos mais importantedo que classific-los.

Agora se podemos ter um nico arcabouo metodolgico (gostei dessa) para tratar requisitos de

todos os tipos sem discriminao, como sugere o BABOK, timo! Estaremos no caminho certopara o exerccio de uma Anlise de Negcio efetiva.

Sobre a relao regras de negcio x requisitos, no meu entendimento uma regra de negcio umtipo de requisito. Um tipo de requisito cuja principal caractersitca a maior volatilidade e queprovavelmente ser tratado pelo sistema de uma forma menos engessada, como voc falou. Mas schegarei a essa concluso aps analisar os requisitos, o que j faz parte do processo de Anlise deNegcio. Antes disso ele s um requisito mesmo, desses bem genricos e escorregadios comodefine o IIBA.

Abraos,

Leandro.

31 admin August 26, 2009 at 21:08

Leandro,

Eu sei que no vou te convencer. E nem era esta a minha inteno. Seguirei achando o BABoKdeveras (Cony j proibiu essa palavra) perigoso, escorregadio e preguioso. J citei fontes quetrataram melhor a distino entre requisitos, regras etc.

Concordo contigo e com o Fabrcio: cada organizao ou projeto definir um mtodo maisadequado para o desenvolvimento de requisitos. Mas acho que no era isso que estava em questo.

Abraos e obrigado pela participao.

Paulo




26/36


Paulo,

Agradeo a ateno dispesada aos comentrios. Sinto que estamos gerando contedo bastante

relevante para discusses futuras, neste e em outros fruns.

Apesar dos diversos comentrios, no acho que desviamos a questo central do artigo que acrtica (construtiva) ao BABOK. Independente de estar cero ou errado, o fato que o BABOK trataos requisitos dessa forma mais genrica e esse entendimento fundamental para aqueles que vorealizar a leitura.

Para as demais questes apontadas por ti, reforo o meu apoio.

Abraos,

Leandro Mendona.

33 admin August 27, 2009 at 09:32

Leandro,

No h o que agradecer. Estou aqui pra isso mesmo. E no tenho dvidas de que a conversa aquiregistrada muito rica. Como eu disse l no nosso grupo de discusso, os comentriosmultiplicaram por 30 e tantos o valor do artigo.

Entendo e respeito seu ponto, que o mesmo defendido pelo Fabrcio, sobre a forma como oBABoK tratou essa questo (requisitos). Certo ou errado, como voc bem colocou, o fato quevira uma definio formal que deve ser estudada por todos que queiram se aprofundar em anlisede negcios, particularmente aqueles que visam a certificao.

Acho que nossa conversa, no mnimo, deixar as partes interessadas com uma pulga atrs daorelha. E isso bom.

Abraos 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 razovel e cita oPMBoK em uma de suas KAs). Naquele dia do FAN eu brinquei que no sabia se era AN ou GP

Na verdade, os BoKs esto s refletindo a confuso do mercado. O que, se pensarmos no que deveser um BoK, em sua essncia, talvez estejam corretos




27/36

Outro dia vi uma grande empresa, de quem se esperaria uma profissionalizao maior, pedir umAnalista de Projetos que era 60% GP, 40% AN, 30% Gerente de Vendas e 20% Arquiteto Noenlouqueci no. 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 Modelerque vai causar arrepios no Paulo, por qu mistura o papel do AN com o Arquiteto, e substitui asdisciplinas do RUP, Modelagem de Negcios, Requisitos e Anlise eDesign pela genrica

Modelagem (???). Obs.: No estou julgando o mrito da proposta, apenas descrevendo.

Gostei da idia do arcabouo metodlogico, but I wanderse no devemos comear a pensar emPadres de Processos, sem a definio de papis, mas de Competncias, Habilidades eAtitudes para os papis em vez de papis (roles) definidos de maneira fundamentalista.

Em tempo: acho que a idia geral do PMBoK e a definio do que atribuio do GP faz sentido,se as empresas entendessem e injetassem na veia o que de fato o GP deve fazer: gerenciar. Masconcordo que a incluso do Coletar Requisitos no novo PMBoK t meio difcil de engolir fiqueimeio fora de contexto (ou estou com limitaes mentais, o que no discarto).

Abraos.

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 discusses. realmente enriquecedor.

Abraos,

Juliane

36 Suzandeise Thom August 31, 2009 at 14:13

ESTRUTURA DO BABOK 2.0

Concordo com a sua avaliao da estrutura do BABOK 2.0 quando diz que a forma como asdisciplinas so apresentadas boa, mas que o diagrama da interao entre as reas deconhecimento deixa a desejar. O diagrama atual til para entender como esto relacionadas as

entradas e sadas de cada conjunto de atividades. Mas ele no deveria ser o nico diagrama, pois aprimeira impresso de quem o v de que ele complicado demais. Seria mais didtico introduzirprimeiramente um diagrama simplificado (mais parecido com o do DRAFT) para depois complic-lo com as setas que indicam todas as entradas e as sadas. O tanto de setas no diagrama atualcausou at essa nova ordenao dos captulos que, como voc colocou, no intuitiva pra quem lo documento pela primeira vez. Vale a pena ressaltar que esse diagrama com todas as setas traz tona a natureza iterativa das atividades de anlise de negcios, ponto com o qual concordoplenamente.

AMBIGUIDADE NA DEFINIO DO TERMO REQUISITOS




28/36

O nmero de comentrios neste thread discutindo a definio de requisitos preocupante. Umdocumento como o BABOK 2.0 no deveria dar margem a interpretaes. (Alis, comunicaoclara e livre de ambiguidade uma habilidade crucial para analistas de negcios).

Admiro a sua maneira apurada e academicamente embasada de definir termos. Entendo a suacrtica de inconsistncia na definio do termo requisitos. Mas teremos que conversar sobre issopor mais algumas horas (sem a cerveja e talvez com um flip-chart) para que eu possa chegar a uma

concluso sobre esse assunto. Os pensamentos que me vm mente agora resumo aqui

Anlise de Negcios acontece quando temos um problema ou uma oportunidade e precisamosencontrar uma soluo. Esta soluo tem que resolver o gap entre a capacidade atual daorganizao (processos, sistemas ou produto/servios atuais) e onde ela quer chegar. Uma coisa modelar o estado atual da organizao (para entend-la), outra coisa descrever o ponto onde elaquer chegar (os requisitos da soluo). Este ponto onde a organizao quer chegar inclui tudo oque queremos manter da capacidade atual (inclusive processos e regras de negcios) + novosprocessos/regras/funcionalidades/etc. Ento os requisitos das novas capacidades se confundem comos requisitos para se manter a capacidade atual de qualquer forma so os requisitos da soluoe a meu ver incluem, sim, processos e regras de negcio.

Toda essa discusso tem que ser resolvida e documentada a ponto de no dar margem parainterpretaes. Ta um desafio pro BABOK v3.

COMPATIBILIDADE RETROATIVA

O que voc chama de compatibilidade retroativa , na minha opinio, consequncia daexperincia daqueles que se juntaram para escrever o BABOK 2.0. A maioria dos envolvidosprovavelmente veio de TI, portanto o texto que por um lado defende que Anlise de Negciosabrange atividades muito alm dos projetos de sistemas de software, cita muitos exemplos de TI eno deixa clara a aplicabilidade a outras reas. Na minha opinio este um dos maiores problemasdesta verso do BABOK. genrico demais em alguns aspectos (vide a confuso que gerou nadefinio de requisitos) e especfico demais em outros (nos exemplos de TI).

Mas tudo depende da perspectiva de quem l. Alias, quase todo o texto do BABOK tem que serinterpretado baseado na experincia de quem l. Este no um texto para iniciantes. (E acredito serimpossvel passar na prova de certificao CBAP decorando o BABOK 2.0 sem ter a experinciarequerida)

Concordo com a diferenciao que o BABOK 2.0 faz entre change-driven e plan-driven. Adeferenciao entre essas duas abordagens realmente clara e consistente no captulo 2(Planejamento e Monitoramento de Anlise de Negcios), como voc indicou. Sua crtica aocaptulo 4 (Gerenciamento e Comunicao de Requisitos) faz sentido. Dada a natureza da

abordagem plan-driven, bem mais fcil entender os exemplos citados no captulo 4 tendo emmente vivncias dos projetos cascata. Mas ele tambm se aplica aos projetos que utilizam umprocesso gil, ou a abordagem change-driven. Mesmo quando se utiliza um processo gil, necessrio gerenciar requisitos, comunic-los e aprov-los. A maneira como se faz isso que deveser diferente, menos demorada ou burocrtica. Ser que incluir exemplos disso no captulo 4 omelhor caminho? Se formos nessa direo deveramos incluir exemplos de projetos que envolvemmelhorias de processo, definio de novos produtos, e outros mais

BABOK 2.0 vs. PMBOK




29/36

Eu te provoquei a ler o BABOK 2.0 e o seu artigo me fez estudar a quarta verso do PMBOK. Nosltimos dez dias despendi muito tempo analisando os textos, trocando emails, enfim No vounem comear a destrinchar esta aparente falta de alinhamento entre o IIBA e o PMI. Daria umlivro. Se eu conseguir respostas aos meus questionamentos, voltarei a esse tpico.

MODELAGEM DE NEGCIOS

Esta disciplina realmente foi dividida em vrios captulos. No tenho opinio formada sobre comoseria melhor abordar isso dentro do BABOK. Isso e a maneira como foi tratada a ArquiteturaCorporativa esto entre os meus questionamentos tambm

ESCOPO

A pergunta no deveria ser quem dono do escopo, e sim quais so as responsabilidades de cadaprofissional em relao ao escopo. Ao gerente do projeto cabe gerenciar o escopo, isto , nodeixar que as atividades do projeto envolvam um escopo maior do que o combinado inicialmentepara que no aconteam impactos negativos no prazo nem no oramento (o gerente de projetos sconsegue fazer isso direito se ele tambm executar as atividades de anlise de negcios ou se tiver

no seu time um analista de negcios.) Ao analista de negcios cabe elicitar requisitos respeitando adelimitao de escopo definida no incio do projeto (aqui assumo que isso foi feito direito no inciodo projeto, claro.) Durante as atividades de elicitao de requisitos, muito comum surgiremassuntos fora de escopo. Cabe ao analista de negcios no permitir que os stakeholders saiampela tangente e incluam pedidos fora do escopo.

Escopo deveria ser do arquiteto? Voc quis dizer o escopo da soluo? Fiquei curiosa

37 admin August 31, 2009 at 15:09

Ol Suzandeise,

Tardou um pouquinho, mas eu sabia que no falharia, n? Antes de mais nada, muito obrigado pelaconsiderao e pela participao neste debate.

Eu seria redundante demais se reafirmasse minhas opinies. Acho que elas ficaram claras no artigoe nos comentrios que publiquei. Ento, me limitarei aos fatos novos:

RequisitosA mudana de uma regra de negcio um requisito. A regra no. A mudana de um processotambm um requisito. O processo no.

Essa distino, que parece bobinha, faz toda a diferena. Onde? Na qualidade das informaes doprojeto na qualidade da documentao!

Suzanne Robertson, co-autora do Volere (http://www.volere.co.uk/), uma das expertsconsultadas pelo IIBA durante a elaborao do BABoK. Se tivessem surrupiado um pouquinhodeste modelo, a definio de requisitos no estaria to vaga. O Volere est bem documentado noapndice A de Requirements-Led Project Management, livro que ela escreveu com JamesRobertson (Addison-Wesley, 2005). No concordo 100% com ele, mas bem melhor que oBABoK no assunto em questo.




30/36

Compatibilidade Retroativa

Eu entendo as origens, prezada Suzandeise. Basta ver a lista de experts consultados para se ter umaideia: Scott Ambler, Meilir Page-Jones O que no entendo e o critrio de seleo de algumasprticas sugeridas.

Me causa espanto (e agora me baseio tambm 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 DFDs e diagramas de contexto Alis, se a gente pudesse ver osresultados da pesquisa Ser que o IIBA pode fornec-la?

Escopo

Sim, o Escopo da Soluo deveria ter um nico dono: o Arquiteto. O profissional que guia odesenho e a construo da soluo que orienta o trabalho de toda a equipe tcnica. E que cuida damanuteno da Integridade Arquitetnica da soluo.

Fred Brooks, no longnquo 1975 (em O Mtico Homem-Ms, Elsevier-Campus, 2009), j dizia:

Pensadores so raros. Executores so raros. Pensadores-executores so rarssimos!

O arquiteto no se envolve com questes administrativas do projeto. O gerente do projeto no seenvolve com o desenho tcnico e a implementao da soluo. Simples assim: um pensador e umexecutor.

Facilitamos a delimitao de fronteiras se eliminarmos algumas definies ambguas, comoescopo do projeto e escopo da soluo.

Escopo, segundo o Houaiss, 1. ponto em que se mira; alvo 2. inteno; objetivo. Para ns, esse

objetivo o conjunto de requisitos que um projeto deve atender, certo? Ento, IMHO, ele pertenceao cara que desenhou a forma pela qual os requisitos sero atendidos.

Prximo debate sem cerveja? Ah

Obrigado. Abraos,

Paulo

38 Suzandeise Thom August 31, 2009 at 15:22

Oi Paulo.

A distino que vc fez entre a regra vs. a mudana da regra ou o processo vs. a mudana doprocesso faz total sentido.

Estou tentando conseguir liberao da pesquisa do ano passado eu sabia que vc iria pedir. No s vc que est espantado com o critrio de seleo das tcnicas

Quanto discusso sobre escopo, vai ter que ser ao vivo mesmo




31/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 Mendona September 1, 2009 at 10:27

Oi Paulo,

No sei se entendi essa parte: o Escopo da Soluo deveria ter um nico dono: o Arquiteto.

Esse Escopo da Soluo seria o produto final do projeto, composto, por exemplo, pelo softwarefuncional, suas especificaes e demais artefatos que se faam necessrios. esse Escopo daSoluo que pertence ao Arquiteto, certo? Nesse caso o conceito parece com o de Escopo doProduto do PMBOK.

Quanto ao Escopo do Projeto, esse de responsabilidade do Gerente de Projetos e englobaria asdemais disciplinas de gesto (riscos, aquisies, prazo, qualidade, integrao, comunicao, etc.).

Penso que tambm 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 oAnalista de Negcio (ou o Product Owner) e no o Gerente de Projetos ou o Arquiteto.

Na verdade tratam-se de 3 perspectivas cheias de interseces sobre o mesmo objeto, no caso oprojeto (problema + soluo), mas a distino me parece pertinente e necessria.

Pensei que voc concordava com essas definies, mas fiquei confuso com seus ltimoscomentrios.

Abraos,

Leandro.

41 Leandro Mendona September 1, 2009 at 10:50

Oi Suzandeise,

Primeiramente gostaria de parabeniz-lo pelo post A Resposta do IIBA. bom saber que oInstituto est realmente disposto ao dilogo aberto com a comunidade.




32/36

Sobre o seu comentrio nesse artigo, mais precisamente na parte do Escopo, discordo do final:

Ao analista de negcios cabe elicitar requisitos respeitando a delimitao de escopo definidano incio do projeto (aqui assumo que isso foi feito direito no incio do projeto, claro.) Duranteas atividades de elicitao de requisitos, muito comum surgirem assuntos fora de escopo. Cabeao analista de negcios no permitir que os stakeholders saiam pela tangente e incluam pedidosfora do escopo.

Na verdade, cabe ao AN gerenciar o escopo de modo que requisitos prioritrios sejam tratadoscomo tal, independente do momento em que surgem. claro que existem n restries queinterferem nessa priorizao, mas justamente a que entram o AN e o GP, na negociao dosrequisitos x restries.

Abraos,

Leandro Mendona

42 admin September 1, 2009 at 11:00

Oi Leandro,

Fiquei mesmo com medo de confundir quando publiquei meu comentrio. Tentei simplificar acoisa e por isso no deveria ter falado em Escopo da Soluo. Afinal, um pouco antes eu estavafalando em Escopo que a gente deveria ver um nico Escopo.

Mas talvez a palavra no seja adequada. Escopo, Requisitos estamos repletos de palavrasque carregam mais responsabilidades do que deveriam. Eu sei que voc no concorda, mas seguireidefendendo uma simplificao um uso mais racional e direto dessas palavrinhas.

Segundo o PMBoK o gerente de projetos tem 9 reas para cuidar. No acho correto chamar esseconjunto de escopo. At porque Escopo uma delas. Exatamente aquela que, insisto, nodeveria pertencer ao gerente de projetos.

Um projeto iniciado para dar origem a um produto, uma soluo, certo? A coisa mais importantede um projeto, independente do tipo ou natureza, o seu produto. Concorda?

O que defendo, seguindo ensinamentos de Brooks e vrios outros, alm de minhas prpriascicatrizes, que o gerente de projeto cuide da parte administrativa (Gerencial!) do projeto: custos,prazos, riscos, contratos A parte criativa do projeto (o desenho da soluo algo que

equivocadamente chamarei novamente de Escopo) deve ser de outra pessoa. Deve ser de umprofissional que domine tcnicas e tecnologias que sero utilizadas no desenvolvimento daqueleproduto. Gosto de chamar esse cara de Arquiteto. Por razes bvias.

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

Obrigado. Abraos,

Paulo




33/36

43 Suzandeise Thom September 1, 2009 at 11:09

Oi Leandro.

Muito bem lembrado! Por descuido, ignorei priorizao nesse pargrafo que escrevi. A entra em

jogo justamente essa interao entre o AN e o GP, a estratgia da empresa, enfim O assuntoescopo to extenso que discutir isso num thread , na minha opinio, totalmente impraticvel.Por isso prefiro as discusses ao vivo

-Suzandeise

Leave a Comment

Name *

E-mail *

Website

Me envie novos comentrios via email

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 Negcios: Os Diagramas

Next post: FAN @ Sampa 16 Edio

Acompanhe & Participe

Submit




34/36

Busca

Categorias

Anlise de Negcios(88)

Arquitetura(28)

Biblioteca(60)

Cursos e Palestras

(78)Engenharia de Software

(27)

Gerenciamento de Proj...(55)

Gesto do Conhecimento(18)

Outros Assuntos(2)

Pessoas(1) Mais Lidos

Morte e Vida UML Como Priorizar Projetos, Influenciar Decises e no Fazer (muitos) Inimigos Agile Product Management with Scrum Modelagem de Negcios: Os Diagramas Times

ltimos Comentrios

Priorizaradmin Ol Danilo, A plena realizao do grande objetivo da nossa empresa... Priorizar

Danilo Carlos Avante Paulo, Uma dvida quanto a ordem de execuo. No... Seminrio Engenharia de Software

pfvasconcellos {finito} Seminrio Engenharia de... Formao de Analistas de Negcios

admin Claro Leandro, Aviso sim. Mas preciso alertar... Formao de Analistas de Negcios

Leandro Pimentel Poderia avisar quando ter turmas para...

To search, type and hit e




35/36

Tags

Administrao de AtivosAgileAlinhamentoAnlise de NegciosArquitetura CorporativaAtivos de SoftwareBABoKCasos de UsoEngenharia de RequisitosEngenharia de SoftwareEPBEEventoFANFormao de EquipesFred BrooksGerenciamentode ProjetosGesto do ConhecimentoIIBAIterativo e IncrementalLivroModelagem de NegciosPriorizaoReusoScottBerkunScrumSOATempo Real EventosThe Art of Project ManagementThe Mythical Man-MonthUML

Agenda

28/08/2010: Seminrio Engenharia de Software (09:00)

17/09/2010: FAN em Curitiba (09:00)

24/09/2010: FAN em Sampa - 21 Edio (e contando...) (09:00)

30/09/2010: FAN in Rio (09:00)

Calendrio

What I'm Doing...

De partida para a 3 edio do FAN em BH. Turma lotada. O que sempre gera um saudvelfrio na barriga. #FAN #finito 1 week ago

Concordo @ccalmendra. Mas toda a apresentao ridcula. Uma vergonha. Uma pena...#pmi #fail 1 week ago

Eu desisto. Uma vez quadrado, sempre quadrado. http://bit.ly/9zP6yV1 week ago Valeu @raphalbino, obrigado pela fora! 2 weeks ago

Where Ive Been

Links

Jul Sep

August 2009

S M T W T F S1

2 3 4 5 6 7 89 10 11 12 13 14 1516171819 20 21 2223 24 25 26 27 28 29

30 31




36/36

Blogroll

Grupos de Discusso

Referncias

Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.Imagens que aparecem nas descries dos servios so de Tanakawho.O finito utiliza Wordpress com o tema Thesis. |


BABoK - Uma Leitura Crítica

Documents

Transcript of BABoK - Uma Leitura Crítica