Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Paulo F. Vasconcellos
Jan-Fev/2009
Voc pode:
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.
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 )
Prefcio
ndice
Introduo
Captulo 1
Introduo
Captulo 1
Introduo
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 superheri 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.
O Analista de Negcios
13
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.
14
Captulo 2
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.
15
O Analista de Negcios
Disciplina
Propsito
Planejamento da Anlise de
Negcios
Anlise da Organizao
Elicitao
Anlise de Requisitos
Avaliao e Validao da
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
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.
O Analista de Negcios
17
Analista de Processos: funo que pega carona na onda BPM (Business Process
Management). Especializa-se na anlise e desenho de processos de negcios.
9 The Rational Unified Process An Introduction (Second Edition). Philippe Kruchten. Addison-Wesley (2000).
18
Captulo 2
O Analista de Negcios
19
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:
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.
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.
O Analista de Negcios
21
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:
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:
12 Termo utilizado originalmente por Karl Wiegers em Software Requirements, Microsoft Press (1999).
13 http://en.wikipedia.org/wiki/Ivar_Jacobson
O Analista de Negcios
23
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
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.
O Analista de Negcios
25
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 acomodlo? 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:
Por ser um desenho centralizador, TI tem mais poder de deciso sobre prioridades de
alocao dos AN's.
E desvantagens:
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.
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.
do Negcio ou de TI?
29
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.
do Negcio ou de TI?
31
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:
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.
do Negcio ou de TI?
33
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.
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.
do Negcio ou de TI?
35
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 :
Guiada pelo Valor: seus membros compartilham interesses ou prticas. O valor est
no processo de aprendizado.
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
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:
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.
do Negcio ou de TI?
37
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.
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.
do Negcio ou de TI?
39
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:
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.
do Negcio ou de TI?
41
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:
do Negcio ou de TI?
43
Dois Lderes
Vou justificar minha sugesto apelando novamente para Fred Brooks10, que no mesmo livro j
referenciado acima falou mais ou menos assim:
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/
do Negcio ou de TI?
45
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:
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 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
47
do Negcio ou de TI?
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 modella? 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
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:
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.
51
Modelagem de Negcios
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.
52
Captulo 4
Modelagem de Negcios
53
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:
A iluso de que este modelo estar imune as mudanas que afetam diariamente um
negcio.
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
IDEF9
(Integration DEFinition)
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
55
Modelagem de Negcios
Linguagem de Modelagem
BPMN12
(Business Process Modeling
Notation)
56
Captulo 4
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.
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.
57
Modelagem de Negcios
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.
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.
Modelagem de Negcios
59
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 qu?
Quem ou O Qu?
Quanto?
Onde?
Quando?
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.