PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: BABoK

  • Business Analysis & Leadership

    Business Analysis & Leadership

    Editado por Penny Pullan e James Archer.
    Kogan Page, 2013.

    Há tempo os analistas de negócios merecem um livro como este. Um texto que os define através de diversas experiências práticas. E um guia que orienta de fato seu desenvolvimento profissional. O trabalho dos dois editores não foi nada trivial. O livro compila 26 artigos de 25 autores. Coletâneas deste tipo costumam sofrer com redundâncias ou viagens nada a ver. Definitivamente, não é o caso aqui.

    São quatro partes: Autoliderança, Liderança em Projetos, Liderança na Organização e Liderança no Mundo todo. A ênfase em liderança é facilmente explicada. Nada a ver com uma posição hierárquica ou qualquer outra confusão parecida. O analista de negócios lidera ao influenciar pessoas e decisões. E ele deve começar liderando a si mesmo.

    Parte I – Autoliderança

    Na primeira parte merecem destaque os artigos de James Archer e Kate Stuart-Cox, “Habilidades para a Análise de Negócios”, e de John Niland, “A Coragem de Perguntar”. Cada parte mereceu uma introdução e um fechamento através de um artigo de opinião. Joseph da Silva, que preside o capítulo do Reino Unido do IIBA, encerra a seção com um belo tapa na cara: “Tá Esperando ser Ungido?” (Are You Waiting to be Anointed?)

    Em suas (britânicas) palavras, Joseph diz que os analistas devem parar de reclamar e começar a mostrar serviço, sendo flexíveis em relação a todas as restrições existentes. Segundo ele, “os analistas não fazem barulho suficiente”, o que impediria o reconhecimento de sua privilegiada visão “independente e desafiadora”. AN’s deveriam começar a provar seu valor fora da função, fora de projetos e… fora de TI¹.

    Parte II – Liderança em Projetos

    Mas o que seria da gente sem projetos? Por isso a segunda parte trata deles. E começa mostrando a convivência de AN’s com gerentes de projetos em artigo de Suzanne Robertson. Suzanne é co-autora de livros sobre requisitos² e do modelo de conhecimentos Volere. O modelo é destacado neste artigo para ilustrar conhecimentos específicos e compartilhados entre AN’s e GP’s.

    James Robertson, que escreve com Suzanne, participa com “Descobrindo A Essência do Problema”. O “Pensamento Visual para a Análise de Negócios” é um dos artigos da co-editora Penny Pullan, este escrito a quatro mãos com Vanessa Rondle. Se depois desta leitura alguém não se convencer da necessidade e utilidade dos modelos, é caso perdido. “Lidando com Partes Encrenqueiras” (“… difficult stakeholders”)³, de Michael Brown, apresenta sugestões bem práticas para lidar com casos perdidos.

    Também merecem destaque os capítulos “Análise de Negócios, Liderança e Agile”, de Chris Matts e Kent J. McDonald, e “Lidando com Incertezas”, de Ruth Murray-Webster e Penny Pullan. O primeiro por ser meio fraquinho. O segundo por atribuir aos AN’s parte da responsabilidade pelo gerenciamento de riscos – uma provocação e tanto. Bem fundamentada, diga-se de passagem.

    Parte III – Liderança na Organização

    Talvez esta seja a parte mais forte do livro. Em “Contexto, Clima e Cultura”, Andy Wilkins e Kate Stuart-Cox ilustram muito bem as raízes da cultura organizacional e como ela gera galhos, ramos e flores. Uma árvore ilustra o conceito. Emma Langhan dá um show ao escrever sobre o “Pensamento Sistêmico para Analistas de Negócios”. São raros os resumos tão bem feitos. Ackoff, Beer, Senge, Weinberg, Snowden – os papas são quase todos citados. Assim como CW Churchman, que nos lembra de que “não há experts em pensamento sistêmico”.“Lidando com Poder e Política”, de Sarah Coleman, e “Pensamento Estratégico para Analistas de Negócios”, de Dav Bisessar, confirmam a abrangência e criticidade desta parte.

    Parte IV – Liderança no Mundo Todo

    Kevin Brennan, VP do IIBA que esteve conosco no último BA Brazil, escreveu “A Análise de Negócios é uma Função de Liderança”. Nick de Voil, diretor do IIBA-UK, contribuiu com o tema “Profissionalização e Melhores Práticas”. É, de certa forma, um bom contraponto ou complemento ao artigo do Kevin. Porque pede que o Guia BABoK seja visto assim, só como um Guia – longe de representar o corpo de conhecimentos da área. “Ele é um mapa, não o território.”

    Nick mostra que a Análise de Negócios é um processo de aprendizagem. O que não combina com nada que fique “congelado” no tempo. É outro autor que cita o Cynefin de David Snowden para balizar algumas de suas sugestões. Curiosidade: Entre todos os 26 artigos, apenas esses dois citam o BABoK.

    Conclusão

    Desconheço outro livro da área que seja tão abrangente. Claro, o preço pago é de certa falta de profundidade. Mas não faltam referências e dicas de leitura ao término de cada capítulo. Se os analistas de negócios esperavam por um livro pra chamar de seu, a espera acabou. Que venha logo a versão em pt-br.

    Serviço

    Notas

      1. A gente já conversou um pouco sobre isso, lembra?
      2. “Requirements-Led Project Management” (Addison-Wesley, 2005) e “Mastering the Requirements Process” (3ª edição – Addison-Wesley, 2012) são dois trabalhos da dupla Suzanne e James Robertson que merecem espaço na biblioteca do AN. O citado modelo Volere é apresentado com mais detalhes neste site.
      3. Minhas traduções são sempre livres, mais ou menos tendenciosas e ocasionalmente falhas. Espero que isso não a(o) aborreça. Neste caso específico, minha intenção era lembrá-la(o) deste artigo.
      4. O rabisco utilizado acima (sem permissão) foi elaborado por Penny Pullan durante um dos eventos de divulgação do livro.
  • 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.
  • Análise X Arquitetura de Negócios

    Análise X Arquitetura de Negócios

    Quando os arquitetos de negócios pintaram no horizonte algumas questões foram colocadas instantaneamente: e agora, o que será dos analistas de negócios? A arquitetura é um desafio? O que ela apresenta de diferente? E quais seriam as justificativas para sua adoção? Há de fato um confronto com a Análise de Negócios?

    Driblando a verborrágica definição apresentada no BABoK®, podemos entender que a Análise de Negócios apoia as atividades de descoberta e desenvolvimento de soluções. É natural vincular tal definição ao trabalho em projetos. O BABoK®, em sua versão atual¹, nos empurra neste sentido. O FAN também. Mas este tenta deixar claro que analistas de negócios podem dar contribuições bastante valiosas no dia a dia de uma organização, em áreas como gestão de conhecimentos, gestão de relacionamentos e qualidade, por exemplo. Em empresas prestadoras de serviços eles parecem ter nascido para atividades de pré-vendas. Enfim, a análise de negócios não se limita a projetos.

    O BizBok™ define a Arquitetura de Negócios como um “blueprint que provê entendimento compartilhado da organização e é utilizada para alinhar objetivos estratégicos e demandas táticas”. Apesar de negar essa característica em outros pontos, o BizBok™ nitidamente apresenta a arquitetura como uma coisa – blueprint – e não um processo. Independente disso é clara a colocação estratégica, a busca por uma alta posição na organização. Posição que não estaria vinculada a nenhum projeto específico. Pela definição acima, a arquitetura gera e define projetos (para alinhar objetivos e demandas).

    Seria esta a principal diferença entre análise e arquitetura de negócios? Enquanto a primeira tem caráter operacional e é atrelada a projetos a segunda fica com o filé estratégico, orientando portfólios e iniciativas de grande valor? Não é bem assim.

    Uma das primeiras apresentações do arquiteto de negócios soou um tanto patética. O Infoworld, em junho de 2011, apresentou o arquiteto como a profissão mais quente de TI. Mas destacou que ele é “do negócio” e se reporta ao CEO. Como assim, a profissão mais quente de TI não é de TI? O arquiteto seria um tipo de CIO totalmente isento das agruras do dia a dia? Um monte de gente adoraria isso. Mas é por essas e outras que não parece ser uma boa ideia apostar em arquitetos de negócios. O que não nos livra de estudar arquitetura.

    A arquitetura nos ajuda a entender, descrever, examinar e explorar negócios. Eu poderia trocar a palavra “examinar” por “analisar”. Isso criaria problemas. Porque permitiria interpretar a análise de negócios como um subconjunto da arquitetura. Não custa repetir: o termo análise é muito ruim e não traduz tudo o que um analista de negócios faz ou poderia fazer. Ele não faz só exames! Assim como ele não se limita a entender, descrever e explorar negócios. O analista precisa resolver problemas. E essa leitura nos permite dizer que a análise de negócios, apesar do nome, é maior que a arquitetura de negócios.

    A próxima versão do guia BABoK® propõe entendimento semelhante. Só é uma pena que ela jogue a Arquitetura de Negócios em um balaio chamado Perspectivas que também reúne TI, BI, Agile e BPM². Como ainda não conheço a nova versão, devo conter minhas críticas. Mas não posso deixar de falar que o BABoK®, ao que tudo indica, seguirá maltratando a modelagem e, consequentemente, a arquitetura de negócios.

    Porque esta distinção – arquitetura X modelagem – é mais difícil de ser feita. Os objetivos de ambas são idênticos: entender, descrever, examinar e explorar um negócio e seu ambiente. Se utilizamos nomes diferentes, talvez seja porque queiramos livrar uma (a arquitetura) dos vícios e mal entendidos da outra (modelagem). Modelagem sempre teve um vínculo com coisas, com terríveis e temíveis entregáveis (sic). Quase sempre é relacionada com uma documentação que só faz acumular pó. A arquitetura, por sua vez, propõe uma reflexão constante. Pretende ser um processo e também um jeito de pensar negócios. Neste sentido, o analista de negócios deve recebê-la como um novo conjunto de ferramentas. Que o ajudará não só a resolver problemas, mas também a evitá-los. A arquitetura está mais para isso, um “toolkit”, do que para uma “perspectiva” ou um mero “blueprint”.

    Só o tempo dirá se as diferenças entre análise e arquitetura de negócios serão interpretadas da forma como foi sugerido acima. Ainda não é possível descartar nem mesmo o surgimento de arquitetos de negócios. Aos analistas deve ficar uma certeza: a arquitetura de negócios precisa ser estudada. Se pretendemos realizar a promessa do BABoK® v3 – catapultar a análise de negócios para uma relevância estratégica – então a arquitetura precisa ser praticada.

    Notas

    1. Este artigo foi publicado poucos dias antes do lançamento da versão para revisão pública do BABoK v3.
    2. Em empresas meio bagunçadas, a contabilidade é repleta de Contas Diversas. O BABoK® já tem uma conta genérica chamada Competências Fundamentais. Agora cria outra, a tal Perspectivas. Se seguir nessa toada, conseguirá bater o recorde de pontas soltas num bok. Atualmente este recorde pertence ao BizBok™. Saca só.
    3. “better shot of the spiral“, a imagem que ilustra este artigo, é de autoria do zen Sutherland.
  • +Requisitos +Conversas

    +Requisitos +Conversas

    Depois de uma releitura dos conceitos de arquitetura e modelagem de negócios,  por que não uma série sobre outro tema que é muito caro para este {finito}, requisitos? Até hoje, publiquei apenas onze artigos sobre o tema. Eles estão soltos por aqui. E um tanto datados. Além disso, tenho visto um maior interesse pelo tema. Em buscas que caem neste site e papos que rolam por aí.

    Esta série será elaborada em paralelo a uma revisão do material didático de dois treinamentos, {FAN} +Requisitos e {FAN} +Conversas. Os capítulos devem ser um pouco mais curtos e aparecer com mais frequência do que o normal. Nesta introdução aponto o caminho que será seguido e os principais tópicos abordados.

    Uma Base de Conhecimentos

    Faz tempo que uso o nome Base de Conhecimentos para apresentar o diagrama ao lado. A primeira intenção é didática, como tentarei mostrar no restante deste artigo. Mas, ah como eu gostaria de vê-lo devidamente implantando em uma empresa. Porque está ali praticamente tudo o que é preciso saber sobre projetos e requisitos.  Porque não há caixinhas soltas – nenhuma informação que não possa ser rastreada. Enfim, deixa pra lá (por enquanto).

    No lado esquerdo do diagrama temos os quatro elementos fundamentais que compõem qualquer negócio: Objetivos, Recursos, Processos e Regras. Trata-se de um metamodelo de negócio cujo detalhamento está fora do escopo deste trabalho. Se você quiser entender um pouco mais sobre ele, dê uma olhada na série Pensando Negócios. Nos interessam aqui as duas ligações principais entre o modelo de negócios e os requisitos: 1. Requisitos do Negócio representam objetivos; 2. Funções suportam a execução de processos de negócios.

    O diagrama sugere que objetivos de negócio podem ser quebrados em um ou muitos requisitos do negócio. Vejamos como isso poderia ou deveria acontecer.

    Dirigentes da empresa ACME decidem que um de seus maiores objetivos para o próximo biênio é aumentar a lucratividade em 30%. Sabem que este ganho será produto de duas iniciativas principais: a) Aumento da base de clientes; e b) Redução dos custos de vendas. Ambas iniciativas apontam para uma única grande mudança: o processo de vendas deve ser totalmente revisto. Os vendedores devem ser capazes de realizar no mínimo 30 visitas por dia, um aumento de 50% em relação à média atual. A ACME está ciente de que precisa aprender duas coisas de forma que possa realizar o ganho de produtividade dos vendedores: i) Tornar as visitas de vendas mais eficazes (indicadores: número de negócios fechados e valor médio das vendas); e ii) Tornar as visitas mais eficientes (indicador: duração média de cada visita).

    Utilizei uma poderosa ferramentinha para descrever os objetivos do negócio acima: o Balanced Scorecard. Como sugeri em outra oportunidade, sua última perspectiva (Aprendizado & Desenvolvimento) pode ser tratada como fonte (riquíssima) de Requisitos de Negócio. Repare que temos dois grandes requisitos neste momento: aumentar a eficácia e a eficiência das visitas de vendas. No próximo capítulo conversaremos bastante sobre eles.

    Requisitos de negócio, dependendo de sua amplitude e complexidade, podem exigir o lançamento de diversos Projetos. Aqui poderíamos engatar uma conversa sobre programas e portfólios. Mas não é esta a intenção do artigo. Basta entender que determinados requisitos de negócio podem requerer n aprendizados e mudanças (leia-se n projetos).

    Cada projeto é um conjunto de Requisitos. E talvez seja a hora de, pela milionésima vez, apresentar uma definição para essa palavrinha tão maltratada. Antes, uma definição que você só deveria utilizar como piada ou se quiser enrolar alguém (um belo exemplo de maltrato)¹:

    “Ao ler o Guia BABoK® é vital que ‘requisito’ seja tomado pelo sentido mais amplo possível. Requisitos incluem, mas não estão limitados a condições ou capacidades passadas, presentes e futuras em uma organização e descrições de estruturas organizacionais, papéis, processos, políticas, regras e sistemas de informação. Um requisito pode descrever o estado presente ou futuro de qualquer aspecto da organização.”

    Um requisito é simplesmente a expressão de uma necessidade ou restrição. Ponto. Se preferir uma definição mais formal, apele ao Houaiss: re.qui.si.to s.m. condição necessária para alcançar certo fim. PONTO! Para que complicar?

    O que é necessário, isso sim, é uma visão bem estruturada dos principais tipos de requisitos. Como ilustra o diagrama acima, eles são três:

    • Funções – ações que um produto, serviço ou sistema deve realizar ou ajudar um usuário a realizar. Aqui sempre temos um verbo, uma ação. O diagrama sugere que as funções, quando realizadas por um sistema de negócio, invariavelmente suportam (apoiam) a execução de um ou mais processos de negócio. É interessante notar que esta vinculação direta pode não fazer sentido em produtos de uso geral como um editor de textos, por exemplo.
    • Atributos – são características que um produto, serviço ou sistema deve apresentar. Alguns atributos serão gerais – devem caracterizar o produto, serviço ou sistema como um todo. Mas a grande maioria estará vinculada a funções específicas. O diagrama sugere que alguns atributos serão detalhados em termos de Preferências, possibilitando ou facilitando, por exemplo, negociações ou tarefas de personalização.
    • Restrições – são as fronteiras apresentadas e que devem merecer, logo de cara, uma classificação. Existem restrições ao projeto (orçamento, prazos, equipe etc – sim, são exemplos de requisitos!) e restrições ao produto, serviço ou sistema (tecnologia, formas de acesso e distribuição, política de atualização etc). É curiosa e muito comum a confusão que existe entre requisitos do tipo restrição e regras de negócio. É fácil desfazê-la: tire o produto, serviço ou sistema; A restrição segue valendo? Então se trata de uma regra de negócio, não de um requisito.

    Estas definições, nada menos que fundamentais, não deveriam mudar dependendo da escola, metodologia ou ferramental empregado. Uma função será sempre uma função, não importa se ela foi descrita na forma de uma user story, uma especificação de caso de uso ou em um documento pra lá de formal.

    Pretendo bater forte nos conceitos. Martelá-los mesmo. Mas não ignorarei o lado prático, o trabalho real com requisitos. A série obedecerá a sequência sugerida neste artigo, ou seja: Requisitos do Negócio, Requisitos, Funções, Atributos e Restrições. Cada tema  merecerá no mínimo dois artigos. Semana que vem: Requisitos do Negócio – Os únicos que podem manchar para sempre o seu currículo. Soou dramático? Foi esta a intenção. Inté!

     

    Notas

    1. O Guia BABoK® (ainda) não mudou mas eu passo a impressão de estar cada dia mais azedo em relação a ele, né? Não é só impressão não. Mas meu alvo não é mais o BABoK e sim a comunidade que insiste em espalhá-lo sem o mínimo senso crítico. Se senso crítico é uma das principais qualidades esperadas de um analista de negócios, o que dizer? O que fazer? O quanto chorar? Melhor é deixar pra lá.
    2. Não passarei toda a série escrevendo “produto, serviço ou sistema”. Vamos combinar o seguinte: nos próximos capítulos vou escrever apenas “sistema”. Por favor, entenda que pode se qualquer tipo de sistema. Um liquidificador é um exemplo de sistema, ok?

     

  • 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

     

  • Os Novos Desafios dos Analistas de Negócios

    É difícil encontrar uma profissão que tenha fechado de maneira tão rápida o ciclo de fundação, encantamento, estabilização e queda. A Análise de Negócios, como conhecida hoje, foi definida a pouco mais de sete anos. Seu corpo de conhecimentos oficial, publicado pelo IIBA (Instituto Internacional de Análise de Negócios), ainda está na versão 2.0. Mas os analistas de negócios são cada vez mais desafiados a reverem suas responsabilidades, seu conjunto de conhecimentos, habilidades e sua posição nas empresas.

    O ciclo de desenvolvimento da profissão foi acelerado não só pela dinâmica dos tempos modernos, mas principalmente pelo seu mau uso. Não foram poucas as empresas e organizações de TI que viram nos analistas de negócios um tipo de ponte entre estas e as demais áreas de negócios. Os analistas atacariam aquele que é o maior problema de TI: a comunicação com seus clientes e usuários.

    A visão está correta. Equivocadas estão as organizações que fizeram dos analistas de negócios uma espécie de analista de suporte de luxo. Eles foram jogados no inferno cotidiano das operações de TI, na vã esperança de que sua especialização em conversas e requisitos representasse algum alívio. Em muitos casos o que ocorreu foi uma piora dos níveis de serviço, um aumento no tempo de atendimento aos usuários. Porque os analistas de negócios viraram um nó a mais na rede de comunicação. Nem simpatia nem todas as habilidades sociais do mundo aplacam a ira de usuários mal atendidos.

    Os problemas das organizações de TI e de seus famigerados sistemas legados estão além do escopo deste artigo. Assim como sempre estiveram além das promessas da Análise de Negócios. É hora de rever o que foi prometido, aprender com os muitos erros e alguns acertos e recolocar desafios. Senão a profissão definhará e perderá seu sentido, a exemplo do que já ocorreu com a Análise de Organização & Métodos e com a própria Análise de Sistemas. Disciplinas que são, de certa forma, antecessoras da Análise de Negócios.

    Analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios. Temos assim, em uma frase, a definição da profissão. Três verbos delimitam suas principais atribuições. Analistas apoiam outras áreas e pessoas, o que significa que suas atividades nunca são um fim em si mesmas. Apoiam a descoberta de soluções, um processo que envolve o correto entendimento de um problema e a exploração de alternativas de solução. Por fim, ajudam o desenvolvimento de soluções, entendendo que seu trabalho só está concluído quando o problema está definitivamente sanado.

    Esta definição nunca direcionou os analistas de negócios para os departamentos de TI. O verdadeiro analista de negócios está apto a resolver problemas de qualquer natureza. Mas o fato é que, não fosse o impulso originado em TI, talvez não estivéssemos aqui, conversando sobre Análise de Negócios. Sejamos eternamente gratos. Mas, para o bem da profissão, não podemos ficar eternamente presos. Porque TI não tem o monopólio dos problemas que afetam as empresas. E muito menos o monopólio das soluções.

    As organizações de TI continuarão se beneficiando da atuação dos analistas de negócios. Elas seguirão tendo os seus, mas em quantidade menor do que hoje observamos. Os que migrarem terão dois destinos. As próprias áreas de negócios, que ganharão assim uma interface para comunicação com seus eventuais construtores de soluções, sejam eles TI, marketing, contabilidade, produção etc. É importante observar que não há sobreposição com responsabilidades dos gerentes das áreas dado que o escopo de atuação de um analista é de cunho exclusivamente operacional. Os gerentes seguirão gerenciando, agora apoiados por Solucionadores de Problemas treinados e íntimos de seus objetivos e mazelas.

    Um segundo destino possível são os chamados Escritórios de Gerenciamento de Projetos (PMO’s) ou mesmo escritórios de análise de negócios. É um desenho que pode se justificar em alguns casos, desde que este escritório não esteja subordinado à área de TI. Mas é preciso sempre se lembrar que profissionais que existem para derrubar muros – analistas de negócios e gerentes de projetos – dificilmente conseguirão justificar suas próprias paredes e biombos.

    É difícil prever quando esse movimento migratório começará. Tão difícil quanto antever, há cerca de cinco anos, que a Análise de Negócios teria o espaço que tem hoje. O movimento parece ser tão natural quanto o primeiro. Por isso, é bom que os analistas de negócios estejam bem preparados.

    Os trabalhos de descoberta e desenvolvimento de soluções, brevemente descritos acima, envolvem o domínio de um número considerável de disciplinas. Modelagem de Negócios e Engenharia de Requisitos servem como ponto de partida e conjuntos flexíveis de um sem número de métodos, técnicas e ferramentas. O bom analista sabe que, neste caso, quantidade é importante. Ele entende que será avaliado não apenas por suas habilidades interpessoais, mas também pela riqueza, abrangência e diversidade de suas habilidades técnicas.

    Subjacentes aos processos de descoberta e desenvolvimento estão três áreas que podem se beneficiar com a atuação de analistas de negócios. Áreas que não se limitam aos projetos, mas usam estes como suas principais fontes. A primeira é a Gestão de Relacionamentos, porque os analistas de negócios funcionam como elo entre todas as partes interessadas de um projeto. Faz sentido que eles, além dos problemas e requisitos, cuidem também da qualidade das relações e do gerenciamento de expectativas.

    Em seguida vem a Gestão de Conhecimentos, porque os analistas sabem que cada projeto é uma oportunidade única de aprendizado. Dada sua mobilidade e abrangência de atuação (eles podem treinar usuários, por exemplo), faz sentido que eles sejam cobrados pela qualidade do conhecimento gerado e difundido.

    Por último, mas não menos importante, temos a Manutenção da Qualidade. Porque o tema precisa deixar de ser um requisito implícito dos empreendimentos empresariais – e virar um objetivo de todos. Os analistas de negócios podem desempenhar um papel crucial na busca por um alto padrão de qualidade nos projetos.

    A Análise de Negócios é uma área rica e atraente porque lida com domínios cognitivos de maior complexidade. Tem jeito e cara de uma típica profissão do século XXI, que sabe combinar dinâmica e reflexão, pragmatismo e inovação. Ganharão os profissionais e as organizações que souberem extrair o melhor dela.

    Nota

    Não há nada de muito novo neste artigo, que é uma versão (adocicada?) de Repensando a Análise de Negócios, publicado no último 8 de março. Esta versão foi encomendada pela Assespro-MG e publicada em alguns veículos. Ganha espaço aqui porque o papo tem que continuar.

     

  • Repensando a Análise de Negócios

    Repensando a Análise de Negócios

    eria muita incoerência de minha parte se, após a palestra que apresentei no BA Brazil, seguisse tocando minha vidinha da mesma maneira. Aquelas provocações motivaram o maior redesenho que o Programa {FAN} já recebeu. O que, por sua vez, pediu por um rejuvenescimento deste {finito}. Não vou roubar seu tempo repetindo o que o programa já diz. Minha intenção neste artigo é outra. Que tal ver a Análise de Negócios de uma forma um pouco mais ampla?

    Relembrando e reforçando as duas provocações que apresentei:

    • Não devemos seguir espalhando por aí que “o importante é que a Análise de Negócios seja realizada, não importa por quem”. Esta colocação, por bem intencionada que seja, gera dois efeitos muito negativos: i) parece diminuir a importância e simplificar (no mal sentido) a Análise de Negócios; e ii) deprecia todos que escolheram a Análise de Negócios como profissão. Pergunta (retórica): na ausência de analistas de negócios, como podem a profissão e respectivo corpo de conhecimentos evoluir?
    • Apesar de dever seu ressurgimento à TI, está chegando a hora da Análise de Negócios decretar sua independência. Por definição, analistas de negócios ajudam uma organização a descobrir e desenvolver soluções para problemas de negócios. Qualquer tipo de problema! Mas…

     

    Definições Destroem

    A definição destrói Não há nada definitivo neste mundo. – Bob DylanNão precisamos ser radicais como Dylan, mas é sempre saudável alguma reflexão sobre definições e nomes. Pense um pouco sobre o termo “Análise de Negócios”. Talvez você perceba, como eu (depois de monte de gente¹), que ele é ruim pra chuchu. Veja o que diz o Houaiss:

    • análise s.f. 1 estudo das diversas partes de um todo 2 investigação; exame
    • negócio s.m. 1 transação comercial 2 local onde se realiza essa transação 3 algo que não se sabe ou não se lembra o nome; qualquer coisa; trem (em mineirês e fora do Houaiss)

     

    Pegando apenas o que nos diz respeito, podemos concluir que Análise de Negócios é “o estudo das diversas partes de um local onde se realizam transações comerciais”. O estudo por si só? Não faz sentido. Ou faz tanto quanto propor “a investigação de um trem“.

    Reforço a definição que sugeri no início do artigo: “analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios”. Os analistas apoiam – o que significa que suas atividades nunca são um fim em si mesmas. Eles apoiam dois tipos de atividades: de descoberta e  desenvolvimento (de soluções para problemas de negócios). Veja o diagrama abaixo:

    O losango já foi utilizado por vários autores para ilustrar o caminho para a solução de problemas, dentre eles Scott Berkun² e Tim Brown³. Berkun o chamou de “espaço do problema”. A figura indica que nós aumentamos esse espaço – cogitando e validando alternativas de solução – antes de selecionar, desenhar e construir a mais adequada. Brown nomeia as pontas do losango de maneira um pouco diferente. A primeiro seria de divergência – quando criamos escolhas, a segunda de convergência – quando fazemos escolhas. Quase escondo a provocação nas palavras entre parênteses: a análise – o estudo das diversas partes de um todo – é só parte do trabalho! Ela não tem sentido nenhum sem sua cara metade, a síntese. Houaiss:

    • síntese s.f. 1 reunião de elementos diferentes num todo coerente 2 operação intelectual que apreende o todo partindo dos elementos que o constituem 3 exposição abreviada e genérica; resumo

     

    Se a análise é o estudo das partes, a síntese as combina na elaboração de um todo. Não há processo ou método para solução de problemas que não obedeça essa ordem. Exatamente por isso o termo “análise” é tão ruim¹. Não se trata de chatice de dublê de filólogo. Nomes e definições podem ser perigosos ou até mesmo destrutivos. Se não, como explicar que muitas empresas utilizem analistas de negócios apenas em 1/5 das funções sugeridas no diagrama acima?

    Ainda não cheguei ao cúmulo de sugerir a troca do nome da disciplina ou da profissão. Não sou louco o suficiente. Apenas insisto para que a Análise de Negócios seja vista de forma mais ampla. Reparem, ela nem se limita ao losango no modelo acima. Existem outras três áreas, não limitadas aos projetos, que merecem o apoio dos analistas de negócios. São elas:

    • Gestão de Relacionamentos: se os analistas de negócios funcionam como uma ligação entre todas as partes interessadas de um projeto, é natural que se espere deles uma considerável contribuição na gestão de relacionamentos: gerenciamento de expectativas; resolução de conflitos; averiguação da satisfação de clientes e usuários etc
    • Gestão do Conhecimento: uma responsabilidade muito maior do que a danosa e usual percepção de que os analistas devem “documentar tudo”. Existem documentos – existe a necessidade deles, mas há algo muito maior sendo gerado a cada projeto, por menor que ele seja. É conhecimento novo. Algo que, se não for corretamente gerenciado, será desperdiçado.
    • Manutenção da Qualidade: algo que deve ser incorporado em toda e qualquer função. Os analistas de negócios têm condições de zelar não apenas pelo que desenvolvem, mas também pela qualidade de todo o trabalho executado em um projeto e fora dele.

     

    Para Pensar e Repensar

    Você pode estar perguntando, com razão, o que esse papo tem a ver com as duas provocações que abriram este artigo. Tudo:

    • Cabe um mundo inteiro na distância entre analistas de negócios e tiradores de pedidos. A Análise de Negócios lida com domínios cognitivos de maior dificuldade: Solução de Problemas, Análise e Síntese; Pensamento Criativo; Pensamento Sistêmico; Complexidade etc. Entender ou pretender que qualquer outro profissional possa executá-la, mesmo em projetos aparentemente mais simples, é ingênuo e perigoso.
    • Mais importante é entender que a Análise de Negócios não existe sem os analistas. A disciplina definhará se não houver quem a defenda e estude  como uma especialização.
    • Ao propor o modelo acima forço um distanciamento de TI. Até então utilizava disciplinas da Engenharia de Software – Modelagem de Negócios e Requisitos – para mostrar o que os analistas de negócios podem fazer. Elas seguem existindo e continuam importantes para os analistas. Mas devem ser percebidas como itens de uma caixa de ferramentas que precisa ser consideravelmente maior e mais diversificada. Todas as empresas estão carentes de bons solucionadores de problemas. Um time especialista em solução de problemas, qualquer tipo de problema, seria uma cartada e tanto. Você não acha?

     

    Notas

    1.  Esse papo de Análise + Síntese é quase tão velho quanto andar pra frente. Só foi requentado neste artigo porque parece esquecido ou ignorado quando o assunto é a Análise de Negócios. Gerald M. Weinberg, falando para analistas de sistemas em “Redefinindo A Análise e o Projeto de Sistemas” (McGraw-Hill, 1990), já tinha feito o mesmo. Pelo que sei, Weinberg foi o primeiro a destacar o quão ruim é o termo “Análise” e a propor um tal Sintetista. Desta leitura derivei outra provocação: o analista de sistemas falando para o analista de negócios, “eu sou você amanhã”.
      Weinberg teve vários títulos publicados no Brasil mas, salvo engano, estão todos esgotados. Analistas de negócios deveriam ler todos que encontrar nos sebos da vida.
    2. Em “A Arte do Gerenciamento de Projetos“, Bookman (2008).
    3. Em “Design Thinking – Uma Metodologia Poderosa para”, Campus (2010). A editora deu uma bela barbeirada no título, tanto que temo pela  tradução. Se puder, opte pelo original: “Change by Design” (Harper Business, 2009).
    4. A Extensão Ágil do BABoK®, em fase de revisão pública, é muito feliz ao sugerir uma divisão muito parecida com aquela ilustrada pelo losango acima. Só há um termo diferente: Delivery (entrega) ao invés de Desenvolvimento.

     

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