Anlise de Negcios - Gostei desse negcio, mas por onde comear?

(verso 2010*)
* Este artigo uma reviso de um artigo escrito em fevereiro de 2009. O mundo mudou, e ele tambm.

Voc foi picado pela mosquinha da anlise de negcios? Acredita que ela pode ajudar a resolver problemas que vem atormentando os seus projetos? Descobriu nela um lugar para as suas habilidades de profissional de negcios que adora TI ou de profissional de TI que adora negcios? Apesar da procura dos profissionais, mesmo com o BABOK 2.0 disponvel h meses, existe pouca informao formatada para quem est comeando ento pensei que um guia rpido ainda poderia ser til. Como sou cada vez menos formal, ando priorizando comunicao no lugar de documentos abrangentes, escrevi esse guia com a informalidade de uma conversa, tudo de cabea - sem referncias - s o que est fresquinho na cuca. um papo que eu levaria com um amigo interessado no assunto. Se tiver alguma dvida ou estiver faltando algo, envie um e-mail, ok? Em 2009, quando escrevi este guia, ao colocar anlise de negcios no Google, meu site era um dos primeiros a aparecer. Meu site ainda est longe de ser um site de referncia sobre o assunto, mas independente disso, minha experincia com anlise de negcios relativamente rica. Requisitos so a minha vida desde quando produzi meu primeiro website comercial l nos anos 90. Os negcios embarcaram nela pra valer ali por 1999, depois que saquei que precisava entender dele tambm, e no s de software. Ocorreu que a minha primeira empresa de Internet (imvel on-line) foi um sucesso tcnico. O site era bonito e fcil de usar, sistema em PHP e mySQL, mil acessos por dia (isso mesmo, mil visitantes nicos por dia em 1999), mas foi um fracasso completo como negcio. Baixei a bolinha, voltei facul para estudar administrao e marketing. Na experincia recente, na Dgitro, entre 2007 e 2008 eu montei as bases para o que hoje uma rea de anlise de negcios que funciona dentro da rea de TI responsvel pela gesto dos sistemas internos. Na IONICS, onde passei dois anos, implantei e liderei o escritrio de anlise de negcios, o EAN que trabalha com a gesto dos requisitos dos produtos oferecidos pela empresa. Hoje o desafio facilitar a utilizao de anlise de negcios dentro de um contexto gil na Stefanini. Experincias diferentes e enriquecedoras. Na real, eu teria muito para escrever sobre as experincias do dia-a-dia com anlise de negcios, ocorre que devo manter relativo sigilo em relao aos trabalhos atuais em respeito s estratgias da empresa na qual trabalho. Quando me sinto moralmente livre para divulgar abertamente as experincias, elas j no tem mais aquele cheiro de po quentinho e escrever perde a graa. como liberar o making-off de um filme seis anos depois da sua estreia. Eu coloco no CV, mas os detalhes ficam para as conversas. Difcil busca por informaes Eu no posso ignorar os e-mails que venho recebendo nos ltimos dois anos. Muita gente boa, profissionais de diferentes origens que o Google, mais recentemente o Twitter ou alguma indicao de amigos fazem visitar o meu site e entrar em contato, geralmente via e-mail.

www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com

(1)

As mensagens so parecidas: Ol, meu nome x e eu trabalho como y na empresa w e... a) estou com problemas com meus requisitos... b) meu chefe mandou eu pesquisar sobre... c) me amarro em casos de uso... d) li um livro sobre e fiquei interessado... e) eu li o BABoK... f) o fulano f indicou voc... g) pelo amor de Deus me d uma luz! ... meu background b e eu gostaria que voc me passasse algumas informaes sobre anlise de negcios como livros, cursos, blogs para que eu pudesse aprofundar meus conhecimentos e investir nessa rea. Estou sempre buscando por referncias e ainda sinto que esse pessoal tem motivo para pedir essa mozinha. Hoje (se no considerarmos o lanamento do BABOK 2.0) temos praticamente as mesmas poucas informaes que eu tinha quando me interessei pelo assunto no final de 2006. Digamos que o BABOK abrangente demais e os posts nos sites sobre o assunto, picados demais. Alm disso, muito pouco foi escrito para os iniciantes. Os contedos que encontramos (mesmo em ingls) so muito avanados ou trata-se de outros usos para o termo analista de negcios que so comuns tambm. No h nada direto ao ponto e bem basic que voc possa ler em uma pegada. O que Anlise de Negcios? Well, anlise de negcios , nas minhas palavras, foco no problema que precisa ser resolvido. paixo pelo problema. Para entender o que o problema, vamos comear por algo conhecido de quem trabalha com software: a soluo. Existem muitas empresas h tempos vendendo solues, na verdade, Solues o segundo nome de milhares delas. Quando algum vende solues, presume-se que algum entendeu bem o problema para fazer a compra correta. Certo? At parece! Pois ento, ali que o analista de negcios entra, antes dessa deciso desastrada que implicaria um projeto problemtico ele entra em cena e comea a fazer perguntas inconvenientes como uma criana de trs anos encadeando um novo por que? a cada resposta at ficar cansado, satisfeito ou at chegar ao big bang - o que vier primeiro. claro que existe toda uma metodologia para se conseguir as informaes a respeito do objeto da sua paixo - o problema - mas a lgica primordial a seguinte: tudo, eu repito, tudo o que se faz em uma organizao dentro de projetos est (ou deveria estar) ligado estratgia dessa organizao. Nada existe por acaso. Em suma, os processos so como o motor do carro, ele gira mais rpido ou mais de vagar, mas para virar para os lados e mudar de fato a rota voc precisa de projetos. Projetos e processos Apenas para lembrar, processos so atividades que seguem um fluxo e so executadas
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (2)

inmeras vezes, utilizando os mesmos recursos e sempre com o objetivo de gerar o mesmo produto (ou resultado). Quanto mais semelhantes forem os resultados de um processo melhor ele est sendo executado. J um projeto um esforo temporrio feito por um nmero definido de pessoas com o objetivo de gerar um produto (ou resultado) nico. Assim, voc pode at participar de um projeto que tem como objetivo o desenvolvimento de um novo processo, contudo, uma coisa uma coisa e outra coisa outra coisa. Quando falo que para mudar a rota so necessrios projetos, me baseio em algo que vi em um curso do PMI: Projetos ligam a estratgia aos resultados. Esse link me fez falta a faculdade toda, pois em uma aula estudada estratgia, na outra aula processos, mas no sabia como implementar a estratgia, ficava na conversa. Voltando para o negcio Essa pedra me atingiu quando depois de alguns anos fazendo websites por fazer (por que era divertido e eu era bem pago), me toquei que eles eram produzidos devido a objetivos estratgicos como fortalecimento da marca ou aumento das vendas. O projeto do site era a ao que ligaria a estratgia aos resultados. Isso verdadeiro mesmo que essa estratgia esteja na cabea de uma pessoa apenas, geralmente o presidente da organizao. Voc provavelmente vai encontrar diferentes nveis de organizao e transparncia da estratgia indo da cabea do presidente at elaborados mapas estratgicos. O importante saber que ela existe, mesmo quando escondida. Com base nisso temos o primeiro ponto de ruptura com uma imagem antiga do analista de negcios que focava apenas no levantamento de requisitos, limitado ser apenas um dos subordinados engenharia de requisitos. Isso porque no basta voc receber uma misso e sair entrevistando pessoas perguntando o que elas gostariam que fosse feito nos sistemas ou produtos. Se fizer isso, o valor que voc ir trazer ao projeto ser muito limitado, talvez voc reme muito bem, mas pode at remar para o lado errado. Falando em valor, o grande valor de um analista de negcios est em ajudar a organizao a definir quais so os projetos prioritrios, isso com base na estratgia, ou seja, voltando ao negcio, voc precisa conhec-lo intimamente. No saia colocando a mo nos seus sistemas sem levar para jantar e pegar um cineminha. Apenas essa intimidade vai trazer fundamentao verdadeira para o seu trabalho. A modelagem de negcios Para conhecer tudo o que importante para o projeto em relao organizao necessrio efetuar a modelagem de negcios. Por modelagem no estou me referindo estritamente a modelos grficos como organogramas ou UML e BPMN, me refiro a conhecer a empresa a partir de vrias vises. Alis, modelamos para aprender, comunicar, e s por ltimo, para documentar.

www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com

(3)

Como no projeto de uma casa, voc s o entende de verdade se ver a planta, as vistas, cortes, hidrulico, eltrico, sanitrio e memorial descritivo. No a casa em si, so representaes que se limitam a partes importantes para o projeto, por isso chamamos de modelos. Em uma organizao, essas vises passam pelo planejamento estratgico, pelo organograma e pelos diferentes tipos de processos. - necessrio saber tudo isso para fazer um pequeno projeto? - No. Voltando para a analogia da casa, se voc for reformar uma parede colocando uma janela pode bastar voc mapear aquele cmodo dando especial ateno para os eventuais canos e fios que cruzam as suas paredes. A arte de definir o que ou no relevante para a construo do modelo chama-se capacidade de abstrao. Abstrair remover. Tudo a tem em maior ou menor grau. Um bom exemplo de abstrao quando voc conta uma anedota para seus amigos. Um bom contador foca na histria e jamais vai se ater a detalhes como o nome do papagaio safado. O nome abstrado. - Odeio essas coisas de planejamento estratgico, objetivos, metas, participao em mercado me d arrepios. Prefiro J2EE, eu mando e ele obedece. - Amigo, melhor voc criar gosto ou permanecer no lado da soluo. Sabe, nenhum lado mais importante do que o outro e o trabalho dos diferentes profissionais complementar e igualmente importante, ento prefiro ter voc trabalhando comigo como analista de sistemas, arquiteto, ou Srcum Master feliz da vida. Bom, voltando ao pessoal interessado, no domnio do problema assim que chamamos o estudo do qu deve ser feito, infelizmente ainda existe apenas uma pessoa falando srio sobre modelagem de negcios, eu vou falar dela mais adiante junto s referncias. Da estratgia ao requisito - fazendo sentido Falei anteriormente que projetos ligam a estratgia aos resultados. Vamos ver como isso ocorre do ponto de vista dos requisitos, partindo de algo que apareceu na sua mesa, digamos que, escrito em um post-it amarelinho: Como um caixa da lanchonete, eu posso digitar os pedidos durante a venda para que o pessoal da montagem possa ver no telo o que deve ser feito. Requisito interessante, no? O caixa vai digitando o pedido e ele vai aparecendo em uma fila de pedidos para o pessoal que monta os hambrgueres e as batatas fritas. Mas de onde ele surgiu? Bem, evidente que este requisito est ligado a um sistema. Esse sistema utilizado para apoiar o processo de venda da lanchonete. Ele ajuda muito, pois permite que pessoas com diferentes responsabilidades tenham informaes em tempo real do que est acontecendo alm de possibilitar pagamento atravs de diferentes meios e de guardar registros para a administrao. Show de bola. em busca disso que as empresas investem tanto em sistemas de informao. O processo de venda da lanchonete depende de diversos fatores para que ocorra de forma satisfatria. Os ingredientes devem estar disposio, o atendente deve saber quem do pessoal que
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (4)

lota o balco deve ser atendido agora, deve haver troco no caixa, a conta de luz deve ser paga, entre outras inmeras coisas, a tecnologia da informao deve trabalhar para que a informao corra livremente atravs da tecnologia. Essa interdependncia entre as diferentes funes se chama nvel operacional. O sujeito que monta a bandeja sabe que o sujeito das batatas entrega novas batatas a cada trs minutos, e esse por sua vez sabe que sempre vai ter batatas novas cortadinhas no pote ao lado. Isso tudo pode parecer bastante industrial e arcaico, mas lembremos que bons processos so aqueles que so executados com o mnimo de distoro possvel. O mundo pode sentir falta da criatividade em muitos campos, inclusive no nosso, contudo, a maior parte das coisas que voc v funcionando ao seu redor nesse exato momento, depende de processos repetitivos. Esta srie de responsabilidades encadeadas formam o nvel de servio do negcio. Um exemplo muito comum de nvel de servio no nosso dia a dia est ligado contratao de servios de infraestrutura. Contratamos hospedagem em servios que nos garantem funcionamento durante 98% do tempo com resposta para chamados em at duas horas. Tanto o 98% quanto as duas horas so nveis de servio que so acordados durante a contratao (Service Level Agreement SLA). Os nveis de servio existem em todos os tipos de negcios, mesmo quando no so declarados de forma to direta quanto nos contratos de infraestrutura. Pensando na nossa lanchonete, os usurios sabem, mesmo que instintivamente, que sero atendidos em at no mximo quatro minutos, e que depois de efetuar o pagamento, no esperaro mais de sete ou oito minutos pelo lanche. Essa imagem se constri ao longo dos anos e fundamental para quem trabalha no ramo de fast food. Os nveis operacionais so chamados em ingls de OLA (operational level agreement). A equao do nvel de servio algo como: SLA = OLA + OLA + OLA... ou SLA = OLA. Olhando essa equao fica claro que o elo mais fraco da corrente pode trazer problemas para o negcio. Voc pode estar com a sua bandeja quase pronta, mas precisa esperar at chegar as batatas fritas. E aquele requisito, de onde veio? Ou melhor, de onde ele deveria ter vindo? Da estratgia da lanchonete. A alta cpula da lanchonete descobriu atravs de pesquisas mercadolgicas que se conseguisse diminuir o seu SLA mdio de entrega de pedidos em pelo menos 8% conseguiria papar mais 5% do mercado. Parece que uma boa parte dos clientes da lanchonete trabalha com software e est sempre na correria para atender aos prazos de seus projetos. Algum - imaginamos que o analista de negcios ou quem o acionou estudando o processo (recomendo nesses casos a observao passiva, ou seja, ficar parado ao lado da lanchonete observando atentamente como o trabalho realizado) notou que gritar os pedidos traz alguns erros que no final acabam atrasando o SLA mdio da lanchonete. Em suma, voc como analista de negcios da lanchonete sabe que para ela crtico diminuir o tempo de entrega de um pedido (e tambm os erros que ocorrem no escopo dos hambrgueres) e atravs do estudo dos processos chegou at aquele requisito que est sobre a sua mesa.

www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com

(5)

Agora voc pode ter pensado mas isso nunca aconteceu comigo, eu costumo ser jogado em um projeto que tem um escopo mais ou menos claro e saio atrs de levantar e detalhar os requisitos. Isso normal e ocorre o tempo todo. O que eu peo para que voc faa um esforo para sempre buscar os por qus, as razes daquilo estar sendo feito. Esses questionamentos podero levar a grandes revelaes e permitir que seu projeto traga mais valor para a organizao, e no final, isso que interessa para um analista de negcios. Requisitos so tinhosos, em empresas bagunadas como as nossas eles costumam pipocar de todos os lados e voc s vezes o pegar l embaixo e seguir o caminho acima tentando entender o porqu dele. Vale a pena. Mesmo parecendo idealista, o caminho lgico de cima para baixo, removendo um pouco da abstrao a cada passo. Esse o objetivo a se seguir. Aqui aproveito para falar da rea de conhecimento do BABOK que considero mais importante, a elicitao. Veja, se voc trabalha em uma rea de TI voluntariosa, que faz todo o possvel para entregar o que os clientes pedem, descasca os chamados assim que eles chegam, pode ser que voc no esteja fazendo um bom trabalho. Esta devoo cega ao trabalho costuma levar a grandes problemas (que geralmente aparecem na base de dados e atravs de bugs misteriosos), pois as coisas so implementadas fora de contexto e ao sabor do vendo. O analista de negcios deve sempre ter o todo em mente e, atravs da elicitao, buscar conhecer o que o cliente precisa e no somente o que ele quer. Voltando s abstraes, os diferentes nveis foram tirados do livro do Cockburn, que trata sobre como escrever casos de uso eficazes. Ele definiu diferentes nveis de abstrao para os casos de uso sendo que os de baixo sustentam os de cima: Nuvem L encima, o nvel de servio (SLA), o que voc entrega para o cliente. Seu fluxo a interao do cliente com a empresa. Em marketing a experincia. Pipa Mais embaixo, o nvel operacional (OLA), mostra como as coisas acontecem dentro da empresa enquanto ela luta para atender o SLA. Essa parte conhecida como operaes. Nvel do mar a funcionalidade do sistema que apoia o usurio na execuo da sua parte do processo. Essa parte conhecida como aquele maldito sistema.

Mesmo que voc no utilize casos de uso no seu trabalho, essa lgica ajuda muito a conectar as coisas. Se voc trabalha, por exemplo, com histrias do usurio, coloque elas no nvel do mar, as conexes vo funcionar to bem quanto com casos de uso, afinal, as histrias, como os casos de uso, tambm so objetivos do usurio realizados atravs da interao com o sistema. Esse trabalho que busca os porqus dos requisitos tem tudo a ver com uma coisa chamada eficcia. A eficcia fazer a coisa certa, nadar na direo correta, o alinhamento, no nosso caso, o alinhamento do nosso projeto com os objetivos da organizao. Falando em nadar, eu fiz travessias em guas abertas por um tempo e o pessoal desse ramo sabe que saber nadar bem s parte da equao, levantar a cabea e saber onde voc est e para onde est indo compensando a correnteza fundamental. Eu era muito bom em fazer trajetrias curvas. Uma prova de 1600 metros nunca acabava comigo nadando menos de 2000. Vale ressaltar que o fruto do trabalho nem precisa ser software. Talvez outra soluo como
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (6)

remodelar a disposio dos equipamentos na lanchonete possa surtir o mesmo efeito, ou melhor. O analista de negcios est fazendo o seu trabalho tambm quando descobre alternativas s intervenes no software. L no EAN, por exemplo, nosso foco era entender os clientes dos produtos (hardware e software) que desenvolvemos e vendemos. Como so milhares de clientes, devemos conhecer a realidade do ramo para criar um modelo de cliente que represente o que h de comum entre eles alm de estudarmos todas as demandas particulares. comum descobrirmos maneiras criativas dos clientes resolverem ou contornarem seus problemas utilizando, mesmo que temporariamente, a verso atual do produto sem alteraes no cdigo. No se trata de faz-los engolir o problema, mas de se encontrar uma soluo de contorno enquanto a soluo definitiva no sai da fila. Copiamos isso do gerenciamento de incidentes do service desk da ITIL que por sua vez deve ter copiado isso da medicina. Vai uma morfina a? Bem, at agora falei da eficcia da anlise de negcios, a modelagem de negcios. Agora necessrio falar sobre o que traz eficincia ao trabalho, que faz voc nadar mais rpido, a engenharia de requisitos. Engenharia de requisitos Em software, o requisito o problema que o desenvolvedor ter que resolver. O requisito deve ser comunicado de forma clara sendo que o bom requisito factvel, priorizado, testvel e por fim necessrio (eficcia herdada da modelagem de negcios). Voc alcana isso atravs da engenharia de requisitos. Se voc do ramo de TI imagino que depois de ler aquelas informaes que coloquei na parte sobre modelagem de negcios ao ver esse ttulo deu uma suspirada e se sentiu mais em casa. Isso normal, requisitos incomodam voc h vrios anos, mas pelo menos eles so conhecidos. (Isso cheira sndrome de Estocolmo). Vou estimar (chute) que 90% das pessoas que procuram a anlise de negcios o fazem devido a problemas e experincias traumticas envolvendo requisitos, muitas delas envolvendo projetos no estilo cascata, nos quais a engenharia de requisitos mal executada completamente devastadora. Como grande parte, e posso dizer a melhor parte, do trabalho do analista de negcios expressada na forma de requisitos, sim, o problema nosso. Existe uma srie de prticas para se trabalhar com engenharia de requisitos. Vou ser sincero, apesar deles fazerem parte da minha vida h tempos, parece que cada dia descubro algo novo sobre como descobri-los, desenvolv-los e principalmente comunic-los. Soluo de um, problema de outro Aqui chamo a ateno novamente para os domnios do problema e da soluo. Essa diviso gera muita confuso, pois d a impresso de que o analista de negcios no soluciona nada, pois ele se expressa em requisitos que so na verdade o problema que o desenvolvimento vai ter que resolver. Aqui uso a minha frase preferida: A soluo do negcio o problema do sistema.
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (7)

Ou seja, o analista de negcios trabalha para solucionar problemas de negcio, contudo, as suas solues costumam gerar problemas para o lado do sistema que precisa ser criado ou adaptado. O basico da engenharia de requisitos O basico da engenharia de requisitos cai nessas categorias que se assemelham ao trabalho de um detetive: Descobri-los Entrevistas (descobre quem sabe e pergunta) Observao passiva (fica olhando o pessoal trabalhar) Observao ativa (pe a mo na massa) Pesquisa documental (raramente existe algo bem documentado, mas voc pode descobrir algo importante se fuar bem) Engenharia reversa (analisar a aplicao rodando, fuar no cdigo-fonte e no banco de dados) Desenvolve-los Rabiscar, rabiscar, rabiscar Prototipar Discutir Simular Comunica-los Conversas Texto Casos de uso Estrias Texto livre (o sistema deve...) Modelos UML Diagrama de entidades Mquina de estados Diagrama de atividades Diagrama de objetos Workshops

Bem, essa lista bem bsica e traz apenas o que eu lembro de cabea. Se voc se amarra nisso, recomendo o BABoK, ele detalha bem cada tcnica, ferramenta e fonte de informao. Um trabalho muito mais minucioso do que eu me proponho a fazer nesse texto. Ele apenas uma conversa, lembra? Se voc trabalha com desenvolvimento pode at pensar agora que isso to bsico que se fizermos uma boa modelagem de negcios e uma boa engenharia de requisitos (nesses moldes bsicos) no h como ter problemas nos projetos. s empacotar e tocar para o desenvolvimento e ficar esperando o resultado do outro lado, certo? Errado. No lado da soluo temos pessoas que possuem metas prprias, criatividade, conhecimento, motivao e necessidades. Para fazer acontecer necessrio investir em gerenciamento de equipes e engenharia de software sendo que esta comea no requisito no na soluo. Ento todas as vezes
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (8)

que eu quis trabalhar eu aqui, eles l me dei mal. Minha inteno era boa, mas ingnua. Eu acreditava que se entregasse os requisitos mastigados para os desenvolvedores eles iriam ficar muito felizes por no ter que pensar nessa parte. Me vislumbrava sendo ovacionado por hordas de desenvolvedores felizes. Entretanto, esse estilo de trabalho no era muito cordial e soava arrogante: mim desenha, tu executa. O clima no era bom e aprendi que isso no era a forma certa de trabalhar da pior forma possvel quando os desenvolvedores sabotaram um projeto entregando o cdigo mais vagabundo possvel. Foi um lance meio terrorista, mas eu tinha uma boa parcela de culpa nisso. O mtodo deles foi tosco, eu me ressinto por essa irresponsabilidade, mas aprendi. Essa paulada me fez reavaliar as coisas e cheguei a uma ideia que na prtica deu bons resultados e que tem a ver com o lado humano das metodologias geis, apesar de caber na cascata e em tudo o que existe no meio: O deliberativo, quem decide e o consultivo, quem opina. A ideia que quando estamos pensando no domnio do problema, no requisito, na soluo do problema do negcio, o analista de negcios o deliberativo. Ele representa o cliente e bate o martelo nessas questes, contudo, o analista de negcios sbio traz o desenvolvedor para perto e aproveita as suas contribuies. Isso positivo de duas formas. Na primeira, voc faz uso da experincia daquele profissional que pode revolucionar o projeto. Ele(s) pode(m) ter participado de tantos projetos que conhece(m) encrenca s pelo cheiro do requisito. Na segunda forma, voc tem o desenvolvedor envolvido no projeto mais cedo (se for cascata) e ele se sente realmente participante e influente no projeto, alm do briefing posterior tornar-se quase desnecessrio. No segundo momento temos o domnio da soluo, os desenvolvedores encontrando alternativas para atender aos requisitos. Aqui o domnio deles, eles sabem coisas como, criar as classes de forma que o sistema funcione de forma mais eficiente. Eles sabem que java no vai rodar naquele ambiente. Aqui o desenvolvedor deliberativo, e o analista de negcios consultivo. A histria se inverte e agora ele conta com o seu conhecimento e experincia e tambm com o seu envolvimento na equipe. Todos saem ganhando. Se pegarmos um projeto cascata total, aquele com fases bem separadas j teremos um enorme ganho com essa prtica (apesar dela custar horas de desenvolvedor na etapa de definio do escopo e de analista de negcios na etapa de execuo). Essa dinmica ocorre de forma natural quando o SCRUM aplicado. As reunies de planejamento de uma sprint (iterao) fazem com que o responsvel por representar o cliente (o Product Owner) e o time de desenvolvimento discutam os requisitos e a soluo continuamente, cada um sendo deliberativo ou consultivo ao seu tempo. Se voc trabalha com grandes projetos, recomendo que faa um esforo para diminuir continuamente o tamanho das suas iteraes. Os problemas sero detectados mais cedo e a comunicao entre as pessoas ser mais frequente e melhor. L encima eu citei alguns artefatos para a comunicao de requisitos. Eu gosto muito de alguns deles e tem horas que parece que s consigo falar da parte esttica por meio de diagrama de
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (9)

entidades. Como eu me sentia confortvel me expressando assim, escrevendo casos de uso com maestria acabei ficando tradicionalista, formalista, um verdadeiro poeta parnasiano - tambm conhecido como chato. Comigo era caso de uso ou nada feito, passo a passo, fluxo a fluxo, mas a realidade me fez perceber que o essencial a comunicao correta dos requisitos e que ela encontra o seu clmax na interao humana apoiada por um pedao de papel ou um quadro branco. Isso foi ocorrendo na prtica quando vi projetos nos quais os requisitos eram comunicados em forma de frases com textos adicionais anexos andaram melhor do que aqueles que tinham documentos parrudos, mas interao humana fraca. Eu incomodei um bocado os agilistas at essa ficha cair. Ainda existe quem pense que diminuir a quantidade de documentao diminuir a quantidade de trabalho realizado, contudo, trata-se de redirecionar o esforo para algo que traz mais resultado, a comunicao entre as pessoas. O papel uma das formas de comunicao mais limitadas existentes. No papel no temos gestos, expresses visuais, tons de voz e outras mensagens que enriquecem a interao. A nica vantagem que o papel possui em relao interao pessoal se chama stickness. Stickness quer dizer que o papel fica. Ele sobrevive ao tempo e as pessoas. Um documento permanece inalterado depois de dez anos, j a memria fica fraca, se confunde. A resposta para a pergunta o quanto eu devo documentar? documente apenas aquilo que precisa de stickness, no mais, nem menos. Lembro que o meu preconceito (ou seria ceticismo?) com as metodologias geis era tamanho que eu cheguei a cunhar a frase Nem todo agilista vagabundo, mas todo o vagabundo agilista. Na verdade, o pior lugar para um vagabundo tentar se esconder em um ambiente de entregas constantes e interao pessoal intensa. Voltando aos domnios Este esquemtico abaixo mostra bem a diviso entre os domnios quando conversamos a respeito de desenvolvimento de software: Domnio do problema Requisito Usurio Analista de negcios deliberativo O que e porque fazer Fontes de informao Howard Podeswa O Howard trabalhou muitos anos como analista de sistemas em empresas de diferentes pases e com o tempo foi sentindo mais necessidade de entender o domnio do problema. Com isso, ele incorporou o que chama de ITBA, ou, analista de negcios de TI. Seu mtodo bastante
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (10)

Domnio da soluo Especificao Sistema Desenvolvedor deliberativo Como fazer e porque fazer assim

pragmtico e muito interessante para quem deseja aprender a utilizar a UML no desenvolvimento e comunicao dos requisitos e no apenas de especificaes. Ele faz um uso magistral dos recursos como diagrama de entidades, atividades, objetos e mquinas de estados ainda dentro dos requisitos. Ele chama isso de BOOM Business Object Oriented Modeling. Vamos falar srio, o mundo composto por objetos. Se at os sistemas que se baseiam nos negcios so orientados a objetos, por que no orientar a prpria modelagem dos negcios? Experimente, pegue qualquer negcio e mapeie as suas entidades como classes, fica muito legal. Para fazer cenrios, use um diagrama de objetos. Todavia ele pensa pouco em modelagem de negcios como definimos anteriormente. Ele se concentra mais no projeto em mos. Se voc trabalha em uma rea de desenvolvimento e precisa colocar ordem na casa rapidamente, sugiro que faa um copy and paste no processo que ele prega e ento faa seus ajustes. S lembre de deixar as iteraes pequenas, por favor. Aquela documentao cheira cascata. O seu livro, UML for the ITBA traz o mtodo completo explicado com base em um caso real. Para termos uma idia do foco do Howard, ele acabou de lanar um guia completo de ferramentas para o analista de negcios do tipo abra e use, The BA handbook que em breve estar disponvel no Brasil em portugus. Atualmente, alm de escrever (e pintar quadros), ele possui uma empresa de consultoria e que licencia os direitos da sua metodologia para empresas que oferecem treinamentos no Canad e Estados Unidos e agora tambm Brasil. Howard um dos revisores do BABoK. Eu tive o prazer de visit-lo em Toronto em 2008, sujeito gente finssima, pena que no se envolve muito em blogs e grupos de discusso, pois traria uma contribuio muito rica. Lembro que modelamos um pequeno sistema em um pedao de papel em um restaurante. Quem gosta de modelar modela em qualquer lugar. IIBA International Institute of Business Analysis O instituto internacional de Anlise de Negcios surgiu no Canad faz pouco tempo e tem como misso a divulgao a anlise de negcios e a definio de um corpo de conhecimento da rea. O seu principal produto, o BABOK (Business Analysis Body of Knowledge) um guia bastante abrangente das atividades de anlise de negcios, das suas tcnicas e competncias. Essas coisas quando surgem l na Amrica do Norte ficam meio de cima para baixo, distantes, contudo, foi aberto um captulo do IIBA em So Paulo no qual estou botando muita f. O objetivo divulgar pra valer a anlise de negcios. Se voc estiver interessado em contribuir, s entrar em contato. O IIBA est atualmente trabalhando em uma extenso gil para o BABOK. Ocorre que apesar de no haver um pensamento cascata no BABOK, comum os leitores interpretarem as atividades de anlise de negcios como sendo uma fase separada do projeto, realizada antes do desenvolvimento ocorrer. A extenso gil vem para deixar claro como ocorre a anlise de negcios em contextos geis. Se eu ler o BABOK de ponta a ponta vou me transformar em analista de negcios?, no exatamente, mas ajuda muito. Atualmente estou trabalhando junto ao captulo So Paulo do IIBA da
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (11)

traduo do BABOK 2.0. Acreditamos que uma verso em portugus ir auxiliar na aproximao entre o IIBA e os praticantes de anlise de negcios no Brasil. Paulo Vasconcellos O Paulo o maior pensador de anlise de negcios no Brasil. Ele formatou um contedo baseado em muito estudo e nas suas experincias de muitos projetos, bons e maus, e criou oficinas de formao para analistas de negcios as quais ele vem ministrando em todo Brasil. Suas oficinas sofrem constantes evolues conforme ele vai estudando e trocando ideias com os participantes. Temos divergncias, entretanto posso dizer que evolu e muito graas tanto s oficinas quanto aos embates que acontecem no grupo de e-mails que ele mantinha para as pessoas que participam das oficinas e que foi recentemente assumido pelo IIBA. Este texto conta com o meu ponto de vista a respeito da anlise de negcios, contudo, muito, mas muito ali foi influenciado pelo Paulo, e por isso sou grato. Est longe de ser uma obra original. Outro grande mrito do Paulo o foco que ele d para a modelagem de negcios. Ele foi quem a colocou no mesmo patamar da engenharia de requisitos pra valer. O Howard passa longe disso, o BABoK destinou to pouco espao que o Paulo chegou a cham-lo de REBoK. Como vimos, a modelagem de negcios merece carinho (alm do jantar e do cineminha). Est mais que na hora do Paulo publicar um livro sobre anlise de negcios, ele j ameaou fazer isso em 2009, mas depois cancelou. Quando sair, ser uma bela referncia. Depois de ler tudo isso, afinal, por onde comear? Bem, eu sugiro as seguintes aes para o curto prazo: Fale com outros profissionais: No fique s nas minhas palavras, procure apoio de outros profissionais que j foram mais a fundo do que voc no assunto. Critique as minhas opinies e desenvolva as suas. Faa cursos: Recomendo as oficinas do Paulo Vasconcellos de modelagem de negcios e de engenharia de requisitos. Recomendo tambm (claro), os cursos da Noble Inc Brasil, criados pelo Howard Podeswa e ministrados por mim. A Interdual tambm possui cursos muito bons prprios e trazidos dos Estados Unidos. Envolva-se com o IIBA: D uma boa lida no BABOK 2.0. Apie o captulo do IIBA mais prximo de voc. Participe do grupo de analistas de negcios: O IIBA mantm um grupo de discusses para os interessados em anlise de negcios. Participe, mas participe mesmo, pergunte, incomode, feche o pau, mas enriquea a discusso, no seja um zumbi. Estude negcios: Voc da rea de sistemas? Que tal um livro sobre estratgia, processos, marketing ou finanas? Tudo isso vai ajudar muito sua modelagem de negcios. Estude engenharia de software: No h como escapar, mesmo que o seu perfil seja mais administrativo, voc precisa levar em conta que as coisas s saem com uma boa engenharia de
www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com (12)

software, estude alguma opo, conhea metodologias mais tradicionais e as que esto na moda. S far bem e aproximar voc dos desenvolvedores (e da realidade). Por fim, o mais importante: APLIQUE TUDO O QUE VOC APRENDEU Escrevi grande, pois muito importante. No espere estar nas condies ideais para fazer anlise de negcios. No espere algum convidar voc para montar uma rea ou dar para voc o emprego dos sonhos. Anlise de negcios envolve prticas que podem ser aplicadas em diferentes reas e momentos. Voc trabalha em uma rea pequena gerenciando um sistema chinfrim? Voc auxiliar de assistente de estagirio? E da? Ser analista de negcios tem mais a ver com atitude do que com cargo, tem mais a ver com autoridade do que com poder. Trate seu sisteminha chinfrim como um rei, estude e comporte-se como analista de negcios. Essa prtica vai ensinar muito e trazer muito retorno profissional. Falando em rei, sempre lembre que antes de ser o melhor jogador de futebol do mundo o Pel era o melhor engraxate de Santos. Resumindo tudo Anlise de negcios se concentra no domnio do problema, para entender o problema voc precisa entender o negcio e isso se faz atravs da modelagem de negcios que representa o que importante para o projeto a partir de diferentes vises. Atravs dela voc alcana a eficcia que quer dizer fazer a coisa certa, pois traa uma linha que vem da estratgia aos requisitos. Os requisitos so a forma atravs da qual o analista de negcios expressa a maior parte do seu trabalho. A engenharia de requisitos garante a sua eficincia (fazer direito) atravs de uma srie de tcnicas para que voc descubra, desenvolva e comunique os requisitos garantindo que eles estejam corretos, sejam factveis e, sobretudo, necessrios. Lembro que anlise de negcios serve para todo tipo de projetos, independente do produto do trabalho ser software. s vezes voc acaba at evitando que se produza software. Foco no domnio do problema no quer dizer que voc vai abandonar a soluo s moscas. Quanto mais integrado o trabalho com os desenvolvedores melhor, por isso proponho o deliberativo e o consultivo: que na hora do problema voc seja o responsvel e eles opinem e na hora da soluo eles sejam os responsveis e voc opine. Entender de engenharia de software (ou de produo) para o analista de negcios to importante quanto entender de negcios. As fontes de informaes sobre anlise de negcios que recomendo so: Howard Podeswa, focado em utilizar UML para expressar requisitos e no s especificaes pensando no negcio orientado a objetos. O IIBA que pretende divulgar a anlise de negcios e definir seu escopo de prticas atravs do BABoK. E por fim o Paulo Vasconcellos que o maior pensador do assunto no Brasil. normal que com um contedo to corrido, resumido e de cabea voc sinta falta de alguma informao. Fique a vontade para entrar em contato: claudiobr@claudiobr.com

www.claudiobr.com | Twitter: oclaudiobr | claudiobr@claudiobr.com

(13)