PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Sobre Conversas e Comunidades

    De todos os modelos de negócio que vi nos últimos anos, apenas um merece minha mão no fogo e meus suados centavos. Conheci sua versão consolidada através do blog Confused of Calcutta, de JP Rangaswami. Dada sua amplitude, talvez seja mais correto chamá-lo de metamodelo. É o seguinte:

    Gere conteúdo. Se ele for bom, conversas surgirão em torno dele. As conversas serão duradouras, se forem boas. Elas gerarão transações, se forem realmente boas.

    A simplicidade do modelo não deveria enganá-lo. Sua implementação não é nada fácil nem rápida. Mas não pense que é a geração de conteúdo a parte mais complicada. Apesar de alguns poucos preguiçosos que vivem de surrupiar material alheio sinalizarem o oposto, o fato é que criar conteúdo – ter assunto – é a etapa mais simples do modelo acima. Ainda mais numa área fervilhante e diversificada como a nossa.

    Difícil mesmo é iniciar e manter conversas. Mesmo que o assunto seja bom e promissor. E as razões para essa dificuldade são óbvias: conversas demandam tempo, e tempo é um recurso muito escasso atualmente; conversas requerem atenção, e como andamos distraídos e/ou sobrecarregados!

    A boa administração do que é escasso e do que é abundante é tema recorrente tanto do JP quanto de Seth Godin, outro provocador obrigatório. A lei existe desde que nos entendemos por gente: o que é escasso é obrigatoriamente mais caro. Então, por favor, valorize seu tempo! Valorize meu tempo! No bullshit!, diriam nossos amigos do norte.

    O programa FAN (Formação de Analistas de Negócios) foi desenhado de acordo com esse modelo. Eu não queria que as conversas terminassem depois das 7, 14 ou 20 horas de um evento. Cerca de 25% dos participantes também não. Por isso aceitaram participar de um grupo de discussão que tinha só essa grande missão: esticar o papo.

    Em 2 anos e 3 meses nós trocamos 4.166 mensagens. Hoje somos pouco mais de 500 participantes. Impossível mensurar o que aprendi e quanto enriqueci o conteúdo a partir dessas conversas. Só sei dizer que é muita, muita coisa. Também não sei dizer o quanto os outros integrantes do grupo ganharam. Mas quero desconfiar que não é pouco. Se fosse, já teriam abandonado o barco.

    O curioso dos grupos, de todos eles, é que a grande maioria dos integrantes é relativamente silenciosa. Quando provocados, costumam dizer “não sou muito ativo(a), mas gosto muito das discussões”. Confesso um certo incômodo com tamanha passividade, mas já desisti de achar uma forma de reduzi-la.

    O grupo sempre foi um diferencial do programa FAN. Até hoje ele era exclusivo para os participantes dos eventos promovidos por mim. E a razão da trava nunca foi comercial: eu queria apenas uma uniformidade de interesses e vocabulário. Essa homogeneidade não faz mais sentido e o grupo topou ser aberto para o público em geral.

    Portanto, se você aceitou esse lero-lero até aqui, talvez aceite também nosso convite para participar do AN.br, uma comunidade virtual que debate a Análise de Negócios, profissões correlatas, Modelagem de Negócios, Pensamento Visual, Engenharia de Requisitos e Viabilização de Projetos. Se for o caso, por favor, solicite sua inscrição através deste link, informando que recebeu o convite através do finito.

    E, já que estamos aqui, posso surrupiar mais 15 minutos de seu escasso tempo? É que estou fazendo uma pequena pesquisa sobre projetos e a Análise de Negócios no Brasil. São apenas 23 questões, a maioria demandando apenas um clique. Quem participar terá acesso integral ao resultado da pesquisa, além de concorrer aos seguintes prêmios: 3 vagas em eventos FAN e 5 agendas personalizadas (desenhadas especificamente para analistas de negócios e product owners). Para tanto, basta que você envie um email para [email protected], confirmando que respondeu ao questionário. Clique aqui para participar.

    É conversando que a gente se entende. E se estou com orelhas tão grandes, é só pra te escutar melhor. Inté!

    .:.

    A imagem utilizada, FOWA Sketch, é de KaiChanVong, e foi surrupiada legalmente, se é que você me entende.

  • No Fundo do Poço

    Quando vivemos em tempos de abundância de crises, é natural que algumas delas passem totalmente desapercebidas. Ponto minúsculo e silencioso no radar não chama atenção. Mas ele será lembrado quando o estrago já estiver feito. Há uma crise na relação entre empresas e seus fornecedores de serviços de desenvolvimento e manutenção de sistemas. É fato, esse relacionamento nunca foi harmonioso. Mas parece que estamos chegando no fundo do poço – naquele momento em que, mais do que debatida, a relação deveria ser totalmente revista.

    Tentarei ilustrar a situação com uma breve história.

    .:.

    Era uma vez uma empresa de médio para grande porte repleta de sistemas. Como é tradicional, a parte “feijão com arroz” do negócio (processos de apoio – financeiro, contábil, RH…) foi informatizada com um pacote ERP; A parte “filé com fritas” (processos primários – vendas, atendimento…) é um combinado de módulos desenvolvidos internamente com algumas soluções de terceiros. Antenada por necessidade, a empresa em questão, que chamaremos de ACME, já usa mas pouco abusa de conceitos modernos como SOA, BPM e BI.

    Assim como acontece em praticamente todas as organizações ao redor do globo, a “Arquitetura Corporativa” da ACME assemelha-se ao retrato do inferno devidamente registrado por uma câmera de 12 megapixels. Consequência natural de anos e anos de projetos “para ontem”, adoção de caixinhas mágicas, fornecedores famintos e voluntariosos e algumas pitadas de modismos. A receita pode variar um pouquinho de empresa para empresa, mas o prato parece ser sempre o mesmo. E é indigesto.

    A demanda por manutenção (80%) e novas aplicações (20%) é sempre maior que a capacidade instalada. Fornecedores devidamente homologados adoram essa parte. Afinal, “fábricas de software” (sic) foram inventadas para isso mesmo, certo?

    Software é um elemento vital para a ACME. Aliás, deve ser para 80% das empresas. Mas ele ainda não é visto como ativo, como conhecimento. Software é contabilizado como despesa. E é tratado como tal: um mal necessário. Então a ACME brinca de fazer de conta que mantém o cérebro e terceiriza membros, mais precisamente os braços. Traduzindo: uma equipe interna definiria o que precisa ser feito; o “como” e respectiva construção seriam executados por “parceiros”. (Há palavra mais maldita que essa em nosso mundo?)

    Acontece que o cérebro é pequeno e fica cada vez menor. Para cada neurônio disponível para “coletar requisitos” (sic), existem dezenas ou centenas de usuários putos da vida, atrasados, indecisos e com hora marcada no psicólogo. Quando muito, uma reunião(zinha) de 1 hora é tudo o que o neurônio tem para entender o que o usuário quer. Desse entendimento nasce um briefing. E dele extrai-se um “cheiro” que, como num passe de mágica, vira compromisso de prazo e custo. Tudo acontece tão rápido que o neurônio nem tem tempo de suspirar.

    Com um olho na fila de usuários que aguardam sua vez de choramingar requisitos, o neurônio repassa para o parceiro selecionado por um critério qualquer aquele conjunto de parágrafos desconexos apresentados anteriormente como briefing. Sim, a escassez de neurônios é tamanha que cabe ao parceiro “fechar o escopo” (sic). Com um pouco de insistência e um tanto de sorte o parceiro consegue um ou dois encontros com usuários para desenvolver “casos de uso”. O papo é menos belicoso que aquele entre usuários e neurônios porque o parceiro é “de fora”. Mas, talvez para mitigar riscos de rusgas, o parceiro sempre manda um analista diferente. O rodízio deve seguir a lógica do namoro de jogador de futebol. Mas os usuários já se cansaram de dizer que “eu já expliquei isso antes…”

    Tão logo o parceiro se manifeste satisfeito com as informações coletadas (implicitamente ele tá de saco cheio daquelas idas e vindas), tem início um hiato de duração indeterminada (apesar do cronograma assinado).

    É marcado para um belo dia (e precisa ser belo mesmo – porque, se ameaçar chover, o parceiro nem tira o carro da garagem) a apresentação do projeto. Dependendo da cara (e do bolso) do sponsor, o evento tem lá suas regalias. Na maior parte das vezes, é só um encontro do parceiro com alguns usuários e um cafezinho. O neurônio autor do briefing é convidado a participar. Claro, se ele ainda estiver na folha de pagamentos da ACME.

    O encontro é tenso. Já começa nervoso. E os usuários não colaboram com o clima: “Nossa, atrasou tanto desta vez, né?”

    Num caso específico a apresentação começou por uma parte bem complicada do projeto: uma tela de cadastro de clientes. O usuário do departamento de marketing mal esperou a tela acabar de ser “renderizada” (sic) e já reclamou: “Nossa logomarca sofreu pequenas alterações há 6 meses. Adequação para a nova realidade Web 2.0 e patati patatá…”. Foi interrompido. O parceiro falou que ninguém avisou. “Mas é uma pequena alteração besta…”, disse, tentando encerrar o assunto. Afinal, o importante era o conteúdo! O cara do marketing não concordou, mas silenciou.

    Para testar o conceito de usabilidade o parceiro pediu que um outro usuário, sem nenhum treinamento, fizesse o cadastro de um cliente. Claro, ele escolheu a menininha mais bonitinha que estava na sala. E quase pegou em sua mão para guiar o mouse na direção do botão “Incluir”. “Por que esse botão tem a cor diferente dos outros?”, questionou a bela. Não mereceu resposta, mas seguiu em sua nobre tarefa.

    Até que, após digitar nome, CPF e logradouro do namorado (para infelicidade do parceiro), se deparou com uma combo box onde ela deveria selecionar a Unidade da Federação. Clicou na setinha e viu uma lista mais ou menos assim: SP, BA, MG, RJ, DF, RS, SC, AC, RR, PA, MS, AM…

    Não se sabe quem disparou primeiro, se o neurônio, a bela ou o cara de marketing. Talvez tenha sido um coro: “Caramba, por que a lista não está ordenada?”

    O parceiro engoliu seco e sacou da mochila importada um calhamaço manchado e cheio de dobras que apresentava na capa a logomarca da ACME (desatualizada) e o nome do projeto. Passou pelas (33) páginas do caso de uso em questão – de trás para frente e de frente para trás – e cravou: “Não tá escrito aqui que a lista deveria ser ordenada. Isso é mudança de escopo!”

    .:.

    A história acima é uma ficção baseada em fatos reais. Só as trechos mais exagerados são verdadeiros.

    A foto utilizada, “Lift Shaft Within the Old Town Hall Tower”, foi devidamente surrupiada de lostajy. Ela foi liberada com licença Creative Commons.

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

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

  • FAN :: Os Novos Módulos do Programa

    O programa de Formação de Analistas de Negócios (FAN) nasceu para ser alicerce, fonte e processo de criação de meu primeiro livro. Seu inesperado sucesso1 fez com que ele ganhasse vida própria. Quando ele foi lançado ainda não era um programa. Era só uma imensa palestra com 7 horas de duração, erroneamente identificada como “workshop”. Críticas e sugestões de vários participantes levaram a criação de duas oficinas de verdade: Modelagem de Negócios e Engenharia de Requisitos. Desenvolvi versões com 14, 35 e 70 horas, configurando assim um programa para formação de AN’s. Dezoito meses e mais de 1200 participantes depois, chega a hora de rever o programa e propor novos caminhos. Incrementais, claro, porque os módulos atuais continuam valendo.

    Em agosto do ano passado eu publiquei aqui uma sugestão de roadmap para AN’s. Era ao mesmo tempo um plano e uma provocação. Poucas mas boas ideias foram apresentadas. Mas chega a ser curiosa a distância entre as alternativas fruto de um cutucão e as oportunidades / necessidades percebidas. Na primeira reunião pública do Capítulo SP do IIBA2 (International Institute of Business Analysis) muitos participantes cobraram reconhecimento da profissão / função. De certa forma ficou implícita na solicitação uma melhor definição do perfil, formação e responsabilidades dos AN’s. Algumas das threads mais longas e quentes de nosso grupo de discussões e fórum tratam exatamente deste ponto: quem é e o que faz um AN? Ao conversar com colaboradores de empresas dos mais diversos segmentos e portes, percebi as mesmas questões. E os mais diversos cenários.

    Há quem use o AN como se fosse um analista de sistemas, cobrando deste o domínio e desenho da solução. Em algumas empresas o AN parece guarda-costas ou válvula de escape do pessoal de suporte. Em outras é bode expiatório e sparring de usuários insatisfeitos e desenvolvedores idem. Para não dizer que tudo é negativo ou distorcido quando se trata de análise de negócios, vale ressaltar também que algumas organizações cobram de seus AN’s o que realmente deve ser cobrado: o entendimento do negócio e dos usuários e a comunicação desta compreensão para todas as partes interessadas de um projeto.

    Como ainda há muita desinformação e contrainformação quando o assunto é análise de negócios, resolvi editar uma 3ª versão daquele palestrão de 7 horas. Chamado “FAN Especial”, sua primeira turma está programada para a próxima quarta-feira, 11/fev, em São Paulo. Com ele tento matar 2 coelhinhos com a mesma cajadada:

    • Explicar para as empresas, particularmente gerentes de TI, gerentes de desenvolvimento e coordenadores de projetos: i) quem é o AN; ii) quais são suas responsabilidades na empresa e em projetos; e, iii) porque ele é importante, especialmente em projetos de software.
    • Apresentar a função / profissão para analistas (de negócios, de sistemas, de requisitos, de processos…) e debater: i) o corpo de conhecimentos “oficial” (BABoK); ii) modelagem de negócios e engenharia de requisitos; e, iii) como as empresas estão contratando e estruturando o trabalho do AN.

    Mas 7 horas são realmente necessárias? Sim, isso possibilitará um maior aprofundamento em todos os tópicos. Há também uma generosa fatia de tempo separada exclusivamente para os debates. Mas a principal mudança desta versão 3.0 do “palestrão” é a sequência de apresentação. Nas anteriores eu apresentava o AN, modelagem e requisitos em três partes com fronteiras bem delimitadas. Agora vou apresentar o trabalho do AN como ele realmente ocorre, do início ao fim de um projeto. As práticas e métodos serão apresentados como em um grande estudo de caso. Esta ordem permite apresentar, além do cenário ideal, armadilhas e equívocos que têm caracterizado o uso de AN’s pelas organizações.

    Mas este formato nos leva a mesma situação apresentada lá no primeiro parágrafo: e se a turma quiser “sujar” as mãos, praticando um pouco daquilo que está sendo sugerido? Indicá-los o formato padrão, o par de oficinas com 14 horas de duração, não seria muito legal de minha parte. Afinal, nas oficinas eu repito toda a parte teórica. Pensando nisso, Tempo Real Eventos e eu resolvemos colocar no ar o “FAN – Mão na Massa“, um evento 100% prático. Os participantes serão apresentados a um problema de negócio e devem resolvê-lo em 7 horas, exercitando as principais ferramentas que estão a disposição do analista de negócios. A estréia deste evento em São Paulo está agendada para o dia 24 de março, véspera do lançamento do meu livro na mesma cidade.

    O “Mão na Massa” será o primeiro evento do programa com um pré-requisito obrigatório: os participantes devem ter assistido algum outro módulo do programa FAN. Sem a base teórica destes eventos, é praticamente impossível aproveitar bem esta oficina. Que não será restrita ao público do “palestrão”. Todos que participaram dos workshops podem tirar proveito deste novo formato: a dinâmica é diferente – não tem aquele esquema “teoria – exercício – teoria…” que os caracteriza. É realmente 100% prático, o que garante uma experiência bem diferente das anteriores. Esta versão “Mão na Massa” foi testada em Florianópolis3, em dezembro. Como o resultado foi muito positivo, resolvi liberá-lo em formato comercial.

    E tudo indica que este será o caminho de evolução do FAN, com pequenos módulos específicos. Cursos tradicionais, com 35 ou 70 horas de duração, são de difícil comercialização. A crise atual complica ainda mais a viablização de treinamentos mais longos. Os módulos do FAN, mais curtos e consequentemente mais baratos, são uma boa alternativa. Mas minha principal preocupação é com a utilidade deles: que os alunos consigam adotar as sugestões no dia ou no projeto seguinte. AN que é AN de verdade sabe que o retorno sobre o investimento deve ser nítido.

    .:.

    Notas:

    1. Sucesso que devo a todos os participantes do programa FAN. Neste mercado só podemos considerar *cliente* aquele que faz a segunda compra. E ainda indica os serviços para colegas e amigos. Vale ressaltar também o incrível trabalho da “sócia” Tempo Real Eventos, que acreditou na proposta do FAN desde o primeiro momento.
    2. Capítulo SP que agora terá com quem conversar. Está sendo lançado o Chapter Carioca do IIBA. Parabéns e boa sorte aos pioneiros.
    3. E cabe aqui o agradecimento ao pessoal da FIESC, SESI e SENAI de Santa Catarina, que deu inestimável apoio ao evento “teste” que realizei lá. E, claro, devo agradecer também a turma que topou o desafio e mandou bem, muito bem.

  • Você não pode julgar um livro pela capa

    Título surrupiado / traduzido de “You Can’t Judge a Book by its Cover”, de Willie Dixon. Um blusão gravado originalmente por Bo Diddley, em 1962. Pura verdade. Não fosse, eu nunca teria conhecido aquele que citei no último artigo como o melhor livro de TI e gerenciamento de projetos que já li, “The Art of Project Management“, de Scott Berkun. Saca só a capinha aí do lado: mais feia e enigmática impossível, não?

    Mas a frase do Willie não deve servir de desculpa para que a capa e toda a programação visual de um livro sejam relegados ao 2º plano. Estética, beleza – são preocupações que devemos ter em tudo o que fazemos. Não sou bom nisso, mas sei apreciar um trabalho bonito. E criticar a feiúra alheia…

    Há tempos contatei uma empresa de design “maluca”, que participa do SP Fashion Week, decorou alguns dos principais restaurantes de Sampa e tem um espírito criativo sadiamente distante do nosso insípido e gelado mundinho de TI. Meu único requisito: não quero que meu livro se pareça com um livro de TI, particularmente os tupiniquins. Tem bobo aí que vai dizer que isso é papo de boiola e coisa e tal. Breve e única resposta para eles: a forma deve refletir e valorizar o conteúdo. Não é só uma questão de linhas e cores, mas de conceito, de integridade. Mas eu não quero falar só de programação visual, e sim de tudo que gira em torno do formato de um livro.

    O livro impresso é uma das invenções mais longevas da humanidade – de Gutenberg pra cá já se foram 572 anos! A tecnologia de impressão mudou bastante, mas o produto final quase nada. E nenhuma edição digital conseguiu nos dar a manuseabilidade de um livro ‘normal’. Uma leitura de verdade se faz com um livro em mãos, passando suas páginas de uma forma que para outros olhos parece ser uma coisa aleatória e desprovida de lógica. Um livro ‘de verdade’ pode ser marcado, rabiscado, anotado. Um livro de fato lido fica gasto, meio manchado. E não raro tem memória: costuma abrir exatamente naquelas páginas mais necessárias em determinados momentos. Ok, meu papo soou um tanto romântico. Mas quem lê de verdade sabe do que estou falando. E apronta com seus livros algo parecido com o que faço com os meus. Meus livros não recebem o mesmo cuidado que os discos e DVDs. Mas sua valorização, por visitas e amigos, é realmente inversa. Os mais surrados são aqueles de maior valor. Meus amigos sabem. E os livros não me deixam mentir.

    Livro lido é livro gasto.Durante o projeto do livro fui confrontado com duas questões que, a princípio, estavam totalmente fora do meu escopo. A primeira referia-se ao modelo do negócio, a forma como eu esperava comercializar e distribuir o livro. Dela brotou o projeto Rendiconti, cujo lançamento obedece ao mesmo cronograma do livro: lançamento em 25 de março do ano que vem.Sobre isso eu já falei em duas ocasiões:

    Nos últimos meses, já prestes a entrar na última curva do projeto, outra questão passou a me incomodar: o formato do livro. Desde o início trato este projeto como se fosse um projeto de software. Aí, quando vislumbrei o produto final, algumas dúvidas surgiram como baldes d’água morna: como se atualiza um livro texto? Caso sejam necessárias as publicações de patches e service packs, como elas seriam? Daqui derivei outras dúvidas, e delas requisitos.

    Todos os livros que tenho morrem em si: apesar da possiblidade de erratas e extensões mais modernas, como web sites, aquele produto é fechado. O leitor pode rabiscar e corrigir. Mas o autor não consegue fazer mais nada com sua própria obra. Normalmente os autores lançam novas edições. Scott Berkun, por exemplo, chegou a trocar até o título na última edição de “The Art of Project Management”. Agora sua obra-prima se chama “Making Things Happen“. Que baita service pack, não? Acontece que os dois volumes que tenho aqui comigo não podem ser atualizados…

    Mergulhei nessas questões e fui aumentando o ‘espaço do problema’. Meu livro é de fato um guia, um guia de referência. Quero que ele esteja sempre à disposição do Analista de Negócios, para consultas pontuais. Daí imaginei que o AN queira fazer suas intervenções no próprio livro. Ao invés dos famigerados (e temporários) post-its, por que não um espaço para notas e observações? Melhor: e se o AN puder inserir páginas inteiras em seu livro texto (da mesma forma como ele pode customizar um bom software)? Se este requisito for atendido, ele facilita demais a realização de outro: a possiblidade de atualizar trechos do livro. Saca só o caso de uso: o chato autor aqui resolver atualizar o capítulo sobre Desenvolvimento de Requisitos. Ele publica a atualização (na loja Rendiconti. lógico) e a deixa disponível para todos que já adquiriram o livro. O cliente pode baixar a versão digital (gratuitamente) ou adquirir a versão impressa (daquele único capítulo). O próprio cliente encaderna o novo capítulo, substituindo a versão que ficou defasada. Jóia, não? Puxa, como eu gostaria de ter tal alternativa em meus livros. Mas… como realizar tal requisito?

    Um livro atualizável: por que não?É claro que a encadernação tinha que ser totamente diferente. Nova? Quem conhece a IOB sabe que isso tá resolvido há muito, muito tempo. Não consegui descobrir, mas acho que as “pastas Z” têm quase 100 anos. Mas, por favor, não pensem naquelas pastas antiquadas e feiosas que você vê no escritório do seu contador. Dê uma olhada na pastinha ao lado. Que tal?

    E se ela for também a capa das apostilas? Assim, todos os participantes dos cursos e oficinas, caso se interessem, compram só o miolo do livro. E aquele espaço ali para um DVD… e se tiver uma edição com uma versão integral de uma palestra ou curso? E se… Ok, as possibilidades são várias.

    Mas, é claro, tanta conveniência tem um preço. E eu não posso simplesmente ignorar aquele público que quer a opção de um livro “normal”. O jóia é que na loja virtual Rendiconti ele poderá escolher a encadernação que mais lhe agrade.

    Entendem agora como um projeto atrasa tanto? Olha como o escopo mudou. Será que eu conseguiria pensar nisso tudo lá no início, quando estava só preocupado em escrever o livro? Não sei. Mas não me arrependo de nenhuma decisão. O atraso de (quase) um ano será compensado com um produto muito, muito melhor. Ops… bom, quem vai dizer isso são os leitores. Ops.. leitores não, Usuários do Livro.

  • É o Negócio, Beócio!

    Todos os participantes de meus eventos se defrontaram com o título acima. Como era o penúltimo slide e pintava lá no finalzinho do dia, nunca mereceu muita atenção. Pouquíssimos sabiam o que significa beócio. Também foram poucos os que ficaram curiosos. Segundo o Houaiss:

    be.ó.cio adj.s.m. 1.  que(m) é natural ou habitante da Beócia, região da antiga Grécia. 2. p.ext. infrm.pej. (indivíduo) grosseiro, ignorante ou ingênuo.

    Não sei se dei sorte ou realmente não fui mal interpretado, mas nunca ninguém se sentiu ofendido com o título. Realmente os participantes de meus eventos nunca foram alvo da exclamação. Pelo contrário, minha intenção era dar-lhes de presente um clichê: É o negócio, beócio! Uma frase-projétil útil toda vez que alguém se esquece quem paga a dolorosa de nossos projetos. Resolvi hoje contar as origens e explicar o codinome do meu livro.

    Bill Clinton, em um dos últimos debates contra Bush pai, bofeteou-o: É a Economia, Estúpido! Saiu vitorioso e construiu um superávit inédito na história daquele país. Bush filho assumiria a mesma cadeira tempos depois e deixaria como legado o maior déficit que aquela nação já viu. Mas essa é outra história…

    Desde que criei coragem para escrever meu primeiro livro já tinha claro quem seria o maior homenageado: meu pai, Paulo Fernando Nogueira, que nos deixou há 12 anos, quando tinha só 49 anos de idade. Contador, foi o cara que me colocou na carreira de TI e a influenciou em diversos momentos chave. Qualquer dia falo mais sobre ele. Hoje nos interessa o beócio. O “velho” era meio erudito. Herdei dele a paixão pela leitura – de jornais (de papel), livros policiais e nossos quase sempre chatos tratados técnicos. Mas ele não gastava sua erudição em papos sérios. Não, usava-a apenas como pequenas alegorias em seus papos divertidos e xingamentos. Insulto favorito: beócio! Era dirigido, principalmente, contra jogadores perna-de-pau, juízes pouco honestos e motoristas barbeiros.

    Quando defini o tema do livro, um Guia para a Formação de Analistas de Negócios, surgiu quase que imediatamente a frase-arma: “É o Negócio, Beócio!”. Tente pronunciá-la em voz alta;jogue-a na cara dos caras que começam projetos de software pelos ferros, caixinhas e código, hehe. É de fato um belo presente que ganhei e repasso. Sem custos!

    Mas, obviamente, “É o negócio, beócio” não ficaria muito bem como título de um livro para analistas de negócios. Aliás, seria de certa forma um desperdício. Penso em utilizá-la como título de uma série! Sim, uma série de livros que terá um tema em comum: a eliminação da distância entre TI e o negócio. Ou, para usar uma casa do ‘embromation bingo’ , uma série sobre “Alinhamento Estratégico”. Qual será, então, o nome do livro? Por mim ficaria “Guia para a Formação de Analistas de Negócios”. Mas uma consulta ao nosso grupo de discussão deve ser feita antes do fechamento da questão.

    Ok, Mas Cadê o Livro?

    Quero crer que minha arrogância nunca foi tão longe: logo no início do trampo de escrever o primeiro livro fui lá e cravei um prazo: 27/mar/2008. O divulguei aqui e em todos os eventos que apresentei até o final do ano passado. Influência dos processos ágeis, onde prazos e custos são “imexíveis”? hehe.. Não importa, o fato é que foi realmente um grande erro. Trata-se de um tipo de projeto que enfrento pela primeira vez. Pior: falando de um tema que ainda está em fase de ebulição / definição. Que não sirva como desculpa, mas o próprio BABoK V2 já apresenta aproximadamente 1 ano de atraso. E olha que o trabalho deles é feito a n mãos! Mas, como eu disse, não é desculpa.

    Agora sim eu consigo trabalhar com um prazo definitivo: 25 de março de 2009. É uma quarta-feira e um pequeno evento acontecerá em Sampa. Para quem gosta de curiosidades: é dia de São Dimas, o “Bom Ladrão”. Achei coerente com um texto que ‘rouba’ boas idéias de diversos autores (também ladrões). E fica a 2 dias de completar exatamente 1 ano de atraso! Mas eu quero compartilhar um pouco da experiência de se escrever um livro, agora e em futuros artigos.

    Desde o início decidi que utilizaria um processo iterativo e incremental. Tinha a intenção de tratar o projeto do livro como se deve tratar um projeto de software. Como eu não tinha um cliente pré-definido, com o tempo criei uma comunidade de clientes para o meu ‘software’. Todos os participantes dos eventos foram convidados a participar de um grupo de discussão. Hoje somos 357 pessoas de praticamente todo o Brasil. Tem até um ilustre participante em GMT -11. Quase todos os debates ali servem como feedback direto ou indireto ao meu trampo. Tanto que até acho a troca um tanto injusta… mas o grupo não reclama. No entanto, o retorno não vem da forma como eu esperava. Não vem tão mastigado, tão diretamente relacionado ao livro, que o grupo já conhece em uma versão bastante preliminar. Mas, é claro, não posso reclamar.

    Reclamo só de mim: já escrevi o livro 3 vezes! Escrevi mesmo, do zero. Uma das versões, a 0.7, saiu do computador direto para o lixo.Não á fácil achar um ponto de equilíbrio. Explico: o texto é técnico. Mas não precisa ser chato. Minha principal referência neste ponto é “A Arte do Gerenciamento de Projetos“, de Scott Berkun. É um texto moderno, sério mas leve. Digo sem medo de errar que é o livro de TI que mais gostei de ler. E, claro, gostaria que o meu tivesse o mesmo tom e utilidade. É quase uma arte, e equilíbrio é a palavra-chave. Por exemplo: a tentação de mergulhar um pouco mais em uma parte ou técnica que mais me agrada é muito grande. Mas assim eu deixaria o texto ‘cambeta’. Quem já viu meus eventos sabe que defendo (teimosamente! hehe) alguns pontos de vista (leia-se conceitos, processos, práticas e ferramentas). Mantenho o tom (teimoso!) no livro. Mas não me esqueço que equilíbrio é a palavra-chave. Aliás, esqueço e lembro, esqueço e lembro, de uma forma iterativa e incremental. É o próprio Berkun quem diz: “Planeje voltar – escrever é editar.”

    Pois bem, início agora a última etapa do processo. Liberarei os capítulos individualmente para o grupo, até meados de fevereiro. É a versão 0.9, que também está sendo chamada de “release candidate”. Haverá um prazo para críticas e sugestões. As revisões ortográfica e gramatical, a cargo do mano jornalista Luiz Gustavo, acontecerão em paralelo. A única coisa que não será revelada nesta versão é a programação visual . Uma surpresa que só será revelada na versão 1.0, no próximo dia de São Dimas, 25/mar/09.

    Notas:

    1. Para quem não viu, o ‘embromation bingo’ é tema de uma hilária e provocativa campanha publicitária da IBM. Está no ar em alguns canais pagos, inclusive ESPN Brasil.
    2. Diversos participantes do grupo deram uma contribuição danada ao meu trabalho. Sem demagoria, considero-os co-autores. É claro que compartilharei com eles a responsabilidade de escolher um nome para meu (nosso!) primogênito.
    3. Além do conteúdo, a forma do livro me incomodou bastante. Se ele está sendo tratado como um software, como seriam realizadas as atualizações? Como aplicar patches e service packs em um livro texto? Apresento as respostas no próximo artigo. Amanhã! Inté!