Harry era um coordenador de projetos. Vivia para resolver problemas. O último foi insolúvel: Harry bateu as botas; foi dessa para uma melhor; tá mortinho da silva. Ninguém percebeu ainda. Ele está em seu cubículo, silencioso como quase sempre. Debruçado sobre o teclado, parece dormir. A tela do micro exibe o gráfico Gantt que ele atualizava quando morreu.

Jenifer apareceu para confirmar a reunião das 10. Notou que algo estava errado só na quarta vez que chamou Harry, tocando seu ombro. Pela temperatura do pescoço sacou que o cara estava realmente morto. Lembrou-se imediatamente da rodinha que se formou em torno da máquina de café logo após a reunião do dia anterior. Sentiu um frio na espinha quando recordou a jura que fez para meia dúzia de testemunhas: “Ainda mato esse $%&”. Deixou o cubículo se certificando de que ninguém havia reparado sua presença ali.

Jenifer é analista de negócios. Os 5 meses e 18 dias de convívio com Harry foram, segundo suas próprias palavras, “um inferno”. Se arrependeu de ter sugerido a adoção de um modelo iterativo e incremental para o desenvolvimento do projeto. “Melhor seria ter ficado aqui apenas um mês, escrito do jeito que desse todos os casos de uso e me mandado para outro projeto”. Harry lhe roubou a ideia e fez um curso de 8 horas de ScrumMaster. Voltou com o certificado e algumas conclusões: “A ideia do Scrum é muito boa. Só não curti muito esse papo de ScrumMaster, Product Owner e coisa e tal. Vamos adotá-lo, mas eu seguirei sendo GP. E tenho dito!”

Harry fazia questão de participar de todas as reuniões com o cliente. Jenifer funcionava mais como sua secretária do que como analista de negócios.

Arnie é um dos três programadores plenos (pero no mucho) alocados no projeto. Com espinhas no rosto e bonequinhos japoneses em sua mesa, vivia irritado com Harry. Reclamava do “clima opressivo” do projeto. Não suportava mais as 4 horas extras diárias e as manhãs de sábado trabalhando, coisa que Harry chamava de “esforcinho extra”. Algo que ele compensaria, dependendo do sucesso do projeto, “com uma bela feijoada no Bar Brahma. Por minha conta!”, prometia o falecido.

Arnie nunca manifestava suas opiniões para o coordenador – tremia de medo dele. Aos pares sempre acusava as sugestões “malucas” e o risível domínio técnico de Harry: “O cara sabe de Java tanto quanto eu manjo de culinária peruana”. As piadinhas de Arnie nunca mereciam uma risada espontânea, mas todos os programadores concordavam com suas críticas.

Passou pelo cubículo do Harry para perguntar, pela terceira vez, se a data de encerramento da iteração realmente mudaria. Todo mundo achava aquilo uma loucura e Harry nunca era conclusivo. A verdade é que nenhuma iteração até aquele momento havia respeitado o plano original (que previa ciclos de 30 dias). Arnie tremeu muito quando percebeu que seu silencioso interlocutor estava mortinho. Agachou e elaborou 100 planos para escafeder-se sem ser notado. Saiu engatinhando e entrou no cubículo ao lado, da gata Jenifer, simulando a busca pela lente de contato que ele nunca usou. Nem notou as cruzadas pernas torneadas de tão nervoso que estava.

Eis que chega o Capitão, bufando. É o gerente da área comercial e já avisou que não toleraria mais reclamações do cliente. Esperava desde a noite anterior por uma versão atualizada do arquivo do ‘project’. O cliente falou que não pagaria mais nenhuma parcela se não visse uma “evolução” do projeto. Harry e Capitão acordaram que o envio do ‘project’ talvez funcionasse como calmante. Não sem antes discutirem, por 3 horas e 17 minutos, sobre os problemas do projeto. Harry dizia que o cliente não sabia o que queria. E reclamava que sua equipe era muito “júnior”. Capitão, entre um tapa e um murro na mesa, lembrava que nunca vira, em 30 anos de carreira, um projeto de software sem problemas. No ápice do papo, lá pelas 8 da noite, gritou para quem quisesse ouvir: “Se esse projeto não der lucro eu te mato, safado!”

Boa parte da remuneração do Capitão vinha de um naco do lucro de cada projeto comercializado. Ou seja, há tempos ele vivia com a corda no pescoço, contas penduradas e um salário mínimo. A empresa resolveu que comissões ‘normais’ estavam apenas contribuindo para o aumento do prejuízo dos projetos. E concluiu que a participação nos lucros incentivaria maior colaboração da área comercial nos projetos, “gerenciando relacionamentos. Afinal, esses técnicos são muito ruins de papo”. Capitão bufou, acatou e enviou o currículo atualizado para 47 empresas.

Capitão gritou uma, duas, três vezes. “Não é possível que agora esse @#$ resolveu dormir aqui!”. Com um safanão fez a cadeira girar, o que mostrou meia face do pobre coitado e morto Harry. O olho esbugalhado dizia tudo.

Jenifer e Arnie aproveitaram o escândalo para dar e livrar suas caras: “Capitão, você matou o Harry?” A pergunta saiu em uníssono e em volume suficiente para ser ouvida em todo o andar. Logo estavam todos ali, pescoços sobre as divisórias do cubículo, rostos de espanto e comentários inteligentes sem champanhe nem cicuta. “Jura? O Capitão matou o Harry?”

Ninguém gostava do Harry. “Mas matar o cara! Meldels… onde vamos parar?” As meninas choravam um choro nervoso. Os rapazes, com seus modernos celulares, espalhavam a nova para toda a agenda de contatos. Ninguém sabia o que fazer. Capitão estava estático, catatônico, com cara de bobo. Jenifer e Arnie ainda o fitavam, acusadores e aliviados.

O ramal do Harry tocou. Identificador de chamadas: “Amorzinho”. Todos que estavam próximos trocaram olhares, esperando que um herói tomasse a iniciativa de atender ao chamado. Ninguém teve coragem e depois do 13º toque o telefone silenciou. Para tocar de novo 30 segundos depois. Identificador de chamadas: “Esse cara não tem mãe”.

“Xi… agora é o freguês”, disse alguém.

Capitão atendeu, mandando bala: “Ô Xerife, você sabe que mora eu meu coração, não?”. Silêncio constrangedor de dois minutos e meio. Todos sacaram que o Xerife, o cliente, desfilava seu repertório de impropérios nos acostumados ouvidos do Capitão. Do nada, o gerente comercial resolveu mudar o rumo da conversa: “Querido, por favor, me diz uma coisa: você mandou matar o Harry? Porque, veja bem, se foi você, eu gostaria que você soubesse que todos aqui consideraram a decisão mais acertada para que finalmente a gente possa estar providenciando a otimização de nosso processo orientado ao…” tum, tum, tum…

Epílogo

Foi no velório que todos ficaram sabendo que Harry não foi assassinado. Sofreu uma parada cardíaca fulminante. “Também”, disse Jenifer, “o cara se alimentava mal e não fazia exercício nenhum! Não aguentava um lance de escadas”. Arnie lembrou que havia dois meses que Harry parou de fumar: “Não adiantou nada.” “Pudera, o cara tava mascando 60 chicletes de nicotina por dia!”, assuntou outro. Capitão consolava o Amorzinho dizendo que Harry era o melhor coordenador de projetos que ele conheceu em 30 anos de carreira. “Pena que não suportou a pressão”.

E Harry não conseguiu o que queria quando veio para a “Top Down**”, com o diabo ter. Ele queria era falar pro Presidente pra montar um PMO e ajudar toda essa gente que só faz sofrer…

.:.

* O drama acima foi levemente inspirado num dos melhores filmes pouco conhecidos do Mestre Hitchcock, “The Trouble with Harry” (1955), que aqui em Pindorama é tratado como “O Terceiro Tiro”. As imagens utilizadas neste artigo foram indevidamente surrupiadas da Internet.

** A “Top Down” é uma software house de última geração fincada no meio do potencial vale do silício tupiniquim, leia-se Vale do Anhangabaú. Sediará outros dramas, com certeza. Infelizmente, sem nosso querido Harry.

Lembrete: salvo engano, ontem foi o Dia dos Gerentes de Projetos. Eu não ia homenagear-nos (ainda me considero um) com um artigo sobre as “maravilhas” da última versão do PMBoK, né? Fica para uma data mais propícia (ou menos perigosa).

Aviso: a história acima é pura ficção e bobagem. Qualquer semelhança com fatos, empresas ou pessoas de verdade deve ser mera coincidência. (3 batidas na madeira)

No related posts.

Minha caixa postal amanheceu repleta de mensagens de amigos avisando: Brooks estará no Brasil na próxima quarta-feira, 21/out! A preocupação dos colegas tem uma única explicação: eles sabem que sou fanzaço do cara. Não só de sua obra prima, “O Mítico Homem-Mês” (lançada originalmente em 1975 e finalmente disponibilizada em PT-br), mas também de seus artigos que seguiram, particularmente “No Silver Bullet” (1987. Este e outros artigos aparecem na edição do livro lançada pela Elsevier-Campus).

Seguem os convites:

Se você quiser entender um pouquinho mais a importância do cara, veja a série de artigos que publiquei aqui no finito em 2006. Se gostar, não deixe de comprar o livro. Se comprar o livro, lembre-se de uma provocação do Brooks:

Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!

A gente se vê num dos dois eventos acima. Inté!

Artigos relacionados:

1. De Brooks a Berkun – Prólogo
2. A Receita e o Bolo de Fubá
3. Novo Berkun

Existem usuários e usuários. Quem convive com eles sabe que cada um tem suas peculiaridades – suas necessidades e desejos, suas reclamações e chororôs, seus jeitos e manias, seus tiques e chiliques. Mas isso não nos impede de identificar e traçar alguns padrões, perfis, estereótipos e… Estereotipinhos!

O analista de negócios mais esperto sabe que não pode colocar a mão no fogo por todos os requisitos que aprende. E as melhores pistas que ele tem para não se queimar são o jeitão e a postura dos usuários. Não, o analista não precisa virar o Doutor Cal Lightman (personagem de Tim Roth na série “Lie to Me”) – um cara que percebe mentiras e outras coisas simplesmente observando seus interlocutores.  Mas atenção e canja de galinha não matam projeto nenhum, certo?

Este artigo não é (muito) sério. Ele pretende apenas apresentar alguns perfis de usuários que costumam criar probleminhas em projetos. E dar algumas sugestões para que os analistas evitem maiores acidentes.

.:.

Caetano

O usuário Caetano é carente. Passa eras esquecido em seu departamento Trancoso. A cada bimestre ele tenta receber um pouco de atenção, naquelas enfadonhas e inúteis reuniões com todo o escalão intermediário. Caetano só lida com processos de apoio (leia-se Despesas). Então só merece atenção quando a realização de seu backlog é uma obrigação. De vez em quando acontece. E lá vai o analista ouvir tudo o que o Caetano precisa.

Caetano fala devagar, mas não para de falar. Parece que não precisa da pausa para respirar. E fala, fala e fala. Pede uma coisa, reclama de outras duas. Pede duas coisas, reclama de alguém genérico. Caetano adora abstrações e picuínhas. E mistura tudo em 45 minutos de um monólogo muito chato. Quando se aproxima dos ‘finalmentes’, Caetano desacelera: “Como vou saber o que estou pensando se não ouvir o que estou falando?” Suas frases ficam mais curtas e cada vez mais lentas. Até que há um intervalo que dura entre 5 e 10 segundos. Aí, num moroso (de) repente, Caetano condena toda a sessão de desenvolvimento de requisitos com apenas duas palavrinhas: “Ou não”.

Ao analista resta: respirar fundo e ter muita paciência. Caetano é carente e acha que TI nunca lhe dá atenção (o que é a pura verdade). Suas demandas nunca são prioritárias. O analista deve evitar interromper o monólogo, para não correr o risco de ter um Caetano nervoso e irritado. E deve tentar entender o “ou não”, por impossível que isso pareça.

Glória

Ah, a usuária Glória – uma novelista nata. Adora contar histórias (no meio de uma sessão de desenvolvimento de requisitos). Não, não o tipo de história que agradaria agilistas. Suas histórias são muito longas, verdadeiros épicos. E intrincadas demais. Glória normalmente comanda um departamento “global” – atinge todo mundo. RH, financeiro ou algo do tipo. Parece que todos na empresa gostam da Glória. Alguns por obrigação. Mas seu Ibope é alto: ela é realmente muito simpática. Calorosa até na hora de expressar seus requisitos.

Glória complica demais e é voluntariosa. Aprendeu e ensina que tem mais valor aquele profissional que não se limita a reportar problemas. Ela adora apresentar soluções. Praticamente cada requisito que ela pede já vem acompanhado da solução ideal. Mas suas soluções, quando não são ingênuas demais (”Nossa, mas colocar esse campinho na tela é tão fácil!”), são nonsense de tão complexas  (”Então vamos colocar a Deborah numa caixa de papelão e entregá-la, como que por acidente, na casa do galã da novela”).

Pobre analista: você deve ser muito sutil ao pedir para a Glória que ela se limite a dizer “o que ela precisa”. Explique, gentilmente, que o “como” é responsabilidade de outra patota, outra plateia. Diga que, se for o caso, ela pode até participar das sessões de brainstorming que definirão a melhor solução. A equipe técnica o odiará por isso. Ninguém se esquece que Glória já derrubou coordenadores, arquitetos e até diretores no passado.

Azevedo

Azevedo é um usuário azedo. Para ele, tudo e todos estão sempre errados. E ai de quem discordar. Azevedo vive colado no alto escalão – tem “moral”.  Apesar de seu job description não formalizar e ninguém pedir, Azevedo sempre se mete nos temas estratégicos da empresa. E parece ter resposta para tudo. Ele é muito culto, um intelectual de chapéu panamá. E gosta de exibir a riqueza de seu vocabulário quando expressa seus requisitos.

Azevedo detesta ser entrevistado – particularmente para o desenvolvimento de requisitos. Ele não fala, mas indica que os entrevistadores nunca estão a sua altura. Ele gostaria mesmo é de ser entrevistado pelo diretor de TI, CIO ou equivalentes. Como isso nunca é possível, ele prefere mandar os requisitos por escrito. O analista também ficaria satisfeito com isso, se ele não soubesse que nada substitui o contato cara a cara. Enfrentar o chato do Azevedo é inevitável.

Ilustríssimo analista: acalente-se. Todo ofício tem seus ossos. E toda empresa tem seus azevedos. Evite o confronto porque ele só será resolvido em outra instância. Ou seja, *nunca* discorde do Azevedo. Mas também não precisa baixar a cabeça para ele. Registre com capricho os requisitos. Não pule nenhuma etapa da cerimônia que o Azevedo eventualmente exigir. E torça para que esses encontros sejam breves.

Dunga

Muitos analistas gostariam que o usuário Dunga fosse aquele amiguinho da Branca de Neve – quietinho e muito bonzinho. Não é. Dunga é um ranheta – vive zangado e enfesado. Mas é diferente do Azevedo. Dunga é paranóico, tem mania de perseguição. Acha que todo mundo quer derrubá-lo (o que nem sempre é mentira). Mas Dunga é muito importante para a empresa. Como mostra resultados, não será fácil tirá-lo de lá. E Dunga sempre tem muitos requisitos para apresentar.

Requisitos do tipo “desconfiado”. Dunga costuma pedir um monte de coisa que só sua paranóia justifica: dezenas de senhas, centenas de relatórios. E lê nas entrelinhas de cada pergunta do analista alguma crítica ou complô. Dunga não tem paciência nenhuma. Nem os modos educados do Azevedo. Dunga esbraveja e, em situações extremas, usa até palavras que não podem ser publicadas neste espaço. Dunga mete medo. Em seus adversários e, infelizmente…

… nos tristes analistas: que ouvem desaforos que não merecem. É muito importante manter a calma e a compostura. Faça o Dunga entender que você, prezado analista, é apenas o mensageiro. E está ali só para entender as necessidades dele. Mas não tente ganhar o raivoso com elogios ou mimos. O paranóico verá indícios de conspiração até nisso. Demonstre isenção, imparcialidade. Mas sinta-se a vontade para interromper uma entrevista toda vez que o Dunga passar dos limites. Afinal, ninguém merece chilique de gente mal educada, né?

Outras Figurinhas

O espaço é curto e o elenco de estereotipinhos é quase infinito. Listo abaixo outras figurinhas relativamente comuns que, dependendo do projeto, podem ser tão ou mais perigosas que os colegas apresentados acima:

• Mikaela: usuária um tanto lenta e sem um pingo de autonomia. Seu chefe, sem tempo para nada, sempre a joga nessa enrascada: passar os requisitos para o chato do analista. O problema é que ela não sabe nada e decide menos ainda. Analistas: peguem o chefe no corredor ou elevador. Rende mais.
• Maikol: usuário que não acerta uma! 90% de seus requisitos são falsos. Os outros 10% não têm valor nenhum. Não é má vontade, pelo contrário: é excesso de vontade. E muita falta de conhecimento. Analistas: confirmem de alguma forma os pedidos do Maikol antes de passá-los adiante. Mas tentem não queimar o cara, ok? Ele é gente fina.
• Maike: é um super-usuário, curioso e fuçador que nem te conto. É pior que a Glória na hora de propor soluções, porque ele realmente acha que sabe tudo sobre .Net, Java, SQL e o ângulo correto para colocação da rebimboca da parafuseta. Maike é um destruidor de soluções e um martírio para analistas de negócios. Analista: coloque seu melhor técnico para baixar a bola desse cara. Senão você está perdido.
• Mikey: é o engraçadinho da turma, faz piada com tudo e todos. Requisito-piada? Pois é, existe. E é sempre de mau gosto. Mas esses caras têm sua utilidade quando um workshop de requisitos está carrancudo demais. Mas é bom não dar muita trela. Senão eles roubam a festa (e o seu precioso tempo).
• Mixel: é uma figura, um fenômeno. Excelente funcionário e amigo de todo mundo. O problema é que ele vive se metendo em confusões. Em projetos, suas trapalhadas aparecem mais aos 45 do segundo tempo, quando apresentado para uma solução: “Nossa, eu pensei que não tivesse nada disso. Eu queria outra coisa!”

.:.

Observação: Os usuários serão vingados! Qualquer dia publico “Estereotipinhos (do outro lado)”. Garanto que eles são piores que o pior usuário que conhecemos.

No related posts.

Sabe aquela sua colega que parece ser a única num raio de 500km que conhece e gosta de uma obscura banda de rock belga? Lembra-se como ela se revoltou e desgostou quando a banda assinou contrato com uma grande gravadora? É o mesmo caso daquele amigo que era fanzaço de um diretor de cinema chinês, mas desistiu da idolatria quando o cara resolveu fazer um filme em Hollywood: “O cara se vendeu”. Todos conhecemos gente assim, que gosta de coisas muito diferentes, distantes do universo pop(ular). Pessoas que se sentem traídas quando seus modelos ou ídolos tentam falar para um público maior, tentam atingir mais pessoas.

Desconfio que algo muito parecido esteja acontecendo agora, naquele universo que surgiu após o big-bang do Manifesto Ágil. Dois excelentes artigos, de José Paulo Papo e Rodrigo Yoshima, ajudaram a alimentar minhas suspeitas. Além de um bate papo bem legal que rolou sobre a possível morte do RUP (Rational Unified Process) no grupo UML-BR.

O Yoshima está certo: RUP e Agile compartilham hoje uma mesma tendência. Mas seria a de morrer? Márcio Tierno, o MT, fez um diagnóstico diferente ao falar especificamente sobre o estado atual do RUP:

Acho que o RUP, pior do que estar morto, entrou para o mainstream. Hoje um cliente ou usa um processo waterfall ou usa um processo *pretensamente* baseado no RUP.

E entrar para o mainstream significa ter sua evolução freada. Ninguém entendia direito o RUP. Poucos dos que o “adotaram” em suas empresas se deram ao trabalho de ler a última versão e entender. Os “metodologistas” das empresas sempre gostaram do RUP exclusivamente pelos artefatos, pela sensação de controle e pelo tamanho. Jamais pela iteratividade.

Surrupiei do Google Trends alguns dados que de certa maneira confirmam as palavras do MT e solidificam minhas suspeitas. Veja os gráficos abaixo:

Azul = RUP | Vermelho = Agile | Laranja = Scrum

O primeiro gráfico abrange o mundo todo. O segundo levou em consideração apenas as buscas e notícias realizadas no Brasil. O Google Trends faz exatamente isso: mostra a quantidade de buscas pelos termos. Não pode ser considerado ao pé da letra, afinal Scrum e Agile significam outras coisas para outras pessoas. O que não tira totalmente o valor do indicativo de tendências.

E o que os gráficos nos mostram? Uma queda constante porém gradual no interesse pelo RUP e um crescimento vertiginoso nas buscas pelo termo “agile”, particularmente aqui no Brasil. Seria isso um indicativo de morte? Só para aqueles que, como os fãs de bandas e diretores obscuros, gostariam de permanecer num grupo pequeno e muito restrito.

Eu entendo e compartilho o que acredito que sejam as principais preocupações do MT e do Yoshima. Ao se transformarem em artigos pop – ou “carne de vaca”, para usar um termo bem nosso – RUP e Agile saem do controle. Do nosso controle. E não serão poucos os que irão distorcer, desfigurar e desmontar os valores e princípios que caracterizam e definem essas propostas. Aliás, preciso confessar, eu sou um deles. Tanto que já fui criticado, aqui mesmo no finito, por chamar de “bullshitagenzinhas ágeis” algumas das práticas sugeridas. Falei de práticas, não de princípios e valores. Mas isso não importa. O que importa aqui é saber se é mesmo o caso de decretar a morte do RUP ou do Agile.

Se o RUP é muito mal utilizado, e de fato é, boa parte da culpa é dos seus criadores e evangelistas. Já mostrei por aqui como o RUP foi uma verdadeira metamorfose ambulante desde o seu lançamento. Alteraram sem pudor seus princípios, causando confusão. O artigo do José Papo mostra que agora a versão 7.5 tem um “Agile Core”. Não estou dizendo que o RUP não deveria evoluir. Estou afirmando que a evolução foi mal conduzida (parece improviso) e muito mal comunicada. O que não isenta, claro, os cabeças de pamonha que fizeram dele uma cascata iluminada.

O universo Agile pode e vai sofrer com problemas semelhantes. Cabeças de pamonha estão longe da extinção. Mas o caso aqui é diferente. Os valores e os princípios consolidados no Agile Manifesto permanecem os mesmos desde o dia 13 de fevereiro de 2001. E eles não sofrem com um dono nem com as pressões comerciais que este faria.

Esqueçamos por alguns minutos os Pamonhas e suas cascatas e contratos a preço fechado. Cabe aqui uma autocrítica por todos aqueles que defendem o manifesto:

• Será que estamos sendo didáticos o suficiente?
• Não somos impacientes demais para explicar, por exemplo, por que uma iteração não é uma mini-cascata?
• Será que, ao invés de explicar, não estamos detonando demais o “outro lado”. Vide meu termo acima: Pamonha!
• Não estamos sendo religiosos e puristas demais?

Meu maior temor é que os agilistas de hoje se comportem como os cascateiros de ontem. Não concordo com o MT quando ele diz que “mainstream significa evolução freada”. Oras, se no contexto de um projeto estimulamos (ou forçamos) a participação de todos, exatamente para gerar mais ideias e inovações, por que numa escala maior esta mesma prática seria nociva – por que ela geraria o efeito contrário?

Se de fato nós acreditamos que RUP e Agile são as respostas para melhores projetos, não faz o menor sentido o medo de que essas propostas se transformem em suculentas “carnes de vaca”. Ou nós queremos seguir como os raros fãs de obras cult que ninguém conhece?

.:.

A foto utilizada neste artigo, “We Love Crisis”, é de Daquella Manera (Daniel Lobo), fotógrafo profissional que disponibiliza alguns de seus trabalhos como Domínio Público.

No related posts.

A pesquisa que disparei 15 dias atrás só permite concluir uma coisa: nosso povo não gosta muito desse tipo de coisa. Coloquei uma meta muito modesta: 150 participantes. Consegui apenas 131. Entendo que é uma amostra muito pequena, que não permite conclusões. Mas dá boas pistas. E possibilita a elaboração de alguns palpites.

O pessoal que define “o que  precisa ser feito”, os analistas de negócios, empatou com a turma do “como será feito”, os analistas de sistemas. 22% de participação de cada um. Em segundo lugar vieram os coordenadores de projetos, com 15% das respostas. Desenvolvedores e analistas de processos aparecem com 10% e 9%, respectivamente. De curioso aqui nosso coringa, que disse ser analista de negócios, de sistemas, de requisitos, desenvolvedor e arquiteto! Será que o salário é compatível com tantas responsabilidades?

Um participante cobrou, não perguntei sobre rendimentos. Falha minha. Não sei se por sorte ou azar, no mesmo período, a revista Você SA da Abril liberou uma pesquisa sobre o assunto. Cobre mais de 130 profissões, sendo 14 específicas da área de TI. Vou destacar aqui apenas um ponto: analistas de sistemas ou analistas-programadores (chamados naquela publicação de analistas de desenvolvimento) ganham praticamente a mesma coisa que analistas de negócios. Até os 5 anos de experiência. Depois disso, mostra a pesquisa, os analistas de negócios apresentam salários consideravelmente maiores. A diferença chegaria a R$ 5 mil entre profissionais com mais de 15 anos de experiência. Nesta faixa de tempo de estrada, o salário de analistas de negócios em pequenas e médias empresas seria maior até do que dos gerentes de projetos. Estranhei muito o número, mas não tenho como questioná-lo. A empresa que executou a pesquisa, a Robert Half, fez mais de 30 mil entrevistas. É uma pena que tenha se limitado aos mercados de São Paulo e Rio de Janeiro.

São Paulo de fato concentra a grande maioria das vagas. Em minha pesquisa, 58% dos participantes são de lá. Rio, Santa Catarina e Minas aparecerem na sequência, com quase 10% cada um. Profissionais do sexo masculino também confirmam outro tipo de concentração: são 81%, contra 19% de mulheres. 70% dos participantes têm idade entre 23 e 34 anos. Com mais de 40 tivemos 11%. Curiosidades: 44% disseram se apresentar como “Sêniores”, contra 39% que são “plenos (ocasionalmente vendidos como sêniores)”; 5% estão “loucos(as) para mudar de profissão”.

Mais da metade dos participantes, 57%, trabalha em empresas de TI. 30% em serviços de desenvolvimento e manutenção de sistemas. A maioria, 28%, conta com mais de 100 profissionais na área de TI. Mas, que espanto, 48% de todas as empresas contam apenas com algo entre 1 e 5 profissionais trabalhando com análise de negócios. Na questão eu ainda tive a preocupação de especificar que seria qualquer profissional que executasse: modelagem de negócios, modelagem de processos, desenvolvimento de requisitos etc. O desequilíbrio parece ser muito grande.

Sobre Projetos

Repetiu-se neste levantamento um número que tem cara de “default”: 62% dos projetos têm algum tipo de problema. 21% seriam “muito mal sucedidos (muito atrasados e gerando prejuízos)”. Para dizer a verdade, o número até que é um pouquinho melhor do que aqueles que vemos em outros lugares. Mas ainda é muito comprometedor.

Nada de novo também no front dos principais problemas: mudanças de requisitos (18%), requisitos mal definidos (17%) e mudanças de regras de negócios (13%) são os principais. Pouco envolvimento de clientes e usuários, metodologia mal aplicada e equipe mal preparada respondem por 9% cada um.

61% das empresas estão cientes dos problemas e tomando providências. As principais seriam: treinamento da equipe (31%), implantação de novas tecnologias e ferramentas (23%), implantação de nova metodologia (21%).

E quais metodologias, processos ou padrões são utilizados? Algumas surpresas: PMBoK (23%), Scrum (18%), RUP (16%), CMMI (10%) e XisPê (8%) são os destaques. Fiquei com pulgas atrás do orelhão: com tanto Scrum, como ninguém se apresentou como ScrumMaster ou Product Owner? O número do RUP também surpreendeu.

O que não surpreende é que 71% ainda utilizem editores de texto para tarefas de descoberta, descrição e gerenciamento de requisitos. E 61% depositem suas esperanças em planilhas eletrônicas. A relação não fica explícita, mas tenho certeza que essas ferramentas colaboram diretamente com os problemas listados acima.

Mas 68% utilizam especificações de casos de uso. Parece um bom sinal. Mas o número não bate com os levantamentos informais que faço em meus eventos. Será que estão falando de casos de uso de verdade, ou daquelas extensas descrições de telas e de como a solução deve ser construída? Infelizmente seguirei sem resposta. Mas desconfiado de que estamos falando de casos diferentes.

Perguntei se praticavam a modelagem de negócios. 38% disseram que sim, “e percebem o valor dela”. 35% disseram que praticam, mas “só um pouquinho”. 73% praticam a modelagem de negócios?!? Outro número que não bate de forma alguma com o que vejo nos eventos e empresas. Ainda mais com 59% dizendo utilizar a UML para tal. Para se ter uma ideia, são 23% aqueles que utilizam a BPMN. Pouco mais que os 20% que já estariam utilizando o método do “Pensamento Visual”.

Uai cara pálida: você faz uma pesquisa para depois questionar os números obtidos? Entendam, por favor: a culpa é da pesquisa e do número de respostas. Minha críticas acima servem apenas para destacar pontos da pesquisa que parecem estar bastante distorcidos. E uma das causas das distorções é óbvia e também foi levantada: 55% de quem participou da pesquisa já participou de algum evento FAN.

Mas, de qualquer maneira, pistas e palpites podem ser observados e colocados. Resta esperar que futuras iniciativas como esta sejam melhor elaboradas e mereçam um número bem maior de participantes. Aos que aceitaram meu convite e doaram preciosos minutos, registro aqui meu muito obrigado. E boa sorte no sorteio!

.:.

A foto utilizada acima, “Torcedor Solitário“, foi devidamente surrupiada do Rodrigo Moraes.

No related posts.

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 finito@pfvasconcellos.com, 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.

Artigos relacionados:

1. Sobre o Livro (e uma Oferta)

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

[Simulação textual do hiato .... Dependendo do projeto, cabe uma novela inteira aqui. Vou poupá-lo disso.]

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

No related posts.

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

Artigos relacionados:

1. Boas Vindas ao IIBA
2. O Giro em Falso das Rodas Reinventadas
3. 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)

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:

• O BABoK pode ser obtido diretamente no site do IIBA, em http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge

Outras Notas:

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

Artigos relacionados:

1. BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios
2. O Analista de Negócios e o tal BABoK
3. O BABoK e a Disciplina “Enterprise Analysis”

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 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:

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

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

Quando 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:

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

Quando é 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.

Pois é, 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.

O 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:

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

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

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

Aliá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.

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

O 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’:

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

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

Artigos relacionados:

1. Modelagem de Negócios: Uma Sugestão
2. Modelagem de Negócios: A Encruzilhada
3. BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios