Tag: IIBA

FAN :: Os Novos Módulos do Programa
O programa de Formação de Analistas de Negócios (FAN) nasceu para ser alicerce, fonte e processo de criação de meu primeiro livro. Seu inesperado sucesso¹ fez com que ele ganhasse vida própria. Quando ele foi lançado ainda não era um programa. Era só uma imensa palestra com 7 horas de duração, erroneamente identificada como “workshop”. Críticas e sugestões de vários participantes levaram a criação de duas oficinas de verdade: Modelagem de Negócios e Engenharia de Requisitos. Desenvolvi versões com 14, 35 e 70 horas, configurando assim um programa para formação de AN’s. Dezoito meses e mais de 1200 participantes depois, chega a hora de rever o programa e propor novos caminhos. Incrementais, claro, porque os módulos atuais continuam valendo.

Em agosto do ano passado eu publiquei aqui uma sugestão de roadmap para AN’s. Era ao mesmo tempo um plano e uma provocação. Poucas mas boas ideias foram apresentadas. Mas chega a ser curiosa a distância entre as alternativas fruto de um cutucão e as oportunidades / necessidades percebidas. Na primeira reunião pública do Capítulo SP do IIBA² (International Institute of Business Analysis) muitos participantes cobraram reconhecimento da profissão / função. De certa forma ficou implícita na solicitação uma melhor definição do perfil, formação e responsabilidades dos AN’s. Algumas das threads mais longas e quentes de nosso grupo de discussões e fórum tratam exatamente deste ponto: quem é e o que faz um AN? Ao conversar com colaboradores de empresas dos mais diversos segmentos e portes, percebi as mesmas questões. E os mais diversos cenários.

Há quem use o AN como se fosse um analista de sistemas, cobrando deste o domínio e desenho da solução. Em algumas empresas o AN parece guarda-costas ou válvula de escape do pessoal de suporte. Em outras é bode expiatório e sparring de usuários insatisfeitos e desenvolvedores idem. Para não dizer que tudo é negativo ou distorcido quando se trata de análise de negócios, vale ressaltar também que algumas organizações cobram de seus AN’s o que realmente deve ser cobrado: o entendimento do negócio e dos usuários e a comunicação desta compreensão para todas as partes interessadas de um projeto.

Como ainda há muita desinformação e contrainformação quando o assunto é análise de negócios, resolvi editar uma 3ª versão daquele palestrão de 7 horas. Chamado “FAN Especial”, sua primeira turma está programada para a próxima quarta-feira, 11/fev, em São Paulo. Com ele tento matar 2 coelhinhos com a mesma cajadada:
- Explicar para as empresas, particularmente gerentes de TI, gerentes de desenvolvimento e coordenadores de projetos: i) quem é o AN; ii) quais são suas responsabilidades na empresa e em projetos; e, iii) porque ele é importante, especialmente em projetos de software.
- Apresentar a função / profissão para analistas (de negócios, de sistemas, de requisitos, de processos…) e debater: i) o corpo de conhecimentos “oficial” (BABoK); ii) modelagem de negócios e engenharia de requisitos; e, iii) como as empresas estão contratando e estruturando o trabalho do AN.
Mas 7 horas são realmente necessárias? Sim, isso possibilitará um maior aprofundamento em todos os tópicos. Há também uma generosa fatia de tempo separada exclusivamente para os debates. Mas a principal mudança desta versão 3.0 do “palestrão” é a sequência de apresentação. Nas anteriores eu apresentava o AN, modelagem e requisitos em três partes com fronteiras bem delimitadas. Agora vou apresentar o trabalho do AN como ele realmente ocorre, do início ao fim de um projeto. As práticas e métodos serão apresentados como em um grande estudo de caso. Esta ordem permite apresentar, além do cenário ideal, armadilhas e equívocos que têm caracterizado o uso de AN’s pelas organizações.

Mas este formato nos leva a mesma situação apresentada lá no primeiro parágrafo: e se a turma quiser “sujar” as mãos, praticando um pouco daquilo que está sendo sugerido? Indicá-los o formato padrão, o par de oficinas com 14 horas de duração, não seria muito legal de minha parte. Afinal, nas oficinas eu repito toda a parte teórica. Pensando nisso, Tempo Real Eventos e eu resolvemos colocar no ar o “FAN – Mão na Massa“, um evento 100% prático. Os participantes serão apresentados a um problema de negócio e devem resolvê-lo em 7 horas, exercitando as principais ferramentas que estão a disposição do analista de negócios. A estréia deste evento em São Paulo está agendada para o dia 24 de março, véspera do lançamento do meu livro na mesma cidade.

O “Mão na Massa” será o primeiro evento do programa com um pré-requisito obrigatório: os participantes devem ter assistido algum outro módulo do programa FAN. Sem a base teórica destes eventos, é praticamente impossível aproveitar bem esta oficina. Que não será restrita ao público do “palestrão”. Todos que participaram dos workshops podem tirar proveito deste novo formato: a dinâmica é diferente – não tem aquele esquema “teoria – exercício – teoria…” que os caracteriza. É realmente 100% prático, o que garante uma experiência bem diferente das anteriores. Esta versão “Mão na Massa” foi testada em Florianópolis³, em dezembro. Como o resultado foi muito positivo, resolvi liberá-lo em formato comercial.

E tudo indica que este será o caminho de evolução do FAN, com pequenos módulos específicos. Cursos tradicionais, com 35 ou 70 horas de duração, são de difícil comercialização. A crise atual complica ainda mais a viablização de treinamentos mais longos. Os módulos do FAN, mais curtos e consequentemente mais baratos, são uma boa alternativa. Mas minha principal preocupação é com a utilidade deles: que os alunos consigam adotar as sugestões no dia ou no projeto seguinte. AN que é AN de verdade sabe que o retorno sobre o investimento deve ser nítido.

.:.

Notas:
1. Sucesso que devo a todos os participantes do programa FAN. Neste mercado só podemos considerar *cliente* aquele que faz a segunda compra. E ainda indica os serviços para colegas e amigos. Vale ressaltar também o incrível trabalho da “sócia” Tempo Real Eventos, que acreditou na proposta do FAN desde o primeiro momento.
2. Capítulo SP que agora terá com quem conversar. Está sendo lançado o Chapter Carioca do IIBA. Parabéns e boa sorte aos pioneiros.
3. E cabe aqui o agradecimento ao pessoal da FIESC, SESI e SENAI de Santa Catarina, que deu inestimável apoio ao evento “teste” que realizei lá. E, claro, devo agradecer também a turma que topou o desafio e mandou bem, muito bem.
fevereiro 4, 2009
Rendiconti: Modelando Negócios em São Paulo

No dia 26 de abril eu anunciei aqui a morte do ‘Patinho Feio’. Me referia ao evento que então era conhecido como “Análise e Modelagem de Negócios”. Sua baixa popularidade o colocou em risco. E o evento de abril foi a gota d’água. O evento demandava uma revisão. Não tanto em seu conteúdo, mas na forma em que estava sendo apresentado e comercializado. No final de maio Tempo Real Eventos e eu lançamos um “pacote” FAN: duas oficinas que, se contratadas em conjunto, significariam um pequeno desconto. Sei que é uma prática que pode ser mal recebida: configura-se venda casada? Bom, até agora ninguém reclamou e o sucesso da iniciativa fala por si: na última quarta-feira, 16/jul, tivemos uma turma com 60 participantes!

Outra pequena alteração que efetuei foi no nome do módulo: tirei a palavrinha “Análise” e dei o braço a torcer para o RUP. Esta primeira metade do programa FAN agora se chama só “Modelagem de Negócios”. Claro que faz mais sentido, já que vendo a Análise de Negócios como a junção da Modelagem de Negócios com a Engenharia de Requisitos. Aliás, visando facilitar o entendimento do escopo dos dois módulos criei uma tagline, um tipo de sobrenome para cada um deles: Modelagem de Negócios – Entendendo o Negócio; Engenharia de Requisitos – Entendendo o Usuário. Ficou meio simplista, até apelativo. Mas não tenho dúvidas que facilitou a apresentação dos módulos.

O programa FAN (Formação de Analistas de Negócios) é um eterno “trabalho em desenvolvimento”. Mas estou tratando a versão atual, publicada há cerca de 2 meses, como um release candidate. Ou seja, ela ficará ‘congelada’ nesta que considero a penúltima iteração do projeto do livro. Uma iteração longa, de 6 meses. As oficinas e cursos sempre antecedem a publicação de uma versão do livro. É o feedback que obtenho ali que direciona as alterações e incrementos que devo fazer em meu texto. A partir de agosto começo a publicar, exclusivamente para os participantes dos eventos, o release candidate de cada capítulo do livro. Minha intenção é liberar um capítulo por quinzena. Em paralelo está acontecendo o projeto Rendiconti – a loja virtual (POD – Print on Demand) que venderá meu trabalho e, se tudo der certo, o trabalho de vários colegas.

Mas, caramba… esta deveria ser a prestação de contas do evento do último dia 16. Vamos a ela. Na teoria minhas oficinas deveriam ter um público máximo de 50 pessoas. Na prática meu recorde é de 72. Coloquei o limite por uma razão muito simples: a possibilidade de interagir e dar atenção para todos os participantes.Tivemos 60 na última quarta-feira, mas acredito que todos que precisaram de atenção foram atendidos. Sem comprometer a duração do evento. Adianto para todos, logo na abertura do evento, que temos um buffer de 1 hora. E explico: se o evento for muito ruim, lá pelas 5 da tarde tá todo mundo indo embora. E confesso que isso já aconteceu uma vez, na 3ª turma do FAN “palestrão”. O tal buffer é utilizado nas interações. E foi totalmente consumido neste último evento.

Turma grande e variada, no sentido de que tínhamos ali vários ramos de atividades representados. De escolas a usinas de álcool, passando por várias empresas de desenvolvimento de sistemas com perfis bastante distintos. Esta heterogeneidade enriquece o evento, principalmente porque permite a exploração e o debate de muitas expectativas e perspectivas distintas. Os exemplos que vêem dos participantes, suas demandas e dificuldades, são parte central da matéria-prima que utilizo em meu trabalho. Tanto que não vejo mais como seria possível escrever um livro deste tipo com um processo diferente.

Apesar de insistir que os dois módulos do programa são “levemente acoplados”, por diversas vezes encerrei um papo dizendo que aquilo era tema para o evento do dia 31. Ficou feio, mas do contrário eu correria o sério risco de estourar o horário. Na verdade o que está acontecendo, intencionalmente, é uma melhor amarração das duas disciplinas. Como aprendi em nosso grupo de discussão, mesmo os participantes mais envolvidos e antenados viviam “me jogando na cara” que a formatação do programa tinha um Q de cascata. Por mais que eu insistissse que as duas disciplinas ocorrem em paralelo em um projeto para desenvolvimento de sistemas, a sensação de “quedas em cascatas” persistia. Por isso amarrei um pouco mais as disciplinas. Tento indicar onde e como há o entrelace. Fico sempre devendo o outro lado da amarração, a parte dos Requisitos. Devendo para o evento seguinte. Não vejo como fazer de outra forma.

Por falar em “cascatas”, confirmei um padrão que demanda atenção. Empresas de software que desenvolvem pacotes apresentam uma grande resistência a processos que preguem a adoção de um ciclo iterativo e incremental. Percebi isso em turmas fechadas que executei nas últimas semanas, no interior de São Paulo e em Santa Catarina. E a coisa ficou ainda mais “quente” neste evento. Os argumentos de quem defende a “cascata” neste tipo de organização são fortes, contundentes. Existem aqui duas variações principais: quem defende “cascatas” com unhas e dentes e quem pensa que iterações com 3 ou 5 meses de duração não configuram uma “cascata”. Com o segundo grupo tive tempo suficiente para descobrir que seu processo carece de revisão – foi em SC. O debate com esta turma de Sampa prosseguirá no próximo 31/jul. Espero entender e registrar melhor seus argumentos. Como a próxima oficina é bem mais prática, espaço para o debate não faltará. Claro, registrarei aqui meus achados (e perdidos).

Sempre recebo uma compilação (anônima) das avaliações. O ponto que mereceu a imensa maioria das críticas ao evento foi uma inserção comercial de 15 minutos. O evento teve um patrocinador, que ganhou um tempinho para deixar sua mensagem. A turma não gostou. Mas acho que foi só um problema de comunicação. Minha parcela é grande. Existem eventos parecidos que custam o dobro deste. A turma precisa entender que a manutenção dos valores atuais dependerá de recursos assim, de patrocinadores. Eu aviso que não endosso nenhum dos produtos ou serviços apresentados pelo patrocinador. Mas também não os ‘detono’. (Só adoro detonar mesmo o Requisite Pro, hehe). Tempo Real, Borland e eu tentaremos tornar o “reclame” mais útil e interessante para os participantes. Uma breve demonstração de produtos / ferramentas é o caminho.

Para encerrar, devo registrar a satisfação de ter contado com a presença da presidente do Capítulo São Paulo do IIBA (International Institute of Business Analysis), Suzandeise Thomé. O amigo Cláudio Kerber nos apresentou, e a convidei para os dois eventos. O Capítulo São Paulo foi fundado no dia 1º de abril deste ano. Sim, a Suzandeise brincou com a data. Além de nos informar que o trabalho ainda está em sua fase inicial, brigando com uma certa burocracia. Mas as perspectivas são boas. Em pvt ela me disse que o interesse é muito grande. Que várias empresas já os procuram para, principalmente, oferecer treinamentos para a formação de Analistas de Negócios. “Hot Commodity” é isso aí. Chute meu: os dois próximos anos serão quentíssimos!

Momento “falha nossa”: 1 mês sem atualizações do finito é muita coisa. Aos amigos que gostam de meus artigos, registro aqui um sincero pedido de desculpas. Tenho em meu backlog quase uma dezena de temas que quero tratar aqui. Mas a correria das últimas semanas mal deixa tempo para uma necessária cervejinha. E os próximos 45 dias seguirão no mesmo ritmo – até pior. Mas tentarei não deixar este espaço tão abandonado. Não por um período tão longo.

julho 22, 2008
Boas Vindas ao IIBA

Quem deu a boa notícia foi o amigo Kerber, de Floripa. Taí: 18 meses após a ‘descoberta’ do International Institute of Business Analysis, temos o desembarque dele em terras tupiniquins. Outra comprovação de que a profissão-função Analista de Negócios ganha corpo e força. O Kerber, como voluntário, ajuda o capítulo de Sampa na criação e manutenção de seu site. Parabéns, meu caro, pela iniciativa.

O Kerber lembrou, em uma mensagem para o nosso grupo AN.br, que tenho alguns ‘poréns’ em relação a este tipo de associação: “Eu conheço e compartilho das preocupações do Paulo em relação a órgãos como esse que tendem a encontrar um fim em si mesmo”. Ele sabe, não é só isso (tudo). Me incomoda, particularmente, o jeitão ‘panelinha’ desses institutos. Preciso dizer que meus ‘poréns’ nasceram após mínimos contatos com o PMI?

Jóia é que, conhecendo os acertos e erros de PMI’s e afins, fica mais fácil desenvolver uma associação mais moderna, aberta e realmente útil. Claro, oferecerei meu apoio sempre que ele se fizer necessário. E torcerei muito pelo sucesso do Capítulo de Sampa e pela criação de outros capítulos por todo o Brasil. Os Analistas de Negócios têm muito a ganhar com o Instituto. E não falo da certificação, mas da difusão de conhecimentos e da função-profissão. Portanto, que a gente saiba receber a iniciativa com braços abertos.

junho 11, 2008
Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
Seqüência obrigatória do último post. A motivação é a seguinte afirmação: “Os passos em um Caso de Uso são Requisitos Funcionais“. A questão parece simples mas esconde alguns “probleminhas”. Minha intenção aqui, além de justificar minha afirmação, é debater os tais “probleminhas”.

Variações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.

Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.

A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.

Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.

As variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.

No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):
1. Coloca uma moeda
2. Seleciona o tipo de bebida
3. Retira o copo
O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?

Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.

Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.

Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: “It’s not what the software does. It’s what the user does.” Deveria virar um poster-lembrete na sala-mesa de todo AN.

Atualização:

Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!

Bibliografia:
1. Writing Effective Use Cases
  Alistair Cockburn. Addison-Wesley (2001).
2. Software Requirements
  Karl E. Wiegers. Microsoft Press (1999).
3. More About Software Requirements
  Karl E. Wiegers. Microsoft Press (2006).
4. Use Case Modeling
  Kurt Bittner e Ian Spence. Addison-Wesley (2003).
maio 14, 2008
BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios
Nada como um dia (agitadíssimo) depois de outro (não menos agitado). Ao reler o artigo anterior, “O BABoK e a Disciplina ‘Enterprise Analysis’“, reparei que posso resumi-lo assim: O BABoK trata exclusivamente da macro-disciplina Engenharia de Requisitos. Apesar do nome, a KA (Knowledge Area) Enterprise Analsys (ou Análise Corporativa) trata exclusivamente daquilo que Karl Wiegers chama de Requisitos de Negócio . Trata bem e de maneira bem completa, diga-se de passagem. Mas este fato torna o nome BABoK (Business Analysis Body of Knowledge) meio enganador. Aquele conteúdo formaria um bom REBoK – Requirements Engineering Body of Knowledge. Para a Análise de Negócio falta uma metade: exatamente a Análise (e Modelagem) de Negócios!

Desconfio que a falta já é sentida pelos próprios autores e responsáveis pelo BoK. Em uma das apresentações recentemente utilizadas na divulgação da profissão e do BABoK, eles frisam:
Análise de negócios não é análise de requisitos de software. Analisar um negócio é compreender:
- Como a organização trabalha;
- Qual a razão de sua existência;
- Seus objetivos e metas;
- Como ela busca esses objetivos; e
- O que ela precisa mudar para melhor atender esses objetivos.
Para ajudar a definir uma solução para um problema de negócio.
Com certeza, alguém já fez a mesma cobrança que faço desde que conheci o BABoK. Pena, mas a declaração acima (ainda) não está refletida naquele corpo de conhecimentos. Não há no BABoK um conjunto de Tarefas e Técnicas que atenda plenamente a lista acima, exceção feita ao terceiro item. Bom, como prometi no artigo anterior, serei mais “construtivo”.

Antes de estudar as necessidades ou problemas de um negócio, é necessário conhecê-lo, aprendê-lo. Uma maneira muito eficaz para se *aprender* um negócio é a modelagem. Modelar é simplificar. Modelar é compilar apenas o que é essencial. Indico (teimosamente) o uso da EPBE (Eriksson-Penker Business Extensions) para a criação desses modelos por dois motivos principais: i) Ela é completa – me permite cobrir todos os aspectos de um negócio, sua estrutura e sua dinâmica (processos); e ii) A EPBE é uma extensão da UML (Unified Modeling Language), uma linguagem madura, bem difundida e fácil de aprender. (Já apresentei a EPBE em outra série de artigos).

Todo e qualquer negócio apresenta 4 *coisas* que precisamos aprender: Objetivos, Recursos, Processos e Regras. Cada um deles pode merecer um ou mais modelos, dependendo da criticidade do negócio ou do projeto em questão. A EPBE nos oferece 4 visões, 4 dimensões – maneiras diferentes de *ver* o negócio: A visão do Negócio propriamente dita; sua Estrutura; Processos e Comportamento. Não há uma seqüência pré-fixada para o estudo. Como sempre, depende do negócio e do projeto. Mas, mesmo em empreendimentos muito simples, não abro mão de um enxuto mapa de processos e do diagrama de processos (ou “linha de montagem“) um pouco mais detalhado. Usando uma boa ferramenta CASE , e não meus rabiscos, obtemos automaticamente outros modelos, como a estrutura de recursos, objetivos e metas (ou mesmo um balanced scorecard).

Ao estudar os processos, vendo as atividades e tarefas que os formam e toda a estrutura (departamentos e outros recursos) envolvida em sua execução, ganhamos uma visão mais nítida do “terreno que estamos pisando”. Se há um projeto, existem Requisitos de Negócio. São os objetivos (um dos 4 elementos básicos apresentados acima, lembra-se?), as necessidades ou problemas que devemos sanar. São os primeiros requisitos que conhecemos. Na maioria das vezes, bem antes do projeto ser iniciado. Mesmo que sejam mais críticos e essencias para o sucesso do projeto, esses requisitos são tratados da mesma forma – acolhidos em uma mesma estrutura. Destaquei este ponto para mostrar que Análise e Modelagem de Negócios e a Engenharia de Requisitos são atividades que ocorrem de maneira simultânea, e não sequencial. Nem quem mergulha em “cascatas” conseguiria tratá-las como fases distintas de um projeto – são naturalmente indissociáveis, “gêmeas siamesas”.

Processos Envelhecem

O que acontece quando um recurso de uma empresa se torna obsoleto? Ele é trocado, certo? Se for um computador ou um caminhão, compra-se um novo. Se for uma pessoa, aposenta-se ou mostra-lhe o bilhetinho azul (ou cartão vermelho, como queira). Mas, e quando um processo de negócio envelhece? O que acontece? As empresas costumam remendá-los e redesenhá-los. Trocas radicais só ocorrem mediante a implementação arbitrária de um pacote de melhores práticas também conhecido como ERP. Mas, mesmo assim, em curto espaço de tempo, voltam os remendos e redesenhos. O mundo não pára.

O envelhecimento de processos, assim como o nosso, vem com más notícias. Saca aquela dorzinha na coluna que nunca tivemos? Bom, é por aí. E aqui entramos num ponto relativamente polêmico do trabalho dos Analistas de Negócios (AN’s). É mal traçada a linha que os separa daqueles tradicionais Consultores de Negócios. Há quem diga que um AN não deve “se meter” com os problemas do negócio. Oras, o que justificaria tamanha “vista grossa”?

É claro que, quando em projetos para desenvolvimento ou implantação de sistemas, o foco do AN não é o redesenho (ou reengenharia) de processos de negócio. Mas isso não significa que ele deva ignorar sintomas e doenças que porventura encontre durante seus estudos. Se ele insistir em levar para a solução aquele processo e suas pequenas dores, levará também maiores riscos e chances de mudanças. É exatamente por isso que, ao contrário do RUP, gosto de chamar esta disciplina de Análise e Modelagem de Negócios. Soarei idiota, mas preciso reforçar: é o Analista de Negócios quem executa a Análise de Negócios! E analisar, definitivamente, não se resume ao desenho de belos modelos.

Portanto, a grande e grave deficiência do BABoK é o fato deste ignorar por completo este estudo, a análise e modelagem de negócios. Acho pouco provável que todo esse “chororô”, que não é só meu, gere alguma mudança significativa na versão 2.0 que está em vias de ser publicada. Resta torcer para que, ao contrário do que ocorre em outras instituições similares, eles não se apeguem de forma intransigente à estrutura atual daquele corpo de conhecimentos. Seria fatal.

Outros Corpos

Como eu disse lá em cima, foi uma semana bem agitada. Em nosso grupo de discussão, parcialmente restrito aos participantes de meus eventos, surgiu um conversa meio “subversiva”: elaborar o que o amigo Jefferson chamou de “BABoK Apócrifo”! Acho que (ainda) não é o caso, mas um fruto imediato aquela discussão toda já gerou: nascerá (muito) em breve um Fórum que tratará exclusivamente do BABoK e da profissão AN. Ao contrário do grupo, acho que o Fórum será público. Acho. A turma decidirá.

: Acontece na próxima quinta-feira (24/abr), em Sampa, a 2ª edição da oficina Análise e Modelagem de Negócios. É um evento de um dia só, mas consigo mostrar nele tudo aquilo que, na minha opinião, foi ignorado no BABoK. Nesta página você tem uma visão geral do programa. É extenso e tem vários exercícios. Mas nada que a gente não consiga conversar em 1 dia.

Referências:
1. Software Requirements
  Karl Wiegers. Microsoft Press (1999).
2. Já utilizei a EPBE no Rational Rose e no Visual Paradigm, além d’outras, menos fechadas. Para quem quiser experimentar, existem duas ferramentas “free” que oferecem a extensão: StarUML e JUDE. (Tks! Marcelo).
abril 18, 2008
O BABoK e a Disciplina “Enterprise Analysis”
O IIBA (International Institute of Business Analysis) liberou no último dia 31 de março a versão 2.0 do BABoK (Business Analysis Body of Knowledge) para revisão pública. O projeto da nova versão tem uns 6 meses de atraso. E eles descontaram nos revisores: temos só até o próximo dia 15 de maio para apresentarmos nossas sugestões / reclamações. Tática estranha, mas não percamos tempo com ela. Abri este post para fazer uma revisão pública de um único capítulo daquela publicação, o capítulo 4, que trata de uma área de conhecimento (Knowledge Area) chamada “Enterprise Analysis”. Ponto que questiono e critico desde a versão anterior do BABoK.

Antes de descarregar minhas críticas preciso explicar rapidamente a estrutura deste BoK caçula. Ele é formado por 6 KA’s (Knowledge Areas, ou Disciplinas). São elas: i) Planejamento e Monitoramento da Análise de Negócios; ii) Gerenciamento e Comunicação de Requisitos; iii) Análise Corporativa; iv) Elicitação; v) Análise de Requisitos; e vi) Avaliação e Validação da Solução. Cada KA é formada por Tarefas, Técnicas, Entradas e Saídas.

Tarefas são “peças essenciais do trabalho que deve ser executado na análise de negócio”. As técnicas descrevem “como as tarefas devem ser executadas em determinadas circunstâncias”. Momento ‘dã’: tarefas recebem entradas e geram saídas. ufs.. Mas, por favor, não me entendam mal: a estrutura do BABoK é legal, bem simples. Tanto que consegui explicá-la em dois mínimos parágrafos. Vamos então ao que interessa (neste artigo), a “estranha” KA chamada “Análise Corporativa”.

O problema já começa no nome. Tiveram que inventar um substituto para “Análise de Negócio”, porque interpretam este nome como um grande guarda-chuva que incorpora outra macro-disciplina, a Engenharia de Requisitos. Tudo bem, há tempos aprendemos a conviver com nomes e definições confusas. Por falar em definição, “Enterprise Analysis” é apresentada da seguinte forma:

A (disciplina) Análise Corporativa descreve como tratamos uma necessidade de negócio, como refinamos e esclarecemos aquela necessidade, e como definimos o escopo de uma solução viável. Aqui conversaremos sobre a definição e a análise do problema, o desenvolvimento do Business Case, de Estudos de Viabilidade e da definição do escopo da solução.

Na introdução do capítulo 4 do BABoK, que trata especificamente desta disciplina, é apresentada uma definição mais formal e completa:

A Área de Conhecimento Análise Corporativa consiste de uma coleção de tarefas para a análise da situação do negócio para a completa compreensão de seus problemas e oportunidades, além de uma avaliação das condições atuais e futuras com o intuito de identificar as mudanças necessárias para a satisfação das necessidades do negócio e seus objetivos estratégicos. As saídas geradas nesta disciplina fornecem a base necessária para o trabalho de elicitação, análise, validação e documentação de requisitos, e também para a identificação de uma solução para uma determinada iniciativa e / ou para o planejamento de longo prazo.

A definição é legal. Assim como o gráfico ao lado, que ‘explica’ a disciplina em uma apresentação oficial do IIBA. Mas reparem na definição acima e na lista de KA’s do primeiro parágrafo. Se temos lá uma KA chamada “Avaliação e Validação da Solução”, qual a razão da KA “Enterprise Analysis” tratar do desenvolvimento do Business Case e, mais ainda, da elaboração de estudos de viabilidade? Confunde, não?

Claro, uma avaliação mais profunda das técnicas mostra que estamos falando de coisas diferentes. Para ser mais exato, de momentos diferentes! Então, como fruto de um trabalho notadamente departamentalizado, temos que o estudo de viabilidade não está no escopo da disciplina Avaliação e Validação da Solução. Tudo bem. Como eu já disse, estamos acostumados a conviver com definições confusas e dúbias.

Em meu entedimento, o problema com a disciplina Análise Corporativa é outro, consideravelmente maior. Ela deveria incorporar aquilo que conhecemos como Análise e Modelagem de Negócios. Não é o que acontece. Veja abaixo a lista de tarefas que formam esta KA:
1. Definir as necessidades do negócio;
2. Determinar o gap entre as necessidades e a capacidade do negócio de atendê-las;
3. Determinar o enfoque recomendado para a solução;
4. Definir o escopo da solução; e
5. Desenvolver o Business Case.
Que estranho: em nenhum momento o Corpo de Conhecimentos da Análise de Negócios fala sobre “aprender o negócio”, “entender o negócio”. Já cai direto na “definição das necessidades do negócio”. Tamanha pressa é medo dos agilistas (muito citados no BoK)? Sigamos, agora sem ironias.

Alguém pode dizer que está implícito na compreensão das necessidades de um negócio o aprendizado sobre o próprio negócio. Grave engano, e as estatísticas sobre projetos que falham são a maior prova que posso apresentar. Só consigo aprender realmente as necessidades (requisitos) de um negócio depois de conhecê-lo. Façamos uma breve (e covarde) analogia: você saberia dizer as necessidades de sua (seu) namorada(o) ou esposa(o) antes de conhecê-la(o)? Antes mesmo de manifestar suas intenções?

Se eu não conheço um negócio, aquele domínio, como posso avaliar suas necessidades e oportunidades? Pior, como posso “definir o escopo de uma solução”? Vale aqui ressaltar que conhecer um negócio não se limita ao entendimento daquela entidade, mas compreender todo o seu ambiente, clientes, concorrentes, parceiros, legislação e um monte de etc.

Por essas e (muitas) outras insisto que o BABoK pode criar uma terrível distorção do trabalho conhecido como Análise de Negócios. Como tempo e espaço ficaram curtos, deixarei para o próximo artigo a porção mais construtiva de minhas críticas.

Mas, claro (!), sobrou um tempinho para convidá-lo a conhecer uma visão um pouco diferente da Análise de Negócios. Acontece no próximo dia 24/abr, em Sampa, a 2ª edição da oficina “Análise e Modelagem de Negócios”. Nela e em sua co-irmã, Engenharia de Requisitos, apresento as tarefas e técnicas que são utilizadas por um Analista de Negócios. Claro, contemplo todas as boas idéias sugeridas no BABoK. Mas, definitivamente, não o considero um “corpo fechado”. Por isso apresento vários adendos, inclusive o uso da UML para a modelagem de negócios.

Merchan Parte II: quem participa dos eventos ganha uma versão digital de meu (adiado) livro (com garantia de atualização até a versão 1.0), alguns PPT’s e, o mais importante, acesso ao Grupo de Discussão AN.br. Já somos mais de 200. E no último mês batemos o recorde de mensagens trocadas. Está muito quente e rico. E a última iniciativa do grupo é o estudo conjunto do BABoK. No meio de nosso “toró de parpites”, já pintou até a sugestão de elaboração de um “BABoK Apócrifo”. Pode? Claro que pode! Inté!
abril 16, 2008
Repensando o Papel do Analista de Negócios
Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido “pensá-lo”? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN’s! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN’s certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

Para começar, a forma muito legal que o Ambler apresenta o AN:

Na teoria, a idéia de ter AN’s tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela “poluição informativa” – lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN’s claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os “tech weenies” de TI e os “business morons” para os quais o sistema é construído.

Jóia né? Mas aí apareceram os “poréns”. Comento abaixo cada um deles, na seqüência original:
1. AN’s não apresentam as habilidades corretas
  pv: Natural, afinal ainda não temos um mínimo ‘corpo de conhecimentos’ consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
  AN’s são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN’s não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos “analistas-programadores”. Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
2. AN’s podem ter uma influência muito negativa no projeto
  pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN’s que não funcionam como canais, mas sim como uma “parede” entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
3. AN’s podem ficar desatualizados
  pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito… muito jeito.
4. AN’s podem ser uma barreira para a comunicação
  pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a “tradução livre”. Explico: o AN começa a contar apenas “boas notícias” para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
5. AN’s podem reduzir a influência dos stakeholders
  pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de “firewall” para a equipe.
6. AN’s analisam MUITO
  pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da “analysis-paralysis“. Simplificando: se o AN for jogado em um processo baseado no ciclo “cascata” (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
  Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo . Se ele resolver executar seu trampo “numa tacada só”, só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
  * São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).
7. AN’s reduzem o feedback
  pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers , um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
8. AN’s reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
  pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue “tirar o pé da jaca”. Ou, colocando d’uma forma menos agressiva: “não tira o boné de jeito nenhum”. Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN’s. E aprender muito com os bons AN’s.
.:.

Notas:
1. Agility and Discipline made Easy: Practices from OpenUP and RUP
  Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
2. More About Software Requirements
  Karl Wiegers. Microsoft Press (2006).
.:.
setembro 21, 2007
Sobre o Livro (e uma Oferta)
Quando decidi escrever meu primeiro livro, não tinha a menor idéia de como seria o processo. Escrever artigos, mesmo aqueles longos, é uma coisa. Um livro é totalmente diferente. Seth Godin e Scott Berkun, em seus blogs, costumam contar um pouco sobre seu processo. Ariano Suassuna, Chico Buarque e Luis Fernando Veríssimo me assustaram um tanto com seus depoimentos sobre o trampo. Mas, no final das contas, cada um tem seu processo, suas manias e traumas. Resolvi desenvolver meu próprio processo (e manias). Espero não colecionar muitos traumas. Mas sei que alguns serão inevitáveis.

Começando do começo, fixei alguns princípios:
- Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
- O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
- Peça de marketing não pode significar um livro “marketeiro” (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
- O livro é um esforço “solo”. Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro “míope” (ou “caolho”) é muito grande.
- Apesar de conhecer a tendência, o livro não será do tipo “como passar na prova”. Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.
Na seqüência desenhei a extensão do livro, uma visão de “alto nível”. Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 “convidados”). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

Por isso os workshops que estou realizando com a Tempo Real Eventos são tão importantes. Não pelo contato de 1 dia, mas pelas conversas que acontecem depois. Por isso montei um grupo de discussão “fechado”. Ali posso receber críticas e sugestões. Ali nós trocamos idéias sobre o conteúdo, práticas, processos…

Pois é, adotei um processo Iterativo & Incremental para o desenvolvimento do livro. Sendo assim, posso dizer que nos encontramos na fase de construção, na 7ª iteração. O produto, o texto, já está na versão 0.6. Chegamos em uma fase em que as iterações precisam ser mais curtas. Mas o cronograma segue rigorosamente em dia.

O trabalho de escrita, com todas as revisões, se encerra em dezembro. Já divulguei até a data oficial de lançamento: 27/mar/2008 (quinta-feira) Um dia eu explico a data e o codinome do rebento, “É o Negócio, Beócio“.

.:.

Do mesmo conteúdo gerei uma palestra (1h30), o workshop (7hs) e um curso (80hs, dividido em dois módulos de 40hs: Modelagem de Negócios e Engenharia de Requisitos).

Segue aqui uma oferta para escolas, universidades e entidades sem fins lucrativos (de Sampa ou Varginha): quem quiser levar a palestra ou workshop para suas organizações (em outubro ou novembro), não terá custo nenhum. Demais localidades podem ser incluídas, dependendo da distância e das despesas de deslocamento. Todos os participantes receberão uma cópia (digital) do livro (que ainda é uma apostila) e outros artefatos. Se interessou? Então, fale comigo.

.:.
setembro 11, 2007
Hot Commodity

Hot Commodity! Jeito legal de dizer que a profissão “Analista de Negócios” está em alta. Foi assim que a revista CIO da Alemanha apresentou o AN, em artigo do último dia 16/ago. Em novembro, também na Europa (Barcelona), acontece o “Project World & World Congress for Business Analysts“. Em 9 meses, o IIBA conseguiu certificar pouco mais de 70 profissionais. Um neozelandês, o resto dos EUA e Canadá. Ou seja, é tudo muito novo.

Ao mesmo tempo em que é tudo muito velho. A função existe há muito tempo, com nomes e responsabilidades um pouco diferentes, mas nova ela não é. Pode ser vista como uma releitura dos saudosos “Analistas de Organizações, Métodos e Sistemas”, uma profissão que ficou esquecida depois da ‘ascensão’ dos “Analistas de Sistemas” (AS). Veio a inevitável ‘queda’ dos AS’s, vieram os métodos ágeis e muito mais água debaixo da mesmíssima ponte, até que (re)descobrimos a importância desse cara que, na maioria das vezes, é apresentado como uma “ponte entre todos os stakeholders“. No artigo da CIO o job description é o seguinte:

“O AN é uma ponte entre o negócio e TI, trabalhando em ambos os lados para propor mudanças em processos e sistemas, visando satisfazer as necessidades do negócio.”

Definição meio perigosa, já que pode levar à falsa impressão de que um AN é um tipo de tradutor; que suas funções são um tipo de retrabalho; um passo ou uma fase adicional no processo de desenvolvimento. Enfim, um custo ou, pior ainda, um desperdício.

Em meu trabalho, logo no primeiro capítulo, reforço que um AN passivo não é um AN de verdade. Vira quase um “garoto de recados”. A razão para o rótulo “hot commodity” ficou, de certa forma, implícita na descrição acima: “trabalhando em ambos os lados para propor mudanças em processos e sistemas”. O ponto de vista de um AN é super-privilegiado. Ao navegar entre TI e o negócio, ele pode desenvolver uma perspectiva única, caríssima para qualquer empresa que fale seriamente sobre “alinhamento estratégico”.

Há dois dias estive em um dos maiores bancos brasileiros. Eles têm quase 150 AN’s, alocados em um departamento independente. Seu esforço: fazer com que os AN’s compreendam e assumam sua responsabilidade estratégica.

Não tem nada a ver com o banco, mas é por essa e outras que reafirmo: o BABOK, mesmo com as alterações previstas para a versão 2.0, está um tanto distante do alvo correto. Sua ênfase em documentação, no desenvolvimento e gestão de requisitos, cria uma visão um tanto equivocada das responsabilidades dos AN’s. Oportunamente, e com uma maior freqüência, espero explorar melhor o tema por aqui.

Por enquanto vale o registro da tendência: AN é um hot job. Resta torcer para que ele não seja recebido como um ‘salvador da pátria’; que sua certificação não se torne uma indústria com fim em si mesma; que os livros e cursos não mirem exclusivamente as provas de certificação; que os AN’s, fortalecidos, não tentem se fechar em “Escritórios de Análise de Negócios”… Enfim, que o AN aprenda com os erros dos outros.

.:.

Momento “Oportunista, eu?”

A próxima turma do workshop “Formação de Analistas de Negócios” acontece no distante 27/set. Quem se inscrever até a próxima sexta, 31/ago, receberá 50% de desconto. Quem se inscrever e falar comigo antes receberá a versão eletrônica da apostila e um passe para o grupo de discussão exclusivo. A próxima versão da apostila, 0.7, será disponibilizada para os participantes das turmas anteriores no dia 20/set. Será a primeira versão com a formatação mais próxima da versão final do livro. Aliás, já está acertado que o livro será lançado em 27/Março/2008.

Até lá, melhor dizendo, até dezembro, é tratar de amadurecer e enriquecer o texto. Daí os workshops e o grupo de discussão. Daí que, logo, serão lançados os treinamentos. Espero falar sobre eles muito em breve.

.:.

agosto 24, 2007
O Giro em Falso das Rodas Reinventadas

Há quem ache que a síndrome NIH (Not Invented Here) é uma exclusividade dos desenvolvedores. Não é. Parece que toda a nossa área adora reinventar rodas, eixos e padrões. O tempo todo.

Foto de Tom@HK.

Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; “oceanos azuis” e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM… Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a “reinvenção”) são ainda mais perigosas.

Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

O BABoK é novo. A versão que estou utilizando é apresentada como um “draft 1.6”, de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como “CMM” em algumas poucas referências. No corpo do “corpo” ele é sumariamente ignorado.

Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

Mas os “agilistas” não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que “em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo”. Não há quase nada além disso.

Acho que nem preciso dizer que “gestão do conhecimento” e “aprendizagem organizacional” também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas ‘levemente acopladas’. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables – toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de “guia de referência rápida”. Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada “integração” ou algo do tipo.

Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um “Corpo de Conhecimentos da Análise de Negócios”. A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

.:.

junho 14, 2007