Guia para a Formação de Analistas de Negócios

Transcrição

1
Guia para a Formação de
Analistas de Negócios
Draft 0.9
(Release Candidate)
Paulo F. Vasconcellos
Jan-Fev/2009
2
Créditos & Débitos
Este livro é liberado sob a licença
Creative Commons :: Atribuição – Uso Não-Comercial –Compartilhamento pela mesma licença 2.5
(http://creativecommons.org/licenses/by-nc-sa/2.5/br/)
Você pode:
copiar, distribuir, exibir e executar a obra
criar obras derivadas
Sob as seguintes condições:
Atribuição. Você deve dar crédito ao autor original, da forma
especificada pelo autor ou licenciante.
Uso Não-Comercial. Você não pode utilizar esta obra com
finalidades comerciais.
Compartilhamento pela mesma Licença. Se você alterar, transformar, ou
criar outra obra com base nesta, você somente poderá distribuir a obra
resultante sob uma licença idêntica a esta.
•
Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da
licença desta obra.
•
Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha
permissão do autor.
•
Nada nesta licença impacta ou restringe os direitos morais do autor.
Qualquer direito de uso legítimo (ou "fair use") concedido por lei, ou qualquer outro direito
protegido pela legislação local, não são em hipótese alguma afetados pelo disposto acima.
Este é um sumário para leigos da Licença Jurídica (na íntegra).
( http://creativecommons.org/licenses/by-nc-sa/2.5/br/legalcode )
Outras informações Legais e sobre a Editora
3
4
Prefácio
Índice
5
6
Introdução
Capítulo 1
Introdução
7
8
Capítulo 1
9
Introdução
Parte I
O Analista de
Negócios
10
Capítulo 1
O Analista de Negócios
11
Capítulo 2
A função do analista de negócios (AN) existe há décadas. De maneira resumida, podemos dizer
que é aquele profissional responsável por interagir com clientes e usuários para entender seus
problemas e necessidades. Acontece que na maioria das vezes esse profissional acumula outra
função. E esta é a sua principal responsabilidade: gerenciar o projeto, desenhar a solução,
programar. Não raro, o processo de levantamento e entendimento dos requisitos de clientes e
usuários é visto assim mesmo, como uma atividade secundária de um projeto. Porque o
gerente, analista ou programador foi alocado ali para fazer outra coisa – para criar e entregar
uma solução.
Houve um tempo em que a formação de analistas de sistemas contemplava de maneira
satisfatória o estudo de métodos e práticas que auxiliavam no entendimento de problemas de
negócio. No entanto, tanto o mercado quanto a academia começaram a privilegiar o domínio
da solução, formando e contratando analistas-programadores. Não é arriscado dizer que a
crescente dinâmica do mundo dos negócios e um certo imediatismo criaram essa distorção
pouco lógica: equipes de tecnologia da informação (TI) estão repletas de gente preparada para o
domínio da solução – criar, modelar, programar, entregar – e carentes de profissionais que
realmente entendam o problema que precisa ser resolvido.
Não por acaso, o alinhamento estratégico de TI com o negócio figura há tempos em listas de
prioridades de diretores de informática, CIO's (Chief Information Office) e afins. Também não é
por acaso que problemas com requisitos, com a participação dos usuários e com mudanças
aparecem em todas as listas de problemas recorrentes em projetos mal sucedidos.
Calma: não estou afirmando que a presença de um AN por si só promove o tal alinhamento
estratégico e faz dos projetos de TI uma sequência de casos de sucesso. Depois dos gerentes de
projetos, arquitetos, desenvolvedores ágeis e afins, não pretendo nomear o próximo superherói da nossa área. Mas tentarei convencê-lo, neste capítulo e no restante deste livro, que o
AN pode ser sim um profissional muito importante em todas as organizações.
Comparada a outras áreas de conhecimento que tratam do desenvolvimento de sistemas, a
análise de negócios é uma das mais novas. Tão nova que podemos dizer que é uma área ainda
em fase de definição1. O que não nos impede de traçar algumas linhas básicas visando a
formação de analistas de negócios.
Antes, porém, precisamos entender quem é o analista de negócios. Quais devem ser suas
atribuições e quais habilidades ele precisa desenvolver. Esses são os temas deste primeiro
capítulo.
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 definição. Mas, de todas as suas disciplinas, a análise de negócios é
realmente a mais nova. E, talvez, a mais imatura.
12
Capítulo 2
A Análise de Negócios
A análise de negócios é uma macrodisciplina que tem como principal objetivo o entendimento
do negócio - seus problemas e oportunidades - e das necessidades, restrições e desejos de todas
as partes interessadas2. Ela ainda é mais conhecida através das duas disciplinas que lhe dão
forma: a Modelagem de Negócios e a Engenharia de Requisitos. Apesar de nascer e se
desenvolver como uma parte da engenharia de software, veremos adiante que a análise de
negócios não se limita a projetos para o desenvolvimento ou implantação de sistemas de
informação.
No contexto de um ou mais projetos, lançamos mão dos métodos e práticas que formam a
análise de negócios para dominarmos o problema. Ou seja, para efetivamente entendermos as
necessidades do negócio e de seus participantes.
A motivação pode ser um problema que requer alterações em processos, políticas e sistemas.
Mas também pode ser uma oportunidade de negócio, algo que igualmente gera requisitos de
mudanças em diversas partes de uma organização. De qualquer maneira estamos tratando aqui
de mudanças que, a princípio, serão implementadas na forma de projetos.
Que não são, necessariamente, projetos de sistemas. A solução para um problema de negócio
ou para aproveitamento de uma oportunidade pode se limitar ao redesenho de um processo,
reestruturação de recursos ou alteração de políticas que não geram impacto em sistemas
existentes nem demandam novos sistemas de informação. No entanto, dado o nível de
informatização de empresas dos mais diversos ramos de atividade e portes, é de se esperar que a
grande maioria das soluções encontradas gere mudanças em sistemas existentes ou requisitos
para novos sistemas.
Os negócios e seus processos estão sendo digitalizados. Por isso é difícil separar o analista de
negócios de um projeto de software. Por isso este livro trata quase que exclusivamente de
projetos para desenvolvimento ou implantação de sistemas de informação.
É comum a apresentação da análise de negócios como uma função estratégica3. Apesar do
trabalho ser predominantemente operacional. Ao participar ativamente do gerenciamento do
portfólio de projetos e do gerenciamento do relacionamento com as unidades de negócios4, o
AN assume relevância estratégica para a organização de TI. Como veremos no decorrer do
livro, mesmo em projetos isolados um bom AN não ignora a estratégia da empresa. Ele sabe
que um projeto, por menor que seja, tem ou deveria ter uma motivação estratégica. Ao cuidar
para que todos os requisitos contribuam para a realização daqueles objetivos maiores, ele está
na prática realizando o alinhamento estratégico de TI com o negócio.
2 Partes interessadas: tradução do termo stakeholder.
3 Por exemplo, um exagerado artigo da CIO Magazine recebeu o título “Analistas de Negócios valem Ouro”:
http://cio.uol.com.br/gestao/2008/05/19/analistas-de-negocio-valem-ouro/
4 Posição defendida por Richard Wyatt-Haines em “Align IT” (Wiley, 2007). Ele chega a indicar o uso do termo
Gerente de Relacionamentos ao invés de analista de negócios.
13
Já existe uma proposta de estrutura para o corpo de conhecimentos da análise de negócios, o
BABoK (Business Analysis Body of Knowledge), do IIBA (International Institute of Business Analysis).
Por vários motivos, explicados no tópico “IIBA & BABoK” abaixo, este livro não obedece essa
estrutura.
Este guia apresenta a análise de negócios em três partes:
•
Entendendo o Negócio: título que visa dar sentido a modelagem de negócios. Aqui o
AN conhecerá métodos e práticas para entender um negócio, suas motivações,
estrutura, processos e regras. Não é possível um correto entendimento dos requisitos
de usuários se não conhecemos seu negócio. E vice-versa.
•
Entendendo o Usuário: nome alternativo para engenharia de requisitos. O conjunto
de métodos e práticas que o AN pode utilizar para desenvolver e gerenciar requisitos –
as necessidades, desejos e restrições de usuários e do negócio.
•
Viabilizando o Projeto: o AN auxilia unidades de negócios e a área de TI na
viabilização de projetos. Esta terceira parte apresenta o que o AN deve aprender para
viabilizar, obter financiamento e vender um projeto.
14
Capítulo 2
IIBA & BABoK
Em 2003 foi fundado o IIBA em Toronto, Canadá. Seguindo os moldes do PMI, Project
Management Institute, promete fazer pela análise de negócios o que este fez pelo gerenciamento
de projetos: buscar o reconhecimento e divulgação da profissão e desenvolver e manter padrões
para a prática da análise de negócios e para a certificação de seus praticantes. No centro desses
objetivos está o principal produto do instituto: o corpo de conhecimentos da análise de
negócios, ou BABoK. Seu primeiro draft, estranhamente numerado como 1.4, foi publicado em
outubro de 2005. A versão disponível para download gratuito no momento da publicação deste
livro, ainda um draft, é a 1.65.
Produto do trabalho de dezenas de colaboradores, dentre eles renomados metodologistas como
Scott Ambler6, o BABoK é estruturado em 6 disciplinas, ou áreas de conhecimento (KA –
Knowledge Areas). Abaixo uma breve apresentação de cada uma delas, de acordo com
documento publicado pelo IIBA em 20077.
Figura 1 - As 6 disciplinas do BABoK
5 http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge
6 http://en.wikipedia.org/wiki/Scott_Ambler
7 “The Business Analysis Profession”, apresentação elaborada por Kevin Brennan, vice-presidente do IIBA,
em setembro de 2007.
15
Disciplina
Propósito
Planejamento da Análise de
Negócios
Determinar o que precisa ser feito.
Análise da Organização
Entender o problema de negócio e o escopo das possíveis soluções.
Elicitação
Encontrar as reais necessidades das partes interessadas.
Análise de Requisitos
Descrever características e qualidades da solução que deve satisfazer
as necessidades das partes interessadas.
Avaliação e Validação da
Solução
Determinar se a solução é correta para as partes interessadas.
Gerenciamento e
Garantir que as partes interessadas concordam com as necessidades
Comunicação dos Requisitos que serão satisfeitas.
A princípio não há nada de errado com a estrutura acima. O nome das disciplinas e respectivos
propósitos parecem cobrir tudo o que é necessário para uma eficaz análise de negócios. Porém,
uma análise mais detalhada do BABoK revela algumas surpresas. A principal delas: a
modelagem de negócios é sumariamente ignorada!
Revirei tanto a versão 1.6 quanto a versão 2.0, que foi temporariamente disponibilizada para
revisão pública, e pouquíssimo encontrei sobre modelagem de negócios. Na versão 1.6 o
termo aparece apenas como sendo uma das habilidades que um arquiteto de negócios deve
desenvolver.
Na versão 2.0 a modelagem de negócios surge durante a apresentação da técnica “modelagem
de processos” (6.15). O problema começa com o número aí: a técnica faz parte da disciplina
análise de requisitos!? O problema aumenta quando o BABoK registra que “BPMN é a
notação mais amplamente aceita para a modelagem de negócios”8. BPMN, de Business Process
Modeling Notation, atende, como o próprio nome indica, apenas a modelagem de processos de
negócios. A modelagem de negócios, como veremos na segunda parte do livro, é muito mais
que isso. Também é questionável a afirmação de que esta seria a notação “mais amplamente
aceita”. É a notação da moda, sem dúvida, mas será realmente a mais aceita? Infelizmente o
BABoK não indica fontes que sustentem a afirmação. Voltarei ao tema na segunda parte deste
livro, que trata da modelagem de negócios.
O que interessa aqui é notar que o BABoK parece cometer uma grave omissão. Por mais de um
ano tentei contatá-los, sem sucesso. Minha pergunta: se não é o AN quem faz a modelagem de
negócios, então quem é? É visível que boa parte do BABoK trata exclusivamente da engenharia
de requisitos. De maneira adequada, diga-se de passagem.
Mas é cambeta por desconsiderar técnicas e métodos que nos auxiliam no entendimento do
negócio. Desconheço fato mais contundente que prove o quanto a disciplina modelagem de
negócios é mal compreendida. Espero que a segunda parte deste livro comprove minhas
considerações. Antes precisamos conhecer melhor o tal Analista de Negócios.
8 BABoK version 2.0 – Draft for Public Review. IIBA (2008).
16
Capítulo 2
Definindo o Analista de Negócios
O AN é o profissional responsável pelo entendimento, avaliação e comunicação das
necessidades de um negócio e suas partes interessadas. Desta forma ele colabora com a
definição de uma solução para determinado problema de negócio.
TI e as áreas de negócios vivem em um conflito que parece eterno e tem uma origem muito
bem identificada: a dificuldade de comunicação. Seus vocabulários são muito diferentes. O
cenário piora quando TI desconhece ou não mostra comprometimento com os reais objetivos
do negócio.
De uns tempos para cá, algumas empresas forçaram a aproximação de diretores e gerentes de
TI com o negócio. Enquanto um relativo sucesso foi obtido no relacionamento entre
membros do alto escalão, na parte operacional os sérios problemas de comunicação
persistiram. Entra o analista de negócios.
Este profissional deve atuar como uma ponte entre o negócio e TI. Dominando os dois
vocabulários, deve eliminar, principalmente, os sérios problemas de comunicação. Mas esta
definição parece fazer do AN um tradutor ou intérprete, o que não é verdade.
Voltemos à definição do primeiro parágrafo acima. Temos três verbos ali: Entender, Avaliar e
Comunicar. É hora de detalhar o significado de cada um deles:
•
Entender: o AN entende o negócio – seus problemas e oportunidades, e também as
necessidades e restrições de todas as partes interessadas, o que inclui toda a equipe
técnica, além de clientes, patrocinadores e usuários. Essa compreensão é ampla, o que
confere ao AN uma perspectiva única. Enquanto áreas de negócios e TI observam e
cuidam de seus respectivos lados e interesses, o AN vislumbra os dois lados da moeda –
que é única.
•
Avaliar: sendo assim o AN tem condições de efetuar uma isenta e clara avaliação dos
problemas e / ou oportunidades e das soluções apresentadas. Sua avaliação, que sempre
é executada com representantes dos dois lados, deve guiar a seleção da melhor solução,
ou da mais viável.
•
Comunicar: durante todo o processo de entendimento e avaliação que, diga-se de
passagem, podem ter praticamente a mesma duração do projeto, o AN se comunica de
forma constante com todas as partes interessadas. Em dado momento, questionando e
estudando. Em outros, avaliando e negociando. O AN é uma espécie de hub, um
concentrador de comunicações. O risco de virar um gargalo para os projetos é grande.
Mas este é assunto para outro momento.
17
Uma Profissão, Vários Nomes
Por antiga que seja a demanda, a profissão AN é relativamente nova. Por isso ainda vemos
vários nomes sendo utilizados para referenciar o mesmo profissional. O nome também pode
indicar algum tipo de especialização. Mas, de maneira geral, todos podem ser chamados de
Analistas de Negócios. A lista abaixo apresenta alguns dos termos mais comuns utilizados
atualmente:
•
Analista de Requisitos: como o próprio nome indica, se limita ao levantamento,
desenvolvimento e, em alguns casos, ao gerenciamento de requisitos.
•
Analista de Processos: função que pega carona na “onda” BPM (Business Process
Management). Especializa-se na análise e desenho de processos de negócios.
•
Multiplicadores: termo que indica claramente a responsabilidade de aprender
(sistemas, com TI) e repassar o conhecimento, multiplicá-lo entre as áreas usuárias. A
via de retorno, do negócio para TI, existe mas parece ser secundária.
•
Product Owner: ou Dono do Produto, termo cunhado no método ágil para
gerenciamento de projetos Scrum. É o profissional que define requisitos e prioridades e
gerencia o Product Backlog, ou seja, a relação de tudo o que precisa ser entregue pelo
projeto.
Outros termos, relativamente estranhos, são utilizados em algumas empresas brasileiras para
identificar o profissional AN ou seu departamento. “Ponto Focal” e “Departamento de
Tecnologia do Negócio” são 2 deles. No primeiro caso vê-se nitidamente a tentativa de
posicionar o AN como a ligação entre usuários e a área de TI. De certa forma aproxima-se com
a sugestão de Richard Wyatt-Haines citada anteriormente: Gerentes de Relacionamento, ao
invés de analistas de negócios.
O RUP (Rational Unified Process), famoso por sugerir algumas dezenas de papéis em equipes de
desenvolvimento, tem vários nomes para o AN: Business-Process Analyst, Business Designer e UseCase Specifier. Mas ele não lista o termo Analista de Negócios9.
No entanto, com a mídia e principalmente o IIBA promovendo o nome “Analista de
Negócios”, é fácil supor que este será o termo mais comumente aceito. Mesmo que suas
responsabilidades e habilidades permaneçam nebulosas por um certo tempo.
Independente do nome, afinal, como se dá a formação de analistas de negócios, ou de
requisitos, processos ...?
9 “The Rational Unified Process – An Introduction” (Second Edition). Philippe Kruchten. Addison-Wesley (2000).
18
Capítulo 2
Formando Analistas de Negócios
Ainda não existem cursos técnicos ou de graduação que tratem exclusivamente da formação de
analistas de negócios. A exemplo do que ocorre com gerentes de projetos, talvez esses cursos
nem venham a existir. Ou melhor, existirão na forma de cursos de extensão, pós-graduação ou
especialização. Tendo em vista os cursos regulares oferecidos atualmente, aquele cujo
currículo mais se aproxima da profissão é conhecido no Brasil como “Sistemas de Informação”.
No entanto, como colocado anteriormente, os currículos vigentes dão enorme ênfase ao
domínio da solução: estudantes aprendem lógica e programação, modelagem de sistemas e até
noções de gerenciamento de projetos. Mas pouco ou nada veem sobre o entendimento do
negócio, clientes e usuários – ou seja, o conhecimento de métodos e práticas que levam ao
domínio do problema.
Nem sempre foi assim. Cursos e publicações voltadas para os analistas de sistemas, em um
passado não muito remoto, se preocupavam mais com a definição do problema a ser resolvido.
Não parece ser coincidência que tais temas tenham evaporado tão logo o mercado sinalizou
com forte demanda por “analistas-programadores”. Ao interpretar etapas da análise de sistemas
como atividades que agregavam pouco ou nenhum valor aos projetos de desenvolvimento, a
solução descoberta foi a simples eliminação dessas “fases”. Não são raros os depoimentos de
analistas que, tão logo alocados em um projeto, devem “gerar código”. Por isso não me
surpreendo quando pesquisas indicam que cerca de 70% de nossos projetos falham – atrasam,
custam mais ou simplesmente são cancelados. Surpresa, dado o cenário atual, seriam 70% de
projetos de sucesso. Mas... retornemos ao tema central deste tópico.
Por sua atuação muito próxima ou mesmo subordinada a área de TI, espera-se que o AN tenha
uma formação técnica. Noções básicas de lógica, modelagem de dados e sistemas e até mesmo
de alguma linguagem de programação dão considerável estofo para um AN. Mas isso não
deveria ser visto como um pré-requisito. E, felizmente, o mercado parece estar vendo desta
maneira. Empresas estão empregando administradores de empresas, contadores e até
publicitários como analistas de negócios. Se a ausência de um background técnico é sentida, por
outro lado esses profissionais levam para as empresas pontos de vista e conhecimentos novos,
diferentes daqueles que predominam em uma organização de TI.
No final das contas, é tudo uma questão de equilíbrio. Aqueles com formação técnica deverão
desenvolver conhecimentos sobre administração e contabilidade, por exemplo. Enquanto isso,
os demais AN's deverão conhecer um pouco mais sobre sistemas, arquitetura de aplicações etc.
Este livro recomenda que um AN nunca atue sozinho, em nenhuma situação. Ele sempre é
acompanhado de outro analista. Sendo assim, é fácil compor uma dupla com um profissional
com formação de TI e outro de outra área qualquer. Além da troca de conhecimentos, do
aprendizado conjunto, a dupla oferece ao projeto perspectivas totalmente complementares.
Mas, afinal, qual é a formação de um analista de negócios? Quais habilidades ele deve
desenvolver?
19
Habilidades
Não está no escopo deste livro o estudo das habilidades sociais que devem ser desenvolvidas
por um AN. Apesar de não 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 não hesitarei em apresentar alguma dica, quando considerá-la realmente
válida. Mas, definitivamente, não sei falar muito sobre liderança, negociação, postura,
meditação e levitação. 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 técnicas, estas sim o foco deste trabalho.
Habilidades Sociais
Em inglês elas são chamadas de soft skills. É reconhecido que sua transferência, 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 intransponíveis. Tomemos como exemplo o ato de falar em
público. 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 público em diversas ocasiões, facilitando sessões de workshop ou
apresentando alternativas de soluções. Já vimos, a comunicação é uma das principais
responsabilidades de um AN. A facilidade de comunicação, em qualquer meio, é uma das
principais habilidades soft que ele deve desenvolver.
O que podemos afirmar é que, mais que treinamentos e miraculosas técnicas para
“destravamento total”, é a prática constante que lapida nossas habilidades sociais. A menos que
você tenha algum trauma (trava) realmente sério, considere a prática frequente e as críticas de
seus colegas como suas principais fontes de aprendizado de habilidades soft.
A lista abaixo destaca as principais habilidades sociais que um AN deve desenvolver:
•
Aprendizado: um bom AN aprende rápido. E aprende direito. Sabe identificar as
fontes mais ricas e eficazes e extrair delas todo conhecimento necessário. O AN tem o
hábito de ler e de estudar. Quando confrontado com um novo negócio ou cenário, não
hesita em disparar um processo de pesquisa. Em tempos de Internet e principalmente
de Google, o bom AN sabe que não existem muitos impedimentos ao seu estudo.
O AN não tem medo de perguntar. E sabe que nada é óbvio quando se trata de
negócios e sistemas de informação. Entende que pode ser confundido com um chato de
vez em quando, mas que isso faz parte de seu trabalho. E faz perguntas e mais
perguntas, como uma criança de 3 anos de idade.
O AN também sabe que o conhecimento tácito, aquele que está na cabeça das pessoas,
pode ser só uma parte do que ele precisa. Por isso ele também aprende ao ler
documentos, diagramas, sistemas e outros diversos tipos de conhecimento explícito.
•
Comunicação: o AN é um exímio comunicador. Conversando, escrevendo,
apresentando e facilitando eventos – não importa o meio ou o público. Se o principal
problema que o AN veio resolver é de comunicação entre áreas de negócios e TI, é
simplesmente o cúmulo do absurdo imaginar um AN que não saiba se comunicar
20
Capítulo 2
muito bem.
O que não pode significar que aquele tímido ou aquele relaxado não podem se
transformar em excelentes AN's. Todo mundo, em todas as profissões, um dia teve que
começar. Quando bem guiados, tímidos, relaxados e afins saberão driblar suas
limitações. Um aspecto particularmente importante é a comunicação do AN com a
equipe técnica. Ele precisará ensinar alguns conceitos e termos de negócio para
coordenadores e desenvolvedores. Saber ensinar também deve fazer parte do currículo
do analista de negócios.
•
Negociação: não basta se comunicar bem, o AN deve negociar bem. Em diversos
momentos de um projeto isso é quase tudo o que ele estará fazendo: negociando o
escopo com usuários e desenvolvedores, combinando prazos, avaliando mudanças.
Como bom negociador, o AN elimina ou reduz atritos e ruídos.
Sua capacidade de negociação pode ser especialmente exigida quando a viabilização de
um projeto estiver sob sua responsabilidade. A obtenção de apoio da alta direção, os
acertos com o patrocinador, a revisão de prioridades com a organização de TI – tudo
isso é negociação.
•
Pensamento Sistêmico: habilidade que em algumas rodas é chamada de “(ante)visão
do jogador de xadrez” e em outras de “sexto sentido”. Falando sério, esta é a famosa
“Quinta Disciplina” de Peter Senge10, que para o AN tem dois significados
fundamentais: i) ver inter-relacionamentos, em vez de cadeias lineares de causa-efeito; e
ii) ver os processos de mudança, em vez de simples fotos instantâneas.
O AN entende que durante um projeto o negócio continua vivo e que, desta forma,
segue sujeito e gerador dos mais diversos tipos de mudanças. E entende que o próprio
projeto é uma mudança, o que o leva a desenvolver uma ampla visão de todos os
impactos que podem ser gerados por ele.
•
Capacidade de Síntese: o AN deve ser capaz de, a partir de informações diferentes
oriundas dos mais diversos lugares, gerar um todo que seja coerente. Ele sabe destacar
aquilo que é realmente fundamental em determinado contexto e, o mais importante,
compilar dados e informações de forma a gerar um conjunto íntegro, alinhado e
factível.
Quando falamos de modelagem de negócio estamos falando de simplificação. O bom
AN sabe que um bom modelo de negócio se limita aquilo que é realmente necessário
para um projeto. Já na engenharia de requisitos, no entendimento dos usuários, o AN
busca a uniformização e organização de todos os dados e informações desenvolvidas. É
assim que ele demonstra sua capacidade de síntese.
•
Visão Crítica e Criativa: o bom AN sabe que não pode se limitar aos requisitos
apresentados pelos usuários. Isso porque ele entende que os requisitos, logo que
surgem, carecem de desenvolvimento, de amadurecimento. Por isso apresenta críticas e
novas sugestões, debatendo-as com usuários e desenvolvedores.
10 “A Quinta Disciplina”, Peter M. Senge. Editora Best Seller (2000).
21
Habilidades Técnicas
Também conhecidas como hard skills, em inglês. É o tipo de conhecimento mais fácil de ser
transferido, tanto em processos de socialização (treinamento, por exemplo), quanto em
processos de internalização (a partir de livros, apostilas e afins). No decorrer deste livro
apresentarei diversas técnicas, ferramentas e métodos que devem formar a base de habilidades
técnicas de um analista de negócios. Neste momento me limitarei a listar e descrever
brevemente as principais habilidades hard que um AN deve desenvolver. Vamos a elas:
•
Modelagem: é a capacidade de gerar abstrações de algo que existe no mundo real.
Uma habilidade que também pode ser apresentada como “Pensamento Visual11”. Do
AN será cobrado, principalmente, a capacidade de gerar modelos de negócios. Mas é
importante que ele também saiba gerar outros modelos. Abaixo uma lista com os mais
importantes:
•
Modelagem de Negócios: representação dos aspectos mais importantes de um
negócio em determinado contexto, determinado projeto. Aqui o AN entende que
“menos é mais”. Negócios são complexos por natureza. Um modelo de negócio não
tenta reproduzir todos os detalhes, pelo contrário. Ele se limita ao que é
estritamente fundamental para entender o negócio e comunicar tal entendimento.
Como a modelagem de negócios é muito mal compreendida (e mal falada), vale a
pena adiantar aqui que Balanced Scorecards e Mapas Estratégicos, por exemplo,
podem fazer parte de um modelo de negócio.
•
Modelagem de Dados: dados e informações são recursos de uma empresa.
Consequentemente, podem fazer parte de um modelo de negócios. Mas aqui o AN
entende que existem regras e padrões específicos para a modelagem de dados,
baseados principalmente nas teorias da modelagem Entidade-Relacionamento e
modelagem multidimensional.
•
Modelagem de Sistemas: claro, não é muito recomendado que um AN seja
convocado para desenvolver um modelo de sistema. Mas saber ler um modelo de
sistema pode ser necessário, particularmente nas interações com a equipe de
desenvolvimento. Noções básicas de modelagem, particularmente aquela orientada
a objetos, são necessárias. O conhecimento do padrão de facto para modelagem de
sistemas, a UML (Unified Modeling Language), também. Cabe adiantar que sugiro a
utilização desta mesma linguagem para a geração de vários diagramas que podem
compor o modelo de negócios.
•
Prototipação: porque protótipos são modelos. O AN deve conseguir gerar
desenhos que representem idéias. Protótipos de interfaces talvez sejam os mais
exigidos, mas não são os únicos. O desenho de Storyboards que representem
navegações entre telas ou a simulação de um trecho de um processo de negócio
também é uma habilidade que o AN deve assimilar.
11 O termo Pensamento Visual é sugerido, por exemplo, por Dan Roam no livro “The Back of the Napkin –
Solving Problems and Selling Ideas with Pictures”, Portfolio (2008).
22
Capítulo 2
•
•
Engenharia de Requisitos: tentei encontrar outro nome para esta habilidade mas não
aparaceu nenhum melhor que este. Engenharia de Requisitos compreende um vasto
conjunto de habilidades hard que um AN deve dominar. As principais são:
•
Técnicas para o Desenvolvimento de Requisitos: entrevistas, sessões JAD
(Joint Application Development), workshops, engenharia reversa, observação ativa e
passiva, pesquisas e outras. O AN tem a sua disposição um leque de alternativas
para efetivamente entender o usuário, suas necessidades e restrições. Cada projeto
ou usuário pode requerer o uso de uma ou outra técnica. É importante que o AN
demonstre versatilidade e agilidade para escolher as técnicas mais apropriadas.
•
Especificação e Estruturação da “Voz do Usuário”12: o usuário fala muita
coisa, pede outro tanto. Em conversas ou documentos ele mistura requisitos, regras
de negócios, definições de dados, requisitos de interface e mais um sem número de
informações. Ele não precisa saber distinguir uma regra de um requisito, por
exemplo. Essa responsabilidade é exclusiva do AN. Saber organizar a “voz do
usuário” é uma das habilidades mais caras que um analista deve apresentar.
Diretamente relacionada com uma habilidade soft citada anteriormente, a capacidade
de síntese. Aqui falamos exclusivamente da porção hard deste trabalho, que
demanda o domínio de técnicas e ferramentas que viabilizam a especificação e
estruturação de requisitos e demais informações aprendidas.
•
Redação de Casos de Uso: um documento criado especificamente para facilitar a
descoberta e descrição dos requisitos funcionais de um sistema. Durante o
desenvolvimento deste trabalho fui surpreendido com o tamanho da confusão que
existe em torno desta técnica que, a princípio, deveria ser muito simples. Casos de
uso foram inventados por Ivar Jacobson13 no final da década de 1960, para entender
melhor os requisitos de um sistema de telecomunicações. A técnica ganhou público
quando foi incorporada à linguagem de modelagem UML. Infelizmente, ganhou
público e um show de desinformação.
•
Preparação e Execução de Testes: porque o AN é a última pessoa que testa uma
aplicação antes do usuário final. A preparação acontece quase que simultaneamente
ao registro dos requisitos, através da redação de casos de testes, por exemplo. Aqui o
AN fixa todos os critérios de aceite, indicando para a equipe de desenvolvimento
todos os testes que executará quando receber a aplicação. São testes do tipo “caixapreta”, ou seja, visam exclusivamente validar a conformidade da aplicação em
relação aos requisitos apresentados.
Viabilização da Solução: além das habilidades sociais necessárias para a viabilização
de um projeto, como comunicação e negociação por exemplo, o AN também deve
dominar habilidades técnicas com tal fim. Merecem destaque: redação de documentos
de visão ou propostas técnicas; elaboração de apresentações; facilitação de workshops;
matemática financeira; e gerenciamento de portfólios.
12 Termo utilizado originalmente por Karl Wiegers em “Software Requirements”, Microsoft Press (1999).
13 http://en.wikipedia.org/wiki/Ivar_Jacobson
23
Especialização
Ao dominar as habilidades sociais e técnicas listadas acima o AN está pronto para atuar em
diversos tipos de projetos para negócios de qualquer porte ou natureza. Ele é um AN
“genérico”. Ou “horizontal”, para usar um termo que pareça menos pejorativo. Se ele atua em
uma empresa que presta serviços de desenvolvimento ou consultoria, atendendo diversos tipos
de clientes, é exatamente isso que será esperado dele: que ele tenha condições de atuar em
qualquer tipo de organização.
No entanto, será exigido que ele seja ainda mais ágil no aprendizado, aquela primeira
habilidade social apresentada. É recomendável que ele faça um tipo de imersão na história de
um cliente e na situação 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 é factível supor que, com o tempo, o AN “horizontal” vai se especializar em alguns
tipos de negócios. Dois ou três projetos dentro de uma mesma área, não necessariamente para
um mesmo cliente, podem ser suficientes para gerar um conhecimento muito bom sobre
aquela atividade. Conhecimento que a empresa prestadora de serviços, se atenta, apresentará
como um diferencial competitivo.
Situação diferente é daquele AN que atua apenas em uma empresa. A necessidade de
especialização naquele ramo de atividade é óbvia. Desta forma temos um analista mais
“vertical”, especialista em determinado ecossistema de negócios14.
Mais do que uma habilidade que se aprende na escola, a especialização em determinado ramo
de atividades é fruto da experiência, de considerável tempo de estrada. Ela pode ser
desenvolvida de maneira intencional, planejada. Pelo AN ou pela empresa para a qual trabalha.
Mas também pode ser consequência de uma série não consecutiva de projetos. Esta foi a minha
experiência e de alguns AN's que trabalharam comigo. Em determinado momento
percebemos, por exemplo, que poderíamos explorar melhor a área de seguros porque o
conhecimento acumulado em projetos anteriores se configurava uma interessante vantagem
competitiva.
Outro tipo de especialização possível é por tipo de solução. 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 são
conhecidos como Consultores Funcionais.
O mais importante para o AN é entender que antes de qualquer tipo de especialização ele deve
buscar o domínio do básico, daquela lista de habilidades sociais e técnicas apresentada acima.
14 Ecossistema significa tudo e todos que giram em torno e dentro de um negócio, seus clientes, fornecedores,
parceiros comerciais, concorrentes, legislação e marcos regulatórios, produtos e serviços, além dos sistemas.
24
Capítulo 2
Analistas de Negócios – Por que agora?
A questão acima é mais fácil de responder do que “por que só agora?”. Guardiães de um
estranho status quo gostam de dizer que a crescente demanda por analistas de negócios é só uma
moda. Talvez seja mesmo. Talvez, a exemplo de várias outras modas que caracterizam o mundo
de TI e dos negócios, esse movimento todo não dure mais do que 3 ou 4 anos. Mas surgirá
então outro termo – arquiteto de negócios, projetista de negócios, analista de organização &
métodos (ops15) – e essa “nova” profissão deverá dominar praticamente tudo o que um AN
aprende hoje. Em nossa área é assim mesmo: vão-se os nomes, ficam os conceitos e,
principalmente, as necessidades.
Vamos aos fatos:
1. Negócio e TI nunca tiveram um relacionamento muito amistoso. Não por acaso o tal
“alinhamento estratégico” vive no topo da lista de prioridades de 9 entre 10 gestores de
TI.
2. Cerca de 70% dos nossos projetos atrasam e / ou estouram orçamentos e / ou são
cancelados. Dentre as causas mais comuns sempre aparecem: i) problemas com o
entendimento dos requisitos; ii) a participação dos usuários; e iii) mudanças de escopo.
3. Desenvolvedores e coordenadores de projetos não estão sendo treinados para entender
o negócio e os usuários.
4. O mundo dos negócios nunca foi tão volátil e dinâmico, o que aumenta
consideravelmente os riscos de TI e particularmente de seus projetos.
Alinhar, acompanhar o ritmo do negócio, muitas vezes parece ser o mesmo que pedir
para que você, com um velocípede, tente acompanhar Massa em sua Ferrari.
5. O conhecimento sobre o negócio está espalhado entre diversas pessoas, lugares e
sistemas. Dependendo da empresa, simplesmente ninguém tem uma visão do todo. A
concorrência entre silos pelos caros recursos apenas complica ainda mais o panorama.
Por tudo isso e mais um pouco, a figura do AN surgiu e vem ganhando relevância. É claro que
o analista de negócios não é o único recurso à disposição das organizações de TI para a busca
do alinhamento estratégico. Mas é, sem sombra de dúvidas, um dos mais importantes. É aquele
que pode demonstrar no dia-a-dia o comprometimento com essa busca, através do
relacionamento com as áreas de negócios e da entrega de bons projetos.
Ou seja, ninguém deveria ter dificuldades para justificar a contratação ou alocação de AN's em
uma equipe. Então, a pergunta que fica é: por que só agora? Sinceramente, não sei dizer.
15 Gosto de dizer que os analistas de O&M são, de certa maneira, os bisavós dos analistas de negócios. Falo um
pouco mais sobre isso no quadro “Darwin e os Analistas”.
25
Darwin e os Analistas
Darwin ficou famoso por descobrir e dizer que as espécies, todas as espécies vivas da face da
terra, evoluem. Ele contou que não são os mais fortes, os mais inteligentes ou aqueles que
gritam mais alto que sobrevivem – são aqueles que melhor se adaptam às mudanças.
Todo mundo já gastou essa teoria fazendo analogias com o universo dos negócios e de TI.
Tirarei minha casquinha.
Era uma vez... uma empresa, lá nos anos 50, animadíssima com as possibilidades oferecidas
por um novíssimo fruto da genialidade humana, o tal cérebro eletrônico. Contabilidade, folha
de pagamentos, cálculos e mais cálculos. As possibilidades eram lindas e maravilhosas. Mas,
“êita engenhoca difícil de operar!”.
Uma rebelião de empresas usuárias quase decretou a morte da informática ainda em seus
primeiros anos de vida. Quase, porque um sábio vendedor da IBM debelou o conflito e salvou
nossa área16. Coincidência ou não, nasciam ali também os primeiros analistas.
As áreas de negócios, guiadas por manuais tayloristas17, também criaram seus analistas: os
Analistas de Organização & Métodos. 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 bagunça então conhecida por CPD (Centro de Processamento
de Dados). Aliás, TI não se chamava TI ainda. Era só um CPD. Uma caixa preta com um
monte de gente esquisita falando línguas esquisitas. COBOL? Fortran?
O tempo passou, Jobs e Gates inventaram a microinformática e alguns anônimos (intencionais
ou não) inventaram os Analistas de Sistemas. Gente que tinha que estudar o problema de
negócio e solucioná-lo através de sistemas de informação. Novo conflito. Por um breve
período os analistas de O&M foram renomeados. Viraram Analistas de Organização, Métodos
& Sistemas. Não adiantou. Eles seguiram chatos, imutáveis e com um “e” comercial no nome.
Não se adaptaram. Não estudaram sistemas. Não entenderam o Visicalc. Foram extintos.
Vitoriosos, os Analistas de Sistemas começaram sua saga. Dramática saga. Breve saga. Negócios
começaram a entender que os computadores podiam sim fazer a diferença. O impacto da
Internet então, nem me diga. E tudo é para ontem, anteontem... Buscando adaptação, os
analistas ganharam um sobrenome: programadores. Daí para o mal interpretado mundo Agile,
onde muita gente prega zero-documentação, zero-modelo, foi um pulinho. Alinhamento?
Coloca o usuário sentado ao lado do programador que a coisa sai! Programador?
Sim, o Analista de Sistemas se foi. Aconteceu tão rápido que nem enterro teve.
Eis que surge, sem convite, o tal analista de negócios. Incorrigível, o mundo de TI já trata de
fazer suas adaptações: já tem gente contratando AN com experiência em Java!
16 Está aqui um trecho que não é só ficção e palpite não. Esta história 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
Capítulo 2
É do Negócio ou de TI?
27
Capítulo 3
Que dilema! Se o analista de negócios atua como um tipo de ponte entre as áreas de negócio e
de tecnologia, a quem ele deve ser subordinado? Este capítulo não estava previsto no plano
original do livro. Mas se tornou necessário depois de minhas andanças e conversas. Não há
uma resposta clara para a questão e, provavelmente, nunca haverá um padrão.
Originalmente o AN brotou nas dependências 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 organização de TI com as áreas de negócios.
Por outro lado, existem empresas que veem o AN como um SME (Subject Matter Expert), um
especialista em determinado tema do negócio. E que, como tal, deve responder diretamente
para a respectiva área de negócio.
Há também a terceira via, que cria um departamento exclusivo para a análise de negócios. Um
departamento totalmente independente de TI e das áreas usuárias. Em algumas empresas os
AN's estão sendo alocados no departamento de marketing!
Neste capítulo serão apresentadas as três alternativas, os prós e contras de cada uma delas.
Parece haver um desenho mais adequado para cada tipo de negócio. Mas, ao invés de
apresentar conclusões, me limito a oferecer subsídios para que você decida qual o modelo mais
adequado para sua situação. Claro que essa discussão não faz muito sentido se sua empresa
presta serviços de consultoria e / ou desenvolvimento. Mesmo assim, evite a tentação de pular
diretamente para o próximo capítulo. Explico: saber como seus clientes podem estruturar essa
função pode ser muito importante. Você vai se relacionar com os AN's de seus clientes. Além
disso, atenção para o parágrafo abaixo.
Outro tópico abordado aqui é a formação de equipes de projetos. Independente de qual seja
seu departamento, o AN deve ser alocado em projetos. Qual a melhor estrutura para acomodálo? Como minimizar as possibilidades de conflito entre ele e a equipe técnica? Afinal, como se
dá o relacionamento entre desenvolvedores, arquitetos, coordenadores e o analista de negócios?
No decorrer desse papo apresentarei algumas estruturas alternativas, que visam principalmente
ao aprendizado, a troca de experiências entre os analistas. Comunidades de prática, centros de
excelência e escritórios de análise de negócios serão apresentados e avaliados.
Pois é: como este capítulo poderia não existir? Tsc, tsc...
28
Capítulo 3
O Analista de Negócios é de TI
A princípio 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 informação. É provável que ele não seja especializado em
nenhuma área de negócio específica, como vendas, produção ou finanças. Pelo contrário, a
organização 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 conheça muito bem o negócio da empresa.
Este desenho apresenta as seguintes vantagens:
•
Menor probabilidade de conflitos com desenvolvedores e demais integrantes da equipe
técnica. Isso porque há uma convivência frequente e todos trabalham de acordo com
uma mesma filosofia – compartilham valores, padrões, métodos e práticas.
•
Por ser um desenho centralizador, TI tem mais poder de decisão sobre prioridades de
alocação dos AN's.
•
É mais fácil garantir que a metodologia ou processo de desenvolvimento está sendo
obedecido.
E desvantagens:
•
A centralização também pode ser uma desvantagem. Dependendo da proporção entre o
número de solicitações e a quantidade de AN's disponíveis, podemos ter aqui um
belíssimo gargalo. Além disso, oportunidades de negócio podem ser negligenciadas, as
prioridades podem estar equivocadas.
•
Isso também pode gerar um volume maior de atritos com as áreas de negócio. Conflitos
que, não raro, devem ser intermediados por alguém que está acima na hierarquia da
empresa.
•
Como o AN de uma estrutura centralizada é naturalmente “genérico”, há uma certa
lentidão quando ele tem que aprender uma atividade ou situação de negócio inédita.
Este problema é consideravelmente reduzido quando a rotatividade de profissionais é
baixa.
Uma grande empresa nacional de telecomunicações utiliza este desenho. E chama a equipe de
AN's de “Ponto Focal”. Dado o porte da empresa, os analistas são divididos por áreas de
negócio ou tipos de processos: Produtos, Atendimento e Processos de Apoio são alguns
exemplos. O quadro “No Meio do Tiroteio” detalha um pouco mais esse caso.
Quando o analista de negócios está subordinado à área de TI o processo de trabalho ocorre
mais ou menos assim: um departamento ou seção manifesta a necessidade de uma nova
aplicação. Esta solicitação entra na lista de pendências (backlog) da área de TI. O quanto antes
um AN deve ser destacado para entender um pouco mais o problema em questão. Só assim a
solicitação pode ser priorizada – posicionada no backlog. A priorização é negociada com a área
1 No final deste capítulo falo sobre “O Tamanho da Equipe”.
29
solicitante. Todo mundo quer tudo para ontem, e TI deve ter uma boa justificativa caso aquele
pedido não mereça estar no topo de sua lista de afazeres.
A sequência acima é ridiculamente simplista e esconde uma série de variáveis. Exploremos um
pouco mais o tema.
Quando chega uma nova solicitação, nem sempre é possível dizer se se trata de uma nova
aplicação ou de uma alteração em um sistema existente. O porte da alteração também pode ser
uma incógnita. Como o usuário nem sempre tem essa informação, é de se esperar que
solicitações assim apareçam em outro canal: no help-desk, por exemplo. Quem gosta de dizer
que “atendimento nível 1 é coisa de analista de suporte júnior” deveria parar e pensar um
pouquinho. Aqui nascem alguns sérios conflitos entre áreas de negócio e TI. Como o “analista
de suporte júnior” pode ter condições de dizer se aquela solicitação é pequena ou grande, se
gerará demanda por manutenção em um sistema legado ou um novo projeto?
Confrontadas com a situação descrita acima, algumas empresas tomaram uma decisão bastante
perdulária: alocam AN's para cuidar até de pequenas demandas. Justificam o desenho
apresentando uma solução para outro problema: a padronização das solicitações. A coisa é tão
maluca em algumas empresas, que o mesmo padrão utilizado para novos sistemas deve ser
obedecido em pequenas solicitações de manutenção. Imagine o processo: um AN tentando
escrever casos de uso, protótipos e uma detalhada especificação, repleta de justificativas, só
porque o usuário pediu o acréscimo de um novo campo numa tela qualquer. Pode parecer
absurdo, mas acontece.
A demanda por manutenção e correções de sistemas legados é imensa em um grande número
de empresas, dos mais diversos portes. É, no popular, um indigesto abacaxi que as organizações
de TI engolem diariamente. Longe de mim apresentar alguma sugestão para adoçar um
pouquinho o abacaxi2. Me preocupa aqui que o AN, uma posição cara e rara, seja
desperdiçado. Usuários 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 negócio e dos usuários. Enfim, quando a demanda
realmente tiver uma maior importância para o negócio.
2 Hmm.. não me segurei. Então vão não uma, mas duas sugestões: i) SOA (Arquitetura Orientada a Serviços);
e / ou, ii) uma velha dica do Gartner: aposente 2 ou 3 sistemas legados por ano, começando por aqueles que
não passam em qualquer avaliação básica de custos x benefícios.
30
Capítulo 3
No Meio do Tiroteio
A empresa, fruto de algumas fusões, tem um péssimo histórico de relacionamento entre áreas
de negócio e o departamento de TI. Em determinado momento a coisa ficou tão feia que
usuários passaram a estudar sistemas. Não as funcionalidades oferecidas, mas o interior das
aplicações. Tanto que alguns aprenderam a linguagem SQL! Não sei dizer se alguns se
arriscaram a colocar a mão na massa, mas o fato é que algumas de suas solicitações já
apresentavam a solução pronta – o código que deveria ser implementado. Em outras situações
eles descreviam campos e tabelas que deveriam ser alterados.
A empresa mudou, e duas áreas foram criadas para receber e filtrar todas as solicitações
recebidas. A primeira cuida do entendimento do problema e da especificação deste de forma
padronizada. A segunda, um centro de soluções, cuida do relacionamento com os
fornecedores. Sim, praticamente todas as atividades de manutenção e desenvolvimento de
sistemas foram terceirizadas.
O problema é que os traumas dos usuários permanecem. E os maus costumes idem. O
departamento que foi criado para o entendimento do problema é visto como um empecilho.
As atividades desta área são consideradas supérfluas por muitos usuários. Sendo assim, alguns
deles simplesmente passam por cima dos AN's, negociando suas solicitações diretamente com
o centro de soluções. A primeira área só é avisada quando sua assinatura é necessária. Ou seja,
pura burocracia.
Sob o ponto de vista de alguns usuários, tudo é pequeno, tudo é “facinho facinho”. A coisa
piora muito quando o usuário se esquece que a empresa não se limita ao seu departamento,
que podem existir outras prioridades. Então ele “fura a fila”, sem noção das consequências. É
curiosa a grande criatividade dos usuários. A empresa estipulou que existem dois tipos de
solicitações: as pequenas e as grandes. Estas devem ser tratadas como projetos. Os usuários
sabem que projetos seguem um ritual diferente, mais demorado. Então eles fatiam suas
solicitações e as apresentam “pequenas demandas” em intervalos regulares de tempo. Demora
até o departamento de TI perceber que está sendo ludibriado.
Talvez o problema não fosse crítico se a qualidade dos serviços prestados pelas fábricas não
fosse tão ruim. Mas o fato é que muitas aplicações e até pequenas alterações são entregues com
muitos erros. Não é necessária muita esperteza para perceber que muitos desses bugs são frutos
exclusivos dos atalhos que foram tomados.
Mas, como eu disse, o serviço das fábricas de software é ruim. Então mesmo aquelas
solicitações que seguem sem desvios o manual, sofrem com erros e funcionalidades diferentes
daquelas esperadas pelos usuários. O estranho é que as empresas, esta em particular, acreditam
que a culpa é delas – que o problema está na qualidade da especificação que é entregue para as
fábricas. E passam a exigir especificações ainda mais detalhadas, e colocam mais e mais pontos
de checagem. Consequência: o processo se torna ainda mais lento, os usuários mais
insatisfeitos, os AN's mais criticados... nessa bagunça toda, nesse ciclo vicioso, só um lado sai
ganhando: as fábricas de software.
31
O AN é do Negócio
E cada área usuária possui o seu. É indiscutível 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 localização 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 atribuição. O que
percebi em algumas empresas é que usuários com mais tempo de casa desempenham a função
de AN's em projetos. São temporariamente alocados para representar o departamento em um
empreendimento. Seus afazeres cotidianos são assumidos por outro colaborador até o término
do projeto.
Vantagens deste modelo:
•
O domínio do negócio, do problema, é total. Ou, colocando de outra forma, o
aprendizado se dá de maneira muito mais rápida.
•
Como o AN é também um usuário direto ou indireto da solução em questão, seu
ponto de vista tende a ser muito mais respeitado pela equipe técnica.
•
A possibilidade de enganos e mal entendidos é minimizada. De certa forma, há um nó a
menos na rede de comunicações do projeto.
A contrapartida, ou os riscos inerentes a este modelo:
•
Este AN não tem uma formação técnica. Se não dominar as disciplinas que formam a
análise de negócios, será apenas um usuário. (Entendam, não estou menosprezando os
usuários. Apenas estou dizendo que não podemos confundir usuários com AN's).
•
O AN pode não respeitar integralmente os padrões e o processo de desenvolvimento
estipulados pelo departamento de TI. O problema é minimizado ou eliminado se ficar
clara a subordinação do AN ao gerente do projeto.
•
Se um projeto atende, por exemplo, três departamentos, teremos então três AN's. Cada
um defendendo seu lado. Incorpora-se assim, à equipe de projeto, os conflitos que
normalmente existem entre departamentos.
•
Pode faltar uma visão do todo. Talvez este seja o risco mais sério. Se cada AN olha
exclusivamente o seu departamento, quem se preocupa com o negócio ou processo
como um todo?
Lá no início do capítulo eu prometi uma certa isenção, mas preciso dizer que este desenho
parece mais moderno, mais ágil. Ele parece fazer muito sentido em médias e grandes empresas,
particularmente naquelas que renovam sua carteira de produtos e serviços com bastante
frequência, como bancos, seguradoras e empresas de telecomunicações. Esta renovação sempre
significa novos projetos ou grandes alterações em aplicações existentes.
Áreas de apoio, como contabilidade, RH e o departamento financeiro, não precisam de AN's
32
Capítulo 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 visão
mais ampla do negócio e seus processos. Um risco que pode ser mitigado com a instituição de
uma comunidade de prática, sugestão que será apresentada posteriormente neste capítulo.
Podemos transformar um usuário-chave em um analista de negócios? Sim, por que não?
Mesmo que no início existam algumas deficiências no conhecimento de arquitetura de
aplicações, isso é compensado pelo grande domínio de negócio apresentado. Mas, vale repetir
que é fundamental que o usuário-chave seja de fato treinado para dominar as habilidades
técnicas que caracterizam um AN. É isso que vai garantir uma boa comunicação com a equipe
técnica. Em um grande banco nacional, cujo modelo será apresentado no tópico seguinte, tem
advogados, administradores e gente formada em letras em sua equipe de AN's.
O treinamento dos usuários-chave deve ser patrocinado e ministrado pela área de TI. Assim,
além das habilidades técnicas, o novo AN também é apresentado ao processo de
desenvolvimento utilizado pela empresa, aos seus padrões, ferramentas e tecnologias.
Em outro cenário, ainda neste modelo, as áreas de negócio contratam AN's já formados. Neste
caso será preciso um período de imersão. Mesmo que conheça o ramo de atividade em
questão, o AN precisará estudar a empresa e o departamento que o está contratando. Falo mais
sobre a seleção e contratação de AN's abaixo, ainda neste capítulo.
33
O AN não é de Ninguém
Ou seja, existe um departamento autônomo de análise de negócios que não é subordinado
nem a TI nem a nenhuma área de negócio específica. Tamanha independência realmente deve
significar uma privilegiada posição em todas as negociações e situações de conflito. Ou, por
outro lado, mais um chefe a ser chamado para acalmar ânimos e encontrar uma solução 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 não conheço levaram a declaração de
independência desta área que agora é conhecida como Departamento de Tecnologia do
Negócio. Estrutura estranha, nome mais ainda.
Vantagens superficialmente percebidas ou chutadas:
•
A independência dos AN's possibilita a atuação destes como juízes realmente isentos.
Nos conflitos entre áreas usuárias e TI, tão comuns, os AN's podem ter a última
palavra. Ou guiar o consenso.
•
Ao contrário do modelo anterior, aqui a visão do todo é mais fácil de ser obtida. Como
precisa atender todas as áreas de negócio, é mandatório que o conjunto de AN's
conheça todo o negócio, sua estrutura, processos, motivações e regras. Além, é claro, da
arquitetura de informações e de aplicações.
O preço pago, igualmente suposto:
•
Trata-se de um canal a mais de comunicação, um departamento a mais, uma estrutura
gerencial a mais. Além do custo, maior que dos dois modelos anteriores, há o risco de
conflitos ainda mais difíceis de serem sanados por envolverem agora um mínimo de
três e não duas partes interessadas.
•
A consolidação dos protocolos de comunicação entre as áreas, particularmente entre o
departamento de AN's e a área de TI, é mais lenta. Os processos de desenvolvimento e
gerenciamento foram divididos. As partes do processo que envolverem as duas áreas
não podem ser alteradas sem o consentimento de ambas.
Devo confessar uma certa antipatia por este modelo. Em tempos de questionamento e
enxugamento das estruturas e dos processos de gestão3, é difícil justificar a criação de um novo
departamento em uma empresa.
Parece, eu disse parece, que “tiraram o bode da sala”. Havia um sério problema de
relacionamento entre usuários e técnicos? Ao invés 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 solução cara demais.
3 Aqui confesso extrema simpatia e forte influência de “O Futuro da Administração”, livro de Gary Hamel e
Bill Green. Elsevier-Campus (2008).
34
Capítulo 3
Mas vamos trabalhar em outro cenário. Imaginem uma empresa que trabalha apenas com um
tipo de produto ou serviço. Um produto ou serviço baseado em software. Neste caso faz
sentido que a equipe de AN's fique concentrada em um único departamento, que não é 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
serviços oferecidos. A subordinação ao dono do produto, marketing, garante agilidade e
alinhamento. Mas reparem que não se trata de um departamento de AN's, e sim de uma
variação do segundo modelo: uma área de negócio é “dona” dos AN's.
Escritórios de Análise de Negócios
E por falar em antipatia e azedume... Queria muito 5 minutos cara-a-cara com o infeliz que
inventou os escritórios de projetos4. Este novo silo retrata duas coisas: o corporativismo e o
medo. Criaram um muro em torno dos gerentes de projetos, exatamente quem deveria
derrubar muros e mostrar para as empresas como é o trabalho em equipes multidisciplinares.
Um contrasenso total. Mas nossa área adora propagar péssimas idéias. Eis então que pipocam
sugestões de escritórios de processos e escritórios de análise de negócios. Céus!
Puxo o tema aqui exatamente porque esses escritórios se assemelham ao modelo em que há
um departamento exclusivo para AN's. A diferença é que os escritórios de AN's, pelo visto,
serão subordinados a TI. Mas, a exemplo dos PMO's (Project Management Offices), terão sua
estrutura gerencial e sua própria burocracia. Há justificativa?
Em todos os casos as desculpas são as mesmas: i) promover o gerenciamento de projetos (ou a
análise de negócios); ii) treinar novatos; e, iii) garantir o respeito aos padrões.
Primeiro: profissão nenhuma carece de promoção no interior de uma empresa. Se ela é
instituída é porque reconhecem seu valor e utilidade. Segundo: existem alternativas mais
baratas para treinamento e difusão de boas práticas. Terceiro: um escritório por si só não
garante nada. Vai punir?
Acabei de me lembrar que naquele caso que contei lá em cima, “No Meio do Tiroteio”, a
empresa retratada também tem um PMO. Olha só: AN's, um centro de soluções, fábricas
terceirizadas e, como cereja do bolo, um escritório de projetos. É ou não é uma beleza? Quatro
áreas só para brigar com os usuários! Quanta covardia...
Peço desculpas pelo desabafo. Mas ele foi necessário para que a alternativa apresentada abaixo
seja melhor avaliada.
4 E 10 minutos com o “gênio” que inventou as fábricas de software.
35
Comunidades de Prática5
Em organizações dos mais diversos portes e naturezas existem grupos informais que
compartilham informações e conhecimentos. Esses grupos ou redes de contatos normalmente
giram em torno de um interesse comum. É natural que tais redes extrapolem as fronteiras da
organização, na forma de grupos de estudos e comunidades virtuais. Esses grupos nascem de
forma espontânea e seu crescimento é orgânico. Não há colaboração que não seja voluntária.
As organizações 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 Prática que são reconhecidas e apoiadas pela organização. É importante saber
respeitar o aspecto espontâneo e voluntário dessas comunidades, cujas características são
bastante distintas daquelas que caracterizam uma equipe de projeto, um departamento e
arranjos como os PMO's e escritórios de análise de negócios.
Equipes, departamentos e escritórios são estruturas formais. Seguem uma hierarquia e
obedecem procedimentos e padrões. Enquanto as equipes são temporárias, os dois últimos são
permanentes. Colocando de outra forma, eles são centros de custos.
Comunidades de prática, por outro lado, são estruturas informais. Elas se autodefinem e
autogerenciam, alheias à hierarquia e aos processos vigentes. Preste um pouco de atenção: sua
empresa pode ter algumas dezenas de comunidades de prática. Grupos que gostam de se reunir
com certa frequência, durante o almoço, nos cafezinhos ou até mesmo em happy hours. Muitos
gostam de “falar sobre o serviço”, já reparou? Pois bem, eles são embriões de ou comunidades
de prática já constituídas. No popular, de forma pejorativa, gostamos de tratar esses grupos
como “panelinhas”. Mas as trocas de conhecimento e experiências que eles estão efetuando já
devem gerar algum valor para a empresa. A proposta aqui é que a empresa reconheça e apoie
esses grupos informais, as Comunidades de Prática.
Antes de definirmos como uma empresa pode apoiar uma comunidade, vamos detalhar um
pouco mais as suas características fundamentais. Uma comunidade de prática é:
•
Motivada pelo Bate-papo: ela visa desenvolver as competências dos participantes
através da geração e troca de conhecimentos. Ocasionalmente o grupo pode tentar
descobrir uma solução para um problema específico, mas isso é uma exceção. Não há
uma pauta pré-definida para seus encontros.
•
Guiada pelo Valor: seus membros compartilham interesses ou práticas. O valor está
no processo de aprendizado.
•
Definidas pelo Conhecimento: que é interdependente. Suas fronteiras são
permeáveis, ao contrário de equipes de projetos, departamentos e escritórios que
apresentam rígidas estruturas.
•
Duração Indeterminada: uma comunidade dura enquanto houver interesse.
5 Contém trechos do artigo “Aprendizado Interprojetos”, de minha autoria, publicado nos anais da 6a. edição
do seminário “Gestão de Projetos de TI” promovido pela SUCESU-SP (2004). A versão integral do artigo, em
36
Capítulo 3
•
Formação Aleatória: a participação é voluntária. E os participantes se autoselecionam.
Daí o apelido “panelinha”.
São esses aspectos simples e naturais que fazem das comunidades de prática uma alternativa
muito moderna. A ausência de mecanismos de controle formais pode assustar um pouco. Mas
é exatamente essa liberdade que gera o potencial de aprendizado. E de inovação, uma palavra
que está na boca de todo mundo mas distante demais das estruturas e processos das empresas.
Uma empresa não precisa fazer muito para apoiar a formação e manutenção das comunidades
de prática. Quatro passos bem básicos são necessários:
•
Identificar os grupos informais criados em torno de temas (conhecimentos) que sejam
relevantes para a organização;
•
Indicar um ou mais membros do grupo para intermediar o relacionamento do grupo
com a organização;
•
Oferecer uma infraestrutura básica para o grupo, como espaços reservados para seus
encontros;
•
Reservar um período de tempo, da jornada normal de trabalho, para que tais encontros
ocorram.
A interferência da organização no funcionamento da comunidade de prática deve ser a menor
possível. O sentimento de confiança mútua e de abertura para exposição de pontos de vista são
essenciais para a longevidade da comunidade. Porém, é claro, as organizações precisam
perceber que seu investimento, por menor que seja, está dando algum tipo de retorno.
Indicadores tradicionais de ganho de produtividade não servem neste caso. Os principais
ganhos serão percebidos na performance dos colaboradores e, consequentemente, na qualidade
dos projetos.
Uma empresa pode ter comunidades com os mais diversos temas. Nossa preocupação aqui é
com os analistas de negócios. Por se tratar de uma função ainda em fase de definição, uma
comunidade de prática específica para AN's faz muito sentido.
Por fim, é importante destacar também as extensões das comunidades de prática.
Normalmente elas extrapolam as fronteiras de uma organização. Grupos de discussão, fóruns e
outras ferramentas oferecidas na Internet permitem a colaboração e a troca de experiências com
profissionais do mundo todo. Uma empresa tem muito a ganhar quando seus colaboradores
são incentivados a participar desse tipo de associação. Mas, por incrível que pareça, muitas
ainda censuram o uso da Internet por trabalhadores do conhecimento. Se há o temor de que
informações sensíveis ou sigilosas sejam acidentalmente liberadas, a empresa deveria apenas
publicar um guia de uso desse tipo de ferramenta. Impedir seu uso, além de antipático e
desmotivador, também fecha as portas da empresa para conhecimentos que existem além de
seus muros. Na era da Economia da Informação, essa não parece ser uma coisa muito
inteligente.
37
Contratando Analistas de Negócios
Se esta é uma função / profissão relativamente nova e mal definida, como uma empresa pode
contratá-la? O que ela deve buscar nos currículos? Quais tipos de testes podem ser aplicados?
Enfim, como devem ser os processos de seleção e contratação de AN's?
É importantíssimo começar bem. Nossa área, particularmente aqui no Brasil, é conhecida por
publicar anúncios de vagas exagerados, mal definidos e pouco eficazes. São exagerados porque
frequentemente buscam super-heróis. Por exemplo:
Coordenador de projeto com 10 anos de experiência e certificação PMP. Formação superior em engenharia, administração, sistemas de informação ou equivalentes. Experiência comprovada no gerenciamento de projetos de sistemas de informação para varejo, atacado ou indústria. Será considerado um diferencial conhecimentos do SAP/R3 e da arquitetura Java (JEE). Noções de alguma metodologia de desenvolvimento, particularmente O RUP, é desejável.
Esse tipo de coisa ficou tão comum que nem percebemos o absurdo, né? Como é possível que
alguém realmente domine temas tão díspares 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 tecnológica complexa e o RUP (Rational Unified
Process), igualmente gigantesco? Mas o fato de gente se candidatar para vagas desse tipo assusta
mais que o anúncio. Será que os candidatos usam capas, máscaras e vão para as entrevistas
voando?
Resta a torcida para que o mesmo não ocorra com os AN's. Apesar de uma certa indefinição,
aquela lista básica de habilidades sociais e técnicas que ele deve apresentar parece bastante
razoável, não? Se você concorda, então talvez goste da sugestão de anúncio abaixo:
Analista de negócios com X anos de experiência. Formação superior em sistemas de informação, administração ou equivalente é desejável. Deve comprovar experiência no ramo de [nomedoramode
atividades]. A certificação CBPA (Certified Business Analysis Professional) será considerada um diferencial. Deve dominar a modelagem de negócios, preferencialmente utilizando o padrão de notação [UML|EPBE|BPMN|EPC|IDEF*]. Deve saber guiar eventos para desenvolvimento de requisitos e ter boa comunicação. É imprescindível o conhecimento de técnicas para registro, estruturação e testes de requisitos. Não estou pedindo que você copie e cole o exemplo acima. Minha preocupação é que você não
exija do AN mais do que ele pode dar.
Um anúncio bem específico e detalhado tem maiores chances de atrair melhores candidatos.
As retrições devem espantar a maioria dos aventureiros. Normalmente, quando citamos as
habilidades técnicas de forma detalhada, o candidato desconfia que algum tipo de teste será
aplicado. Será!
38
Capítulo 3
Se você pediu conhecimento de UML, por exemplo, como avaliá-lo se não com uma
provinha? O mesmo vale para todas as habilidades técnicas. Eu aplicaria, no mínimo, um teste
com as seguintes situações:
•
Peça que o candidato desenvolva um modelo de alto nível que destaque os principais
elementos que caracterizam aquele ramo de atividades específico. Se há uma linguagem
de modelagem em questão, peça que o modelo seja desenvolvido neste padrão.
•
Apresente um modelo de um processo de negócio relevante (para seu negócio) e
comum, mas incompleto. Peça que o candidato complete o desenho e justifique cada
elemento acrescentado.
•
Apresente um problema de negócio e se ofereça para ser entrevistado pelo candidato.
Ele deve elaborar uma especificação de caso de uso completa, inclusive com os casos de
testes.
•
Por fim, peça que o candidato escreva na hora, na forma de um documento de visão, as
razões porque a empresa deve contratá-lo. Que o candidato se venda como venderia um
projeto. Em um documento de uma página apenas.
Cada questão acima vale 25 pontos. Todo candidato que não 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 questões. É horrível quando sinto que gasto o
seu e o meu tempo com questões que dependem exclusivamente de bom senso. Perdão.
Mas o processo não se encerra aqui. Por enquanto você apenas garantiu que o candidato possui
as habilidades técnicas mínimas. O que fazer para avaliar as habilidades sociais? Aqui, mais do
que provinhas, são as conversas que comprovarão a adequação do candidato. E essas conversas
não 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 negócio para conhecer o candidato e
bater papo com ele. Se você é de uma área de negócio, chame alguém de TI para o bate-papo.
Este profissional será uma ligação entre diversas áreas. É fundamental que a avaliação do
candidato seja compartilhada pelo maior número de departamentos envolvidos. A área
contratante tem a palavra final, claro. Mas ela deve conhecer opiniões e eventuais vetos de
outras áreas. Questão de prevenção, de gerenciamento de riscos.
Ah, faltou dizer que o RH pode participar do processo. Se ele não for um departamento
exclusivamente burocrático e divulgador de regras, então ele deve participar do processo.
39
Sendo Contratado
Este livro foi escrito para você, meu caro (candidato a) Analista de Negócios. Mas eu não
poderia ignorar demandas como a que tratei no tópico anterior. Apenas espero que aquelas
sugestões ali também sejam úteis para ti. Já pensou se uma empresa maluca resolve adotar
minhas sugestões para anúncio 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 sério, tratemos agora do lado dos candidatos. O que eles podem fazer para serem
selecionados para entrevistas e contratados? Do lado de lá o processo começa na identificação
da necessidade e na correta redação de um anúncio. Do lado de cá começa na elaboração do
currículo. Não, não vou te dar um template de currículo. AN de verdade sabe que templates são
um perigo! Profissionais do século XXI acham que templates são coisas de gente preguiçosa e
pouco criativa. Te darei apenas algumas dicas:
•
Comece escrevendo com todas as letras qual vaga você almeja: AN.
•
Valorize sua experiência começando o currículo por ela. Indique as últimas empresas e
suas principais realizações, de forma sucinta. Lembre-se, a capacidade de síntese é uma
habilidade social esperada pelo contratante.
•
Na sequência mostre sua formação, inclusive extensões e cursos. Como esta área não
tem um curso de graduação específico, esses complementos são de suma importância.
Mas limite-se àqueles que realmente comprovem seu interesse pela análise de negócios.
Simples assim, objetivo desse tanto. Uma versão mais detalhada, com referências e indicações,
pode ser mantida em um site de relacionamentos profissionais como o LinkedIn6. Se for o caso,
então informe o endereço de seu perfil público no currículo impresso. E prepare-se para a
entrevista.
Lembre-se que toda empresa minimamente séria vai aplicar testes. Então estude e revise seus
conhecimentos com uma certa antecedência. Faça uma breve pesquisa sobre a empresa e seu
ramo de atividades. É legal conhecer tanto o histórico quanto as perspectivas de todo aquele
mercado. Saber quais são os clientes, fornecedores e concorrentes devem fazer parte do estudo.
Se a Internet (melhor dizendo, o Google) não ajudar muito, o que é difícil hoje em dia, busque
publicações da área. Ou seja, demonstre interesse. Afinal, você está se oferecendo para trabalhar
naquela empresa. Você não quer saber onde está amarrando seu burrinho?
6 http://www.linkedin.com
40
Capítulo 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-capítulo. Com uma justificativa: preciso mostrar como podemos posicionar os
AN's em uma equipe de projeto para desenvolvimento de sistemas. Não 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 especialização, mas não numa
filosofia taylorista ou fordista, por favor. É Drucker7 quem me inspira8:
“Conhecimento, por definição, é especializado. Com efeito, as pessoas
realmente detentoras de conhecimentos tendem ao excesso de especialização,
qualquer que seja seu campo de atuação, exatamente porque sempre se deparam
com muito mais a aprender.”
Nos tempos do COBOL e similares, era fácil imaginar uma equipe formada em torno de um
superprogramador, como sugerido por Fred Brooks9. Depois que inventamos o mundo Cliente
/ Servidor e decidimos usar a Internet como plataforma para nossas aplicações, tudo mudou.
Tecnologias se tornaram mais complexas – cresceram para os lados e para cima. Antes um
mesmo módulo escrito em COBOL definia dados, interfaces e lógica de negócio. Era natural
que um programador escrevesse tudo.
Depois ganhamos bancos de dados, servidores de aplicações, servidores Web e mais um imenso
conjunto de elementos. Mesmo que alguns gênios insistam que podem dominar tudo, uma
organização séria deve se preocupar com a formação de equipes que valorize especializações.
Da mesma forma que técnicos de futebol não montam times com 11 generalistas em campo.
Em cada posição há muito a ser estudado. Com um agravante quando falamos de
desenvolvimento de sistemas: novidades aparecem quase todo dia, o que torna o domínio
relativamente efêmero. Como dizia Drucker, todos sempre irão se deparar com muito mais a
aprender. Por isso é bom desconfiar de todo mundo que domina muita coisa em nossa área.
Ou confiar desconfiando. Goleiros artilheiros são exceção, não a regra.
Mas é importante saber quais especializações valorizar. Um time de futebol sempre terá 11
posições a ser ocupadas. Não podemos ter um número variável de especializações. Uma
estrutura básica, um modelo para a formação de equipes é necessário. Abaixo apresento um
desenho e uma breve explicação sobre cada especialista sugerido. De novo: esse breve desvio é
necessário para que você entenda a relevância e o posicionamento do analista de negócios em
uma equipe de projeto.
7 http://en.wikipedia.org/wiki/Peter_Drucker
8 “O Advento da Nova Organização”, artigo de Peter F. Drucker publicado em “Gestão 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 edição original do livro, de 1975.
41
Figura 2: Modelo para a Formação de Equipes.
Em Infraestrutura residem todos os profissionais responsáveis pelo dimensionamento,
montagem (setup) e manutenção dos ambientes de desenvolvimento, homologação e produção.
Cada projeto pode exigir uma composição um pouco diferente desta célula. Lidaremos com
transações financeiras ou outros dados que requerem muito cuidado, então precisaremos de
um especialista em segurança, firewalls, encriptação e assim por diante.
Infelizmente, é relativamente comum que estes profissionais só sejam alocados em um projeto
quando a fase de entrega está prestes a ser iniciada. Essa prática resulta nos tradicionais embates
entre desenvolvedores e “a turma de infra”. Eles deveriam se envolver com o projeto desde os
primeiros dias, entendendo os requisitos e se mobilizando para realizar o dimensionamento,
configuração e testes de todos os elementos de infraestrutura envolvidos na solução.
Aqueles que o mercado convencionou chamar de “analistas-programadores” aparecem em três
células: Dados, Serviços e Interfaces. Talvez a distinção entre analistas de sistemas e
programadores realmente seja uma coisa do passado. Mas ignorar a diferença entre as três
camadas não é uma boa idéia. Cada uma dessas áreas evoluiu muito nos últimos tempos. E,
consequentemente, se tornaram mais exigentes em termos de conhecimentos e especialização.
Vamos dar uma olhada em cada uma delas.
O DBA (DataBase Administrator) morreu. Viva o novo especialista na camada de Dados, o
profissional que sabe que o mundo não gira em torno de bases relacionais. O cara que,
conhecendo os requisitos dos usuários, saberá lançar mão de bases multidimensionais e
gerenciadores de conteúdo não-estruturado, além dos tradicionais bancos transacionais.
42
Capítulo 3
O programador clássico, aquele que se destaca por seu domínio de lógica e coisas como
orientação a objetos, componentização, orientação a serviços, design patterns e outros papos
afins, é aquele que ocupa a célula chamada Serviços. As fronteiras com as duas células vizinhas
devem ser bem delimitadas. Acontece que, não raro, os ocupantes desta casa gostam de falar
que “banco de dados é coisa do passado”. Isso sem falar que suas telas são terríveis, uns
rascunhos medonhos: eles valorizam demais a parte invisível do iceberg, se esquecendo que
tudo o que o usuário vê, toca e avalia são as interfaces.
Ou seja, as Interfaces merecem uma célula 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 móveis... Não é preciso ir muito
longe para mostrar que especialistas são necessários aqui também. E que, além das tecnologias,
eles devem dominar conceitos de ergonomia de software e usabilidade.
Esses quatro profissionais ou grupos de profissionais, infraestrutura, dados, serviços e
interfaces, têm pelo menos uma coisa em comum: normalmente eles são desastrados (e
desastrosos) no trato com clientes e usuários. Porque eles não são treinados para entender o
negócio e os usuários. Como já foi dito anteriormente, eles estão ansiosos para desempenhar
sua função principal, seja ela modelar, programar ou configurar servidores. Para eles, o
desenvolvimento de requisitos é um tipo de empecilho, uma “chateação” que deve ser
resolvida antes que eles possam se debruçar naquilo que realmente gostam de fazer. Por isso,
não raro, eles são negligentes – querem remover aquela barreira o mais rapidamente possível.
Entra o Analista de Negócios. O cara que foi treinado para entender o negócio e os usuários.
O profissional cuja principal atribuição é a comunicação desse entendimento para toda a
equipe de projeto.
Veja novamente a figura 2 acima. Clientes e usuários ficam do lado esquerdo daquele diagrama.
Isso significa que o AN, o Coordenador e o Arquiteto são os principais pontos de contato com
as partes interessadas que ficam fora da equipe. Mas é importante frisar que o AN não é um
tipo de parede, um impedimento para o contato dos usuários com o restante do time. Pelo
contrário, ele deve facilitar esses contatos. E organizá-los. É sabido que o contato não 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 três pontos de contato? Acontece que cada um deve cuidar de seu assunto:
•
O AN cuida do problema, ou seja, do entendimento do negócio e dos usuários;
•
O Arquiteto cuida da solução, de seu desenho, qualidade e implementação; enquanto o
•
Coordenador cuida do projeto, prazos, custos, suprimentos, e todas as demais questões
administrativas.
Mas é preciso explicar um pouco melhor as atribuições do Coordenador e do Arquiteto.
43
Dois Líderes
Vou justificar minha sugestão apelando novamente para Fred Brooks10, que no mesmo livro já
referenciado acima falou mais ou menos assim:
“Pensadores são raros. Executores são raros.
Pensadores-Executores são mais raros ainda.”
Uma empresa não pode ter um modelo para a formação de equipes que se baseie na sorte. Na
sorte de encontrar um gênio “pensador-executor” que lidere seus projetos. Por isso a distinção
entre o Arquiteto (Pensador) e o Coordenador (Executor) é tão importante.
O Arquiteto, também conhecido como Líder Técnico, é o dono da solução. Trabalhando com
os representantes das células Interfaces, Serviços, Dados e Infraestrutura, ele cuida do desenho
e da implementação de um sistema. Uma de suas principais atribuições é a manutenção da
integridade arquitetônica da solução. Em conjunto com o AN, ele garante que a aplicação
realmente satisfaz todos os requisitos apresentados. Ele lidera a equipe, cuidando
exclusivamente de questões técnicas. E deve ter a palavra final sobre o escopo da solução. É
interessante notar que não se trata de uma função burocrática. O arquiteto também coloca a
mão na massa, implementando as partes mais críticas de uma solução ou criando guias e
modelos para os demais membros.
Já o Coordenador se concentra em todas as questões gerenciais e administrativas de um
projeto. O gerenciamento de prazos, custos, suprimentos, comunicação, pessoal e riscos, não
necessariamente nesta ordem, são suas principais atribuições. Ele entende que é ele quem
trabalha para o time, e não o contrário. Como foi colocado por Tom DeMarco11 e Timothy
Lister há muito tempo12:
“A função do gerente não é fazer as pessoas trabalharem e sim tornar possível
que elas trabalhem.”
Definitivamente, não se aplica a máxima que diz que “cachorro com dois donos morre de
fome”. É só uma divisão de responsabilidades: enquanto o coordenador se ocupa da aquisição
da ração – no tempo correto e sem estourar o orçamento, o arquiteto monta o cardápio e serve
nosso querido melhor amigo.
A liderança técnica do arquiteto deve ser respeitada pelo coordenador. Eles debaterão suas
respectivas restrições, sobre prazos por exemplo. Mas a palavra final sobre o desenho da
solução deve ser do arquiteto. Da mesma forma, o arquiteto deve saber respeitar as
deliberações do coordenador. Um bom arquiteto sabe que sempre existirão restrições de
prazos e custos, por exemplo. E que essas restrições serão apresentadas e defendidas pelo
coordenador, principalmente.
10 http://en.wikipedia.org/wiki/Fred_Brooks
11 http://en.wikipedia.org/wiki/Tom_DeMarco
12 No livro “Peopleware: Productive Projects and Teams”, Dorset House (1987).
http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams
44
Capítulo 3
Este tipo de divisão 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 especializações demandadas para a
construção de um filme se equivalem às nossas especializações técnicas (Interfaces, Dados...).
Mas, quando um filme recebe um prêmio, é 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 funções administrativas relativas ao projeto do filme, contratações,
financiamento, controle do cronograma etc. O pensador tem sua própria categoria de prêmios,
de Melhor Diretor.
Por históricas que sejam as desavenças entre produtores e diretores, a indústria do cinema sabe
que precisa desses dois tipos de cérebros para realizar seus projetos. São raros os gênios, como
Spielberg e Lucas, que conseguem assumir qualquer das duas funções. Mais raros ainda são
aqueles que conseguem acumular as duas funções em um mesmo projeto.
O método para gerenciamento de projetos Ágeis chamado Scrum13 tem uma proposta que, em
conceito, se assemelha com este desenho. Ele sugere a existência 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 método, Jeff Sutherland, criou uma bela analogia para explicar a importância dos dois
papéis14: comparando com uma equipe de rally, o Scrummaster é o piloto e o Product Owner é o
navegador.
A similaridade com minha proposta só não é total porque muitos defendem que o Product
Owner trate exclusivamente do domínio 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
solução e não sobre o problema que pretende resolver. Falo mais sobre o Scrum e outros
processos de desenvolvimento e gerenciamento de projetos no último capítulo.
13 http://en.wikipedia.org/wiki/Scrum_(development)
14 http://jeffsutherland.com/scrum/
45
O Tamanho do Time
O modelo sugerido acima deve ser adaptado para cada empresa ou tipo de projeto. Mas sua
estrutura básica deveria ser respeitada. Uma empresa bem pequena, por exemplo, pode não ter
7 funcionários. Ou 7 especialistas. Não é por isso que o modelo não lhe atenderá. Empresas de
software, com irritante frequência, incham mas não crescem. Acumulam funções similares,
talvez aproveitando a ampla oferta de generalistas. Isso é inchaço. Ao usar o modelo como um
guia elas podem, a cada contratação, preencher as células de especialização onde há maior
carência. Assim seu processo de seleção se torna mais objetivo.
Mas, tratemos de algumas questões mais práticas. Se um determinado projeto demandar
apenas 4 pessoas, por exemplo, como fica o desenho da equipe? Algumas recomendações:
•
Que o coordenador e o arquiteto sejam realmente pessoas diferentes. O projeto ganha
com tal distinção, com esse confronto.
•
O coordenador pode acumular a função do AN. Suas habilidades técnicas e sociais são,
de certa forma, equivalentes, o que deve facilitar a junção de responsabilidades.
•
E o arquiteto, como já foi dito anteriormente, realmente coloca a mão na massa. Então
ele pode acumular qualquer outra atribuição técnica (interfaces, serviços e dados).
Devemos notar que o arquiteto sairá mesmo de uma dessas células.
E como saber qual o número ideal de AN's para um empresa? Ainda é muito difícil cravar um
número, uma fórmula. Uma grande empresa nacional, com cerca de 60 mil funcionários, tem
cerca de 150 AN's. Isso daria algo em torno de 1 analista para cada 400 funcionários.
Definitivamente, dada a ordem de grandeza, não serve muito como referência. Prefiro uma
fórmula que leve em conta o número de projetos correntes. Quantos projetos sua empresa
desenvolve de forma simultânea? O número ideal de AN's é igual ao número de projetos
simultâneos vezes 2.
Eu disse número ideal. Porque o ideal é que os AN's atuem em duplas. No decorrer do livro
justifico minha sugestão. Por enquanto vale dizer que se o número ideal não for possível, por
alguma restrição qualquer, mesmo assim considere a possibilidade do trabalho de análise de
negócios ser executado por duas pessoas: o AN e mais um integrante da equipe, de preferência
o coordenador.
Faltou explicar a formulazinha acima: por que o número de projetos simultâneos vezes 2?
Porque é enfaticamente defendido neste livro que seja adotado um processo de
desenvolvimento iterativo e incremental15. Sendo assim, os AN's terão 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 específica no último capítulo.
15 http://en.wikipedia.org/wiki/Iterative_and_incremental_development
16 http://en.wikipedia.org/wiki/Waterfall_model
46
Capítulo 3
47
Parte II
Entendendo o
Negócio
48
Capítulo 3
Modelagem de Negócios
49
Capítulo 4
De todas as disciplinas que formam a engenharia de software, nenhuma é mais mal
compreendida e mal falada do que a Modelagem de Negócios. Muitos a veem como pura
burocracia – geradora de um tipo de documentação que nunca mais é utilizada e muito menos
atualizada. Outros tantos acham que se trata de tentar representar em modelos todo um
negócio, nos mínimos detalhes, o que é impossível. Tanta má compreensão resultou em um
incômodo fato: quase ninguém pratica a modelagem de negócios em seus projetos. Existe até
quem sugira que a modelagem seja tratada como um projeto a parte, separado daquele que
deve gerar a solução. Quanta desinformação!
Que faz com que os projetos já comecem no levantamento de requisitos, com corajosos
analistas tentando compreender as necessidades dos usuários. Não raro esse entendimento é
falho porque o analista não conhece o negócio. Sua comunicação com clientes e usuários é
prejudicada porque ele simplesmente ignora os conceitos básicos que caracterizam aquela
organização e seu mercado. Como esperar boas respostas se o analista não sabe o que
perguntar? Engraçado é que não é raro ouvirmos que “o usuário nunca sabe o que quer”.
Como o título desta segunda parte do livro antecipa, a modelagem de negócios serve para que
possamos Entender o Negócio. As técnicas e métodos que formam esta disciplina nos
ajudam a compreender todos os aspectos de uma empresa, suas motivações, estruturas,
processos e regras.
A modelagem de negócios é o oposto da modelagem de sistemas. Nesta sempre objetivamos o
mínimo detalhe, os modelos evoluem até seu estágio final, o código. Na modelagem de
negócios nos contentamos com o mínimo, só modelamos o essencial. Essencial para quê?
Oras, para uma boa compreensão do negócio. Pensamos assim: se uma parte do negócio é bem
compreendida por todas as partes interessadas, então para que gastar tempo tentando modelála? Hora do alerta para todos que gostam de receitinhas de bolo, checklists e afins: todas as
técnicas e métodos sugeridos nesta parte do livro são opcionais. Você só lançará mão
deles em um projeto quando de fato precisar daquele entendimento.
E, por favor, pense 10 vezes antes de utilizar qualquer diagrama aqui sugerido como
documentação de sistema. A explicação é simples: todo negócio é volátil e dinâmico demais.
Sua documentação ficaria obsoleta em uma velocidade impressionante. E a manutenção desses
documentos pode ser cara demais.
Alertas colocados, mergulhemos então nesta bela e mal compreendida matéria. Neste capítulo
veremos o básico da disciplina, opções de linguagens para modelagem e uma introdução às 3
visões que compõem um modelo de negócios. Visões que serão detalhadas nos capítulos
seguintes.
50
Capítulo 4
Por que modelamos?
Ok, você já sabe, modelamos para entender. Em nosso caso específico, para entender um
negócio. Mas essa afirmação, de certa forma simplista, talvez não seja suficiente para que você
justifique a aplicação desta disciplina em seu próximo projeto. Vamos detalhar melhor as
motivações para a execução da modelagem de negócios:
•
Uma imagem explica mais e melhor do que mil palavras: este velho dito popular,
levemente adaptado, é verdadeiro mas ao mesmo tempo perigoso. Não é qualquer
imagem que substitui milhares de palavras. Há uma imagem certa para cada situação. E
isso significa mais agilidade nos processos de entendimento, avaliação e comunicação
com as partes interessadas.
•
Precisamos saber onde vamos pisar: nosso projeto vai mexer no negócio, alterando
processos e embutindo sistemas. Precisamos ter uma clara noção de todos os impactos
que vamos gerar. Afinal, quem é louco de fazer de um negócio um laboratório de
experiências1? Um bom modelo serve como base para essa avaliação e para a realização
de todas as experiências que se fizerem necessárias. O modelo é o nosso mapa e
laboratório. O modelo também é, por que não, o nosso tabuleiro.
Se ainda assim estiver difícil para você justificar o esforço de modelagem, então apele para
autores de fora, como a dupla escandinava Hans-Erik Ericksson e Magnus Penker2, por
exemplo. Segundo eles:
“Se os requisitos estão baseados em um bom modelo de negócios, há uma
chance muito maior do sistema de informação suportar o negócio de maneira
adequada”.
Além disso, Eriksson e Penker listam outras vantagens que podemos obter de um bom modelo
de negócios:
•
•
•
•
Maior e melhor aderência do sistema ao negócio;
Facilidade na integração de sistemas;
Redução no custo de propriedade (manutenção) de sistemas; e
Reutilização da lógica do negócio em outros sistemas.
Claro, não é o modelo por si só que realiza tantas mágicas. Dependemos de bons processos de
desenvolvimento, boa arquitetura de aplicações e um zilhão de outras coisinhas mais. Aqui é
importante notar que um bom modelo de negócios pode representar mesmo várias 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 comentário:
cientes ou não, existem vários loucos por aí que fazem isso: do negócio uma experiência.
2 Autores de “Business Modeling with UML”, Wiley (2000), que aparece na Bibliografia Comentada, no final
deste livro.
51
O que Modelamos?
Negócios de qualquer segmento ou porte são sistemas muito complexos, compostos dos mais
diversos elementos. Temos pessoas, funções e departamentos; instalações, máquinas e
equipamentos; processos, procedimentos e regras; produtos, serviços e clientes; mercado,
concorrentes e parceiros; planos, objetivos e metas. Essa listinha é genérica e nem de longe
tenta encerrar o assunto. Um modelo deve conseguir representar todos os componentes e
aspectos de um negócio relevantes em determinada situação. Mas deve fazê-lo de forma
organizada, senão não terá valor algum. Todo negócio é complexo. Nossos modelos devem
representar essa complexidade de forma elaborada3, de maneira que facilite o entendimento e
comunicação.
Tão antiga quanto andar para a frente é a noção de que facilitamos a resolução de um problema
grande e complicado quebrando-o em diversos pedacinhos. Um modelo de negócios é
formado por um determinado número de visões – os nossos pedacinhos. Cada visão indica
uma forma diferente de enxergar o negócio, uma perspectiva diferente4. Este livro apresentará
apenas as visões mais comuns, existentes em negócios de qualquer natureza. Mas é importante
frisar que, além de não serem obrigatórias (na composição de um modelo de negócios), elas
não são as únicas visões possíveis.
Estudaremos aqui e nos próximos capítulos 3 visões:
•
Visão do Negócio: que também pode ser chamada de Visão da Motivação (do
Negócio). Ela nos ajuda a entender o negócio e seu ecossistema, detalhando
principalmente as suas motivações, seus objetivos e metas.
•
Visão da Estrutura: que nos ajuda a analisar todos os recursos utilizados, consumidos
ou produzidos por uma empresa.
•
Visão dos Processos: que cuida de toda a parte “viva” de uma organização, toda a sua
dinâmica.
Optei por essas três visões, e só por elas, por
acreditar que este conjunto representa um modelo
mínimo – útil e necessário na grande maioria dos
projetos de sistemas. De forma resumida: a visão do
negócio nos mostra o cenário e os objetivos; em
estrutura vemos todos os recursos que estarão
envolvidos nesta busca pelos objetivos; e a visão dos
processos mostra como faremos essa busca.
Figura 3: As 3 visões de um modelo de negócios
3 Combinemos o seguinte: aqui o oposto de complexo não é simples e sim elaborado. Entendemos que não é
possível simplificar um negócio (através de um modelo), e sim torná-lo melhor elaborado. Esse conceito foi
surrupiado de “The Back of the Napkin”, livro de Dan Roam, Portfolio (2008). Como veremos no restante
deste capítulo, não foi só nisso que este livro me inspirou.
4 Esta frase, se fora do contexto, compromete um tanto, não?
52
Capítulo 4
Existem relativamente poucos trabalhos sobre a modelagem de negócios. E não há um padrão
consolidado acerca das visões, nem mesmo das básicas ou mais comuns. No livro de Eriksson e
Penker citado anteriormente, “Business Modeling with UML”, além das três visões acima existe a
Visão do Comportamento. Ela é utilizada particularmente para a análise de recursos
complexos. Aqui vou considerá-la como um subconjunto da visão de processos. Justificarei
minha escolha no capítulo 7.
Outro trabalho sério sobre modelagem de negócios, “Business Modeling: A Practical Guide to
Realizing Business Value5”, não fala de visões mas de disciplinas de modelagem de negócios.
Segundo os autores existiriam 4: Modelagem de Processos, da Motivação, da Organização e das
Regras. Apesar de considerar várias sugestões deste trabalho, optei pelo termo Visões em
detrimento de Disciplinas. E considero a modelagem da motivação como um subconjunto da
visão do negócio. Assim como a modelagem de regras é um subconjunto de todas as três visões
que apresento. Espero que tudo isso fique um pouco mais claro na medida em que as visões
forem apresentadas com mais detalhes.
Agora preciso explicar o adjetivo “sério” utilizado no início do parágrafo anterior. Talvez o
termo seja exagerado, mas serve para distinguir os dois trabalhos supracitados de outros,
particularmente da forma como a modelagem de negócios é apresentada no RUP e no livro
“Modelagem Ágil” de Scott Ambler6. Das 351 páginas de seu trabalho, Ambler dedica apenas 7
ao tema modelagem de negócios. E, como o RUP, baseia suas sugestões exclusivamente em
casos de uso de negócio (BUC – Business Use Case) e modelos de objetos de negócio. Fica claro
que ambos trabalhos nasceram de “gente de sistema” e não de negócio. Os modelos sugeridos
são muito fracos na representação de um negócio real. Não distinguem nem elementos básicos
como recursos, processos, objetivos e regras.
A especificação de casos de uso é uma das ferramentas mais importantes de um AN. Mas neste
trabalho é sugerido que ela seja utilizada exclusivamente para descobrir e descrever requisitos
funcionais de um sistema. Aliás, foi só para isso que ela foi inventada. Qualquer outro uso é
“forçar de barra”, algo como usar um serrote para colocar um prego na parede.
Pois é, já reparou como tomei uma série de decisões por você? Mas eu não espero que você
confie em mim. Não assim, de imediato. O que eu espero mesmo é que você, como eu, sinta
na pele o que é usar uma sugestão ou outra. Tente, por exemplo, modelar um negócio da forma
como é sugerido por Scott Ambler e no RUP. E tire suas próprias conclusões. Eu cometeria
um grave engano se ficasse “em cima do muro” neste livro. Minhas experiências não serviriam
para nada. Mas, por favor, isso aqui não é um atalho. Na menor desconfiança acerca de alguma
das minhas indicações, tente o outro lado. O que eu prometo é isso: sempre mostrar qual é o
outro lado. Portanto, para ficar bem claro: a modelagem de negócios sugerida neste livro
não tem nada a ver com aquela que aparece no RUP e derivados7. Ponto.
Vamos para a próxima questão.
5 De David M. Bridgeland e Ron Zahavi. Morgan Kauffman / OMG Press (2008).
6 “Modelagem Ágil – Práticas Eficazes para a Programação eXtrema e o Processo Unificado”, Scott
W. Ambler. Bookman / Artmed Editora (2004).
7 Faltou citar outro livro relativamente famoso que caiu na “armadilha” do RUP: “UML for the IT Business
Analyst”, de Howard Podeswa. Thomson (2005).
53
Quanto Modelamos?
Uma das maiores falácias sobre a modelagem de negócios é que ela é burocrática. Não raro
utilizam o seguinte termo para condená-la: BDUF8, sigla que em inglês significa “Big Design
Up Front”. Numa tradução livre, “um montão de diagramas antes de qualquer coisa”. O termo
não foi criado exclusivamente para a modelagem de negócios. Mas pegou.
E não de forma gratuita. Realmente há muita gente que acha que deve modelar todo um
negócio, ou boa parte dele, antes de fazer qualquer outra coisa em um projeto. Não é por acaso
que há muita gente também que sugere que a modelagem de negócios seja tratada como um
projeto a parte, bem separado daquele que deve gerar software. Duas coisas ficam implícitas
aqui:
•
Uma visão muito “cascata” do ciclo de vida de desenvolvimento; e
•
A ilusão de que este modelo estará imune as mudanças que afetam diariamente um
negócio.
A modelagem de negócios no contexto de um projeto de software é diferente. Não queremos
documentar o negócio, apenas entendê-lo. Por isso e pelos equívocos listados acima a questão
aqui colocada é muito importante: quanto modelamos? Quantos diagramas são necessários ao
entendimento, avaliação e comunicação de um determinado negócio? Chegamos naquela
questão que interessa a maioria: quanto tempo isso leva?
Resposta default em nossa área: depende. Alguns projetos mais simples podem demandar
apenas um ou dois diagramas que não consomem nem um dia de trabalho. No outro extremo
podemos ter empreendimentos que exigem a elaboração de dezenas ou até mesmo centenas de
artefatos. O mais importante aqui é um teste muito simples: cada diagrama deve explicar de
forma completa e inequívoca algum aspecto do negócio. Esse diagrama só foi gerado porque
não havia outro meio de buscar tal entendimento. Mas, mesmo em um cenário em que muito
trabalho de modelagem é exigido, não há justificativas para que esse trabalho seja feito “antes
de qualquer coisa”. O tal BDUF é nocivo sim e deve ser evitado pelo AN e por toda a equipe
de projeto.
Na sequência deste trabalho tentarei ilustrar este trabalho em um processo iterativo e
incremental. Mesmo que o AN seja obrigado a gerar um grande número de diagramas, ele o
faz de forma gradual e durante praticamente todo o decorrer de um projeto. O que nos traz de
volta a questão: quanto modelamos? Apenas o suficiente para o correto entendimento do
negócio. Podemos pular para a próxima questão?
8 http://en.wikipedia.org/wiki/Big_Design_Up_Front
54
Capítulo 4
Onde Modelamos?
Estranhou a pergunta? Você verá que a resposta não é tão complicada. Refazendo a questão:
Onde baseamos nossos modelos? Um monte de diagramas como fluxogramas e organogramas
não representam necessariamente um modelo de negócio. Ok, um modelo é um conjunto de
diagramas. Mas esse conjunto deve fazer sentido, deve ser íntegro e coerente. Uma das
principais características de um bom modelo de negócio é 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 peça neste tabuleiro. Sendo assim, cada diagrama
deve respeitar as regras de uso do tabuleiro.
Existe um número razoável de alternativas de padrões de notação ou linguagens para a
modelagem de negócios, mas são poucas as que oferecem um metamodelo completo. Agora,
antes de entregar de mão beijada minha opção (acho que já o fiz), apresentarei as 4 principais
alternativas de linguagens para a modelagem de negócios, suas vantagens e desvantagens:
Linguagem de Modelagem
Descrição, prós e contras
IDEF9
(Integration DEFinition)
Uma família inteira de linguagens de modelagem criada entre os
anos 1970 e 1980. Oferece variações (representadas por números na
frente do nome) para os mais diversos tipos de uso. Por exemplo:
•
IDEF0 – Modelagem de Funções
•
IDEF1 – Modelagem de Informações
•
IDEF1X – Modelagem de Dados
•
IDEF4 – Projeto Orientado a Objetos
•
IDEF8 – Modelagem de Interfaces com usuários
Pró: Tem muito tempo de estrada.
Contras: Tem muito tempo de estrada e envelheceu. Apesar do
aspecto “família”, carece de um metamodelo.
É provável que esta linguagem seja mais conhecida através do
EPC10
(Event-driven Process Chain) modelo de trabalho que a tem como núcleo, o ARIS (Architecture of
Integrated Information Systems)11.
Criada no início dos anos 1990, a EPC é uma linguagem para
modelagem de processos de negócio. Como o próprio nome indica,
tem os eventos de negócio como ponto de partida.
Prós: Difusão e bom número de ferramentas que a suportam.
Contra: Incompleta e não-extensível.
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
Linguagem de Modelagem
Descrição, prós e contras
BPMN12
(Business Process Modeling
Notation)
Padrão criado pelo BPMI (Business Process Management Initiative) que
em 2005 foi incorporado pelo OMG (Object Management Group).
Como o próprio nome indica, é um padrão de notação para
processos de negócio. Ou seja, não contempla outros elementos,
como estruturas e dados, que formam um modelo de negócios
completo.
Na realidade a aplicação de BPMN parece fazer mais sentido no
desenho de uma solução, na modelagem de como um processo
deve ficar (to be). É provável que sua utilização se limite a projetos
que envolvam a implementação de um produto BPMS (Business
Process Management System)13.
Pró: É um moderno fluxograma, passível de transformação direta
para execução14.
Contras: É só um moderno fluxograma. E carece de um
metamodelo15.
A UML é uma linguagem de modelagem mantida pelo OMG. Sua
UML16
(Unified Modeling Language) versão 1.1 foi lançada em novembro de 1997, marcando o fim de
um embate que era conhecido como a “Guerra dos Métodos”.
Grady Booch, James Rumbaugh e Ivar Jacobson, os “Três Amigos”,
encabeçaram a criação desta linguagem que reunia as melhores
ideias de cada metodologista.
A UML nasceu para modelar sistemas, não negócios. Ainda assim
algumas alternativas foram sugeridas, particularmente no RUP e
nos trabalhos de Scott Ambler e Howard Podeswa (criticados
anteriormente neste capítulo).
Mas a UML é extensível, ela pode ser adaptada praticamente para
qualquer tipo de necessidade. Em 2000 Hans-Erik Ericksson e
Magnus Penker apresentaram a EPBE (Eriksson-Penker Business
Extensions) no livro “Business Modeling with UML”. Estas extensões
possibilitam a geração de um completo modelo de negócios.
Prós: É a alternativa mais completa para modelagem de negócios.
Com amplo suporte de ferramentas.
Contra: A UML é relativamente complexa. Pode não ser muito
intuitiva para pessoas não técnicas.
12 http://en.wikipedia.org/wiki/BPMN
13 http://en.wikipedia.org/wiki/BPMS
14 Mas nem aqui a coisa ainda funciona direito. A transição de modelos BPMN para BPEL (Business Process
Execution Language) (http://en.wikipedia.org/wiki/BPEL) ainda é problemática.
15 Apesar dos esforços do OMG e alguns de seus integrantes no sentido de dar 'estofo' para a BPMN,
especificamente através do BPDM (Business Process Definition Metamodel)
(http://en.wikipedia.org/wiki/BPDM), até a data de publicação deste livro não havia nenhuma definição.
Oracle, SAP e IBM, por motivos não muito claros, não querem que esta evolução apareça na versão 2.0 da
BPMN.
16 http://en.wikipedia.org/wiki/Unified_Modeling_Language
56
Capítulo 4
UML & EPBE
Se o quadro anterior não foi suficiente para tornar isso claro, então reafirmo aqui uma outra
escolha que fiz por você: quase todas as propostas de diagramas para a modelagem de negócios
apresentadas neste livro se baseiam na UML e em sua extensão EPBE. Preciso justificar minha
escolha:
•
A UML já tem muitos quilômetros e projetos rodados. É uma linguagem
madura, ao contrário da BPMN por exemplo, que carente de um metamodelo não é
muito mais do que uma moderna régua de gabarito.
•
Como a UML é um padrão de facto para a modelagem de sistemas, sua adoção para a
modelagem de negócios reduz traduções e consequentes problemas. A comunicação
entre a turma de negócios e a turma de sistemas se torna mais natural e
intuitiva.
•
Reduzimos gastos com ferramentas e treinamento ao adotar um mesmo padrão
para a modelagem de negócios e de sistemas.
•
A EPBE expande os velhos padrões de modelagem de negócios (organogramas e
fluxogramas), oferecendo novas maneiras de se ver um negócio.
•
A EPBE está disponível em diversas ferramentas, tanto comerciais quanto aquelas
gratuitas e / ou de código aberto.
•
UML e EPBE são extensíveis. Podemos adaptar os padrões para acomodar aspectos
que sejam exclusivos de determinado domínio. Além disso, podemos incorporar novas
ferramentas, como Balanced Scorecards, Mapas Estratégicos e outras que não fazem
parte do desenho original destes padrões mas se configuram importantes elementos de
um negócio.
•
Casos de uso, uma das principais ferramentas utilizadas por um AN para a descoberta e
descrição de requisitos, é também uma das 5 visões oferecidas pela UML. Configuram
a visão central, aquela que permite rastreabilidade entre as demais visões (Lógica,
Processo, Implementação e Distribuição), ou seja, a ligação entre os requisitos e todos
os artefatos gerados em um projeto. Está aqui a ligação entre modelos de negócios e
modelos de sistemas.
Se a lista acima não foi sufiente para convencê-lo do uso da UML para a modelagem de
negócios, então talvez você queira interromper a leitura por aqui mesmo... Peraí!
Brincadeirinha. Mesmo que por algum motivo qualquer você não queira ou não possa utilizar
a UML, o mais importante neste e nos próximos capítulos desta parte são os conceitos. De
certa maneira, todos os diagramas aqui sugeridos podem ser feitos em outra linguagem. Até
numa linguagem inventada por ti. Então, por favor, siga adiante.
57
Quando Modelamos?
Parece consenso, pelo menos teórico17, que todo projeto começa pelo entendimento do
negócio, ou seja, pela modelagem do negócio. Se nenhum estudo é necessário, se toda a
compreensão sobre o negócio é compartilhada por todas as partes interessadas, então não há o
que modelar. Não se deixe enganar, essa situação é raríssima. Quase sempre precisaremos, no
mínimo, de um ou outro modelo. Quando eles devem ser gerados?
Quando a necessidade de entendimento de determinado aspecto do negócio for percebida. Em
um processo iterativo e incremental, a modelagem de negócios pode ocorrer durante
praticamente todo o projeto. Na medida em que novos processos ou atividades de negócio
virarem escopo de uma iteração, a necessidade de gerar modelos – de entender aquela parte do
negócio, pode aparecer. O modelo de ciclo de vida “iterativo e incremental” aparece em
diversos momentos deste texto. Chegou a hora de entender seus conceitos básicos.
Logo no início de um projeto precisamos ter uma visão do todo, algo que em inglês chamam
de “big picture”. É como se fosse uma fotografia instantânea com uma característica muito
peculiar: ela tem 2 quilômetros de extensão e apenas 2 centímetros de profundidade.
Normalmente ela será um elemento da Visão do Negócio.
Esta grande fotografia será o mapa que norteará todos os trabalhos da equipe. O AN, ao
entender o problema de negócio e os requisitos do usuário, ajudará a equipe a definir as
prioridades – a sequência de trabalho. De todos os elementos retratados nesta figura, onde está
aquele que é mais crucial para a solução do problema? O trabalho deve começar por ele. O AN
vai detalhá-lo, saindo dos 2cm iniciais para 4, 8, ou 16 centímetros, dependendo da
complexidade do problema em questão e das necessidades de entendimento das partes
interessadas. Após entregar este estudo para a equipe de construção, o AN parte para o segundo
elemento mais importante. Não sem antes avaliar os resultados da iteração 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
solução; e finalmente, iii) a fase em que a
gente constrói a solução. O desenho ao lado,
intencionalmente, nos lembra uma cascata.
Figura 4: As 3 Fases de todos os projetos.
17 Porque na prática pouca gente modela.
18 No obrigatório “A Arte do Gerenciamento de Projetos”, de Scott Berkun. Artmed Editora (2008). Este
trabalho reaparece na Bibliografia Comentada e em diversos pontos deste livro.
58
Capítulo 4
Quando um projeto utiliza o modelo de ciclo de vida “cascata”, cada uma das três fases acima
ocorrem apenas uma vez. Quando falamos sobre um modelo iterativo e incremental, a
primeira impressão 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 adoção de um ciclo iterativo e incremental é a aproximação com
os usuários 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 não é correto. O
feedback de usuários e clientes define ou altera o plano de trabalho das iterações futuras.
O que em outros modelos de ciclos de vida é tratado como mudança, em um processo iterativo
é visto como evolução, como o amadurecimento da solução. O princípio é muito lógico:
somos humanos, vamos errar. Ao adotar um processo iterativo e incremental assumimos nossa
falibilidade, nossa humanidade.
Voltemos ao gráfico acima. O trabalho do AN se limita a primeira caixinha, na definição do que
precisa ser feito. Então, se em determinado projeto está prevista a realização de 10 iterações,
entendemos que o trabalho do AN, a modelagem do negócio e o desenvolvimento dos
requisitos, ocorrerá 11 vezes. Onze? Sim, porque consideramos que a construção daquele
instantâneo de “2km X 2cm” é uma iteração em si – que podemos chamar de “Iteração 0
(zero)”.
Como eu prometi o básico sobre o modelo iterativo e incremental, aproveitemos o momento
para aprender outras coisinhas básicas:
•
Iterar vem do latim itetare, que significa repetir. Estamos dizendo que repetimos
determinadas atividades n vezes no decorrer de um projeto.
•
O modelo também é incremental porque cada iteração, cada repetição deve significar o
acréscimo de funcionalidades a solução.
•
A duração das iterações é fixa. O escopo pode alterar, mas o prazo não. Quanto maior a
insegurança e / ou a volatilidade dos requisitos, menor deve ser a duração de uma
iteração. Para não complicar as organizações podem adotar 2 padrões: 30 dias para
projetos “calmos” e 15 dias para projetos “nervosos”.
•
O término de cada iteração, com exceção da iteração zero, significa a entrega de
software rodando. Isso é mandatório. Só assim usuários e clientes podem avaliar a
evolução e a qualidade do trabalho. Não há nem nunca existirão modelos ou
documentos que substituam o software. O que não significa que este release esteja
pronto para ser colocado em ambiente de produção, por favor. Na maioria das situações
as entregas intermediárias serão avaliadas em um ambiente de homologação ou testes.
•
Na indisponiblidade do usuário, é o AN quem deve receber e avaliar o software. Mas
este, definitivamente, não é o cenário ideal. A avaliação de usuários e clientes não pode
ser terceirizada. Uma boa alternativa é a liberação quinzenal para AN's e mensal para os
usuários.
59
Como Modelamos?
Você reparou a sequência de tópicos deste capítulo? Ela apresenta uma parte muito importante
do “know-how”, do “saber como” modelar. Espere, não precisa voltar lá no início. Vou repetir a
sequência abaixo:
•
•
•
•
•
•
Por que modelamos?
O Que modelamos?
Quanto modelamos?
Onde modelamos?
Quando modelamos?
Como modelamos?
Esta sequência de perguntas é um dos três principais componentes de uma metodologia
proposta por Dan Roam no livro “The Back of the Napkin – Solving Problems and
Selling Ideas with Pictures19”. Chamada de 6 W's20, essas questões representam 6 maneiras
de ver as coisas. A ordem das perguntas é importante. Sua lógica tem justificativas até no ramo
da neurobiologia. Claro que não vou me aprofundar tanto aqui. Se você ficou curioso, leia o
livro do Dan21. Nos interessa aqui saber como modelar. E nosso processo de modelagem, de
entendimento do negócio, fica mais fácil se tentar responder essas 6 perguntas em sequência22:
1.
2.
3.
4.
5.
6.
Por quê?
Quem ou O Quê?
Quanto?
Onde?
Quando?
Como?
Mas preciso avisar que, apesar da lógica (e da neurobiologia), tomei a liberdade de alterar a
sequência original de perguntas proposta por Dan. O “por que” é sua última pergunta. Para nós
será a primeira. E a explicação é simples: o AN começa o trabalho tentando entender porque
foi colocado no projeto...
Ok, é mais importante que isso. A primeira pergunta é: por que o projeto é necessário? Por que
a empresa precisa do produto deste projeto? Este é o ponto de partida da análise de negócios. É
aqui que aprendemos os Requisitos de Negócio.
19 Portfolio (2008).
20 6 W's porque no inglês as perguntas são: Why, Who/What, How Much / How Many, Where, When e How.
Ok, o cara forçou a barra. Tem dois H's ali no meio. Mas as palavras também possuem um W. Então, tá
valendo. Você entendeu.
21 E veja mais detalhes sobre ele na Bibliografia Comentada, no final deste livro.
22 Pois é, para os caras é fácil decorar “6 W's”. Mas podemos tentar. Que tal? PQQOQC? Tente em voz alta:
PôQêQêOQéCê? Se ainda não decorou, fique calmo. Logo será tão natural quanto contar de 1 a 6.
60
Capítulo 4
A pergunta seguinte nos ajuda a descobrir quem ou o que está envolvido no problema /
oportunidade em questão: 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 irão para o olho da rua?
Na quarta questão avaliamos o onde: Onde a coisa vai acontecer? O objetivo aqui é localização
mesmo: mercado, região, departamento. Qual é o local?
Só então mergulhamos no quando, nos aspectos temporais do problema em questão: Quando
esse problema ocorre? Qual deve ser a sequência 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 difícil de ser respondida? Que é a mais complexa? Que é aquela que tomará a
maior parte de nosso tempo? O “como” é a cola das 5 questões anteriores.
Livros sobre modelagem costumam ser muito generosos na definição do que devemos
desenhar, mas excessivamente econômicos na descrição do processo de modelagem. Eriksson e
Penker, por exemplo, já abrem seu livro avisando que não se trata de uma “metodologia de
modelagem”. Apesar de não se tratar de um livro sobre modelagem de negócios, o trabalho de
Dan Roan cobre esta lacuna de uma maneira muito prática e didática. Seu método é indicado
para qualquer pessoa, para a solução de qualquer tipo de problema. Meu trabalho aqui foi
remixar o melhor dos dois mundos em uma proposta específica para analistas de negócios.
No próximo capítulo estudaremos este remix e os conceitos básicos da modelagem de negócios.

Guia para a Formação de Analistas de Negócios

Transcrição

Documentos relacionados

Modelagem para Tomada de Decisão Financeira - CEFET-MG

Curriculum Vitae - PMI-RIO

Pattern magic. A magia da modelagem

construção do acervo de vestidos de festa

“Esculpir Geometria”

Pesquisa Operacional - Ceplan

CURRICULUM VITAE

Tabela 01 - vagas - Engenharia Ambiental

Resolução de Problemas, Modelagem Matemática e Tecnologias

Coordenador de QSMS RD QSMS