PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: IIBA

  • BABoK v3 – Primeiras Impressões

    BABoK v3 – Primeiras Impressões

    No último dia 12 de maio o Guia BABoK v3 foi liberado para revisão pública. Dado o tempo de maturação – cinco anos se passaram desde a última atualização – a expectativa era a de um grande salto qualitativo. Ao contrário do que ocorreu entre as versões 1.6 e 2.0, a evolução é bastante perceptível. Infelizmente, há alguns poréns.

    Comecemos pelas boas novas. As definições básicas foram todas revistas. A verborragia que tanto atrapalhava e comprometia o entendimento do guia foi, em grande parte, eliminada. Tomemos como exemplo a própria definição da Análise de Negócios: ela foi abreviada de 43 para 27 palavras. Sai aquele papo sobre “…atividades e técnicas para servir como ligação entre parte interessadas…” – um terror, e entra “viabilizar mudanças em organizações através da definição de necessidades e recomendação de soluções”. Boa!

    A nova versão também troca a definição de Requisito proposta pelo IEEE por uma bem mais enxuta: “representação utilizável de uma necessidade”. Enxuta e curiosa. Porque prevalece um entendimento técnico em detrimento da definição fixada em dicionários. Requirement, segundo o Oxford, é uma “coisa necessária ou desejada”. Aqui no Brasil tomamos a liberdade de traduzir Requirement como Requisito, termo que o Houaiss define como uma “condição para alcançar determinado fim”. A Navalha de Occam adaptada para analistas de negócios ensina que, na dúvida (entre definições de um mesmo termo), deve prevalecer o que facilita a vida de uma pessoa de negócios, não a do técnico. Por isso termos como “requisitos não funcionais” deveriam ser abolidos ou apresentados com ressalvas e as devidas adaptações para leigos. Infelizmente, isso não ocorreu.

    E não se trata de um mero detalhe. Se uma das maiores contribuições de um analista de negócios é a comunicação eficiente e eficaz, o primeiro passo é a adoção de um vocabulário livre do tecniquês e de jargões. Noves fora, o fato é que a simplificação apresentada na nova versão merece aplausos.

    Escorando a Estrutura

    A estrutura básica, com seis disciplinas (KA – Knowledge Areas) e um “repositório universal” (Competências Fundamentais) está mantida. Alguns nomes sofreram alterações, como Análise Estratégica ao invés de Análise Corporativa. Pequenas alterações que não são apenas cosméticas porque facilitam o entendimento¹.

    Uma das novidades na estrutura do BABoK é o BACCM (Business Analysis Core Concept Model – Modelo de Conceitos Centrais). O modelo é formado por seis termos apresentados na seguinte ordem: Mudança, Solução, Contexto, Valor, Partes Interessadas e Necessidades. Uma mudança em um desses “lugares” forçaria uma revisão nas outras cinco “dimensões”. E isso facilitaria uma visão holística.

    Honestamente, não entendi bem a novidade. E o checklist que a encerra dá certo frio na espinha – irão os decorebas adotá-lo, para pesadelo das partes interessadas em busca de soluções para problemas que em dado contexto mutante devem gerar algum valor? Não sei se é a santa obviedade que me trai. Ou meus pré-conceitos. De qualquer forma, melhor esperar por experiências ou outras explicações.

    Como comentei anteriormente, o BABoK agora apresenta uma nova seção chamada Perspectivas. Estão ali: Agile, BI (Business Intelligence), TI (Tecnologia da Informação), Arquitetura de Negócios e BPM (Business Process Management). O que delimita esse conjunto além do óbvio berço tecnológico? Nada!

    Mas o BABoK ensina que as Perspectivas determinariam conjuntos específicos de comportamentos, termos e atitudes. E justificariam definições diferentes para: Escopo de Mudanças; Escopo da Análise de Negócios; Impacto em KA’s; Metodologias e Técnicas; e Competências Fundamentais. Como as Perspectivas não são mutuamente exclusivas, fica a curiosidade em saber como ficaria o caldo no caso de um projeto de BI e de TI guiado por algum método Agile.

    Lembrando seus velhos (e maus) momentos, o BABoK oferece um desserviço neste ponto. Que é um tanto comprometedor por falar tanto de tecnologia e muito pouco sobre Negócios. É desta forma que o discurso sobre uma Análise de Negócios ampla, geral e irrestrita (e não mais subordinada a TI) soa falso e cai por terra.

    A estrutura original do BABoK, apesar de suas carências, não precisava dessa escora. Precisava, isso sim, rever a maneira como trata a modelagem de negócios. Salpicar o “Pensamento Visual” como uma nova Competência Fundamental ou “Arquitetura de Negócios” como uma Perspectiva é muito, muito pouco.

    O Salto que Falta

    Acho que ninguém duvidava que a nova versão do BABoK seria consideravelmente melhor que a anterior. Assim como a próxima também será uma evolução. Mas quanto tempo esperaremos por ela? Outros cinco ou seis anos? E a comunidade, como agora, terá generosos dois meses para uma “revisão pública”?

    Talvez tenha chegado o momento de discutir uma questão que é maior do que todas listadas acima. Por que o BABoK não vira um Wiki? Por que, a exemplo da Wikipedia, ele não aceita contribuições de todos o tempo todo?

    Não acredito em impedimentos financeiros. Vendas do guia não representam nem 10% das receitas do IIBA². E uma versão Wiki não significaria, necessariamente, o fechamento desta fonte de receitas.

    Outro fator que deve tornar este momento único – uma janela de oportunidade – é a entrada do PMI no mercado de análise de negócios. Um corpo de conhecimentos de fato aberto e democrático seria uma resposta e tanto. Esperta, no bom sentido, ao reconhecer que sempre haverá mais inteligência fora do que dentro do comitê que elabora o BABoK, por capacitado que ele seja. Seria, acima de tudo, uma resposta catalisadora, que tornaria a comunidade de análise de negócios mais próxima e atuante. O que impede esse salto?

    Notas

    1. O que não significa que não haverá confusão em outros contextos. Mais sobre isso em um futuro artigo.
    2. Em dados de 2012. O relatório financeiro do IIBA é aberto.
    3. How to Break In a New Book é uma foto-dica de Jocelyn McAuley.
  • IIBA x PMI-PBA

    IIBA x PMI-PBA

    O título antecipa um artigo enjoado. Por isso tentarei ser breve. Há pouco mais de um mês, um colega avisou que o PMI estava lançando uma certificação para analistas de negócios: PMI-PBA (Professional in Business Analysis). Não me surpreendi. Consultei amigos da área e folheei artigos na Internet tentando entender o impacto da notícia. Sigo sem condições de mensurá-lo. O que não me impede de jogar alguns gravetos nessa curiosa fogueira.

    Curiosa porque trata de uma concorrência entre dois institutos sem fins lucrativos, IIBA e PMI. No entanto, ambos movimentam muita grana e nutrem milhares de negócios mundo afora. Fato que deve tornar esse duelo um tanto mais quente nos próximos meses e anos.

    A novidade do PMI não surpreendeu porque parecia um desenvolvimento óbvio. No distante agosto de 2009, em “BABoK: Uma Leitura Crítica”, escrevi o seguinte¹:

    O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação (sic) de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos  duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

    As faixas de gaza criadas pelo BABoK passaram a justificar eventos e artigos que nos ajudariam a “promover uma convivência pacífica entre gerentes de projetos e analistas de negócios”. Criou-se uma guerra com o objetivo de levantar bandeiras brancas? Se uma função tem caráter gerencial e a outra operacional, por que cargas d’água haveriam conflitos? Não importa mais, o estrago já foi feito.

    E a resposta do PMI é pesada. E nem cita o BABoK nominalmente. Ciente do potencial de crescimento da função nos próximos anos², o PMI lança um exame antes mesmo de publicar um BoK ou algo parecido. Por enquanto, ele divulga apenas um esboço (outline) do conteúdo, estruturado em cinco domínios:

      • Avaliação de Necessidades
      • Planejamento
      • Análise
      • Rastreabilidade e Monitoramento
      • Avaliação (da Solução)

    Quem tem um mínimo de intimidade com o BABoK não sentirá dificuldade em fazer um “de-para”. E a relação óbvia das tarefas descritas em cada domínio é com a “abordagem orientada ao planejamento”. Um pouco mais trabalhoso será o relacionamento entre o conteúdo do BABoK e a genérica lista de 40 “Conhecimentos e Habilidades” que encerra o esboço. Se o BABoK tem alguns balaios de gato (Competências Fundamentais e Perspectivas), essa lista do PMI é um primor de confusão. Como nenhum desses “conhecimentos e habilidades” será cobrado diretamente no exame, é de se questionar sua publicação. Para que servem? Se for para desencargo de consciência, esquece. NEGÓCIOS mal são citados ali!

    Este será um duelo do tipo Davi X Golias. O PMI tem mais de 500 mil profissionais certificados em todo o mundo. Deve ter batido ou estar em vias de bater o número de um milhão de membros. Suas receitas em 2012 ultrapassaram US$ 170 milhões. O IIBA conta com cerca de 28 mil membros e pouco mais de 3 mil certificados emitidos. Faturou US$ 4,7 milhões em 2012. A diferença de idade – 45 anos de PMI e 10 de IIBA – explica parcialmente a disparidade dos números. Reconhecimento da função, áreas de aplicação e conhecimento da “marca” são fatores que não podem ser menosprezados.

    Enfim, o potencial de “estrago” que o PMI pode causar neste mercado é pra lá de considerável. A concorrência é salutar – sempre é – apesar de estranha em um primeiro momento. Se ela se tornou possível é porque um padrão não foi estabelecido. É improvável que isso aconteça em uma área tão ampla e difusa como a análise de negócios. Se a concorrência ajudar a elevar o nível das conversas e, principalmente, da qualidade da análise de negócios praticada, todos sairão ganhando. Sinceramente, eu gostaria de acreditar nisso³.

    Notas

    1. Por curiosidade reli “BABoK: Uma Leitura Crítica” e todos os 43 comentários que ele mereceu. Que conversa rica. Onde esse tipo de papo tem acontecido atualmente? O que estou perdendo?
    2. Nos EUA, esse potencial seria de 19% até 2022, segundo o US Bureau of Labor Statistics. Acho que não temos estudo parecido aqui no Brasil. Mas a revista Você S/A de novembro de 2013 mostrou que analistas de negócios podem ter aumento de salários de até 19% neste ano. Este aumento, três vezes acima da inflação projetada, seria reflexo de uma demanda bem maior que a oferta. A conferir.
    3. Mas não acredito. Porque estou cansado de ver certificações sendo usadas como fim, não como meio; Porque não acredito que uma prova de múltipla escolha seja suficiente para definir minimamente quão bom ou ruim é um gerente de projetos ou um analista de negócios; Porque desconfio que o duelo colocado descambará para política, preços, “reputação” e diversos outros fatores, menos para a Análise de Negócios. Enfim, porque tenho muito mais razões para ser cético do que o contrário. Infelizmente. Mas vou torcer para que o IIBA se mexa e resista. Porque acho seu propósito mais nobre e sua visão de análise de negócios mais completa.
    4. “White Rabbit vs. Rabbit”, a foto que utilizada neste artigo, é mais uma prova de que a imagem (certa) vale por 916 palavras. Seu autor é JD Hancock.
  • Crise de Identidade

    Crise de Identidade

    No consultório do Dr. Malemá, psicólogo.

    Malemá: Diga Antônio, o que lhe aflige?

    Antônio: Não sei mais quem eu sou, doutor. Não sei o que faço, pra quem devo fazer, o que devo entregar. Não consigo explicar para meus parentes e amigos qual é a minha profissão. E as perguntas que eles fazem, doutor, céus… me deixam com mais dúvidas. Minha vida era mais simples quando eu era só analista-programador. Falava que programava computadores e todo mundo entendia. Agora não, inventaram que sou analista de negócios e minha vida virou de cabeça pra baixo.

    Malemá: Analista de negócios?!?

    Antônio: Ah não, doutor, o senhor também? Não começa não, por favor…

    Malemá: Calma Antônio, tô aqui pra ajudar. Uma mudança de profissão não pode levar alguém ao ponto de procurar um psicólogo. Ainda mais quando nem tem plano de saúde. O que pode haver de tão terrível nesta função?

    Antônio: Tudo doutor, tudo… Dizem que tenho importância estratégica – meu contracheque contradiz. Dizem que tenho que resolver problemas das partes interessadas – nome chique para usuários e clientes, entende? Então, tenho que atendê-los, como falaram em um cursinho de dois dias, com o máximo de habilidades sociais. Eu tento… mas eles vivem insatisfeitos. E mal educados, impacientes. Quando levo suas reclamações para quem tem de resolver de verdade, os que continuaram programadores (suspiro – inveja), levo mais porrada. Não adianta dizer que sou só o mensageiro. Sou detestado, doutor, por todos. (Suspiro – choro).

    Malemá: Analista de negócios… espera, calma. Sabe, também sou chamado de analista. Não gosto, mas o nome explica o que faço. Eu analiso pessoas. Você analisa negócios. Não pode ser assim tão ruim.

    Antônio: Você – posso usar você, né? – então, você não tá entendendo doutor. Você analisa dezenas ou centenas de insanos irados simultaneamente? Não, né? Então, mas eu faço isso todo dia!

    Malemá: Não seria um problema específico da empresa onde trabalha? Já considerou a possibilidade de uma mudança?

    Antônio: Participo de um grupo de discussão, doutor. Quase todo mundo reclama das mesmas coisas… É um mal generalizado…

    Malemá: Então por que você não pede para voltar para sua antiga função?

    Antônio: Ah, pegaria mal, né doutor? Ainda mais depois de eu ter defendido a criação da análise de negócios lá na firma. Dizia – como fui ingênuo – que resolveria quase todos os nossos problemas. Além disso, doutor, nunca gostei muito de programar não. Tenho um amigo que diz que meu código parece escrito pelo Joyce – saca, aquele do Ulisses?

    Malemá: Entendo… Só não entendo como um profissão – ela é nova? – pode ser assim tão mal definida. Vocês têm uma representação, um órgão que os defina e defenda?

    Antônio: Tem sim doutor, é o iba – escreve I-I-B-A. É ele que publica o babok – B-A-B-O-K -, nosso corpo de conhecimentos.

    Malemá: E esse babok não diz qual é sua função e como você deve ser empregado?

    Antônio: Ah, mais ou menos, doutor. Ele ajuda a gente a fazer entrevistas, coletar requisitos, esse tipo de coisa, entende?

    Malemá: Não, mas não vem ao caso. Mas ele define sua função, não define? Eu entendo que o corpo de conhecimentos de uma profissão começa exatamente pela definição desta, certo?

    Antônio: Peraí (ligando o laptop), tenho uma versão digital aqui. É que não consegui decorar ainda, sabe?

    Malemá: (Paciente, inexpressivo, consulta o relógio).

    Antônio: Só mais um segundinho… é que esse Windows demora pra butá.

    Malemá: (Outra olhada no relógio, mesma cara. Quatro minutos e contando…)

    Antônio: Pronto. O senhor quer a definição, né doutor? Ainda bem que saiu a versão em português. Peraí… tô achando… Achei! É a definição de análise de negócios, tá doutor? É a seguinte: “Conjunto de atividades e técnicas utilizadas para servir como ligação entre as partes interessadas no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas.”

    Malemá: Essa é a definição?

    Antônio: É doutor, bem completa, não acha?

    Malemá: Você já tentou mostrar ela para sua mãe, sua esposa ou para um colega de outra área?

    Antônio: Ah, nem tentei não doutor. Acho que eles não entenderiam nem metade desse papo…

    Malemá: E você não acha que isso é um problema?

    Antônio: Sabe doutor, não tinha pensado nisso não até ficar sabendo de uma nova versão do babok. Pelo que li num blog eles vão mudar essa definição.

    Malemá: Opa…

    Antônio: Acho que guardei aqui no nôte em algum lugar, peraí…

    Malemá: (Relógio – faltam 5 minutos para encerrar a consulta).

    Antônio: Sabia, tá aqui nos favoritos. Mudaram bem, viu doutor. Olha só:  “A prática de promover mudanças no contexto organizacional através da definição de necessidades e recomendação de soluções que entregam valor às partes interessadas.” Deu uma boa enxugada, né doutor?

    Malemá: (Cara de quem entendeu tudo)

    Antônio: Fala doutor, o que o senhor achou?

    Malemá: Faz quanto tempo que esse negócio, digo, essa profissão existe?

    Antônio: Ah, acho que já vai pra uns seis ou sete anos. Com o babok, né? Porque acho que ela é bem mais antiga…

    Malemá: Entendo… E todo mundo trabalha com essas definições na boa?

    Antônio: Sem problemas… é assim que vejo eles apresentarem nos seminários, cursos, palestras. Mas, qual é o problema doutor?

    Malemá: Filho, o problema é que você não tem a menor ideia do que faz.

    Antônio: Ah, mas isso eu sei. É por isso que estou aqui, oras…

    Malemá: Sinto muito Antônio, mas acho que não vou conseguir resolver seu problema.

    Antônio: Pô doutor, o senhor não é analista?

     

    Nota

     

  • BA Brazil 2011: Balanço, Reflexos e Reflexões

    BA Brazil 2011: Balanço, Reflexos e Reflexões

    Aconteceu na última semana, em Porto Alegre, a 1ª Conferência Brasileira de Análise de Negócios – o BA Brazil 2011. Transcrevo neste artigo minhas experiências e considerações sobre o evento. E trago para cá conversas e provocações que, acredito, merecem reflexões e debates.

    ?

    Se fosse preciso resumir tudo em uma única palavra ela seria: Show! Show de organização. Show diversificado. Show com lotação praticamente esgotada. O BA Brazil provou a força da comunidade e como o trabalho voluntário move e remove montanhas. Se alguém ainda tem dúvidas sobre a combinação dos termos “planejamento” e “métodos ágeis” ou sobre a utilização dos últimos fora da seara do desenvolvimento de sistemas é porque não viu o BA Brazil. Créditos para o time do IIBA e todos os parceiros que ajudaram a viabilizar o evento. Evito citar nomes para não cometer nenhuma injustiça. Todos estão de parabéns.

    Infelizmente, por problemas de agenda, não pude ver praticamente nada dos dois dias de palestras e espaços abertos. Mas tive tempo suficiente para rever amigos de Brasília, Floripa, Sampa e Rio. E, claro, pude assistir a palestra de abertura ministrada por Shane Hastie. Shane explicou “porque precisamos de Análise em Projetos Ágeis”. Você acha estranho que esse tipo de “explicação” ainda seja necessária? Eu achava. Mas a conversa do Shane foge do lugar comum. E mira dois alvos: também fala sobre métodos ágeis para analistas de negócios. Seu discurso é sereno, objetivo e bem ilustrado. Seria impossível e injusto destacar algum ponto. Prefiro resumir assim: eu queria que mais executivos e agilistas tivessem a oportunidade de ouvir e conversar com Shane. Só isso.

    Eu tive essa oportunidade, em cafés, viagens de táxi e jantares. E as primeiras coisas que você nota em Shane, além do profundo conhecimento dos temas que aborda, são sua humildade e generosidade. Em questão de pouquíssimas horas “viajávamos” pelas necessárias revisões do BABoK®, a sentida ausência dos casos de uso no draft da extensão ágil¹, a corrupção no Brasil (e suas similaridades com a África do Sul, país onde Shane morou por alguns anos), a beleza das mulheres de Porto Alegre, churrasco, caipirinhas (with two you get to the limit of liability!) e nossas experiências profissionais. Não necessariamente nessa ordem.

    Em outro dia, quando compartilhávamos a mesa com Suzandeise Thomé, Luiz Parzianello, Marcelo Neves e Willen Dijkgraaf, chamei a atenção para a forma como Shane destacava sua não concordância com algum tema. Por exemplo: “Arquitetura Corporativa”. Shane desacelera e calibra a dicção, frequentemente soltando um “fundamentally wrrrrrong!”.  Aquele “Wrrrrrong” soa como um trovão. E não deixa a menor dúvida sobre sua posição. O que não significa que a conversa tenha se encerrado, pelo contrário. Está apenas começando!

    Acompanhei de longe a repercussão do restante do evento. Pelos comentários a única conclusão possível é de um retumbante sucesso. E a certeza de que a versão 2012 é só questão de tempo. Que assim seja!

    Reflexões

    Minha palestra aconteceu logo na sequência, ainda na manhã da quinta-feira. Falar logo após a abertura do Shane já era uma responsabilidade e tanto. De carona no presente-provocação sugerido pelo Luiz Parzianello, uma responsabilidade quase insuportável. Quando me convidou, Parzianello sugeriu o título de minha fala: “Para você, o que é Análise de Negócios?”

    Abri o papo confessando a dificuldade em condensar em quarenta e cinco minutos uma resposta que, a primeira vista, deveria ser muito simples e direta. Mostrei que apelei para um oráculo (Bob Dylan?!?) e para o pai dos burros (Houaiss) em uma busca infrutífera por inspiração. Quem leu meu artigo anterior já conhece o final da história. Meu problema não era definir a Análise de Negócios mas sim justificar a definição. E não havia mais nenhuma razão para manter implícitas ou autocensuradas duas provocações:

    1. Há, no meu ponto de vista, exagerada e arriscada ênfase na macrodisciplina  “Análise de Negócios” em detrimento de seus praticantes principais, os Analistas. Algo como: “o importante é que a Análise seja feita, não importa por quem”. Concordo que a área não carece de muros ou testes como aqueles que vemos em Direito, Medicina, Engenharia e afins. Por outro lado, se não existirem profissionais especializados e orgulhosos de sua área, como podem a disciplina e respectivo corpo de conhecimentos evoluir? Não é de hoje que é notória a baixa autoestima dos Analistas de Negócios, particularmente dos tupiniquins. Existem razões mil para tanto – sendo a principal a confusão com “tiradores de pedidos²”. Mas não melhoramos a situação com o discurso vigente. Em suma: se queremos uma Análise de Negócios forte e reconhecida precisamos fortalecer e reconhecer os Analistas de Negócios. Eles não são nada menos que fundamentais para o futuro da disciplina.
    2. Não estava escrito em nenhum slide que utilizei mas acho que falei mais ou menos assim: “Se tivermos legítima preocupação com a Análise de Negócios em médio e longo prazos, então é hora de decretar sua independência de TI“. Reconheci que devemos ser eternamente gratos pelo fato de TI ter ressuscitado e viabilizado a área. Mas é chegada a hora de debater se queremos ou podemos limitar o uso da disciplina exclusivamente em problemas de negócios que envolvam Tecnologia da Informação. Apresento novamente mea culpa. Tenho vinte e cinco anos de vida profissional e sempre trabalhei com TI. Meu trabalho se limita a TI. Mas meu trabalho é só um grãozinho de areia, sem falsa modéstia. Quero crer que o público presente, pelas questões apresentadas, entendeu bem o recado. Até quando sugeriu, para minha concordância, que o Analista de Negócios é o Novo Novo Analista de Organização & Métodos.

    Testando o {FAN}

    Se o {FAN} 2012 precisava ser puxado até o limite, ele conseguiu em PoA. Foram duas turmas, uma delas não programada originalmente. E entre os quase setenta participantes uma diversidade grande, muita sede, muitas dúvidas e bastante colaboração. Ligeiras conclusões:

    • O programa está perigosamente no limite de sua carga horária. Já penso seriamente em uma versão com 20 horas distribuídas em três ou cinco dias. Na próxima semana, em turma fechada e com 24 horas ao meu dispor, farei novo teste.
    • Algumas atividades podem “sujar” mais paredes. A turma via o curso do Shane ao lado e gostava de todos aqueles displays.
    • Aliás, posso contemplar em algumas turmas o trabalho de derivação de casos de uso em histórias e tarefas. E tornar a montagem de diagramas PUCS uma atividade mais interativa, fazendo toda  a sala montar um único diagrama.
    • Preciso rever o último sprint, que acontece logo após um coffee-break. É um tour-de-force com cerca de duas horas de duração e sem nenhuma interrupção – nenhuma atividade prática. É uma longa história que conto, mostrando como os analistas de negócios trabalham em conjunto com o time de desenvolvimento em busca de uma solução. É legal – acho que todos gostam. Mas chego ali estourado, com voz e pernas extenuados. Ok, preciso melhorar minha condição física. Mas acho que é possível quebrar aquela história de forma a torná-la menos cansativa.

    Tks!

    Suzandeise Thomé, Luiz Parzianello e Marcelo Neves, pelo voto de confiança e pela oportunidade. Oferecer tão generoso espaço para um chato e crítico frequente do IIBA é prova incontestável da maturidade e do espírito democrático dos Chapters brasileiros. Vocês sabem, seguirei chato e crítico. Mas seguirei também um fã incondicional do trabalho de vocês. Parabéns!

    Thank you, Mr. Shane Hastie, for your generosity, the shared knowledge and the patience with my bumbling english. 

    Simone Kosmalski, pela hospitalidade, atenção e organização.

    Melissa Trevisan e Marta Py, pelo trabalho, força e confiança.

    Willem Dijkgraaf, pelo apoio e pelo feedback.

    E muito obrigado a todos que tornaram o BA Brazil 2011 possível.

    Observações:

    1. Shane justificou a ausência (de casos de uso na extensão ágil do BABoK®) dizendo que a técnica já está devidamente coberta no BABoK® 2.0. Mas alertei, a ele e ao Parzianello (que também trabalha naquela extensão), que talvez o texto esteja passando a impressão (equivocada) de que no mundo ágil só se trabalha com histórias de usuários. Prometi ser mais específico na leitura crítica que publicarei antes para eles e depois aqui no {finito}.
    2. Perdi a oportunidade de fazer um teste de DNA e tirar dúvidas sobre a paternidade do termo “tirador de pedidos”. Mas aproveito para registrar aqui outra coisa que o Analista de Negócios NÃO é: “traficante de picuinhas!” Qualquer dia compilo todos os “criativos” termos criados para desmerecer e desmotivar o mau uso da profissão.
  • {FAN} 2012

    {FAN} 2012

    Lancei na última semana, em São Paulo, a versão 2012 do {FAN} Formação de Analistas de Negócios. É uma versão especial porque celebra o quinto ano do programa. Aproveitei o impulso do BA Brazil, que acontece daqui a duas semanas em Porto Alegre, para antecipar o lançamento. Apresento neste artigo a estrutura, alterações e extensões da oficina.

    ?

    Não acredito que um dia o núcleo duro do {FAN} seja alterado. Desde o longínquo junho de 2007, quando foi apresentada ao público pela primeira vez, esta oficina está estruturada em torno de duas grandes disciplinas: Modelagem de Negócios e Requisitos. Aprendi depois de um tempo que deveria utilizar uma explicação relativamente simplista para justificar a estrutura: a primeira disciplina nos ajuda a entender um negócio; a outra concentra-se no entendimento das necessidades e restrições de usuários e outros interessados. Cada uma merece 50% da carga horária. A divisão arbitrária – um dia para cada disciplina – tem fins didáticos. Os participantes devem entender que lançam mão de ambas simultaneamente durante toda a sua participação em um projeto. Eles entendem.

    Assim como entendem o fato deste evento não se basear na estrutura proposta pelo BABoK®. É fácil fazer um ‘de-para’ quando necessário. Como o foco da oficina não é a certificação, mas o trabalho prático com a Análise de Negócios, nunca ninguém reclamou. Cito o corpo de conhecimentos oficial quando necessário, seja para destacar algum problema ou boa solução. Tanto que falo até hoje sobre a versão 1.6 e seu bom capítulo sobre “Elicitação” de requisitos.

    Deixo a impressão, até aqui, de que não mudou muita coisa no {FAN}. É que comecei pelo que não mudou. Vamos às alterações. A versão anterior, que utilizei até outubro deste ano, tinha 200 slides no arquivo de apresentação. A nova versão conta com exatos 299! Um acréscimo de praticamente 50% e a mesma carga horária? Como isso seria possível?

    Fiz um levantamento de todos os tópicos que, a partir da interação com os participantes, exigiam improvisos em um quadro branco. Apesar de gostar de toda aquela dinâmica, percebi que perdia um tempo precioso rabiscando. Pior: ficava muito tempo de costas para a plateia. Todos os improvisos que ficaram frequentes mereceram slides. Praticamente todo um novo tópico sobre estimativas, priorização e definição de escopo brotou dessa decisão.

    Eliminei também o ridículo “ditado” de uma especificação de caso de uso que servia como exemplo. Mantenho a apresentação passo-a-passo de um caso, mas agora os alunos ficam livres para prestar atenção no que de fato interessa. Três atividades práticas os deixam rabiscar e abusar do novo modelo que apresentei no artigo anterior.

    E por falar em atividades práticas: são 11 no total. E, a partir de agora, nenhuma é opcional. Elas totalizam cerca de 240 minutos, quatro horas de um total de quatorze. Ou seja, cerca de 30% da oficina é totalmente prática. Parece pouco, mas me lembro dos tempos em que o {FAN} era FAN e tinha apenas 4 atividades. E de sua “pré-história”, quando não havia exercício algum.

    Todos os exercícios são posicionados de forma a reforçar ou demonstrar a parte teórica recém apresentada. E são baseados em um mesmo problema de negócio. Mantenho a estratégia de não fixá-lo nas apresentações ou na apostila. Isso permite que a cada turma eu possa sugerir um novo. Também possibilita que em cursos fechados sejam utilizados projetos reais dos clientes. Na última edição eu ressuscitei o imbróglio do ‘seu’ Moreira – português fabricante de pãezinhos que precisa dobrar a produtividade de seus vendedores. Em PoA eu devo trocar a nacionalidade do preocupado e seu produto: de pão para vinho.

    Outra mudança significativa está no número de ferramentas apresentadas, particularmente no módulo de modelagem. Incorporei novas sugestões, inspirado principalmente por dois trabalhos: Business Model Generation¹ (o ‘canvas’) e Gamestorming². Mantenho o Pensamento Visual como método de modelagem, mas sem a ênfase que ele mereceu nas versões anteriores. Ao ‘esconder’ o método e apresentá-lo apenas no final do primeiro dia eu consegui, por incrível que pareça, facilitar seu entendimento.

    No final do segundo dia também acontece um momento flashback, desta vez revendo todo o evento e demonstrando um método para definição do escopo inicial de um projeto. Conto uma história onde o analista tem dez dias úteis para entender um problema e, junto com o time, tentar descobrir a melhor solução. Funciona realmente como uma grande revisão da oficina, da famosa fotografia 2km X 2cm até o detalhamento de casos de uso. É uma das partes que eu costumava improvisar e que ficou muito melhor com o apoio visual pré-concebido.

    Agora deixei a impressão de que foi tudo perfeito no ‘teste beta’ que executei, o que não é verdade. Peguei uma turma que ficou muito silenciosa (assustada?) no primeiro dia. No segundo, se soltaram e interagiram bem mais, comigo e entre eles. Mas fiquei com a pulga atrás da orelha: a sobra de trinta minutos em cada dia é real? Só terei certeza depois das duas oficinas no BA Brazil. Encontrei um bug mais sério só no segundo dia, o mal posicionamento da atividade #8. Mas foi muito pouco para evento tão extenso. Sorte de principiante? Hehe… pode ser.

    Outro probleminha: a apostila está mais bonita, melhor diagramada. Agora ela tem espaço para a resolução dos exercícios. Não pretendo mais distribuir blocos separados para eles. Acontece que o pessoal ficou com dó da apostila. Muitos não quiseram rabiscá-la. Mesmo com minha promessa de que a versão digital está disponível para download. O que fazer? Ah, se eles vissem como trato meus livros de papel…

    Meio & Mensagem

    Mudanças cosméticas; inserção pontual de ferramentas; maior cuidado com atividades práticas. O {FAN} nunca ficou parado no tempo e em seus quatro anos e meio de vida sempre apostou que podia ser bem melhor. Mas a nova versão traz uma mudança maior, não citada até agora.

    Em meu entendimento, a “onda” em torno da Análise de Negócios passou. Assim como já ficou para trás a “moda” Scrum. É uma aposta que torno pública: vocês verão muitos entusiastas de primeira hora vestindo novas roupas, estampando novas cores e reciclando promessas. Trata-se do melhor momento de todas as ondas. Porque o que fica é o que de fato interessa. O que passou era entusiasmo (e oportunismo) e nada além disso.

    O {FAN} 2012 incorpora esse espírito. Entende que a Análise de Negócios, que a necessidade dela, sempre existiu e sempre vai existir. Mas há um tanto de mea culpa no novo discurso. Motivado, principalmente, pelo advento dos Arquitetos de Negócios. Eles não seriam sugeridos se nós, envolvidos com a formação de analistas de negócios, tivéssemos feito um bom trabalho. Mas é só outra moda. Não deve preocupar.

    Preocupa, isso sim, que os bons analistas de negócios não desanimem. Para isso acho que é fundamental provar sua criticidade no cotidiano de uma organização. Não apenas na solução de problemas de TI. Analistas de negócios não dão manutenção em sistemas! Analistas de negócios não são “tiradores de pedidos”! Analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios. Qualquer tipo de problema.

    Posicionados a partir da definição acima os analistas de negócios se verão desafiados por domínios cognitivos de maior dificuldade. Não basta a análise – o estudo das diversas partes de um todo (Houaiss). O analista não é nada menos que fundamental na síntese – na destilação da tese proveniente daqueles que têm problemas e da antítese colocada pelos eventuais provedores de soluções. É peça fundamental – meio e mensagem – em um diálogo verdadeiramente produtivo.

    Enfim, o {FAN} 2012 traz uma mensagem otimista embalada em belos desafios. Desenha-se em torno de duas disciplinas que definem as habilidades técnicas que um analista de negócios deve desenvolver. Mas é guiado por um conjunto que, por falta de termo melhor, tenho chamado de Habilidades Essenciais: Solução de Problemas, Análise, Síntese, Gestão do Conhecimento e Aprendizagem Organizacional, Comunicação Corporativa, Pensamento Criativo, Pensamento Sistêmico, Pensamento Visual, Teoria da Complexidade etc. Eu sei, assusta. Mas posso garantir: é apaixonante. Por isso seguirei teimando que essa é uma das melhores profissões do século XXI. Quem sobreviver (à onda), verá.

    Extensões do {FAN}

    Há meses brigo com uma ideia: liberar módulos curtos, com três horas de duração, para apresentação e aprofundamento de tópicos específicos do programa {FAN}. Como é impossível prever sua aceitação, farei testes reais em janeiro do próximo ano. Não exigirei participação prévia no {FAN} tradicional de 14 horas. Esta primeira geração do que estou chamando {FAN Fast} é formada por quatro módulos:

    • Introdução à Análise de Negócios: apresentação da área, seu corpo de conhecimentos & habilidades e as responsabilidades de um analista de negócios em uma organização e em projetos. Tiro curto dirigido a todos que ainda precisam conhecer a função/profissão e saber como tirar melhor proveito dela em suas empresas.
    • Aprendendo Requisitos, Contando Causos e Histórias: aprendizagem, estruturação e desenvolvimento de requisitos de forma prática e direta. Há tempo muita gente tenta contratar apenas o segundo dia do {FAN}, aquele que trata especificamente de requisitos. Este módulo é para eles e todos que queiram mergulhar um pouco mais no tema.
    • Conversando (e Rabiscando) a Gente se Entende: novamente inspirado pelos livros citados acima. Ferramentas práticas que facilitam a comunicação com usuários, clientes e outros interessados. Outras ferramentas, além daquelas apresentadas no {FAN}, serão exercitadas aqui.
    • Trabalhando com Scrum e outros Métodos Ágeis: para analistas e gente de negócios que precisam saber como se comportar (hehe) em projetos guiados pelo framework Scrum ou outros métodos ágeis. O que muda na atuação de um analista? E o que não deveria mudar? Evento prático e divertido que mostra a importância de um analista na formação de um “time de (dono de) produto” e no trabalho com métodos ágeis.

    Todos os módulos são ‘levemente acoplados’. Ou seja, você contrata apenas aquele ou aqueles que te interessar. Não haverão (muitas) referências cruzadas, nem mesmo com o {FAN} tradicional. Nesta primeira leva, apenas uma restrição: os módulos acontecerão durante a semana, em dias consecutivos e em período noturno. Em breve publico as páginas dos eventos e divulgo a agenda.

    Upgrade

    Em 2010 ofereci, de graça, um FAN Upgrade. Foi muito curto e serviu para rever amigos. Passados quase dois anos, hora de agendar uma nova atualização. E ela se dará através da participação no evento tradicional, com 14 horas de duração! Desta vez o evento será pago (assim quem se inscreve realmente participa, né?) Mas terá descontos progressivos. Quanto mais antiga sua participação no FAN, menos você paga. Quem participou das turmas de 2007 e 2008, por exemplo, tem desconto de 50%.

    O Upgrade está agendado em programação especial de férias: acontecerá em São Paulo, nos dias 13 e 14 de janeiro. O site da Tempo Real Eventos já está recebendo inscrições: http://www.temporealeventos.com.br/?area=15

    ?

    Observações:

    1. Business Model Generation – Inovação em Modelos de Negócios
      Alexander Osterwalder – Alta Books (2011)
    2. Gamestorming – A playbook for Innovators, Rulebreakers, and Changemakers
      Dave Gray, Sunni Brown e James Macanufo – O’Reilly (2010)
    3. “Creating Solutions”, de HikingArtist.com, é o título do cartoon utilizado neste artigo.
  • Os Arquitetos (de Negócios) estão Chegando

    Os Arquitetos (de Negócios) estão Chegando

    Estão chegando os arquitetos (de negócios). E a tendência (nova moda?) estava tão fácil de ser percebida que não me perdoo. Fiquei uma hora batendo minha cabeça no teclado e berrando, entre gritos de dor, “beócio! É a arquitetura (de negócios), beócio!”. Brincadeirinha. E nem posso me condenar tanto assim. Afinal, em outubro do ano passado eu já estava falando sobre Arquitetura do Negócio. O assunto estava tão gelado na época que mereceu dois comentários, além de minhas respostas. Agora, oito meses depois, acho que ele sai do frio para o morno rapidinho. Justifico minha suspeita neste artigo.

    ?

    Anteontem, dia 14/junho, o InfoWorld publicou uma lista com as seis “mais quentes” novas profissões em TI¹. Hottest job nº 1? Arquiteto de Negócios. Peço desculpas antecipadas pelo veneno que escorrerá na sequência, mas o InfoWorld não ajudou: o trabalho mais quente em TI não é de TI?!? Está lá no texto: “o arquiteto do negócio é um membro da organização do negócio e reporta-se ao CEO”. E o que ele faz? “fashionaliza (ai!) a estratégia de alto nível da empresa com a tecnologia em mente”. Perdão, mas nem o Google Translate conseguiu trazer “fashioning” para o português. E como temos vários adoradores de termos chiques e da moda aportuguesados nas coxas, porque não fashionalizar? O problema é o Tite começar a se preocupar com a fashionabilidade de seu time. Chega! Meu corretor ortográfico não suporta mais neologismos bestas.

    O advento da Computação na Nuvem (leia-se, aplicativos muito sexy e algumas vezes úteis que estão a um clique de distância) deixa gerentes de negócios com água na boca e coceira nos dedos. Por que esperar meses ou anos por um projeto da área de TI se posso contratar um serviço na Internet em questão de minutos? Segundo o artigo da InfoWorld, “o trabalho do arquiteto de negócios é armar os gerentes com o conhecimento que eles vão precisar para fazer boas escolhas “. Seria, em outras palavras, “adeus CIO, tchau departamento de TI, bye bye, so long, farewell…”? O texto não responde. Aliás, ele nem faz a pergunta. Afinal, onde entram CIO e sua área neste negócio? (Perdão pelo trocadilho).

    Quem tem ou começa a ter cabelos brancos, como este que vos escreve, já viu este filme antes. Em preto e branco, digo, em fósforo verde. Tem início lá na segunda metade dos anos 1980, quando a microinformática começou a invadir as empresas. Foi assim que nasceu o que hoje conhecemos como “planilhódromo”, outro neologismo besta que resume aquela incomensurável quantidade de planilhas eletrônicas que tapa buracos dos softwares empresariais. Aquele foi o primeiro grito de independência de nossos queridos usuários insatisfeitos com nossa agilidade em atender suas demandas. Pelo visto, a Nuvem e suas suculentas e fáceis ofertas dão argumentos para o segundo grito. Seria esta a justificativa para a “invenção” de um arquiteto de negócios? Segundo a InfoWorld, sim. Se for, salve-se quem puder. E para o mundo porque eu vou descer agora.

    Eu acho, e apenas acho, que eles acertaram o remédio mesmo com um diagnóstico muito equivocado da doença. Como escrevi naquele velho artigo, temos duas grandes motivações para desenhar e cuidar da arquitetura de um negócio: i) Entendê-lo; e ii) Avaliar a prontidão de TI (ou de qualquer outra área de apoio). E não é de hoje, nem de ontem, que tento mostrar que os analistas de negócios desempenham esta função. Querendo ou não, de forma estruturada e pensada ou não. Avaliar se determinada tecnologia, aplicativo ou brinquedinho (gadget) é adequado para um negócio é, desde o início dos tempos, uma das diversas atribuições que podem ser delegadas para analistas de negócios.

    Não tem muito tempo que inventamos o Arquiteto Corporativo. Agora, chega esse Arquiteto de Negócios. Até quando seguiremos inventando falsas especializações e acreditando que este tipo de trabalho é coisa para uma pessoa só?

    O BABoK® vem na Cola?

    Um passarinho me contou que sim². Disse que o IIBA estaria trabalhando em uma nova extensão para o BABoK, uma extensão que falaria exclusivamente sobre Arquitetura do Negócio. Outra bullshitagem passageira? Pergunto porque, um ano atrás, anunciaram uma tal “Extensão Ágil”. Depois de um comedido bafafá e um ridículo draft de 24 páginas, não vi mais nada sobre o assunto. Espero estar errado. Aquela extensão é necessária.

    Assim como é necessário que o BABoK saiba falar sobre Modelagem de Negócios. Mesmo que isso se dê pela via torta (e pelo chique nome da moda) da Arquitetura de Negócios. Só é uma pena que a comunidade de AN’s, particularmente a tupiniquim, gaste tanto tempo com picuinhas, festinhas e eventos chuchu (que repetem ad nauseam as maravilhas do BABoK). Se gastassem 10% de seu precioso tempo na evolução daquele “corpo de conhecimentos” o mundo seria um lugar melhor para se viver.

    Os Arquitetos já Estão entre Nós

    Chegaram em um dos meus clientes. Mas ele não sabia que InfoWorld e IIBA falariam sobre isso. Na realidade, por uma série de motivos, o cliente resolveu dividir o papel dos analistas de negócios em dois: Arquitetos de Negócios e Analistas de Requisitos. Os primeiros atuariam de forma mais próxima ao negócio, apoiando desde a definição do portfólio de projetos até o ponto em que um trabalho mais braçal possa ser delegado para os segundos. Não gosto do desenho, mas entendo e respeito as justificativas para ele. Como é um trabalho que mal começou, ainda não posso falar sobre os resultados. Espero poder fazê-lo em breve.

    Conclusão?

    Preciso mesmo concluir? Meu encosto-writer acha que sim. Posso dar uma de Dr. House? Então, lá vai: Se você é ou pretende ser um Analista de Negócios, então esqueça o papo sobre Arquitetos de Negócios. É só outro nome que inventaram para você que já foi, é ou pretende ser: analista de requisitos, analista de processos, analista de processos de negócios, business designer, use-case specifier, requirements reviewer etc³. Mas, atenção: siga com curiosidade e carinho tudo o que se refere a Arquitetura de Negócios. Inté!

    Observações:

    1. As outras cinco profissões também parecem ser bem divertidas. Não me segurei e as apresento brevemente, e sem tanto veneno, lá no GRAFFiTi.
    2. Apesar de confiar bastante no passarinho, fui dar uma conferida (preguiçosa) no amigo Google. Não encontrei nada sobre a extensão, mas vi muito evento do IIBA (ou de gente do instituto) falando sobre Arquitetura do Negócio. Separei dois exemplos: 1, 2.
      Ganha um picolé de chuchu o primeiro que começar a falar por aqui sobre como um AN pode “alavancar” a Arquitetura de um Negócio. Depois da crise de 2008, o termo “leverage” e seu risível correspondente tupiniquim “alavancar” deveriam ser banidos dos dicionários.
    3. Se assustou com a extensão da lista? Saiba que um dia ela já pintou, por exemplo, no RUP. E aceite que é assim, e talvez agora como Arquiteto de Negócios, que muitas empresas tratam e seguirão tratando aquela(e) que por aqui é conhecida(o) como Analista de Negócios.
    4. “sigurd lewerentz, florist, 1969“, a imagem utilizada neste artigo, é de seier+seier e foi liberada sob licença CC-by.

     

  • Um Corpo de Verdade

    Um Corpo de Verdade

    Como prometi no último artigo, vou tentar liberar uma série de textos mais construtivos sobre Análise de Negócios. E por onde eu deveria começar? Já tinha uma ideia. O colega Jefferson Velasco deu o empurrão que faltava ao comentar que o processo de seleção de analistas de negócios (AN’s) costuma ser um tanto confuso e muito exigente. Como não há uma definição amplamente aceita sobre o papel de um AN, pedem e buscam de tudo nos currículos e testes. Esta é a questão que tentarei responder neste artigo: o que devemos cobrar de um AN? O que um AN estuda, aprimora e domina? Afinal, qual é o CORPO de conhecimentos que o define?

    ?

    A sensação de eterno reset me incomoda também. Estou cansado de ver artigos sobre o mesmíssimo assunto. Acontece que boa parte dos problemas que reportei no artigo anterior tem a ver com isso, com a má compreensão do papel e responsabilidades de um AN. Por isso decidi voltar ao básico e arriscar o desenho de um CORPO de conhecimentos. Por favor, esqueça o BABoK por enquanto. Lá no final do artigo eu falo sobre ele e suas diferenças em relação ao corpo aqui proposto.

    Começamos com as duas pernas. São elas que dão sustentação e movem todo o corpo. A perna direita de nosso simpático Woody (O AN Vitruviano) representa o Conhecimento do Negócio. Se a pessoa será analista de Negócios, parece lógico que iniciemos a jornada por aqui, certo? Acontece que “negócio” é um termo tão amplo e abstrato que há o sério risco desta perna ficar superdimensionada ou atrofiada. Precisamos separar dois tipos de conhecimentos do negócio. O primeiro, que vou chamar de básico (mas alguns chamarão de horizontal), é formado por disciplinas… básicas. Disciplinas que são aplicáveis em negócios de qualquer ramo ou porte. Sim, estou falando de Administração de Empresas, Contabilidade, Finanças e Marketing, principalmente. Calma! Ninguém em sã consciência vai passar a exigir dos AN’s diplomas de curso superior nessas áreas. Mas devem cobrar sim que o AN conheça: planos de contas, lançamentos contábeis, matemática financeira e um monte de etc. Esta é a primeira metade da perna, aquela que vai do pé ao joelho.

    A segunda é menos chata (hehe) e mais cheia de carne e músculos. Aqui podemos utilizar o termo “vertical” para identificar este tipo de conhecimento do negócio. Prefiro chamá-lo de conhecimento especializado. Refere-se à especialização em determinada empresa, área ou ramo de atividades. O AN pode ter experiência no ramo de seguros ou no varejo de drogas lícitas, por exemplo. É relativamente comum, particularmente em anúncios estrangeiros, que as empresas exijam este tipo de experiência, de conhecimento de um tipo específico de negócio. Reparem que citei também a especialização em “determinada empresa”. Neste caso o profissional tem tempo de casa suficiente para “saber tudo” sobre ela. Tipo de domínio muito caro em tempos de pouca fidelidade.

    A perna esquerda representa Conhecimentos de TI. Desenhei assim porque estou falando com AN’s que atuam exclusivamente em projetos de TI. Novamente é necessária uma divisão. O conhecimento básico (do pé até o joelho) condensa: conceitos fundamentais de informática, lógica de programação, modelagem de sistemas, modelagem de bancos de dados, operação de ferramentas de produtividade e colaboração e alguns etc. Há quem questione parte desta lista, principalmente os itens que falam de programação e modelagem. Insisto que um bom AN deve ter tal conhecimento para conseguir se comunicar de maneira mais eficaz com os times técnicos. Pode não ser mandatório, mas sempre será desejável. Dado o perfil de 80% dos AN’s que conheço (com formação em algum sabor de TI), não creio que isso represente um problema.

    A segunda parte desta perna, a exemplo do que aconteceu com a direita, também representa conhecimentos específicos. No caso de AN’s que atuam apenas em uma organização, estamos falando do conhecimento sobre a Arquitetura Corporativa daquela organização. Conhecer a plataforma tecnológica, os principais repositórios de dados e aplicações. Mas é importante destacar que aqui podemos ver o desenvolvimento de outra categoria de especialização: AN’s que atuam exclusivamente em projetos de determinado tipo, de BI (Business Intelligence), por exemplo.

    Como já coloquei, são as pernas que sustentam e movem o corpo. Deficiências em qualquer dos dois tipos de conhecimentos significam dificuldade de locomoção e de aprendizado. CALMA! Todos os AN’s que conheço apresentam alguma dificuldade de locomoção. É natural. Ninguém sabe tudo, e nós estamos falando de conhecimentos muitas vezes voláteis e dinâmicos (particularmente aqueles que chamei de especializados). O bom AN saberá diagnosticar e diferenciar uma unha encravada de um menisco estropiado. E saberá sanar o problema ou encontrar um bom médico. Só deve preocupar mesmo aquele AN que chega manco no fim de um projeto.

    Não estamos aqui para conversar sobre o que um AN carrega no abdômen, então pularemos diretamente para os dois braços. Não foi o acaso que decidiu a posição de cada disciplina no desenho acima. O braço direito de um AN é a Modelagem de Negócios. Porque esta é a disciplina que o ajuda a Entender um Negócio. Reparem que o lado direito dele é só negócio, perna e braço. A modelagem, o entendimento de um negócio, é condição primordial para um bom entendimento dos usuários. Coisa que conseguimos através da Engenharia de Requisitos, o braço canhoto do AN. Todo analista precisa dos dois braços. Mas muitos ainda utilizam apenas sua mão sinistra¹!

    Os braços representam habilidades técnicas que um AN deve desenvolver. É o tipo de habilidade (e conhecimento) mais fácil de ser transferido. É aqui que se posiciona, por exemplo, o programa FAN. Mas é importante notar que o domínio dessas duas disciplinas facilita a evolução das pernas (o desenvolvimento de conhecimentos sobre o negócio e sobre TI). Quem malha – quem faz musculação ou algo parecido – sabe que existem exercícios específicos e outros que movimentam pernas e braços. A analogia se aplica aqui. Por exemplo: quanto mais você praticar a modelagem de negócios, mais conhecerá sobre um negócio ou ramo de atividade.

    Mas braços e pernas são suficientes para a formação de um bom AN? Claro que não. Como o desenho acima ilustra, um AN também tem Coração e Mente. Sobre eles a gente conversa na próxima semana. Inté!

    ?

    Se este é, como o título adianta, um “Corpo de Verdade”, então o BABoK seria um corpo de mentira? Não, não há (muitas) mentiras no BABoK. Mas, como você já deve estar cansado de saber, não vou muito com a cara e o jeito daquele Corpo de Conhecimentos. Se você fizer uma comparação minimamente isenta em relação ao que foi apresentado acima, verá que o BABoK praticamente se resume a um braço esquerdo. Portanto, quem entende a profissão só pelo que viu no BABoK está contratando, formando ou se transformando em um braço esquerdo¹.

    Observações:

    1. Nada contra o braço esquerdo, por favor! Sou canhoto e gosto disso (jogando bola, principalmente). Mas houve um tempo em nossa história que canhotos eram queimados em fogueiras. Tô brincando não. Alguns acreditavam que canhotos eram “coisa do demo”. Daí o surgimento de um termo utilizado até hoje. Em meu certificado de reservista, no campo “Sinais Particulares”, está escrito: sinistromano. Sinistro!
    2. A classificação apresentada neste artigo foi levemente inspirada neste trabalho.
    3. O uso de um Corpo Humano como metáfora para um Corpo de Conhecimentos foi totalmente inspirado (leia-se: surrupiado e adaptado) em uma classificação feita por Jurgen Appelo no livro “Management 3.0“. A diferença é que ele desenhou um “Corpo de Conhecimentos de Sistemas”. E utilizou uma bonequinha medonha para representá-lo. O livro, excepcional, vai furar fila e aparecer muito em breve aqui na Biblioteca do finito.
    4. O “Woody Witruviano” é obra do Aldo Cavini Benedetti e foi disponibilizada no Flickr com licença CC (by-nc-sa).

  • O Clube da Esquina Globalizada

    Esta é a primeira das três partes da palestra que apresentei no último sábado, “O Futuro não é mais como era Antigamente“. Publicarei todas aqui, antes que voltem para o segundo plano de minha gaveta. Hoje escrevo sobre pessoas e equipes. O artigo foi bem contaminado por um tema que ganha espaço até em agenda de candidato, o “apagão” de mão de obra qualificada.

    .:.

    Nossa história se inicia com um grande apagão. Lá nos idos de 1950 e início da década de 1960, quando agências do governo dos EUA e algumas pouquíssimas empresas começaram a apostar no potencial do “cérebro eletrônico”, aconteceu a Crise do Software 1.0: milhões foram gastos naquelas engenhocas mastodônticas antes que sentissem falta de um componente essencial: gente. Particularmente daquele tipo que depois receberia a genérica alcunha “programador¹”. Qualquer projetinho de meia tigela demandava dezenas e até centenas de profissionais. Acontece que poucos projetos daquela época eram pouco ambiciosos. Só o SAGE (Semi Automatic Ground Environment), da Força Aérea, contou com 700 programadores e 1400 profissionais de suporte. Época legal, em que cada linha de código chegava a custar assombrosos US$ 50.

    A grana, melhor dizendo, o potencial de faturamento chamou a atenção de muita gente. Começaram a brotar as “software houses” independentes. O desenvolvimento de sistemas deixava de ser uma exclusividade dos produtores de ferro (IBM, Burroughs, RCA etc). Mas como faltava gente. Os dois anúncios que você vê ao lado se preocupavam só com isso: atrair talentos. O simpático Dr. Bauer, da Informatics Inc., cravou a sua “segunda lei” no clássico reclame²: “o talento vai para onde está a ação“.

    Mas os anúncios não eram suficientes. E as empresas lançaram mão das estratégias mais agressivas para encontrar “talentos”. Montavam escritórios e quiosques em grandes cidades só para achar pessoas que poderiam ser “convertidas” em programadores. Os recrutadores eram orientados a dedicar especial atenção para: professores de matemática e, olha que jóia, professores de música!

    A estratégia funcionou. Em paralelo, universidades e escolas nasceram ou criaram cursos para formar gente que deveria atender toda aquela demanda pós-moderna.

    Até que, num belo dia, o mundo ficou chato (no sentido de ter uma superfície plana). E dos lugares mais improváveis surgiam programadores que prometiam executar o mesmo trampo de seus similares ocidentais por 1/10 do preço ou menos. Quem já teve o prazer de ler “O Mundo é Plano“, de Thomas L. Friedman (Objetiva, 2005), aprendeu que a Globalização 3.0 não afetou apenas os desenvolvedores de sistemas. Ninguém está isento do achatamento do mundo. E todo mundo pode aproveitá-lo. Acontece que a pancada no mercado do software, além de ter sido a primeira, foi também a mais sentida. “The New Face of the Silicon Age”, artigo publicado na Wired em fevereiro de 2004, mostra bem o tamanho do estrago.

    Os Pecados do Lado de Baixo do Equador

    O alegre povo de Pindorama, com um certo atraso, sacou: “tem bagulho bom aí!” (e João de Santo Cristo ficou rico a acabou com todos desenvolvedores da Índia). Bem, não foi bem assim. Poderia ter sido, não fôssemos tão viciados no auto-engano. A edição da EXAME aí ao lado, de 25/jun/2003, cravava na capa: “Descobrimos um segredo: o Brasil produz tanto software quanto a Índia.” Pouco tempo depois, em 17/mar/2004, a mesma revista jogou uma ducha d’água fria: “A Índia dá aula ao Brasil” (negrito e vermelho da versão original). Segredinho sem vergonha esse, hem?

    Jogamos tantas fichas em apostas bobinhas (CMMI, MPS.br e cartórios afin$) que agora assistimos bondes a nos ultrapassar. EXAME, em 30/jun/2010: “Rivais Além do Futebol – No setor de tecnologia, os empreendedores da Argentina estão melhor que os brasileiros na corrida da globalização.”

    Vou poupá-los do chororô sobre uma estratégia para o software tupiniquim. Quem se interessar pelos meus R$ 0,02 sobre o tema pode ler uma pequena série que publiquei em dezembro de 2007 no abandonado Graffiti. O ponto aqui é outro.

    É a Educação, Estúpido!

    O que Índia, China, Coréia do Sul e outros emergentes da indústria digital têm em comum é a preocupação com educação. O tema sempre aparece na pauta de nossos políticos. Mas aparece assim, como um tópico em um slide que apresenta suas “prioridades”. Até hoje não vi ninguém ir além do óbvio (mais escolas, professores melhor preparados e mais bem pagos etc etc). Como sou um dos menos indicados a tratar o tema com a profundidade e seriedade que ele merece, me limitarei a propor dois ou três novos “slides”, com questões mais específicas:

    • No último dia 12/ago a FGV assustou um tanto de gente com um número: “Até 2014, haverá um déficit de 800 mil vagas no setor“. Como não tem muito tempo que esse número era 200 mil, minha desconfiança é alta. Tanto que na palestra perguntei: “Será que estão confundindo a gente com atendentes de telemarketing de novo?” Não importa (muito). O fato é que há sim um “apagão”. E como suprir tamanha demanda de forma rápida? Com cursos técnicos! Em 2 anos é possível formar um batalhão de bons desenvolvedores. Repito o que disse o mineiro Adail Retamal em um seminário há 3 anos: “Programação se aprende em curso técnico, não na faculdade“.
    • Não tenho números oficiais, mas há tempos sabemos que cerca de metade da patota que inicia um curso (técnico ou superior) não o conclui. Alguém já se ocupou em descobrir as razões de tanta desilusão? Será que a distância entre nosso instigante cotidiano digital e os ângulos retos e empoeirados de nossas escolas não é uma boa explicação?
    • Se eu tivesse grana montaria uma escola com uma grade antenada. Uma base comum, formada por mínimas certezas e teorias fortes, seria obrigatória para todos. Depois, um cardápio multidisciplinar estaria à disposição de designers, engenheiros, líderes, analistas etc. Não me preocuparia em ter o crivo do MEC, PMI, IIBA nem nada do tipo. Uma escola de pensamento independente. Acho que seria uma revolução.
    • A formação de mão de obra qualificada é responsabilidade exclusiva de governos? É estranho o pensamento de alguns de nossos capitalistas de TI. Aqueles que têm real consciência da criticidade das pessoas para seu negócio devem se mexer. Quem quer talento hoje deve se preocupar em formá-lo. Duas dicas: i) Faça com que 4 ou 8 horas da jornada semanal seja utilizada exclusivamente em atividades de aprendizado; ii) Incorpore a segunda lei do Dr. Bauer: “O talento vai para onde a ação está“. Ação, pra quem não entendeu, é projeto que dá tesão.

    Observações:

    1. É preciso dizer que naquela época a tarefa de programação era dividida entre diversas funções, do pensador de algoritmos ao perfurador de cartões.
    2. Sorte nossa que o anúncio, lá no rodapé (p.s.), mata a curiosidade. A “primeira lei” do Dr. Bauer é a seguinte: “se o programa tem um bug, o computador o encontrará”. Grande Dr. Bauer. Mal sabia que sua primeira lei viraria mantra-desculpa de tester preguiçoso…
    3. A parte pré-histórica aqui narrada foi surrupiada do grande livro “From Airline Reservations to Sonic the Hedgehog – A History of the Software Industry”, de Martin Campbell-Kelly (The MIT Press, 2003).
    4. O cartoon, “Fitting into the system“, foi surrupiado de HikingArtist.com. Os dois anúncios que ilustram este artigo foram publicados no livro citado acima. E as capas da EXAME e da Wired são propriedade de suas editoras.
    5. O “Clube da Esquina” é do Milton e de todos os Mineiros; “O Pecado ao Sul do Equador” é do Chico; e o “Bom Bagulho”, do Renato Russo.

  • A Resposta do IIBA

    Como prometi em “BABoK: Uma Leitura Crítica“, o IIBA terá o mesmo espaço e destaque para publicar suas respostas às críticas apresentadas naquele artigo. Suzandeise Thomé, presidente do Chapter São Paulo do IIBA, encaminhou uma resposta oficial. Ela segue na íntegra:

    .:.

    Primeiramente quero agradecer ao Paulo pela sua análise do BABOK® 2.0. Aliás, esta leitura crítica feita por ele é consequência de uma conversa nossa há algumas semanas, quando eu lhe mostrei o diagrama com a estrutura do BABOK® 2.0 e praticamente o provoquei a comprar o documento e estudá-lo… Acho essa discussão extremamente construtiva.

    Concordo que o BABOK® 2.0 tenha defeitos. A imaturidade do BABOK® 2.0 citada por Joe Gollner em seu artigo “O Curioso Caso da Análise de Negócios” não foi contestada por Kevin Brennan, IIBA VP Body of Knowledge, em sua resposta “O Perfeito é Inimigo do Bom.” Ao invés de defender o BABOK® 2.0, Kevin defendeu a iniciativa do IIBA de documentar as práticas de Análise de Negócios mesmo numa época em que a própria disciplina está em processo de formalização. Ele ressalta que o BABOK® 2.0 não é uma compilação das melhores práticas de Análise de Negócios, mas sim uma compilação de “generally accepted practices”, ou práticas habitualmente utilizadas por Analistas de Negócios. (Vale aqui uma retificação da descrição utilizada por mim em palestras recentes do IIBA-SP. Utilizei o termo “melhores práticas” para descrever o BABOK® 2.0 quando eu deveria ter dito “práticas habitualmente utilizadas.”)

    A discussão iniciada por Joe Gollner, rebatida por Kevin Brennan, e resumida por Jonathan Babcock em “IIBA: Timely or Premature?” ressalta o fato de que é preciso ter um ponto de partida, de que é necessário criar um Corpo de Conhecimento para poder depois aperfeiçoá-lo. A iniciativa do IIBA de trazer formalização e reconhecimento à profissão e de documentar suas práticas vem de encontro à necessidade dos profissionais desta área que, até hoje, enfrentam dificuldades para justificar não só seus cargos dentros das empresas mas tamtém o tempo despendido em atividades de Análise de Negócios nos projetos em que atuam.

    Defendo a existência do BABOK® 2.0 como guia de referência para Analistas de Negócios que deve descrever as atividades com as quais devemos nos preocupar. O objetivo do BABOK® 2.0 é estabelecer uma visão abrangente, não um manual detalhado de como se executar Análise de Negócios em situações específicas.

    Respostas oficiais que obtive até o momento:

    Técnicas incluidas no BABOK® 2.0

    A escolha das técnicas a serem incluidas no BABOK foi baseada numa pesquisa feita no final de 2008 com membros do IIBA ao redor do mundo. Foram escolhidas as técnicas que muitos Analistas de Negócios utilizam no seu dia a dia. Não são as técnicas mais recomendadas, nem as únicas que um Analista de Negócios deve saber mas sim as que um AN deve estar preparado para executar. Em linha com o restante do BABOK® 2.0, essa lista é um ponto de partida.

    Referências ao PMBOK

    A omissão de referências ao PMBOK na versão final do BABOK® 2.0 se deve à decisão do IIBA de não fazer referências a fontes específicas exceto em casos absolutamente necessários. Além disso, a data de lançamento da quarta edição do PMBOK não permitiu que o IIBA tivesse tempo de rever as referências mencionadas no DRAFT e atualizá-las para refletir a versão mais recente do PMBOK.

    Encerro aqui a minha defesa do BABOK® 2.0 como Presidente do IIBA-SP. Minha opinião pessoal sobre o artigo “BABoK: Uma Leitura Crítica” colocarei como comentário, pois não posso defender cegamente algo que não escrevi. Repito o que disse ao Paulo pessoalmente e também em palestras do IIBA-SP: continua de pé o meu compromisso de levar ao IIBA críticas construtivas que nós brasileiros gerarmos. Acredito que temos muito a contribuir para a compilação das melhores práticas de Análise de Negócios. Levarei as críticas do Paulo Vasconcellos e as minhas próprias dúvidas ao Kevin Brennan e me comprometo a compartilhar as respostas assim que eu as obtiver.

    -Suzandeise Thomé
    Presidente
    IIBA São Paulo

  • BABoK: Uma Leitura Crítica

    Antes de mais nada, um alerta: se seu interesse pelo BABoK limita-se à obtenção da certificação, então este artigo não vai ajudá-lo muito. Poupe seu tempo. Eu sei, é chato, mas este artigo também merece um prólogo-escudo: não tenho interesse nenhum em depreciar o IIBA (International Institute of Business Analysis) ou seu principal produto, o BABoK® Guide (A Guide to the Business Analysis Body of Knowledge). Há tempos apresento, aqui e ali, críticas àquela que deveria ser a principal referência para a formação de analistas de negócios (AN’s), o BABoK. Meus objetivos sempre foram apenas dois: i) ajudar os AN’s em seu processo de formação; e ii) contribuir para a evolução do BABoK. Ressalvas e alertas devidamente colocados, vamos ao que interessa. Este artigo trata da última versão do BABoK, a 2.0, publicada em 2009.

    A Estrutura do BABoK

    Alguma coisa muito estranha aconteceu entre a liberação da versão para revisão pública, em março/2008, e a versão definitiva publicada agora. A estrutura básica do BABoK foi mantida, com suas 6 disciplinas (KA’s ou Knowledge Areas), mas a ordem de apresentação sofreu consideráveis alterações. Se alguma justificativa para tal foi apresentada, não percebi. O fato é que complicaram a leitura. Em meu entendimento, desnecessariamente.

    Na versão 2.0 liberada para revisão as duas primeiras disciplinas apresentadas eram aquelas de perfil mais gerencial e tático: “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”. Era uma alteração necessária em relação à versão anterior, a 1.6, que começava pela “Análise da Organização” (ou “Enterprise Analysis”). Necessária por agrupar, mesmo que de maneira implícita, as disciplinas cuja aplicação se diferencia substancialmente das outras quatro. (Mais sobre elas no decorrer do artigo).

    A versão atual do BABoK inseriu “Elicitação” entre as duas, comprometendo uma certa lógica de leitura. E a “Análise da Organização”, que um dia foi a primeira disciplina apresentada, agora aparece apenas no quinto capítulo. Uma estrutura que parecia bem resolvida, como ilustra o gráfico abaixo, virou um diagrama de difícil entendimento.

    As disciplinas no BABoK 2 (public review)
    As disciplinas no BABoK 2 (public review)
    A nova estrutura do BABoK
    A nova estrutura do BABoK

    No primeiro diagrama percebemos claramente uma sequência lógica de 4 disciplinas, além da informação de que outras duas guiam e/ou dão suporte à análise de negócios. O segundo desenho quebra essa lógica e não faz nada mais do que confundir. Realmente é incompreensível a mudança.

    Além disso, ainda sobre a estrutura do BABoK, é preciso dizer que a forma como as disciplinas são apresentadas é boa. Destacam-se as entradas, tarefas e saídas principais de cada disciplina. Depois, para cada tarefa, são descritos: entradas, elementos (que são específicos para cada tipo de tarefa), técnicas, partes interessadas (stakeholders) e saídas. A sequência é lógica e didática, apesar dos deslizes que serão discutidos abaixo.

    Armadilhas

    Saca aquele sujeito que, aéreo e desastrado, acaba caindo em armadilhas que ele próprio armou? Essa imagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia do IEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definição de requisitos. Logo depois, ainda no capítulo 1, alerta que “é vital que o termo ‘requisito’ seja compreendido no mais amplo sentido possível”. Ao tentar ilustrar o que seria essa amplitude toda, confundem: “em uma iniciativa BPM, requisitos podem ser uma descrição dos processos de negócio atualmente em uso pela organização”. Além de comprometer a definição do IEEE utilizada na página anterior, criam um tipo de saco sem fundo onde tudo é ou pode ser um requisito. Armadilha armada no primeiro capítulo faz vítimas no decorrer de todo o BoK. Quando apresentando a técnica de “Análise de Regras de Negócios”, por exemplo, é dito que “regras de negócios devem ser separadas de outros requisitos…”. Ou seja, dão a entender que regras de negócios também seriam um tipo de requisito.

    Um analista de negócios deve aprender cedo que a distinção entre elementos do negócio (recursos, processos, eventos e regras) e elementos da solução (requisitos) é crucial para o bom desenvolvimento de seu trabalho. Ele sabe que há uma única interseção entre esses dois conjuntos e ela atende pelo nome de Requisitos do Negócio. O BABoK os define corretamente, como “grandes objetivos, metas e necessidades de um negócio”. De tão importantes, mereceram uma disciplina só para eles, a “Análise da Organização”. O que torna ainda mais indecifrável a bagunça apontada no parágrafo anterior.

    A segunda armadilha bastante notável no BABoK é a necessidade de manutenção de uma certa “compatibilidade retroativa”. O BABoK tenta colocar e manter os pés em dois mundos muito distantes. Ele os chama de “Plan-driven” e “Change-Driven” – nomenclatura criativa usada para diferenciar o mundo clássico¹ de projetos daquele universo que surgiu após o big-bang do Manifesto Ágil. Se num primeiro momento – no capítulo 2, que trata do “Planejamento e Monitoramento da Análise de Negócios” – ele se mostra muito atencioso com o enfoque “change-driven”, na parte que seria mais cara e necessária tal atenção evaporou. Em “Gerenciamento e Comunicação de Requisitos” (capítulo 4), por exemplo, quase nada é falado sobre a forma como requisitos são gerenciados quando é adotado um processo ágil qualquer (Scrum, XP etc).

    O referido capítulo é repleto de  procedimentos para revisão e aprovação de requisitos, baselines, documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar de clássico. Se mantido o mesmo balanceamento (de preocupações) apresentado no capítulo 2, aqui deveríamos ver no mínimo uma vez a expressão “software rodando”, ou “solução rodando” ou algo do tipo. Não vemos. O que permite dizer que o BABoK firma o pé mesmo é no mundo clássico, a exemplo de seu primo não muito distante, o PMBoK. E por falar nele…

    O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos  duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

    Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e muito menos do gerente de projetos. Deveria ser só do arquiteto e ponto. Mas isso é tema para outra hora. Aliás, atenção piratas! Vou lançar o FAS – Formação de Arquitetos de Soluções. Preparem suas copiadoras! hehe..

    Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crítica ao BABoK é o fato dele ignorar por completo a disciplina conhecida como Modelagem de Negócios. O problema se torna mais perceptível na versão 2.0. Porque de fato ele não ignora a necessidade da modelagem. Sugestões para o uso de técnicas de modelagem aparecem a todo momento, em diversas disciplinas. Mas elas surgem de forma tão solta e desestruturada que é difícil imaginar que sejam utilizadas em sua plenitude. Pior: é difícil imaginar que gerem algum valor. Aos fatos.

    Ainda na primeira disciplina, “Planejamento e Monitoramento da Análise de Negócios”², são apresentadas como técnicas gerais a “Modelagem da Organização” e a “Modelagem de Processos”. Em “Análise da Organização”, o 5º capítulo, são elencadas as técnicas “Benchmarking”, “Análise de Regras de Negócios”, “Decomposição Funcional” e “Análise SWOT”. No sexto capítulo, “Análise de Requisitos”, o assombro: além de diversas das técnicas acima, sugerem inclusive o uso de “Diagramas de Fluxo de Dados” na tarefa que deveria ser apenas “Organizar Requisitos”. Dentre os elementos desta tarefa aparece uma breve explanação sobre cada um dos 5 conceitos que, segundo o BoK, “garantem a total cobertura do domínio do negócio”. Aliás, os 5 conceitos são: 1) Classes de Usuário, Perfis e Papéis; 2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.

    Nada mais é necessário para confirmar que a Modelagem de Negócios é fundamental para o entendimento de um negócio. Colocando de outra maneira: é fundamental para a Análise de Negócios. O BABoK sabe disso. Acontece que, ao invés de tratá-a como uma disciplina – como um corpo – preferiu esquartejá-la e distribuí-la em pedacinhos em diversas de suas KA’s. É grave quando percebemos que a Análise de Requisitos, uma disciplina por si só complexa e crítica, vira uma espécie de monstro de Frankestein no BABoK.

    Essa armadilha se torna mais visível quando percebemos que em outros pontos do BoK é apresentada como entrada para determinadas tarefas uma tal “Arquitetura Corporativa” (um documento que, segundo o BABoK, “descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos de negócio, sistemas, informação etc”). Esse input já existiria de alguma maneira na organização. Duas coisinhas: 1) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é factível supor que seu desenvolvimento e manutenção, mesmo que parcial,  sejam atribuições dos analistas de negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na Análise de Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a compor uma “Arquitetura Corporativa”. Vai entender…

    Conclusão

    No final das contas o grande problema com o BABoK é esse: entendê-lo. Se por um lado sua estrutura geral é desenhada com esse fim, e é bem desenhada, por outro o conteúdo ainda apresenta inconsistências demais. Pouco adianta o reuso de conhecimentos bem consolidados, como definições do IEEE e diagramas UML, se eles são contraditos ou diluídos de tal forma que perdem seu sabor e valor.

    Joe Gollner publicou em julho último um artigo chamado “O Curioso Caso da Análise de Negócios“. Brinca com o título do filme estrelado por Brad Pitt, “O Curioso Caso de Benjamin Button”. Joe erra feio ao dizer que não estaríamos prontos para definir um corpo de conhecimentos para a análise de negócios. Tenho certeza de que já temos conhecimento e maturidade suficientes para delinear um BoK. Mas ele acerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.

    A necessidade de manutenção de uma “compatibilidade retroativa” é, sem sombra de dúvidas, a grande culpada. Como justificar, em 2009, o uso de técnicas como a elaboração de DFD’s e diagramas de contexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim o BABoK só faz confirmar uma fama dos AN’s: seriam consumidores vorazes de papel. Não digo com isso que ele deveria se ater aos princípios pregados no Manifesto Ágil. Afinal, a análise de negócios não se limita a projetos de software. Mas é imperdoável que um BoK para análise de negócios se lembre de DFD’s e ignore por completo balanced scorecards, mapas estratégicos, conceitos Lean etc etc etc.

    Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obtenção da certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar o BABoK. Além de ter boa experiência prática. Mas o analista deve ter consciência de todas as armadilhas e inconsistências que o BABoK apresenta em sua versão atual. Para não correr o risco de comprometer seu trabalho e até sua carreira.

    .:.

    Nota aberta ao IIBA

    A lei de imprensa morreu, o finito não é imprensa, mas ética e educação não precisam ser regidas por leis. Caso o instituto julgue necessária uma resposta ao artigo acima, eu garanto o mesmo espaço e mesmo destaque. E reafirmo: não tenho interesse nenhum em criticá-los por criticar. Muito pelo contrário. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com um BABoK forte e consistente. Todos sabemos que um debate franco e aberto é o melhor caminho para a realização desses objetivos.

    .:.

    Serviço:

    Outras Notas:

    1. Entenda como “Mundo Clássico de Projetos” aquele que brotou e cresceu no século passado. Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ou waterfall e que sustenta seus métodos e práticas em diferentes níveis de comando e controle. Não há nada de pejorativo nessa definição. E não há nada de errado com esse modelo, desde que ele não seja utilizado em projetos de software.
    2. O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de  suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework do SEI?