finito

Autor: Paulo Vasconcellos

  • Rendiconti: Dose Dupla

    2.600km em 3 semanas. Tudo via asfalto (e buracos). Nos últimos 15 dias, dois workshops em Sampa: a 4ª turma do FAN (Formação de Analistas de Negócios) e a 1ª turma do 1º filhote do FAN: Engenharia de Requisitos. O cansaço é grande, mas valeu o esforço. Valeu bem mais do que eu esperava.

    A 4ª turma do FAN marcou a despedida de um formato. Quando ele voltar, em fevereiro de 2008, será direcionado para coordenadores de projetos e gerentes de TI. A intenção será mostrar a criticidade e importância dos Analistas de Negócios (AN’s) em projetos e organizações de TI. Será o primeiro de uma nova série sobre Alinhamento Estratégico. A série será composta de maneira ‘bottom-up’: começarei dos AN’s, passarei por processos de desenvolvimento até chegar em arquitetura corporativa. (Estou pensando alto, mas é meu primeiro plano para 2008).

    E a prestação de contas (rendiconti) da 4ª turma (07/nov)? Sem querer, ela serviu como experiência para um novo formato. A turma era menor. As interações foram mais freqüentes e ricas. Aliás, minha grande “derrota” foi a terceira turma. Não consegui criar “liga” com a platéia, e o evento terminou com uma hora de antecedência. Na 4ª, repetindo o mesmíssimo roteiro, o resultado foi consideravelmente superior. O problema com a redução do número de participantes é o custo. E, sinceramente, não queria que esses eventos ficassem caros. Estamos, Tempo Real Eventos e eu, analisando possibilidades.

    Uma certeza: a “oficina” de Engenharia de Requisitos merecerá uma 2ª turma já em janeiro, dia 18. O FAN, em 2008, aparecerá como dois eventos “levemente acoplados”: Modelagem de Negócios (1ª turma dia 31/jan) e Engenharia de Requisitos. Como no evento de ontem, pelo menos 50% da carga horária será composta de exercícios. Ou seja, “oficina” de verdade.

    Não preciso esconder, temia muito pelo evento de ontem. Lotação esgotada, era a primeira aparição pública do “Engenharia de Requisitos”. Na quinta-feira da semana passada, retornando para Vga, deu um “estalo” e resolvi remontar todo o evento (que até então pegava carona nos exercícios que eu havia elaborado para o curso completo de Formação de Analistas de Negócios). Minha preocupação: o negócio e respectivo projeto-exemplo eram relativamente complexos. Eu temia que tal complexidade desviasse o foco de meu principal objetivo: reforçar conceitos, práticas e métodos que formam a Engenharia de Requisitos. Passei sexta e sábado remontando praticamente metade dos 120 slides do evento.

    Para minha satisfação, o workshop foi um grande sucesso. O que não significa que foi perfeito. Três participantes reclamaram a não execução integral do roteiro que estava no site do evento. Na revisão, acabei reforçando os exercícios em detrimento de algumas partes exclusivamente teóricas. Mas, na conta final, os participantes gostaram muito. Os exercícios, simulando entrevistas, workshops, sessões de brainstorming e a elaboração de casos de uso, se provaram bem legais. Eficazes no reforço de conceitos e práticas. Em outro post (que só virá depois que eu pagar uma certa dívida com a série sobre EPBE) comentarei um “acidente” que enriqueceu demais a “oficina”. No meio do acidente, perdidos numa imensa nuvem de fatos, idéias e requisitos, um participante concluiu: “Isso acontece em todo projeto!”. Sem perder muito tempo, vimos como é possível “domar” o projeto mesmo naquela fase mais “selvagem”. Mesmo em projetos que requerem muita “selvageria” (aka Criatividade). Mas, como eu disse, é assunto para outro post.

    Para a realização do workshop pedi o reforço de 5 “monitores”: pessoas que haviam participado de turmas do FAN e que me ajudariam nos exercícios. A turma foi dividida em 5 grupos. O evento não teria o mesmo resultado não fosse a imensa colaboração de Celso Cândido, Jean Streleski, Nilton Nakate, Rafael Kiss e Reinaldo de Oliveira Castro. Registro aqui meu sincero agradecimento. Devo agradecer também toda a turma que participou. O nível era excelente, o que ficou evidente logo nas primeiras discussões. Eles enriquecem demais os eventos relatando suas experiências, dores e necessidades.

    Portanto, nesta reta final para a liberação de todo o material desenvolvido para a Formação de Analistas de Negócios, só tenho uma coisa a lamentar: a não realização do curso de Modelagem de Negócios que estava previsto para o início de novembro. Como eu não seria nada honesto se ‘podasse’ o material, fazendo com que o curso tivesse uma carga horário menor que 35 horas (70 no total, considerando o módulo II sobre Engenharia de Requisitos), tenho que rever a oferta. Realizá-lo aos sábados? Oferecer como treinamento remoto? Sinceramente, ainda não descobri o melhor formato. Mas, tenho certeza, ele sairá ainda no início de 2008.

    .:.

    E ainda não fechei a agenda de 2007 para os eventos gratuitos em escolas, faculdades (públicas ou privadas) e entidades sem fin$. Para minha felicidade, talvez eu finalmente consiga promover um deles em minha terra natal, Minas. Mais precisamente em Lavras (UFLA). Tô torcendo muito por isso. Outra oportunidade é São Carlos. Estou torcendo para o Reinaldo achar uma data. Final de ano é difícil, mas estamos brigando para viabilizar outras viagens do FAN. Mais 2 mil e tantos kilômetros de asfalto farão muito bem para o conteúdo.

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

  • EPBE: Introdução

    Chororô só não basta. E não dá para esperar que todo mundo com um mínimo de curiosidade compre o único livro* que documenta a EPBE (Eriksson-Penker Business Extensions) ou participe dos meus eventos. Então, começo agora uma pequena série com um objetivo muito simples: explicar o básico da EPBE e compará-la com outras propostas.

    .:.

    A EPBE (Eriksson-Penker Business Extensions), como o nome indica, foi desenvolvida por Hans-Erik Eriksson e Magnus Penker. Foi apresentada no ano 2000, no livro “Business Modeling with UML – Business Patterns at Work“. Como o título indica, o livro tem objetivos bem maiores. Mas a compreensão da EPBE está em seu núcleo. Mas o que é, afinal, a EPBE?

    A EPBE é uma extensão da UML (Unified Modeling Language). Foi desenhada para possibilitar o uso da UML na modelagem de negócios. A UML é extensível, e várias outras especializações existem: sistemas Web, modelagem de bases de dados, sistemas embarcados etc. Estendemos a UML através de três elementos: estereótipos (stereotypes), valores nomeados (tagged values) e restrições (constraints). Quando uma organização ou equipe faz um uso maduro da UML, ela cria suas próprias extensões. Evita-se a “reinvenção da roda” quando se parte de uma extensão existente, como a EPBE, por exemplo.

    Mas a EPBE “reinventou a roda”, não? Afinal, no ano 2000, já existiam diversos padrões de notação para a modelagem de negócios. A justificativa para sua criação é exatamente essa: existiam diversos padrões – o que é o mesmo que dizer que não existia padrão nenhum. A mesma razão, em outro domínio, motivou Grady Booch, Ivar Jacobson e James Rumbaugh a criarem a UML. E por que utilizar a UML como base para a modelagem de negócios?

    Segundo os criadores da EPBE, a primeira motivação são os “conceitos similares: um negócio pode ser descrito em termos de processos que satisfazem objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e restrições sobre como os processos e recursos devem se relacionar e como devem se comportar. Tudo isso pode ser mapeado em objetos, relacionamentos e interações entre objetos” .

    Outras razões apontadas por Eriksson e Penker são: i) a maturidade da UML (e da orientação a objetos); ii) a notação padrão (de facto); iii) o aprendizado rápido; e, iv) a nova e fácil maneira de ver a organização e o negócio. Vale reforçar a motivação descrita no parágrafo anterior com outra leitura: negócio e TI teriam uma mesma linguagem padrão de modelagem. Os benefícios são óbvios.

    Do mesmo parágrafo podemos extrair os 4 elementos fundamentais que utilizamos para descrever qualquer negócio:

    • Recursos: é tudo o que a empresa utiliza, consome ou produz. São as pessoas, materiais, informações e produtos. Recursos são manipulados através de processos, ou os manipulam e gerenciam. E são classificados como: físicos, abstratos e de informação.
      Para ficar um pouco mais claro: uma nota fiscal é um recurso abstrato, assim como uma ordem de compra ou um “bilhete azul”. Quando uma nota fiscal é registrada em uma base de dados, por exemplo, torna-se um recurso de informação.
    • Processos: são as atividades realizadas pelo negócio. Eles descrevem como o trabalho é executado na empresa, e são delimitados por regras.
    • Regras: são as definições ou restrições de algum aspecto do negócio. Regras determinam como um negócio deve ser gerenciado ou como os recursos devem ser estruturados e utilizados. Elas podem ser criadas pela própria empresa ou são impostas por entidades externas (governo, associações, sindicatos etc).
    • Objetivos: representam a razão da empresa, ou os resultados que o negócio espera atingir. Objetivos podem ser divididos e distribuídos entre os diversos processos da empresa. Objetivos expressam o estado desejado de determinados recursos (caixa, estoque, market share – por exemplo), e são atingidos através dos processos. O conjunto dos objetivos de alto nível forma a estratégia da empresa.

    A lista acima pode ser resumida da seguinte forma: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras. O diagrama ao lado representa esta lógica.

    Para entender e aceitar a EPBE, além de compreender os elementos fundamentais descritos acima, é necessário entender o que é a Modelagem de Negócios e para que ela serve. Modelamos um negócio com o objetivo de simplificá-lo. Criamos abstrações ou analogias de uma forma que facilite a compreensão, a documentação e a comunicação de todos os aspectos principais de um negócio. Nós modelamos um negócio para:

    • Fornecer uma base que apóie a criação de sistemas de informação;
    • Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de negócio;
    • Experimentar novos conceitos e desenhos;
    • Identificar oportunidades de outsourcing; e
    • Facilitar a integração com entidades externas.

    Tratando especificamente de projetos de sistemas de informação, podemos dizer que a modelagem de negócios também serve para :

    • Entender a estrutura e a dinâmica da organização;
    • Compreender os problemas da organização e identificar oportunidades de melhoria;
    • Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do negócio; e
    • Extrair requisitos do sistema.

    Do que consiste um modelo de negócio? Ele é formado por três partes principais:

    • Visões: é impossível descrever completamente um negócio sob um único ponto de vista. Existem quatro categorias de visões: Visão do Negócio, Visão dos Processos, Visão da Estrutura e Visão do Comportamento.
      Obs.: nas próximas partes desta série as visões serão apresentadas de forma mais detalhada.
    • Diagramas: toda visão é representada por um ou mais diagramas, que representam partes específicas da estrutura ou da dinâmica do negócio. Diagramas são compostos por objetos e processos.
    • Objetos e Processos: Objetos representam todos os recursos, enquanto os processos representam qualquer atividade ou função executada no negócio.
    .:.

    A mensagem mais importante até aqui é a seguinte: Modelar é Simplificar. Modelamos um negócio para facilitar sua compreensão, entender seus problemas correntes e identificar oportunidades de melhoria. Em projetos de sistemas de informação, a modelagem de negócio é lançada para municiar da melhor forma possível a equipe que criará a solução. A EPBE é “só” um padrão de notação. É diferente de outras propostas porque: i) Usa o mesmo padrão dos sistemas, a UML; e, ii) É completa.

    A EPBE não é um processo ou metodologia nem pretende sê-lo; O uso da EPBE não implica necessariamente em BDUF (big design up front) ou na utilização de processos “waterfall”; A EPBE não concorre com BPMN e afins – na realidade estes podem ser utilizados como um sub-conjunto da EPBE.

    No próximo artigo veremos como a EPBE descreve a Estrutura de um negócio. E no seguinte, como ela é utilizada para modelar Processos de negócio.

    .:.

    Bibliografia:

    1. Business Modeling with UML – Business Patterns at Work
      Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
    2. The Rational Unified Process – An Introduction (2nd Edition)
      Philippe Kruchten. Addison-Wesley (2000).

    Observação:

    * – Para não cometer uma total injustiça: o livro “UML 2.0 – Do Requisito à Solução“, de Adilson da Silva Lima, tem um capítulo inteiro dedicado à EPBE. Pelo que sei, é o único em língua portuguesa que toca no assunto. Se tudo der certo, ele perderá o monopólio em março de 2008, quando meu livro deve chegar em algumas prateleiras. Eu disse lá em cima que o livro de Eriksson e Penker é o único porque o Adilson limita-se, como eu aqui nesta série de artigos, a dar um overview da EPBE. Ou seja: EPBE na íntegra, só no original.

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

  • EPBE: Quem usa?

    Desde a semana passada estou envolvido em debates sobre a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios. O provocador das discussões foi o mesmo, José Augusto Agnello. O primeiro debate, no grupo UML-BR, começou com BUC’s (Business Use-Cases). Já no grupo BPM o Agnello foi direto: alguém usa? Como ela se compara com BPMN?

    Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN’s e da EPBE em um grupo “pesado”, o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro “brinde” veio hoje: a “desconfiança” de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.

    Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro “Business Modeling with UML“. Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha “tese”. Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: “caramba, ninguém usa isso!”.

    Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: “que p**** é essa?”. Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma – caramba, é uma linguagem! – ela é muito nova. Por outro – pô, informática! – ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?

    Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: “a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas”. Seria outro caso de uma boa idéia carente de um bom marketing.

    Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro “Business Modeling with UML” no site da Amazon. Surrupiarei alguns trechos:

    “The ‘Eriksson-Penker extensions for business modelling’ are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read.”
    – A.K. Johnston

    “Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models.”
    – J. Chong

    Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.

    Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar “analistas-programadores”; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.

    Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:

    1. UML já é uma linguagem madura e consolidada;
    2. Utilizada amplamente no domínio da solução;
    3. Por que não utilizá-la também para a modelagem do problema?
    4. Assim, TI e negócio teriam pela primeira vez em sua história uma mesma língua – mesmo que ela seja “só” para modelagem.

    Pronto, minhas dúvidas já se dissiparam. E as suas?

    .:.

    Observações:

    * Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.

    ** Adjetivos pouco nobres (como o “capenga” acima) vivem me criando problemas. Um dia foram as “bullshitagenzinhas ágeis”. Hoje foi o BPMN “bonitinho”. Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora – na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.

    No UML-BR, “brigando” com o MT na questão “BUC’s X EPBE”, eu usei “fraquinho” no lugar do “capenga”. É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.

    Mas aqui cabe uma explicação: sou fã do Jacobson. Seu “The Object Advantage – Business Process Reengineering with Object Technology” é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.

    .:.

    Dica levemente acoplada: não percam o artigo de hoje do Philip “Shoes” Calçado, no Fragmental.

    .:.

  • Quem Paga a Dolorosa?

    O negócio não interessa. O que interessa, isso sim, são os maravilhosos badulaques, frameworks, caixinhas-caixões e código. Adoramos esquecer que, no final das contas, quem ‘morre com a dolorosa’ é o tal do negócio. Há mais de uma década o Gartner estampa no Top 5 das preocupações dos CIO’s: “Alinhamento Estratégico“. Perdemos o novelo ou o papo sobre alinhamento não é sério?

    É claro que é sério. Na maioria das empresas é. O problema é mudar uma cultura de décadas de “cara-caixa-preta”. Não são poucos os exemplos de modelos, processos e metodologias que colocam TI como um fim e não um meio. Não por acaso, a Análise e Modelagem de Negócios é a disciplina mais ignorada em projetos de TI, particularmente em iniciativas para desenvolvimento ou implantação de sistemas. É comum que a Modelagem de Negócios seja vista como papo furado, desperdício ou algo do tipo.

    .:.

    A edição 903 da revista Exame (10/out/2007) apresenta uma série de artigos especiais. Mostra como o Brasil mudou nos últimos 40 anos. Alguns números são tão espetaculares que nos fazem questionar essa eterna mania de achar que tudo por aqui está ou dá errado. Ops… o assunto mudou ou o editor viajou? Não.

    Pense nas empresas que estão aí há 40, 20 ou 10 anos. Como elas passam por tantas ondas de mudanças? Processos de negócio envelhecem e adoecem. Quando o mesmo ocorre com recursos da empresa, máquinas por exemplo, eles são trocados. E o que acontece com os processos de negócio?

    Em grande parte das vezes eles são ajustados ou remendados. Várias empresas optaram pela implantação de ERP’s – grandes sistemas corporativos que em seu conceito original propunham a adoção de novos processos. Grande parte dos problemas com a adoção desse tipo de solução acontece exatamente na diferença entre processos existentes e os novos desenhos.

    Mas a questão está longe de ser uma exclusividade das empresas mais velhas. Mesmo empresas muito novas convivem diariamente com a pressão por mudanças em parte de seus processos de negócio. A demanda ocorre, particularmente, nos processos primários – aqueles que lidam diretamente com o mundo exterior, com os clientes.

    Processos ultrapassam as fronteiras de uma organização. Para frente, na direção dos clientes, e para os outros lados, no sentido dos fornecedores e parceiros de negócios. Na economia atual, têm nítida vantagem as empresas que oferecem processos abertos e flexíveis. Então, testemunhamos o surgimento de propostas muito boas para a realização dos requisitos de abertura e flexibilidade, notadamente SOA (Arquitetura Orientada a Serviços) e BPM (Gerenciamento de Processos de Negócio).

    Mas, como quase sempre ocorre em TI, caixinhas e ferramentas monopolizam discursos, press-releases e budgets. Passa desapercebido o fato de que processos remendados, velhos e doentes seguirão remendados, velhos e doentes numa SOA ou sob os cuidados de um BPMS. É muito velha a máxima que diz que “engessamos processos equivocados”. Tão antiga quanto nossa teimosia em ignorá-la.

    .:.

    A Análise e Modelagem de Negócios, uma das duas macro-disciplinas que formam o corpo de conhecimentos dos Analistas de Negócios (AN’s), está longe de ser papo-furado ou desperdício. Na realidade, quando bem executada, pode ser a diferença entre um projeto de sucesso e o total fracasso.

    A correta compreensão dos requisitos do negócio – seus objetivos e as metas específicas de seus processos – possibilita que projeto e produto tenham um horizonte e escopo bem definidos. Por isso a modelagem de negócios é bem mais que o mapeamento de processos. Ela pode compreender o estudo da estratégia da empresa, suas oportunidades e limitações, estrutura e relações.

    O que não pode significar, de maneira alguma, que projetos de TI devem ficar ‘congelados’ por um bom tempo, aguardando a realização da tal Modelagem do Negócio. Trata-se de um mito bastante comum que acompanha a disciplina. Uma primeira visão, a primeira iteração, pode demandar apenas alguns dias. E ela ocorre de forma simultânea com sua co-irmã, a Engenharia de Requisitos (a outra macro-disciplina que forma BoK do Analista de Negócios, aquela que mereceu maior atenção do BABoK).

    Ao incorporar práticas de Análise e Modelagem de Negócios em seus processos para desenvolvimento ou implantação de sistemas de informação, a organização fortalece equipes e projetos. Indica que está falando sério quando fala em alinhamento estratégico. Entende que o negócio é tudo o que importa. Afinal, quem paga a dolorosa?

    .:.

    Modelagem de Negócios é o primeiro módulo do curso para Formação de Analistas de Negócios, que o finito realizará em conjunto com a Tempo Real Eventos. Conheça mais detalhes sobre o curso, e veja aqui o seu conteúdo programático.

    .:.

  • O Último Sprint

    Como eu disse no último post, começo agora o último sprint do processo de redação do livro “É o Negócio, Beócio!“. De acordo com o cronograma, no dia 31/dez entrego os originais para a gráfica. Como previsto, preciso aumentar o número de stakeholders-colaboradores. Por isso a agenda de eventos ganha outras datas, novas praças e novos formatos.

    Para o dia 7 de novembro (quarta-feira) está programada a 4ª edição do FAN – Formação de Analistas de Negócios – em seu formato tradicional. Quarta edição em Sampa, novamente no Centro de Convenções Pompéia. Provavelmente será a última turma do ano em terras paulistas.

    A turma da região Sul terá outra oportunidade. A Innovit promoverá uma turma do FAN em Floripa-SC, no dia 5 de dezembro (quarta-feira). Provavelmente o workshop será encaixado em um evento maior. Com desconto para a estudantada e tudo o mais. Em breve divulgo maiores detalhes.

    Antes dele, brotará em Sampa o primeiro filhote do FAN: um workshop sobre Engenharia de Requisitos, também promovido pela Tempo Real Eventos. Está agendado para o dia 13 de novembro (terça-feira), no Centro de Convenções Pompéia. Engenharia de Requisitos ocupa 50% do material de Formação de Analistas de Negócios. Mereceu um workshop exclusivo para que a disciplina seja explorada com maior profundidade (uma antiga solicitação). Será repleto de exercícios de desenvolvimento e gerenciamento de requisitos. Simulações de entrevistas, workshops e sessões de brainstorming estão previstas. A confecção de casos de uso e documentos auxiliares também. Os participantes terão a chance de usar vários “bonés” durante o evento: Analistas de Negócios (claro!), usuários, desenvolvedores, coordenadores… O workshop deve ser encerrado com a elaboração de um belo, memorável, objetivo e “vendedor” Documento de Visão.

    Mas a parte prática da outra metade do FAN, a Análise e Modelagem de Negócios, não foi esquecida. Ainda em novembro, também em Sampa, acontecerá um treinamento de 35 horas (!). Imersão total nesta disciplina que é tão negligenciada em projetos. Maiores detalhes sobre o treinamento eu divulgarei em breve. Mas anote aí na agenda: será em novembro (apesar dos 3 feriados!).

    .:.

    Apesar da agenda meio lotada, segue disponível a oferta de levar qualquer variação dos eventos acima para escolas, faculdades e universidades. Vascão* (ou seja: na faixa, grátis, zero800…). Quem se interessar, por favor, fale comigo.

    * Depende da localidade e de não causar nenhum tipo de prejuízo para outros profissionais ou empresas.

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

  • Rendiconti: FAN – 3ª Turma + Anhembi Morumbi

    FAN = Formação de Analistas de Negócios.

    Na última quinta (27) rolou a terceira turma do workshop promovido pela Tempo Real Eventos. Incrível como as 3 edições foram muito diferentes. Na primeira acertamos na mosca (a duração). Como era a primeira execução, foi sorte pura (e um cadinho de administração do tempo). Aí pintou a síndrome da 2ª vez: atrasei em 30 minutos seu encerramento. Mesmo assim, para a 3ª turma, coloquei uns 20 slides adicionais. Surpresa: o workshop terminou 1 hora antes do previsto!!

    A explicação mais óbvia foi a seguinte: um número menor de interações com a platéia. Teve menos debate, o que torna o evento um cadinho mais pobre. E a responsabilidade é só minha. A platéia, só para variar, era muito boa (sem demagogia, please! Se eu pudesse revelar o perfil das pessoas e empresas participantes…)

    A maior reclamação nas fichas de avaliação foi a de sempre: profundidade. Realmente é muito assunto para apenas 1 dia (7 horas). Como sobrou uma hora, eu poderia ter mergulhado mais em algum assunto. Mas qual? Desta vez “Casos de Uso” foi o tema que mereceu mais tempo. Ganhou alguns slides a mais também. Depois do evento (ah, se houvesse prorrogação!), caiu uma ficha: parte do debate (sobre casos de uso) aconteceu porque ainda há uma certa confusão entre requisitos e especificações. Ainda é difícil entender que “caso de uso” é um meio, não um fim. De novo: falha minha. Mas acho que já descobri o caminho das pedras. E vou usar um “liquidificador” para triturá-las. Em um futuro artigo eu explico.

    .:.

    Aproveitando uma oferta que fiz aqui no finito, aconteceu ontem (sex, 28) uma palestra para uma turma da Anhembi-Morumbi (Vila Olímpia). Deveria ser só uma versão “diet” do workshop, com 1h30 de duração. Não passei da 1ª parte, apresentando apenas o perfil, habilidades e responsabilidades do Analista de Negócios. Mas foi muito jóia. É uma experiência muito diferente. O prisma da estudantada é diferente daquele público que participa dos workshops. Daí minha oferta: espero atender parte das expectativas de estudantes e professores no livro. Uma bela parte, diga-se de passagem.

    A grande maioria da turma já trabalha (em TI, claro). Tem gente na Tata e na EDS.. Mas, ainda assim, o prisma e as necessidades deles são um tanto distintas. Assim como a interação. Há um certo ceticismo e até uma certa agressividade (palestra na 6ª é barra, né?). Mas foi muito divertido. Não dispensei nem o tradicional arremesso de giz (que carimbou o note de um dos rebeldes).

    Espero que parte da turma ingresse no grupo de discussão. Quero ver o caldo que dá.

    .:.

    Aliás, se você quer conhecer melhor o trabalho FAN, o conteúdo elaborado e também participar do grupo de discussão, fale comigo.

    Começo agora o sprint final: 90 dias para encerrar a redação do livro. Ainda acontecerão, no mínimo, 2 workshops e 1 curso. E todo apoio será muito bem vindo.

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

  • Repensando o Papel do Analista de Negócios

    Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido “pensá-lo”? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN’s! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN’s certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

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

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

    Jóia né? Mas aí apareceram os “poréns”. Comento abaixo cada um deles, na seqüência original:

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

    7. AN’s reduzem o feedback
      pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers , um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
    8. AN’s reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
      pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue “tirar o pé da jaca”. Ou, colocando d’uma forma menos agressiva: “não tira o boné de jeito nenhum”. Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN’s. E aprender muito com os bons AN’s.
    .:.

    Notas:

    1. Agility and Discipline made Easy: Practices from OpenUP and RUP
      Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
    2. More About Software Requirements
      Karl Wiegers. Microsoft Press (2006).

    .:.

  • Sobre o Livro (e uma Oferta)

    Quando decidi escrever meu primeiro livro, não tinha a menor idéia de como seria o processo. Escrever artigos, mesmo aqueles longos, é uma coisa. Um livro é totalmente diferente. Seth Godin e Scott Berkun, em seus blogs, costumam contar um pouco sobre seu processo. Ariano Suassuna, Chico Buarque e Luis Fernando Veríssimo me assustaram um tanto com seus depoimentos sobre o trampo. Mas, no final das contas, cada um tem seu processo, suas manias e traumas. Resolvi desenvolver meu próprio processo (e manias). Espero não colecionar muitos traumas. Mas sei que alguns serão inevitáveis.

    Começando do começo, fixei alguns princípios:

    • Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
    • O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
    • Peça de marketing não pode significar um livro “marketeiro” (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
    • O livro é um esforço “solo”. Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro “míope” (ou “caolho”) é muito grande.
    • Apesar de conhecer a tendência, o livro não será do tipo “como passar na prova”. Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.

    Na seqüência desenhei a extensão do livro, uma visão de “alto nível”. Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 “convidados”). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

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

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

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

    .:.

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

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

    .:.

  • (Requisitos) Levanta aí que eu Coleto daqui

    Seqüência de “Tácitos & Explícitos“.

    Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em “More About Software Requirements” , faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que “coletamos, descobrimos, inventamos e entendemos”. Espero ter passado a correta amplitude do trabalho.

    No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção…) de requisitos nestes dois grupos. Veja o gráfico abaixo :


    As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o “Fone” ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

    • Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
      Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
    • Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
      Novamente o cenário ideal exige a presença de dois AN’s, um conduzindo a reunião e outro registrando os achados.
    • Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
    • Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

    Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os “agilistas” não erram quando dizem que nada substitui o “tête-à tête”. Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O “mapeamento psicológico e sociológico” dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades “sociais” (soft skills): comunicação, negociação, intermediação, e por aí vai.

    Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O “Email” aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

    • Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
      Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como “análise Caixa-Branca”. Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
      Código Executável: ou “análise Caixa-Preta”, mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
      Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então…)
    • Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos “workshops” (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
      Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
      Versões de Testes: ou o “processo Google” de validação, com suas quase eternas versões “beta”. Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.

    Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns “agilistas”) gera um certo tipo de miopia no projeto.

    Um AN “completo” desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.

    .:.

    Notas:

    1. More About Software Requirements
      Karl E. Wiegers. Microsoft Press (2006).
    2. Gráfico foi inspirado neste, extraído de
      The Enterprise Unified Process: Extending the Rational Unified Process
      Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).
    .:.

  • Tácitos & Explícitos

    Há uns 6 anos me ‘cansei’ do estudo de engenharia de requisitos. Técnicas e métodos mudavam, mas mantinham uma sensação de déjà vu. As mudanças eram cosméticas ou uma questão de nomenclatura. As propostas “ágeis” (aspas não tornam o termo pejorativo) colocaram o Conhecimento Tácito na “coluna esquerda” (leia-se: nomearam-no o mais importante). Essa talvez tenha sido a mudança mais significativa nos últimos 10 anos da disciplina. Mas, basta olhar os métodos e técnicas sem muita paixão para descobrir que tem muito ‘revival’ ali, pouca coisa original.

    Foi quando decidi olhar a estranha disciplina “gestão do conhecimento” com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre “Gestão de Conhecimentos Inter-Projetos” , que acabou inspirando meu trabalho sobre “Aprendizado Inter-Projetos“. Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.


    O trabalho que me ‘pegou’ foi o clássico “Theory of Organizational Knowledge Creation”, de Hirotaka Takeuchi e Ikujiro Nonaka . Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):

    • Socialização: pessoas trocando idéias, de forma direta, conversando. É um canal rico, já que nossa comunicação não se limita a palavras, gestos e desenhos. Um sorriso pode ter n significados.
    • Externalização: pessoas transferindo seus conhecimentos para o papel (ou disco rígido, não importa). Estamos registrando idéias e experiências, de forma que elas possam ser úteis para outras pessoas.
    • Internalização: quando são (úteis), acontece a internalização. Ou seja, as pessoas aprendem ao ler um documento, diagrama ou rabisco.
    • Combinação: por fim temos a combinação, a transformação de um conhecimento explícito (texto, por exemplo), em outra forma de conhecimento explícito (diagrama ou código, por exemplo).

    Quando trato especificamente de engenharia de requisitos, gosto de dividir o diagrama acima em duas partes: o hemisfério esquerdo trata da coleta, descoberta e invenção de requisitos (estamos aprendendo). O hemisfério direito cuida de como analisamos, modelamos e comunicamos* os requisitos.
    * Observação: a comunicação também envolve o quadrante ‘socialização’.

    Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas “ágeis”. É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz “apenas”. Mas, infelizmente, muitos interpretam assim.

    Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado “meet in the middle”:

    Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento “mágico” eles “se encontram no meio do caminho”, confrontando requisitos, realidades, verdades, mentiras e restrições.

    Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.

    .:.

    Notas:

    1. Knowledge Management in Inter-Project Learning
      Daniel Fitzek. ITEM-HSG Universität St.Gallen (2002).
    2. Theory of Organizational Knowledge Creation
      Hirotaka Takeuchi e Ikurijo Nonaka.
      Publicado em “Knowledge Management – Classic and Contemporary Works”. MIT Press (2000).
    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.