PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: BABoK

  • A Resposta do IIBA

    Como prometi em “BABoK: Uma Leitura Crítica“, o IIBA terá o mesmo espaço e destaque para publicar suas respostas às críticas apresentadas naquele artigo. Suzandeise Thomé, presidente do Chapter São Paulo do IIBA, encaminhou uma resposta oficial. Ela segue na íntegra:

    .:.

    Primeiramente quero agradecer ao Paulo pela sua análise do BABOK® 2.0. Aliás, esta leitura crítica feita por ele é consequência de uma conversa nossa há algumas semanas, quando eu lhe mostrei o diagrama com a estrutura do BABOK® 2.0 e praticamente o provoquei a comprar o documento e estudá-lo… Acho essa discussão extremamente construtiva.

    Concordo que o BABOK® 2.0 tenha defeitos. A imaturidade do BABOK® 2.0 citada por Joe Gollner em seu artigo “O Curioso Caso da Análise de Negócios” não foi contestada por Kevin Brennan, IIBA VP Body of Knowledge, em sua resposta “O Perfeito é Inimigo do Bom.” Ao invés de defender o BABOK® 2.0, Kevin defendeu a iniciativa do IIBA de documentar as práticas de Análise de Negócios mesmo numa época em que a própria disciplina está em processo de formalização. Ele ressalta que o BABOK® 2.0 não é uma compilação das melhores práticas de Análise de Negócios, mas sim uma compilação de “generally accepted practices”, ou práticas habitualmente utilizadas por Analistas de Negócios. (Vale aqui uma retificação da descrição utilizada por mim em palestras recentes do IIBA-SP. Utilizei o termo “melhores práticas” para descrever o BABOK® 2.0 quando eu deveria ter dito “práticas habitualmente utilizadas.”)

    A discussão iniciada por Joe Gollner, rebatida por Kevin Brennan, e resumida por Jonathan Babcock em “IIBA: Timely or Premature?” ressalta o fato de que é preciso ter um ponto de partida, de que é necessário criar um Corpo de Conhecimento para poder depois aperfeiçoá-lo. A iniciativa do IIBA de trazer formalização e reconhecimento à profissão e de documentar suas práticas vem de encontro à necessidade dos profissionais desta área que, até hoje, enfrentam dificuldades para justificar não só seus cargos dentros das empresas mas tamtém o tempo despendido em atividades de Análise de Negócios nos projetos em que atuam.

    Defendo a existência do BABOK® 2.0 como guia de referência para Analistas de Negócios que deve descrever as atividades com as quais devemos nos preocupar. O objetivo do BABOK® 2.0 é estabelecer uma visão abrangente, não um manual detalhado de como se executar Análise de Negócios em situações específicas.

    Respostas oficiais que obtive até o momento:

    Técnicas incluidas no BABOK® 2.0

    A escolha das técnicas a serem incluidas no BABOK foi baseada numa pesquisa feita no final de 2008 com membros do IIBA ao redor do mundo. Foram escolhidas as técnicas que muitos Analistas de Negócios utilizam no seu dia a dia. Não são as técnicas mais recomendadas, nem as únicas que um Analista de Negócios deve saber mas sim as que um AN deve estar preparado para executar. Em linha com o restante do BABOK® 2.0, essa lista é um ponto de partida.

    Referências ao PMBOK

    A omissão de referências ao PMBOK na versão final do BABOK® 2.0 se deve à decisão do IIBA de não fazer referências a fontes específicas exceto em casos absolutamente necessários. Além disso, a data de lançamento da quarta edição do PMBOK não permitiu que o IIBA tivesse tempo de rever as referências mencionadas no DRAFT e atualizá-las para refletir a versão mais recente do PMBOK.

    Encerro aqui a minha defesa do BABOK® 2.0 como Presidente do IIBA-SP. Minha opinião pessoal sobre o artigo “BABoK: Uma Leitura Crítica” colocarei como comentário, pois não posso defender cegamente algo que não escrevi. Repito o que disse ao Paulo pessoalmente e também em palestras do IIBA-SP: continua de pé o meu compromisso de levar ao IIBA críticas construtivas que nós brasileiros gerarmos. Acredito que temos muito a contribuir para a compilação das melhores práticas de Análise de Negócios. Levarei as críticas do Paulo Vasconcellos e as minhas próprias dúvidas ao Kevin Brennan e me comprometo a compartilhar as respostas assim que eu as obtiver.

    -Suzandeise Thomé
    Presidente
    IIBA São Paulo

  • BABoK: Uma Leitura Crítica

    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.

    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)
    As disciplinas no BABoK 2 (public review)
    A nova estrutura do BABoK
    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 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 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:

    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  suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework do SEI?

  • Modelagem de Negócios: Os Diagramas

    Sequência obrigatória de “Modelagem de Negócios: Uma Sugestão“. Como prometido, apresento neste artigo um conjunto básico de diagramas que um analista pode desenvolver para entender um negócio. Opa… vale repetir o mantra: Modelamos um negócio para entendê-lo. Este é o principal objetivo da disciplina conhecida como modelagem de negócios. Assim como o principal alvo da engenharia de requisitos é a compreensão dos desejos, necessidades e restrições dos usuários.

    Portanto, por favor, utilize as sugestões abaixo com moderação. Traduzindo: não é para sair desenhando tudo quanto é diagrama sugerido aqui! Apresento uma variação do “Codex” de Dan Roam (autor de “The  Back of the Napkin”) exatamente para facilitar a escolha de determinado tipo de diagrama, dependendo do problema em questão. Como ainda se trata de uma versão beta, críticas e sugestões serão muito bem vindas. Desde já agradeço.

    O 'Codex' da Modelagem de Negócios
    O 'Codex' da Modelagem de Negócios

    O gráfico acima representa nosso ‘Codex’ – um guia que nos ajuda a definir o diagrama ou artefato mais indicado para o entendimento ou apresentação de determinado problema ou solução. O desenho é grande demais para o espaço aqui. Clique na imagem para ver uma versão ampliada. Podemos seguir?

    As linhas representam as 3 visões – do Negócio, da Estrutura e dos Processos – e suas respectivas perguntas. As colunas representam as 5 decisões SQVID. Lembrando: Simples ou Elaborado; Qualitativo ou Quantitativo; Visão ou Execução; Individual ou Conjunto; e Mudança (to-be) ou estado Atual (as-is). Nas células aparecem ícones que representam um tipo de diagrama ou artefato. Quando a célula estiver vazia é porque aquela pergunta, naquele seletor, não faz sentido.

    Abaixo, na sequência das visões, são apresentados todos os diagramas ou artefatos sugeridos.

    Visão do Negócio

    Aqui tentamos responder uma única questão: Por quê? Ou seja, quais são as motivações do negócio? Quais são os grandes requisitos do negócio? Afinal, quais necessidades do negócio esse projeto ou demanda deve satisfazer? Três ícones apareceram no desenho acima:

    0documentoO documento é a única representação não desenhada de todas as sugestões do ‘Codex’. É algo que foi antecipado por Eriksson e Penker em “Business Modeling with UML”. Algumas informações obtidas neste momento simplesmente não fazem sentido de outra forma que não seja texto puro. Mas, antes de abrir seu editor de textos, entenda que essas informações podem estar estruturadas em sofisticados formatos, como Mapas Estratégicos, Balanced Scorecards, matrizes SWOT etc. Podem representar também a declaração de Missão ou Visão da empresa. E ainda, num cenário mais pobrezinho, uma lista com os principais requisitos do negócio.

    0mapa_processosO mapa de processos (neste momento, um ‘modelão’ conceitual) pode ser uma alternativa ao texto puro – uma alternativa mais elaborada. Se estivermos lidando com milhares de palavras, então o desenho pode ser uma boa opção. Afinal, modelamos para simplificar – para facilitar o entendimento. Seu uso também é util para explicar a execução – o meio pelo qual a organização espera realizar a visão, seus objetivos. Como mostra o ‘codex’, este mapa pode ser utilizado tanto para ilustrar o ‘as-is’ como o ‘to-be’, ou seja, como a empresa se vê após a realização de seus objetivos.

    0grafico_simplesQuando lidando com  números, quantidades, não há representação melhor que um belo gráfico – de preferência de barras, que além de muito legível é mais fácil de ser desenhado à mão. Quando utilizado na elaboração da visão do negócio, este gráfico representa grandes números que explicam ou justificam os requisitos do negócio. Estamos falando de aumento de receitas? Ou de redução de custos? Sempre que requisitos assim são apresentados, um gráfico pode ajudar em sua visualização e divulgação.

    A construção da visão do negócio é uma tarefa que normalmente não dura mais que poucos dias ou até mesmo horas. O que não significa que ela não seja importante, pelo contrário. Muitos projetos falham porque, a partir de determinado momento, a equipe simplesmente esquece a principal razão pela qual aquele empreendimento foi iniciado. A visão do negócio representa os principais requisitos do negócio. Portanto, ela não é nada menos que fundamental. E todo projeto deveria começar por ela.

    Visão da Estrutura

    Por estrutura devemos entender todos os recursos que compõem uma organização ou se relacionam com ela de alguma maneira. Três questões devem ser colocadas para a elaboração da visão da estrutura:

    • Quem / O Quê? – para identificar partes interessadas (stakeholders) ou recursos envolvidos em determinada situação. Esses recursos podem ser produtos, serviços, máquinas, documentos etc. Ou seja, qualquer tipo de recurso físico, abstrato ou de informação.
    • Quanto? – para entender e tratar todas as informações numéricas: volume de vendas, número de colaboradores, salários, giro de estoques, quantidade de clientes etc etc. Enfim, separamos com essa questão todos os dados quantitativos sobre os recursos elencados na pergunta anterior.
    • Onde? – agora uma questão para localização, para posicionamento dos recursos na organização ou em seu macro-ambiente (nicho, mercado ou cadeia de valor).

    São 4 os diagramas principais usados para elaboração da visão da estrutura:

    0classes_simplesO diagrama de classes é quase onipresente nesta visão. Não é uma questão de falta de opções, mas sim de uma grande versatilidade desta ferramenta. No entendimento das questões de identificação (quem / o quê), o diagrama de classes pode ser utilizado para representar organogramas ou a composição de produtos ou serviços, por exemplo. Na pergunta que trata de localização (onde), este diagrama pode representar departamentos, seções, filiais, franqueados etc. No ‘codex’ aparece também uma outra versão deste diagrama, simplesmente para indicar a possibilidade de confecção de desenhos mais elaborados e extensos.

    0estadoQuando é necessário analisar um recurso específico o diagrama de estado pode ser de grande utilidade. Os estágios no ciclo de vida de um contrato ou uma apólice, o status de uma ordem de compra, os estados de determinado equipamento etc. No livro “Business Modeling with UML”, este diagrama é usado na construção da visão do comportamento, opção que não está contemplada nesta sugestão. Independente do nome ou perspectiva, o importante é saber que podemos contar com esta ferramenta sempre que um recurso relativamente complexo exigir um estudo e representação mais detalhados.

    0grafico_elabPois é, como já foi citado na visão anterior, não existe representação visual melhor do que um gráfico (de barras, preferencialmente) para as respostas da questão “quanto”. Repare no ‘codex’ que este é o único artefato gerado em todas as variações oferecidas no seletor. Mas é importante colocar que algumas organizações podem apresentar essas respostas em outros formatos. Um balanced scorecard, por exemplo, obrigatoriamente apresenta metas quantitativas para todos os indicadores apontados. O bom analista evita redundâncias.

    0fluxo_swinlanesO artigo anterior chamou a atenção para o fato de alguns diagramas ultrapassarem os limites de uma visão. Eis aqui um diagrama de atividades (ou fluxograma), natural da visão dos processos. Aqui, na visão da estrutura, ele aparece em uma única célula: quando precisamos ver a execução (2ª opção da terceira coluna do ‘codex’) em resposta para a pergunta “onde?”. Colocando de outra maneira, este diagrama pode ser utilizado para explicar onde determinadas atividades ocorrem ou devem ocorrer.

    A visão da estrutura é sumariamente ignorada no padrão de modelagem da moda, a BPMN. Claro, não é uma culpa da notação. O problema é que muitos profissionais ainda misturam e chacoalham bolas, acreditando ser possível a utilização da BPMN para a modelagem (o *entendimento*) de negócios. Não é.

    Visão dos Processos

    Finalmente, a visão que trata da parte dinâmica de uma organização. Todas as tarefas, atividades e processos executados por uma empresa são capturados e analisados através dos artefatos que compõem esta visão. Duas perguntas nos levam até eles:

    • Quando? – nos ajuda a  posicionar ações em uma linha de tempo. Quando tal problema ocorre? Quando aquele evento deve ser disparado? Qual é o deadline daquela tarefa? E assim por diante.
    • Como? – por fim, a última e mais complicada questão. Como tal atividade acontece? Como aquele processo deve ser executado? É a questão que guia o mapeamento e modelagem de processos e atividades de negócio.

    Não por acaso, é nesta visão que temos um conjunto maior de diagramas. São 8 tipos principais, listados abaixo:

    0processo_seqMapas de processos nos ajudam a responder tanto o “quando” quanto o “como”. Geralmente formam o melhor ponto de partida para o desenho das respostas para as duas perguntas desta visão. São particularmente úteis quando os envolvidos não têm um entendimento comum sobre os processos envolvidos em determinado problema. Todos os outros artefatos gerados na construção desta visão, de certa forma, derivam deste.

    0processoO mapa, apresentado acima, é na realidade um conjunto de diagramas de processos. Para desenhá-los deveríamos seguir um pattern sugerido em “Business Modeling with UML”. Um padrão que vem de outra notação, a IDEF0. É simples: à esquerda do processo ficam as entradas; na direita as saídas; abaixo, todos os recursos utilizados na produção das saídas; e acima os recursos usados no controle do processo. Este diagrama, que à primeira vista parece simplista e desnecessário, pode dar origem a artefatos mais avançados, como mapas de avaliação (nome tropicalizado para “System Maps”, apresentado por Ralph Smith em “Business Process Management and the Balanced Scorecard”). Outro artefato derivado deste é o diagrama de linha de montagem, que veremos posteriormente.

    0fluxo_cronogramaAnalistas de O&M (eles ainda existem?) vão se lembrar da figurinha ao lado. É o velho ‘fluxo-cronograma’. Trata-se do diagrama de atividades da UML acrescido de informações sobre tempo, apontadas em swinlanes ou de alguma outra maneira – isso não importa muito. Uma alternativa é o uso do diagrama de Timing (linha de tempo), que foi introduzido na UML 2. Mas o uso de uma variação do diagrama de atividades deve fazer mais sentido na maioria das vezes, já que o analista reutilizaria um diagrama já elaborado, adicionando apenas informações sobre a duração de atividades e tarefas.

    0fluxo_swinlanesAliás, a base para o diagrama sugerido acima é esse aqui, o diagrama de atividades (ou fluxograma, como queiram). Quando detalhamos um processo, este é o formato. Podemos nos limitar a um nível mais alto – as atividades, ou descer ao menor nível de detalhamento possível – as tarefas. A ferramenta pode ser sexagenária ou centenária. Se dura tanto é porque ninguém inventou nada melhor, certo? Como eu disse em um artigo anterior, a BPMN nada mais é do que uma revisão (3.0?) deste velho conceito. Aliás, quando no domínio da solução (to be) e tendo como base algum produto BPMS, o analista pode substituir este diagrama por modelos BPMN. Aliás, deve. Mas, em todos os outros casos, particularmente quando ainda estiver *entendendo o negócio*, ele deveria evitar a BPMN. E utilizar UML.

    0sequenciaUma alternativa ao diagrama de atividades é o diagrama de sequência. Atenção: é uma alternativa. O analista desenvolve um ou outro para estudar ou representar determinado processo ou atividade. Quando interações entre as partes envolvidas e uma noção de duração das atividades forem muito importantes, então o diagrama de sequência pode ser mais útil que o de atividades. Quando o analista tiver à sua disposição uma ferramenta CASE, ele ganhará um diagrama quando desenvolver o de sequência – o diagrama de comunicação é gerado automaticamente. E pode ser útil na análise das interações entre as partes interessadas – para identificar gargalos, por exemplo.

    0assembly_lineO diagrama de linha de montagem é uma variação do diagrama de processo. Serve para análise específica de recursos que apoiam a execução de um processo (como vimos, esses recursos são desenhados abaixo do processo). É especialmente útil quando esses recursos, representados por linhas de montagem (pacotes da UML), são sistemas de informação. O diagrama ilustra todos os dados lidos e gravados em sistemas, demonstrando como eles viabilizam (ou impactam) um processo de negócio.

    Repare que o artefato acima é o primeiro que trata especificamente de sistemas. Todos os outros apresentados até aqui são utilizados exclusivamente para o entendimento ou demonstração do negócio e seus diversos aspectos. Vale ressaltar que o diagrama de linha de montagem é particularmente útil quando ainda estamos no domínio do problema. Tanto que ele é apresentado como uma alternativa para responder o “como” é hoje (as-is, última coluna do ‘codex’).

    Mas, quando o analista começa a entrar no domínio da solução – capturando requisitos das diversas partes interessadas – quais artefatos ele pode gerar? Abaixo são apresentados dois diagramas que aparecem apenas na coluna D (to be) do ‘codex’:

    0PucsO diagrama PUCS (Process Use-Case Support) é mais um belo exemplo de toda a versatilidade da UML. Ele é a combinação de dois diagramas, de atividades e de casos de uso. O diagrama de atividades, descrito acima, é a base para a elaboração de um PUCS. O analista pode utilizá-lo para iniciar e facilitar os trabalhos de identificação de casos de uso, ou seja, de descoberta e descrição de requisitos funcionais. No PUCS indicamos explicitamente quais atividades ou tarefas do negócio serão suportadas (incrementadas ou impactadas) por determinados casos de uso. Nenhuma imagem representa melhor o ato de ‘embarcar’ sistemas em um processo de negócio.

    0use_caseChegamos então ao último artefato de nossa listinha, o mal falado e mal entendido diagrama de casos de uso. Ele pode ser extraído de um PUCS ou ser desenhado do zero, dependendo das necessidades de entendimento do analista. Suspeito que muitos não concordem, mas desconheço outra representação gráfica que ilustre tão bem todo o escopo funcional de um projeto. Além do pouco tempo gasto em sua elaboração, outra vantagem desse tipo de diagrama é sua legibilidade.

    Deve ter ficado claro pela listinha acima que a elaboração da visão dos processos é a mais complicada – aquela que exigirá mais do analista. O mais perigoso engano que deve ser evitado a todo custo é o desenvolvimento deste estudo numa tacada só, como se fosse uma fase de um projeto. Devemos brigar pelo pleno uso de um processo que seja iterativo e incremental. Com exceção da visão do negócio, desenvolvida na primeira iteração, todas as outras são maturadas e desenvolvidas durante todo o projeto. Mas isso já é assunto para outra hora, né?

    E as Regras de Negócio, onde ficam?

    Como citei no artigo que deu origem a esta série, “Modelagem de Negócios: A Encruzilhada“, David Bridgeland e Ron Zahavi defendem em seu livro, “Business Modeling – A Practical Guide to Realizing Business Value”, que as regras de negócio tenham sua própria disciplina. Até aí, tudo bem. O problema começa quando tentamos buscar algum tipo de representação que seja específico para as regras. Cria-se muita confusão desta maneira. Devemos nos lembrar que a motivação para a modelagem é a simplificação.

    Regras de negócio podem aparecer, definindo ou restringindo, em qualquer outro elemento básico de um negócio (leia-se: objetivos, recursos e processos). Portanto, parece ser um grave engano a definição de um padrão de apresentação específico para regras. Seu repositório natural deveria ser aquele artefato que estava sendo elaborado quando a regra surgiu. Ou, dependendo do caso, um anexo deste artefato. Por exemplo: a regra apareceu quando desenhávamos um diagrama de atividades. Por que não registrá-la ali mesmo, na forma de uma nota? (a UML tem o recurso ‘nota’ para a colocação de comentários em diagramas. As notas podem inclusive ser ‘ancoradas’ em elementos específicos de um diagrama. E são utilizadas em qualquer tipo de diagrama).

    Claro, existem regras muito complexas – extensas pra chuchu. Uma fórmula de cálculo de seguro, por exemplo. Não faz nenhum sentido que uma fórmula de trocentas páginas seja comprimida em um diagrama, certo? Custa grampear a fórmula no diagrama, indicando com um código bobo o local onde ela se aplica? O tema é importante demais para ficar só aqui, no rodapé deste artigo. Voltarei ao tema.

    .:.

    Agora, para encerrar este longo artigo, apenas um breve comentário sobre a disciplina em questão, a Modelagem de Negócios. O que antes era uma suspeita caminha agora para a certeza absoluta: quase ninguém pratica a modelagem de negócios. E, se depender de iniciativas recentes como o BABoK, a situação pode piorar bastante. Por que isso é um problema? Porque o entendimento do negócio é fundamental para o sucesso de um projeto. E ainda não inventaram disciplina mais eficaz que a modelagem de negócios para a obtenção desse entendimento.

    Mas sou teimoso e um incurável otimista. Livros publicados recentemente, particularmente “The Back of the Napkin” (Dan Roam. Portfolio, 2008) e “Business Modeling – A Practical Guide to Realizing Business Value” (David M. Bridgeland e Ron Zahavi. Morgan Kaufmann, 2009) provam que a displina pode ganhar um novo impulso. Eu espero que minhas contribuições mereçam 2 centavos. E um pouquinho de sua atenção. Inté!

    .:.

    Nota:

    • Mais uma imagem surrupiada de Kelbv, agora a flikr0679. É aquela enigmática e colorida figura do topo do artigo. Tudo a ver com modelagem, certo?

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

    Nada como um dia (agitadíssimo) depois de outro (não menos agitado). Ao reler o artigo anterior, “O BABoK e a Disciplina ‘Enterprise Analysis’“, reparei que posso resumi-lo assim: O BABoK trata exclusivamente da macro-disciplina Engenharia de Requisitos. Apesar do nome, a KA (Knowledge Area) Enterprise Analsys (ou Análise Corporativa) trata exclusivamente daquilo que Karl Wiegers chama de Requisitos de Negócio . Trata bem e de maneira bem completa, diga-se de passagem. Mas este fato torna o nome BABoK (Business Analysis Body of Knowledge) meio enganador. Aquele conteúdo formaria um bom REBoK – Requirements Engineering Body of Knowledge. Para a Análise de Negócio falta uma metade: exatamente a Análise (e Modelagem) de Negócios!

    Desconfio que a falta já é sentida pelos próprios autores e responsáveis pelo BoK. Em uma das apresentações recentemente utilizadas na divulgação da profissão e do BABoK, eles frisam:

    Análise de negócios não é análise de requisitos de software. Analisar um negócio é compreender:

    • Como a organização trabalha;
    • Qual a razão de sua existência;
    • Seus objetivos e metas;
    • Como ela busca esses objetivos; e
    • O que ela precisa mudar para melhor atender esses objetivos.

    Para ajudar a definir uma solução para um problema de negócio.

    Com certeza, alguém já fez a mesma cobrança que faço desde que conheci o BABoK. Pena, mas a declaração acima (ainda) não está refletida naquele corpo de conhecimentos. Não há no BABoK um conjunto de Tarefas e Técnicas que atenda plenamente a lista acima, exceção feita ao terceiro item. Bom, como prometi no artigo anterior, serei mais “construtivo”.

    Antes de estudar as necessidades ou problemas de um negócio, é necessário conhecê-lo, aprendê-lo. Uma maneira muito eficaz para se *aprender* um negócio é a modelagem. Modelar é simplificar. Modelar é compilar apenas o que é essencial. Indico (teimosamente) o uso da EPBE (Eriksson-Penker Business Extensions) para a criação desses modelos por dois motivos principais: i) Ela é completa – me permite cobrir todos os aspectos de um negócio, sua estrutura e sua dinâmica (processos); e ii) A EPBE é uma extensão da UML (Unified Modeling Language), uma linguagem madura, bem difundida e fácil de aprender. (Já apresentei a EPBE em outra série de artigos).

    Todo e qualquer negócio apresenta 4 *coisas* que precisamos aprender: Objetivos, Recursos, Processos e Regras. Cada um deles pode merecer um ou mais modelos, dependendo da criticidade do negócio ou do projeto em questão. A EPBE nos oferece 4 visões, 4 dimensões – maneiras diferentes de *ver* o negócio: A visão do Negócio propriamente dita; sua Estrutura; Processos e Comportamento. Não há uma seqüência pré-fixada para o estudo. Como sempre, depende do negócio e do projeto. Mas, mesmo em empreendimentos muito simples, não abro mão de um enxuto mapa de processos e do diagrama de processos (ou “linha de montagem“) um pouco mais detalhado. Usando uma boa ferramenta CASE , e não meus rabiscos, obtemos automaticamente outros modelos, como a estrutura de recursos, objetivos e metas (ou mesmo um balanced scorecard).

    Ao estudar os processos, vendo as atividades e tarefas que os formam e toda a estrutura (departamentos e outros recursos) envolvida em sua execução, ganhamos uma visão mais nítida do “terreno que estamos pisando”. Se há um projeto, existem Requisitos de Negócio. São os objetivos (um dos 4 elementos básicos apresentados acima, lembra-se?), as necessidades ou problemas que devemos sanar. São os primeiros requisitos que conhecemos. Na maioria das vezes, bem antes do projeto ser iniciado. Mesmo que sejam mais críticos e essencias para o sucesso do projeto, esses requisitos são tratados da mesma forma – acolhidos em uma mesma estrutura. Destaquei este ponto para mostrar que Análise e Modelagem de Negócios e a Engenharia de Requisitos são atividades que ocorrem de maneira simultânea, e não sequencial. Nem quem mergulha em “cascatas” conseguiria tratá-las como fases distintas de um projeto – são naturalmente indissociáveis, “gêmeas siamesas”.

    Processos Envelhecem

    O que acontece quando um recurso de uma empresa se torna obsoleto? Ele é trocado, certo? Se for um computador ou um caminhão, compra-se um novo. Se for uma pessoa, aposenta-se ou mostra-lhe o bilhetinho azul (ou cartão vermelho, como queira). Mas, e quando um processo de negócio envelhece? O que acontece? As empresas costumam remendá-los e redesenhá-los. Trocas radicais só ocorrem mediante a implementação arbitrária de um pacote de melhores práticas também conhecido como ERP. Mas, mesmo assim, em curto espaço de tempo, voltam os remendos e redesenhos. O mundo não pára.

    O envelhecimento de processos, assim como o nosso, vem com más notícias. Saca aquela dorzinha na coluna que nunca tivemos? Bom, é por aí. E aqui entramos num ponto relativamente polêmico do trabalho dos Analistas de Negócios (AN’s). É mal traçada a linha que os separa daqueles tradicionais Consultores de Negócios. Há quem diga que um AN não deve “se meter” com os problemas do negócio. Oras, o que justificaria tamanha “vista grossa”?

    É claro que, quando em projetos para desenvolvimento ou implantação de sistemas, o foco do AN não é o redesenho (ou reengenharia) de processos de negócio. Mas isso não significa que ele deva ignorar sintomas e doenças que porventura encontre durante seus estudos. Se ele insistir em levar para a solução aquele processo e suas pequenas dores, levará também maiores riscos e chances de mudanças. É exatamente por isso que, ao contrário do RUP, gosto de chamar esta disciplina de Análise e Modelagem de Negócios. Soarei idiota, mas preciso reforçar: é o Analista de Negócios quem executa a Análise de Negócios! E analisar, definitivamente, não se resume ao desenho de belos modelos.

    Portanto, a grande e grave deficiência do BABoK é o fato deste ignorar por completo este estudo, a análise e modelagem de negócios. Acho pouco provável que todo esse “chororô”, que não é só meu, gere alguma mudança significativa na versão 2.0 que está em vias de ser publicada. Resta torcer para que, ao contrário do que ocorre em outras instituições similares, eles não se apeguem de forma intransigente à estrutura atual daquele corpo de conhecimentos. Seria fatal.

    Outros Corpos

    Como eu disse lá em cima, foi uma semana bem agitada. Em nosso grupo de discussão, parcialmente restrito aos participantes de meus eventos, surgiu um conversa meio “subversiva”: elaborar o que o amigo Jefferson chamou de “BABoK Apócrifo”! Acho que (ainda) não é o caso, mas um fruto imediato aquela discussão toda já gerou: nascerá (muito) em breve um Fórum que tratará exclusivamente do BABoK e da profissão AN. Ao contrário do grupo, acho que o Fórum será público. Acho. A turma decidirá.

    : Acontece na próxima quinta-feira (24/abr), em Sampa, a 2ª edição da oficina Análise e Modelagem de Negócios. É um evento de um dia só, mas consigo mostrar nele tudo aquilo que, na minha opinião, foi ignorado no BABoK. Nesta página você tem uma visão geral do programa. É extenso e tem vários exercícios. Mas nada que a gente não consiga conversar em 1 dia.

    Referências:

    1. Software Requirements
      Karl Wiegers. Microsoft Press (1999).
    2. Já utilizei a EPBE no Rational Rose e no Visual Paradigm, além d’outras, menos fechadas. Para quem quiser experimentar, existem duas ferramentas “free” que oferecem a extensão: StarUML e JUDE. (Tks! Marcelo).

  • O BABoK e a Disciplina “Enterprise Analysis”

    O IIBA (International Institute of Business Analysis) liberou no último dia 31 de março a versão 2.0 do BABoK (Business Analysis Body of Knowledge) para revisão pública. O projeto da nova versão tem uns 6 meses de atraso. E eles descontaram nos revisores: temos só até o próximo dia 15 de maio para apresentarmos nossas sugestões / reclamações. Tática estranha, mas não percamos tempo com ela. Abri este post para fazer uma revisão pública de um único capítulo daquela publicação, o capítulo 4, que trata de uma área de conhecimento (Knowledge Area) chamada “Enterprise Analysis”. Ponto que questiono e critico desde a versão anterior do BABoK.

    Antes de descarregar minhas críticas preciso explicar rapidamente a estrutura deste BoK caçula. Ele é formado por 6 KA’s (Knowledge Areas, ou Disciplinas). São elas: i) Planejamento e Monitoramento da Análise de Negócios; ii) Gerenciamento e Comunicação de Requisitos; iii) Análise Corporativa; iv) Elicitação; v) Análise de Requisitos; e vi) Avaliação e Validação da Solução. Cada KA é formada por Tarefas, Técnicas, Entradas e Saídas.

    Tarefas são “peças essenciais do trabalho que deve ser executado na análise de negócio”. As técnicas descrevem “como as tarefas devem ser executadas em determinadas circunstâncias”. Momento ‘dã’: tarefas recebem entradas e geram saídas. ufs.. Mas, por favor, não me entendam mal: a estrutura do BABoK é legal, bem simples. Tanto que consegui explicá-la em dois mínimos parágrafos. Vamos então ao que interessa (neste artigo), a “estranha” KA chamada “Análise Corporativa”.

    O problema já começa no nome. Tiveram que inventar um substituto para “Análise de Negócio”, porque interpretam este nome como um grande guarda-chuva que incorpora outra macro-disciplina, a Engenharia de Requisitos. Tudo bem, há tempos aprendemos a conviver com nomes e definições confusas. Por falar em definição, “Enterprise Analysis” é apresentada da seguinte forma:

    A (disciplina) Análise Corporativa descreve como tratamos uma necessidade de negócio, como refinamos e esclarecemos aquela necessidade, e como definimos o escopo de uma solução viável. Aqui conversaremos sobre a definição e a análise do problema, o desenvolvimento do Business Case, de Estudos de Viabilidade e da definição do escopo da solução.

    Na introdução do capítulo 4 do BABoK, que trata especificamente desta disciplina, é apresentada uma definição mais formal e completa:

    A Área de Conhecimento Análise Corporativa consiste de uma coleção de tarefas para a análise da situação do negócio para a completa compreensão de seus problemas e oportunidades, além de uma avaliação das condições atuais e futuras com o intuito de identificar as mudanças necessárias para a satisfação das necessidades do negócio e seus objetivos estratégicos. As saídas geradas nesta disciplina fornecem a base necessária para o trabalho de elicitação, análise, validação e documentação de requisitos, e também para a identificação de uma solução para uma determinada iniciativa e / ou para o planejamento de longo prazo.

    Escopo da Enterprise AnalysisA definição é legal. Assim como o gráfico ao lado, que ‘explica’ a disciplina em uma apresentação oficial do IIBA. Mas reparem na definição acima e na lista de KA’s do primeiro parágrafo. Se temos lá uma KA chamada “Avaliação e Validação da Solução”, qual a razão da KA “Enterprise Analysis” tratar do desenvolvimento do Business Case e, mais ainda, da elaboração de estudos de viabilidade? Confunde, não?

    Claro, uma avaliação mais profunda das técnicas mostra que estamos falando de coisas diferentes. Para ser mais exato, de momentos diferentes! Então, como fruto de um trabalho notadamente departamentalizado, temos que o estudo de viabilidade não está no escopo da disciplina Avaliação e Validação da Solução. Tudo bem. Como eu já disse, estamos acostumados a conviver com definições confusas e dúbias.

    Em meu entedimento, o problema com a disciplina Análise Corporativa é outro, consideravelmente maior. Ela deveria incorporar aquilo que conhecemos como Análise e Modelagem de Negócios. Não é o que acontece. Veja abaixo a lista de tarefas que formam esta KA:

    1. Definir as necessidades do negócio;
    2. Determinar o gap entre as necessidades e a capacidade do negócio de atendê-las;
    3. Determinar o enfoque recomendado para a solução;
    4. Definir o escopo da solução; e
    5. Desenvolver o Business Case.

    Que estranho: em nenhum momento o Corpo de Conhecimentos da Análise de Negócios fala sobre “aprender o negócio”, “entender o negócio”. Já cai direto na “definição das necessidades do negócio”. Tamanha pressa é medo dos agilistas (muito citados no BoK)? Sigamos, agora sem ironias.

    Alguém pode dizer que está implícito na compreensão das necessidades de um negócio o aprendizado sobre o próprio negócio. Grave engano, e as estatísticas sobre projetos que falham são a maior prova que posso apresentar. Só consigo aprender realmente as necessidades (requisitos) de um negócio depois de conhecê-lo. Façamos uma breve (e covarde) analogia: você saberia dizer as necessidades de sua (seu) namorada(o) ou esposa(o) antes de conhecê-la(o)? Antes mesmo de manifestar suas intenções?

    Se eu não conheço um negócio, aquele domínio, como posso avaliar suas necessidades e oportunidades? Pior, como posso “definir o escopo de uma solução”? Vale aqui ressaltar que conhecer um negócio não se limita ao entendimento daquela entidade, mas compreender todo o seu ambiente, clientes, concorrentes, parceiros, legislação e um monte de etc.

    Por essas e (muitas) outras insisto que o BABoK pode criar uma terrível distorção do trabalho conhecido como Análise de Negócios. Como tempo e espaço ficaram curtos, deixarei para o próximo artigo a porção mais construtiva de minhas críticas.

    Mas, claro (!), sobrou um tempinho para convidá-lo a conhecer uma visão um pouco diferente da Análise de Negócios. Acontece no próximo dia 24/abr, em Sampa, a 2ª edição da oficina “Análise e Modelagem de Negócios”. Nela e em sua co-irmã, Engenharia de Requisitos, apresento as tarefas e técnicas que são utilizadas por um Analista de Negócios. Claro, contemplo todas as boas idéias sugeridas no BABoK. Mas, definitivamente, não o considero um “corpo fechado”. Por isso apresento vários adendos, inclusive o uso da UML para a modelagem de negócios.

    Merchan Parte II: quem participa dos eventos ganha uma versão digital de meu (adiado) livro (com garantia de atualização até a versão 1.0), alguns PPT’s e, o mais importante, acesso ao Grupo de Discussão AN.br. Já somos mais de 200. E no último mês batemos o recorde de mensagens trocadas. Está muito quente e rico. E a última iniciativa do grupo é o estudo conjunto do BABoK. No meio de nosso “toró de parpites”, já pintou até a sugestão de elaboração de um “BABoK Apócrifo”. Pode? Claro que pode! Inté!

  • Repensando o Papel do Analista de Negócios

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

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

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

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

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

    7. AN’s reduzem o feedback
      pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers , um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
    8. AN’s reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
      pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue “tirar o pé da jaca”. Ou, colocando d’uma forma menos agressiva: “não tira o boné de jeito nenhum”. Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN’s. E aprender muito com os bons AN’s.
    .:.

    Notas:

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

    .:.

  • Hot Commodity

    Hot Commodity! Jeito legal de dizer que a profissão “Analista de Negócios” está em alta. Foi assim que a revista CIO da Alemanha apresentou o AN, em artigo do último dia 16/ago. Em novembro, também na Europa (Barcelona), acontece o “Project World & World Congress for Business Analysts“. Em 9 meses, o IIBA conseguiu certificar pouco mais de 70 profissionais. Um neozelandês, o resto dos EUA e Canadá. Ou seja, é tudo muito novo.

    Ao mesmo tempo em que é tudo muito velho. A função existe há muito tempo, com nomes e responsabilidades um pouco diferentes, mas nova ela não é. Pode ser vista como uma releitura dos saudosos “Analistas de Organizações, Métodos e Sistemas”, uma profissão que ficou esquecida depois da ‘ascensão’ dos “Analistas de Sistemas” (AS). Veio a inevitável ‘queda’ dos AS’s, vieram os métodos ágeis e muito mais água debaixo da mesmíssima ponte, até que (re)descobrimos a importância desse cara que, na maioria das vezes, é apresentado como uma “ponte entre todos os stakeholders“. No artigo da CIO o job description é o seguinte:

    “O AN é uma ponte entre o negócio e TI, trabalhando em ambos os lados para propor mudanças em processos e sistemas, visando satisfazer as necessidades do negócio.”

    Definição meio perigosa, já que pode levar à falsa impressão de que um AN é um tipo de tradutor; que suas funções são um tipo de retrabalho; um passo ou uma fase adicional no processo de desenvolvimento. Enfim, um custo ou, pior ainda, um desperdício.

    Em meu trabalho, logo no primeiro capítulo, reforço que um AN passivo não é um AN de verdade. Vira quase um “garoto de recados”. A razão para o rótulo “hot commodity” ficou, de certa forma, implícita na descrição acima: “trabalhando em ambos os lados para propor mudanças em processos e sistemas”. O ponto de vista de um AN é super-privilegiado. Ao navegar entre TI e o negócio, ele pode desenvolver uma perspectiva única, caríssima para qualquer empresa que fale seriamente sobre “alinhamento estratégico”.

    Há dois dias estive em um dos maiores bancos brasileiros. Eles têm quase 150 AN’s, alocados em um departamento independente. Seu esforço: fazer com que os AN’s compreendam e assumam sua responsabilidade estratégica.

    Não tem nada a ver com o banco, mas é por essa e outras que reafirmo: o BABOK, mesmo com as alterações previstas para a versão 2.0, está um tanto distante do alvo correto. Sua ênfase em documentação, no desenvolvimento e gestão de requisitos, cria uma visão um tanto equivocada das responsabilidades dos AN’s. Oportunamente, e com uma maior freqüência, espero explorar melhor o tema por aqui.

    Por enquanto vale o registro da tendência: AN é um hot job. Resta torcer para que ele não seja recebido como um ‘salvador da pátria’; que sua certificação não se torne uma indústria com fim em si mesma; que os livros e cursos não mirem exclusivamente as provas de certificação; que os AN’s, fortalecidos, não tentem se fechar em “Escritórios de Análise de Negócios”… Enfim, que o AN aprenda com os erros dos outros.

    .:.

    Momento “Oportunista, eu?”

    A próxima turma do workshop “Formação de Analistas de Negócios” acontece no distante 27/set. Quem se inscrever até a próxima sexta, 31/ago, receberá 50% de desconto. Quem se inscrever e falar comigo antes receberá a versão eletrônica da apostila e um passe para o grupo de discussão exclusivo. A próxima versão da apostila, 0.7, será disponibilizada para os participantes das turmas anteriores no dia 20/set. Será a primeira versão com a formatação mais próxima da versão final do livro. Aliás, já está acertado que o livro será lançado em 27/Março/2008.

    Até lá, melhor dizendo, até dezembro, é tratar de amadurecer e enriquecer o texto. Daí os workshops e o grupo de discussão. Daí que, logo, serão lançados os treinamentos. Espero falar sobre eles muito em breve.

    .:.

  • O Giro em Falso das Rodas Reinventadas

    Há quem ache que a síndrome NIH (Not Invented Here) é uma exclusividade dos desenvolvedores. Não é. Parece que toda a nossa área adora reinventar rodas, eixos e padrões. O tempo todo.

    Foto de Tom@HK.

    Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; “oceanos azuis” e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM… Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a “reinvenção”) são ainda mais perigosas.

    Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

    O BABoK é novo. A versão que estou utilizando é apresentada como um “draft 1.6”, de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como “CMM” em algumas poucas referências. No corpo do “corpo” ele é sumariamente ignorado.

    Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

    Mas os “agilistas” não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que “em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo”. Não há quase nada além disso.

    Acho que nem preciso dizer que “gestão do conhecimento” e “aprendizagem organizacional” também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas ‘levemente acopladas’. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables – toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de “guia de referência rápida”. Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada “integração” ou algo do tipo.

    Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um “Corpo de Conhecimentos da Análise de Negócios”. A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

    .:.

  • O Analista de Negócios e o tal BABoK

    Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, “o analista de negócios não existe. Particularmente aqui no Brasil”. Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

    O IIBA segue os passos do PMI. Ou seja, lança um ‘guia para o corpo de conhecimentos’ e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
    .

    .:.


    Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

    “Enterprise Analysis”, segundo capítulo do BABoK, é descrita como “uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução “.

    Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham “momentos”, independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

    Quero crer que, com a demanda gerada pelas ‘ondas’ BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

    .:.

    Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

    .:.