PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Hot Commodity

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

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

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

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

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

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

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

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

    .:.

    Momento “Oportunista, eu?”

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

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

    .:.

  • D.E.V.A.G.A.R.

    Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento ‘business-centric’. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria ‘business-centric’. Na minha opinião, mais que ‘business-centric’, aquele conjunto de princípios – que, aliás, é muito legal – é mais ‘agile-manifesto-centric’ ou, em outras palavras, ‘developer-centric’.

    Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

    D)emonstrar Valor de maneira Iterativa
    Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

    E)ntender (e Melhorar) o Negócio
    É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

    V)alorizar os Ativos de Software
    Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

    1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
    2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

    A)daptar o Processo
    Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

    No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

    G)erenciar Requisitos (e Mudanças)
    Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

    A)tacar os Riscos
    Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

    R)espeitar os Usuários
    É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

    Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

    .:.

    Notas:

    1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
      O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
    2. Object Solutions – Managing the Object-Oriented Project
      Grady Booch. Addison-Wesley (1996).

    .:.

  • Business-Centric

    Quem participa do ótimo grupo UML-BR (Yahoo!Groups) deve ter visto uma discussão em torno da liberação da versão 1.0 do OpenUP. Em determinado momento, ainda lá nas primeiras mensagens, o debate virou “Architecture Centric X Business Centric”. Enquanto o RUP estaria mais para o primeiro, o OpenUP seria uma representação do segundo. Não é uma definição amplamente aceita. O RUP vem alterando seus princípios desde sua criação. Tanto que no verbete RUP da Wikipedia ele também é apresentado como “business centric”.

    Para entender: quando lançado, eram apresentados como princípios (ou grupos de melhores práticas) do RUP :

    1. Desenvolver software de maneira iterativa
    2. Gerenciar Requisitos
    3. Utilizar arquiteturas baseadas em componentes
    4. Modelar o software
    5. Verificar continuamente a qualidade dos artefatos gerados
    6. Controlar mudanças

    Com o tempo os princípios foram mudando. Em determinado momento, o “espírito do RUP” consistia em :

    1. Atacar os grandes riscos o quanto antes, continuamente
    2. Entregar valor para o cliente
    3. Direcionar seus esforços para gerar software executável
    4. Assimilar mudanças o quanto antes no projeto
    5. Definir uma arquitetura o quanto antes
    6. Construir o sistema com componentes
    7. Trabalhar como uma equipe
    8. Fazer da qualidade um modo de vida

    A pressão do “Agile Manifesto” e por um processo menos “pesado” continuou, o que nos trouxe para o mais novo conjunto de princípios que, segundo Per Kroll e Bruce MacIsaac , norteiam tanto o RUP quanto o OpenUP. São eles:

    • A)daptar o Processo;
    • B)alancear Prioridades dos stakeholders;
    • C)olaboração entre os times;
    • D)emonstrar valor de maneira iterativa;
    • E)levar o nível de abstração; e
    • F)ocalizar continuamente a qualidade.

    Este último conjunto seria, segundo seus criadores, “Business-Centric”, enquanto os dois anteriores, particularmente o primeiro, seria nitidamente “Architecture-Centric”. No grupo de discussão, respondendo ao Marcio Tierno e Rodrigo Yoshima, eu falei que não concordava com o rótulo “Business-Centric”. É um rótulo adotado pelos próprios criadores da lista de princípios. Se fosse um rótulo colocado por gente de fora, um consenso, tudo bem. Mas ao batizar suas idéias e sugestões de práticas de “business-centric”, os autores, imho, pesaram a mão. Eu disse que a lista parece mais “Agile-Manifesto-Centric”, enquanto o Tierno sugeriu “User-Centric”. Mas a crítica não basta.

    Desde então ando pensando em quais seriam os princípios de um processo “Business-Centric” de verdade. Meus 7 cents:

    • D)emonstrar valor de maneira iterativa
    • E)ntender (e Melhorar) o negócio
    • V)alorizar ativos de software
    • A)daptar o processo
    • G)erenciar requisitos (e mudanças)
    • A)tacar os riscos
    • R)espeitar os usuários

    Ops… D.E.V.A.G.A.R…. não deve pegar muito bem. Talvez com sobrenome: “Devagar e Sempre!” hehe..

    Mas, apesar do nome, gostei da idéia. No próximo post falo um pouco mais sobre cada princípio.

    .:.

    Bibliografia:

    1. The Rational Unified Process – An Introduction
      Phillipe Kruchten. Addison-Wesley (2000 – 2ª Edição).
    2. The Rational Unified Process Made Easy
      Phillipe Kruchten e Per Kroll. Addison-Wesley (2003).
    3. Agility and Discipline Made Easy – Practices from OpenUP and RUP
      Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
    .:.

  • Formação de AN’s – 3ª Turma

    Pois é, já vamos para a 3ª turma do workshop “Formação de Analistas de Negócios“. A Tempo Real Eventos já abriu a página de inscrições. Contando as duas turmas, já tivemos 114 participantes. 79 estão participando de um grupo de discussão exclusivo.

    Honestamente, eu não esperava um retorno tão positivo. O tema é relativamente novo. Ainda não vejo tanta demanda. Mas, a necessidade, por incrível que pareça, é uma “tendência”. Foi isso que li na divulgação de outro treinamento com tema similar. Que seja!

    Então seguem aqui algumas dicas e palpites aleatórios:

    • Atenção escolas, quem lançar um curso que mire a certificação CBAP (do IIBA) pegará um belo filé. Mas, por favor, cursos sérios! Sem gambiarras.
    • Aliás, não sei como se tropicaliza um ‘chapter’. Quem trouxe o PMI para o Brasil deve ter o caminho das pedras. Em se confirmando a demanda, o IIBA precisará de uma representação em solo tupiniquim.
    • Profissão em fase de criação sofre com muita desinformação. Como já registrei aqui, o BABoK (do IIBA) se concentra em Engenharia de Requisitos. IMHO, Modelagem de Negócios é tão importante quanto. Mas vão existir muitas variações de currículo, tenham certeza. No início, tudo bem. Desde que saibamos a hora de ‘desacoplar’ (coisa que o PMI, IMHO, não soube fazer).
    • A primeira especialização nítida: Desenhista de Processos (com ênfase em BPMS). O nome, com certeza, não será esse. Mas será um cara com muita demanda. Aliás, já é. Mas, cabe ressaltar, não dou muito espaço para ele no workshop. Falta tempo.
    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Rendiconti – Formação de AN’s (2ª Turma)

    Aconteceu na última quinta (2/ago), a 2ª turma do workshop “Formação de Analistas de Negócios“, promovido pela Tempo Real Eventos. 60 participantes! 10 além do limite esperado. Um tanto além das expectativas iniciais. Ainda não recebi a compilação das avaliações mas, pelos papos pós-evento, tudo indica que foi tão legal quanto a 1ª turma. Uma coisa posso dizer: foi mais dinâmico. O que acabou gerando um pequeno atraso. Felizmente a greve do metrô não nos atrapalhou muito.

    Como na turma anterior, aguardarei as avaliações para fechar esta prestação de contas. Por enquanto me limitarei a apontar coisinhas que devo providenciar para as próximas turmas (devemos ter pelo menos 3 em setembro, 2 em Sampa):

    • Iterativo & Incremental: ainda é uma dificuldade para muita gente. Acho que facilito a vida de todo mundo se levar um exemplo prático completo. Tenho certeza de que o Sr Antonio voltou para casa com a mesma opinião: “É uma cascata disfarçada”. Infelizmente não sobrou tempo para brigar com a certeza dele. Mas, se ele ficou com um pouquinho de dúvida, já me considerarei um pouquinho satisfeito.
    • Vou reduzir descrições de processos (particularmente o RUP) e deslocá-los para a parte final do workshop. Espero assim abrir mais espaço para exercícios.
    • Aliás, vou forçar um pouco mais os exercícios. Alguns deixarão de ser opcionais. Talvez eu até monte algumas “dinâmicas de grupo” (argh!). O único problema é realmente o tempo.
    • Foram vários participantes, de ambas as turmas, que sugeriram que o evento aconteça em 2 dias! Passei a bola para a turma da Tempo Real Eventos. Talvez a gente lance uma versão diferente: um dia só para Modelagem de Negócios e outro só para Engenharia de Requisitos. Talvez! Antes disso vou buscar a redução dos temas “menos relevantes”. A redução do espaço dos processos é meu primeiro alvo.
    • Mas não deixarei de brincar com o POREM e outras bullshitagenzinhas ágeis.
    • Tipo: “É difícil saber por onde começar” (trecho de um livro sobre User Stories).
    • Se a turma sai com boas pistas (sobre onde começar), considero que parte dos meus objetivos foi atingida.
    • Talvez assim fique mais fácil entender e aceitar o “É o negócio, Beócio!“

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

  • Proposições & Modelos

    Em “Processos de Negócios: São todos iguais?” eu escrevi que o classificação básica dos processos e a identificação da proposição de valor da organização são algumas das primeiras informações que um Analista de Negócios (AN) aprende para guiar seus trabalhos. Neste post vou explorar um pouco mais o tema, acrescentado outro dado que pode ser muito importante, dependendo do tipo de projeto: o Modelo Operacional da organização.

    .:.

    É mandatório que o AN conheça o perfil da empresa – aquele pequeno conjunto de características que a torna única. A parte que é (ou deveria ser ) mais evidente é a proposição de valor, dado que norteia praticamente todas as estratégias da empresa. Para Michael Porter existiriam duas proposições básicas: baixo custo ou diferenciação. Robert Kaplan e David Norton , depois de vários autores, fixaram a existência de quatro proposições de valor:

    • Baixo custo total;
    • Liderança do Produto (ou Inovação);
    • Soluções Completas; ou
    • Aprisionamento.

    Utilizei o “OU” (um XOR – OU Exclusivo) para mostrar que o natural é que a empresa apresente apenas uma proposição de valor. Seria uma questão de identidade. O que não significa que uma empresa reconhecidamente inovadora (Apple, por exemplo), não tenha preocupação com custos ou que ela não lance mão de táticas de aprisionamento (iPod + iTunes + DRM, por exemplo). O fato é que a primeira identificação (Apple = Liderança do Produto, seguindo no exemplo acima) é a sua proposição de valor. Algo como: “a primeira impressão é a que fica”.

    Qual a relevância desse aprendizado para o AN e para o projeto em questão? Acontece que a proposição de valor :

    • Determina o desenho dos processos de negócio da organização. Afinal, é através deles que ela cria valor;
    • Influencia diretamente a forma como a empresa administra seus recursos;
    • Caracteriza suas regras de negócio; e
    • Direciona seus objetivos e metas.

    Por exemplo: se a empresa se caracteriza por oferecer “Baixo custo total”, o AN se concentrará na extrema eficácia e eficiência dos processos de negócio. Gargalos, estoques de segurança e retrabalho são alguns dos principais sintomas que o AN procurará identificar . Assim como o AN deverá dar especial atenção à integração de dados (particularmente de clientes e parceiros), quando a proposição de valor da empresa for oferecer “Soluções Completas”.

    Mas a proposição de valor é apenas uma parte da equação. Ela nos diz o QUE a empresa levará para seus clientes e para a sociedade, mas não explica COMO o fará. É aqui que entram os Modelos Operacionais.

    Um modelo operacional indica “o nível necessário de integração e padronização dos processos de negócio para que a empresa possa entregar seus produtos e serviços para os clientes” . Trata-se de um conceito relativamente novo, que ainda carece de muitas pesquisas. Ou seja, será difícil encontrar uma empresa, particularmente em solo tupiniquim, que tenha institucionalizado seu Modelo Operacional. No entanto, mesmo que ‘sem querer’, toda empresa possui um modelo operacional (assim como toda empresa apresenta uma proposição de valor, por dúbia que seja).

    Na definição acima ficou claro que o modelo operacional possui duas dimensões: Integração e Padronização. O diagrama abaixo mostra as 4 combinações possíveis :

    • Diversificação: a empresa possui poucos (ou nenhum) processos integrados e padronizados. As unidades de negócio são autônomas e, geralmente, cuidam de suas soluções de TI (que são descentralizadas). Clientes, produtos e parceiros também não são compartilhados entre as unidades.
    • Replicação: processos não são integrados, mas são padronizados, o que garante escalabilidade. Normalmente os clientes não são compartilhados (como em modelos de franquias, por exemplo). O desenho dos processos é centralizado, mas as unidades de negócio são semi-autônomas. TI, na maioria das vezes, é totalmente centralizada.
    • Coordenação: processos não são padronizados, mas são altamente integrados. Isso indica que as unidades de negócio compartilham clientes, produtos e/ou parceiros de negócio. As unidades de negócio são autônomas, normalmente cuidando também de suas soluções de TI.
    • Unificação: integração e padronização plena dos processos de negócio, o que normalmente é obtido através do uso de sistemas de gestão centralizados (ERPs ou afins). TI também é centralizada.

    Não há um modelo melhor. Cada negócio pode exigir uma combinação única, ou até mesmo a adoção de combinações diferentes para alguns conjuntos de processos de negócio. Também não parece ser possível fazer uma vinculação direta da proposição de valor com um modelo operacional. Não de maneira arbitrária. Podemos encontrar, por exemplo, empresas que oferecem “baixo custo total” e utilizem o modelo “diversificação” ou o modelo “unificação” – os dois extremos da matriz acima.

    Ou seja, o AN deve levantar as duas informações: descobrir a proposição de valor da empresa e também o seu modelo operacional. Quanto tempo ele deve gastar em tamanha descoberta? Se a empresa for ‘organizadinha’, uns 10 minutos. Caso contrário, meia hora deve ser suficiente. Sem exageros. Como eu disse anteriormente, são informações muito básicas. Mas caríssimas em várias decisões do projeto. Em um futuro artigo tentarei demonstrar essa relevância toda na prática.

    .:.

    Notas:

    1. Competitive Advantage: Creating and Sustaining Superior Performance
      Michael Porter. Free Press (1985).
    2. Mapas Estratégicos
      Robert S. Kaplan e David P. Norton. Editora Campus (2004).
    3. Reparem nos itens em negrito daquela lista: Processos, Recursos, Regras e Objetivos. Através destes 4 elementos básicos devemos ter condições de descrever qualquer negócio. No workshop ‘Formação de Analistas de Negócios‘, mostramos como eles podem ser representados em diagramas UML.
    4. Para alguns, o AN deveria ser um mero “coletor de requisitos”. Outros, como este que os aporrinha, crê que um AN pode ser mais útil como um mix de palpiteiro e enfermeiro de processos: um cara que não faz vista grossa para processos de negócio doentes.
      Aliás, ao detectar processos “dodói”, o AN aumenta consideravelmente as possibilidades de antecipar mudanças, reduzir riscos do projeto, etc etc
    5. Enterprise Architecture as Strategy
      Jeanne W. Ross, Peter Weill e David C. Robertson. Harvard Business School Press (2006).
    6. Menos de 10% (chute meu) dos participantes da 1ª turma do workshop não souberam dizer qual a proposição de valor de suas organizações. A turma que representava órgãos públicos (principalmente prefeituras) titubeou um pouco, mas logo (eu acho) concordaram: Prefeituras = Soluções Completas.

    .:.

  • Código = Documentação?

    Na pequena série sobre o “Agile BA” eu prometi um post para falar especificamente sobre Documentação – o 2º maior pesadelo dos programadores.

    Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.

    O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal “documentação”. Enquanto trato de outras prioridades, fica a provocação:

    “Software is the leaky abstraction. It makes poor documentation for a business process.“

    .:.

  • Agile BA Parte III – Criando Caso

    Última parte de uma pequena série que tratou dos problemas da Anne, uma Scrummaster que foi ligeiramente afetada por um curso de Análise de Negócios. Como adiantei na semana passada, vou criar caso questionando algumas estórias.

    .:.

    Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos, as User Stories são formadas por três elementos:

    • Cartão: onde escrevemos as estórias ;
    • Conversas: que nos levariam a entender e detalhar as estórias; e
    • Confirmação: o ‘the end’, o fim da estória.

    A motivação para tamanha invenção gira em torno da palavrinha ‘documentação’ (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo reforça: “os cartões representam os requisitos do cliente, mas não os documentam”. Vai na linha de um mestre-pacificador (mezzo tucano) que vive insistindo: “gente, modelagem não é documentação… modelagem não é documentação… isso é um mito”. Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

    No post anterior eu destaquei um probleminha com o processo adotado pela Anne: “Nós organizamos as cento e poucas estórias por processos de negócios…”. Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) : “É difícil saber por onde começar”.

    Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de “organização de estórias”. Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

    Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo .

    .:.

    Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador , “um caso de uso é o nosso constructo para um processo de negócio”; ” descrevem o negócio e o seu ambiente”.

    A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso :

    • Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
    • Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
    • Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD’s e afins por aí.
    • Estimáveis: ok, UCP‘s são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
    • Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado – regrinha básica;
    • Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que : “Se um requisito não pode ser testado então ele não é um requisito”.

    Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de ‘casa de ferreiro… espeto de bambu’ (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas…

    … começando do começo: o Negócio.

    .:.

    Notas:

    1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
    2. User Stories Applied: For Agile Software Development
      Mike Cohn. Addison-Wesley (2004).
      Obs: Mesmo autor do artigo sobre UCP referenciado acima.
    3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre “estória versus história”? Pois é, me lembrei deles na hora de traduzir stories.
    4. The Power of Stories
      Rachel Davies. XP 2001.
    5. Debunking Modeling Myths
      Scott W. Ambler. Software Development (Agosto/2001).
    6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
    7. The Object Advantage – Business Process Reengineering with Object Technology
      Ivar Jacobson. Addison-Wesley (1995).
    8. Requirements-Led Project Management
      Suzanne e James Robertson. Addison-Wesley (2005).

    .:.

  • Agile BA Parte II – Os Problemas da Anne

    Seqüência deste post, onde a Anne, uma Scrummaster, tenta justificar seu desejo por um pouquinho de ‘planejamento up front’ em seu projeto. Reforço o ‘pouquinho’ para dizer que não se trata do combatido BDUF (Big Design Up Front). BDUF, BPUF, SPUF… ufs…

    .:.

    Um sintoma que indica que o trabalho da equipe da Anne começa ‘muito solto’ pode ser identificado na seguinte sentença: “Nós organizamos as cento e poucas estórias por processos de negócio…”

    Parece que as estórias são coletadas de uma forma aleatória. Os tais ‘workshops para coleta de estórias dos usuários’ não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.

    Se o AN começar seu trabalho “do início”, ele não terá o trampo de “organizar estórias por processos de negócio”. Ele realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro – em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.

    Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.

    Me desculpem o rabisco, mas usando uma variação da UML o mapa de processos pode ficar mais ou menos assim:

    Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?

    Nota: Mapa = um ‘pouquinho’ de planejamento up front‘.

    .:.

    Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as ‘estórias’. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.

    Observações:

    1. Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
    2. Todos os diagramas da apostila/livro, por enquanto, estão no padrão “rabisco”. Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
    3. EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro “Business Modeling with UML“, de Hans-Erik Eriksson e Magnus Penker – Wiley/OMG (2000).

    .:.

  • Agile BA

    Ou AN Ágil. Acontece que boa parte deste post estará em inglês. Há cerca de uma semana está rolando uma discussão muito boa no grupo APM (Agile Project Management – Yahoo). Anne, Scrummaster, fez um curso para Analistas de Negócios. Aproveitou uma thread para dizer mais ou menos o seguinte: “logo depois do curso bateu uma vontade danada de fazer um pouco mais de planejamento antes de cair na ‘sangria desatada’ do projeto”.

    Pronto, virou prato feito para extremistas-desastrados-alérgicos-a-planos. Depois de um tanto de mensagens, algumas bem mal educadas (pra variar), Anne apareceu com a seguinte resposta:

    “To clarify what I said about wishing we had done more planning up front, what we did do was jump right in with a user story writing workshop. We organized the 100+ stories by business processes and the product owner prioritized enough for the first few sprints. After two complete sprints, our sprint retrospectives reflect that for the customers are pleased with the Scum process. However, the product owner said ‘adjusting to agile methodology without the complete picture of project’ was a frustration.

    “Now, don’t jump on me. ‘Complete picture’ doesn’t have to mean a fully verified, validated humongous requirements package. I think we haven’t sufficiently defined the scope of the project, which means we haven’t sufficiently set customer expectations or figured out how our project impacts other ongoing processes and projects. In addition to better scope definition, I would like to do some simple operational concepts and/or modeling of current processes to (1) help all the customers understand their work processes and be able to explain them better and (2) help them generate ideas for improving the processes, especially with the new and exciting capabilities of the system we’re developing. We are replacing an internal data-intense management system in our public sector agency. An agile project in the private sector may not have time for this level of planning. We do, and I think it would be time well spent, as long as we keep in mind the goal of a production-ready system in an acceptable amount of time.”

    .:.

    “Dont jump on me”! Hehe. Ninguém deveria. Anne foi didática e precisa. É claro que você pode fazer análise de negócios de uma maneira ágil. Pode não. Deveria fazer. A coisa talvez chegue em um ponto em que a gente tenha que distinguir: ágil adjetivo ou “ágil” substantivo? tsc, tsc..

    .:.