PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Iterativo e Incremental

  • O Assassinato de um Projeto pelo Covarde Seu Moreira

    O seu Moreira era feliz e não sabia. Seus bem cuidados produtos eram distribuídos em quase toda grande São Paulo. Para tanto contava com uma motivada equipe de 40 vendedores. E um processo de venda bem simples. Cada vendedor tinha sua caminhonete e um estoque calculado para durar o dia inteiro. Apenas 5% das vendas não aconteciam com pronta entrega. Seus clientes eram as padocas e pequenos mercados de bairros. O vendedor visitava o cliente, conferia seu estoque e fazia reposição do que era necessário. Emitia manualmente a nota fiscal, enquanto saboreava o cafezinho gratuito e quente. Os fregueses melhores & maiores recebiam visitas semanais. Os outros, quinzenais. O negócio do Moreira ia bem, sem grandes problemas, há mais de 20 anos. Até que aconteceu aquela festa de final de ano na ASSPRONG. Seu Moreira não era de festejos. E se arrepende até hoje de ter participado daquele.

    A festança, como sempre, era uma chatice só. Esquentando na mão a única taça de espumante que se permitiu, seu Moreira já ensaiava uma saída estratégica pela esquerda quando foi interrompido pelo VP de Marketing e Relacionamentos da ASSPRONG, o Zé Bragantino. “Moreira, meu querido, deixa eu te apresentar o Welldonedson, diretor de vendas da cervejaria ACME”. O sujeito sorria de orelha a orelha e tinha os ralos louros cabelos domesticados por gumex. Amenidades trocadas com a usual superficialidade e logo o papo foi para os negócios. Imediatamente perceberam a semelhança entre os seus. A base de clientes era diferente – a ACME vendia principalmente para bares e restaurantes. Mas o modelo de distribuição e atendimento era idêntico. Mas a prosa ruim pendia para o encerramento rápido. Até que Welldonedson revelou um número que deixou o Moreira embasbacado e embaraçado: seus vendedores atendiam uma média de 80 clientes por dia. “Como isso seria possível?”, pensava o assustado Moreira. Quando não chovia e o trânsito não estava tão infernal, seus vendedores conseguiam visitar, no máximo, uns 30 fregueses.

    Welldonedson seguia contando gogó para um Moreira que só fingia ouvir enquanto calculava e pesquisava o mistério da produtividade absurda dos vendedores da ACME. Criou coragem e quis saber sobre os recursos que municiavam os vendedores do Welldoneson. Tinha os carros modernos, mas eles não significam muita coisa numa cidade onde a velocidade média é de 20km/h. Tinha também o GPS, mas o Moreira sabia que o feeling de seus vendedores para o trânsito era mais eficiente que qualquer engenhoca moderna. Além disso, todos tinham tatuados no cérebro seus roteiros de visita, atalhos e pontos de fuga.

    Moreira já ia perder a esperança de descobrir o segredo até que Welldonedson citou o maravilhoso sistema de automação de força de vendas que eles implantaram havia um ano e meio. “Sales Force Automation, ess éff êi”, foi como ele falou. Uma maravilha, uma teteia, uma joia 100% customizada para as características muito específicas da ACME. “Atrasou um ano e custou uns 2 milhões, mas valeu a pena. E o senhor sabe, né seu Moreira, todo projeto de alta tecnologia é assim mesmo”. Moreira concordou com um leve movimento da cabeça. Ele não sabe o que é projeto de alta tecnologia e muito menos “que eles são assim mesmo”. Se despediu sem jeito e deixando a taça de vinho na mão de Welldonedson que disse “até mais” já procurando pelo próximo ouvinte-vítima.

    Foi um final de semana inteiro de noites mal dormidas. Seu Moreira não conseguia parar de pensar na possibilidade de duplicar a produtividade de seus vendedores. Sua linha de raciocínio era simples: dobro de visitas = dobro do faturamento. Poderia até mesmo expandir sua área de atuação. E sem contratar mais ninguém? Parecia bom demais para ser verdade. Mas, pôxa, se a ACME pode, por que o seu Moreira não poderia?

    Na segunda-feira, logo cedo, Moreira chamou o contador e o sobrinho para uma conversa. Eram os dois que mais entendiam desse negócio de computador. Ambos ficaram surpresos. Moreira nunca havia demonstrado entusiasmo algum com coisas assim. Aliás, parecia odiar qualquer “recurso tecnológico que promete acelerar toadas”. Mas agora parecia apaixonado pela ideia de ter um sistema que dobraria suas receitas. A produção não seria problema. Se fosse o caso, disse Moreira, eles fariam com que o 2º turno fosse permanente e não apenas em ocasiões especiais. Nada o distraia ou tirava seu foco: ele queria falar sobre o sistema. “Quem faz esse tipo de coisa?”.

    Dois dias depois eles já recebiam 3 empresas que se candidataram para desenvolver o sistema. Gente de terno e gravata e um linguajar que fazia o Moreira interrompê-los a cada duas frases: “Java? Java é um cliente nosso, lá no Bixiga”. O sobrinho assumiu as negociações. As propostas deveriam chegar até o final da tarde da próxima sexta. Uma das 3 empresas sugeriu a visita de um analista de negócios para entender melhor os requisitos. Sobrinho e contador o receberam na tarde de quarta-feira. “Entrevistar os vendedores? Hmm… não vai dar não. Estão todos na rua, vendendo né? Mas pode perguntar que a gente sabe tudo sobre o negócio.”

    Nove meses depois, cinco além do prazo combinado entre as partes…

    Os vendedores não estavam na rua como deveriam. Estavam todos em reunião com o Moreira, tentando explicar os motivos de não conseguirem mais visitar nem 20 clientes por dia. “O programa é complicado demais, seu Moreira”, insistia Jojoaquim*, o funcionário mais antigo. “A gente tem que conferir e digitar todo o estoque do freguês toda vez, porque dá diferença”, explicava Mustafá. “E a emissão da nota então, seu Moreira. É lerda demais. Quando a gente fazia na mão era mais rápido” disse Magrão, com sua tradicional voz de choro.

    O sobrinho do Moreira tentou culpar os vendedores mas engoliu um parágrafo inteiro quando viu a cara do tio e se lembrou do tanto que ele protegia sua equipe. O contador só fitava, ameaçador, o coitado do analista de suporte que representava a empresa que tinha desenvolvido a aplicação. O moleque, ainda com espinhas na cara, não escondia o constrangimento e o medo. Coitado, ele não tinha nada a ver com aquilo. E explicou que tinha corrido tudo bem no treinamento. E que a aplicação estava lenta, mas ele desconfiava que era culpa do Windows e que um pouco mais de RAM talvez resolvesse a questão. Moreira não entendia nada do que era falado. Entendia menos ainda o fato dos seus vendedores estarem visitando menos clientes depois dele ter gasto “os olhos da cara, ora pois” em um projeto que visava exatamente o contrário.

    .:.

    Observações:

    1. A imagem utilizada, “1918 Farm Auction“, foi colocada no Flickr por Dok1. Eu não sabia que ‘Acid Test’ era um termo tão antigo.
    2. O texto acima deve ajudar a mostrar o tipo de ‘causo’ que serve como base para os exercícios dos 2 Jogos dos 7 Erros, eventos que acontecerão no próximo mês.
    3. Aquele * deve mostrar que não se trata de um erro de digitação. O pai do Jojoaquim era gago. E o escrivão era um brincalhão.

  • Prioridades 2: As Origens

    Sequência do papo sobre “Prioridades & Banalidades“.

    Se uma organização não sabe o que quer e não tem a mínima noção do caminho que pretende trilhar, então não podemos esperar que a equipe de projeto saiba dizer o que é prioritário em seu trabalho. Os ventos mudarão diariamente e o barco vagará a esmo. Até afundar, que é o que costuma acontecer com muitos projetos, particularmente de TI.

    Nas turmas do FAN eu costumo recomendar o seguinte: se a estratégia, se o valor do projeto não está claro para clientes, patrocinadores e usuários, então é melhor nem começar o trabalho. Se não atacar o quanto antes as dúvidas e ambiguidades, que provavelmente são fruto de sérios problemas de comunicação, a equipe estará assimilando riscos que dificilmente terá condições de administrar quando o projeto ganhar ritmo.

    Mas é curioso que até em empresas que apresentam um processo de planejamento aparentemente robusto as equipes tenham dificuldade de definir suas prioridades. Em dado momento as organizações elaboram e refinam seu portfólio de projetos. Em algumas o horizonte é de um ano ou mais. É a estratégia da empresa, sua Visão, que norteia o processo e ajuda a definir os projetos prioritários. Seria de se esperar que as mesmas informações que guiaram esta tomada de decisão sejam utilizadas pela equipe de projeto. Surpreendentemente, não é o que acontece em diversas organizações.

    Em algumas há a definição de que esse tipo de informação é sensível e merece sigilo. O que desemboca no engano de achar que uma equipe não precisa saber o que o negócio ganhará com o projeto. Pode parecer absurdo, mas já vi clientes e usuários urrando: “Você não precisa saber disso!”. Como não? Quem pensa assim ignora que os desenvolvedores tomam dezenas ou até centenas de decisões por dia. Decisões que afetam o negócio de uma forma ou de outra.

    Em outras organizações – que interpretam de maneira diferente o mantra “Informação é Poder” – os problemas com a definição de prioridades são outros. A equipe não é municiada com requisitos do negócio simplesmente porque não pergunta por eles. São diversos os fatores que ajudaram a criar essa alienação. Um dos principais, desconfio, é a mentira que diz que “tudo é para ontem”. E, se a pressa é grande, por que cargas d’água um analista perderia tempo tentando entender as motivações do projeto? Eles vão direto ao que interessa, aos requisitos que brotam e lotam listas. O problema é que esses requisitos, desprovidos de sentido, dizem muito pouco sobre o caminho que a empresa espera tomar. E fica simplesmente impossível que a equipe saiba dizer o que é prioritário.

    Sabe o que é estranho e paradoxal nessa lenga-lenga toda? É que normalmente o entendimento dos objetivos do negócio não rouba nem 30 minutos de um analista de negócios. O não entendimento costuma roubar muito mais.

    .:.

    Novamente surrupio uma foto da Tanakawho, “Indecision at the last moment“. O surrupio é legal!

  • Prioridades & Banalidades

    É curiosa e perigosa uma dificuldade que vejo por aí com uma certa frequência: Equipes de projetos não sabem ou não conseguem dizer o que é prioritário. O escopo de projetos de software é tratado como um monolito. E a iniciativa vira um jogo de 8 ou 80 – de tudo ou nada. Segundo analistas e desenvolvedores, seriam os usuários os principais responsáveis pela falta de flexibilidade. Algo como: “se eu estou pedindo, então é prioritário”. Todos os requisitos¹ são recebidos e tratados como iguais. É difícil que algum tipo de projeto possa evoluir bem com tamanha rigidez.

    A situação é curiosa porque não reflete nosso comportamento cotidiano. É natural que as pessoas considerem opções e definam prioridades quando vão fazer qualquer aquisição que comprometa uma fatia de seu orçamento. Pense na compra de um carro novo, por exemplo. Você define o que é fundamental, como marca, modelo, potência e cor. Elege itens importantes como o trio elétrico, tipo de combustível, airbag etc. Por fim, lista os opcionais que você só comprará caso o bolso permita, como o MP3 player com entrada USB, DVD para as crianças etc.

    Software é muito maleável. Qual o motivo, então, para tratá-lo de forma tão inflexível? Desconfio que a culpa não seja só dos usuários. Aliás, desconfio que eles não tenham culpa nenhuma nesta questão. Não na maioria das vezes.

    Quando utilizamos um processo que prevê a “coleta” (sic²) de todos os requisitos nos momentos iniciais do projeto, implicitamente estamos dizendo para os usuários: “fale agora ou cale-se para sempre”. Parece natural que os usuários tentem se lembrar de tudo. Que eles tentem entuchar de *tudo* naquilo que chamamos de escopo. Assim como é natural a reciprocidade. Ou seja, se eles só tiveram uma chance para falar, também darão apenas uma chance para a equipe entregar *tudo* o que eles pediram. Mas, apesar de ser irritantemente comum, o sintoma acima foi apresentado de maneira simplista porque explica apenas uma parte do problema.

    Muitos analistas e desenvolvedores se comportam como “tiradores de pedidos”. Vão conversar com os usuários e se limitam a registrar, vírgula por vírgula, *tudo* o que eles pedem. Se desconhecem o negócio, seus objetivos e o problema em questão, os analistas não apresentam condições de criticar o que está sendo pedido. Acontece que em algumas empresas os analistas não têm o direito de criticar. Será que um dia eles serão cobrados por terem o dever de criticar?

    A visão crítica e criativa aplicada ali, no nascedouro dos requisitos, é que permite uma priorização realmente eficaz. E esta visão só existe quando há um bom entendimento do negócio.

    .:.

    Como o papo é longo e anteontem eu prometi artigos mais curtos (e frequentes), o papo seguirá em posts futuros. Inté!

    Observações

    1. Caso seja de sua preferência, leia “histórias” (ou User Stories) onde escrevi “requisitos”.
    2. O termo “coleta” é muito ruim. Dá a impressão de que os requisitos estão lá, prontinhos e maduros, como tangerinas no pé. Na realidade nós *aprendemos e desenvolvemos* requisitos, sempre com os usuários.
    3. A imagem utilizada, Arch, é da Tanakawho – talento que libera suas obras no Flickr com licença Creative Commons.

  • Fracasso 2.0

    Sequência do papo sobre “O Novo Gerente de Projetos“. Segunda parte de um total de três (ou quatro).

    Em todas as turmas do FAN, quando mostrando como todos os requisitos devem derivar dos objetivos do negócio, sempre comentei o seguinte: meu currículo apresenta projetos que tiveram problemas com prazos e orçamentos. Alguns maiores, outros nem tanto. Só me sentiria envergonhado se apresentasse ali algum projeto que tivesse falhado na realização dos objetivos do negócio.

    A comunidade de gerenciamento de projetos tem demonstrado maior preocupação com o Valor gerado para os negócios. Dentre vários artigos e outros trabalhos distingue-se, por exemplo, “Diferenciando os Alinhamentos Estratégicos de Projetos“, de Ana Helena Moreira e Fabio Medeiros, publicado na MundoPM de Abr/Mai de 2009. Eles demonstram como a Proposição de Valor de uma organização, da qual derivam as estratégias, deve direcionar “o foco e o conteúdo dos elementos do gerenciamento de projetos”. Aliás, o título do editorial da mesma edição, assinado por Zózimo, é “Valor“.

    O PMBoK¹ não dá margens para dúvidas quando registra que “projetos são meios para a realização de metas ou objetivos da organização”. Nem quando afirma que o gerente “entrega projetos balanceando requisitos de escopo, prazos, qualidade e custos”. Ele falha, em minha opinião, quando não explicita que tal “balanceamento” deveria ser orientado pelos objetivos do negócio. Na realidade, o grande problema do PMBoK é não fazer refletir em seus processos a devida preocupação com a satisfação das metas e objetivos da organização.

    Alinha-se ao PMBoK o Chaos Report, relatório publicado pelo Standish Group desde 1994. Alinha-se? Sim, ao considerar que um projeto *falha* quando atrasa e/ou estoura orçamento e/ou não entrega todo o escopo *planejado*. Ambos os trabalhos ainda apresentam em seu “espírito” uma preocupação exagerada com o plano. Contra desvios são recomendadas “ações corretivas”, o que deixa entender que o plano está sempre correto; Equivocada seria a execução.

    Apesar da qualidade aparecer entre itens que precisam ser “balanceados”, tanto PMBoK quanto o Chaos Report nos remetem ao velho “Triângulo de Ferro” do gerenciamento de projetos: Escopo, Prazos e Custo. Esses três itens configuram as principais preocupações de um gerente de projetos. E elas estão explicitamente refletidas nas várias práticas e processos sugeridos não só nos dois trabalhos mas em vários outros que tratam o gerenciamento de projetos.

    O primeiro dos 12 princípios do Manifesto Ágil diz que: “Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso”. Valioso no sentido de que o produto entregue realmente representa um meio eficaz para a busca dos objetivos do negócio. Vários métodos, frameworks e práticas derivados do Manifesto Ágil atestam tal preocupação. Mas alguns parecem limitar a percepção de valor à medição do ROI (Retorno sobre o Investimento). É suficiente?

    O Novo Triângulo

    Um Novo Triângulo para o Gerenciamento de Projetos
    Um Novo Triângulo para o Gerenciamento de Projetos

    Jim Highsmith, em “Agile Project Management – Second Edition²“, sugere a adoção de um “novo triângulo”, de algo que de fato represente as principais preocupações de um novo gerente ou líder de projetos. Para ele, as três pontas deste novo triângulo são: Valor, Qualidade e Restrições. Segue uma breve explicação sobre cada uma:

    • Valor: representa diretamente a contribuição para a realização dos objetivos do negócio. Quando tratamos de um sistema para uso próprio, avaliamos e valorizamos a eficácia com a qual ele ajudará a empresa na busca pelos seus objetivos.
      Quando a principal saída de um projeto é um produto ou serviço para uso de terceiros, o Valor indica tanto a satisfação destes quanto a realização das estratégias comerciais.
      Aqui é importante destacar que o Valor também representa a Qualidade Extrínseca ou externa do produto ou serviço. Essa qualidade é imediatamente percebida pelo cliente e não é a mesma citada como segunda ponta do triângulo.
    • Qualidade: esta é a Qualidade Intrínseca ou interna do produto, e refere-se principalmente à sua confiabilidade e capacidade de adaptação. Por exemplo: um produto pode ser muito bem recebido por um cliente no primeiro momento – seu Valor foi percebido pelo cliente. No entanto, quando mudanças são necessárias mas de difícil e cara implementação, consideramos que a qualidade do produto é baixa, sofrível ou inexistente.
    • Restrições: e quem disse que o velho triângulo deveria ir para o lixo? Muito pelo contrário. É aqui, formando a terceira ponta do novo triângulo, que manifestamos nossa preocupação com Escopo, Prazos e Custos. Como reforça Jim, utilizando o mesmo padrão de apresentação dos valores do Manifesto Ágil, a colocação das restrições como apenas uma ponta do novo triângulo não significa dizer que elas não são importantes. Mas é considerável o impacto na crença de que a realização sem desvios do escopo, prazos e custos previstos seriam suficientes para determinar o sucesso de um projeto.
      E esta não é a única mudança. Além do livro de Jim, um outro trabalho a ser publicado em 2010, “Agile Product Management with Scrum³“, sugere um interessante tratamento das restrições. Das três – escopo, prazos e custos – uma é mais relevante para a realização dos objetivos do negócio. Apenas ela deveria ser fixada. As outras duas seriam tratadas com certa flexibilidade. Por exemplo: o prazo, o time-to-market, é considerado crucial para o sucesso de determinado produto. Sendo assim, tanto o escopo quanto os custos poderiam variar. É claro que não se trata de flexibilização total (e insana). Mas o cliente ou patrocinador aceitaria a flutuação dentro de uma faixa pré-estabelecida. Os custos ficariam entre $ 80 e $ 120, por exemplo. Também seria aceitável o possível corte de algumas funcionalidades opcionais (ou secundárias). Tudo para que o prazo, neste exemplo a restrição mais importante para o negócio, fosse atendido plenamente.

    .:.

    Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro, “planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.

    Do outro lado, do Mundo Ágil, espero a compreensão de que o ROI (Retorno sobre o Investimento) não é a única unidade de medida ou preocupação que deve nortear um projeto ou mesmo indicar seu sucesso ou fracasso.

    Mas… devo me segurar. Afinal, prometi uma série de artigos com provocações e questionamentos, não com conclusões. Portanto, deixo algumas questões: Como você mede o sucesso de seus projetos? E o fracasso? Você realmente acredita que um projeto cancelado significa um fracasso? Planos não realizados em sua plenitude são fracassos? Essas percepções são compartilhadas por todas as partes interessadas?

    O papo seguirá. O próximo artigo será “O Mundo Mudou“. Inté!

    .:.

    Referências

    1. Guide to the Project Management Body of Knowledge – PMBoK® Guide, Fourth Edition.
      PMI – Project Management Institute. 2009.
    2. Agile Project Management – Second Edition.
      Jim Highsmith. Addison-Wesley, 2010.
    3. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley, 2010.

    A figura utilizada no topo do artigo, flikr2298, é do Flikr e liberada como Creative Commons (by).

  • O Novo Gerente de Projetos

    Quase cometi um “O Mundo Ágil precisa de Gerentes de Projetos?“. Não o fiz porque, além de apelativo, o título remeteria ao artigo anterior, quando repeti a mesma pergunta para falar sobre analistas de negócios. Se naquele texto eu apresento uma conclusão, agora meu objetivo é apresentar alguns cenários e provocações. Na realidade, vou apenas compilar e repassar uma série de ‘achados’ que devem nos ajudar a debater e, se for o caso, definir um novo Gerente de Projetos. Soou pretencioso, né? Repare que a intenção é ajudar a definir, ok? São meus R$ 0,02.

    Antes de qualquer coisa: por que precisaríamos de um novo gerente de projetos? Algumas respostas: 1) O Mundo Mudou; 2) Os Fracassos são Constantes; e 3) Os Gerentes Vivem Sobrecarregados e Criticados. Se você não acredita nessas motivações ou acha que elas não são suficientes para justificar esse papo todo, então poupe seu tempo. Caso contrário, espero não chateá-lo com a série de 3 ou 4 partes que se inicia aqui. Sim, precisarei de uma série para desfilar alguns ‘achados’. Vamos lá.

    Gerentes de Projetos Vivem Sobrecarregados e Criticados

    E as causas são conhecidas. Em TI, insistimos em gerentes de projetos (GP’s) que também devem apresentar bons conhecimentos de determinadas tecnologias. Ou seja, muitos esperam que o GP seja também uma espécie de arquiteto. Ou, no mínimo, que ele consiga orientar ou validar o trabalho técnico desenvolvido. Isso sem isentá-lo de todas as tarefas administrativas. Não é a primeira vez que toco neste ponto e não pretendo explorá-lo em maiores detalhes. Me limitarei a citar Fred Brooks (“O Mítico Homem-Mês”, Campus, 2009): “Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos”.

    Outra causa do excesso de trabalho é o microgerenciamento. Não importa se a “culpa” é do profissional ou do processo utilizado. Ou mesmo da falta de um. O fato é que, a partir de determinado porte, é simplesmente impossível microgerenciar um projeto. Claro, considerando uma jornada de trabalho de 8 horas por dia.

    Mas o efeito mais importante do microgerenciamento é outro: a insatisfação da equipe. Projetos de TI são tocados por “trabalhadores do conhecimento” – profissionais que gostam e precisam de espaço e autonomia para desempenhar bem suas funções. Temos aqui um típico exemplo de relação “perde – perde”.

    Aquilo que chamo de “Mundo Ágil”, o conjunto de propostas derivadas do Manifesto Ágil, endereça essas questões de diversas maneiras.  Tem poucos dias, por exemplo, Tobias Mayer escreveu em seu Twitter que: “Projetos ágeis não precisam ser ‘gerenciados’. Eu gostaria que este oxímoro fosse banido de nosso vocabulário”. Sua ‘revolta’ foi motivada por este anúncio, que fala de certificação em gerenciamento de projetos ágeis.  Só para clarear: oxímoro é uma figura de linguagem que coloca dois termos antagônicos, contrários, em uma mesma expressão. Tobias considera então que “gerenciamento” e “projetos ágeis” devem ser como água e óleo. Desconfio que ele quer dizer outra coisa: projetos ágeis não precisam de gerentes.

    A implementação mais comum deste conceito de “não-gerenciamento” é o “autogerenciamento”. A equipe se gerencia, sem nenhum tipo de interferência externa. Não há ingerência, já que todos podem falar sobre o trabalho de todos. Na realidade, em dada situação, algum membro da equipe pode assumir a responsabilidade por uma tomada de decisão. Mas o gerenciamento é uma responsabilidade de todos.

    Ainda no Mundo Ágil, mas em um pólo bem diferente de Tobias e outros, está Jim Highsmith. Na segunda edição de “Agile Project Management” (Addison-Wesley, 2010) ele quebra o termo “autogerenciamento” para clarear alguns pontos. Ele defende que uma equipe seja auto-organizada. Isso estaria no ‘core’ do APM (Agile Project Management) e a sua viabilização seria uma das principais responsabilidades de um Líder (ele não usa os termos gerente ou coordenador de projetos).

    Ainda segundo Jim, existem também os times “autodirigidos”, aqueles que independem de um líder. Em inglês ele usa o termo Leaderless. Para ele, esse tipo de estrutura “vai contra várias pesquisas que mostram que o sucesso em projetos e organizações dependem de bons líderes”. Algumas páginas adiante, mais precisamente na 60, Jim ‘desce o malho’: “Equipes auto-organizadas estão no núcleo do gerenciamento ágil, mas os conceitos estão corrompidos em setores da comunidade ágil. Apesar de ser um bom termo, ele tem sido, infelizmente, confundido com anarquia”. E prossegue: “É fácil combater os gerentes fracos e defender sua eliminação. Muito mais difícil é trabalhar com as organizações para que elas alterem seu estilo de liderança de forma a suportar um ambiente ágil”.

    Melhores líderes e um melhor estilo de liderança  não significam, na visão de Jim, que uma equipe não possa se auto-organizar e autogerenciar. Seria tudo uma questão de equilíbrio: “Auto-organização significa que, na medida do possível, a tomada de decisões é delegada para os times”. E explica: “Mesmo que líderes ágeis devam ser ‘light’ em termos de decisões ‘top-down’, eles devem ser ‘heavy’ na articulação de objetivos, facilitação de interações, melhoria da dinâmica da equipe, suporte a colaboração e incentivo da experimentação e inovação”.

    Não me parece uma coincidência o fato da lista acima guardar várias semelhanças com aquela apresentada no artigo anterior, que tratava das responsabilidades de um Dono do Produto em um projeto guiado pelo Scrum. Vale lembrar: o Scrum é uma metodologia que, em certo sentido, se propõe Leaderless. As responsabilidades sobre o gerenciamento são compartilhadas pelo ScrumMaster, Dono do Produto e Time.

    Acontece que, em vários trabalhos mais recentes (como “Product Management with Scrum”, de Roman Pichler – Addison-Wesley, 2010), a função do Dono do Produto está sendo apresentada de tal maneira que chega a ser estranho o fato dele não ser tratado como um Líder. De uma forma ou de outra, os autores são claros em um ponto: trata-se da função mais crítica e difícil em uma iniciativa guiada pelo Scrum.

    Por fim, gostaria de destacar algumas possibilidades apresentadas por Phillip “Shoes” Calçado no papo que tivemos sobre o último artigo: “Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos.”

    Queria apenas acrescentar que essa divisão entre gerenciamento de projetos e gerenciamento de iterações é totalmente compatível com o framework proposto por Jim Highsmith no livro citado acima. Aliás, “Agile Project Management – Second Edition” é uma compilação de práticas estruturada em torno de 3 das 4 “camadas” que formam o que Jim chama de “Agile Enterprise Framework”. As quatro “camadas” são: Governança do Portfolio, Gerenciamento de Projetos, Gerenciamento de Iterações e Práticas Técnicas. Apenas essa última camada, formada por práticas de engenharia, não está no escopo do livro.

    Como eu disse lá em cima, (ainda) não apresentarei conclusões. Na próxima parte da série falarei sobre “Fracassos”. Inté.

    .:.

    Observações

    A imagem utilizada, flikr0629, é de flikr e foi surrupiada no Flickr. Simples assim.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!

  • O Problema com Harry*

    Harry era um coordenador de projetos. Vivia para resolver problemas. O último foi insolúvel: Harry bateu as botas; foi dessa para uma melhor; tá mortinho da silva. Ninguém percebeu ainda. Ele está em seu cubículo, silencioso como quase sempre. Debruçado sobre o teclado, parece dormir. A tela do micro exibe o gráfico Gantt que ele atualizava quando morreu.

    Jenifer apareceu para confirmar a reunião das 10. Notou que algo estava errado só na quarta vez que chamou Harry, tocando seu ombro. Pela temperatura do pescoço sacou que o cara estava realmente morto. Lembrou-se imediatamente da rodinha que se formou em torno da máquina de café logo após a reunião do dia anterior. Sentiu um frio na espinha quando recordou a jura que fez para meia dúzia de testemunhas: “Ainda mato esse $%&”. Deixou o cubículo se certificando de que ninguém havia reparado sua presença ali.

    Jenifer é analista de negócios. Os 5 meses e 18 dias de convívio com Harry foram, segundo suas próprias palavras, “um inferno”. Se arrependeu de ter sugerido a adoção de um modelo iterativo e incremental para o desenvolvimento do projeto. “Melhor seria ter ficado aqui apenas um mês, escrito do jeito que desse todos os casos de uso e me mandado para outro projeto”. Harry lhe roubou a ideia e fez um curso de 8 horas de ScrumMaster. Voltou com o certificado e algumas conclusões: “A ideia do Scrum é muito boa. Só não curti muito esse papo de ScrumMaster, Product Owner e coisa e tal. Vamos adotá-lo, mas eu seguirei sendo GP. E tenho dito!”

    Harry fazia questão de participar de todas as reuniões com o cliente. Jenifer funcionava mais como sua secretária do que como analista de negócios.

    TheTroubleWithHarry

    Arnie é um dos três programadores plenos (pero no mucho) alocados no projeto. Com espinhas no rosto e bonequinhos japoneses em sua mesa, vivia irritado com Harry. Reclamava do “clima opressivo” do projeto. Não suportava mais as 4 horas extras diárias e as manhãs de sábado trabalhando, coisa que Harry chamava de “esforcinho extra”. Algo que ele compensaria, dependendo do sucesso do projeto, “com uma bela feijoada no Bar Brahma. Por minha conta!”, prometia o falecido.

    Arnie nunca manifestava suas opiniões para o coordenador – tremia de medo dele. Aos pares sempre acusava as sugestões “malucas” e o risível domínio técnico de Harry: “O cara sabe de Java tanto quanto eu manjo de culinária peruana”. As piadinhas de Arnie nunca mereciam uma risada espontânea, mas todos os programadores concordavam com suas críticas.

    Passou pelo cubículo do Harry para perguntar, pela terceira vez, se a data de encerramento da iteração realmente mudaria. Todo mundo achava aquilo uma loucura e Harry nunca era conclusivo. A verdade é que nenhuma iteração até aquele momento havia respeitado o plano original (que previa ciclos de 30 dias). Arnie tremeu muito quando percebeu que seu silencioso interlocutor estava mortinho. Agachou e elaborou 100 planos para escafeder-se sem ser notado. Saiu engatinhando e entrou no cubículo ao lado, da gata Jenifer, simulando a busca pela lente de contato que ele nunca usou. Nem notou as cruzadas pernas torneadas de tão nervoso que estava.

    Eis que chega o Capitão, bufando. É o gerente da área comercial e já avisou que não toleraria mais reclamações do cliente. Esperava desde a noite anterior por uma versão atualizada do arquivo do ‘project’. O cliente falou que não pagaria mais nenhuma parcela se não visse uma “evolução” do projeto. Harry e Capitão acordaram que o envio do ‘project’ talvez funcionasse como calmante. Não sem antes discutirem, por 3 horas e 17 minutos, sobre os problemas do projeto. Harry dizia que o cliente não sabia o que queria. E reclamava que sua equipe era muito “júnior”. Capitão, entre um tapa e um murro na mesa, lembrava que nunca vira, em 30 anos de carreira, um projeto de software sem problemas. No ápice do papo, lá pelas 8 da noite, gritou para quem quisesse ouvir: “Se esse projeto não der lucro eu te mato, safado!”

    Boa parte da remuneração do Capitão vinha de um naco do lucro de cada projeto comercializado. Ou seja, há tempos ele vivia com a corda no pescoço, contas penduradas e um salário mínimo. A empresa resolveu que comissões ‘normais’ estavam apenas contribuindo para o aumento do prejuízo dos projetos. E concluiu que a participação nos lucros incentivaria maior colaboração da área comercial nos projetos, “gerenciando relacionamentos. Afinal, esses técnicos são muito ruins de papo”. Capitão bufou, acatou e enviou o currículo atualizado para 47 empresas.

    Capitão gritou uma, duas, três vezes. “Não é possível que agora esse @#$ resolveu dormir aqui!”. Com um safanão fez a cadeira girar, o que mostrou meia face do pobre coitado e morto Harry. O olho esbugalhado dizia tudo.

    Jenifer e Arnie aproveitaram o escândalo para dar e livrar suas caras: “Capitão, você matou o Harry?” A pergunta saiu em uníssono e em volume suficiente para ser ouvida em todo o andar. Logo estavam todos ali, pescoços sobre as divisórias do cubículo, rostos de espanto e comentários inteligentes sem champanhe nem cicuta. “Jura? O Capitão matou o Harry?”

    Ninguém gostava do Harry. “Mas matar o cara! Meldels… onde vamos parar?” As meninas choravam um choro nervoso. Os rapazes, com seus modernos celulares, espalhavam a nova para toda a agenda de contatos. Ninguém sabia o que fazer. Capitão estava estático, catatônico, com cara de bobo. Jenifer e Arnie ainda o fitavam, acusadores e aliviados.

    O ramal do Harry tocou. Identificador de chamadas: “Amorzinho”. Todos que estavam próximos trocaram olhares, esperando que um herói tomasse a iniciativa de atender ao chamado. Ninguém teve coragem e depois do 13º toque o telefone silenciou. Para tocar de novo 30 segundos depois. Identificador de chamadas: “Esse cara não tem mãe”.

    “Xi… agora é o freguês”, disse alguém.

    Capitão atendeu, mandando bala: “Ô Xerife, você sabe que mora eu meu coração, não?”. Silêncio constrangedor de dois minutos e meio. Todos sacaram que o Xerife, o cliente, desfilava seu repertório de impropérios nos acostumados ouvidos do Capitão. Do nada, o gerente comercial resolveu mudar o rumo da conversa: “Querido, por favor, me diz uma coisa: você mandou matar o Harry? Porque, veja bem, se foi você, eu gostaria que você soubesse que todos aqui consideraram a decisão mais acertada para que finalmente a gente possa estar providenciando a otimização de nosso processo orientado ao…” tum, tum, tum…

    Epílogo

    Foi no velório que todos ficaram sabendo que Harry não foi assassinado. Sofreu uma parada cardíaca fulminante. “Também”, disse Jenifer, “o cara se alimentava mal e não fazia exercício nenhum! Não aguentava um lance de escadas”. Arnie lembrou que havia dois meses que Harry parou de fumar: “Não adiantou nada.” “Pudera, o cara tava mascando 60 chicletes de nicotina por dia!”, assuntou outro. Capitão consolava o Amorzinho dizendo que Harry era o melhor coordenador de projetos que ele conheceu em 30 anos de carreira. “Pena que não suportou a pressão”.

    E Harry não conseguiu o que queria quando veio para a “Top Down**”, com o diabo ter. Ele queria era falar pro Presidente pra montar um PMO e ajudar toda essa gente que só faz sofrer…

    .:.

    * O drama acima foi levemente inspirado num dos melhores filmes pouco conhecidos do Mestre Hitchcock, “The Trouble with Harry” (1955), que aqui em Pindorama é tratado como “O Terceiro Tiro”. As imagens utilizadas neste artigo foram indevidamente surrupiadas da Internet.

    ** A “Top Down” é uma software house de última geração fincada no meio do potencial vale do silício tupiniquim, leia-se Vale do Anhangabaú. Sediará outros dramas, com certeza. Infelizmente, sem nosso querido Harry.

    Atualização em 3/Fev/10: As três batidas na madeira, dadas abaixo, não adiantaram muito. Eu deveria ter verificado anteriormente a coincidência com nomes, principalmente com a empresa. É preciso dizer que a Top Down do artigo acima, agora definitivamente fechada, não tem nada a ver com a empresa homônima sediada no Rio de Janeiro. Foi uma infeliz coincidência mesmo. E pelo meu descuido peço desculpas. Agora vou ter que inventar um novo nome para as futuras aventuras da trupe desenvolvedora.

    Lembrete: salvo engano, ontem foi o Dia dos Gerentes de Projetos. Eu não ia homenagear-nos (ainda me considero um) com um artigo sobre as “maravilhas” da última versão do PMBoK, né? Fica para uma data mais propícia (ou menos perigosa).

    Aviso: a história acima é pura ficção e bobagem. Qualquer semelhança com fatos, empresas ou pessoas de verdade deve ser mera coincidência. (3 batidas na madeira)

  • Crise no Mundo Ágil. Que Crise?

    Sabe aquela sua colega que parece ser a única num raio de 500km que conhece e gosta de uma obscura banda de rock belga? Lembra-se como ela se revoltou e desgostou quando a banda assinou contrato com uma grande gravadora? É o mesmo caso daquele amigo que era fanzaço de um diretor de cinema chinês, mas desistiu da idolatria quando o cara resolveu fazer um filme em Hollywood: “O cara se vendeu”. Todos conhecemos gente assim, que gosta de coisas muito diferentes, distantes do universo pop(ular). Pessoas que se sentem traídas quando seus modelos ou ídolos tentam falar para um público maior, tentam atingir mais pessoas.

    Desconfio que algo muito parecido esteja acontecendo agora, naquele universo que surgiu após o big-bang do Manifesto Ágil. Dois excelentes artigos, de José Paulo Papo e Rodrigo Yoshima, ajudaram a alimentar minhas suspeitas. Além de um bate papo bem legal que rolou sobre a possível morte do RUP (Rational Unified Process) no grupo UML-BR.

    O Yoshima está certo: RUP e Agile compartilham hoje uma mesma tendência. Mas seria a de morrer? Márcio Tierno, o MT, fez um diagnóstico diferente ao falar especificamente sobre o estado atual do RUP:

    Acho que o RUP, pior do que estar morto, entrou para o mainstream. Hoje um cliente ou usa um processo waterfall ou usa um processo *pretensamente* baseado no RUP.

    E entrar para o mainstream significa ter sua evolução freada. Ninguém entendia direito o RUP. Poucos dos que o “adotaram” em suas empresas se deram ao trabalho de ler a última versão e entender. Os “metodologistas” das empresas sempre gostaram do RUP exclusivamente pelos artefatos, pela sensação de controle e pelo tamanho. Jamais pela iteratividade.

    Surrupiei do Google Trends alguns dados que de certa maneira confirmam as palavras do MT e solidificam minhas suspeitas. Veja os gráficos abaixo:

    Tendências para RUP, Agile e Scrum no mundo

    Tendências só no Brasil

    Azul = RUP | Vermelho = Agile | Laranja = Scrum

    O primeiro gráfico abrange o mundo todo. O segundo levou em consideração apenas as buscas e notícias realizadas no Brasil. O Google Trends faz exatamente isso: mostra a quantidade de buscas pelos termos. Não pode ser considerado ao pé da letra, afinal Scrum e Agile significam outras coisas para outras pessoas. O que não tira totalmente o valor do indicativo de tendências.

    E o que os gráficos nos mostram? Uma queda constante porém gradual no interesse pelo RUP e um crescimento vertiginoso nas buscas pelo termo “agile”, particularmente aqui no Brasil. Seria isso um indicativo de morte? Só para aqueles que, como os fãs de bandas e diretores obscuros, gostariam de permanecer num grupo pequeno e muito restrito.

    Eu entendo e compartilho o que acredito que sejam as principais preocupações do MT e do Yoshima. Ao se transformarem em artigos pop – ou “carne de vaca”, para usar um termo bem nosso – RUP e Agile saem do controle. Do nosso controle. E não serão poucos os que irão distorcer, desfigurar e desmontar os valores e princípios que caracterizam e definem essas propostas. Aliás, preciso confessar, eu sou um deles. Tanto que já fui criticado, aqui mesmo no finito, por chamar de “bullshitagenzinhas ágeis” algumas das práticas sugeridas. Falei de práticas, não de princípios e valores. Mas isso não importa. O que importa aqui é saber se é mesmo o caso de decretar a morte do RUP ou do Agile.

    Se o RUP é muito mal utilizado, e de fato é, boa parte da culpa é dos seus criadores e evangelistas. Já mostrei por aqui como o RUP foi uma verdadeira metamorfose ambulante desde o seu lançamento. Alteraram sem pudor seus princípios, causando confusão. O artigo do José Papo mostra que agora a versão 7.5 tem um “Agile Core”. Não estou dizendo que o RUP não deveria evoluir. Estou afirmando que a evolução foi mal conduzida (parece improviso) e muito mal comunicada. O que não isenta, claro, os cabeças de pamonha que fizeram dele uma cascata iluminada.

    O universo Agile pode e vai sofrer com problemas semelhantes. Cabeças de pamonha estão longe da extinção. Mas o caso aqui é diferente. Os valores e os princípios consolidados no Agile Manifesto permanecem os mesmos desde o dia 13 de fevereiro de 2001. E eles não sofrem com um dono nem com as pressões comerciais que este faria.

    Esqueçamos por alguns minutos os Pamonhas e suas cascatas e contratos a preço fechado. Cabe aqui uma autocrítica por todos aqueles que defendem o manifesto:

    • Será que estamos sendo didáticos o suficiente?
    • Não somos impacientes demais para explicar, por exemplo, por que uma iteração não é uma mini-cascata?
    • Será que, ao invés de explicar, não estamos detonando demais o “outro lado”. Vide meu termo acima: Pamonha!
    • Não estamos sendo religiosos e puristas demais?

    Meu maior temor é que os agilistas de hoje se comportem como os cascateiros de ontem. Não concordo com o MT quando ele diz que “mainstream significa evolução freada”. Oras, se no contexto de um projeto estimulamos (ou forçamos) a participação de todos, exatamente para gerar mais ideias e inovações, por que numa escala maior esta mesma prática seria nociva – por que ela geraria o efeito contrário?

    Se de fato nós acreditamos que RUP e Agile são as respostas para melhores projetos, não faz o menor sentido o medo de que essas propostas se transformem em suculentas “carnes de vaca”. Ou nós queremos seguir como os raros fãs de obras cult que ninguém conhece?

    .:.

    A foto utilizada neste artigo, “We Love Crisis”, é de Daquella Manera (Daniel Lobo), fotógrafo profissional que disponibiliza alguns de seus trabalhos como Domínio Público.

  • BABoK: Uma Leitura Crítica

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

    A Estrutura do BABoK

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

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

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

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

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

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

    Armadilhas

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

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

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

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

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

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

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

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

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

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

    Conclusão

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

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

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

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

    .:.

    Nota aberta ao IIBA

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

    .:.

    Serviço:

    Outras Notas:

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

  • Modelagem de Negócios: Os Diagramas

    Sequência obrigatória de “Modelagem de Negócios: Uma Sugestão“. Como prometido, apresento neste artigo um conjunto básico de diagramas que um analista pode desenvolver para entender um negócio. Opa… vale repetir o mantra: Modelamos um negócio para entendê-lo. Este é o principal objetivo da disciplina conhecida como modelagem de negócios. Assim como o principal alvo da engenharia de requisitos é a compreensão dos desejos, necessidades e restrições dos usuários.

    Portanto, por favor, utilize as sugestões abaixo com moderação. Traduzindo: não é para sair desenhando tudo quanto é diagrama sugerido aqui! Apresento uma variação do “Codex” de Dan Roam (autor de “The  Back of the Napkin”) exatamente para facilitar a escolha de determinado tipo de diagrama, dependendo do problema em questão. Como ainda se trata de uma versão beta, críticas e sugestões serão muito bem vindas. Desde já agradeço.

    O 'Codex' da Modelagem de Negócios
    O 'Codex' da Modelagem de Negócios

    O gráfico acima representa nosso ‘Codex’ – um guia que nos ajuda a definir o diagrama ou artefato mais indicado para o entendimento ou apresentação de determinado problema ou solução. O desenho é grande demais para o espaço aqui. Clique na imagem para ver uma versão ampliada. Podemos seguir?

    As linhas representam as 3 visões – do Negócio, da Estrutura e dos Processos – e suas respectivas perguntas. As colunas representam as 5 decisões SQVID. Lembrando: Simples ou Elaborado; Qualitativo ou Quantitativo; Visão ou Execução; Individual ou Conjunto; e Mudança (to-be) ou estado Atual (as-is). Nas células aparecem ícones que representam um tipo de diagrama ou artefato. Quando a célula estiver vazia é porque aquela pergunta, naquele seletor, não faz sentido.

    Abaixo, na sequência das visões, são apresentados todos os diagramas ou artefatos sugeridos.

    Visão do Negócio

    Aqui tentamos responder uma única questão: Por quê? Ou seja, quais são as motivações do negócio? Quais são os grandes requisitos do negócio? Afinal, quais necessidades do negócio esse projeto ou demanda deve satisfazer? Três ícones apareceram no desenho acima:

    0documentoO documento é a única representação não desenhada de todas as sugestões do ‘Codex’. É algo que foi antecipado por Eriksson e Penker em “Business Modeling with UML”. Algumas informações obtidas neste momento simplesmente não fazem sentido de outra forma que não seja texto puro. Mas, antes de abrir seu editor de textos, entenda que essas informações podem estar estruturadas em sofisticados formatos, como Mapas Estratégicos, Balanced Scorecards, matrizes SWOT etc. Podem representar também a declaração de Missão ou Visão da empresa. E ainda, num cenário mais pobrezinho, uma lista com os principais requisitos do negócio.

    0mapa_processosO mapa de processos (neste momento, um ‘modelão’ conceitual) pode ser uma alternativa ao texto puro – uma alternativa mais elaborada. Se estivermos lidando com milhares de palavras, então o desenho pode ser uma boa opção. Afinal, modelamos para simplificar – para facilitar o entendimento. Seu uso também é util para explicar a execução – o meio pelo qual a organização espera realizar a visão, seus objetivos. Como mostra o ‘codex’, este mapa pode ser utilizado tanto para ilustrar o ‘as-is’ como o ‘to-be’, ou seja, como a empresa se vê após a realização de seus objetivos.

    0grafico_simplesQuando lidando com  números, quantidades, não há representação melhor que um belo gráfico – de preferência de barras, que além de muito legível é mais fácil de ser desenhado à mão. Quando utilizado na elaboração da visão do negócio, este gráfico representa grandes números que explicam ou justificam os requisitos do negócio. Estamos falando de aumento de receitas? Ou de redução de custos? Sempre que requisitos assim são apresentados, um gráfico pode ajudar em sua visualização e divulgação.

    A construção da visão do negócio é uma tarefa que normalmente não dura mais que poucos dias ou até mesmo horas. O que não significa que ela não seja importante, pelo contrário. Muitos projetos falham porque, a partir de determinado momento, a equipe simplesmente esquece a principal razão pela qual aquele empreendimento foi iniciado. A visão do negócio representa os principais requisitos do negócio. Portanto, ela não é nada menos que fundamental. E todo projeto deveria começar por ela.

    Visão da Estrutura

    Por estrutura devemos entender todos os recursos que compõem uma organização ou se relacionam com ela de alguma maneira. Três questões devem ser colocadas para a elaboração da visão da estrutura:

    • Quem / O Quê? – para identificar partes interessadas (stakeholders) ou recursos envolvidos em determinada situação. Esses recursos podem ser produtos, serviços, máquinas, documentos etc. Ou seja, qualquer tipo de recurso físico, abstrato ou de informação.
    • Quanto? – para entender e tratar todas as informações numéricas: volume de vendas, número de colaboradores, salários, giro de estoques, quantidade de clientes etc etc. Enfim, separamos com essa questão todos os dados quantitativos sobre os recursos elencados na pergunta anterior.
    • Onde? – agora uma questão para localização, para posicionamento dos recursos na organização ou em seu macro-ambiente (nicho, mercado ou cadeia de valor).

    São 4 os diagramas principais usados para elaboração da visão da estrutura:

    0classes_simplesO diagrama de classes é quase onipresente nesta visão. Não é uma questão de falta de opções, mas sim de uma grande versatilidade desta ferramenta. No entendimento das questões de identificação (quem / o quê), o diagrama de classes pode ser utilizado para representar organogramas ou a composição de produtos ou serviços, por exemplo. Na pergunta que trata de localização (onde), este diagrama pode representar departamentos, seções, filiais, franqueados etc. No ‘codex’ aparece também uma outra versão deste diagrama, simplesmente para indicar a possibilidade de confecção de desenhos mais elaborados e extensos.

    0estadoQuando é necessário analisar um recurso específico o diagrama de estado pode ser de grande utilidade. Os estágios no ciclo de vida de um contrato ou uma apólice, o status de uma ordem de compra, os estados de determinado equipamento etc. No livro “Business Modeling with UML”, este diagrama é usado na construção da visão do comportamento, opção que não está contemplada nesta sugestão. Independente do nome ou perspectiva, o importante é saber que podemos contar com esta ferramenta sempre que um recurso relativamente complexo exigir um estudo e representação mais detalhados.

    0grafico_elabPois é, como já foi citado na visão anterior, não existe representação visual melhor do que um gráfico (de barras, preferencialmente) para as respostas da questão “quanto”. Repare no ‘codex’ que este é o único artefato gerado em todas as variações oferecidas no seletor. Mas é importante colocar que algumas organizações podem apresentar essas respostas em outros formatos. Um balanced scorecard, por exemplo, obrigatoriamente apresenta metas quantitativas para todos os indicadores apontados. O bom analista evita redundâncias.

    0fluxo_swinlanesO artigo anterior chamou a atenção para o fato de alguns diagramas ultrapassarem os limites de uma visão. Eis aqui um diagrama de atividades (ou fluxograma), natural da visão dos processos. Aqui, na visão da estrutura, ele aparece em uma única célula: quando precisamos ver a execução (2ª opção da terceira coluna do ‘codex’) em resposta para a pergunta “onde?”. Colocando de outra maneira, este diagrama pode ser utilizado para explicar onde determinadas atividades ocorrem ou devem ocorrer.

    A visão da estrutura é sumariamente ignorada no padrão de modelagem da moda, a BPMN. Claro, não é uma culpa da notação. O problema é que muitos profissionais ainda misturam e chacoalham bolas, acreditando ser possível a utilização da BPMN para a modelagem (o *entendimento*) de negócios. Não é.

    Visão dos Processos

    Finalmente, a visão que trata da parte dinâmica de uma organização. Todas as tarefas, atividades e processos executados por uma empresa são capturados e analisados através dos artefatos que compõem esta visão. Duas perguntas nos levam até eles:

    • Quando? – nos ajuda a  posicionar ações em uma linha de tempo. Quando tal problema ocorre? Quando aquele evento deve ser disparado? Qual é o deadline daquela tarefa? E assim por diante.
    • Como? – por fim, a última e mais complicada questão. Como tal atividade acontece? Como aquele processo deve ser executado? É a questão que guia o mapeamento e modelagem de processos e atividades de negócio.

    Não por acaso, é nesta visão que temos um conjunto maior de diagramas. São 8 tipos principais, listados abaixo:

    0processo_seqMapas de processos nos ajudam a responder tanto o “quando” quanto o “como”. Geralmente formam o melhor ponto de partida para o desenho das respostas para as duas perguntas desta visão. São particularmente úteis quando os envolvidos não têm um entendimento comum sobre os processos envolvidos em determinado problema. Todos os outros artefatos gerados na construção desta visão, de certa forma, derivam deste.

    0processoO mapa, apresentado acima, é na realidade um conjunto de diagramas de processos. Para desenhá-los deveríamos seguir um pattern sugerido em “Business Modeling with UML”. Um padrão que vem de outra notação, a IDEF0. É simples: à esquerda do processo ficam as entradas; na direita as saídas; abaixo, todos os recursos utilizados na produção das saídas; e acima os recursos usados no controle do processo. Este diagrama, que à primeira vista parece simplista e desnecessário, pode dar origem a artefatos mais avançados, como mapas de avaliação (nome tropicalizado para “System Maps”, apresentado por Ralph Smith em “Business Process Management and the Balanced Scorecard”). Outro artefato derivado deste é o diagrama de linha de montagem, que veremos posteriormente.

    0fluxo_cronogramaAnalistas de O&M (eles ainda existem?) vão se lembrar da figurinha ao lado. É o velho ‘fluxo-cronograma’. Trata-se do diagrama de atividades da UML acrescido de informações sobre tempo, apontadas em swinlanes ou de alguma outra maneira – isso não importa muito. Uma alternativa é o uso do diagrama de Timing (linha de tempo), que foi introduzido na UML 2. Mas o uso de uma variação do diagrama de atividades deve fazer mais sentido na maioria das vezes, já que o analista reutilizaria um diagrama já elaborado, adicionando apenas informações sobre a duração de atividades e tarefas.

    0fluxo_swinlanesAliás, a base para o diagrama sugerido acima é esse aqui, o diagrama de atividades (ou fluxograma, como queiram). Quando detalhamos um processo, este é o formato. Podemos nos limitar a um nível mais alto – as atividades, ou descer ao menor nível de detalhamento possível – as tarefas. A ferramenta pode ser sexagenária ou centenária. Se dura tanto é porque ninguém inventou nada melhor, certo? Como eu disse em um artigo anterior, a BPMN nada mais é do que uma revisão (3.0?) deste velho conceito. Aliás, quando no domínio da solução (to be) e tendo como base algum produto BPMS, o analista pode substituir este diagrama por modelos BPMN. Aliás, deve. Mas, em todos os outros casos, particularmente quando ainda estiver *entendendo o negócio*, ele deveria evitar a BPMN. E utilizar UML.

    0sequenciaUma alternativa ao diagrama de atividades é o diagrama de sequência. Atenção: é uma alternativa. O analista desenvolve um ou outro para estudar ou representar determinado processo ou atividade. Quando interações entre as partes envolvidas e uma noção de duração das atividades forem muito importantes, então o diagrama de sequência pode ser mais útil que o de atividades. Quando o analista tiver à sua disposição uma ferramenta CASE, ele ganhará um diagrama quando desenvolver o de sequência – o diagrama de comunicação é gerado automaticamente. E pode ser útil na análise das interações entre as partes interessadas – para identificar gargalos, por exemplo.

    0assembly_lineO diagrama de linha de montagem é uma variação do diagrama de processo. Serve para análise específica de recursos que apoiam a execução de um processo (como vimos, esses recursos são desenhados abaixo do processo). É especialmente útil quando esses recursos, representados por linhas de montagem (pacotes da UML), são sistemas de informação. O diagrama ilustra todos os dados lidos e gravados em sistemas, demonstrando como eles viabilizam (ou impactam) um processo de negócio.

    Repare que o artefato acima é o primeiro que trata especificamente de sistemas. Todos os outros apresentados até aqui são utilizados exclusivamente para o entendimento ou demonstração do negócio e seus diversos aspectos. Vale ressaltar que o diagrama de linha de montagem é particularmente útil quando ainda estamos no domínio do problema. Tanto que ele é apresentado como uma alternativa para responder o “como” é hoje (as-is, última coluna do ‘codex’).

    Mas, quando o analista começa a entrar no domínio da solução – capturando requisitos das diversas partes interessadas – quais artefatos ele pode gerar? Abaixo são apresentados dois diagramas que aparecem apenas na coluna D (to be) do ‘codex’:

    0PucsO diagrama PUCS (Process Use-Case Support) é mais um belo exemplo de toda a versatilidade da UML. Ele é a combinação de dois diagramas, de atividades e de casos de uso. O diagrama de atividades, descrito acima, é a base para a elaboração de um PUCS. O analista pode utilizá-lo para iniciar e facilitar os trabalhos de identificação de casos de uso, ou seja, de descoberta e descrição de requisitos funcionais. No PUCS indicamos explicitamente quais atividades ou tarefas do negócio serão suportadas (incrementadas ou impactadas) por determinados casos de uso. Nenhuma imagem representa melhor o ato de ‘embarcar’ sistemas em um processo de negócio.

    0use_caseChegamos então ao último artefato de nossa listinha, o mal falado e mal entendido diagrama de casos de uso. Ele pode ser extraído de um PUCS ou ser desenhado do zero, dependendo das necessidades de entendimento do analista. Suspeito que muitos não concordem, mas desconheço outra representação gráfica que ilustre tão bem todo o escopo funcional de um projeto. Além do pouco tempo gasto em sua elaboração, outra vantagem desse tipo de diagrama é sua legibilidade.

    Deve ter ficado claro pela listinha acima que a elaboração da visão dos processos é a mais complicada – aquela que exigirá mais do analista. O mais perigoso engano que deve ser evitado a todo custo é o desenvolvimento deste estudo numa tacada só, como se fosse uma fase de um projeto. Devemos brigar pelo pleno uso de um processo que seja iterativo e incremental. Com exceção da visão do negócio, desenvolvida na primeira iteração, todas as outras são maturadas e desenvolvidas durante todo o projeto. Mas isso já é assunto para outra hora, né?

    E as Regras de Negócio, onde ficam?

    Como citei no artigo que deu origem a esta série, “Modelagem de Negócios: A Encruzilhada“, David Bridgeland e Ron Zahavi defendem em seu livro, “Business Modeling – A Practical Guide to Realizing Business Value”, que as regras de negócio tenham sua própria disciplina. Até aí, tudo bem. O problema começa quando tentamos buscar algum tipo de representação que seja específico para as regras. Cria-se muita confusão desta maneira. Devemos nos lembrar que a motivação para a modelagem é a simplificação.

    Regras de negócio podem aparecer, definindo ou restringindo, em qualquer outro elemento básico de um negócio (leia-se: objetivos, recursos e processos). Portanto, parece ser um grave engano a definição de um padrão de apresentação específico para regras. Seu repositório natural deveria ser aquele artefato que estava sendo elaborado quando a regra surgiu. Ou, dependendo do caso, um anexo deste artefato. Por exemplo: a regra apareceu quando desenhávamos um diagrama de atividades. Por que não registrá-la ali mesmo, na forma de uma nota? (a UML tem o recurso ‘nota’ para a colocação de comentários em diagramas. As notas podem inclusive ser ‘ancoradas’ em elementos específicos de um diagrama. E são utilizadas em qualquer tipo de diagrama).

    Claro, existem regras muito complexas – extensas pra chuchu. Uma fórmula de cálculo de seguro, por exemplo. Não faz nenhum sentido que uma fórmula de trocentas páginas seja comprimida em um diagrama, certo? Custa grampear a fórmula no diagrama, indicando com um código bobo o local onde ela se aplica? O tema é importante demais para ficar só aqui, no rodapé deste artigo. Voltarei ao tema.

    .:.

    Agora, para encerrar este longo artigo, apenas um breve comentário sobre a disciplina em questão, a Modelagem de Negócios. O que antes era uma suspeita caminha agora para a certeza absoluta: quase ninguém pratica a modelagem de negócios. E, se depender de iniciativas recentes como o BABoK, a situação pode piorar bastante. Por que isso é um problema? Porque o entendimento do negócio é fundamental para o sucesso de um projeto. E ainda não inventaram disciplina mais eficaz que a modelagem de negócios para a obtenção desse entendimento.

    Mas sou teimoso e um incurável otimista. Livros publicados recentemente, particularmente “The Back of the Napkin” (Dan Roam. Portfolio, 2008) e “Business Modeling – A Practical Guide to Realizing Business Value” (David M. Bridgeland e Ron Zahavi. Morgan Kaufmann, 2009) provam que a displina pode ganhar um novo impulso. Eu espero que minhas contribuições mereçam 2 centavos. E um pouquinho de sua atenção. Inté!

    .:.

    Nota:

    • Mais uma imagem surrupiada de Kelbv, agora a flikr0679. É aquela enigmática e colorida figura do topo do artigo. Tudo a ver com modelagem, certo?