Blog

Quem Acerta na Primeira?
Dos diversos vícios que caracterizam nossa área, existe um particularmente perigoso: quando apresentados a um determinado problema, nos contentamos com a primeira solução que aparece. Excesso de confiança? Outra derivação da fatídica – e não inteiramente mentirosa – arrogância que carimba nosso perfil? Sim, mas não é só isso. Há também o fator prazo: “é para ontem!” O cliente, mal acostumado como nossa extrema agilidade, não entenderia caso pedíssemos um tempinho para pensar na melhor solução. Este problema é mais comum em empresas prestadoras de serviços, mas também é percebido em outras organizações de TI. Ou seja, nossas propostas, sejam elas para clientes externos ou internos, quase sempre estão vendendo a primeira solução que pintou em nossas cabeças. Mas quem acerta na primeira?

A mais importante ferramenta do físico é sua cesta de lixo.
– Albert Einstein

As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção.
– Frank Lloyd Wright

Costumo dizer que, na iteração 0 (nos momentos iniciais do projeto, que antecedem o estudo de viabilidade e a elaboração de uma proposta), o principal trabalho do analista de negócios (AN) é ter uma visão do todo: “2 quilômetros de extensão e 2 centímetros de profundidade“. Para obter esse “instantâneo”, o AN lança mão de suas duas principais armas-disciplinas: A Análise e Modelagem do Negócio e a Engenharia de Requisitos .

Ao interpretar as dores e os objetivos do cliente, o AN começa a dar um certo “relevo” àquele “instantâneo”. Ele destaca os requisitos de usuários mais críticos – fundamentais para o negócio. Como mostrei na pequena série “Estruturando Requisitos” (link p/ parte 2), cada requisito devidamente *aprendido* pelo AN é – obrigatoriamente – acompanhado do atributo “Grau de Importância”: aquele requisito é Fundamental, Importante ou Opcional?

Com base nesta classificação o AN tem condições de selecionar os pontos que merecerão sua maior atenção. Sua atuação, agora, depende do tempo que ele tem para a elaboração da Proposta (ou Estudo de Viabilidade, ou Documento de Visão, ou Project Charter…). Seguindo a sugestão apresentada no artigo citado no parágrafo anterior, cada Requisito de Usuário selecionado é transformado em um Caso de Uso. O requisito “Emitir Nota Fiscal”, por exemplo, vira o caso de uso cujo título é “Emitir Nota Fiscal”.

Ao desenvolver o caso de uso em questão, o AN está “fazendo um zoom” naquele “instantâneo”. Por ser crítico para a solução do problema de negócio, aquele requisito (de usuário) será desdobrado em n requisitos funcionais. Mais que isso: no mesmo momento o AN também pode estar descobrindo ou aprendendo regras de negócio, definições de dados e também alguns requisitos não-funcionais. Informações que podem ser facilmente registradas em um bom modelo para especificações de casos de uso. Para cada requisito *aprendido* segue valendo a mesma questão: ele é Fundamental, Importante ou Opcional?

Vamos supor que estamos tratando de um projeto com 10 casos de uso. O AN teve tempo suficiente para detalhar um pouco mais 4 deles. Claro, para o detalhamento ele lançou mão de entrevistas, observações, sessões JAD (ou workshops) – as técnicas mais indicadas para aquele projeto e/ou cliente. Respeitando o prazo (que quase sempre é imposto), ele desenhou o melhor retrato possível do problema do cliente. Este retrato é composto por um grande diagrama conceitual (ou mapa de processos), diagramas de processos ou de linhas de montagem (caso os processos de negócio em questão sejam complexos o suficiente para justificar a elaboração destes), a classificação de 10 casos de uso e a especificação (um pouco mais detalhada) de 4 deles. Esta “radiografia” é tudo que a equipe possui para definir qual a melhor solução.

Equipe? Sim, o desenho da solução deve ser um trabalho em equipe. Em um futuro artigo apresentarei o que chamo de “parlamento” – o formato desta equipe. Vale ressaltar que cada ponto de vista relevante deve estar representado neste momento. Desenvolvedores, especialistas em usabilidade, os “inimigos” da infra, os “chatos” dos DBA’s e, claro, o coordenador do projeto. O AN, óbvio, representa o cliente. Mas não como um “advogado do diabo”. Não agora, em que sua principal responsabilidade é *ensinar* para a equipe o problema que deve ser solucionado. O AN apresenta um conjunto de “Fatos”, o problema definido.

Começamos aqui a expandir aquilo que Scott Berkun chama de “Espaço do Problema” :

O início dos debates é marcado por um volume relativamente grande e heterogêneo de idéias. O “espaço do problema” aumenta, como ilustra a figura acima (surrupiada do Berkun). Em determinado momento (que variará bastante dependendo do tipo e complexidade do projeto), o time pára de gerar idéias e começa a agrupá-las. É sugerido que se chegue em 3 alternativas de solução: a mais cara, a mais barata e a coluna do meio, por exemplo. Sugestão: as idéias também são agrupadas em casos de uso.

Os debates, que a partir deste momento podem incluir o próprio cliente (formalmente, via proposta que contemple as 3 alternativas, ou informalmente, na mesa de discussões) visam a redução do número de opções. Gradativamente, por exclusão, ou com o cliente fazendo a escolha de uma das três alternativas apresentadas.

O problema com este enfoque é que, se por um lado está bem claro o que é fundamental ou importante para o negócio, por outro temos pouca visibilidade da complexidade e custo daquelas alternativas de solução. O “parlamento” foi reunido exatamente para suprir tal necessidade. Mas como isso é feito? O próximo artigo apresentará uma sugestão. Inté!

Notas:
1. Mais do que os objetivos ou os atores (e seus objetivos), acredito que o melhor “guia” para o desenvolvimento de requisitos são os próprios processos de negócio. Um dia, num clássico trabalho (The Object Advantage – Addison Wesley (1995)), Ivar Jacobson disse que o “caso de uso é o nosso constructo para um processo de negócio”. Entendo que a análise e modelagem do negócio é indissociável da engenharia de requisitos. Para minha sorte, não estou só.
2. “A Arte do Gerenciamento de Projetos“, de Scott Berkun – Artmed Editora (2008). Pois é, finalmente o grande livro do Berkun é lançado em pt-br. Para nosso azar o livro foi reeditado lá fora, com novo título (“Making Things Happen“) e conteúdo revisto. Quem mandou demorar?
março 19, 2008
Rendiconti: FAN na UFSCar

Sexta, 14/mar 17h15, entrada de São Carlos. No canto esquerdo de um outdoor azul, aparece bem grande: JEE. Sorte que o ônibus está a 10km/hr. Deu tempo de ler na parte de baixo: Jabu Equipamentos Elétricos. A piadinha ‘quebra-gelo’ para o evento do dia seguinte já estava garantida. Breve pausa no hotel. Reconhecimento de terreno agendado para o mesmo dia. Graças ao atencioso Prof. Zorzo. 235alqs., mas está meio escuro. A Universidade está meio vazia. Não importa: já deu para perceber sua imensidão. E o ritmo de sua expansão. De cara, duas obras. Depois, três salas cheias e silenciosas. Duas moças apressadas preparam um coffee-break. No andar de cima um professor encerrando um trabalho “para ontem”. Sensação boa. Ambiente inspirador.

Foto de Juliana Maria (a mulher do ladrão boliviano!), surrupiada do Flickr.

Sabadão. Quase 80 pessoas na platéia. Normalmente elas só têm atividades no período da manhã. Hoje terão que me aturar até o final do dia. Aguentaram. São todos alunos do curso de pós-gradução “Desenvolvimento de Software para Web”. Metade começou esse ano. A outra parte está nessa desde o ano passado. O auditório é grande e confortável. Tem um quadro negro “dobrável” meio assustador. Assusta mais o tamanho da responsabilidade.Sorte minha que detono PM’s, DBA’s, Xispeiros e outros superheróis logo no início do evento. Garante risadinhas, algumas nervosas. Mas até que deu para guardar a piadinha do JabuEE para o período da tarde (o “quebra-gelo” virou “digestivo”). Jornada de 188 slides no trilho, vamos lá…

Desde dezembro eu não apresentava o FAN original – formato “palestrão”. É bem mais cansativo que suas duas oficinas-filhas. Claro, quase não paro de falar. O problema é que o formato também cansa a platéia. Um cansaço diferente, mas cansa. Em um ou outro ponto eu consigo “forçar” alguma interação, mas a turma é curiosamente passiva. Zorzo, logo após o evento: “aluno é sempre aluno”. Compreendo, mas sigo achando que posso corrigir – melhorar alguma coisa. E não são as piadinhas, que funcionam.

Os 3 breaks foram concorridos e variados. De novo, aquele espírito empreendedor que tanto invejo para minhas Minas. Projetos superinteressantes, livres dos vícios burocráticos e daquela verborragia cheia de modismos que impregna outras paradas. O papo com professoras e professores serve para confirmar d’onde vem a maturidade daquele pessoal. E tem gente que não entende porque insisto em não cobrar nada em eventos para Escolas.

A única nota triste aconteceu no 2º break, no almoço. Tive que testemunhar um meliante cometendo uma tremenda covardia com um amigo de Sampa. Não fosse o ambiente tão bom, o cara teria conseguido me estragar o dia. O sujeito não merece. E, por sorte, não estava em meu evento. Espero não revê-lo.

17 horas, apito final. Retorno muito legal – novas fontes de luz no horizonte. Me policio para não fazer deste o texto mais “baba-ovo” da história do finito. Mas o evento na UFSCar é daqueles que ficam tatuados na memória. Agradeço aqui a todos que participaram. Agradeço a valiosa participação da Profa. Dra. Sandra Fabbri e do Prof. Dr. Paulo. E registro minha grande dívida com Reinaldo Castro, que motivou o evento, e com o Prof. Dr. Sérgio Zorzo, que organizou tudo (com valioso apoio da Cristina) e pressionou F5.

.:.

É claro que aquele ambiente não se encerra em seus 235alqs., naquele “ex-fazendão”. A cidade de São Carlos é muito agradável, bela, acolhedora, rica e enriquecedora. Tive pouco tempo para passear, mas fiz minhas caminhadas (nada perto dos 10km rodados em Floripa). No sábado mesmo fiz uma breve pausa no Mosaico, na praça XV de Novembro, bem pertinho de um campus da USP. Quando entrei tocava Sting. Depois samba. Tinha Gil na cidade (e, claro, nenhum ingresso naquele horário). Não vou prolongar a “babação de ovo”, mas devo antecipar uma provocação que destilarei em outro lugar: empresas espertas de Sampa e outros lugares deveriam considerar seriamente a abertura de filiais em São Carlos. Empresas de TI que dependam de talento, qualidade de vida e muita gente boa. Mas, por favor, sem o papo de “fábricas” e afins, ok?

março 17, 2008
Rendiconti: Sampa – Floripa sem Escalas

Na última terça-feira, 26/fev, aconteceu a estréia em evento aberto da oficina “Análise e Modelagem de Negócios“. Organizado pela Tempo Real Eventos, foi realizado em Sampa. Abri a oficina com duas confissões comprometedoras: este módulo, o 1º do programa para Formação de Analistas de Negócios, é um “patinho feio”. Comparado ao seu co-irmão, o módulo “Engenharia de Requisitos“, ele é menos sexy – mais difícil de vender. Como eu disse aos participantes, não conheço a razão. Uma suspeita eu tenho: ainda não reconhecemos a importância dessa macro-disciplina, particularmente em projetos para desenvolvimento de sistemas. Para minha surpresa, 1 hora após o início do evento a sala estava completamente lotada. Gelo no abdomem.

É que minha segunda confissão era ainda mais perigosa: briguei com 3 conjuntos de exercícios e não gostei de nenhum. Cheguei para a oficina sem um conjunto pré-definido de exercícios. Explico minha dificuldade: preciso que os participantes tenham alguma “intimidade” com o negócio – conheçam seus objetivos e, particularmente, seus problemas. Inventei uma indústria, uma empresa de serviços e uma locadora de DVD’s. Nenhuma me deu a segurança necessária para a execução dos exercícios. Como o programa é extenso, temia gastar muito tempo explicando o negócio e não os conceitos e práticas que formam os verdadeiros objetivos da oficina. Resolvi desenvolver apenas alguns exemplos (ramo Seguros), para reforçar cada tipo de modelo gerado. E pedi que os participantes executassem os exercícios se baseando em sua empresa ou em algum cliente. Acabou funcionando acima de minhas expectativas. Agora espero descobrir uma maneira de fazer com que os ricos exemplos sejam compartilhados entre todos os participantes. Ao contrário da oficina Engenharia de Requisitos, todos os exercícios foram individuais.

Três dias depois, outra estréia: o 1º evento aberto longe do estado de São Paulo. Organizada pela Innovit, a oficina aconteceu na bela Floripa. O Claudio Kerber, frequentador assíduo e ativo deste espaço, participou com outros 11 colegas de empresa! Uma empresa de Blumenau* também enviou um grande número de pessoas. Ainda assim o público era bastante heterogêneo, fator que sempre enriquece os eventos. Resumindo: o evento obteve uma avaliação média de 3.41 pontos, de um máximo de 4. Espero que o resultado para todos seja o mesmo que o Kerber já manifestou neste espaço. E, claro, espero rever todo mundo na próxima oficina, dia 28/mar.

* Exceto quando necessário ou autorizado, não me sinto confortável para divulgar os nomes das empresas participantes.

.:.Na 1ª turma da oficina Engenharia de Requisitos eu não distribui apostilas. Pedi que os participantes recebem apenas um bloco e uma caneta. Como alguns “chiaram” (com razão), a 2ª turma recebeu uma versão editada da apostila (sem os exercícios – o efeito “surpresa” é fundamental para a execução dos exercícios propostos). Novo acidente: os exercícios foram transcritos nas páginas brancas da apostila. Como eu recolho parte deles, para avaliação posterior, teve gente perdendo valiosas páginas de suas apostilas. Céus! Era só uma questão de pensar e planejar um cadinho, né?Pois bem, as duas turmas da semana passada participaram de outra estréia: os avançados Notebooks finito… (rs). Tem um “especialista” para cada tipo de exercício. Abaixo uma imagem daquele que utilizamos para os exercícios de modelagem:

Para os exercícios de prototipação, executados principalmente na oficina Engenharia de Requisitos, foi desenvolvido um modelo um pouquinho diferente: Mas, falando um pouquinho mais sério, o notebook mais valioso será aquele especializado na especificação de casos de uso, de uso intensivo na oficina Engenharia de Requisitos: Créditos: a provocação (que derrubou a ficha em meu cabeção) foi do Cacá Vasconcellos, a arte final é do Guz Vasconcellos. Os dois são da Opção Artes Gráficas, daqui de Vga (é claro). Tks!

março 5, 2008
EPBE: Um Meta-Modelo Básico
No meio da enésima revisão do material para as oficinas da próxima semana* descobri que naquela pequena série sobre a EPBE (Eriksson-Penker Business Extensions – uma extensão da UML para modelagem de negócios) eu ignorei um de seus elementos mais “vendedores”: o seu meta-modelo. Como eu também não cumpri a promessa de compará-la a outras alternativas (não conclui o estudo… ainda), vale a pena mostrar e descrever o “modelão”.

E forçar a comparação. Não tanto com a BPMN que, como o próprio nome indica, serve apenas para a modelagem de Processos de negócio. Mas, principalmente, com aquela míope visão de modelagem de negócios proposta no RUP*. Direto ao modelo:

Serei redundante, mas acho legal fazer uma leitura do modelo. Uma porque meus rabiscos nem sempre são legíveis. Mas também porque nem todos que aqui pousam conseguirão entender o diagrama (de classes – UML, é claro).

Um objetivo de negócio é alcançado através de um ou mais processos de negócio. Objetivos expressam o estado desejado de um determinado recurso. Por exemplo: ~~Lucro é um recurso (uma coisa abstrata!)~~. Lucro é o estado desejado de um recurso que, por questões de simplificação, chamaremos de Caixa (uma conta contábil – um recurso abstrato). Aumentar o lucro em 10% é um objetivo de negócio. Alguns objetivos também podem ser expressos na forma de regras de negócio.

Uma regra de negócio governa ou controla um ou mais processos de negócio. Por exemplo: o desconto de 5% só pode ser concedido em transações de valor igual ou superior a R$100. A regra em questão delimita o processo de vendas. Mas as regras de negócio também podem ser aplicadas a recursos: não será emitida a conta mensal se o valor total da fatura for menor que R$ 10; sendo assim, o valor deve ser acumulado para o mês seguinte. Neste exemplo a fatura é um recurso abstrato.

Os recursos são criados, refinados, consumidos, modificados ou simplesmente utilizados pelos processos de negócio. Exemplificando: o processo de vendas é realizado por vendedores (recurso abstrato); gera uma nota fiscal (recurso abstrato); aumenta o caixa da empresa (idem) e reduz o estoque (recurso abstrato) de determinados produtos (recursos físicos). Um processo causa uma mudança de estado que afeta determinado recurso. A redução do estoque, por exemplo, é uma mudança de estado.

Processos de negócio também geram eventos, e são afetados por estes. Seguindo no exemplo anterior, aquela redução de estoque gerou um evento que é disparado quando um produto está prestes a atingir a quantidade mínima aceita. Este evento afeta outro processo de negócio, o processo de reposição de estoque (ou compras).

Esta descrição espicha um pouco aquela definição publicada anteriormente em “EPBE: Introdução“: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras.

Insisto: a EPBE consegue ser simples e robusta, completa, ao mesmo tempo.

Observação importante: o diagrama acima é apenas um meta-modelo básico. Surrupiado da página 65 de “Business Modeling with UML“, de Hans-Erik Eriksson e Magnus Penker, sofreu ainda algumas ‘reduções’. E um complemento mal definido: aquela “meta” não existe na proposta original. Vincularei ali metas e indicadores levantados, por exemplo, em Balanced Scorecards e Mapas Estratégicos. Não utilizei uma variação dos próprios objetivos (possível – vide o auto-relacionamento) para destacar um tipo diferente de requisito de negócio. Mas isso é papo para outro artigo. Fico devendo também um que trate exclusivamente das regras de negócio. Papo bom.

.:.

* EPBE é uma linguagem, uma ferramenta. Seu uso não exige a adoção deste ou daquele processo. Ou seja, se você utiliza o RUP (ou qualquer variação dele, inclusive o OpenUP), pode enriquecer muito os seus projetos com a adoção da EPBE. Uma breve justificativa: aquela visão proposta no RUP, que fala de casos de uso de negócio (BUC’s) e derivados, é míope porque trata o negócio como uma “caixa preta” (assim como os casos de uso de sistema tratam este como uma “caixa preta”). O problema deste enfoque é que olhamos exclusivamente a interação do negócio com o ambiente, com os atores. Uma completa análise e modelagem de negócios só ocorre quando “olhamos” dentro do negócio também, e não só as suas interações. Normalmente as interações são só a ponta do iceberg.A EPBE é apresentada de forma mais detalhada na oficina “Análise e Modelagem de Negócios“. Duas turmas acontecem na próxima semana:
- 26/fev (terça), em São Paulo (Tempo Real Eventos)
- 29/fev (sexta), em Florianópolis (Innovit)
fevereiro 19, 2008
Estruturando Requisitos – Parte 2
No artigo anterior vimos a estruturação de requisitos em 4 níveis (ou tipos). Hoje mergulharemos um pouco mais no desenho, mostrando atributos que devem caracterizar todos os requisitos. Para isso vamos pegar todos os tipos de requisitos…

… e tratá-los como uma coisa (!) só:

Apresentarei os atributos em sentido anti-horário, começando pelo Tipo. O Tipo aparece aqui apenas para fins ilustrativos. A informação já apareceu no diagrama anterior. Um requisito sempre terá um dos seguintes tipos:
- Um objetivo do Negócio;
- Objetivos ou metas mais específicos, atribuídos a um único processo de negócio;
- Um requisito do Usuário;
- Um requisito Funcional; ou
- Um requisito Não-funcional.
Todo requisito possui uma única Fonte. Trata-se da pessoa que manifestou aquela necessidade. Em alguns casos bastará o registro do nome. Outros podem preferir uma ficha mais completa, com cargo, departamento, formas de contato etc. De qualquer maneira, o Ponto de Vista desta pessoa deve ser registrado em separado. É uma informação que ajuda muito no processo de tomadas de decisão sobre o escopo do projeto, por exemplo. No nível mais simples e genérico, o Ponto de Vista pode ser:
- Estratégico: é o dono do negócio, ou a alta direção. Desnecessário dizer que, na maior parte das vezes, seus requisitos têm um peso consideravelmente maior que os demais.
- Tático: é um gerente, coordenador ou supervisor. Ou seja, todo o escalão que fica entre a alta direção e o pessoal
- Operacional: que é quem realmente executa o trabalho. É interessante alertar que, dependendo do projeto, esses três níveis podem ser usuários do sistema. Esta delimitação aparecerá de maneira mais clara nos Casos de Uso. Além deles há também um 4º ponto de vista, o
- Técnico: que pode representar, por exemplo, o pessoal de TI da empresa. Neste caso, eles são a origem de muitos requisitos não-funcionais. Sobre arquitetura tecnológica, por exemplo.
Não é bom confundir a estrutura com o processo de desenvolvimento dos requisitos, mas aqui cabe uma exceção. É muito importante que, no momento do registro de um requisito, a Fonte indique qual é o Grau de Importância que ela lhe atribui. Neste ponto estamos distantes do processo de priorização, mas esta informação será de muita relevância lá e em várias outras decisões tomadas pela equipe no decorrer de um projeto. Por isso é importante que esta classificação seja simples e objetiva:
- Fundamental: ou seja, o projeto será considerado falho se este requisito não for atendido. Soou um tanto “dramático” mas é assim mesmo que estes requisitos devem ser vistos: cruciais para o sucesso do projeto.
- Importante: o cliente não abre mão da implementação deste requisito, mas saberá aguardar sua satisfação caso o projeto enfrente algum problema ou se surgirem outros requisitos Fundamentais no meio do caminho.
- Opcional (ou Acessório): como o próprio nome indica, a não satisfação deste requisito não comprometerá em nada o projeto. São os tradicionais “badulaques” (ou “perfumaria”) que devem ser relegados para quinto plano (dos infernos) tão logo o projeto tenha seus prazos desafiados. Falando sério: há um lugar muito nobre para requisitos não satisfeitos. Uma seção do documento de visão chamada “Idéias para Versões Futuras”.
Os dois últimos atributos, ao contrário dos anteriores, nascerão ou serão amadurecidos em momentos posteriores ao registro do requisito. O primeiro deles é o auto-relacionamento entre os requisitos (representado pela elipse no canto inferior direito da classe Requisito no diagrama acima). Faz parte da análise de requisitos, além da validação de sua acuracidade, o “confronto” com outros requisitos. Existem 4 tipos de relacionamentos possíveis:
- Dependência: por exemplo, “a satisfação do requisito ‘A’ depende da satisfação do requisito ‘B’”. Esta relação pode ser descoberta bem cedo no ciclo de um projeto, mas é mais comum que ela só seja percebida no momento do desenho da solução.
- Complementariedade (ou Facilitação): “a satisfação do requisito ‘A’ é facilitada pela satisfação anterior do requisito ‘B’”. Na relação de dependência, se o requisito ‘B’ não for satisfeito, torna-se impossível a realização do requisito ‘A’. Aqui apenas indicamos que se o requisito ‘B’ for atendido antes, a satisfação do requisito ‘A’ é facilitada. No entanto, em ambos os casos estamos indicando claramente uma seqüência de desenvolvimento.
- Substituição: pois é, assim registramos uma mudança. Afinal, uma mudança nada mais é do que um requisito “atrasado”. É uma boa prática a decisão de nunca “deletar” um requisito. Assim mantemos todo o histórico de um projeto. Por isso é necessário que registremos toda e qualquer alteração sofrida por um requisito como um novo requisito, que *substitui* o anterior.
- Conflito: sendo direto, “a satisfação do requisito ‘A’ impede a realização do requisito ‘B’”. Ou seja, é obrigatória uma tomada de decisão: qual requisito será excluído do escopo do projeto? É o primeiro ponto em que a informação sobre o Ponto de Vista da Fonte do requisito pode ser útil: qual pesa mais? A exemplo dos demais tipos de relacionamentos, as vezes um Conflito só é detectado em estágios avançados do projeto. No entanto, assim como os riscos e bugs, quanto antes eles forem identificados, melhor. Aliás, ele é um bug!
Por fim temos o Status do requisito. Registramos aqui o seu ciclo de vida. Todos nascem com o estado “Pendente”. Após um primeiro ciclo de validação eles são “Aprovados” ou “Recusados”. Os “Aprovados”, no decorrer do projeto, podem assumir 1 de 3 estados possíveis: “Substituído”, “Excluído” ou “Implementado”. Nos dois primeiros encerrou-se o ciclo. Aos “Implementados” falta um último estado: “Verificado”. Consideramos que todos os requisitos marcados como “Veficados” estão devidamente satisfeitos. Esta seqüência pode ser estendida, para contemplar eventos e resultados de testes, por exemplo.

.:.

Assim encerramos o “básico do básico” sobre estruturação de requisitos. Estranho, mas se trata de um “básico” que raramente percebemos em projetos e até mesmo nas ferramentas utilizadas para o gerenciamento de projetos (ou de requisitos).Sim, a estruturação proposta resulta em um grande volume de informações. Mas, na realidade, o que ela faz é nos dar a exata noção da quantidade de informações que lidamos ao desenvolver e gerenciar requisitos. Tais informações já existem em qualquer projeto. A diferença aqui é que elas não ficam “soltas”. Não há burocracia nem redundância. Os modelos propostos consideraram apenas as informações mínimas necessárias para uma correta e precisa engenharia de requisitos.

Encerrei o artigo anterior prometendo falar sobre análise e rastreabilidade dos requisitos. A análise, apesar de não explicitamente descrita, está na apresentação de todos os atributos dos requisitos. O registro de cada um deles é resultado da análise. Aliás, isso é Análise de Requisitos.

Já a rastreabilidade ficou implícita, escondida nos dois diagramas apresentados. Imaginando os modelos como uma base de dados, não é fácil perceber como podemos “rastrear” os requisitos “na vertical e na horizontal”? Um breve checklist (surrupiado do SEI – Software Engineering Institute):
- Qual meta ou objetivo de negócio é atendido pelo requisito?
- Este requisito é realmente necessário?
- Como eu devo interpretar este requisito?
- Quais decisões de projeto afetam a satisfação deste requisito?
- Qual teste de aceitação será utilizado para validar o requisito?
- Qual o impacto gerado pela mudança deste requisito?
- Todos os requisitos foram atendidos?
- O projeto acabou??
Para encerrar, uma provocação (sem ironia) ao amigo agilista. Saca só o segundo diagrama. Troque “Requisito” por “User Story”. E se usarmos as cores dos post-its para diferenciar os tipos de requisitos? Fica bem legal, não acha?
fevereiro 12, 2008
Estruturando Requisitos – Parte 1
Não é fácil explicar, mas problemas com “requisitos” seguem respondendo por grande parte das falhas e atrasos em projetos. Um estudo recém publicado pelos Capítulos Brasileiros do PMI mostra que entre os principais problemas enfrentados, 62% refere-se à mudanças em requisitos e 60% tem a ver com a (má) definição destes. Quando olhamos especificamente para projetos do setor de TI, os números sobem para 83% e 81%, respectivamente. Publiquei no Graffiti um artigo comentando o estudo. Aqui vou apresentar uma idéia que pode ajudar a reduzir os problemas com requisitos.

Trata-se de uma idéia “requentada”. Há 5 anos ela foi o núcleo do primeiro trabalho que apresentei em público, no Seminário de Gestão de Projetos promovido pela SUCESU-SP e pelo PMI. Requentada não, amadurecida. Ela é uma das partes principais de meu trabalho para Formação de Analistas de Negócios. Além da experiência, utilizei os trabalhos de Karl Wiegers e de Suzanne e James Robertson para chegar no desenho que apresento abaixo. Neste último livro, publicado em 2005, conheci o Volere e o Requirements Knowledge Model, propostas que reforçaram minha idéia sobre a Estruturação de Requisitos.

Para começar, vale a pena revisar a definição de requisitos e seus tipos. Em levantamentos informais que realizo nos cursos e oficinas descobri que a definição mais comum para requisitos é: “uma necessidade do cliente ou usuário”. Correta, mas não explica bem a amplitude e heterogeneidade dessas “necessidades”. Uma das melhores definições para requisitos foi criada por Ian Summerville e Pete Sawyer em Requirements Engineering – A Good Practice Guide :

Requisitos são… uma especificação do que deve ser construído. São descrições de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Podem ser uma restrição ao processo de desenvolvimento.

O diagrama acima ilustra todas essas possibilidades. Começamos pelos Objetivos do Negócio. Normalmente eles são os primeiros requisitos que recebemos. Infelizmente, também são os primeiros que esquecemos no decorrer de um projeto. Mas isso fica para outro artigo. Esses objetivos podem ser “quebrados” em objetivos mais específicos, ou metas, que vinculamos diretamente a Processos de Negócio. Por exemplo: “reduzir em 10% os custos de vendas é uma meta colocada para o processo de vendas”; um requisito que deve ser atendido pelo projeto. O diagrama também mostra que as Regras de Negócio são vinculadas aos Processos de Negócio. O destaque se faz necessário porque é comum a confusão entre requisitos e regras de negócio. E se torna ainda mais relevante quando percebemos que as regras são muito mais voláteis (passíveis de mudanças) do que os requisitos. Exemplificando: “nas operações de vendas o sistema deve permitir a aplicação de um desconto sobre o valor total da transação”. “O desconto máximo de 10% só pode ser aplicado em vendas superiores a R$ 100,00”. A primeira frase é um requisito funcional. A segunda, uma regra de negócio. A chance da segunda mudar é muito maior.

Na seqüência temos os Requisitos do Usuário, solicitações que podemos quebrar em vários Requisitos Funcionais. Esta classificação, originalmente proposta por Karl Wiegers , gera uma certa confusão. Um Requisito de Usuário é de alto nível. Por exemplo: “Emitir uma Nota Fiscal”. Reparem no diagrama acima: um Requisito do Usuário pode se transformar em um Caso de Uso. Pode. Acontece que nem todo requisito é incorporado ao Escopo do Projeto; Foi uma idéia que, por algum motivo qualquer, foi abandonada em determinado momento.

Os Casos de Uso nos ajudam a agrupar logicamente os Requisitos Funcionais. Estes são, portanto, as “menores unidades de solicitações” dos usuários ou clientes. Existe muita confusão neste ponto porque o nível de detalhamento dos requisitos funcionais varia muito, entre organizações e até mesmo entre projetos de uma mesma empresa. Pior: o nível pode variar até mesmo em um mesmo projeto. Não há receitinha mágica aqui. Fábricas normalmente optarão pelo maior nível de detalhamento possível. Equipes mais experientes (ou exigentes) brigarão por espaço para sua “criatividade”, ficando satisfeitas com requisitos definidos em nível mais alto. Em um processo iterativo e incremental, não raro os analistas descobrirão que alguns requisitos funcionais, dada sua superficialidade, se transformarão em requisitos de usuário (e, consequentemente, em novos Casos de Uso), exigindo assim seu maior detalhamento.

Por fim, no lado direito do diagrama, temos os Requisitos Não-Funcionais. Apenas para fins de ilustração aparecem duas especializações: Arquitetura (Tecnológica) e Restrições. Dependendo da organização ou projeto, essa estrutura pode ser modificada de forma a receber outros conjuntos específicos de requisitos não-funcionais. Este grupo e os casos de uso dão forma ao Escopo do Projeto.

.:.

O diagrama acima ilustra o núcleo de uma Base de Conhecimentos para um projeto específico. Gosto de apresentá-la como uma forma de se ver, analisar, desenvolver e gerenciar requisitos. Em projetos de médio e grande porte, ou ainda em empresas que lidam com vários projetos simultâneos, a criação desta base como um banco de dados pode significar um grande avanço em todas as atividades de engenharia de requisitos (desenvolvimento e gerenciamento de requisitos). Na parte 2 deste artigo apresentarei outra parte da base, que trata especificamente dos atributos dos requisitos.Quando discutimos ferramentas para o desenvolvimento e gerenciamento de requisitos, como aconteceu na última oficina, sempre surge a questão sobre o melhor front-end para esta base de conhecimentos. Costumo dizer que nunca vi um front-end melhor do que uma ferramenta CASE, aquela que uso para elaborar os diagramas UML. Há muito tempo vi uma versão do Together que implementava algo parecido. Há mais tempo ainda participei do desenvolvimento de um add-on para o Rational Rose (a implementação foi feita, em VB(!), pelo grande Nelson Ponce de Leon). Simplifica muito o trabalho do analista: um clique com o botão direito do mouse em qualquer elemento UML apresentava a opção Requisitos. Lá podíamos inserir novos ou então ver todos os requisitos vinculados a determinado artefato. A rastreabilidade era total: íamos dos casos de uso e atores até métodos e propriedades de determinada classe. Infelizmente a ferramenta ficou por um tempo esquecida. Felizmente (!) alguns colegas do grupo Analistas de Negócios.br estão trabalhando no desenvolvimento de uma nova versão. Não é difícil perceber que um banco de dados faz muito mais sentido do que documentos Word, planilhas, matrizes imensas (olá Requisite Pro!), post-its ou “papel de pão”. A próxima parte do artigo tentará reforçar isso, falando de análise e rastreabilidade total dos requisitos. Inté.

.:.

Bibliografia:
1. Software Requirements
  Karl Wiegers. Microsoft Press (1999).
2. More About Software Requirements
  Karl Wiegers. Microsoft Press (2006).
3. Requirements-Led Project Management
  Suzanne Robertson e James Robertson. Addison-Wesley (2005).
4. Requirements Engineering – A Good Practices Guide
  Ian Sommerville e Pete Sawyer. Wiley (1997).
fevereiro 11, 2008
Rendiconti: A Primeira Oficina de 2008

Aconteceu no último dia 31/jan a primeira oficina de 2008, Engenharia de Requisitos, promovida pela Tempo Real Eventos. Como era ante-véspera de festança, o número de participantes surpreendeu: 53, contando os 5 monitores*. Era a segunda edição do evento, o que sempre me deixa um pouco grilado. Como a primeira edição foi muito legal, temia a tradicional “síndrome do segundo”. Felizmente os acidentes foram adiados para a terceira edição. Correu tudo bem, apesar das novas instalações e da configuração das cadeiras.

Como uma edição é muito pouco para tirar qualquer conclusão sobre um evento, mantive quase 100% da estrutura do evento de dezembro. Apenas acrescentei alguns slides, reforçando pontos sobre casos de uso e o documento de visão. Não mexi nada nos exercícios. A diferença é que esta turma não ‘cabulou’ o último exercício – a elaboração de um curto documento de visão. Só neste ponto eu contei para a turma que havia uma competição entre os 5 grupos formados. “Confisquei” parte dos exercícios (protótipo, estimativas e documento de visão) prometendo dizer aqui qual fornecedor eu escolheria.Pelo poder de concisão, pelo “pé-no-chão” (da estimativa) e pela excelente qualidade do protótipo, o grupo vitorioso é o da monitora Socorro Cavalcante. O grupo liderado pelo monitor Fernando Salla fica com um honroso segundo lugar: faltou um pouco de cuidado com o protótipo, só isso. A grande maioria dos participantes “cravou” bom e ótimo nos critérios de avaliação. Alguns depoimentos, disponíveis no site da Tempo Real, mostram bem como foi a recepção do evento:

“Treinamento agrega um conhecimento valioso da disciplina Requisitos”
Elisângela Margaris, São Paulo, SP
Gonow Tecnologia

“Foi um evento dinâmico e fantástico; rico em detalhes”
Marco Moribe, São Paulo, SP
CETESB

“Trabalha na realidade do mundo, na construção do software. Muito bom!”
Daniel Duarte, São Paulo, SP
Compuware

Este último depoimento me deixa até um pouco sem jeito. Explico: de uma maneira meio desastrada e sem tato eu dei uma “detonada” geral em ferramentas para gerenciamento de requisitos. Claro, sobrou para a Compuware. Não tanto quanto sobraria para um eventual representante da IBM/Rational, mas sobrou. De qualquer maneira, espero que os comentários que faço sobre essas ferramentas sejam bem recebidos. Um motivo para tal foi validado na própria turma: só 3 dos 53 participantes utilizam algum tipo de ferramenta para requisitos. Há alguma coisa errada, não? Requisitos não respondem por 80% das falhas em projetos? Apesar do assunto “ferramenta” não ser minha praia, no próximo artigo falarei um pouco mais sobre isso.

Agora, pedindo licença para todos que elogiaram o evento, preciso tratar de duas avaliações ruins que recebi. Com um aviso importante: recebo apenas uma compilação das avaliações, com alguns destaques. Mas nunca vejo o nome ou empresa do participante. E duas críticas mereceram destaque.

A primeira fala que não viu “nada de novo”, que o evento “não tem nada de inovador”. Achei curiosa por dois motivos. Primeiro, em nenhum lugar é prometido um evento inovador, um conjunto de técnicas ou métodos “novinhos em folha”. Minha proposta reforça práticas e processos amplamente reconhecidos como fatores de sucesso em um projeto. Deixando a modéstia de lado, se estou falando algo “novo” é realmente o conjunto: a compilação de técnicas e idéias; E uma certa insistência em uma maneira estruturada de se desenvolver e gerenciar requisitos (tema de meu próximo artigo). Mas o que eu queria de verdade era a chance de conversar com esse participante. Entender suas necessidades e qual era sua expectativa quando se inscreveu no evento.

A outra crítica já apareceu em eventos FAN (mais teóricos), mas é a primeira vez que pinta na oficina: “faltou profundidade”; pior, “o palestrante se esquivou de questões complexas”. Me lembro de, em dois momentos, mudar de assunto. Explico: o limite de tempo é claro. E neste último evento era pior ainda: a sala receberia outro evento logo depois do meu. Mas, por isso mesmo, sigo disponível para quem quiser conversar comigo logo após o evento. A coisa mais fácil do mundo é “perder” um evento por dar atenção demais para um tema específico. De uma maneira geral, cada tema tem 30 minutos de “teoria” e outros 30 de prática – tempo que julgo suficiente para tirarmos as dúvidas mais comuns. Todo mundo sabe: tem gente que vai neste tipo de evento para tentar descobrir algo que atenda um problema corrente em sua empresa ou projeto. Não posso atender um participante desconsiderando outros 50! Não durante o evento.

Mas, no final das contas, o que este tipo de crítica faz é gerar novas idéias. Por exemplo, que tal uma “Versão Avançada” da oficina de Engenharia de Requisitos? Antes disso, é importante ressaltar: um evento, mesmo que durando um dia todo, nunca é suficiente. Este tema particularmente é muito extenso e “espinhoso”. Taí uma das utilidades deste blog e do grupo de discussão que foi criado exclusivamente para os participantes das oficinas: caramba, o que não deu pra ver lá no evento pode ser debatido depois, certo? Então… manda bala!

.:.* O que seria da oficina não fossem meus caros monitores? De novo, recebi a ajuda de 5 pessoas muito legais. Fica aqui meu agradecimento para Socorro Cavalcante, Fernando Salla, Gilberto Valente, José Carlos Santos e Raphael Albino. Vocês foram 10! E alguns ainda tiveram que “brigar” com seus fornecedores?!? hehe.. Valeu!

fevereiro 7, 2008
FAN no Sul, Modelagem de Negócios e outras novas [Atualizado]

Atualização em 15/jan: Link que faltava para o evento “Análise e Modelagem de Negócios”.

Antes de mais nada: que 2008 seja um ano muito jóia para todos, cheio de realizações. E, principalmente, de muita paz e saúde.

Em 2008, finalmente, o FAN (Formação de Analistas de Negócios) começa a ultrapassar as fronteiras de São Paulo. RJ e PA* estão na mira, mas a “estréia” acontecerá na Região Sul, mais precisamente na belíssima Florianópolis.

A colega, promotora e organizadora, será a Innovit. E o evento chegará em seu formato completo, ou seja, dividido em dois módulos. O primeiro é “Análise e Modelagem de Negócios“, programado para o dia 29/fev.

No dia 28/mar (um dia após o lançamento oficial do livro) acontece o “Engenharia de Requisitos“. Floripa receberá o novo formato do FAN, desenhado para ser extremamente prático. As oficinas (conhecidas como ‘workshops’ antes daquela proposta do deputado) são compostas assim: 50% de teoria e 50% de exercícios. Os ares de Floripa farão muito bem ao conteúdo. Espero retribuir da melhor maneira possível.

.:.

Mas Sampa segue Sampa e, claro, eu sigo por lá. No próximo dia 31/jan acontece a 2ª turma da oficina “Engenharia de Requisitos”. Via Tempo Real Eventos, como sempre.

E a estréia da oficina “Análise e Modelagem de Negócios” ocorrerá em São Paulo, dia 26/fev.

Como a turma que passeia por aqui já sabe, esta é a parte mais “polêmica” da Formação de Analistas de Negócios. Há aqueles que pregam que essa atividade ocorra ANTES de um projeto de TI. E, mais ainda, que não seja uma responsabilidade da área de TI. Procuro mostrar neste evento que não é bem assim. E traço o limite que separa a Análise e Modelagem de Negócios de iniciativas de reengenharia e afins. O objetivo aqui, para dizer de maneira bem resumida, é a compreensão do problema, o entendimento do negócio. O programa do evento está nesta página.

.:.

Bye Bye, Blogger

Pois é, este é o penúltimo post do finito neste espaço. Passou da hora dele ter um espaço um pouco mais “nobre”. E bem mais rico. Estou maravilhado pelo WordPress e portando todo o blog para um domínio próprio. Todo o histório de quase 4 anos será transportado para lá. Mas eu não desativarei este endereço tão cedo. Acontece que o Google favorece seus endereços em alguns casos. Mas.. penúltimo? Sim. O último será a comunicação dos novos endereços. Novos? Pois é, terei variações de feeds RSS por assunto (categoria). Por isso serão vários endereços. Mas prometo uma transição tranquila.

.:.

* Região Sul, Rio, Pará. Gostaria muito de descobrir também um parceiro no nordeste. No próximo dia 31, por exemplo, terei um participante da Microsoft de Recife! Pô, ele gastará mais com avião e estadia do que com o evento.

Mas, o que mais me chateia é a confirmação de que “santo de casa não faz milagre”. Não tenho nada programado para minha querida terra natal, Minas! E olha que, tirando São Paulo, é o estado que mais participa dos eventos. Já tive gente de BH, Uberlândia, Lavras, Santa Rita do Sapucaí e Alfenas nos eventos. Pena, mas seguirei procurando um bom parceiro mineiro.

.:.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

janeiro 14, 2008
EPBE: Processos de Negócio
3ª parte da série sobre EPBE (Eriksson-Penker Business Extensions). A série começou com “EPBE: Introdução” e seguiu com “EPBE: O Negócio e sua Estrutura“. Para um melhor aproveitamento do artigo, talvez seja interessante a leitura de outro pequeno artigo: “Processos de Negócio: São Todos Iguais?“. Eles não são (iguais), e cada um pode demandar estudos e modelos bastante diferentes. Ao contrário do que ocorre em algumas proposições, como BPMN por exemplo, a EPBE oferece toda a flexibilidade necessária para a correta e completa modelagem de processos de negócios.

.:.

A visão dos processos de negócio é a mais complexa das 4 visões propostas na EPBE. É aquela que demandará mais trabalho do Analista de Negócios (AN). Claro, ela é o núcleo da modelagem de negócios. No artigo anterior foram apresentadas a visão do negócio e a visão da estrutura. Ao modelar processos, damos sentido para aquelas vistas, explicando como os recursos (visão da estrutura) são consumidos, utilizados e gerados para satisfazer os objetivos do negócio (visão do negócio).

Na EPBE, utilizamos um Diagrama de Processo para a representação básica de um processo. Veja a imagem acima: trata-se de uma extensão (um tanto radical) do diagrama de atividades da UML. Indicamos nele todos os principais recursos utilizados ou gerados, diferenciando-os através de estereótipos (Info, Físico, Pessoa). Se a visão da estrutura foi corretamente desenvolvida (em uma ferramenta CASE), todos os recursos estão disponíveis na forma de “classes”. Ou seja, ao elaborar o diagrama acima, o AN simplesmente “arrasta” para o diagrama todos os recursos consumidos, utilizados ou gerados por um determinado processo.

Há outro estereótipo no gráfico acima: Objetivo. São informações que foram obtidas no desenvolvimento da visão do negócio. Todo processo, por definição, possui (ou deveria possuir) objetivos bem claros. Mas, neste ponto, podemos ser mais específicos. Como sugerido anteriormente, podemos atrelar ao processo metas, indicadores e iniciativas planejadas na elaboração de Balanced Scorecards e Mapas Estratégicos. Ao formalizá-las em um diagrama de processos, o AN está registrando os primeiros requisitos de um projeto, por exemplo.

Se o projeto exigiu uma análise mais profunda do processo de negócio, também é neste diagrama que registramos os principais achados. Repare na figura do Processo: 4 atributos representam algumas características básicas de um processo. No exemplo acima, Tempo de Ciclo, Custo, Eficácia e Eficiência. Se o projeto demandar, o AN pode desenvolver um diagrama que retrate a situação atual do processo (“as is”) e outro que aponte o cenário desejado (“to be”).

No entanto, como aprendemos com Goldratt (depois de vários outros), melhorias locais podem gerar desastrosos efeitos colaterais em outras partes do negócio. Um processo de negócio sempre se relaciona com outros. Por isso, o AN desenvolve mapas que mostram a interação entre processos. São derivações do diagrama acima, que podem inclusive mostrar as áreas envolvidas.

O diagrama acima pode ser utilizado tanto para a elaboração de um grande mapa de processos quanto para o detalhamento de um processo específico. Neste caso, a figura (estereótipo) que representa um processo (o pontiagudo hexágono) é utilizada para representar partes menores do processo, um sub-processo, atividade ou tarefa (dependendo do nível de detalhamento necessário).

.:.

É raro encontrar um processo de negócio que não esteja minimamente amparado por sistemas de informação. Um AN não pode ignorar a influência dos sistemas existentes, mesmo quando um projeto tratar exatamente da substituição destes. Utilizamos então outra variação do diagrama de processos para ilustrar a relação de um processo com os sistemas. Trata-se do Diagrama de Linha de Montagem (Assembly-line):

No exemplo acima estão representados o processo e dois sub-processos (ou atividades, não importa). As “linhas de montagem”, representadas por pacotes da linguagem UML, são os sistemas. Os pequenos círculos brancos representam informações fornecidas pelas aplicações. Os círculos escuros são as informações geradas e “gravadas” pelo processo. Assim, de uma maneira bem simples, mostramos como o processo está automatizado atualmente.

Trata-se de um momento muito importante para o AN. Atenção para as elipses entre o processo e as “linhas de montagem”. São Casos de Uso. Se estiver executando uma engenharia reversa, por exemplo, o AN começa aqui o desenvolvimento de requisitos.

.:.

Os três diagramas apresentados acima, como tudo na EPBE (e na UML), não são mandatórios. São ferramentas que auxiliam na compreensão dos processos de negócio e dos requisitos de um projeto. Todos eles são, de certa forma, de “alto nível”. Ou seja, não representam os detalhes da execução de um processo. O menor bloco de construção de um processo de negócio, sua única parte indivisível, é a tarefa. Vários tipos de projetos exigirão que o AN analise e modele um processo no nível “mais baixo” possível. Para tanto, é difícil fugir do nosso velho e bom fluxograma.

Na EPBE utilizamos o diagrama de atividades tradicional da UML. Se necessário, podemos estendê-lo para fornecer informações coletadas nos diagramas desenvolvidos anteriormente, como metas, recursos específicos (e críticos) etc. Outra alternativa, dependendo do projeto, é a utilização da BPMN. Trata-se do único ponto em que BPMN substitui um diagrama da EPBE.

.:.

Um projeto pode exigir um estudo ainda mais minucioso da dinâmica de uma organização, do comportamento de recursos e / ou processos. Para tanto, o AN lança mão da 4ª e última visão (básica) proposta pela EPBE: A Visão do Comportamento do Negócio. Não está no escopo desta série o detalhamento desta visão. Mas vale a pena citar que entre seus principais diagramas estão: Diagrama de Estado, Diagrama de Seqüência, Diagrama de Comunicação (muito parecidos com os originais da UML) e variações dos diagramas de Processo e Linha de Montagem.

.:.

O principal objetivo desta série, que se encerra aqui, era apresentar o básico da EPBE. Espero que, no mínimo, a adoção da EPBE seja mais debatida. É importante reforçar dois pontos: i) UML já é um padrão de facto para a modelagem de sistemas. Reaproveitar o investimento em ferramentas e treinamento faz muito sentido. Adotar um padrão único para a modelagem do negócio e de sistemas faz mais sentido ainda; ii) BPMN e afins não são suficientes para uma completa e correta modelagem de negócios.

.:.

Notas:
1. “A Meta” – 2ª Edição, Eliyahu Goldratt e Jeff Cox. Nobel (2002).
  Considerei seriamente colocar algumas pitadas de TOC (Teoria das Restrições) em meu trabalho para a formação de AN’s. Queria, particularmente, desenvolver algumas extensões para a EPBE. Talvez o cronograma não permita. Mas fica aí o desafio e um requisito do tipo “idéias para implementações futuras”.
.:.
dezembro 20, 2007
EPBE: O Negócio e sua Estrutura
Finalmente a continuação da série que começou em “EPBE: Introdução“. Neste artigo vou apresentar duas das quatro visões propostas: a Visão do Negócio e a Visão da Estrutura. Lembrete importante, não mencionado no capítulo anterior: as 4 visões propostas pela EPBE (Processos e Comportamento completam a lista) são básicas, mas não mandatórias nem fixas. Podemos suprimir alguma, dependendo das necessidades e do projeto. Também podemos criar novas visões, como “Papéis e Objetivos das Pessoas”, “Visão dos Efeitos Econômicos”, etc. A EPBE, assim como seu alicerce, a UML, é extensível. Por exemplo, veja neste artigo do IEEE (pago), até onde levaram a EPBE.

Como colocado anteriormente, o objetivo desta série é apresentar a EPBE e seus elementos básicos. Quem sabe, num futuro próximo, possamos explorar outros usos e extensões. Hoje vou mostrar um pequeno exemplo. Vou incorporar dois elementos que não existem na EPBE original: Balanced Scorecard e Mapas estratégicos. Eles nos ajudarão a documentar a estratégia da empresa.

.:.

A Visão do Negócio guia a modelagem das outras três visões. Isso porque é nela que aprendemos e registramos quais são os objetivos do negócio. Portanto, a construção da visão do negócio é o ponto de partida do processo de modelagem do negócio. Das 4 visões básicas propostas pela EPBE, esta é a única que não se consolida na forma de diagramas. Na realidade, em alguns casos, criamos apenas um grande modelo conceitual que destaca os principais elementos (ou conceitos) do negócio. Veja o exemplo (rabiscado) abaixo:

Por favor, não espere que o desenho acima derive para um diagrama de classes ou algo do tipo. O AN lança mão dessa ferramenta para facilitar sua compreensão do negócio. E, ao consolidá-la, pode utilizar o mesmo desenho para explicar o negócio para outros interessados. Só (isso tudo).

Crucial no desenvolvimento da visão do negócio é a compreensão de seus objetivos. Na proposta original da EPBE, essa parte principal é registrada na forma de texto. Os principais pontos a destacar são: Missão, Objetivos, Forças, Fraquezas, Oportunidades, Ameaças (obs: as 4 últimas são conhecidas também como matriz SWOT), Fatores Críticos, Estratégias, Competências Principais, Perfis, Unidades de Negócio e Processos-chave. Ao detalhar as estratégias pode ser necessário que também destaquemos: Clientes, Concorrentes, Ambiente, Lucratividade, Potencial de Crescimento e a Percepção que o mercado tem da empresa. O nível de detalhamento deste documento vai depender bastante das necessidades da empresa ou do projeto em questão. Quanto mais estratégico for o projeto, maior a necessidade de um estudo mais minucioso das variáveis listadas acima.

A EPBE não cita, mas eu gosto de completar o estudo acima com duas informações adicionais: a Proposição de Valor da empresa e o seu Modelo Operacional. Dois artigos publicados anteriormente neste espaço apresentam com um pouco mais de detalhes os dois estudos:
- Processos de Negócios: São Todos Iguais?
- Proposições & Modelos
Parto do princípio de que 90% dos novos projetos abertos pelas organizações têm um cunho estratégico. É raro vermos hoje em dia projetos que lidem com processos de negócio secundários, como folha de pagamento, contabilidade e afins (que, se não estão terceirizados, já foram devidamente informatizados). Sendo assim, a grande maioria dos projetos está vinculada à alguma iniciativa estratégica. Aqui nasce o alinhamento *estratégico* de TI com o negócio. Compreender e se comprometer com a estratégia do negócio é fundamental para o sucesso do projeto.

Por isso sugiro a incorporação de duas ferramentas que têm se mostrado bastante eficazes na elaboração, execução e acompanhamento das estratégias de negócio: o Balanced Scorecard e seu co-irmão, o Mapa Estratégico . Se a empresa não for usuária destas ferramentas, ou seja, se eles não estiverem disponíveis em sua forma tradicional e “bonitinha”…

… ainda assim, o AN pode desenvolvê-las:

Aliás, mesmo que eles existam em sua forma tradicional, é recomendável a elaboração do diagrama acima, em UML. Ao utilizar uma ferramenta CASE, e não o meu tosco rabisco, o AN ganha a facilidade de vincular objetivos, iniciativas e indicadores aos processos (como veremos no próximo capítulo desta série).

Minha sugestão não deve ser vista como uma substituição àquela da EPBE original, mas como um complemento. Se ela substitui alguma coisa, é o diagrama “Objetivos/Problemas” proposto por Eriksson e Penker. Trata-se de uma extensão, como prometi no início do artigo. Cabe relembrar outra coisa: a Visão do Negócio servirá como *guia* para o desenvolvimento das outras 3 visões. Veremos agora mais uma delas.

A Visão da Estrutura do Negócio

Quando falamos de Estrutura do Negócio estamos falando de todos os seus Recursos. No capítulo anterior vimos que recurso é tudo o que a empresa utiliza, consome ou produz. Portanto, com esta visão, detalhamos como a empresa organiza seus produtos e serviços, suas informações e também a si mesma, na forma de unidades de negócios, departamentos, cargos etc. Normalmente utilizamos apenas uma variação do tradicional diagrama de classes da UML para representar todos os tipos de recursos. As informações, por exemplo, são representadas em um grande modelo conceitual que lembra muito um tradicional modelo E-R. Aliás, para ser franco, é o mesmo cara.

Já o organograma da empresa pode ser traduzido num diagrama mais ou menos assim:

Estamos falando de documentos que normalmente o AN já encontrará em uma empresa. Portanto, a única justificativa para a sua (re)construção em UML é a facilidade que uma ferramenta CASE pode proporcionar quando o AN entrar na parte “dura” da modelagem de negócios: seus Processos. Assunto do próximo capítulo. Inté.

.:.

Bibliografia:
1. Business Modeling with UML – Business Patterns at Work
  Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
2. Para quem quiser conhecer o básico sobre Balanced Scorecards e Mapas Estratégicos, recomendo dois títulos:
  a) Medindo o Desempenho Empresarial – Harvard Business Review. Campus (2000).
  b) Mapas Estratégicos – Robert Kaplan e David Norton. Campus (2004).
.:.
novembro 29, 2007