PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Modelagem de Negócios

  • Obrigado pela Informação que Você NÃO me Deu!

    Subtítulo: Relevância, Concisão e Simplicidade na Comunicação Empresarial

    Autor: Normann Kestenbaum, pós-graduado em administração de empresas pela FGV. Sócio da Baumon, onde presta consultoria para grandes empresas.

    Editora: Elsevier / Campus (2008).

    Do que se trata: Comunicação empresarial. No popular, um pequeno (108 páginas) grande guia para todo tipo de conversa que rola em uma organização.

    A quem se destina: Todo mundo. Claro, todo mundo que conviva de alguma forma em empresas e outros tipos de organizações.

    Dê de presente para:

    • Líderes e gerentes de projetos
    • Analistas de Negócios
    • Analistas de Sistemas
    • Todos os chatos que não conseguem transmitir uma simples ideia em 5 minutos ou linhas
    • CIO’s, gerentes e afins

    Contra-indicações: Nenhuma.

    Prós:

    • Texto leve e agradável.
    • Coerente – Conciso e objetivo.
    • Bem fundamentado, apesar da curta bibliografia (apenas 9 títulos citados).

    Contras:

    • Como em praticamente todo título nacional, falta um índice remissivo.
    • E alguns gráficos são muito ruins. Mereciam melhor trato.

    Um trecho (escolhido aleatoriamente entre aqueles que destaquei com um marca-textos):

    Outro ponto sobre a concisão que merece comentários é a percepção errônea de que apresentação é a parte mais importante de um encontrou ou o único elemento importante a preenchê-lo. Muitas vezes uma pessoa tem 30 minutos para fazer uma exibição, ocupa integralmente esse tempo e é obrigada a ir embora porque seu tempo expirou. E o que pensa o lado de lá? Quais são suas sugestões e contribuições? Para mim, é na troca de idéias que o encontro acontece de fato. Portanto a regra é ser o mais breve e objetivo possível na apresentação, de forma a deixar o máximo de espaço de tempo possível para uma saudável troca de ideías e opiniões.

    Uma citação:

    É importante ter distanciamento para olhar o jogo inteiro, uma visão panorâmica que permita traçar estratégias. Poucos conseguem virar esta chave.
    Garry Kasparov, ex-campeão mundial de xadrez.

    Uma piada:

    Kestenbaum surrupiou o trecho a seguir de uma matéria da Exame (jul/2005), que por sua vez surrupiou o tema de “Por Que as Pessoas de Negócios Falam como Idiotas” (apresentado abaixo). Trata-se de um exemplo de como não falar nada usando muitas palavras:

    Precisamos adotar as melhores práticas. Mas com foco no cliente? É claro! Sem isso perderíamos nossa vantagem competitiva, afetando o bottom line no longo prazo. Mas, se não nos alinharmos às stakeholders, vamos deixar de estar agregando valor ao negócio.

    Trilha de estudo para quem quer mergulhar no tema:

    1. Por Que as Pessoas de Negócios falam como Idiotas
      Brian Fugere, Chelsea Hardaway & Jon Warshawsky
      Editora BestSeller (2007).
    2. The Back of the Napkin – Solving Problems and Selling Ideas with Pictures
      Dan Roam
      Portfolio (2008).
      Extensão: blog Digital Roam
    3. Presentation Zen: Simple Ideas on Presentation Design and Delivery
      Garr Reynolds
      New Rider Press (2008).
      Extensão: blog Presentation Zen

    Prováveis extensões da trilha (ainda não lidas / testadas):

    • Blink – A Decisão num Piscar de Olhos
      Malcolm Gladwell
      Rocco (2005).
    • Confessions of a Public Speaker
      Scott Berkun
      O’Reilly (2009).
      Extensão: blog do autor.

    .:.

    Observações:

    • Como prometido, inicio aqui uma série de artigos sobre Biblioteca Básica e Trilhas de Estudos. Prometo a publicação de pelo menos uma trilha por mês.
    • Os títulos citados na trilha ou como prováveis extensões merecerão artigos específicos. Só não seguirei uma ordem pré-fixada para não tornar a série muito chata ou repetitiva.
    • As trilhas não são estáticas nem se pretendem fechadas. Qualquer sugestão será muito bem vinda. A única coisa que garanto é que só vou recomendar títulos que eu tenha lido e, quando for o caso, testado.

  • Eventos: Os Novos e o Velho

    Direto ao ponto: estão liberadas as inscrições para 3 eventos em São Paulo, dois novos e o velho conhecido FAN.

    O Jogo dos 7 Erros para Líderes de Projetos é um dos novos. É uma oficina (workshop) com duração de um dia e formato um pouco diferente. Brincamos com o velho jogo dos 7 erros – aquele onde devemos descobrir diferenças entre duas imagens. Na oficina cada erro aparecerá em uma situação diferente. E cada situação tratará de um tema desafiador e recorrente na vida dos líderes e gerentes de projetos.

    É um jogo mas está longe de ser brincadeira de criança. Os exercícios, elaborados individualmente, são de médio ou alto graus de dificuldade. E são baseados em situações reais. Cada situação terá duração de uma hora e será encerrada com um bate-papo entre os participantes.

    A outra novidade tem o mesmo formato: O Jogo dos 7 Erros para Analistas de Negócios. Não é requerida participação no FAN. Mas é desejável que os participantes tenham experiência em Análise de Negócios.

    Os dois jogos estão sendo lançados em caráter “Beta”. Ou seja, trata-se de um teste realmente. Daí o precinho especial (R$ 199 para clientes da Tempo Real Eventos e R$ 249 para estreantes). Além disso, cada evento contará com a presença de 5 convidados especiais. Na linha de uma famosa revista de informática, talvez estejamos inventando uma nova profissão: Crítico de Oficinas! Será esta a função dos convidados. Se você se interessou pelo desafio, tente sua estréia aqui, deixando um comentário crítico / criativo sobre os novos eventos. Se for aprovado, a vaga é sua.

    .:.

    E o velho FAN dá as caras novamente, rumo ao seu 3º ano de vida. Será a 18ª turma em São Paulo – com certeza um dos recordes da Tempo Real Eventos. Legal que se trate de um velho (na nossa área 3 anos pode ser muito tempo) que ainda está sabendo envelhecer. Esta turma marcará a estréia da versão 1.1 do programa. Em  números absolutos, trata-se da 4ª versão diferente desta oficina de 14 horas.

    Aliás, vale lembrar que é o mesmo evento que será apresentado pela primeira vez em Brasília, nos dias 9 e 10 de abril.

    Críticas, dúvidas ou sugestões podem ser colocadas aqui mesmo, na forma de comentários. Ou através do email: [email protected]

    Desde já agradeço. Inté!

  • Prioridades 2: As Origens

    Sequência do papo sobre “Prioridades & Banalidades“.

    Se uma organização não sabe o que quer e não tem a mínima noção do caminho que pretende trilhar, então não podemos esperar que a equipe de projeto saiba dizer o que é prioritário em seu trabalho. Os ventos mudarão diariamente e o barco vagará a esmo. Até afundar, que é o que costuma acontecer com muitos projetos, particularmente de TI.

    Nas turmas do FAN eu costumo recomendar o seguinte: se a estratégia, se o valor do projeto não está claro para clientes, patrocinadores e usuários, então é melhor nem começar o trabalho. Se não atacar o quanto antes as dúvidas e ambiguidades, que provavelmente são fruto de sérios problemas de comunicação, a equipe estará assimilando riscos que dificilmente terá condições de administrar quando o projeto ganhar ritmo.

    Mas é curioso que até em empresas que apresentam um processo de planejamento aparentemente robusto as equipes tenham dificuldade de definir suas prioridades. Em dado momento as organizações elaboram e refinam seu portfólio de projetos. Em algumas o horizonte é de um ano ou mais. É a estratégia da empresa, sua Visão, que norteia o processo e ajuda a definir os projetos prioritários. Seria de se esperar que as mesmas informações que guiaram esta tomada de decisão sejam utilizadas pela equipe de projeto. Surpreendentemente, não é o que acontece em diversas organizações.

    Em algumas há a definição de que esse tipo de informação é sensível e merece sigilo. O que desemboca no engano de achar que uma equipe não precisa saber o que o negócio ganhará com o projeto. Pode parecer absurdo, mas já vi clientes e usuários urrando: “Você não precisa saber disso!”. Como não? Quem pensa assim ignora que os desenvolvedores tomam dezenas ou até centenas de decisões por dia. Decisões que afetam o negócio de uma forma ou de outra.

    Em outras organizações – que interpretam de maneira diferente o mantra “Informação é Poder” – os problemas com a definição de prioridades são outros. A equipe não é municiada com requisitos do negócio simplesmente porque não pergunta por eles. São diversos os fatores que ajudaram a criar essa alienação. Um dos principais, desconfio, é a mentira que diz que “tudo é para ontem”. E, se a pressa é grande, por que cargas d’água um analista perderia tempo tentando entender as motivações do projeto? Eles vão direto ao que interessa, aos requisitos que brotam e lotam listas. O problema é que esses requisitos, desprovidos de sentido, dizem muito pouco sobre o caminho que a empresa espera tomar. E fica simplesmente impossível que a equipe saiba dizer o que é prioritário.

    Sabe o que é estranho e paradoxal nessa lenga-lenga toda? É que normalmente o entendimento dos objetivos do negócio não rouba nem 30 minutos de um analista de negócios. O não entendimento costuma roubar muito mais.

    .:.

    Novamente surrupio uma foto da Tanakawho, “Indecision at the last moment“. O surrupio é legal!

  • Prioridades & Banalidades

    É curiosa e perigosa uma dificuldade que vejo por aí com uma certa frequência: Equipes de projetos não sabem ou não conseguem dizer o que é prioritário. O escopo de projetos de software é tratado como um monolito. E a iniciativa vira um jogo de 8 ou 80 – de tudo ou nada. Segundo analistas e desenvolvedores, seriam os usuários os principais responsáveis pela falta de flexibilidade. Algo como: “se eu estou pedindo, então é prioritário”. Todos os requisitos¹ são recebidos e tratados como iguais. É difícil que algum tipo de projeto possa evoluir bem com tamanha rigidez.

    A situação é curiosa porque não reflete nosso comportamento cotidiano. É natural que as pessoas considerem opções e definam prioridades quando vão fazer qualquer aquisição que comprometa uma fatia de seu orçamento. Pense na compra de um carro novo, por exemplo. Você define o que é fundamental, como marca, modelo, potência e cor. Elege itens importantes como o trio elétrico, tipo de combustível, airbag etc. Por fim, lista os opcionais que você só comprará caso o bolso permita, como o MP3 player com entrada USB, DVD para as crianças etc.

    Software é muito maleável. Qual o motivo, então, para tratá-lo de forma tão inflexível? Desconfio que a culpa não seja só dos usuários. Aliás, desconfio que eles não tenham culpa nenhuma nesta questão. Não na maioria das vezes.

    Quando utilizamos um processo que prevê a “coleta” (sic²) de todos os requisitos nos momentos iniciais do projeto, implicitamente estamos dizendo para os usuários: “fale agora ou cale-se para sempre”. Parece natural que os usuários tentem se lembrar de tudo. Que eles tentem entuchar de *tudo* naquilo que chamamos de escopo. Assim como é natural a reciprocidade. Ou seja, se eles só tiveram uma chance para falar, também darão apenas uma chance para a equipe entregar *tudo* o que eles pediram. Mas, apesar de ser irritantemente comum, o sintoma acima foi apresentado de maneira simplista porque explica apenas uma parte do problema.

    Muitos analistas e desenvolvedores se comportam como “tiradores de pedidos”. Vão conversar com os usuários e se limitam a registrar, vírgula por vírgula, *tudo* o que eles pedem. Se desconhecem o negócio, seus objetivos e o problema em questão, os analistas não apresentam condições de criticar o que está sendo pedido. Acontece que em algumas empresas os analistas não têm o direito de criticar. Será que um dia eles serão cobrados por terem o dever de criticar?

    A visão crítica e criativa aplicada ali, no nascedouro dos requisitos, é que permite uma priorização realmente eficaz. E esta visão só existe quando há um bom entendimento do negócio.

    .:.

    Como o papo é longo e anteontem eu prometi artigos mais curtos (e frequentes), o papo seguirá em posts futuros. Inté!

    Observações

    1. Caso seja de sua preferência, leia “histórias” (ou User Stories) onde escrevi “requisitos”.
    2. O termo “coleta” é muito ruim. Dá a impressão de que os requisitos estão lá, prontinhos e maduros, como tangerinas no pé. Na realidade nós *aprendemos e desenvolvemos* requisitos, sempre com os usuários.
    3. A imagem utilizada, Arch, é da Tanakawho – talento que libera suas obras no Flickr com licença Creative Commons.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!

  • 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?

  • Modelagem de Negócios: Uma Sugestão

    Finalmente a prometida sequência de “Modelagem de Negócios: A Encruzilhada“. Justifico a demora: passei os últimos meses envolvido em serviços de treinamento e consultoria para 3 grandes empresas. Nelas tive a oportunidade de experimentar e validar a sugestão que apresento neste artigo. Trata-se de um teste ao qual são submetidos todos os métodos e práticas que formam o programa FAN: a aplicação real, em empresas e projetos de verdade.

    Encerrei o último artigo prometendo um ‘remix’ do método proposto por Dan Roam em “The Back of the Napkin” com a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para a modelagem de negócios. Essa é a sugestão apresentada neste artigo.

    .:.

    A principal ferramenta do método proposto por Dan Roam é a sequência de 6 perguntas conhecida como “6 W’s”. As questões são: Quem / O quê (who/what); Quanto (how much); Onde (where); Quando (when); Como (how) e por quê (why). Como vimos no artigo anterior, há um tipo de desenho mais indicado para cada pergunta.

    A modelagem de negócios compreende a elaboração de visões. Cada visão é formada por um conjunto de diagramas. Há sempre uma visão mais indicada, dependendo do objeto que está sendo modelado / analisado. No trabalho que lançou a EPBE, “Business Modeling with UML”, são apresentadas 4 visões: do Negócio, da Estrutura, dos Processos e do Comportamento. Hans-Erik Eriksson e Magnus Penker, os autores, lembram que podem ser criadas outras visões, dependendo da necessidade do analista e do projeto. As visões Econômica, de Sistemas de Informação e de Recursos Humanos são alguns exemplos.

    Visões

    Foi necessário um pequeno (mas sensível) ajuste na ordem das perguntas sugerida por Roam. Todo projeto ou estudo deve começar com o entendimento da motivação do negócio. Ou seja, “por quê?” não é a última e sim a primeira questão. Claro, ela também pode ser executada no final do ciclo. Serviria assim como um tipo de teste, uma validação dos trabalhos de modelagem e análise do negócio. A resposta para o “por quê” determina aquilo que na EPBE chamamos de Visão do Negócio. Trata-se da apresentação dos requisitos do negócio que, dependendo do projeto, podem incluir a transcrição da Missão e Visão – seus mais altos objetivos.

    As três primeiras perguntas de Roam – “Quem / O Quê”, “Quanto” e “Onde” – nos levam a construir a Visão da Estrutura. Vale lembrar que essa visão trata de todos os recursos que pertencem ao negócio ou que se relacionam com ele de alguma maneira. Estamos falando de recursos físicos (instalações, máquinas, veículos, computadores etc), humanos (colabodoradores, clientes, parceiros etc), de informação (sistemas, bancos de dados, documentos etc) além de outros não menos relevantes como produtos, serviços, concorrentes etc.

    Por fim, as duas questões  que fecham os “6 W’s”: “Quando” e “Como”. Suas respostas geram os modelos que formam a terceira perspectiva, a Visão dos Processos. Dan Roam, mesmo num contexto que é muito diferente da modelagem de negócios ‘pura’, avisa que a resposta para o “como” é a mais difícil. De certa forma ela consolida e valida tudo o que foi respondido anteriormente.

    Cabe aqui uma comparação com um tipo de modelagem mais conhecido pela maioria dos leitores do finito. A modelagem de sistemas envolve a construção de diagramas que representem dois aspectos: estrutural (diagrama de classes, por exemplo) e dinâmico (diagrama de sequência, por exemplo). Neste ponto a modelagem de negócios é idêntica. Também temos a visão da estrutura e da dinâmica (processos). A grande diferença é a existência de uma visão maior, a Visão do Negócio, que deve justificar e dar sentido para todas as outras.

    Outra observação sobre o diagrama acima: as interseções existem de fato. Há diagramas que ultrapassam as fronteiras de uma visão. O diagrama de linhas de montagem, por exemplo, combina recursos (as linhas, que podem representar sistemas de informação) que pertencem à Visão da Estrutura, com processos de negócio. A UML, de uma maneira geral, facilita a criação desses cruzamentos.

    SQVID

    Outra ferramenta apresentada em “The Back of the Napkin” é o SQVID, um seletor que nos ajuda a configurar um diagrama. Cada letra representa uma decisão que o analista deve tomar antes de começar o desenho. A lista abaixo apresenta as alternativas:

    • imples ou Elaborado: o diagrama deve ser simples ou mais completo, mais elaborado. Dan Roam lembra que o oposto de simples não precisa ser complexo.
    • ualitativo ou Quantitativo: o que é mais importante para aquele determinado diagrama, os aspectos qualitativos (e, de certa forma, subjetivos) ou quantitativos?
    • isão ou Execução: mostraremos apenas o destino (a Visão) ou é importante que o diagrama mostre como chegamos / chegaremos lá (a Execução)?
    • ndividual ou Comparativo: o diagrama tratará apenas um item ou todo o conjunto?
    • elta (Mudança – to-be) ou Como é (as-is): por fim, o diagrama mostrará o estado futuro daquilo que estamos modelando ou seu estado atual?

    Uma curiosidade sobre o SQVID. Segundo Dan Roam, sua configuração default (que forma a sigla) nos levaria a utilizar o lado direito do cérebro – ou seja, aquele que é mais “quente”, abstrato, visionário e emocional. Consequentemente, a outra configuração do seletor forçaria um raciocínio mais “frio”, objetivo, analítico, quantitativo e orientado à execução – características do lado esquerdo do cérebro. Como eu já disse no artigo anterior, Roam ampara suas sugestões em estudos da neurobiologia. Me limito a afirmar que o seletor SQVID é de uma utilidade impressionante. Ele deve ser configurado antes que uma linha seja traçada. Desta forma o analista fixa os objetivos daquele modelo, levando em consideração o perfil das pessoas que farão uso dele e o tipo de problema que pretende entender ou resolver.

    Relembrando: cada uma daquelas 6 perguntas apresentadas anteriormente nos leva a elaborar um ou mais diagramas. O SQVID nos ajuda e configurar um diagrama ou a selecionar um determinado tipo de diagrama. Cruzando essas duas variáveis geramos uma matriz, o Visual Thinking Codex, que foi apresentado no artigo anterior. Fazendo uma ‘conta de padaria’, podemos dizer que teríamos 60 tipos de diagramas diferentes (6 perguntas X 5 seletores X 2 alternativas). Não precisamos de tanto, mas o número de diagramas à nossa disposição pode ser bem maior do que aquele proposto por Dan Roam, que fixa apenas um tipo para cada questão.

    .:.

    No próximo artigo, que não demorará outros 4 meses, apresentarei as sugestões de diagramas para cada pergunta e cada opção SQVID. Inté!

    Atualização: O artigo já foi publicado – “Modelagem de Negócios: Os Diagramas“.

    Nota:

    • A imagem utilizada no topo deste artigo, flikr0627, é do flikr ou Kelbv, fotógrafo profissional que também elabora criativos desenhos (diagramas?). A variação 0627 acima foi escolhida por um simples motivo: olhares atentos perceberão 2 pessoas no centro do desenho, um AN atendendo seu cliente. Duvida? Então olhe a imagem de novo. Ou veja o destaque no Flickr.

  • Modelagem de Negócios: A Encruzilhada

    Se não vai no atacado, vai no varejo mesmo!1 Há tempos ameaço retomar a publicação de artigos técnicos aqui no finito. Tardei. Espero não falhar.

    Já comentei por aqui: a modelagem de negócios é, entre todas as disciplinas que dão forma para a engenharia de software, a menos compreendida. Consequentemente é pouco e mal utilizada. No entanto, surgem evidências e suspeitas de que esta situação deve mudar. Iniciativas SOA, BPM e de Arquitetura Corporativa, em níveis diferentes, exigem a existência ou a criação de modelos de negócios. Mas não se trata de outra demanda ‘falsa’, parida exclusivamente nos domínios de TI. O pessoal do mundo do negócio também começou a perceber os benefícios de bons modelos de negócios. O que nos traz para a encruzilhada do título. Neste artigo vou apresentar duas alternativas de modelagem, uma bem TI e outra bem “negócio”. Ambas foram apresentadas em livros lançados recentemente. E indicam um momento crítico para a evolução da disciplina.

    Encruzilhada

    Modelando Negócios, segundo TI

    Acabou de sair, pela Morgan Kaufmann/OMG (Object Management Group), o livro “Business Modeling – A Practical Guide to Realizing Business Value“, de David M. Bridgeland e Ron Zahavi. Como obras que tratam exclusivamente a modelagem de negócios ainda são raríssimas, este lançamento merece destaque. E vai receber. Repare, não se trata de um livro sobre BPM e afins. O papo aqui é apenas sobre modelagem. Os autores, otimistas, começam mostrando que a tendência é de uma crescente adoção da disciplina. E apostam que por volta de 2011 ela atingirá “massa crítica”2. Justificam suas apostas de forma simples: “a Modelagem de Negócios se tornou mais popular porque transformações em negócios se tornaram mais comuns“. E explicam que “modelos ajudam na implementação de mudanças. Se nada muda, você não precisa de modelos, assim como não precisa de mapas se não pretende viajar para lugar nenhum“.Business Modeling

    Os autores mostram que a modelagem pode gerar valor para o negócio de oito maneiras: i) Comunicação entre pessoas; ii) Treinamento e Aprendizado; iii) Persuasão e Vendas; iv) Análise de alguma situação do negócio; v) Gestão de Conformidade; vi) Desenvolvimento de Requisitos de Software; vii) Execução direta dos modelos através de mecanismos de software; e viii) Gestão do Conhecimento e Reuso.

    A lista, apesar de extensa, me parece incompleta. Neste ponto os autores não citaram a possibilidade de simulação e experimentação de novas ideias e a identificação de oportunidades de outsourcing de processos (BPO), por exemplo. Mas as omissões são relativamente pequenas. O que me preocupa de verdade são as sugestões apresentadas no livro.

    Bridgeland e Zahavi partem do princípio de que não há um padrão completo para a modelagem de negócios. E não deixam de reclamar em diversos momentos do texto a total ausência de ferramentas que contemplem uma “completa” modelagem. Eles apresentam a modelagem como um conjunto de 4 disciplinas: Modelagem da Motivação do Negócio, da Organização, dos Processos e das Regras. Completo, na visão deles, seria um padrão que possibilitasse a criação de modelos das 4 disciplinas. Eu acredito que o problema foi criado pelos próprios autores, no “quebra-cabeças” de padrões que eles selecionaram.

    Para a modelagem da motivação do negócio eles optaram por um novíssimo e único padrão existente, o BMM (Business Motivation Model), um trabalho do BRG (Business Rules Group) aceito pelo OMG em agosto de 2008. Como os próprios autores acusam, o OMG cometeu grave pecado ao aceitar e liberar o padrão antes de definir seu perfil visual – um padrão para os diagramas. O BMM cuida da visão (fim) e da missão (meios) de um negócio, de maneira abrangente e consistente. Mas parece uma ilha isolada do resto do mundo. Não se relaciona com nenhum padrão existente. Talvez o OMG tente incorporá-lo futuramente a algum metamodelo. No entanto, quando o assunto é o OMG e seus constituintes, tudo é incerto.

    Há tempos eu joguei todas as minhas fichas na EPBE (Eriksson-Penker Business Extensions). E sempre reconheci que a forma como essa extensão trata dos objetivos (motivações) do negócio é fraca. Por isso apresento mapas estratégicos e BSC’s (Balanced Scorecards) como complementos. Como a EPBE é extensível como sua base, a UML, não tive nenhuma dificuldade em incorporar a ela o BMM. Oportunamente eu falo mais sobre BMM e EPBE. Mas se você não aguenta de curiosidade, relembre aqui o metamodelo EPBE e obtenha aqui uma visão geral (bem alto nível) do BMM.

    O problema dos autores aumenta quando eles entram em sua segunda disciplina, a Modelagem da Organização. Eles afimam que não haveria um padrão para a construção desses modelos. Quem diria, nossos velhos e bons organogramas carecem de um padrão. Mas a questão não é só essa. Bridgeland e Zahavi ignoram outros recursos, outros elementos da estrutura de um negócio. Não citam, por exemplo, a necessidade de modelagem de produtos, serviços etc. A EPBE fala em Visão da Estrutura, não de Modelagem da Organização. A EPBE contempla, portanto, a modelagem de qualquer tipo de recurso.

    É fácil entender a omissão ao vermos o padrão que eles selecionaram para a Modelagem de Processos. Sim, eles optaram pela BPMN. Um padrão cheio de promessas e com um futuro promissor, mas que entrega muito pouco quando o assunto é *Modelagem de Negócios*.Sigo aguardando ansioso pelo dia em que uma boa alma apareça dizendo: “gente, BPMN é só um fluxograma 3.0 – um falso padrão3 sacaneado por ilustres fornecedores que deveriam defendê-lo. Um falso padrão que tem pouco ou nenhum valor quando nossa preocupação é entender um negócio“.

    Os autores justificam sua não opção pela UML dizendo que esta é muito ‘complicada’ para usuários finais. Concordo. Mas, apesar deles citarem o trabalho de Eriksson e Penker, “Business Modeling with UML“, ignoram por completo a EPBE. Ao relacionarem UML exclusivamente com o diagrama de atividades, demonstram desconhecer todas as outras opções de diagramas apresentadas no trabalho da dupla escandinava. Sigo desconfiado de que é este pequeno detalhe geográfico que segue fazendo da EPBE uma ilustre desconhecida.

    Problema dos autores, que tiveram que se revirar ainda mais no momento de fixar um padrão para sua última disciplina, a Modelagem de Regras. Acertam na escolha do SBVR (Semantics of Business Vocabulary and Business Rules), outro padrão adotado pelo OMG em 2008. Mas não conseguem deixar de mostrar a fragilidade das ligações desta com as outras 3 disciplinas que formam sua proposta. Eles reclamam muito da deficiência de ferramentas. O buraco é mais embaixo: os 4 padrões sugeridos pelos autores carecem de um alicerce único, de um metamodelo. Ao jogarem todas as suas fichas em padrões do OMG, implicitamente os autores apostam que esta entidade será capaz de suprir essa imensa necessidade. Ao ver os probleminhas que o OMG tem enfrentado só com a BPMN 2.0, sou obrigado a ‘mineiramente’ desconfiar. Com seus passos de cágado, talvez lá em 2037 o OMG apresente uma bela sugestão de metamodelo para uma completa modelagem de negócios. Vamos esperar sentados?

    O Negócio pelo Negócio

    É um livro de modelagem?!?Aí vem aquele “velho” cara de negócios e pergunta: “meu caro, diz aí, o tal OMG entende de negócios?” Antes que uma resposta (ou desculpa) pinte em nossas cabeças, o velho saca de sua estante um estranho livro quadrado: “The Back of the Napkin“, de Dan Roam (Portfolio – 2008). O velho nos diz: “Parece que o tal do Dan aí entende de negócios, e presta serviços de consultoria para empresas como Google, eBay, GE, Wal-Mart…”

    Se o livro de Dan Roam usou o termo “modelagem” em algum momento passou despercebido. Ele prefere o termo “Pensamento Visual”. Mas seu livro é só sobre isso: Modelagem de Negócios. Saca só o subtítulo: “Resolvendo Problemas e Vendendo Ideias com Figuras”. Não espere ver nada sobre UML, BPMN e coisinhas afins. Dan é um cara de negócios. E, por isso mesmo, insiste que devemos fugir de ferramentas informatizadas: “mão, caneta e guardanapos são suficientes para resolvermos qualquer problema de negócio!” Radical? Não, prático e pragmático mesmo. E, preciso dizer, ágil!

    Dan apresenta uma metodologia completa, formada por 4 elementos. Ele a apresenta como um “canivete suiço”. Sua primeira parte é formada por “3 ferramentas básicas para o pensamento visual”: nossos olhos, mente e mãos. Na sequência ele apresenta as 4 fases do pensamento visual: Ver, Observar, Imaginar e Mostrar4.Aí vem o SQVID5, uma série de 5 perguntas que “nos ajuda a abrir os olhos da mente: simples ou elaborado, qualitativo ou quantitativo, visão ou execução, individual ou comparações, mudança ou ‘as-is’?” Por fim as 6 formas como enxergamos que também são as formas como deveríamos mostrar, os 6W’s: “Who/what, hoW much, Where, When, hoW e Why”. Parece bobinho, não? Se você não reparou, até a sequência como o “canivete” é apresentado é “simplificadora”: 3 (ferramentas básicas), 4 (passos), 5 (perguntas) e 6 (formas de ver/mostrar).

    Parece bobinho, mas Dan escora suas sugestões em bases muitos fortes, como pesquisas muito recentes no campo da neurobiologia. Os 6 W’s, por exemplo, realmente representam a sequência pela qual nossos olhos passam informações para o cérebro. Por isso seriam intuitivas, naturais. Logo no início do livro o autor se preocupa em “escorar” suas sugestões. Em três páginas quase consecutivas ele nos convida a visitar o apêndice A, “A Ciência do Pensamento Visual”. Justamente para derrubar nossas possíveis desconfianças e mostrar que, apesar de simples, suas propostas são sérias. Aliás, a simplicidade é uma grande qualidade de seu trabalho. Porém, mais que o alicerce científico, são os casos reais apresentados que atestam a utilidade e força de seu método.

    O ‘Codex’ do Pensamento VisualAcontece que, a primeira vista, as sugestões de Dan Roam parecem totalmente incompatíveis com a disciplina que conhecemos como Modelagem de Negócios. Em nenhum momento ele cita o OMG ou coisinhas mais ‘pop’, como BPMN. Trata-se realmente de outro mundo.

    O diagrama acima mostra do “CODEX” do Pensamento Visual, uma grade que cruza os 6 W’s com as 5 decisões que tomamos no SQVID. Repare que, para cada W, Dan sugere apenas um tipo de desenho: retrato para o “quem/o que”; gráfico de barras para o “quanto”; mapas para o “onde”; cronograma ou linha de tempo para o “quando”; fluxograma para o “como”; e um gráfico comparativo (plot) para o “porque”. O SQVID ajuda a definir uma versão diferente para cada tipo de desenho.A única sugestão de Dan que se aproxima minimamente de nosso mundo é o fluxograma. Todos os outros desenhos parecem distantes de tudo que conhecemos para a modelagem de negócios: retratos, mapas, gráficos de barras…

    Precisa ser assim? Digo, TI e negócio precisam ser tão distantes até nisso, numa disciplina que deveria ajudar um a compreender melhor o outro? O mundo de TI precisa seguir insistindo em padrões lentamente definidos e sistematicamente desrespeitados?

    Como a Modelagem de Negócios é uma disciplina ainda em fase de definição, acho que é hora de revermos alguns caminhos, particularmente aqueles trilhados pelo OMG e fornecedores de ferramentas como SAP, IBM e Oracle.

    Em paralelo, os Analistas de Negócios, principais usuários da Modelagem de Negócios, devem procurar uma base que combine o melhor dos dois mundos. No próximo artigo apresentarei uma sugestão, um ‘remix’ das ideias de Dan executado na vitrola da EPBE/UML. Inté!

    Notas:

    1. O “atacado” seria o livro, que já toca neste assunto (com outras palavras. Aliás, muito mais palavras e figuras). Mas, como eu já disse em um pequeno post-agenda, não se trata apenas de um livro, mas também de um novo negócio e um sistema. Adiei o lançamento para costurar melhor todas as partes. Conto com a compreensão e paciência de todos.
    2. Em dinâmica social, massa crítica é a mentalidade de um grupo que é suficiente para, em quantidade e qualidade, permitir, propiciar e sustentar determinada ação ou comportamento. (Wikipedia).
    3. Digo que BPMN é um falso padrão porque ele não é respeitado por quase ninguém. Grandes fornecedores, como IBM, Oracle e SAP, insistem em ter seu “sabor” do padrão. Claro, assim eles dificultam a debandada de clientes insatisfeitos. Nada de novo no front de TI: SQL, HTML, COBOL e várias outras coisinhas também nasceram um dia para serem “padrões”.
    4. Minha tradução livre para Look, See, Imagine e Show.
    5. SQVID é uma sigla estranha mas de fácil compreensão: Simple, Quality, Vision, Individual e Change (D é de delta, mudança). O SQVID é apresentado como um seletor ou equalizador. O nome indica as primeiras opções. O contraponto, na mesma sequência, é: Elaborate, Quantity, Execution, Comparison e As-is.  Como o gráfico acima ilustra, para cada um dos 6 W’s escolhemos um lado do SQVID. Simples ou Elaborado, por exemplo.

    A foto utilizada neste artigo é de Kevin Slavin (Flickr). Aliás, vale a pena olhar o curioso jogo “Crossroads” que ele montou com GPS, usando Manhatan como tabuleiro.

  • Um Roadmap para Analistas de Negócios

    Quem tem acompanhado nosso pequeno mas agitado Fórum deve ter reparado: ainda há muita indefinição em torno do currículo e do job description de um Analista de Negócios. Os últimos debates, particularmente com o Ronan Lúcio e o Leandro Mendonça, me deram uma grande ajuda em uma decisão: qual item deveria sair de meu backlog (de artigos e temas represados – haha) e vir para cá, para o blog. Há tempos adio esta publicação, com a falsa esperança de conseguir desenhar um mapa completo que mostre os caminhos para a Formação de um Analista de Negócios (AN). Passou da hora dessa discussão se tornar pública. Ao mapa (versão Beta):

    Um Roadmap para Analistas de Negócios

    Antes, os créditos: foi o André Wolff quem deu a sugestão de usar um desenho parecido com aqueles mapas que apareciam nos livros da Wrox. E algumas caixinhas acima só apareceram por causa de depoimentos (e desejos) dos colegas Leandro e Ronan.

    Talvez o meu rabisco não dê esta impressão, mas ainda há muito espaço a ser preenchido ali. Tentei destacar o fundamental, inclusive no tópico ‘Formação Complementar’. E, claro, não contemplo nenhum treinamento de ‘Habilidades Sociais’ (Soft Skills). O desenho trata exclusivamente de ‘Habilidades Técnicas’ (Hard Skills). Cabe uma breve descrição de cada caixinha:

    FAN – Entendendo o Negócio é o programa que ‘roda mundo’ há pouco mais de um ano. Sua versão ‘oficina’ (workshop – 7 horas) dá uma visão geral de tudo que está inserido no tema “Modelagem de Negócio”. O curso (35 horas) permite o detalhamento e prática de alguns temas, particularmente a modelagem de negócios com UML e sua extensão EPBE (Eriksson-Penker Business Extensions).

    A relativa complexidade da EPBE e, principalmente, da Modelagem de Negócios, justifica a existência de um módulo avançado, o FAN – Modelando Negócios com UML/EPBE. Imagino um curso 100% prático, com a modelagem de um negócio “inteiro”. Teria algo entre 32 e 40 horas. Imagino… teria… Sim, por enquanto este módulo é só uma idéia.

    FAN – Business Patterns  segue no mesmo caminho. Só o livro de Eriksson e Penker apresenta algumas dezenas de patterns. Debatê-las e praticá-las em um treinamento faz todo o sentido. O problema aqui é nosso nível de maturidade quando o assunto é modelagem de negócios. Ou seja, é idéia para a próxima Copa do Mundo. E olhe lá!

    Apesar de meu “apego” à EPBE, não posso ignorar a crescente demanda por profissionais que dominem a Modelagem de Processos de Negócios com BPMN. Não tenho condições de oferecer tal treinamento. Por isso este módulo não tem a marca “FAN”. É o mesmo caso do Modelagem com Aris/EPC.

    Destaquei dois módulos em Formação Complementar que estão diretamente relacionados com a Modelagem de Negócios: i) Balanced Scorecards & Mapas Estratégicos, ferramentas que enriquecem consideravelmente um modelo de negócios – facilitando o entendimento de objetivos, metas, oportunidades e problemas; e ii) BPM (Business Process Management), um universo em si. Tanto que, neste ponto, imagino apenas um treinamento de introdução ao BPM. Reparem, BPMN está em outro canto.

    Segurei a tentação de colocar caixinhas SOA e Arquitetura Corporativa aqui por dois motivos: estamos tratando da Formação de Analistas de Negócios. Lotar o módulo Formação Complementar pode gerar muita dispersão de atenção. Mantive o básico. Pelo menos, enquanto as duas áreas de cima não estiverem melhor resolvidas. Vamos então ao amplo e “polêmico” módulo Engenharia de Requisitos:

    FAN – Entendendo o Usuário também faz parte do programa que tenho apresentado. A oficina (7 horas) trata do básico, com ênfase no Desenvolvimento de Requisitos. O treinamento de 35 horas permite uma maior exploração de algumas técnicas, particularmente a especificação de casos de uso e a realização e facilitação de entrevistas, sessões JAD etc.

    Como temos visto no fórum, o tema ‘Casos de Uso’ é mais cabeludo e incompreendido do que imaginamos. Por isso ele merece um módulo adicional, Escrevendo Casos de Uso, que desenvolvo há 2 meses. Deve se transformar em um curso prático, de 40 horas. Isso tudo? Sim, pelo que descobri, o tema merece. Mas deve existir uma versão oficina (7 horas) também.

    E faz todo o sentido que o roadmap contemple também o módulo Escrevendo Users Stories. É uma alternativa aos casos de uso. Tenho lá minhas restrições, mas não posso ignorar sua adoção e eficácia em alguns projetos. Só não me habilito a formatar e oferecer tal treinamento.

    Assim como, por enquanto, me manterei relativamente distante do Gerenciamento de Requisitos. É importante destacar que quando falo Gerenciamento de Requisitos estou falando também de Gerenciamento de Mudanças.Coloquei aqui apenas dois módulos: No OpenUP e No Scrum. (Obs: “No” não está em inglês, ok?).

    Derivam deste último módulo duas sugestões para a formação complementar: Gerenciamento de Projetos e Scrum. Não é para o AN se bandear para o gerenciamento de projetos, please! Acontece que suas atividades se entrelaçam demais com aquelas de um gerente de projetos. É legal que ele conheça a disciplina de uma forma mais ampla.

    Por fim, abri um módulo que é meu “xodó” mais recente: uma oficina que exercite exclusivamente as diversas técnicas de descoberta, aprendizado e descrição de requisitos: Entrevistas, JAD, 6 Hats…  Xodó meu, não sei se há demanda. Quero crer que sim. É outro item de meu backlog que anda clamando por atenção. Sua aparição aqui pode dar o empurrão necessário.

    Aliás, a grande motivação para este post é exatamente essa: empurrões! Algumas definições & idéias! E, claro, uma deixa-provocação: será que alguém (alguma instituição) consegue oferecer todo esse roadmap como um programa único? Alguém aí quer tentar preencher as caixinhas não assinadas? E colocar novas caixinhas? É isso. Inté!