Guia para A Formação de Analistas de Negócios - Draft 0.9

1
Guia para a Formao de

Analistas de Negcios
Draft 0.9
(Release Candidate)
Paulo F. Vasconcellos
Jan-Fev/2009
2
Crditos & Dbitos

Este livro liberado sob a licena
Creative Commons :: Atribuio Uso No-Comercial Compartilhamento pela mesma licena 2.5
(http://creativecommons.org/licenses/by-nc-sa/2.5/br/)
Voc pode:
copiar, distribuir, exibir e executar a obra
criar obras derivadas
Sob as seguintes condies:
Atribuio. Voc deve dar crdito ao autor original, da forma

especificada pelo autor ou licenciante.
Uso No-Comercial. Voc no pode utilizar esta obra com

finalidades comerciais.
Compartilhamento pela mesma Licena. Se voc alterar, transformar, ou

criar outra obra com base nesta, voc somente poder distribuir a obra
resultante sob uma licena idntica a esta.
Para cada novo uso ou distribuio, voc deve deixar claro para outros os termos da
licena desta obra.
Qualquer uma destas condies podem ser renunciadas, desde que Voc obtenha
permisso do autor.
Nada nesta licena impacta ou restringe os direitos morais do autor.
Qualquer direito de uso legtimo (ou "fair use") concedido por lei, ou qualquer outro direito
protegido pela legislao local, no so em hiptese alguma afetados pelo disposto acima.
Este um sumrio para leigos da Licena Jurdica (na ntegra).
( http://creativecommons.org/licenses/by-nc-sa/2.5/br/legalcode )
Crditos & Dbitos 3
Outras informaes Legais e sobre a Editora

4
Prefcio
Crditos & Dbitos 5
ndice
6
Introduo 7
Captulo 1
Introduo
8 Captulo 1
Introduo 9
Parte I
O Analista de
Negcios
10 Captulo 1
O Analista de Negcios 11
Captulo 2
O Analista de Negcios
A funo do analista de negcios (AN) existe h dcadas. De maneira resumida, podemos dizer
que aquele profissional responsvel por interagir com clientes e usurios para entender seus
problemas e necessidades. Acontece que na maioria das vezes esse profissional acumula outra
funo. E esta a sua principal responsabilidade: gerenciar o projeto, desenhar a soluo,
programar. No raro, o processo de levantamento e entendimento dos requisitos de clientes e
usurios visto assim mesmo, como uma atividade secundria de um projeto. Porque o
gerente, analista ou programador foi alocado ali para fazer outra coisa para criar e entregar
uma soluo.
Houve um tempo em que a formao de analistas de sistemas contemplava de maneira

satisfatria o estudo de mtodos e prticas que auxiliavam no entendimento de problemas de
negcio. No entanto, tanto o mercado quanto a academia comearam a privilegiar o domnio
da soluo, formando e contratando analistas-programadores. No arriscado dizer que a
crescente dinmica do mundo dos negcios e um certo imediatismo criaram essa distoro
pouco lgica: equipes de tecnologia da informao (TI) esto repletas de gente preparada para o
domnio da soluo criar, modelar, programar, entregar e carentes de profissionais que
realmente entendam o problema que precisa ser resolvido.
No por acaso, o alinhamento estratgico de TI com o negcio figura h tempos em listas de

prioridades de diretores de informtica, CIO's (Chief Information Office) e afins. Tambm no
por acaso que problemas com requisitos, com a participao dos usurios e com mudanas
aparecem em todas as listas de problemas recorrentes em projetos mal sucedidos.
Calma: no estou afirmando que a presena de um AN por si s promove o tal alinhamento

estratgico e faz dos projetos de TI uma sequncia de casos de sucesso. Depois dos gerentes de
projetos, arquitetos, desenvolvedores geis e afins, no pretendo nomear o prximo super-
heri da nossa rea. Mas tentarei convenc-lo, neste captulo e no restante deste livro, que o
AN pode ser sim um profissional muito importante em todas as organizaes.
Comparada a outras reas de conhecimento que tratam do desenvolvimento de sistemas, a

anlise de negcios uma das mais novas. To nova que podemos dizer que uma rea ainda
em fase de definio1. O que no nos impede de traar algumas linhas bsicas visando a
formao de analistas de negcios.
Antes, porm, precisamos entender quem o analista de negcios. Quais devem ser suas
atribuies e quais habilidades ele precisa desenvolver. Esses so os temas deste primeiro
captulo.
1 Com pouco mais de 50 anos de idade, claro que toda a rea de desenvolvimento de sistemas (ou Engenharia
de Software) ainda est em fase de definio. Mas, de todas as suas disciplinas, a anlise de negcios
realmente a mais nova. E, talvez, a mais imatura.
12 Captulo 2
A Anlise de Negcios
A anlise de negcios uma macrodisciplina que tem como principal objetivo o entendimento
do negcio - seus problemas e oportunidades - e das necessidades, restries e desejos de todas
as partes interessadas2. Ela ainda mais conhecida atravs das duas disciplinas que lhe do
forma: a Modelagem de Negcios e a Engenharia de Requisitos. Apesar de nascer e se
desenvolver como uma parte da engenharia de software, veremos adiante que a anlise de
negcios no se limita a projetos para o desenvolvimento ou implantao de sistemas de
informao.
No contexto de um ou mais projetos, lanamos mo dos mtodos e prticas que formam a

anlise de negcios para dominarmos o problema. Ou seja, para efetivamente entendermos as
necessidades do negcio e de seus participantes.
A motivao pode ser um problema que requer alteraes em processos, polticas e sistemas.
Mas tambm pode ser uma oportunidade de negcio, algo que igualmente gera requisitos de
mudanas em diversas partes de uma organizao. De qualquer maneira estamos tratando aqui
de mudanas que, a princpio, sero implementadas na forma de projetos.
Que no so, necessariamente, projetos de sistemas. A soluo para um problema de negcio

ou para aproveitamento de uma oportunidade pode se limitar ao redesenho de um processo,
reestruturao de recursos ou alterao de polticas que no geram impacto em sistemas
existentes nem demandam novos sistemas de informao. No entanto, dado o nvel de
informatizao de empresas dos mais diversos ramos de atividade e portes, de se esperar que a
grande maioria das solues encontradas gere mudanas em sistemas existentes ou requisitos
para novos sistemas.
Os negcios e seus processos esto sendo digitalizados. Por isso difcil separar o analista de
negcios de um projeto de software. Por isso este livro trata quase que exclusivamente de
projetos para desenvolvimento ou implantao de sistemas de informao.
comum a apresentao da anlise de negcios como uma funo estratgica3. Apesar do

trabalho ser predominantemente operacional. Ao participar ativamente do gerenciamento do
portflio de projetos e do gerenciamento do relacionamento com as unidades de negcios4, o
AN assume relevncia estratgica para a organizao de TI. Como veremos no decorrer do
livro, mesmo em projetos isolados um bom AN no ignora a estratgia da empresa. Ele sabe
que um projeto, por menor que seja, tem ou deveria ter uma motivao estratgica. Ao cuidar
para que todos os requisitos contribuam para a realizao daqueles objetivos maiores, ele est
na prtica realizando o alinhamento estratgico de TI com o negcio.
2 Partes interessadas: traduo do termo stakeholder.
3 Por exemplo, um exagerado artigo da CIO Magazine recebeu o ttulo Analistas de Negcios valem Ouro:
http://cio.uol.com.br/gestao/2008/05/19/analistas-de-negocio-valem-ouro/
4 Posio defendida por Richard Wyatt-Haines em Align IT (Wiley, 2007). Ele chega a indicar o uso do termo
Gerente de Relacionamentos ao invs de analista de negcios.
J existe uma proposta de estrutura para o corpo de conhecimentos da anlise de negcios, o

BABoK (Business Analysis Body of Knowledge), do IIBA (International Institute of Business Analysis).
Por vrios motivos, explicados no tpico IIBA & BABoK abaixo, este livro no obedece essa
estrutura.
Este guia apresenta a anlise de negcios em trs partes:
Entendendo o Negcio: ttulo que visa dar sentido a modelagem de negcios. Aqui o
AN conhecer mtodos e prticas para entender um negcio, suas motivaes,
estrutura, processos e regras. No possvel um correto entendimento dos requisitos
de usurios se no conhecemos seu negcio. E vice-versa.
Entendendo o Usurio: nome alternativo para engenharia de requisitos. O conjunto

de mtodos e prticas que o AN pode utilizar para desenvolver e gerenciar requisitos
as necessidades, desejos e restries de usurios e do negcio.
Viabilizando o Projeto: o AN auxilia unidades de negcios e a rea de TI na

viabilizao de projetos. Esta terceira parte apresenta o que o AN deve aprender para
viabilizar, obter financiamento e vender um projeto.
14 Captulo 2
IIBA & BABoK

Em 2003 foi fundado o IIBA em Toronto, Canad. Seguindo os moldes do PMI, Project
Management Institute, promete fazer pela anlise de negcios o que este fez pelo gerenciamento
de projetos: buscar o reconhecimento e divulgao da profisso e desenvolver e manter padres
para a prtica da anlise de negcios e para a certificao de seus praticantes. No centro desses
objetivos est o principal produto do instituto: o corpo de conhecimentos da anlise de
negcios, ou BABoK. Seu primeiro draft, estranhamente numerado como 1.4, foi publicado em
outubro de 2005. A verso disponvel para download gratuito no momento da publicao deste
livro, ainda um draft, a 1.65.
Produto do trabalho de dezenas de colaboradores, dentre eles renomados metodologistas como

Scott Ambler6, o BABoK estruturado em 6 disciplinas, ou reas de conhecimento (KA
Knowledge Areas). Abaixo uma breve apresentao de cada uma delas, de acordo com
documento publicado pelo IIBA em 20077.
Figura 1 - As 6 disciplinas do BABoK
5 http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge
6 http://en.wikipedia.org/wiki/Scott_Ambler
7 The Business Analysis Profession, apresentao elaborada por Kevin Brennan, vice-presidente do IIBA,
em setembro de 2007.
Disciplina Propsito
Planejamento da Anlise de Determinar o que precisa ser feito.

Negcios
Anlise da Organizao Entender o problema de negcio e o escopo das possveis solues.
Elicitao Encontrar as reais necessidades das partes interessadas.
Anlise de Requisitos Descrever caractersticas e qualidades da soluo que deve satisfazer
as necessidades das partes interessadas.
Avaliao e Validao da Determinar se a soluo correta para as partes interessadas.
Soluo
Gerenciamento e Garantir que as partes interessadas concordam com as necessidades
Comunicao dos Requisitos que sero satisfeitas.
A princpio no h nada de errado com a estrutura acima. O nome das disciplinas e respectivos
propsitos parecem cobrir tudo o que necessrio para uma eficaz anlise de negcios. Porm,
uma anlise mais detalhada do BABoK revela algumas surpresas. A principal delas: a
modelagem de negcios sumariamente ignorada!
Revirei tanto a verso 1.6 quanto a verso 2.0, que foi temporariamente disponibilizada para
reviso pblica, e pouqussimo encontrei sobre modelagem de negcios. Na verso 1.6 o
termo aparece apenas como sendo uma das habilidades que um arquiteto de negcios deve
desenvolver.
Na verso 2.0 a modelagem de negcios surge durante a apresentao da tcnica modelagem

de processos (6.15). O problema comea com o nmero a: a tcnica faz parte da disciplina
anlise de requisitos!? O problema aumenta quando o BABoK registra que BPMN a
notao mais amplamente aceita para a modelagem de negcios8. BPMN, de Business Process
Modeling Notation, atende, como o prprio nome indica, apenas a modelagem de processos de
negcios. A modelagem de negcios, como veremos na segunda parte do livro, muito mais
que isso. Tambm questionvel a afirmao de que esta seria a notao mais amplamente
aceita. a notao da moda, sem dvida, mas ser realmente a mais aceita? Infelizmente o
BABoK no indica fontes que sustentem a afirmao. Voltarei ao tema na segunda parte deste
livro, que trata da modelagem de negcios.
O que interessa aqui notar que o BABoK parece cometer uma grave omisso. Por mais de um
ano tentei contat-los, sem sucesso. Minha pergunta: se no o AN quem faz a modelagem de
negcios, ento quem ? visvel que boa parte do BABoK trata exclusivamente da engenharia
de requisitos. De maneira adequada, diga-se de passagem.
Mas cambeta por desconsiderar tcnicas e mtodos que nos auxiliam no entendimento do
negcio. Desconheo fato mais contundente que prove o quanto a disciplina modelagem de
negcios mal compreendida. Espero que a segunda parte deste livro comprove minhas
consideraes. Antes precisamos conhecer melhor o tal Analista de Negcios.
8 BABoK version 2.0 Draft for Public Review. IIBA (2008).

16 Captulo 2
Definindo o Analista de Negcios

O AN o profissional responsvel pelo entendimento, avaliao e comunicao das
necessidades de um negcio e suas partes interessadas. Desta forma ele colabora com a
definio de uma soluo para determinado problema de negcio.
TI e as reas de negcios vivem em um conflito que parece eterno e tem uma origem muito
bem identificada: a dificuldade de comunicao. Seus vocabulrios so muito diferentes. O
cenrio piora quando TI desconhece ou no mostra comprometimento com os reais objetivos
do negcio.
De uns tempos para c, algumas empresas foraram a aproximao de diretores e gerentes de

TI com o negcio. Enquanto um relativo sucesso foi obtido no relacionamento entre
membros do alto escalo, na parte operacional os srios problemas de comunicao
persistiram. Entra o analista de negcios.
Este profissional deve atuar como uma ponte entre o negcio e TI. Dominando os dois
vocabulrios, deve eliminar, principalmente, os srios problemas de comunicao. Mas esta
definio parece fazer do AN um tradutor ou intrprete, o que no verdade.
Voltemos definio do primeiro pargrafo acima. Temos trs verbos ali: Entender, Avaliar e
Comunicar. hora de detalhar o significado de cada um deles:
Entender: o AN entende o negcio seus problemas e oportunidades, e tambm as

necessidades e restries de todas as partes interessadas, o que inclui toda a equipe
tcnica, alm de clientes, patrocinadores e usurios. Essa compreenso ampla, o que
confere ao AN uma perspectiva nica. Enquanto reas de negcios e TI observam e
cuidam de seus respectivos lados e interesses, o AN vislumbra os dois lados da moeda
que nica.
Avaliar: sendo assim o AN tem condies de efetuar uma isenta e clara avaliao dos
problemas e / ou oportunidades e das solues apresentadas. Sua avaliao, que sempre
executada com representantes dos dois lados, deve guiar a seleo da melhor soluo,
ou da mais vivel.
Comunicar: durante todo o processo de entendimento e avaliao que, diga-se de

passagem, podem ter praticamente a mesma durao do projeto, o AN se comunica de
forma constante com todas as partes interessadas. Em dado momento, questionando e
estudando. Em outros, avaliando e negociando. O AN uma espcie de hub, um
concentrador de comunicaes. O risco de virar um gargalo para os projetos grande.
Mas este assunto para outro momento.
Uma Profisso, Vrios Nomes

Por antiga que seja a demanda, a profisso AN relativamente nova. Por isso ainda vemos
vrios nomes sendo utilizados para referenciar o mesmo profissional. O nome tambm pode
indicar algum tipo de especializao. Mas, de maneira geral, todos podem ser chamados de
Analistas de Negcios. A lista abaixo apresenta alguns dos termos mais comuns utilizados
atualmente:
Analista de Requisitos: como o prprio nome indica, se limita ao levantamento,

desenvolvimento e, em alguns casos, ao gerenciamento de requisitos.
Analista de Processos: funo que pega carona na onda BPM (Business Process
Management). Especializa-se na anlise e desenho de processos de negcios.
Multiplicadores: termo que indica claramente a responsabilidade de aprender

(sistemas, com TI) e repassar o conhecimento, multiplic-lo entre as reas usurias. A
via de retorno, do negcio para TI, existe mas parece ser secundria.
Product Owner: ou Dono do Produto, termo cunhado no mtodo gil para

gerenciamento de projetos Scrum. o profissional que define requisitos e prioridades e
gerencia o Product Backlog, ou seja, a relao de tudo o que precisa ser entregue pelo
projeto.
Outros termos, relativamente estranhos, so utilizados em algumas empresas brasileiras para

identificar o profissional AN ou seu departamento. Ponto Focal e Departamento de
Tecnologia do Negcio so 2 deles. No primeiro caso v-se nitidamente a tentativa de
posicionar o AN como a ligao entre usurios e a rea de TI. De certa forma aproxima-se com
a sugesto de Richard Wyatt-Haines citada anteriormente: Gerentes de Relacionamento, ao
invs de analistas de negcios.
O RUP (Rational Unified Process), famoso por sugerir algumas dezenas de papis em equipes de
desenvolvimento, tem vrios nomes para o AN: Business-Process Analyst, Business Designer e Use-
Case Specifier. Mas ele no lista o termo Analista de Negcios9.
No entanto, com a mdia e principalmente o IIBA promovendo o nome Analista de

Negcios, fcil supor que este ser o termo mais comumente aceito. Mesmo que suas
responsabilidades e habilidades permaneam nebulosas por um certo tempo.
Independente do nome, afinal, como se d a formao de analistas de negcios, ou de

requisitos, processos ...?
9 The Rational Unified Process An Introduction (Second Edition). Philippe Kruchten. Addison-Wesley (2000).
18 Captulo 2
Formando Analistas de Negcios

Ainda no existem cursos tcnicos ou de graduao que tratem exclusivamente da formao de
analistas de negcios. A exemplo do que ocorre com gerentes de projetos, talvez esses cursos
nem venham a existir. Ou melhor, existiro na forma de cursos de extenso, ps-graduao ou
especializao. Tendo em vista os cursos regulares oferecidos atualmente, aquele cujo
currculo mais se aproxima da profisso conhecido no Brasil como Sistemas de Informao.
No entanto, como colocado anteriormente, os currculos vigentes do enorme nfase ao

domnio da soluo: estudantes aprendem lgica e programao, modelagem de sistemas e at
noes de gerenciamento de projetos. Mas pouco ou nada veem sobre o entendimento do
negcio, clientes e usurios ou seja, o conhecimento de mtodos e prticas que levam ao
domnio do problema.
Nem sempre foi assim. Cursos e publicaes voltadas para os analistas de sistemas, em um
passado no muito remoto, se preocupavam mais com a definio do problema a ser resolvido.
No parece ser coincidncia que tais temas tenham evaporado to logo o mercado sinalizou
com forte demanda por analistas-programadores. Ao interpretar etapas da anlise de sistemas
como atividades que agregavam pouco ou nenhum valor aos projetos de desenvolvimento, a
soluo descoberta foi a simples eliminao dessas fases. No so raros os depoimentos de
analistas que, to logo alocados em um projeto, devem gerar cdigo. Por isso no me
surpreendo quando pesquisas indicam que cerca de 70% de nossos projetos falham atrasam,
custam mais ou simplesmente so cancelados. Surpresa, dado o cenrio atual, seriam 70% de
projetos de sucesso. Mas... retornemos ao tema central deste tpico.
Por sua atuao muito prxima ou mesmo subordinada a rea de TI, espera-se que o AN tenha
uma formao tcnica. Noes bsicas de lgica, modelagem de dados e sistemas e at mesmo
de alguma linguagem de programao do considervel estofo para um AN. Mas isso no
deveria ser visto como um pr-requisito. E, felizmente, o mercado parece estar vendo desta
maneira. Empresas esto empregando administradores de empresas, contadores e at
publicitrios como analistas de negcios. Se a ausncia de um background tcnico sentida, por
outro lado esses profissionais levam para as empresas pontos de vista e conhecimentos novos,
diferentes daqueles que predominam em uma organizao de TI.
No final das contas, tudo uma questo de equilbrio. Aqueles com formao tcnica devero
desenvolver conhecimentos sobre administrao e contabilidade, por exemplo. Enquanto isso,
os demais AN's devero conhecer um pouco mais sobre sistemas, arquitetura de aplicaes etc.
Este livro recomenda que um AN nunca atue sozinho, em nenhuma situao. Ele sempre
acompanhado de outro analista. Sendo assim, fcil compor uma dupla com um profissional
com formao de TI e outro de outra rea qualquer. Alm da troca de conhecimentos, do
aprendizado conjunto, a dupla oferece ao projeto perspectivas totalmente complementares.
Mas, afinal, qual a formao de um analista de negcios? Quais habilidades ele deve
desenvolver?
Habilidades
No est no escopo deste livro o estudo das habilidades sociais que devem ser desenvolvidas
por um AN. Apesar de no fazer parte do time que acha que este tipo de habilidade inata e
ponto, devo confessar minha total incapacidade de repassar esse tipo de conhecimento. Claro,
no decorrer do livro no hesitarei em apresentar alguma dica, quando consider-la realmente
vlida. Mas, definitivamente, no sei falar muito sobre liderana, negociao, postura,
meditao e levitao. Me limitarei a apresentar uma breve lista de habilidades sociais mais
importantes que um AN deve demonstrar. Depois, de maneira menos escorregadia, tratarei das
habilidades tcnicas, estas sim o foco deste trabalho.
Habilidades Sociais
Em ingls elas so chamadas de soft skills. reconhecido que sua transferncia, na forma de
cursos de treinamento e principalmente de livros, um tanto mais complicada. Enquanto
algumas pessoas apresentam grande facilidade para assimil-las, outras simplesmente
manifestam barreiras que parecem intransponveis. Tomemos como exemplo o ato de falar em
pblico. Todos conhecemos diversas pessoas que tem verdadeiro pavor de subir em um palco e
se pronunciar para um grupo de pessoas. Se este o seu caso, comece a ficar preocupado: um
AN deve falar em pblico em diversas ocasies, facilitando sesses de workshop ou
apresentando alternativas de solues. J vimos, a comunicao uma das principais
responsabilidades de um AN. A facilidade de comunicao, em qualquer meio, uma das
principais habilidades soft que ele deve desenvolver.
O que podemos afirmar que, mais que treinamentos e miraculosas tcnicas para
destravamento total, a prtica constante que lapida nossas habilidades sociais. A menos que
voc tenha algum trauma (trava) realmente srio, considere a prtica frequente e as crticas de
seus colegas como suas principais fontes de aprendizado de habilidades soft.
A lista abaixo destaca as principais habilidades sociais que um AN deve desenvolver:
Aprendizado: um bom AN aprende rpido. E aprende direito. Sabe identificar as

fontes mais ricas e eficazes e extrair delas todo conhecimento necessrio. O AN tem o
hbito de ler e de estudar. Quando confrontado com um novo negcio ou cenrio, no
hesita em disparar um processo de pesquisa. Em tempos de Internet e principalmente
de Google, o bom AN sabe que no existem muitos impedimentos ao seu estudo.
O AN no tem medo de perguntar. E sabe que nada bvio quando se trata de
negcios e sistemas de informao. Entende que pode ser confundido com um chato de
vez em quando, mas que isso faz parte de seu trabalho. E faz perguntas e mais
perguntas, como uma criana de 3 anos de idade.
O AN tambm sabe que o conhecimento tcito, aquele que est na cabea das pessoas,
pode ser s uma parte do que ele precisa. Por isso ele tambm aprende ao ler
documentos, diagramas, sistemas e outros diversos tipos de conhecimento explcito.
Comunicao: o AN um exmio comunicador. Conversando, escrevendo,

apresentando e facilitando eventos no importa o meio ou o pblico. Se o principal
problema que o AN veio resolver de comunicao entre reas de negcios e TI,
simplesmente o cmulo do absurdo imaginar um AN que no saiba se comunicar
20 Captulo 2
muito bem.
O que no pode significar que aquele tmido ou aquele relaxado no podem se
transformar em excelentes AN's. Todo mundo, em todas as profisses, um dia teve que
comear. Quando bem guiados, tmidos, relaxados e afins sabero driblar suas
limitaes. Um aspecto particularmente importante a comunicao do AN com a
equipe tcnica. Ele precisar ensinar alguns conceitos e termos de negcio para
coordenadores e desenvolvedores. Saber ensinar tambm deve fazer parte do currculo
do analista de negcios.
Negociao: no basta se comunicar bem, o AN deve negociar bem. Em diversos

momentos de um projeto isso quase tudo o que ele estar fazendo: negociando o
escopo com usurios e desenvolvedores, combinando prazos, avaliando mudanas.
Como bom negociador, o AN elimina ou reduz atritos e rudos.
Sua capacidade de negociao pode ser especialmente exigida quando a viabilizao de
um projeto estiver sob sua responsabilidade. A obteno de apoio da alta direo, os
acertos com o patrocinador, a reviso de prioridades com a organizao de TI tudo
isso negociao.
Pensamento Sistmico: habilidade que em algumas rodas chamada de (ante)viso

do jogador de xadrez e em outras de sexto sentido. Falando srio, esta a famosa
Quinta Disciplina de Peter Senge10, que para o AN tem dois significados
fundamentais: i) ver inter-relacionamentos, em vez de cadeias lineares de causa-efeito; e
ii) ver os processos de mudana, em vez de simples fotos instantneas.
O AN entende que durante um projeto o negcio continua vivo e que, desta forma,
segue sujeito e gerador dos mais diversos tipos de mudanas. E entende que o prprio
projeto uma mudana, o que o leva a desenvolver uma ampla viso de todos os
impactos que podem ser gerados por ele.
Capacidade de Sntese: o AN deve ser capaz de, a partir de informaes diferentes

oriundas dos mais diversos lugares, gerar um todo que seja coerente. Ele sabe destacar
aquilo que realmente fundamental em determinado contexto e, o mais importante,
compilar dados e informaes de forma a gerar um conjunto ntegro, alinhado e
factvel.
Quando falamos de modelagem de negcio estamos falando de simplificao. O bom
AN sabe que um bom modelo de negcio se limita aquilo que realmente necessrio
para um projeto. J na engenharia de requisitos, no entendimento dos usurios, o AN
busca a uniformizao e organizao de todos os dados e informaes desenvolvidas.
assim que ele demonstra sua capacidade de sntese.
Viso Crtica e Criativa: o bom AN sabe que no pode se limitar aos requisitos
apresentados pelos usurios. Isso porque ele entende que os requisitos, logo que
surgem, carecem de desenvolvimento, de amadurecimento. Por isso apresenta crticas e
novas sugestes, debatendo-as com usurios e desenvolvedores.
10 A Quinta Disciplina, Peter M. Senge. Editora Best Seller (2000).

Habilidades Tcnicas
Tambm conhecidas como hard skills, em ingls. o tipo de conhecimento mais fcil de ser
transferido, tanto em processos de socializao (treinamento, por exemplo), quanto em
processos de internalizao (a partir de livros, apostilas e afins). No decorrer deste livro
apresentarei diversas tcnicas, ferramentas e mtodos que devem formar a base de habilidades
tcnicas de um analista de negcios. Neste momento me limitarei a listar e descrever
brevemente as principais habilidades hard que um AN deve desenvolver. Vamos a elas:
Modelagem: a capacidade de gerar abstraes de algo que existe no mundo real.

Uma habilidade que tambm pode ser apresentada como Pensamento Visual11. Do
AN ser cobrado, principalmente, a capacidade de gerar modelos de negcios. Mas
importante que ele tambm saiba gerar outros modelos. Abaixo uma lista com os mais
importantes:
Modelagem de Negcios: representao dos aspectos mais importantes de um

negcio em determinado contexto, determinado projeto. Aqui o AN entende que
menos mais. Negcios so complexos por natureza. Um modelo de negcio no
tenta reproduzir todos os detalhes, pelo contrrio. Ele se limita ao que
estritamente fundamental para entender o negcio e comunicar tal entendimento.
Como a modelagem de negcios muito mal compreendida (e mal falada), vale a
pena adiantar aqui que Balanced Scorecards e Mapas Estratgicos, por exemplo,
podem fazer parte de um modelo de negcio.
Modelagem de Dados: dados e informaes so recursos de uma empresa.

Consequentemente, podem fazer parte de um modelo de negcios. Mas aqui o AN
entende que existem regras e padres especficos para a modelagem de dados,
baseados principalmente nas teorias da modelagem Entidade-Relacionamento e
modelagem multidimensional.
Modelagem de Sistemas: claro, no muito recomendado que um AN seja

convocado para desenvolver um modelo de sistema. Mas saber ler um modelo de
sistema pode ser necessrio, particularmente nas interaes com a equipe de
desenvolvimento. Noes bsicas de modelagem, particularmente aquela orientada
a objetos, so necessrias. O conhecimento do padro de facto para modelagem de
sistemas, a UML (Unified Modeling Language), tambm. Cabe adiantar que sugiro a
utilizao desta mesma linguagem para a gerao de vrios diagramas que podem
compor o modelo de negcios.
Prototipao: porque prottipos so modelos. O AN deve conseguir gerar

desenhos que representem idias. Prottipos de interfaces talvez sejam os mais
exigidos, mas no so os nicos. O desenho de Storyboards que representem
navegaes entre telas ou a simulao de um trecho de um processo de negcio
tambm uma habilidade que o AN deve assimilar.
11 O termo Pensamento Visual sugerido, por exemplo, por Dan Roam no livro The Back of the Napkin
Solving Problems and Selling Ideas with Pictures, Portfolio (2008).
22 Captulo 2
Engenharia de Requisitos: tentei encontrar outro nome para esta habilidade mas no
aparaceu nenhum melhor que este. Engenharia de Requisitos compreende um vasto
conjunto de habilidades hard que um AN deve dominar. As principais so:
Tcnicas para o Desenvolvimento de Requisitos: entrevistas, sesses JAD

(Joint Application Development), workshops, engenharia reversa, observao ativa e
passiva, pesquisas e outras. O AN tem a sua disposio um leque de alternativas
para efetivamente entender o usurio, suas necessidades e restries. Cada projeto
ou usurio pode requerer o uso de uma ou outra tcnica. importante que o AN
demonstre versatilidade e agilidade para escolher as tcnicas mais apropriadas.
Especificao e Estruturao da Voz do Usurio12: o usurio fala muita

coisa, pede outro tanto. Em conversas ou documentos ele mistura requisitos, regras
de negcios, definies de dados, requisitos de interface e mais um sem nmero de
informaes. Ele no precisa saber distinguir uma regra de um requisito, por
exemplo. Essa responsabilidade exclusiva do AN. Saber organizar a voz do
usurio uma das habilidades mais caras que um analista deve apresentar.
Diretamente relacionada com uma habilidade soft citada anteriormente, a capacidade
de sntese. Aqui falamos exclusivamente da poro hard deste trabalho, que
demanda o domnio de tcnicas e ferramentas que viabilizam a especificao e
estruturao de requisitos e demais informaes aprendidas.
Redao de Casos de Uso: um documento criado especificamente para facilitar a

descoberta e descrio dos requisitos funcionais de um sistema. Durante o
desenvolvimento deste trabalho fui surpreendido com o tamanho da confuso que
existe em torno desta tcnica que, a princpio, deveria ser muito simples. Casos de
uso foram inventados por Ivar Jacobson13 no final da dcada de 1960, para entender
melhor os requisitos de um sistema de telecomunicaes. A tcnica ganhou pblico
quando foi incorporada linguagem de modelagem UML. Infelizmente, ganhou
pblico e um show de desinformao.
Preparao e Execuo de Testes: porque o AN a ltima pessoa que testa uma

aplicao antes do usurio final. A preparao acontece quase que simultaneamente
ao registro dos requisitos, atravs da redao de casos de testes, por exemplo. Aqui o
AN fixa todos os critrios de aceite, indicando para a equipe de desenvolvimento
todos os testes que executar quando receber a aplicao. So testes do tipo caixa-
preta, ou seja, visam exclusivamente validar a conformidade da aplicao em
relao aos requisitos apresentados.
Viabilizao da Soluo: alm das habilidades sociais necessrias para a viabilizao

de um projeto, como comunicao e negociao por exemplo, o AN tambm deve
dominar habilidades tcnicas com tal fim. Merecem destaque: redao de documentos
de viso ou propostas tcnicas; elaborao de apresentaes; facilitao de workshops;
matemtica financeira; e gerenciamento de portflios.
12 Termo utilizado originalmente por Karl Wiegers em Software Requirements, Microsoft Press (1999).
13 http://en.wikipedia.org/wiki/Ivar_Jacobson
Especializao
Ao dominar as habilidades sociais e tcnicas listadas acima o AN est pronto para atuar em
diversos tipos de projetos para negcios de qualquer porte ou natureza. Ele um AN
genrico. Ou horizontal, para usar um termo que parea menos pejorativo. Se ele atua em
uma empresa que presta servios de desenvolvimento ou consultoria, atendendo diversos tipos
de clientes, exatamente isso que ser esperado dele: que ele tenha condies de atuar em
qualquer tipo de organizao.
No entanto, ser exigido que ele seja ainda mais gil no aprendizado, aquela primeira
habilidade social apresentada. recomendvel que ele faa um tipo de imerso na histria de
um cliente e na situao do ecossistema ao qual ele pertence antes do primeiro contato. Cliente
nenhum gosta de ensinar o be-a-b sobre seu ramo de atividades quando tudo o que ele
precisa um novo sistema. E o tempo sempre curto demais.
Por isso factvel supor que, com o tempo, o AN horizontal vai se especializar em alguns
tipos de negcios. Dois ou trs projetos dentro de uma mesma rea, no necessariamente para
um mesmo cliente, podem ser suficientes para gerar um conhecimento muito bom sobre
aquela atividade. Conhecimento que a empresa prestadora de servios, se atenta, apresentar
como um diferencial competitivo.
Situao diferente daquele AN que atua apenas em uma empresa. A necessidade de

especializao naquele ramo de atividade bvia. Desta forma temos um analista mais
vertical, especialista em determinado ecossistema de negcios14.
Mais do que uma habilidade que se aprende na escola, a especializao em determinado ramo
de atividades fruto da experincia, de considervel tempo de estrada. Ela pode ser
desenvolvida de maneira intencional, planejada. Pelo AN ou pela empresa para a qual trabalha.
Mas tambm pode ser consequncia de uma srie no consecutiva de projetos. Esta foi a minha
experincia e de alguns AN's que trabalharam comigo. Em determinado momento
percebemos, por exemplo, que poderamos explorar melhor a rea de seguros porque o
conhecimento acumulado em projetos anteriores se configurava uma interessante vantagem
competitiva.
Outro tipo de especializao possvel por tipo de soluo. Podemos ter AN's especialistas em
projetos de ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), SCM
(Supply-Chain Management), PLM (Product Life-Cycle Management), MEG (Me Engana que eu
Gosto) e diversas outras STL's (siglas de 3 letras). No mundo SAP, por exemplo, os AN's so
conhecidos como Consultores Funcionais.
O mais importante para o AN entender que antes de qualquer tipo de especializao ele deve
buscar o domnio do bsico, daquela lista de habilidades sociais e tcnicas apresentada acima.
14 Ecossistema significa tudo e todos que giram em torno e dentro de um negcio, seus clientes, fornecedores,
parceiros comerciais, concorrentes, legislao e marcos regulatrios, produtos e servios, alm dos sistemas.
24 Captulo 2
Analistas de Negcios Por que agora?

A questo acima mais fcil de responder do que por que s agora?. Guardies de um
estranho status quo gostam de dizer que a crescente demanda por analistas de negcios s uma
moda. Talvez seja mesmo. Talvez, a exemplo de vrias outras modas que caracterizam o mundo
de TI e dos negcios, esse movimento todo no dure mais do que 3 ou 4 anos. Mas surgir
ento outro termo arquiteto de negcios, projetista de negcios, analista de organizao &
mtodos (ops15) e essa nova profisso dever dominar praticamente tudo o que um AN
aprende hoje. Em nossa rea assim mesmo: vo-se os nomes, ficam os conceitos e,
principalmente, as necessidades.
Vamos aos fatos:
1. Negcio e TI nunca tiveram um relacionamento muito amistoso. No por acaso o tal

alinhamento estratgico vive no topo da lista de prioridades de 9 entre 10 gestores de
TI.
2. Cerca de 70% dos nossos projetos atrasam e / ou estouram oramentos e / ou so

cancelados. Dentre as causas mais comuns sempre aparecem: i) problemas com o
entendimento dos requisitos; ii) a participao dos usurios; e iii) mudanas de escopo.
3. Desenvolvedores e coordenadores de projetos no esto sendo treinados para entender

o negcio e os usurios.
4. O mundo dos negcios nunca foi to voltil e dinmico, o que aumenta

consideravelmente os riscos de TI e particularmente de seus projetos.
Alinhar, acompanhar o ritmo do negcio, muitas vezes parece ser o mesmo que pedir
para que voc, com um velocpede, tente acompanhar Massa em sua Ferrari.
5. O conhecimento sobre o negcio est espalhado entre diversas pessoas, lugares e

sistemas. Dependendo da empresa, simplesmente ningum tem uma viso do todo. A
concorrncia entre silos pelos caros recursos apenas complica ainda mais o panorama.
Por tudo isso e mais um pouco, a figura do AN surgiu e vem ganhando relevncia. claro que
o analista de negcios no o nico recurso disposio das organizaes de TI para a busca
do alinhamento estratgico. Mas , sem sombra de dvidas, um dos mais importantes. aquele
que pode demonstrar no dia-a-dia o comprometimento com essa busca, atravs do
relacionamento com as reas de negcios e da entrega de bons projetos.
Ou seja, ningum deveria ter dificuldades para justificar a contratao ou alocao de AN's em
uma equipe. Ento, a pergunta que fica : por que s agora? Sinceramente, no sei dizer.
15 Gosto de dizer que os analistas de O&M so, de certa maneira, os bisavs dos analistas de negcios. Falo um
pouco mais sobre isso no quadro Darwin e os Analistas.
Darwin e os Analistas
Darwin ficou famoso por descobrir e dizer que as espcies, todas as espcies vivas da face da
terra, evoluem. Ele contou que no so os mais fortes, os mais inteligentes ou aqueles que
gritam mais alto que sobrevivem so aqueles que melhor se adaptam s mudanas.
Todo mundo j gastou essa teoria fazendo analogias com o universo dos negcios e de TI.
Tirarei minha casquinha.
Era uma vez... uma empresa, l nos anos 50, animadssima com as possibilidades oferecidas
por um novssimo fruto da genialidade humana, o tal crebro eletrnico. Contabilidade, folha
de pagamentos, clculos e mais clculos. As possibilidades eram lindas e maravilhosas. Mas,
ita engenhoca difcil de operar!.
Uma rebelio de empresas usurias quase decretou a morte da informtica ainda em seus
primeiros anos de vida. Quase, porque um sbio vendedor da IBM debelou o conflito e salvou
nossa rea16. Coincidncia ou no, nasciam ali tambm os primeiros analistas.
As reas de negcios, guiadas por manuais tayloristas17, tambm criaram seus analistas: os
Analistas de Organizao & Mtodos. Assim mesmo, com um e comercial. Mas os analistas
de TI e de O&M s se encontravam por acidente. Ou naquelas raras vezes em que o cara de
O&M tentava organizar aquela baguna ento conhecida por CPD (Centro de Processamento
de Dados). Alis, TI no se chamava TI ainda. Era s um CPD. Uma caixa preta com um
monte de gente esquisita falando lnguas esquisitas. COBOL? Fortran?
O tempo passou, Jobs e Gates inventaram a microinformtica e alguns annimos (intencionais

ou no) inventaram os Analistas de Sistemas. Gente que tinha que estudar o problema de
negcio e solucion-lo atravs de sistemas de informao. Novo conflito. Por um breve
perodo os analistas de O&M foram renomeados. Viraram Analistas de Organizao, Mtodos
& Sistemas. No adiantou. Eles seguiram chatos, imutveis e com um e comercial no nome.
No se adaptaram. No estudaram sistemas. No entenderam o Visicalc. Foram extintos.
Vitoriosos, os Analistas de Sistemas comearam sua saga. Dramtica saga. Breve saga. Negcios
comearam a entender que os computadores podiam sim fazer a diferena. O impacto da
Internet ento, nem me diga. E tudo para ontem, anteontem... Buscando adaptao, os
analistas ganharam um sobrenome: programadores. Da para o mal interpretado mundo Agile,
onde muita gente prega zero-documentao, zero-modelo, foi um pulinho. Alinhamento?
Coloca o usurio sentado ao lado do programador que a coisa sai! Programador?
Sim, o Analista de Sistemas se foi. Aconteceu to rpido que nem enterro teve.
Eis que surge, sem convite, o tal analista de negcios. Incorrigvel, o mundo de TI j trata de
fazer suas adaptaes: j tem gente contratando AN com experincia em Java!
16 Est aqui um trecho que no s fico e palpite no. Esta histria deliciosa est muito bem documentada em
From Airline Reservations to Sonic the Hedgehog A History of the Software Industry, livro de
Martin Campbell-Kelly. MIT Press (2003).
17 De Taylor, ou Frederick Winslow Taylor ( http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor ).

26 Captulo 2
do Negcio ou de TI? 27
Captulo 3
do Negcio ou de TI?
Que dilema! Se o analista de negcios atua como um tipo de ponte entre as reas de negcio e
de tecnologia, a quem ele deve ser subordinado? Este captulo no estava previsto no plano
original do livro. Mas se tornou necessrio depois de minhas andanas e conversas. No h
uma resposta clara para a questo e, provavelmente, nunca haver um padro.
Originalmente o AN brotou nas dependncias de TI. Na maioria das vezes um profissional

formado em algum curso de tecnologia. Tanto que h quem defenda, por exemplo, que ele seja
um gerente de relacionamentos da organizao de TI com as reas de negcios.
Por outro lado, existem empresas que veem o AN como um SME (Subject Matter Expert), um
especialista em determinado tema do negcio. E que, como tal, deve responder diretamente
para a respectiva rea de negcio.
H tambm a terceira via, que cria um departamento exclusivo para a anlise de negcios. Um
departamento totalmente independente de TI e das reas usurias. Em algumas empresas os
AN's esto sendo alocados no departamento de marketing!
Neste captulo sero apresentadas as trs alternativas, os prs e contras de cada uma delas.
Parece haver um desenho mais adequado para cada tipo de negcio. Mas, ao invs de
apresentar concluses, me limito a oferecer subsdios para que voc decida qual o modelo mais
adequado para sua situao. Claro que essa discusso no faz muito sentido se sua empresa
presta servios de consultoria e / ou desenvolvimento. Mesmo assim, evite a tentao de pular
diretamente para o prximo captulo. Explico: saber como seus clientes podem estruturar essa
funo pode ser muito importante. Voc vai se relacionar com os AN's de seus clientes. Alm
disso, ateno para o pargrafo abaixo.
Outro tpico abordado aqui a formao de equipes de projetos. Independente de qual seja
seu departamento, o AN deve ser alocado em projetos. Qual a melhor estrutura para acomod-
lo? Como minimizar as possibilidades de conflito entre ele e a equipe tcnica? Afinal, como se
d o relacionamento entre desenvolvedores, arquitetos, coordenadores e o analista de negcios?
No decorrer desse papo apresentarei algumas estruturas alternativas, que visam principalmente
ao aprendizado, a troca de experincias entre os analistas. Comunidades de prtica, centros de
excelncia e escritrios de anlise de negcios sero apresentados e avaliados.
Pois : como este captulo poderia no existir? Tsc, tsc...

28 Captulo 3
O Analista de Negcios de TI
A princpio este parece ser o desenho mais natural. O AN, assim como analistas de sistemas,
desenvolvedores, administradores de redes e o pessoal de suporte, subordinado ao
departamento de tecnologia da informao. provvel que ele no seja especializado em
nenhuma rea de negcio especfica, como vendas, produo ou finanas. Pelo contrrio, a
organizao de TI deve apresentar uma pequena equipe de AN's1 capaz de navegar por todas as
reas da empresa. Ser exigido, isso sim, que ele conhea muito bem o negcio da empresa.
Este desenho apresenta as seguintes vantagens:
Menor probabilidade de conflitos com desenvolvedores e demais integrantes da equipe

tcnica. Isso porque h uma convivncia frequente e todos trabalham de acordo com
uma mesma filosofia compartilham valores, padres, mtodos e prticas.
Por ser um desenho centralizador, TI tem mais poder de deciso sobre prioridades de
alocao dos AN's.
mais fcil garantir que a metodologia ou processo de desenvolvimento est sendo

obedecido.
E desvantagens:
A centralizao tambm pode ser uma desvantagem. Dependendo da proporo entre o

nmero de solicitaes e a quantidade de AN's disponveis, podemos ter aqui um
belssimo gargalo. Alm disso, oportunidades de negcio podem ser negligenciadas, as
prioridades podem estar equivocadas.
Isso tambm pode gerar um volume maior de atritos com as reas de negcio. Conflitos
que, no raro, devem ser intermediados por algum que est acima na hierarquia da
empresa.
Como o AN de uma estrutura centralizada naturalmente genrico, h uma certa

lentido quando ele tem que aprender uma atividade ou situao de negcio indita.
Este problema consideravelmente reduzido quando a rotatividade de profissionais
baixa.
Uma grande empresa nacional de telecomunicaes utiliza este desenho. E chama a equipe de
AN's de Ponto Focal. Dado o porte da empresa, os analistas so divididos por reas de
negcio ou tipos de processos: Produtos, Atendimento e Processos de Apoio so alguns
exemplos. O quadro No Meio do Tiroteio detalha um pouco mais esse caso.
Quando o analista de negcios est subordinado rea de TI o processo de trabalho ocorre

mais ou menos assim: um departamento ou seo manifesta a necessidade de uma nova
aplicao. Esta solicitao entra na lista de pendncias (backlog) da rea de TI. O quanto antes
um AN deve ser destacado para entender um pouco mais o problema em questo. S assim a
solicitao pode ser priorizada posicionada no backlog. A priorizao negociada com a rea
1 No final deste captulo falo sobre O Tamanho da Equipe.

solicitante. Todo mundo quer tudo para ontem, e TI deve ter uma boa justificativa caso aquele
pedido no merea estar no topo de sua lista de afazeres.
A sequncia acima ridiculamente simplista e esconde uma srie de variveis. Exploremos um

pouco mais o tema.
Quando chega uma nova solicitao, nem sempre possvel dizer se se trata de uma nova
aplicao ou de uma alterao em um sistema existente. O porte da alterao tambm pode ser
uma incgnita. Como o usurio nem sempre tem essa informao, de se esperar que
solicitaes assim apaream em outro canal: no help-desk, por exemplo. Quem gosta de dizer
que atendimento nvel 1 coisa de analista de suporte jnior deveria parar e pensar um
pouquinho. Aqui nascem alguns srios conflitos entre reas de negcio e TI. Como o analista
de suporte jnior pode ter condies de dizer se aquela solicitao pequena ou grande, se
gerar demanda por manuteno em um sistema legado ou um novo projeto?
Confrontadas com a situao descrita acima, algumas empresas tomaram uma deciso bastante
perdulria: alocam AN's para cuidar at de pequenas demandas. Justificam o desenho
apresentando uma soluo para outro problema: a padronizao das solicitaes. A coisa to
maluca em algumas empresas, que o mesmo padro utilizado para novos sistemas deve ser
obedecido em pequenas solicitaes de manuteno. Imagine o processo: um AN tentando
escrever casos de uso, prottipos e uma detalhada especificao, repleta de justificativas, s
porque o usurio pediu o acrscimo de um novo campo numa tela qualquer. Pode parecer
absurdo, mas acontece.
A demanda por manuteno e correes de sistemas legados imensa em um grande nmero

de empresas, dos mais diversos portes. , no popular, um indigesto abacaxi que as organizaes
de TI engolem diariamente. Longe de mim apresentar alguma sugesto para adoar um
pouquinho o abacaxi2. Me preocupa aqui que o AN, uma posio cara e rara, seja
desperdiado. Usurios e analistas de suporte deveriam ser orientados para qualificar
minimamente as demandas. O AN deveria ser acionado apenas quando a demanda realmente
exigir um melhor entendimento do negcio e dos usurios. Enfim, quando a demanda
realmente tiver uma maior importncia para o negcio.
2 Hmm.. no me segurei. Ento vo no uma, mas duas sugestes: i) SOA (Arquitetura Orientada a Servios);
e / ou, ii) uma velha dica do Gartner: aposente 2 ou 3 sistemas legados por ano, comeando por aqueles que
no passam em qualquer avaliao bsica de custos x benefcios.
30 Captulo 3
No Meio do Tiroteio
A empresa, fruto de algumas fuses, tem um pssimo histrico de relacionamento entre reas
de negcio e o departamento de TI. Em determinado momento a coisa ficou to feia que
usurios passaram a estudar sistemas. No as funcionalidades oferecidas, mas o interior das
aplicaes. Tanto que alguns aprenderam a linguagem SQL! No sei dizer se alguns se
arriscaram a colocar a mo na massa, mas o fato que algumas de suas solicitaes j
apresentavam a soluo pronta o cdigo que deveria ser implementado. Em outras situaes
eles descreviam campos e tabelas que deveriam ser alterados.
A empresa mudou, e duas reas foram criadas para receber e filtrar todas as solicitaes
recebidas. A primeira cuida do entendimento do problema e da especificao deste de forma
padronizada. A segunda, um centro de solues, cuida do relacionamento com os
fornecedores. Sim, praticamente todas as atividades de manuteno e desenvolvimento de
sistemas foram terceirizadas.
O problema que os traumas dos usurios permanecem. E os maus costumes idem. O

departamento que foi criado para o entendimento do problema visto como um empecilho.
As atividades desta rea so consideradas suprfluas por muitos usurios. Sendo assim, alguns
deles simplesmente passam por cima dos AN's, negociando suas solicitaes diretamente com
o centro de solues. A primeira rea s avisada quando sua assinatura necessria. Ou seja,
pura burocracia.
Sob o ponto de vista de alguns usurios, tudo pequeno, tudo facinho facinho. A coisa
piora muito quando o usurio se esquece que a empresa no se limita ao seu departamento,
que podem existir outras prioridades. Ento ele fura a fila, sem noo das consequncias.
curiosa a grande criatividade dos usurios. A empresa estipulou que existem dois tipos de
solicitaes: as pequenas e as grandes. Estas devem ser tratadas como projetos. Os usurios
sabem que projetos seguem um ritual diferente, mais demorado. Ento eles fatiam suas
solicitaes e as apresentam pequenas demandas em intervalos regulares de tempo. Demora
at o departamento de TI perceber que est sendo ludibriado.
Talvez o problema no fosse crtico se a qualidade dos servios prestados pelas fbricas no
fosse to ruim. Mas o fato que muitas aplicaes e at pequenas alteraes so entregues com
muitos erros. No necessria muita esperteza para perceber que muitos desses bugs so frutos
exclusivos dos atalhos que foram tomados.
Mas, como eu disse, o servio das fbricas de software ruim. Ento mesmo aquelas
solicitaes que seguem sem desvios o manual, sofrem com erros e funcionalidades diferentes
daquelas esperadas pelos usurios. O estranho que as empresas, esta em particular, acreditam
que a culpa delas que o problema est na qualidade da especificao que entregue para as
fbricas. E passam a exigir especificaes ainda mais detalhadas, e colocam mais e mais pontos
de checagem. Consequncia: o processo se torna ainda mais lento, os usurios mais
insatisfeitos, os AN's mais criticados... nessa baguna toda, nesse ciclo vicioso, s um lado sai
ganhando: as fbricas de software.
O AN do Negcio
E cada rea usuria possui o seu. indiscutvel que este desenho confere um pouco mais de
agilidade ao processo. O AN exclusivo de um departamento. Ou seja, ele deve saber tudo
sobre ele, a localizao exata de cada clipe de papel. Mas essa alternativa , de certa forma, um
luxo. Afinal, departamento algum tem demanda suficiente para ocupar um AN o tempo todo.
Sendo assim, de se esperar que este profissional tenha alguma outra atribuio. O que
percebi em algumas empresas que usurios com mais tempo de casa desempenham a funo
de AN's em projetos. So temporariamente alocados para representar o departamento em um
empreendimento. Seus afazeres cotidianos so assumidos por outro colaborador at o trmino
do projeto.
Vantagens deste modelo:
O domnio do negcio, do problema, total. Ou, colocando de outra forma, o

aprendizado se d de maneira muito mais rpida.
Como o AN tambm um usurio direto ou indireto da soluo em questo, seu

ponto de vista tende a ser muito mais respeitado pela equipe tcnica.
A possibilidade de enganos e mal entendidos minimizada. De certa forma, h um n a

menos na rede de comunicaes do projeto.
A contrapartida, ou os riscos inerentes a este modelo:
Este AN no tem uma formao tcnica. Se no dominar as disciplinas que formam a

anlise de negcios, ser apenas um usurio. (Entendam, no estou menosprezando os
usurios. Apenas estou dizendo que no podemos confundir usurios com AN's).
O AN pode no respeitar integralmente os padres e o processo de desenvolvimento

estipulados pelo departamento de TI. O problema minimizado ou eliminado se ficar
clara a subordinao do AN ao gerente do projeto.
Se um projeto atende, por exemplo, trs departamentos, teremos ento trs AN's. Cada
um defendendo seu lado. Incorpora-se assim, equipe de projeto, os conflitos que
normalmente existem entre departamentos.
Pode faltar uma viso do todo. Talvez este seja o risco mais srio. Se cada AN olha
exclusivamente o seu departamento, quem se preocupa com o negcio ou processo
como um todo?
L no incio do captulo eu prometi uma certa iseno, mas preciso dizer que este desenho
parece mais moderno, mais gil. Ele parece fazer muito sentido em mdias e grandes empresas,
particularmente naquelas que renovam sua carteira de produtos e servios com bastante
frequncia, como bancos, seguradoras e empresas de telecomunicaes. Esta renovao sempre
significa novos projetos ou grandes alteraes em aplicaes existentes.
reas de apoio, como contabilidade, RH e o departamento financeiro, no precisam de AN's

32 Captulo 3
exclusivos. Podem compartilhar um pequeno pool. Mas as reas nervosas dessas empresas,
como marketing, produtos e vendas, podem se beneficiar muito com esta interface chamada
AN. Como j foi colocado, o nico grande risco deste modelo pode ser a falta de uma viso
mais ampla do negcio e seus processos. Um risco que pode ser mitigado com a instituio de
uma comunidade de prtica, sugesto que ser apresentada posteriormente neste captulo.
Podemos transformar um usurio-chave em um analista de negcios? Sim, por que no?

Mesmo que no incio existam algumas deficincias no conhecimento de arquitetura de
aplicaes, isso compensado pelo grande domnio de negcio apresentado. Mas, vale repetir
que fundamental que o usurio-chave seja de fato treinado para dominar as habilidades
tcnicas que caracterizam um AN. isso que vai garantir uma boa comunicao com a equipe
tcnica. Em um grande banco nacional, cujo modelo ser apresentado no tpico seguinte, tem
advogados, administradores e gente formada em letras em sua equipe de AN's.
O treinamento dos usurios-chave deve ser patrocinado e ministrado pela rea de TI. Assim,
alm das habilidades tcnicas, o novo AN tambm apresentado ao processo de
desenvolvimento utilizado pela empresa, aos seus padres, ferramentas e tecnologias.
Em outro cenrio, ainda neste modelo, as reas de negcio contratam AN's j formados. Neste
caso ser preciso um perodo de imerso. Mesmo que conhea o ramo de atividade em
questo, o AN precisar estudar a empresa e o departamento que o est contratando. Falo mais
sobre a seleo e contratao de AN's abaixo, ainda neste captulo.
O AN no de Ningum
Ou seja, existe um departamento autnomo de anlise de negcios que no subordinado
nem a TI nem a nenhuma rea de negcio especfica. Tamanha independncia realmente deve
significar uma privilegiada posio em todas as negociaes e situaes de conflito. Ou, por
outro lado, mais um chefe a ser chamado para acalmar nimos e encontrar uma soluo que
agrade a todos. Trata-se de um desenho curioso que vi em um dos maiores bancos nacionais.
Esta rea fora subordinada TI. Problemas que no conheo levaram a declarao de
independncia desta rea que agora conhecida como Departamento de Tecnologia do
Negcio. Estrutura estranha, nome mais ainda.
Vantagens superficialmente percebidas ou chutadas:
A independncia dos AN's possibilita a atuao destes como juzes realmente isentos.
Nos conflitos entre reas usurias e TI, to comuns, os AN's podem ter a ltima
palavra. Ou guiar o consenso.
Ao contrrio do modelo anterior, aqui a viso do todo mais fcil de ser obtida. Como
precisa atender todas as reas de negcio, mandatrio que o conjunto de AN's
conhea todo o negcio, sua estrutura, processos, motivaes e regras. Alm, claro, da
arquitetura de informaes e de aplicaes.
O preo pago, igualmente suposto:
Trata-se de um canal a mais de comunicao, um departamento a mais, uma estrutura

gerencial a mais. Alm do custo, maior que dos dois modelos anteriores, h o risco de
conflitos ainda mais difceis de serem sanados por envolverem agora um mnimo de
trs e no duas partes interessadas.
A consolidao dos protocolos de comunicao entre as reas, particularmente entre o

departamento de AN's e a rea de TI, mais lenta. Os processos de desenvolvimento e
gerenciamento foram divididos. As partes do processo que envolverem as duas reas
no podem ser alteradas sem o consentimento de ambas.
Devo confessar uma certa antipatia por este modelo. Em tempos de questionamento e
enxugamento das estruturas e dos processos de gesto3, difcil justificar a criao de um novo
departamento em uma empresa.
Parece, eu disse parece, que tiraram o bode da sala. Havia um srio problema de
relacionamento entre usurios e tcnicos? Ao invs de tratar o problema plantaram um
departamento entre eles. De qualquer maneira, se o problema foi remediado, quem sou eu
para questionar. S acho a soluo cara demais.
3 Aqui confesso extrema simpatia e forte influncia de O Futuro da Administrao, livro de Gary Hamel e
Bill Green. Elsevier-Campus (2008).
34 Captulo 3
Mas vamos trabalhar em outro cenrio. Imaginem uma empresa que trabalha apenas com um
tipo de produto ou servio. Um produto ou servio baseado em software. Neste caso faz
sentido que a equipe de AN's fique concentrada em um nico departamento, que no TI. H
pelo menos um caso no Brasil em que os AN's pertencem ao departamento de marketing. Aqui
sim o desenho faz sentido porque todo o trabalho dos analistas gira em torno dos produtos e
servios oferecidos. A subordinao ao dono do produto, marketing, garante agilidade e
alinhamento. Mas reparem que no se trata de um departamento de AN's, e sim de uma
variao do segundo modelo: uma rea de negcio dona dos AN's.
Escritrios de Anlise de Negcios

E por falar em antipatia e azedume... Queria muito 5 minutos cara-a-cara com o infeliz que
inventou os escritrios de projetos4. Este novo silo retrata duas coisas: o corporativismo e o
medo. Criaram um muro em torno dos gerentes de projetos, exatamente quem deveria
derrubar muros e mostrar para as empresas como o trabalho em equipes multidisciplinares.
Um contrasenso total. Mas nossa rea adora propagar pssimas idias. Eis ento que pipocam
sugestes de escritrios de processos e escritrios de anlise de negcios. Cus!
Puxo o tema aqui exatamente porque esses escritrios se assemelham ao modelo em que h
um departamento exclusivo para AN's. A diferena que os escritrios de AN's, pelo visto,
sero subordinados a TI. Mas, a exemplo dos PMO's (Project Management Offices), tero sua
estrutura gerencial e sua prpria burocracia. H justificativa?
Em todos os casos as desculpas so as mesmas: i) promover o gerenciamento de projetos (ou a

anlise de negcios); ii) treinar novatos; e, iii) garantir o respeito aos padres.
Primeiro: profisso nenhuma carece de promoo no interior de uma empresa. Se ela

instituda porque reconhecem seu valor e utilidade. Segundo: existem alternativas mais
baratas para treinamento e difuso de boas prticas. Terceiro: um escritrio por si s no
garante nada. Vai punir?
Acabei de me lembrar que naquele caso que contei l em cima, No Meio do Tiroteio, a
empresa retratada tambm tem um PMO. Olha s: AN's, um centro de solues, fbricas
terceirizadas e, como cereja do bolo, um escritrio de projetos. ou no uma beleza? Quatro
reas s para brigar com os usurios! Quanta covardia...
Peo desculpas pelo desabafo. Mas ele foi necessrio para que a alternativa apresentada abaixo
seja melhor avaliada.
4 E 10 minutos com o gnio que inventou as fbricas de software.

Comunidades de Prtica5
Em organizaes dos mais diversos portes e naturezas existem grupos informais que
compartilham informaes e conhecimentos. Esses grupos ou redes de contatos normalmente
giram em torno de um interesse comum. natural que tais redes extrapolem as fronteiras da
organizao, na forma de grupos de estudos e comunidades virtuais. Esses grupos nascem de
forma espontnea e seu crescimento orgnico. No h colaborao que no seja voluntria.
As organizaes podem tirar proveito dessas redes informais de contato para aumentar e
melhorar a qualidade de seu capital intelectual. Esses grupos podem ser convertidos em
Comunidades de Prtica que so reconhecidas e apoiadas pela organizao. importante saber
respeitar o aspecto espontneo e voluntrio dessas comunidades, cujas caractersticas so
bastante distintas daquelas que caracterizam uma equipe de projeto, um departamento e
arranjos como os PMO's e escritrios de anlise de negcios.
Equipes, departamentos e escritrios so estruturas formais. Seguem uma hierarquia e

obedecem procedimentos e padres. Enquanto as equipes so temporrias, os dois ltimos so
permanentes. Colocando de outra forma, eles so centros de custos.
Comunidades de prtica, por outro lado, so estruturas informais. Elas se autodefinem e

autogerenciam, alheias hierarquia e aos processos vigentes. Preste um pouco de ateno: sua
empresa pode ter algumas dezenas de comunidades de prtica. Grupos que gostam de se reunir
com certa frequncia, durante o almoo, nos cafezinhos ou at mesmo em happy hours. Muitos
gostam de falar sobre o servio, j reparou? Pois bem, eles so embries de ou comunidades
de prtica j constitudas. No popular, de forma pejorativa, gostamos de tratar esses grupos
como panelinhas. Mas as trocas de conhecimento e experincias que eles esto efetuando j
devem gerar algum valor para a empresa. A proposta aqui que a empresa reconhea e apoie
esses grupos informais, as Comunidades de Prtica.
Antes de definirmos como uma empresa pode apoiar uma comunidade, vamos detalhar um
pouco mais as suas caractersticas fundamentais. Uma comunidade de prtica :
Motivada pelo Bate-papo: ela visa desenvolver as competncias dos participantes

atravs da gerao e troca de conhecimentos. Ocasionalmente o grupo pode tentar
descobrir uma soluo para um problema especfico, mas isso uma exceo. No h
uma pauta pr-definida para seus encontros.
Guiada pelo Valor: seus membros compartilham interesses ou prticas. O valor est
no processo de aprendizado.
Definidas pelo Conhecimento: que interdependente. Suas fronteiras so

permeveis, ao contrrio de equipes de projetos, departamentos e escritrios que
apresentam rgidas estruturas.
Durao Indeterminada: uma comunidade dura enquanto houver interesse.
5 Contm trechos do artigo Aprendizado Interprojetos, de minha autoria, publicado nos anais da 6a. edio
do seminrio Gesto de Projetos de TI promovido pela SUCESU-SP (2004). A verso integral do artigo, em
36 Captulo 3
Formao Aleatria: a participao voluntria. E os participantes se autoselecionam.

Da o apelido panelinha.
So esses aspectos simples e naturais que fazem das comunidades de prtica uma alternativa
muito moderna. A ausncia de mecanismos de controle formais pode assustar um pouco. Mas
exatamente essa liberdade que gera o potencial de aprendizado. E de inovao, uma palavra
que est na boca de todo mundo mas distante demais das estruturas e processos das empresas.
Uma empresa no precisa fazer muito para apoiar a formao e manuteno das comunidades
de prtica. Quatro passos bem bsicos so necessrios:
Identificar os grupos informais criados em torno de temas (conhecimentos) que sejam

relevantes para a organizao;
Indicar um ou mais membros do grupo para intermediar o relacionamento do grupo

com a organizao;
Oferecer uma infraestrutura bsica para o grupo, como espaos reservados para seus
encontros;
Reservar um perodo de tempo, da jornada normal de trabalho, para que tais encontros
ocorram.
A interferncia da organizao no funcionamento da comunidade de prtica deve ser a menor

possvel. O sentimento de confiana mtua e de abertura para exposio de pontos de vista so
essenciais para a longevidade da comunidade. Porm, claro, as organizaes precisam
perceber que seu investimento, por menor que seja, est dando algum tipo de retorno.
Indicadores tradicionais de ganho de produtividade no servem neste caso. Os principais
ganhos sero percebidos na performance dos colaboradores e, consequentemente, na qualidade
dos projetos.
Uma empresa pode ter comunidades com os mais diversos temas. Nossa preocupao aqui
com os analistas de negcios. Por se tratar de uma funo ainda em fase de definio, uma
comunidade de prtica especfica para AN's faz muito sentido.
Por fim, importante destacar tambm as extenses das comunidades de prtica.

Normalmente elas extrapolam as fronteiras de uma organizao. Grupos de discusso, fruns e
outras ferramentas oferecidas na Internet permitem a colaborao e a troca de experincias com
profissionais do mundo todo. Uma empresa tem muito a ganhar quando seus colaboradores
so incentivados a participar desse tipo de associao. Mas, por incrvel que parea, muitas
ainda censuram o uso da Internet por trabalhadores do conhecimento. Se h o temor de que
informaes sensveis ou sigilosas sejam acidentalmente liberadas, a empresa deveria apenas
publicar um guia de uso desse tipo de ferramenta. Impedir seu uso, alm de antiptico e
desmotivador, tambm fecha as portas da empresa para conhecimentos que existem alm de
seus muros. Na era da Economia da Informao, essa no parece ser uma coisa muito
inteligente.
Contratando Analistas de Negcios

Se esta uma funo / profisso relativamente nova e mal definida, como uma empresa pode
contrat-la? O que ela deve buscar nos currculos? Quais tipos de testes podem ser aplicados?
Enfim, como devem ser os processos de seleo e contratao de AN's?
importantssimo comear bem. Nossa rea, particularmente aqui no Brasil, conhecida por
publicar anncios de vagas exagerados, mal definidos e pouco eficazes. So exagerados porque
frequentemente buscam super-heris. Por exemplo:
Coordenadordeprojetocom10anosdeexperinciaecertificao
PMP.Formaosuperioremengenharia,administrao,sistemasde
informaoouequivalentes.Experinciacomprovadano
gerenciamentodeprojetosdesistemasdeinformaoparavarejo,
atacadoouindstria.Serconsideradoumdiferencial
conhecimentosdoSAP/R3edaarquiteturaJava(JEE).Noesde
algumametodologiadedesenvolvimento,particularmenteORUP,
desejvel.
Esse tipo de coisa ficou to comum que nem percebemos o absurdo, n? Como possvel que
algum realmente domine temas to dspares como o gerenciamento de projetos cujo corpo
de conhecimentos formado por 9 disciplinas, SAP R/3 um sistema monstruoso (em todos
os sentidos), Java/JEE uma plataforma tecnolgica complexa e o RUP (Rational Unified
Process), igualmente gigantesco? Mas o fato de gente se candidatar para vagas desse tipo assusta
mais que o anncio. Ser que os candidatos usam capas, mscaras e vo para as entrevistas
voando?
Resta a torcida para que o mesmo no ocorra com os AN's. Apesar de uma certa indefinio,
aquela lista bsica de habilidades sociais e tcnicas que ele deve apresentar parece bastante
razovel, no? Se voc concorda, ento talvez goste da sugesto de anncio abaixo:
AnalistadenegcioscomXanosdeexperincia.Formaosuperior
emsistemasdeinformao,administraoouequivalente
desejvel.Devecomprovarexperincianoramode[nomedoramode
atividades].AcertificaoCBPA(CertifiedBusinessAnalysis
Professional)serconsideradaumdiferencial.Devedominara
modelagemdenegcios,preferencialmenteutilizandoopadrode
notao[UML|EPBE|BPMN|EPC|IDEF*].Devesaberguiareventospara
desenvolvimentoderequisitoseterboacomunicao.
imprescindveloconhecimentodetcnicaspararegistro,
estruturaoetestesderequisitos.
No estou pedindo que voc copie e cole o exemplo acima. Minha preocupao que voc no
exija do AN mais do que ele pode dar.
Um anncio bem especfico e detalhado tem maiores chances de atrair melhores candidatos.
As retries devem espantar a maioria dos aventureiros. Normalmente, quando citamos as
habilidades tcnicas de forma detalhada, o candidato desconfia que algum tipo de teste ser
aplicado. Ser!
38 Captulo 3
Se voc pediu conhecimento de UML, por exemplo, como avali-lo se no com uma
provinha? O mesmo vale para todas as habilidades tcnicas. Eu aplicaria, no mnimo, um teste
com as seguintes situaes:
Pea que o candidato desenvolva um modelo de alto nvel que destaque os principais
elementos que caracterizam aquele ramo de atividades especfico. Se h uma linguagem
de modelagem em questo, pea que o modelo seja desenvolvido neste padro.
Apresente um modelo de um processo de negcio relevante (para seu negcio) e

comum, mas incompleto. Pea que o candidato complete o desenho e justifique cada
elemento acrescentado.
Apresente um problema de negcio e se oferea para ser entrevistado pelo candidato.

Ele deve elaborar uma especificao de caso de uso completa, inclusive com os casos de
testes.
Por fim, pea que o candidato escreva na hora, na forma de um documento de viso, as
razes porque a empresa deve contrat-lo. Que o candidato se venda como venderia um
projeto. Em um documento de uma pgina apenas.
Cada questo acima vale 25 pontos. Todo candidato que no obtiver 75 pontos deveria ser
eliminado. Ok, soou duro e deveras restritivo. Mas deve ser assim mesmo. Claro, nunca se
esquecendo que estamos tratando de pessoas. O cara s tirou 50 mas mostrou qualidades e
habilidades que podem ser muito teis para a empresa? Caramba, tente aproveit-lo. Tente,
antes, entender porque ele foi mal em algumas questes. horrvel quando sinto que gasto o
seu e o meu tempo com questes que dependem exclusivamente de bom senso. Perdo.
Mas o processo no se encerra aqui. Por enquanto voc apenas garantiu que o candidato possui
as habilidades tcnicas mnimas. O que fazer para avaliar as habilidades sociais? Aqui, mais do
que provinhas, so as conversas que comprovaro a adequao do candidato. E essas conversas
no podem ocorrer apenas entre o selecionador e o candidato. responsabilidade demais para
o selecionador.
Se voc da rea de TI, convide profissionais de reas de negcio para conhecer o candidato e
bater papo com ele. Se voc de uma rea de negcio, chame algum de TI para o bate-papo.
Este profissional ser uma ligao entre diversas reas. fundamental que a avaliao do
candidato seja compartilhada pelo maior nmero de departamentos envolvidos. A rea
contratante tem a palavra final, claro. Mas ela deve conhecer opinies e eventuais vetos de
outras reas. Questo de preveno, de gerenciamento de riscos.
Ah, faltou dizer que o RH pode participar do processo. Se ele no for um departamento
exclusivamente burocrtico e divulgador de regras, ento ele deve participar do processo.
Sendo Contratado
Este livro foi escrito para voc, meu caro (candidato a) Analista de Negcios. Mas eu no
poderia ignorar demandas como a que tratei no tpico anterior. Apenas espero que aquelas
sugestes ali tambm sejam teis para ti. J pensou se uma empresa maluca resolve adotar
minhas sugestes para anncio de vagas e testes? J pensou se voc d uma sorte danada e se
candidata a uma vaga nesta empresa? S isso j paga o investimento no livro, certo?
Mas, falando srio, tratemos agora do lado dos candidatos. O que eles podem fazer para serem
selecionados para entrevistas e contratados? Do lado de l o processo comea na identificao
da necessidade e na correta redao de um anncio. Do lado de c comea na elaborao do
currculo. No, no vou te dar um template de currculo. AN de verdade sabe que templates so
um perigo! Profissionais do sculo XXI acham que templates so coisas de gente preguiosa e
pouco criativa. Te darei apenas algumas dicas:
Comece escrevendo com todas as letras qual vaga voc almeja: AN.
Valorize sua experincia comeando o currculo por ela. Indique as ltimas empresas e
suas principais realizaes, de forma sucinta. Lembre-se, a capacidade de sntese uma
habilidade social esperada pelo contratante.
Na sequncia mostre sua formao, inclusive extenses e cursos. Como esta rea no
tem um curso de graduao especfico, esses complementos so de suma importncia.
Mas limite-se queles que realmente comprovem seu interesse pela anlise de negcios.
Simples assim, objetivo desse tanto. Uma verso mais detalhada, com referncias e indicaes,
pode ser mantida em um site de relacionamentos profissionais como o LinkedIn6. Se for o caso,
ento informe o endereo de seu perfil pblico no currculo impresso. E prepare-se para a
entrevista.
Lembre-se que toda empresa minimamente sria vai aplicar testes. Ento estude e revise seus
conhecimentos com uma certa antecedncia. Faa uma breve pesquisa sobre a empresa e seu
ramo de atividades. legal conhecer tanto o histrico quanto as perspectivas de todo aquele
mercado. Saber quais so os clientes, fornecedores e concorrentes devem fazer parte do estudo.
Se a Internet (melhor dizendo, o Google) no ajudar muito, o que difcil hoje em dia, busque
publicaes da rea. Ou seja, demonstre interesse. Afinal, voc est se oferecendo para trabalhar
naquela empresa. Voc no quer saber onde est amarrando seu burrinho?
6 http://www.linkedin.com
40 Captulo 3
Formando Equipes
Este tema merece um livro s para ele. Quem sabe um dia crio coragem. Por enquanto ele ser
s isso, um sub-captulo. Com uma justificativa: preciso mostrar como podemos posicionar os
AN's em uma equipe de projeto para desenvolvimento de sistemas. No consigo falar sobre
isso sem falar um pouco sobre a equipe toda. Apresento abaixo o que costumo chamar de
modelo para um Dream Team, ou time dos sonhos. Defendo a especializao, mas no numa
filosofia taylorista ou fordista, por favor. Drucker7 quem me inspira8:
Conhecimento, por definio, especializado. Com efeito, as pessoas

realmente detentoras de conhecimentos tendem ao excesso de especializao,
qualquer que seja seu campo de atuao, exatamente porque sempre se deparam
com muito mais a aprender.
Nos tempos do COBOL e similares, era fcil imaginar uma equipe formada em torno de um
superprogramador, como sugerido por Fred Brooks9. Depois que inventamos o mundo Cliente
/ Servidor e decidimos usar a Internet como plataforma para nossas aplicaes, tudo mudou.
Tecnologias se tornaram mais complexas cresceram para os lados e para cima. Antes um
mesmo mdulo escrito em COBOL definia dados, interfaces e lgica de negcio. Era natural
que um programador escrevesse tudo.
Depois ganhamos bancos de dados, servidores de aplicaes, servidores Web e mais um imenso
conjunto de elementos. Mesmo que alguns gnios insistam que podem dominar tudo, uma
organizao sria deve se preocupar com a formao de equipes que valorize especializaes.
Da mesma forma que tcnicos de futebol no montam times com 11 generalistas em campo.
Em cada posio h muito a ser estudado. Com um agravante quando falamos de

desenvolvimento de sistemas: novidades aparecem quase todo dia, o que torna o domnio
relativamente efmero. Como dizia Drucker, todos sempre iro se deparar com muito mais a
aprender. Por isso bom desconfiar de todo mundo que domina muita coisa em nossa rea.
Ou confiar desconfiando. Goleiros artilheiros so exceo, no a regra.
Mas importante saber quais especializaes valorizar. Um time de futebol sempre ter 11
posies a ser ocupadas. No podemos ter um nmero varivel de especializaes. Uma
estrutura bsica, um modelo para a formao de equipes necessrio. Abaixo apresento um
desenho e uma breve explicao sobre cada especialista sugerido. De novo: esse breve desvio
necessrio para que voc entenda a relevncia e o posicionamento do analista de negcios em
uma equipe de projeto.
7 http://en.wikipedia.org/wiki/Peter_Drucker
8 O Advento da Nova Organizao, artigo de Peter F. Drucker publicado em Gesto do Conhecimento

Harvard Business Review, Editora Campus (2001).
9 The Mythical Man-Month Anniversary Edition, Frederick P. Brooks Jr, Addison-Wesley (1995). O
texto a que me refiro, The Surgical Team, consta da edio original do livro, de 1975.
Figura 2: Modelo para a Formao de Equipes.
Em Infraestrutura residem todos os profissionais responsveis pelo dimensionamento,

montagem (setup) e manuteno dos ambientes de desenvolvimento, homologao e produo.
Cada projeto pode exigir uma composio um pouco diferente desta clula. Lidaremos com
transaes financeiras ou outros dados que requerem muito cuidado, ento precisaremos de
um especialista em segurana, firewalls, encriptao e assim por diante.
Infelizmente, relativamente comum que estes profissionais s sejam alocados em um projeto

quando a fase de entrega est prestes a ser iniciada. Essa prtica resulta nos tradicionais embates
entre desenvolvedores e a turma de infra. Eles deveriam se envolver com o projeto desde os
primeiros dias, entendendo os requisitos e se mobilizando para realizar o dimensionamento,
configurao e testes de todos os elementos de infraestrutura envolvidos na soluo.
Aqueles que o mercado convencionou chamar de analistas-programadores aparecem em trs

clulas: Dados, Servios e Interfaces. Talvez a distino entre analistas de sistemas e
programadores realmente seja uma coisa do passado. Mas ignorar a diferena entre as trs
camadas no uma boa idia. Cada uma dessas reas evoluiu muito nos ltimos tempos. E,
consequentemente, se tornaram mais exigentes em termos de conhecimentos e especializao.
Vamos dar uma olhada em cada uma delas.
O DBA (DataBase Administrator) morreu. Viva o novo especialista na camada de Dados, o

profissional que sabe que o mundo no gira em torno de bases relacionais. O cara que,
conhecendo os requisitos dos usurios, saber lanar mo de bases multidimensionais e
gerenciadores de contedo no-estruturado, alm dos tradicionais bancos transacionais.
42 Captulo 3
O programador clssico, aquele que se destaca por seu domnio de lgica e coisas como
orientao a objetos, componentizao, orientao a servios, design patterns e outros papos
afins, aquele que ocupa a clula chamada Servios. As fronteiras com as duas clulas vizinhas
devem ser bem delimitadas. Acontece que, no raro, os ocupantes desta casa gostam de falar
que banco de dados coisa do passado. Isso sem falar que suas telas so terrveis, uns
rascunhos medonhos: eles valorizam demais a parte invisvel do iceberg, se esquecendo que
tudo o que o usurio v, toca e avalia so as interfaces.
Ou seja, as Interfaces merecem uma clula s sua. uma das reas que mais se desenvolveu
nos ltimos tempos, principalmente depois do advento da Web. HTML, CSS, Javascript, Ajax,
Flash e mais tecnologias para celulares e outros dispositivos mveis... No preciso ir muito
longe para mostrar que especialistas so necessrios aqui tambm. E que, alm das tecnologias,
eles devem dominar conceitos de ergonomia de software e usabilidade.
Esses quatro profissionais ou grupos de profissionais, infraestrutura, dados, servios e

interfaces, tm pelo menos uma coisa em comum: normalmente eles so desastrados (e
desastrosos) no trato com clientes e usurios. Porque eles no so treinados para entender o
negcio e os usurios. Como j foi dito anteriormente, eles esto ansiosos para desempenhar
sua funo principal, seja ela modelar, programar ou configurar servidores. Para eles, o
desenvolvimento de requisitos um tipo de empecilho, uma chateao que deve ser
resolvida antes que eles possam se debruar naquilo que realmente gostam de fazer. Por isso,
no raro, eles so negligentes querem remover aquela barreira o mais rapidamente possvel.
Entra o Analista de Negcios. O cara que foi treinado para entender o negcio e os usurios.
O profissional cuja principal atribuio a comunicao desse entendimento para toda a
equipe de projeto.
Veja novamente a figura 2 acima. Clientes e usurios ficam do lado esquerdo daquele diagrama.
Isso significa que o AN, o Coordenador e o Arquiteto so os principais pontos de contato com
as partes interessadas que ficam fora da equipe. Mas importante frisar que o AN no um
tipo de parede, um impedimento para o contato dos usurios com o restante do time. Pelo
contrrio, ele deve facilitar esses contatos. E organiz-los. sabido que o contato no planejado
compromete a performance de uma equipe. O AN, em conjunto com o Coordenador e o
Arquiteto, faz com que cada contato da equipe com o mundo exterior seja estruturado.
Por que trs pontos de contato? Acontece que cada um deve cuidar de seu assunto:
O AN cuida do problema, ou seja, do entendimento do negcio e dos usurios;
O Arquiteto cuida da soluo, de seu desenho, qualidade e implementao; enquanto o
Coordenador cuida do projeto, prazos, custos, suprimentos, e todas as demais questes

administrativas.
Mas preciso explicar um pouco melhor as atribuies do Coordenador e do Arquiteto.

Dois Lderes
Vou justificar minha sugesto apelando novamente para Fred Brooks10, que no mesmo livro j
referenciado acima falou mais ou menos assim:
Pensadores so raros. Executores so raros.

Pensadores-Executores so mais raros ainda.
Uma empresa no pode ter um modelo para a formao de equipes que se baseie na sorte. Na
sorte de encontrar um gnio pensador-executor que lidere seus projetos. Por isso a distino
entre o Arquiteto (Pensador) e o Coordenador (Executor) to importante.
O Arquiteto, tambm conhecido como Lder Tcnico, o dono da soluo. Trabalhando com
os representantes das clulas Interfaces, Servios, Dados e Infraestrutura, ele cuida do desenho
e da implementao de um sistema. Uma de suas principais atribuies a manuteno da
integridade arquitetnica da soluo. Em conjunto com o AN, ele garante que a aplicao
realmente satisfaz todos os requisitos apresentados. Ele lidera a equipe, cuidando
exclusivamente de questes tcnicas. E deve ter a palavra final sobre o escopo da soluo.
interessante notar que no se trata de uma funo burocrtica. O arquiteto tambm coloca a
mo na massa, implementando as partes mais crticas de uma soluo ou criando guias e
modelos para os demais membros.
J o Coordenador se concentra em todas as questes gerenciais e administrativas de um

projeto. O gerenciamento de prazos, custos, suprimentos, comunicao, pessoal e riscos, no
necessariamente nesta ordem, so suas principais atribuies. Ele entende que ele quem
trabalha para o time, e no o contrrio. Como foi colocado por Tom DeMarco11 e Timothy
Lister h muito tempo12:
A funo do gerente no fazer as pessoas trabalharem e sim tornar possvel

que elas trabalhem.
Definitivamente, no se aplica a mxima que diz que cachorro com dois donos morre de
fome. s uma diviso de responsabilidades: enquanto o coordenador se ocupa da aquisio
da rao no tempo correto e sem estourar o oramento, o arquiteto monta o cardpio e serve
nosso querido melhor amigo.
A liderana tcnica do arquiteto deve ser respeitada pelo coordenador. Eles debatero suas
respectivas restries, sobre prazos por exemplo. Mas a palavra final sobre o desenho da
soluo deve ser do arquiteto. Da mesma forma, o arquiteto deve saber respeitar as
deliberaes do coordenador. Um bom arquiteto sabe que sempre existiro restries de
prazos e custos, por exemplo. E que essas restries sero apresentadas e defendidas pelo
coordenador, principalmente.
10 http://en.wikipedia.org/wiki/Fred_Brooks
11 http://en.wikipedia.org/wiki/Tom_DeMarco
12 No livro Peopleware: Productive Projects and Teams, Dorset House (1987).

http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams
44 Captulo 3
Este tipo de diviso existe h tempos em outras reas do conhecimento humano. Um dos
melhores exemplos vem do cinema. O diretor de um filme seu arquiteto, o pensador. Ele cria
e controla os outros criadores, os atores, o diretor de fotografia, os especialistas em efeitos
especiais e compositores da trilha sonora, entre outros. Essas especializaes demandadas para a
construo de um filme se equivalem s nossas especializaes tcnicas (Interfaces, Dados...).
Mas, quando um filme recebe um prmio, o produtor (seu executor) quem sobe no palco.
No processo mais comum o produtor quem contrata (ou aloca) o diretor. O produtor se
ocupa de todas as funes administrativas relativas ao projeto do filme, contrataes,
financiamento, controle do cronograma etc. O pensador tem sua prpria categoria de prmios,
de Melhor Diretor.
Por histricas que sejam as desavenas entre produtores e diretores, a indstria do cinema sabe
que precisa desses dois tipos de crebros para realizar seus projetos. So raros os gnios, como
Spielberg e Lucas, que conseguem assumir qualquer das duas funes. Mais raros ainda so
aqueles que conseguem acumular as duas funes em um mesmo projeto.
O mtodo para gerenciamento de projetos geis chamado Scrum13 tem uma proposta que, em
conceito, se assemelha com este desenho. Ele sugere a existncia de dois perfis: o Scrummaster e
o Product Owner (Dono do Produto). O primeiro se aproxima daquele que chamo de
coordenador, enquanto o Product Owner se aproxima um pouco do arquiteto. Um dos criadores
do mtodo, Jeff Sutherland, criou uma bela analogia para explicar a importncia dos dois
papis14: comparando com uma equipe de rally, o Scrummaster o piloto e o Product Owner o
navegador.
A similaridade com minha proposta s no total porque muitos defendem que o Product
Owner trate exclusivamente do domnio do problema. Eu acho que, com tal finalidade, at o
nome Dono do Produto infeliz. O dono do produto, em minha leitura, fala sobre a
soluo e no sobre o problema que pretende resolver. Falo mais sobre o Scrum e outros
processos de desenvolvimento e gerenciamento de projetos no ltimo captulo.
13 http://en.wikipedia.org/wiki/Scrum_(development)
14 http://jeffsutherland.com/scrum/
O Tamanho do Time
O modelo sugerido acima deve ser adaptado para cada empresa ou tipo de projeto. Mas sua
estrutura bsica deveria ser respeitada. Uma empresa bem pequena, por exemplo, pode no ter
7 funcionrios. Ou 7 especialistas. No por isso que o modelo no lhe atender. Empresas de
software, com irritante frequncia, incham mas no crescem. Acumulam funes similares,
talvez aproveitando a ampla oferta de generalistas. Isso inchao. Ao usar o modelo como um
guia elas podem, a cada contratao, preencher as clulas de especializao onde h maior
carncia. Assim seu processo de seleo se torna mais objetivo.
Mas, tratemos de algumas questes mais prticas. Se um determinado projeto demandar

apenas 4 pessoas, por exemplo, como fica o desenho da equipe? Algumas recomendaes:
Que o coordenador e o arquiteto sejam realmente pessoas diferentes. O projeto ganha

com tal distino, com esse confronto.
O coordenador pode acumular a funo do AN. Suas habilidades tcnicas e sociais so,
de certa forma, equivalentes, o que deve facilitar a juno de responsabilidades.
E o arquiteto, como j foi dito anteriormente, realmente coloca a mo na massa. Ento

ele pode acumular qualquer outra atribuio tcnica (interfaces, servios e dados).
Devemos notar que o arquiteto sair mesmo de uma dessas clulas.
E como saber qual o nmero ideal de AN's para um empresa? Ainda muito difcil cravar um
nmero, uma frmula. Uma grande empresa nacional, com cerca de 60 mil funcionrios, tem
cerca de 150 AN's. Isso daria algo em torno de 1 analista para cada 400 funcionrios.
Definitivamente, dada a ordem de grandeza, no serve muito como referncia. Prefiro uma
frmula que leve em conta o nmero de projetos correntes. Quantos projetos sua empresa
desenvolve de forma simultnea? O nmero ideal de AN's igual ao nmero de projetos
simultneos vezes 2.
Eu disse nmero ideal. Porque o ideal que os AN's atuem em duplas. No decorrer do livro
justifico minha sugesto. Por enquanto vale dizer que se o nmero ideal no for possvel, por
alguma restrio qualquer, mesmo assim considere a possibilidade do trabalho de anlise de
negcios ser executado por duas pessoas: o AN e mais um integrante da equipe, de preferncia
o coordenador.
Faltou explicar a formulazinha acima: por que o nmero de projetos simultneos vezes 2?
Porque enfaticamente defendido neste livro que seja adotado um processo de
desenvolvimento iterativo e incremental15. Sendo assim, os AN's tero trabalho durante todo o
projeto. o oposto do modelo cascata (ou Waterfall16), onde o AN desenvolve seu trabalho nas
fases iniciais de um projeto e depois pula para outro. Falo mais sobre isso no decorrer do livro
e de maneira mais especfica no ltimo captulo.
15 http://en.wikipedia.org/wiki/Iterative_and_incremental_development
16 http://en.wikipedia.org/wiki/Waterfall_model
46 Captulo 3
Parte II
Entendendo o
Negcio
48 Captulo 3
Modelagem de Negcios 49
Captulo 4
Modelagem de Negcios
De todas as disciplinas que formam a engenharia de software, nenhuma mais mal
compreendida e mal falada do que a Modelagem de Negcios. Muitos a veem como pura
burocracia geradora de um tipo de documentao que nunca mais utilizada e muito menos
atualizada. Outros tantos acham que se trata de tentar representar em modelos todo um
negcio, nos mnimos detalhes, o que impossvel. Tanta m compreenso resultou em um
incmodo fato: quase ningum pratica a modelagem de negcios em seus projetos. Existe at
quem sugira que a modelagem seja tratada como um projeto a parte, separado daquele que
deve gerar a soluo. Quanta desinformao!
Que faz com que os projetos j comecem no levantamento de requisitos, com corajosos
analistas tentando compreender as necessidades dos usurios. No raro esse entendimento
falho porque o analista no conhece o negcio. Sua comunicao com clientes e usurios
prejudicada porque ele simplesmente ignora os conceitos bsicos que caracterizam aquela
organizao e seu mercado. Como esperar boas respostas se o analista no sabe o que
perguntar? Engraado que no raro ouvirmos que o usurio nunca sabe o que quer.
Como o ttulo desta segunda parte do livro antecipa, a modelagem de negcios serve para que
possamos Entender o Negcio. As tcnicas e mtodos que formam esta disciplina nos
ajudam a compreender todos os aspectos de uma empresa, suas motivaes, estruturas,
processos e regras.
A modelagem de negcios o oposto da modelagem de sistemas. Nesta sempre objetivamos o

mnimo detalhe, os modelos evoluem at seu estgio final, o cdigo. Na modelagem de
negcios nos contentamos com o mnimo, s modelamos o essencial. Essencial para qu?
Oras, para uma boa compreenso do negcio. Pensamos assim: se uma parte do negcio bem
compreendida por todas as partes interessadas, ento para que gastar tempo tentando model-
la? Hora do alerta para todos que gostam de receitinhas de bolo, checklists e afins: todas as
tcnicas e mtodos sugeridos nesta parte do livro so opcionais. Voc s lanar mo
deles em um projeto quando de fato precisar daquele entendimento.
E, por favor, pense 10 vezes antes de utilizar qualquer diagrama aqui sugerido como
documentao de sistema. A explicao simples: todo negcio voltil e dinmico demais.
Sua documentao ficaria obsoleta em uma velocidade impressionante. E a manuteno desses
documentos pode ser cara demais.
Alertas colocados, mergulhemos ento nesta bela e mal compreendida matria. Neste captulo
veremos o bsico da disciplina, opes de linguagens para modelagem e uma introduo s 3
vises que compem um modelo de negcios. Vises que sero detalhadas nos captulos
seguintes.
50 Captulo 4
Por que modelamos?

Ok, voc j sabe, modelamos para entender. Em nosso caso especfico, para entender um
negcio. Mas essa afirmao, de certa forma simplista, talvez no seja suficiente para que voc
justifique a aplicao desta disciplina em seu prximo projeto. Vamos detalhar melhor as
motivaes para a execuo da modelagem de negcios:
Uma imagem explica mais e melhor do que mil palavras: este velho dito popular,
levemente adaptado, verdadeiro mas ao mesmo tempo perigoso. No qualquer
imagem que substitui milhares de palavras. H uma imagem certa para cada situao. E
isso significa mais agilidade nos processos de entendimento, avaliao e comunicao
com as partes interessadas.
Precisamos saber onde vamos pisar: nosso projeto vai mexer no negcio, alterando
processos e embutindo sistemas. Precisamos ter uma clara noo de todos os impactos
que vamos gerar. Afinal, quem louco de fazer de um negcio um laboratrio de
experincias1? Um bom modelo serve como base para essa avaliao e para a realizao
de todas as experincias que se fizerem necessrias. O modelo o nosso mapa e
laboratrio. O modelo tambm , por que no, o nosso tabuleiro.
Se ainda assim estiver difcil para voc justificar o esforo de modelagem, ento apele para
autores de fora, como a dupla escandinava Hans-Erik Ericksson e Magnus Penker2, por
exemplo. Segundo eles:
Se os requisitos esto baseados em um bom modelo de negcios, h uma

chance muito maior do sistema de informao suportar o negcio de maneira
adequada.
Alm disso, Eriksson e Penker listam outras vantagens que podemos obter de um bom modelo
de negcios:
Maior e melhor aderncia do sistema ao negcio;

Facilidade na integrao de sistemas;
Reduo no custo de propriedade (manuteno) de sistemas; e
Reutilizao da lgica do negcio em outros sistemas.
Claro, no o modelo por si s que realiza tantas mgicas. Dependemos de bons processos de
desenvolvimento, boa arquitetura de aplicaes e um zilho de outras coisinhas mais. Aqui
importante notar que um bom modelo de negcios pode representar mesmo vrias vantagens.
Mas do que feito um bom modelo?
1 Pensei um pouco sobre a frase e quase a eliminei. Resolvi deix-la na companhia deste breve comentrio:
cientes ou no, existem vrios loucos por a que fazem isso: do negcio uma experincia.
2 Autores de Business Modeling with UML, Wiley (2000), que aparece na Bibliografia Comentada, no final
deste livro.
O que Modelamos?
Negcios de qualquer segmento ou porte so sistemas muito complexos, compostos dos mais
diversos elementos. Temos pessoas, funes e departamentos; instalaes, mquinas e
equipamentos; processos, procedimentos e regras; produtos, servios e clientes; mercado,
concorrentes e parceiros; planos, objetivos e metas. Essa listinha genrica e nem de longe
tenta encerrar o assunto. Um modelo deve conseguir representar todos os componentes e
aspectos de um negcio relevantes em determinada situao. Mas deve faz-lo de forma
organizada, seno no ter valor algum. Todo negcio complexo. Nossos modelos devem
representar essa complexidade de forma elaborada3, de maneira que facilite o entendimento e
comunicao.
To antiga quanto andar para a frente a noo de que facilitamos a resoluo de um problema
grande e complicado quebrando-o em diversos pedacinhos. Um modelo de negcios
formado por um determinado nmero de vises os nossos pedacinhos. Cada viso indica
uma forma diferente de enxergar o negcio, uma perspectiva diferente4. Este livro apresentar
apenas as vises mais comuns, existentes em negcios de qualquer natureza. Mas importante
frisar que, alm de no serem obrigatrias (na composio de um modelo de negcios), elas
no so as nicas vises possveis.
Estudaremos aqui e nos prximos captulos 3 vises:
Viso do Negcio: que tambm pode ser chamada de Viso da Motivao (do
Negcio). Ela nos ajuda a entender o negcio e seu ecossistema, detalhando
principalmente as suas motivaes, seus objetivos e metas.
Viso da Estrutura: que nos ajuda a analisar todos os recursos utilizados, consumidos
ou produzidos por uma empresa.
Viso dos Processos: que cuida de toda a parte viva de uma organizao, toda a sua
dinmica.
Optei por essas trs vises, e s por elas, por

acreditar que este conjunto representa um modelo
mnimo til e necessrio na grande maioria dos
projetos de sistemas. De forma resumida: a viso do
negcio nos mostra o cenrio e os objetivos; em
estrutura vemos todos os recursos que estaro
envolvidos nesta busca pelos objetivos; e a viso dos
processos mostra como faremos essa busca.
Figura 3: As 3 vises de um modelo de negcios
3 Combinemos o seguinte: aqui o oposto de complexo no simples e sim elaborado. Entendemos que no
possvel simplificar um negcio (atravs de um modelo), e sim torn-lo melhor elaborado. Esse conceito foi
surrupiado de The Back of the Napkin, livro de Dan Roam, Portfolio (2008). Como veremos no restante
deste captulo, no foi s nisso que este livro me inspirou.
4 Esta frase, se fora do contexto, compromete um tanto, no?

52 Captulo 4
Existem relativamente poucos trabalhos sobre a modelagem de negcios. E no h um padro

consolidado acerca das vises, nem mesmo das bsicas ou mais comuns. No livro de Eriksson e
Penker citado anteriormente, Business Modeling with UML, alm das trs vises acima existe a
Viso do Comportamento. Ela utilizada particularmente para a anlise de recursos
complexos. Aqui vou consider-la como um subconjunto da viso de processos. Justificarei
minha escolha no captulo 7.
Outro trabalho srio sobre modelagem de negcios, Business Modeling: A Practical Guide to
Realizing Business Value5, no fala de vises mas de disciplinas de modelagem de negcios.
Segundo os autores existiriam 4: Modelagem de Processos, da Motivao, da Organizao e das
Regras. Apesar de considerar vrias sugestes deste trabalho, optei pelo termo Vises em
detrimento de Disciplinas. E considero a modelagem da motivao como um subconjunto da
viso do negcio. Assim como a modelagem de regras um subconjunto de todas as trs vises
que apresento. Espero que tudo isso fique um pouco mais claro na medida em que as vises
forem apresentadas com mais detalhes.
Agora preciso explicar o adjetivo srio utilizado no incio do pargrafo anterior. Talvez o
termo seja exagerado, mas serve para distinguir os dois trabalhos supracitados de outros,
particularmente da forma como a modelagem de negcios apresentada no RUP e no livro
Modelagem gil de Scott Ambler6. Das 351 pginas de seu trabalho, Ambler dedica apenas 7
ao tema modelagem de negcios. E, como o RUP, baseia suas sugestes exclusivamente em
casos de uso de negcio (BUC Business Use Case) e modelos de objetos de negcio. Fica claro
que ambos trabalhos nasceram de gente de sistema e no de negcio. Os modelos sugeridos
so muito fracos na representao de um negcio real. No distinguem nem elementos bsicos
como recursos, processos, objetivos e regras.
A especificao de casos de uso uma das ferramentas mais importantes de um AN. Mas neste
trabalho sugerido que ela seja utilizada exclusivamente para descobrir e descrever requisitos
funcionais de um sistema. Alis, foi s para isso que ela foi inventada. Qualquer outro uso
forar de barra, algo como usar um serrote para colocar um prego na parede.
Pois , j reparou como tomei uma srie de decises por voc? Mas eu no espero que voc
confie em mim. No assim, de imediato. O que eu espero mesmo que voc, como eu, sinta
na pele o que usar uma sugesto ou outra. Tente, por exemplo, modelar um negcio da forma
como sugerido por Scott Ambler e no RUP. E tire suas prprias concluses. Eu cometeria
um grave engano se ficasse em cima do muro neste livro. Minhas experincias no serviriam
para nada. Mas, por favor, isso aqui no um atalho. Na menor desconfiana acerca de alguma
das minhas indicaes, tente o outro lado. O que eu prometo isso: sempre mostrar qual o
outro lado. Portanto, para ficar bem claro: a modelagem de negcios sugerida neste livro
no tem nada a ver com aquela que aparece no RUP e derivados7. Ponto.
Vamos para a prxima questo.
5 De David M. Bridgeland e Ron Zahavi. Morgan Kauffman / OMG Press (2008).
6 Modelagem gil Prticas Eficazes para a Programao eXtrema e o Processo Unificado, Scott
W. Ambler. Bookman / Artmed Editora (2004).
7 Faltou citar outro livro relativamente famoso que caiu na armadilha do RUP: UML for the IT Business
Analyst, de Howard Podeswa. Thomson (2005).
Quanto Modelamos?
Uma das maiores falcias sobre a modelagem de negcios que ela burocrtica. No raro
utilizam o seguinte termo para conden-la: BDUF8, sigla que em ingls significa Big Design
Up Front. Numa traduo livre, um monto de diagramas antes de qualquer coisa. O termo
no foi criado exclusivamente para a modelagem de negcios. Mas pegou.
E no de forma gratuita. Realmente h muita gente que acha que deve modelar todo um
negcio, ou boa parte dele, antes de fazer qualquer outra coisa em um projeto. No por acaso
que h muita gente tambm que sugere que a modelagem de negcios seja tratada como um
projeto a parte, bem separado daquele que deve gerar software. Duas coisas ficam implcitas
aqui:
Uma viso muito cascata do ciclo de vida de desenvolvimento; e
A iluso de que este modelo estar imune as mudanas que afetam diariamente um
negcio.
A modelagem de negcios no contexto de um projeto de software diferente. No queremos

documentar o negcio, apenas entend-lo. Por isso e pelos equvocos listados acima a questo
aqui colocada muito importante: quanto modelamos? Quantos diagramas so necessrios ao
entendimento, avaliao e comunicao de um determinado negcio? Chegamos naquela
questo que interessa a maioria: quanto tempo isso leva?
Resposta default em nossa rea: depende. Alguns projetos mais simples podem demandar
apenas um ou dois diagramas que no consomem nem um dia de trabalho. No outro extremo
podemos ter empreendimentos que exigem a elaborao de dezenas ou at mesmo centenas de
artefatos. O mais importante aqui um teste muito simples: cada diagrama deve explicar de
forma completa e inequvoca algum aspecto do negcio. Esse diagrama s foi gerado porque
no havia outro meio de buscar tal entendimento. Mas, mesmo em um cenrio em que muito
trabalho de modelagem exigido, no h justificativas para que esse trabalho seja feito antes
de qualquer coisa. O tal BDUF nocivo sim e deve ser evitado pelo AN e por toda a equipe
de projeto.
Na sequncia deste trabalho tentarei ilustrar este trabalho em um processo iterativo e

incremental. Mesmo que o AN seja obrigado a gerar um grande nmero de diagramas, ele o
faz de forma gradual e durante praticamente todo o decorrer de um projeto. O que nos traz de
volta a questo: quanto modelamos? Apenas o suficiente para o correto entendimento do
negcio. Podemos pular para a prxima questo?
8 http://en.wikipedia.org/wiki/Big_Design_Up_Front
54 Captulo 4
Onde Modelamos?
Estranhou a pergunta? Voc ver que a resposta no to complicada. Refazendo a questo:
Onde baseamos nossos modelos? Um monte de diagramas como fluxogramas e organogramas
no representam necessariamente um modelo de negcio. Ok, um modelo um conjunto de
diagramas. Mas esse conjunto deve fazer sentido, deve ser ntegro e coerente. Uma das
principais caractersticas de um bom modelo de negcio sua Integridade Conceitual.
Para que tal integridade seja obtida todos os diagramas devem compartilhar uma mesma base,
uma mesma origem. Chamaremos esta base de Metamodelo, um modelo que explica os outros
modelos e diagramas. Pense nele como um mapa ou, melhor ainda, como um grande tabuleiro.
Cada diagrama que gerarmos ser como uma pea neste tabuleiro. Sendo assim, cada diagrama
deve respeitar as regras de uso do tabuleiro.
Existe um nmero razovel de alternativas de padres de notao ou linguagens para a

modelagem de negcios, mas so poucas as que oferecem um metamodelo completo. Agora,
antes de entregar de mo beijada minha opo (acho que j o fiz), apresentarei as 4 principais
alternativas de linguagens para a modelagem de negcios, suas vantagens e desvantagens:
Linguagem de Modelagem Descrio, prs e contras
IDEF9 Uma famlia inteira de linguagens de modelagem criada entre os

(Integration DEFinition) anos 1970 e 1980. Oferece variaes (representadas por nmeros na
frente do nome) para os mais diversos tipos de uso. Por exemplo:
IDEF0 Modelagem de Funes
IDEF1 Modelagem de Informaes
IDEF1X Modelagem de Dados
IDEF4 Projeto Orientado a Objetos
IDEF8 Modelagem de Interfaces com usurios
Pr: Tem muito tempo de estrada.

Contras: Tem muito tempo de estrada e envelheceu. Apesar do
aspecto famlia, carece de um metamodelo.
EPC10 provvel que esta linguagem seja mais conhecida atravs do
(Event-driven Process Chain) modelo de trabalho que a tem como ncleo, o ARIS (Architecture of
Integrated Information Systems)11.
Criada no incio dos anos 1990, a EPC uma linguagem para
modelagem de processos de negcio. Como o prprio nome indica,
tem os eventos de negcio como ponto de partida.
Prs: Difuso e bom nmero de ferramentas que a suportam.
Contra: Incompleta e no-extensvel.
9 http://en.wikipedia.org/wiki/IDEF
10 http://en.wikipedia.org/wiki/Event-driven_process_chain
11 http://en.wikipedia.org/wiki/Architecture_of_Integrated_Information_Systems
Linguagem de Modelagem Descrio, prs e contras
BPMN12 Padro criado pelo BPMI (Business Process Management Initiative) que
(Business Process Modeling em 2005 foi incorporado pelo OMG (Object Management Group).
Notation) Como o prprio nome indica, um padro de notao para
processos de negcio. Ou seja, no contempla outros elementos,
como estruturas e dados, que formam um modelo de negcios
completo.
Na realidade a aplicao de BPMN parece fazer mais sentido no
desenho de uma soluo, na modelagem de como um processo
deve ficar (to be). provvel que sua utilizao se limite a projetos
que envolvam a implementao de um produto BPMS (Business
Process Management System)13.
Pr: um moderno fluxograma, passvel de transformao direta
para execuo14.
Contras: s um moderno fluxograma. E carece de um
metamodelo15.
UML16 A UML uma linguagem de modelagem mantida pelo OMG. Sua
(Unified Modeling Language) verso 1.1 foi lanada em novembro de 1997, marcando o fim de
um embate que era conhecido como a Guerra dos Mtodos.
Grady Booch, James Rumbaugh e Ivar Jacobson, os Trs Amigos,
encabearam a criao desta linguagem que reunia as melhores
ideias de cada metodologista.
A UML nasceu para modelar sistemas, no negcios. Ainda assim
algumas alternativas foram sugeridas, particularmente no RUP e
nos trabalhos de Scott Ambler e Howard Podeswa (criticados
anteriormente neste captulo).
Mas a UML extensvel, ela pode ser adaptada praticamente para
qualquer tipo de necessidade. Em 2000 Hans-Erik Ericksson e
Magnus Penker apresentaram a EPBE (Eriksson-Penker Business
Extensions) no livro Business Modeling with UML. Estas extenses
possibilitam a gerao de um completo modelo de negcios.
Prs: a alternativa mais completa para modelagem de negcios.
Com amplo suporte de ferramentas.
Contra: A UML relativamente complexa. Pode no ser muito
intuitiva para pessoas no tcnicas.
12 http://en.wikipedia.org/wiki/BPMN
13 http://en.wikipedia.org/wiki/BPMS
14 Mas nem aqui a coisa ainda funciona direito. A transio de modelos BPMN para BPEL (Business Process
Execution Language) (http://en.wikipedia.org/wiki/BPEL) ainda problemtica.
15 Apesar dos esforos do OMG e alguns de seus integrantes no sentido de dar 'estofo' para a BPMN,
especificamente atravs do BPDM (Business Process Definition Metamodel)
(http://en.wikipedia.org/wiki/BPDM), at a data de publicao deste livro no havia nenhuma definio.
Oracle, SAP e IBM, por motivos no muito claros, no querem que esta evoluo aparea na verso 2.0 da
BPMN.
16 http://en.wikipedia.org/wiki/Unified_Modeling_Language
56 Captulo 4
UML & EPBE

Se o quadro anterior no foi suficiente para tornar isso claro, ento reafirmo aqui uma outra
escolha que fiz por voc: quase todas as propostas de diagramas para a modelagem de negcios
apresentadas neste livro se baseiam na UML e em sua extenso EPBE. Preciso justificar minha
escolha:
A UML j tem muitos quilmetros e projetos rodados. uma linguagem

madura, ao contrrio da BPMN por exemplo, que carente de um metamodelo no
muito mais do que uma moderna rgua de gabarito.
Como a UML um padro de facto para a modelagem de sistemas, sua adoo para a
modelagem de negcios reduz tradues e consequentes problemas. A comunicao
entre a turma de negcios e a turma de sistemas se torna mais natural e
intuitiva.
Reduzimos gastos com ferramentas e treinamento ao adotar um mesmo padro

para a modelagem de negcios e de sistemas.
A EPBE expande os velhos padres de modelagem de negcios (organogramas e

fluxogramas), oferecendo novas maneiras de se ver um negcio.
A EPBE est disponvel em diversas ferramentas, tanto comerciais quanto aquelas

gratuitas e / ou de cdigo aberto.
UML e EPBE so extensveis. Podemos adaptar os padres para acomodar aspectos

que sejam exclusivos de determinado domnio. Alm disso, podemos incorporar novas
ferramentas, como Balanced Scorecards, Mapas Estratgicos e outras que no fazem
parte do desenho original destes padres mas se configuram importantes elementos de
um negcio.
Casos de uso, uma das principais ferramentas utilizadas por um AN para a descoberta e
descrio de requisitos, tambm uma das 5 vises oferecidas pela UML. Configuram
a viso central, aquela que permite rastreabilidade entre as demais vises (Lgica,
Processo, Implementao e Distribuio), ou seja, a ligao entre os requisitos e todos
os artefatos gerados em um projeto. Est aqui a ligao entre modelos de negcios e
modelos de sistemas.
Se a lista acima no foi sufiente para convenc-lo do uso da UML para a modelagem de
negcios, ento talvez voc queira interromper a leitura por aqui mesmo... Pera!
Brincadeirinha. Mesmo que por algum motivo qualquer voc no queira ou no possa utilizar
a UML, o mais importante neste e nos prximos captulos desta parte so os conceitos. De
certa maneira, todos os diagramas aqui sugeridos podem ser feitos em outra linguagem. At
numa linguagem inventada por ti. Ento, por favor, siga adiante.
Quando Modelamos?
Parece consenso, pelo menos terico17, que todo projeto comea pelo entendimento do
negcio, ou seja, pela modelagem do negcio. Se nenhum estudo necessrio, se toda a
compreenso sobre o negcio compartilhada por todas as partes interessadas, ento no h o
que modelar. No se deixe enganar, essa situao rarssima. Quase sempre precisaremos, no
mnimo, de um ou outro modelo. Quando eles devem ser gerados?
Quando a necessidade de entendimento de determinado aspecto do negcio for percebida. Em

um processo iterativo e incremental, a modelagem de negcios pode ocorrer durante
praticamente todo o projeto. Na medida em que novos processos ou atividades de negcio
virarem escopo de uma iterao, a necessidade de gerar modelos de entender aquela parte do
negcio, pode aparecer. O modelo de ciclo de vida iterativo e incremental aparece em
diversos momentos deste texto. Chegou a hora de entender seus conceitos bsicos.
Logo no incio de um projeto precisamos ter uma viso do todo, algo que em ingls chamam
de big picture. como se fosse uma fotografia instantnea com uma caracterstica muito
peculiar: ela tem 2 quilmetros de extenso e apenas 2 centmetros de profundidade.
Normalmente ela ser um elemento da Viso do Negcio.
Esta grande fotografia ser o mapa que nortear todos os trabalhos da equipe. O AN, ao
entender o problema de negcio e os requisitos do usurio, ajudar a equipe a definir as
prioridades a sequncia de trabalho. De todos os elementos retratados nesta figura, onde est
aquele que mais crucial para a soluo do problema? O trabalho deve comear por ele. O AN
vai detalh-lo, saindo dos 2cm iniciais para 4, 8, ou 16 centmetros, dependendo da
complexidade do problema em questo e das necessidades de entendimento das partes
interessadas. Aps entregar este estudo para a equipe de construo, o AN parte para o segundo
elemento mais importante. No sem antes avaliar os resultados da iterao anterior. E assim
sucessivamente.
Vejamos o ciclo de vida de um projeto de uma forma insanamente simples, como sugerida
por Scott Berkun18:
Todo e qualquer projeto tem 3 fases bem

delimitadas: i) aquela onde definimos o que
precisa ser feito; ii) depois o momento em
que selecionamos e desenhamos a melhor
soluo; e finalmente, iii) a fase em que a
gente constri a soluo. O desenho ao lado,
intencionalmente, nos lembra uma cascata.
Figura 4: As 3 Fases de todos os projetos.
17 Porque na prtica pouca gente modela.
18 No obrigatrio A Arte do Gerenciamento de Projetos, de Scott Berkun. Artmed Editora (2008). Este
trabalho reaparece na Bibliografia Comentada e em diversos pontos deste livro.
58 Captulo 4
Quando um projeto utiliza o modelo de ciclo de vida cascata, cada uma das trs fases acima
ocorrem apenas uma vez. Quando falamos sobre um modelo iterativo e incremental, a
primeira impresso que fica a de que este modelo nada mais que do que um monte de
cascatinhas. uma forma simples de entender, mas ela esconde alguns perigos.
A principal justificativa para a adoo de um ciclo iterativo e incremental a aproximao com

os usurios e clientes. Incentivamos assim que eles avaliem e nos deem retorno sobre nosso
trabalho o quanto antes, e diversas vezes no decorrer do projeto. Ao ver o processo iterativo e
incremental como um monte de cascatinhas ignoramos esse retorno, o que no correto. O
feedback de usurios e clientes define ou altera o plano de trabalho das iteraes futuras.
O que em outros modelos de ciclos de vida tratado como mudana, em um processo iterativo
visto como evoluo, como o amadurecimento da soluo. O princpio muito lgico:
somos humanos, vamos errar. Ao adotar um processo iterativo e incremental assumimos nossa
falibilidade, nossa humanidade.
Voltemos ao grfico acima. O trabalho do AN se limita a primeira caixinha, na definio do que

precisa ser feito. Ento, se em determinado projeto est prevista a realizao de 10 iteraes,
entendemos que o trabalho do AN, a modelagem do negcio e o desenvolvimento dos
requisitos, ocorrer 11 vezes. Onze? Sim, porque consideramos que a construo daquele
instantneo de 2km X 2cm uma iterao em si que podemos chamar de Iterao 0
(zero).
Como eu prometi o bsico sobre o modelo iterativo e incremental, aproveitemos o momento

para aprender outras coisinhas bsicas:
Iterar vem do latim itetare, que significa repetir. Estamos dizendo que repetimos
determinadas atividades n vezes no decorrer de um projeto.
O modelo tambm incremental porque cada iterao, cada repetio deve significar o
acrscimo de funcionalidades a soluo.
A durao das iteraes fixa. O escopo pode alterar, mas o prazo no. Quanto maior a
insegurana e / ou a volatilidade dos requisitos, menor deve ser a durao de uma
iterao. Para no complicar as organizaes podem adotar 2 padres: 30 dias para
projetos calmos e 15 dias para projetos nervosos.
O trmino de cada iterao, com exceo da iterao zero, significa a entrega de

software rodando. Isso mandatrio. S assim usurios e clientes podem avaliar a
evoluo e a qualidade do trabalho. No h nem nunca existiro modelos ou
documentos que substituam o software. O que no significa que este release esteja
pronto para ser colocado em ambiente de produo, por favor. Na maioria das situaes
as entregas intermedirias sero avaliadas em um ambiente de homologao ou testes.
Na indisponiblidade do usurio, o AN quem deve receber e avaliar o software. Mas

este, definitivamente, no o cenrio ideal. A avaliao de usurios e clientes no pode
ser terceirizada. Uma boa alternativa a liberao quinzenal para AN's e mensal para os
usurios.
Como Modelamos?
Voc reparou a sequncia de tpicos deste captulo? Ela apresenta uma parte muito importante
do know-how, do saber como modelar. Espere, no precisa voltar l no incio. Vou repetir a
sequncia abaixo:
Por que modelamos?

O Que modelamos?
Quanto modelamos?
Onde modelamos?
Quando modelamos?
Como modelamos?
Esta sequncia de perguntas um dos trs principais componentes de uma metodologia

proposta por Dan Roam no livro The Back of the Napkin Solving Problems and
Selling Ideas with Pictures19. Chamada de 6 W's20, essas questes representam 6 maneiras
de ver as coisas. A ordem das perguntas importante. Sua lgica tem justificativas at no ramo
da neurobiologia. Claro que no vou me aprofundar tanto aqui. Se voc ficou curioso, leia o
livro do Dan21. Nos interessa aqui saber como modelar. E nosso processo de modelagem, de
entendimento do negcio, fica mais fcil se tentar responder essas 6 perguntas em sequncia22:
1. Por qu?
2. Quem ou O Qu?
3. Quanto?
4. Onde?
5. Quando?
6. Como?
Mas preciso avisar que, apesar da lgica (e da neurobiologia), tomei a liberdade de alterar a
sequncia original de perguntas proposta por Dan. O por que sua ltima pergunta. Para ns
ser a primeira. E a explicao simples: o AN comea o trabalho tentando entender porque
foi colocado no projeto...
Ok, mais importante que isso. A primeira pergunta : por que o projeto necessrio? Por que
a empresa precisa do produto deste projeto? Este o ponto de partida da anlise de negcios.
aqui que aprendemos os Requisitos de Negcio.
19 Portfolio (2008).
20 6 W's porque no ingls as perguntas so: Why, Who/What, How Much / How Many, Where, When e How.
Ok, o cara forou a barra. Tem dois H's ali no meio. Mas as palavras tambm possuem um W. Ento, t
valendo. Voc entendeu.
21 E veja mais detalhes sobre ele na Bibliografia Comentada, no final deste livro.
22 Pois , para os caras fcil decorar 6 W's. Mas podemos tentar. Que tal? PQQOQC? Tente em voz alta:
PQQOQC? Se ainda no decorou, fique calmo. Logo ser to natural quanto contar de 1 a 6.
60 Captulo 4
A pergunta seguinte nos ajuda a descobrir quem ou o que est envolvido no problema /
oportunidade em questo: Quem o nosso cliente? Qual o nosso produto? O que que t
pegando?
Depois nos preocupamos com o quanto: Quanto a empresa espera ganhar? Quanto ela vai
economizar? Quantos iro para o olho da rua?
Na quarta questo avaliamos o onde: Onde a coisa vai acontecer? O objetivo aqui localizao
mesmo: mercado, regio, departamento. Qual o local?
S ento mergulhamos no quando, nos aspectos temporais do problema em questo: Quando

esse problema ocorre? Qual deve ser a sequncia de eventos ou atividades?
E, finalmente, chegamos no como: Como a empresa atende seus clientes? Como ela executa
determinado processo? Como ela fabrica? E assim por diante. Precisa dizer que o como a
pergunta mais difcil de ser respondida? Que a mais complexa? Que aquela que tomar a
maior parte de nosso tempo? O como a cola das 5 questes anteriores.
Livros sobre modelagem costumam ser muito generosos na definio do que devemos
desenhar, mas excessivamente econmicos na descrio do processo de modelagem. Eriksson e
Penker, por exemplo, j abrem seu livro avisando que no se trata de uma metodologia de
modelagem. Apesar de no se tratar de um livro sobre modelagem de negcios, o trabalho de
Dan Roan cobre esta lacuna de uma maneira muito prtica e didtica. Seu mtodo indicado
para qualquer pessoa, para a soluo de qualquer tipo de problema. Meu trabalho aqui foi
remixar o melhor dos dois mundos em uma proposta especfica para analistas de negcios.
No prximo captulo estudaremos este remix e os conceitos bsicos da modelagem de negcios.

Guia para A Formação de Analistas de Negócios - Draft 0.9

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia para A Formação de Analistas de Negócios - Draft 0.9

Enviado por

Direitos autorais:

Formatos disponíveis

1

Guia para a Formao de

Crditos & Dbitos

copiar, distribuir, exibir e executar a obra

criar obras derivadas

Sob as seguintes condies:

Atribuio. Voc deve dar crdito ao autor original, da forma

Uso No-Comercial. Voc no pode utilizar esta obra com

Compartilhamento pela mesma Licena. Se voc alterar, transformar, ou

Nada nesta licena impacta ou restringe os direitos morais do autor.

Outras informaes Legais e sobre a Editora

Houve um tempo em que a formao de analistas de sistemas contemplava de maneira

No por acaso, o alinhamento estratgico de TI com o negcio figura h tempos em listas de

Calma: no estou afirmando que a presena de um AN por si s promove o tal alinhamento

Comparada a outras reas de conhecimento que tratam do desenvolvimento de sistemas, a

No contexto de um ou mais projetos, lanamos mo dos mtodos e prticas que formam a

Que no so, necessariamente, projetos de sistemas. A soluo para um problema de negcio

comum a apresentao da anlise de negcios como uma funo estratgica3. Apesar do

2 Partes interessadas: traduo do termo stakeholder.

J existe uma proposta de estrutura para o corpo de conhecimentos da anlise de negcios, o

Este guia apresenta a anlise de negcios em trs partes:

Entendendo o Usurio: nome alternativo para engenharia de requisitos. O conjunto

Viabilizando o Projeto: o AN auxilia unidades de negcios e a rea de TI na

IIBA & BABoK

Produto do trabalho de dezenas de colaboradores, dentre eles renomados metodologistas como

Figura 1 - As 6 disciplinas do BABoK

Planejamento da Anlise de Determinar o que precisa ser feito.

Na verso 2.0 a modelagem de negcios surge durante a apresentao da tcnica modelagem

8 BABoK version 2.0 Draft for Public Review. IIBA (2008).

Definindo o Analista de Negcios

De uns tempos para c, algumas empresas foraram a aproximao de diretores e gerentes de

Entender: o AN entende o negcio seus problemas e oportunidades, e tambm as

Comunicar: durante todo o processo de entendimento e avaliao que, diga-se de

Uma Profisso, Vrios Nomes

Analista de Requisitos: como o prprio nome indica, se limita ao levantamento,

Multiplicadores: termo que indica claramente a responsabilidade de aprender

Product Owner: ou Dono do Produto, termo cunhado no mtodo gil para

Outros termos, relativamente estranhos, so utilizados em algumas empresas brasileiras para

No entanto, com a mdia e principalmente o IIBA promovendo o nome Analista de

Independente do nome, afinal, como se d a formao de analistas de negcios, ou de

Formando Analistas de Negcios

No entanto, como colocado anteriormente, os currculos vigentes do enorme nfase ao

A lista abaixo destaca as principais habilidades sociais que um AN deve desenvolver:

Aprendizado: um bom AN aprende rpido. E aprende direito. Sabe identificar as

Comunicao: o AN um exmio comunicador. Conversando, escrevendo,

Negociao: no basta se comunicar bem, o AN deve negociar bem. Em diversos

Pensamento Sistmico: habilidade que em algumas rodas chamada de (ante)viso

Capacidade de Sntese: o AN deve ser capaz de, a partir de informaes diferentes

10 A Quinta Disciplina, Peter M. Senge. Editora Best Seller (2000).

Modelagem: a capacidade de gerar abstraes de algo que existe no mundo real.

Modelagem de Negcios: representao dos aspectos mais importantes de um

Modelagem de Dados: dados e informaes so recursos de uma empresa.

Modelagem de Sistemas: claro, no muito recomendado que um AN seja

Prototipao: porque prottipos so modelos. O AN deve conseguir gerar

Tcnicas para o Desenvolvimento de Requisitos: entrevistas, sesses JAD

Especificao e Estruturao da Voz do Usurio12: o usurio fala muita

Redao de Casos de Uso: um documento criado especificamente para facilitar a

Preparao e Execuo de Testes: porque o AN a ltima pessoa que testa uma

Viabilizao da Soluo: alm das habilidades sociais necessrias para a viabilizao

Situao diferente daquele AN que atua apenas em uma empresa. A necessidade de

Analistas de Negcios Por que agora?

Vamos aos fatos:

1. Negcio e TI nunca tiveram um relacionamento muito amistoso. No por acaso o tal