1

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

Draft 0.9(Release Candidate)

Paulo F. VasconcellosJan-Fev/2009

2

Créditos & DébitosEste 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:

Sob as seguintes condições:

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

copiar, distribuir, exibir e executar a obra

criar obras derivadas

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.

Créditos & Débitos 3

Outras informações Legais e sobre a Editora

4

Prefácio

Créditos & Débitos 5

Índice

6

Introdução 7

Capítulo 1 Introdução

8 Capítulo 1

Introdução 9

Parte I

O Analista de Negócios

10 Capítulo 1

O Analista de Negócios 11

Capítulo 2 O Analista de Negócios

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 super-heró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óciosA 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.

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

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.

Figura 1 - As 6 disciplinas do BABoK

O Analista de Negócios 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 Comunicação dos Requisitos

Garantir que as partes interessadas concordam com as necessidades 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óciosO 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.

O Analista de Negócios 17

Uma Profissão, Vários NomesPor 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 Use-Case 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óciosAinda 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?

O Analista de Negócios 19

HabilidadesNã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 SociaisEm 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).

O Analista de Negócios 21

Habilidades TécnicasTambé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 “caixa-preta”, 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

O Analista de Negócios 23

EspecializaçãoAo 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”.

O Analista de Negócios 25

Darwin e os AnalistasDarwin 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 É do Negócio ou de TI?

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 TIA 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”.

É do Negócio ou de TI? 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 TiroteioA 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.

É do Negócio ou de TI? 31

O AN é do NegócioE 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.

É do Negócio ou de TI? 33

O AN não é de NinguémOu 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óciosE 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.

É do Negócio ou de TI? 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.

É do Negócio ou de TI? 37

Contratando Analistas de NegóciosSe 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 [nome­do­ramo­de­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.

É do Negócio ou de TI? 39

Sendo ContratadoEste 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 EquipesEste 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.

É do Negócio ou de TI? 41

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.

Figura 2: Modelo para a Formação de Equipes.

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.

É do Negócio ou de TI? 43

Dois LíderesVou 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/

É do Negócio ou de TI? 45

O Tamanho do TimeO 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

É do Negócio ou de TI? 47

Parte II

Entendendo o Negócio

48 Capítulo 3

Modelagem de Negócios 49

Capítulo 4 Modelagem de Negócios

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.

Modelagem de Negócios 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.

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?

Figura 3: As 3 visões de um modelo de negócios

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

Modelagem de Negócios 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.

EPC10

(Event-driven Process Chain)É provável que esta linguagem seja mais conhecida através do 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

Modelagem de Negócios 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.

UML16

(Unified Modeling Language)A UML é uma linguagem de modelagem mantida pelo OMG. Sua 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 & EPBESe 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.

Modelagem de Negócios 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.

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.

Figura 4: As 3 Fases de todos os projetos.

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.

Modelagem de Negócios 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. Por quê?2. Quem ou O Quê?3. Quanto?4. Onde?5. Quando?6. 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.