Blog

  • Rendiconti: FAN 2 x 0

    Título estranho, não? Faltou inspiração e tempo para encontrá-la. Será que a esqueci em Sampa? Pode ser. Fazia tempo que eu não ficava 5 dias consecutivos na Terra da Garoa. E isso bagunça um tanto meu humor, metabolismo e, pelo visto, inspiração. Peguei 30° quando cheguei por lá. Quando saí, na manhã do último domingo, tava fazendo uns 12°, se muito. Mas não, nada de gripe (nem terremoto) desta vez. Só uma pressa, uma certa ansiedade que, tenho certeza, importei de lá. Mas vamos ao que interessa.

    Na quarta-feira, dia 28, estive no SENAC (campus Santo Amaro). Atendia um convite do Leandro Abreu e da professora Maria Inês. Convite motivado por uma oferta minha que segue valendo: para escolas e afins, públicas ou privadas, levo meus eventos sem custos*. E lá fui, com um note que se recusou a falar com o projetor deles e 147 slides (!) de uma versão light (!!) do FAN – Formação de Analistas de Negócios. Light porque eu só tinha 3 horas de prazo. Claro, o tamanho da versão que levei estava pra lá de exagerada. Mas funcionou.

    Não cansarei de dizer: gosto do contato com a estudantada. A troca é bem diferente daquela que experimento em eventos abertos. Também foi bastante diferente das experiências nas Universidades do interior. Estudantada de Capital é um pouco mais ‘calejada’. Infelizmente, um pouco mais cansada também. Mas acho que consegui dar meu recado. A maioria dos participantes era de uma turma de Sistemas de Informação, caminho mais natural para a Análise de Negócios. Como sempre, fiquei devendo um retorno. Queria a oportunidade de executar uma oficina completa – de colocar o pessoal para trabalhar. Queria contrastar minhas sugestões de métodos e práticas com aquela não-experiência, aquela quase total ausência de vícios.

    FAN no Sabadão

    Pois é, finalmente o FAN aconteceu num sábado (31/mai). Realmente tem muita gente que não pode ‘largar o osso’ do trampo durante a semana. E tem disposição para encarar um evento que dura o sábado todo! E põe gente nisso: a sala ficou lotada, mais de 60 participantes!

    Comecei o evento comentando um terrível engano: que minha intenção era “matar” aquele evento, o formato FAN “palestrão”. Tanto que era a primeira turma dele em 2008. Daí o placar do título: eu perdi. O FAN “teórico” é um bom produto, que não ‘canibaliza’ as duas oficinas (práticas), Modelagem de Negócios e Engenharia de Requisitos. Eu devo redesenhá-lo, pelas bordas, buscando atender melhor os gerentes e coordenadores de projetos, gerentes de TI e afins. Mas o formato, definitivamente, deve permanecer vivo. E, de preferência, atraindo uma turma tão ‘combativa’ quanto aquela de sábado.

    Combativa? Pois é, não achei adjetivo melhor. Foi uma turma que teve a mesma dinâmica, a mesma interação que uma turma de oficina. Não apenas para concordar ou ilustrar determinados aspectos, mas principalmente para questionar e explorar melhor diversos temas. O André, da Tempo Real Eventos, participou por cerca de uma hora. Depois, por email, fez o mesmo comentário: que a turma havia me colocado em diversas “frias”. E o melhor: eles não se satisfaziam facilmente. Alguns assuntos, como o fatídico “joga o caso de uso no lixo”, foram e voltaram várias vezes. Fantástico!

    Eu sempre entrego que trabalho com um buffer (pulmão) de 1 hora. E digo que, se o evento for ruim (sem nenhuma interação), ele termina lá pelas 17 horas. Pois bem, só encerrei a parte formal do evento lá pelas 18h10. E as conversas prosseguiram por mais meia hora, no mínimo. Em pleno sábado frio e feio numa Paulista estranha e movimentada. Ah, a apresentação estava com 194 slides, um recorde pessoal. Na noite de sexta eram 200. Na última revisão, louco por uma simplificação, consegui cortar 6…

    Deveria ter cortado um dedo também. Explico: lá pelas tantas, 5 e meia da tarde, resolvi fazer uma contagem nos dedos. Acho que falava de definição do escopo. Deveria ilustrar o 1 (opcional), 2 (importante), 3 (fundamental). Desastrado como nunca, na hora do 1, deixei só o dedo médio levantado – como aquele zagueiro do Botafogo – na frente da turma. Acho que demorou uns 10 segundos para eu perceber. Mas a turma, educadíssima, só caiu na risada quando eu recolhi o dedo, morrendo de vergonha. Assim terminou, como havia começado. Num clima legal, com a turma dando risadas e participando. Em pleno sabadão! Não havia melhor forma de comemorar 1 ano de FAN, né?

    Mas as comemorações não se encerraram ali. Só começaram. Novas em breve. Inté!

  • Analistas de Negócio Valem Ouro

    Quem diz é a CIO Magazine: Analistas de Negócios valem Ouro. O artigo, que comenta uma pesquisa da Forrester, foi publicado lá fora no dia 16/abr e mereceu outro título: “Why Business Analysts Are So Important for IT and CIOs“. Why? Uai…

    Por duas décadas, o CIO foi visto como o elo central entre as funções de negócio e tecnologia. Embora esta talvez seja a percepção exata da sala da diretoria, nos bastidores os analistas de negócio são os encarregados de fazer essa ligação ao elaborar os business cases para desenvolvimento de projetos de TI, suavizando as relações entre concorrentes e impulsionando projetos.

    Nos “bastidores”? O Analista de Negócios (AN) atua “nos bastidores”? Parece que ele faz coisas “por baixo dos panos”, não? Quanta infelicidade. A Madame Katyusha (prima da Natasha do Gaspari) acha que a nobre publicação pretendia dizer o seguinte: “é o AN que põe a mão na massa!” E, creiam, os tais “business cases” não têm, por si só, o poder de fazer a tal ligação entre TI e o negócio. Muito menos de “impulsionar projetos”. E “suavizar relações”? “Entre concorrentes”?… sem comentários.

    Nossa área, pelo visto, nunca perderá a mania de criar Super-Heróis que resolvem todos os problemas. Há pouco eram os Coordenadores de Projetos. Como a coisa não andou como prometido, agora elegem AN’s como a bola da vez. Apesar de um certo gelo na barriga, acho que a turma já está vacinada. E não cairá nessa reciclada armadilha.

    AN’s são importantes, mas não mais ou menos que qualquer outro integrante de uma equipe de TI. Se eles valem ouro, então todos valem. Perdão turma, mas não se trata de demagogia, ok? Apenas um lembrete que, vez por outra, se faz necessário.

    O AN ganha importância (e espaço na prensa “especializada”) porque sua área de conhecimento foi paulatinamente reduzida e negligenciada nas últimas duas décadas: o Domínio do Problema. A academia e as empresas passaram a valorizar o domínio da solução: e foi uma enxurrada de “analistas-programadores”, de anúncios pedindo “analistas de sistemas com 10 anos de experiência programando em C# e Java” e assim por diante. Agora estamos aprendendo que, sem um correto domínio do problema, não há solução que vingue. Entram os AN’s!

    Mas quem são os AN’s? O artigo fala que eles valem ouro e, no parágrafo seguinte, confessa:

    Todo mundo concorda com a importância do papel do analista de negócio, porém pouca gente sabe exatamente o que faz um profissional como esse.

    Não é hilário? Não é uma coisa bem típica da nossa área? Engraçado é que a mesma publicação, há quase 1 ano, já falava que o AN era uma “hot commodity” e apresentava, com relativa felicidade, o seu job description. Felicidade que sumiu no segundo parágrafo do artigo atual: “a maioria dos analistas de negócio bem-sucedidos mescla o temperamento e a habilidade de comunicação de um diplomata com o talento analítico de um oficial do serviço secreto.” Céus, pra que dourar tanto a pílula? Madame Katyusha sugere: “O AN é bom no entendimento de problemas e na percepção de oportunidades.” Para tanto, é claro que o cara deve ser um excelente comunicador. Mas esta não é a única ‘soft skill’ que ele deve desenvolver / apresentar.

    Encerro o azedume com minha maior preocupação: sei lá porque cargas d’água, insistem em Analistas Orientados ao Negócio e Analistas Orientados para TI. Na publicação original ficou um tanto pior. Falaram em “Business-Oriented Business Analyst”… já pensou se vira sigla? BOBA! Céus! 10x Céus!! Quem nada entende tudo complica, né? Analista de Negócio é Analista de Negócio. Ponto! Se ele é subordinado ao CIO ou qualquer outra área é outro papo. Mas o nome é o mesmo! Deveria ser… o artigo fala que o pessoal da Forrester achou uma solução: Analista de Tecnologia do Negócio! Céus!!! 1000x Céus!! Detalhe: este é o nome adotado por um grande banco tupiniquim para o departamento de AN’s: DTN: Depto de Tecnologia do Negócio. Então… corre o risco de vingar. Céus…

    Mas não importa. O que importa é que finalmente os AN’s estão ganhando um certo espaço, a devida atenção. Deixemos o “ouro” para nossos compatriotas que irão para Pequim e vamos falar sério sobre a função-profissão.

    Quer saber quem é o AN, onde ele mora, qual a sua formação, habilidades e responsabilidades? Quer saber porque ele pode ajudar na concepção e entrega de projetos? Quais matérias ele deve dominar? Os motivos pelos quais ele se tornou tão importante? Segue o convite:

    No dia 31 de maio, sábado, apresento uma edição especial do evento “Formação de Analistas de Negócios“. Será em Sampa, na Av Paulista. Programação, localização, inscrição e demais informações você encontra no site da Tempo Real Eventos.

  • Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]

    Seqüência obrigatória do último post. A motivação é a seguinte afirmação: “Os passos em um Caso de Uso são Requisitos Funcionais“. A questão parece simples mas esconde alguns “probleminhas”. Minha intenção aqui, além de justificar minha afirmação, é debater os tais “probleminhas”.

    Núcleo da Base de Conhecimentos do ANVariações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.

    Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.

    A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.

    Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.

    Resumo de Tyner BlainAs variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.

    No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):

    1. Coloca uma moeda
    2. Seleciona o tipo de bebida
    3. Retira o copo

    O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?

    Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.

    Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.

    Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: It’s not what the software does. It’s what the user does.Deveria virar um poster-lembrete na sala-mesa de todo AN.

    Atualização:

    Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!

    Bibliografia:

    1. Writing Effective Use Cases
      Alistair Cockburn. Addison-Wesley (2001).
    2. Software Requirements
      Karl E. Wiegers. Microsoft Press (1999).
    3. More About Software Requirements
      Karl E. Wiegers. Microsoft Press (2006).
    4. Use Case Modeling
      Kurt Bittner e Ian Spence. Addison-Wesley (2003).
  • Rendiconti: O Seminário GP e o Caso Criado

    Nem divulguei direito por aqui, mas no último sábado participei do Seminário sobre “Gestão de Projetos de Software” promovido pela Tempo Real Eventos. Foi a segunda edição e contou com os mesmos palestrantes do ano passado: Adail Retamal, José Paulo Papo, Juan Bernabó e este que por aqui rabisca. Contou também com a participação especial de Eduardo Coppo. Pleno sabadão, evento de um dia inteiro, e teve 250 participantes! O tema realmente é quente. Pena que não tive a oportunidade de assistir as apresentações. Mas o breve papo com os colegas e participantes valeu o ingresso.

    Juan e a massaMinha palestra foi a segunda, logo depois do Adail. Baita responsabilidade mas, por outro lado, peguei a platéia devidamente aquecida por TOC, Corrente Crítica e as boas sugestões do Adail. Aliás, antes que eu mergulhe nos meus assuntos, vale dizer que o evento é muito rico exatamente pela diversidade de temas e visões. O Papo apresentou o OpenUP e o Juan (como um maestro na foto ao lado), falou sobre Scrum.

    Eu não hesitei nada quando, há mais de um mês, decidi que meu tema seria “Engenharia de Requisitos”. Só coloquei uma tagline na apresentação da palestra: “Uma Visão Prática”. Depois de algumas oficinas, eu sabia que deveria colocar o assunto para um público um pouco diferente: os Coordenadores e Gerentes de Projetos. Tinha umas 3 “provocações” para apresentar… e, como esperado, criei caso.

    Antes preciso falar que a execução consecutiva de oficinas (com 7 horas de duração) está me deixando “destreinado” em palestras. O ritmo é totalmente diferente. As interações, na palestra, só ocorrem no finalzinho, no tradicional momento “Q & A”. Mas errei feio: minha palestra deveria terminar às 12h20. Levei um susto quando olhei o relógio e vi que ainda restavam uns 30′ e eu só tinha mais uns 4 slides… de um total de 64! Falei mais rápido do que o normal. Isso sem contar que alguns slides-piadinhas-de-gosto-duvidoso não ficam 10″ no telão (e que telão tem o auditório da FIAP, imenso!). Mas, para minha satisfação, o momento “Q & A” durou quase meia hora. Satisfação dupla: preenchi o “buraco” de tempo e, claro, confirmei que as provocações surtiram efeito.

    Coffee BreakProvocações: i) Caso de Uso não é documentação; ii) Matriz de rastreabilidade não é solução; e iii) Engenharia de Requisitos não significa burocracia e falta de agilidade. Foram as 3 explícitas. A que mais gerou debate, claro, foi a primeira. Principalmente quando eu disse que não consigo entender quando alguém me explica que “levanta os requisitos e depois escreve os casos de uso”. Melhor, o bicho pegou mesmo quando eu falei que jogo os casos de uso no lixo tão logo eles tenham cumprido sua nobre utilidade: ajudar equipe e usuários e clientes a *aprender* os requisitos. Até de “agilista” eu fui chamado, vejam só! hehe.. “Você está dizendo que só o código basta como documentação de um sistema?” Claro que não foi o que eu disse.

    Caso de Uso é uma ferramenta fantástica. Sem enrolação, e quando bem desenvolvida, ensina o QUE precisa ser feito; tendo o usuário como ponto de partida. Permite que a gente extraia e estude uma parte específica (tarefa ou atividade) de um processo de negócio sem desmontá-lo e sem a necessidade de novos termos ou metáforas. Repito: Caso de Uso é uma ferramenta fantástica. Mas… como documentação de um sistema? Totalmente dispensável. Não sei se convenci alguém, mas o Sr. Xavier disse ter gostado da “forma como defendo meus argumentos”, ou algo parecido. Um problema-polêmica bem maior viria na sequência, numa provocação até então implícita. Uma questão que me me incomodou em todas as oficinas sobre o tema: Os passos de um Caso de Uso são Requisitos Funcionais!

    Incomoda porque é sempre uma surpresa para muita gente. Incomoda mais porque, como escrevi acima, não está escrito em “lugar nenhum”. Será uma bela “varada n’água”, um terrível engano deste que aqui rascunha? Tentarei responder no próximo post. Inté!


    Está aqui a versão completa da apresentação (PPT – 3mb). Completa: Inclui as fotos de Varginha!!

  • Aprendizado Interprojetos

    Quinze meses mergulhado em um mesmo assunto, mesmo que ele seja amplo e saboroso, cansa. Aproveitei o feriado e meu 3º aniversário para “oxigenar” o cérebro. Trouxe de Sampa, na semana passada, a última edição da MundoPM. Não curto muito a (cara) revista, mas uma chamada de capa me pegou: “Gestão do Conhecimento Interprojetos: como evitar custos imensos de reinvenção e oportunidade a cada projeto“. Caramba… há 4 anos eu não via nada sobre o tema. Este foi o assunto do primeiro trabalho que publiquei aqui no finito, resultado de um estudo que fiz entre 2003 e 2004 (compilado neste PDF de 240kb e 21 páginas – versão revista hoje!).

    O artigo publicado na MundoPM é de Naomi Brookes, diretora do centro de práticas de gerenciamento de projetos da Aston University (UK), e Michel Leseure, professor de gerenciamento de operações na Escola Comercial de Negócios de Plymouth. Desnecessário dizer, são de um universo totalmente diferente do meu. Mas, caramba, como dois trabalhos sobre um mesmíssimo (e específico) assunto podem ser tão diferentes? Até na bibliografia não há uma única referência em comum! O único texto que conheço na lista deles é “The Knowledge Creating Company”, clássico de Takeuchi e Nonaka que não cito em minhas referências.

    O trabalho da dupla compila os resultados de uma pesquisa que fizeram com 14 empresas européias, dos mais diversos ramos. Sua conclusão não difere muito da minha:

    Os estudos de caso mostraram deficiência nos processos formais de gestão do conhecimento explícito para transferir conhecimentos de um projeto para outro.

    Isto ilustra uma falta de consciência sobre o conceito de gestão do conhecimento nas empresas deste nível.

    Mas uma palavrinha da citação acima resume toda a diferença entre o trabalho deles e o meu: “explícito” (conhecimento). Para eles, “conhecimento tácito é difícil de transferir”. E concentram boa parte de seu trabalho na indicação de mecanismos que promoveriam ou facilitariam o aprendizado interprojetos, dentre eles intranets, bancos de dados e bancos de dados de intranets… (não brinquei – está na figura 2 daquele artigo).

    Todo o meu trabalho gira em torno de eventos de socialização, ou seja, na troca de conhecimentos tácitos. Sugiro o uso de dois mecanismos, as “Comunidades de Prática” e as “Histórias de Aprendizado”. Não acredito que intranets e bases de dados promovam aprendizado de verdade. Mas entendo que eles têm sua utilidade em uma empresa que leve a sério o papo sobre gestão do conhecimento. Se bem construídos, são excelentes “guias de referência rápida”.

    Assim como o artigo de Naomi e Michel, que guardarei com carinho. Não só pela sua qualidade, mas também porque me permitiu ressuscitar um assunto há muito ignorado por aqui.

  • Rendiconti: A Morte do Patinho Feio, a Gripe Terremoto e outras novas

    Várias novas. Tanto que precisarei d’outro post para apresentá-las por inteiro. Mas antes, nossa tradicional prestação de contas. Aconteceu na última quinta (24/abr), a 2ª turma da oficina “Análise e Modelagem de Negócios” em Sampa. É o meu “patinho feio”. Explico: ao contrário de sua co-irmã, a oficina “Engenharia de Requisitos”, esta não está sexy o suficiente – não é atraente. Tanto que o público foi “só” 1/3 da média apresentada pelo outra. Sigo sem entender (“elas são indissociáveis!”, é meu choro frequente), mas não insistirei no modelo. Teimosia tem limite. Senão vira burrice, hehe. Mas falarei sobre as mudanças depois.

    Turma pequena é turma privilegiada. Posso atender todo mundo de uma forma mais frequente e pessoal. As interações tendem a ser um pouco mais ricas. E que sorte tivemos neste último evento! Experiências com Aris; AN’s (Analistas de Negócios) de uma grande empresa que utiliza XP (eXtreme Programming) como seu principal processo de desenvolvimento (!); um “Dino Coboleiro” (em suas próprias palavras); e, pela segunda vez, uma profissional de marketing interessadíssima na matéria; quatro participantes já haviam participado da outra oficina, o que também enriquece o evento – dois são professores (!); três pessoas foram de Curitiba exclusivamente para o evento; empresas importadoras e pequenas e médias empresas que desenvolvem sistemas. Ou seja, a turma era pequena mas eclética, variada, rica. O evento ganha muito com a diversidade – podemos conversar sobre vários modelos de negócios, estratégias, processos, problemas e oportunidades. Tanto que eu não via a hora de publicar esta “rendiconti”. Tanto que nem esperei pelas fotos. Quando elas aparecerem, publico aqui.

    Pelo resumo das avaliações que recebi, posso concluir que todos gostaram muito do evento. Mesmo assim, recebi 3 belos “puxões de orelha”. Vou aproveitar este espaço para comentá-los e, quando for o caso, rebatê-los.

    Aris

    O Aris vem no SAP R/3; é uma “linguagem” madura; “todo mundo usa”; “o usuário não precisa de treinamento para entendê-la”; “você não pode ignorá-la”. Pois bem, é a primeira vez que alguém me cobra isso. O que, definitivamente, torna o “todo mundo usa” um exagero. Quando iniciei este trabalho, há mais de um ano, naveguei brevemente pelo “mundo Aris”. O ignorei por completo por um simples motivo: meu trabalho simplesmente não cita nada que não seja um padrão aberto. Mesmo que a tentação (e as justificativas acima) sejam muito fortes, não cometerei o pecado de amarrar os conceitos e práticas que apresento em uma tecnologia ou ferramenta proprietária. Seria um suicídio. No mais, trata-se apenas de outra linguagem, assim como BPMN e a EPBE (UML) que apresento. Assim como eu falo sobre UML, deve ser fácil aprendê-la em um treinamento de 4 horas, mais ou menos.

    UML (e a extensão EPBE) seguirão no núcleo de meu trabalho sobre análise e modelagem de negócios. Mas vou considerar seriamente a inserção de um capítulo sobre outras notações. Mais que isso, deixarei em aberto a possibilidade de uma versão deste evento que utilize o Aris ao invés de EPBE. Mais sobre as extensões do programa FAN (Formação de Analistas de Negócios) abaixo e em futuros artigos.

    Inovação

    Veio do mesmo (simpático) crítico que sugeriu Aris: “esperava algo novo”. Ele falava especificamente da parte onde mostro a elaboração de um balanced scorecard (BSC) em EPBE. Juro, sigo achando que isso é novo! E me esqueci de perguntar se isso seria possível em Aris. Agora, se ele esperava uma alternativa ao BSC, acho que seguirei devendo por um bom tempo. Não vi surgir nada – com exceção do irmão do BSC, o Mapa Estratégico – que represente melhor a estratégia de uma empresa. Sério – não vejo nada no horizonte. Posso estar enganado. Mas, como não foi colocado nada no lugar, seguirei com minhas sugestões.

    XisPê

    A dupla (de AN’s) de uma grande empresa nos mostrou como eles trabalham com XP (ou XisPê ou eXtreme Programming). Foi muito legal. Usam stories (e não casos de uso); pair programming; TDD (Test-Driven Development); ou seja, todas as práticas fundamentais de XP. Detalhe: exceto uma! São eles que se sentam ao lado dos programadores, não os usuários. Meio na brincadeira (e meio sério), alertei-os que os “radicais” falarão que então não se trata de XP de verdade. Afinal, os “radicais” detestam AN’s! Não importa: estão felizes com o processo e, mais importante, está funcionando! Atenção pessoal que vive sendo cobrado (inclusive por este que aqui rabisca) por casos de sucesso na implantação de XP: taí um belo caso. Com AN’s!

    Gripe Terremoto

    Tive uma reunião logo após a oficina. Quando ela se encerrou, lá pelas nove, o primeiro tremor. Sinto uma gripe chegando de longe. E esta resistiria até a uma dose cavalar (e perigosa) de Resfenol. Só sei que não tem nada a ver com Dengue e afins porque estou quase sem voz, parecendo um poço artesiano e tremendo mais que prédio de Sampa na última terça. Ou seja: trata-se da gripe terremoto. Problemão: tenho vários compromissos na próxima semana. Se a overdose de chás e outros remédios não adiantar, não sei o que vou fazer. Só sei que o final de semana será diferente, com o note na barriga acompanhando meus tremores, hehe..

    Cadê o Cisne?

    Pois é: se o patinho feio se foi, cadê o cisne? Bom, ele precisa de alguns dias para concluir sua metamorfose. O coração do programa não sofrerá alterações, é lógico. Mas a oficina sofrerá grandes alterações, inclusive na forma como é comercializada. Preciso deixar mais nítida a amarração entre “Análise e Modelagem de Negócios” e a “Engenharia de Requisitos”, mesmo que um dos meus requisitos fundamentais seja o “leve acoplamento” dos eventos (ou seja, um não é e não será pré-req para o outro). Complicado, não? Bom, acho que já tenho a solução, e espero apresentá-la em breve.

  • BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios

    Nada como um dia (agitadíssimo) depois de outro (não menos agitado). Ao reler o artigo anterior, “O BABoK e a Disciplina ‘Enterprise Analysis’“, reparei que posso resumi-lo assim: O BABoK trata exclusivamente da macro-disciplina Engenharia de Requisitos. Apesar do nome, a KA (Knowledge Area) Enterprise Analsys (ou Análise Corporativa) trata exclusivamente daquilo que Karl Wiegers chama de Requisitos de Negócio . Trata bem e de maneira bem completa, diga-se de passagem. Mas este fato torna o nome BABoK (Business Analysis Body of Knowledge) meio enganador. Aquele conteúdo formaria um bom REBoK – Requirements Engineering Body of Knowledge. Para a Análise de Negócio falta uma metade: exatamente a Análise (e Modelagem) de Negócios!

    Desconfio que a falta já é sentida pelos próprios autores e responsáveis pelo BoK. Em uma das apresentações recentemente utilizadas na divulgação da profissão e do BABoK, eles frisam:

    Análise de negócios não é análise de requisitos de software. Analisar um negócio é compreender:

    • Como a organização trabalha;
    • Qual a razão de sua existência;
    • Seus objetivos e metas;
    • Como ela busca esses objetivos; e
    • O que ela precisa mudar para melhor atender esses objetivos.

    Para ajudar a definir uma solução para um problema de negócio.

    Com certeza, alguém já fez a mesma cobrança que faço desde que conheci o BABoK. Pena, mas a declaração acima (ainda) não está refletida naquele corpo de conhecimentos. Não há no BABoK um conjunto de Tarefas e Técnicas que atenda plenamente a lista acima, exceção feita ao terceiro item. Bom, como prometi no artigo anterior, serei mais “construtivo”.

    Antes de estudar as necessidades ou problemas de um negócio, é necessário conhecê-lo, aprendê-lo. Uma maneira muito eficaz para se *aprender* um negócio é a modelagem. Modelar é simplificar. Modelar é compilar apenas o que é essencial. Indico (teimosamente) o uso da EPBE (Eriksson-Penker Business Extensions) para a criação desses modelos por dois motivos principais: i) Ela é completa – me permite cobrir todos os aspectos de um negócio, sua estrutura e sua dinâmica (processos); e ii) A EPBE é uma extensão da UML (Unified Modeling Language), uma linguagem madura, bem difundida e fácil de aprender. (Já apresentei a EPBE em outra série de artigos).

    Todo e qualquer negócio apresenta 4 *coisas* que precisamos aprender: Objetivos, Recursos, Processos e Regras. Cada um deles pode merecer um ou mais modelos, dependendo da criticidade do negócio ou do projeto em questão. A EPBE nos oferece 4 visões, 4 dimensões – maneiras diferentes de *ver* o negócio: A visão do Negócio propriamente dita; sua Estrutura; Processos e Comportamento. Não há uma seqüência pré-fixada para o estudo. Como sempre, depende do negócio e do projeto. Mas, mesmo em empreendimentos muito simples, não abro mão de um enxuto mapa de processos e do diagrama de processos (ou “linha de montagem“) um pouco mais detalhado. Usando uma boa ferramenta CASE , e não meus rabiscos, obtemos automaticamente outros modelos, como a estrutura de recursos, objetivos e metas (ou mesmo um balanced scorecard).

    Ao estudar os processos, vendo as atividades e tarefas que os formam e toda a estrutura (departamentos e outros recursos) envolvida em sua execução, ganhamos uma visão mais nítida do “terreno que estamos pisando”. Se há um projeto, existem Requisitos de Negócio. São os objetivos (um dos 4 elementos básicos apresentados acima, lembra-se?), as necessidades ou problemas que devemos sanar. São os primeiros requisitos que conhecemos. Na maioria das vezes, bem antes do projeto ser iniciado. Mesmo que sejam mais críticos e essencias para o sucesso do projeto, esses requisitos são tratados da mesma forma – acolhidos em uma mesma estrutura. Destaquei este ponto para mostrar que Análise e Modelagem de Negócios e a Engenharia de Requisitos são atividades que ocorrem de maneira simultânea, e não sequencial. Nem quem mergulha em “cascatas” conseguiria tratá-las como fases distintas de um projeto – são naturalmente indissociáveis, “gêmeas siamesas”.

    Processos Envelhecem

    O que acontece quando um recurso de uma empresa se torna obsoleto? Ele é trocado, certo? Se for um computador ou um caminhão, compra-se um novo. Se for uma pessoa, aposenta-se ou mostra-lhe o bilhetinho azul (ou cartão vermelho, como queira). Mas, e quando um processo de negócio envelhece? O que acontece? As empresas costumam remendá-los e redesenhá-los. Trocas radicais só ocorrem mediante a implementação arbitrária de um pacote de melhores práticas também conhecido como ERP. Mas, mesmo assim, em curto espaço de tempo, voltam os remendos e redesenhos. O mundo não pára.

    O envelhecimento de processos, assim como o nosso, vem com más notícias. Saca aquela dorzinha na coluna que nunca tivemos? Bom, é por aí. E aqui entramos num ponto relativamente polêmico do trabalho dos Analistas de Negócios (AN’s). É mal traçada a linha que os separa daqueles tradicionais Consultores de Negócios. Há quem diga que um AN não deve “se meter” com os problemas do negócio. Oras, o que justificaria tamanha “vista grossa”?

    É claro que, quando em projetos para desenvolvimento ou implantação de sistemas, o foco do AN não é o redesenho (ou reengenharia) de processos de negócio. Mas isso não significa que ele deva ignorar sintomas e doenças que porventura encontre durante seus estudos. Se ele insistir em levar para a solução aquele processo e suas pequenas dores, levará também maiores riscos e chances de mudanças. É exatamente por isso que, ao contrário do RUP, gosto de chamar esta disciplina de Análise e Modelagem de Negócios. Soarei idiota, mas preciso reforçar: é o Analista de Negócios quem executa a Análise de Negócios! E analisar, definitivamente, não se resume ao desenho de belos modelos.

    Portanto, a grande e grave deficiência do BABoK é o fato deste ignorar por completo este estudo, a análise e modelagem de negócios. Acho pouco provável que todo esse “chororô”, que não é só meu, gere alguma mudança significativa na versão 2.0 que está em vias de ser publicada. Resta torcer para que, ao contrário do que ocorre em outras instituições similares, eles não se apeguem de forma intransigente à estrutura atual daquele corpo de conhecimentos. Seria fatal.

    Outros Corpos

    Como eu disse lá em cima, foi uma semana bem agitada. Em nosso grupo de discussão, parcialmente restrito aos participantes de meus eventos, surgiu um conversa meio “subversiva”: elaborar o que o amigo Jefferson chamou de “BABoK Apócrifo”! Acho que (ainda) não é o caso, mas um fruto imediato aquela discussão toda já gerou: nascerá (muito) em breve um Fórum que tratará exclusivamente do BABoK e da profissão AN. Ao contrário do grupo, acho que o Fórum será público. Acho. A turma decidirá.

    : Acontece na próxima quinta-feira (24/abr), em Sampa, a 2ª edição da oficina Análise e Modelagem de Negócios. É um evento de um dia só, mas consigo mostrar nele tudo aquilo que, na minha opinião, foi ignorado no BABoK. Nesta página você tem uma visão geral do programa. É extenso e tem vários exercícios. Mas nada que a gente não consiga conversar em 1 dia.

    Referências:

    1. Software Requirements
      Karl Wiegers. Microsoft Press (1999).
    2. Já utilizei a EPBE no Rational Rose e no Visual Paradigm, além d’outras, menos fechadas. Para quem quiser experimentar, existem duas ferramentas “free” que oferecem a extensão: StarUML e JUDE. (Tks! Marcelo).
  • O BABoK e a Disciplina “Enterprise Analysis”

    O IIBA (International Institute of Business Analysis) liberou no último dia 31 de março a versão 2.0 do BABoK (Business Analysis Body of Knowledge) para revisão pública. O projeto da nova versão tem uns 6 meses de atraso. E eles descontaram nos revisores: temos só até o próximo dia 15 de maio para apresentarmos nossas sugestões / reclamações. Tática estranha, mas não percamos tempo com ela. Abri este post para fazer uma revisão pública de um único capítulo daquela publicação, o capítulo 4, que trata de uma área de conhecimento (Knowledge Area) chamada “Enterprise Analysis”. Ponto que questiono e critico desde a versão anterior do BABoK.

    Antes de descarregar minhas críticas preciso explicar rapidamente a estrutura deste BoK caçula. Ele é formado por 6 KA’s (Knowledge Areas, ou Disciplinas). São elas: i) Planejamento e Monitoramento da Análise de Negócios; ii) Gerenciamento e Comunicação de Requisitos; iii) Análise Corporativa; iv) Elicitação; v) Análise de Requisitos; e vi) Avaliação e Validação da Solução. Cada KA é formada por Tarefas, Técnicas, Entradas e Saídas.

    Tarefas são “peças essenciais do trabalho que deve ser executado na análise de negócio”. As técnicas descrevem “como as tarefas devem ser executadas em determinadas circunstâncias”. Momento ‘dã’: tarefas recebem entradas e geram saídas. ufs.. Mas, por favor, não me entendam mal: a estrutura do BABoK é legal, bem simples. Tanto que consegui explicá-la em dois mínimos parágrafos. Vamos então ao que interessa (neste artigo), a “estranha” KA chamada “Análise Corporativa”.

    O problema já começa no nome. Tiveram que inventar um substituto para “Análise de Negócio”, porque interpretam este nome como um grande guarda-chuva que incorpora outra macro-disciplina, a Engenharia de Requisitos. Tudo bem, há tempos aprendemos a conviver com nomes e definições confusas. Por falar em definição, “Enterprise Analysis” é apresentada da seguinte forma:

    A (disciplina) Análise Corporativa descreve como tratamos uma necessidade de negócio, como refinamos e esclarecemos aquela necessidade, e como definimos o escopo de uma solução viável. Aqui conversaremos sobre a definição e a análise do problema, o desenvolvimento do Business Case, de Estudos de Viabilidade e da definição do escopo da solução.

    Na introdução do capítulo 4 do BABoK, que trata especificamente desta disciplina, é apresentada uma definição mais formal e completa:

    A Área de Conhecimento Análise Corporativa consiste de uma coleção de tarefas para a análise da situação do negócio para a completa compreensão de seus problemas e oportunidades, além de uma avaliação das condições atuais e futuras com o intuito de identificar as mudanças necessárias para a satisfação das necessidades do negócio e seus objetivos estratégicos. As saídas geradas nesta disciplina fornecem a base necessária para o trabalho de elicitação, análise, validação e documentação de requisitos, e também para a identificação de uma solução para uma determinada iniciativa e / ou para o planejamento de longo prazo.

    Escopo da Enterprise AnalysisA definição é legal. Assim como o gráfico ao lado, que ‘explica’ a disciplina em uma apresentação oficial do IIBA. Mas reparem na definição acima e na lista de KA’s do primeiro parágrafo. Se temos lá uma KA chamada “Avaliação e Validação da Solução”, qual a razão da KA “Enterprise Analysis” tratar do desenvolvimento do Business Case e, mais ainda, da elaboração de estudos de viabilidade? Confunde, não?

    Claro, uma avaliação mais profunda das técnicas mostra que estamos falando de coisas diferentes. Para ser mais exato, de momentos diferentes! Então, como fruto de um trabalho notadamente departamentalizado, temos que o estudo de viabilidade não está no escopo da disciplina Avaliação e Validação da Solução. Tudo bem. Como eu já disse, estamos acostumados a conviver com definições confusas e dúbias.

    Em meu entedimento, o problema com a disciplina Análise Corporativa é outro, consideravelmente maior. Ela deveria incorporar aquilo que conhecemos como Análise e Modelagem de Negócios. Não é o que acontece. Veja abaixo a lista de tarefas que formam esta KA:

    1. Definir as necessidades do negócio;
    2. Determinar o gap entre as necessidades e a capacidade do negócio de atendê-las;
    3. Determinar o enfoque recomendado para a solução;
    4. Definir o escopo da solução; e
    5. Desenvolver o Business Case.

    Que estranho: em nenhum momento o Corpo de Conhecimentos da Análise de Negócios fala sobre “aprender o negócio”, “entender o negócio”. Já cai direto na “definição das necessidades do negócio”. Tamanha pressa é medo dos agilistas (muito citados no BoK)? Sigamos, agora sem ironias.

    Alguém pode dizer que está implícito na compreensão das necessidades de um negócio o aprendizado sobre o próprio negócio. Grave engano, e as estatísticas sobre projetos que falham são a maior prova que posso apresentar. Só consigo aprender realmente as necessidades (requisitos) de um negócio depois de conhecê-lo. Façamos uma breve (e covarde) analogia: você saberia dizer as necessidades de sua (seu) namorada(o) ou esposa(o) antes de conhecê-la(o)? Antes mesmo de manifestar suas intenções?

    Se eu não conheço um negócio, aquele domínio, como posso avaliar suas necessidades e oportunidades? Pior, como posso “definir o escopo de uma solução”? Vale aqui ressaltar que conhecer um negócio não se limita ao entendimento daquela entidade, mas compreender todo o seu ambiente, clientes, concorrentes, parceiros, legislação e um monte de etc.

    Por essas e (muitas) outras insisto que o BABoK pode criar uma terrível distorção do trabalho conhecido como Análise de Negócios. Como tempo e espaço ficaram curtos, deixarei para o próximo artigo a porção mais construtiva de minhas críticas.

    Mas, claro (!), sobrou um tempinho para convidá-lo a conhecer uma visão um pouco diferente da Análise de Negócios. Acontece no próximo dia 24/abr, em Sampa, a 2ª edição da oficina “Análise e Modelagem de Negócios”. Nela e em sua co-irmã, Engenharia de Requisitos, apresento as tarefas e técnicas que são utilizadas por um Analista de Negócios. Claro, contemplo todas as boas idéias sugeridas no BABoK. Mas, definitivamente, não o considero um “corpo fechado”. Por isso apresento vários adendos, inclusive o uso da UML para a modelagem de negócios.

    Merchan Parte II: quem participa dos eventos ganha uma versão digital de meu (adiado) livro (com garantia de atualização até a versão 1.0), alguns PPT’s e, o mais importante, acesso ao Grupo de Discussão AN.br. Já somos mais de 200. E no último mês batemos o recorde de mensagens trocadas. Está muito quente e rico. E a última iniciativa do grupo é o estudo conjunto do BABoK. No meio de nosso “toró de parpites”, já pintou até a sugestão de elaboração de um “BABoK Apócrifo”. Pode? Claro que pode! Inté!

  • Rendiconti: Duas Experiências Inesquecíveis

    Tenho que me policiar muito para este artigo não soar muito demagogo ou apelativo. Já não resisti muito no título. Como tenho quase uma centena de testemunhas, garanto que sincero serei. Explicando: as duas últimas oficinas de “Engenharia de Requisitos”, realizadas em Floripa (28/mar) e Sampa (03/abr), foram fantásticas. Não tem segredo nenhum não: eram duas turmas de profissionais muito bons, antenados e bem cientes de seus problemas e necessidades. Ou seja, só não funciona quando seu material é ruim ou você não está bem preparado. Caso contrário o evento flui naturalmente, com o ritmo adequado. Ops… os papos estavam tão bons que, em ambas as turmas, tive que acelerar o passo no final para evitar um constrangedor atraso. Nada mirabolante: os exercícios obedecem uma sequência lógica e são modulares. Bastou agrupá-los para respeitar o prazo. Ah, se fosse simples assim em projetos…

    Floripa

    Grande sala! Auditório da ACATE.Sem chuvas, enfim! A sala grande permitiu que os grupos ficassem bem confortáveis, de certa forma isolados dos ‘concorrentes’. É o tipo de evento que exige muito espaço. Ao contrário do que ocorre em Sampa, tivemos que improvisar e eleger 4 monitores na hora. Jefferson, Patrick, Kelvin (depois Jorge – pois é, até substituição rolou) e Rodrigo formaram meu time de apoio.

    Dos 6 exercícios desenvolvidos durante a oficina eu “recolho” 4. Acontece que no final do evento eu crio uma certa concorrência entre os grupos. Prometendo divulgar aqui qual solução eu compraria (comprarei?). A equipe “É nós no DVD” foi, sem dúvidas, a mais criativa. Não pelo nome, claro, mas pelo conteúdo do documento de visão. Mas o melhor protótipo foi elaborado pela equipe “Menor”. O grupo “União” escreveu uma especificação de caso de uso muito boa. Mas o grande vencedor foi o grupo “WebDVD”, pela integridade e coerência de todos os artefatos desenvolvidos. Parabéns especiais para o Jorge, que “comprou” a solução, e para o caprichado trabalho da Sueli (como designer e AN).

    Claro, isso é só uma brincadeira. O que vale mesmo é a certeza de que conceitos e práticas foram bem assimilados. Foram. Como enfatizo as práticas e insisto que elas podem ser adotadas em qualquer processo de desenvolvimento, fico aqui torcendo para que a maioria consiga implementá-las no dia seguinte. Ops.. na semana seguinte. Era uma sexta.

    Parte da turma havia participado do evento anterior, “Análise e Modelagem de Negócios”. Isso ajudou no entrosamento e na “quebra do gelo”. Mas sei que só isso não explica o sucesso do evento. finito! Parabéns turma! Espero revê-los em breve.

    Grande turma!

    Sampa

    Apenas 6 dias separavam os dois eventos. Não teve jeito, temia muito pelo evento de Sampa. As duas primeiras edições que aconteceram lá foram legais, mas nenhuma alcançou aquele “clima” legal da turma de Florianópolis. Uma diferença está clara e faremos de tudo para eliminá-la: a sala. Em Sampa, além de pequena, a sala é montada com cadeiras fixas, o que causa grande desconforto para alguns participantes. Mas isso não é desculpa.

    Em SampaE a turma do dia 3 de abril provou isso. Foi tão legal quanto a turma de Floripa. Sala cheia, 47 participantes, contando os 5 monitores: Gisele, Amanda, Christiane, Alex e Gustavo. Não sei bem a razão, mas desde o início do dia ficou claro que o evento seria muito bom. Apesar do clima, do trânsito e do desconforto que é andar ultimamente pelas calçadas em obras da Paulista, todos estavam bem humorados. E com vontade de estar ali. Explico: a pior coisa de eventos assim, que duram um dia todo, é a presença de pessoas que parecem que estão ali porque “o chefe mandou”. Mau humor contagia. Má vontade, mais ainda. Sorte nossa: todos ali sabiam muito bem o que queriam.

    Uma prova é o alto nível dos exercícios. A concorrência entre os 5 grupos foi pesada. Tanto que o “Grupo da Chris” conseguiu desenvolver não 1, mas 3 protótipos! Mas não é só uma questão de quantidade. O grupo “TopLeft” elaborou um detalhado storyboard. Pena que foram muito econômicos no documento de visão. Aliás, eles tiveram menos de 10 minutos para elaborar a visão – a proposta técnica. Uma verdadeira covardia deste que vos escreve. Mas o “Grupo da Gisele” soube aproveitar muito bem o tempo. Pena que falharam na especificação de caso de uso, que tinha mais texto do que necessário, mais passos do que necessário. O “Grupo Alex” foi o mais ‘agressivo’ em sua proposta, sinalizando que o cliente poderia estar errado, hehe. Pelo bom humor (”equipe altamente qualificada e com entrosamento de mais de 8 horas!”), pelos 4 protótipos de excelente nível e, principalmente, pela qualidade da especificação de caso de uso, o grande vencedor foi o grupo “OJP Web Solutions”. E olha que era a proposta mais cara!

    Em SampaO evento de São Paulo teve uma particularidade que preciso contar. No início do evento anterior, de “Análise e Modelagem de Negócios”, a organização me avisou que um dos participantes, Márcio, tinha um grave problema de visão. Confesso, eu nunca tinha me preparado para essa situação. Meus eventos são muito “visuais”, com centenas de slides. Mesmo me policiando, sei que falhei com o Márcio em diversos momentos. Mas, para minha felicidade, ele estava novamente presente na última quinta. Talvez a turma não tenha percebido – acho que não chateei ninguém com minhas redundâncias, mas fiz questão de “ler” vários slides, principalmente os diagramas que antes eu não descrevia. Os comentários do Márcio e de sua colega Débora no final do evento comprovaram que, desta vez, acertei na tática. Imitando aquela propaganda: a satisfação que senti não tem preço. E sei que, de certa forma, essa ‘tática’ acabou ajudando para o sucesso do evento.

    Auto-análise

    O grau de maturidade e a aceitação da oficina “Engenharia de Requisitos” me criaram um problemão: sua co-irmã, “Análise e Modelagem de Negócios“, carece de uma boa revisão. O programa está correto, mas o formato “oficina” (também conhecido como workshop) demanda um conjunto de exercícios bem diferente. Primeira alteração óbvia: os exercícios devem realmente ser executados em grupo. Os participantes costumam elogiar a troca de experiências entre si. Não há porque não incentivá-las. Meu grande (e longevo) problema: criar exercícios realmente próximos do mundo real. Quando se trata de requisitos, é fácil “inventar” um projeto. Mas a análise e modelagem de negócios exige algo bem maior que um projeto. Bom, não tenho alternativa: tenho que criar os exercícios.

    Agora, para brigar contra a resistência ao tema (“o evento de requisitos sempre tem mais demanda que o de modelagem”, é o que sempre ouço), talvez eu deva apelar para marketeiros de plantão. O mais esperto me indicaria o seguinte: chame o evento de “Como Iniciar um Projeto”, ou surrupie a idéia-apelação do Karl Wiegers: “Practical Project Initiation“. Hehe.. garanto que teríamos salas lotadas!
    Mas, é claro, se mantido o programa atual, eu estaria sendo desonesto pacas! Prefiro ser teimoso. E seguirei insistindo que uma Engenharia de Requisitos realmente eficaz é amparada por sua prima-disciplina: a Análise e Modelagem de Negócios.

    Próximo teste: dia 24 de abril, 2ª edição em Sampa. Com os exercícios totalmente revisados!

  • O Parlamento

    No artigo anterior vimos que o analista de negócios (AN) descobriu uma série de casos de uso e desenvolveu alguns. Ao aprender o negócio e as necessidades dos usuários, o AN pensa muito pouco sobre a solução. Não está em seu escopo de trabalho tal definição. Ele apoiará o desenho da solução, que é trabalho para um time. Uma equipe que deveria contar com, no mínimo, um representante de cada ponto de vista relevante.

    Quais são os pontos de vista relevantes? Depende do projeto. Trata-se de um empreendimento que exige interfaces complexas com usuários? A equipe deveria contar com um especialista em usabilidade. O projeto requer um sofisticado desenho de bases de dados? A presença de um especialista em bases transacionais, analíticas e em gerenciamento de conteúdo não estruturado é recomendada. O projeto requer um preciso dimensionamento de servidores e da rede? Convoque o especialista em infraestrutura. Claro, o AN é presença obrigatória. É sua responsabilidade *ensinar* o problema para a equipe e auxiliar no desenho da solução. Essa reunião de especialistas é o que chamo de “Parlamento“.

    Parlamento, s.m. (do inglês parliament)
    assembléia ou câmara legislativa;
    ato de falar.

    Cabe aqui um lembrete: tomando o RUP ou o OpenUP como referência, ainda nos encontramos na fase conhecida como Incepção. Não iniciamos ainda a etapa de elaboração que, segundo aquelas propostas, resulta no “Lifecycle Architecture Milestone” (veja figura abaixo ). O parlamento foi convocado para desenhar uma ou mais soluções para o problema colocado, e apoiar o AN na elaboração de uma proposta (ou documento de visão, ou project charter, ou…).

     

    Fases do RUP (ou OpenUP)

     

    Ao aprender e debater cada caso de uso, começando sempre por aqueles mais críticos para o negócio, os participantes do parlamento “rabiscam” as primeiras idéias de solução. São essas idéias que, em determinado momento, são agrupadas. Como vimos no artigo anterior, podemos ter até três alternativas de solução – três agrupamentos de idéias.

    Cada idéia deve ser avaliada por todos os participantes. Antes dos chutes (ou estimativas), espera-se uma classificação bem simples: a implementação daquela idéia é Simples, de Média Complexidade ou Complexa? Ainda estamos preocupados em descobrir qual é a melhor solução para aquele problema. Lembrando: “melhor” não significa a mais sofisticada ou a mais econômica. A melhor solução será aquela que estiver mais alinhada com os objetivos e restrições do negócio.

    Neste momento eu gosto muito de utilizar uma ferramenta que, aparentemente, é meio bobinha. Estou falando da Matriz SMBP (confesso, acabo de inventar um nome para o brinquedinho). Veja o rabisco abaixo:

    A Matriz SMBP

    Todo caso de uso e requisito aprendido e desenvolvido pelo AN mereceu uma classificação simples: Fundamental, Importante ou Opcional. Vamos assumir que esta classificação equivale a 3, 2 e 1 ponto, respectivamente. Somamos a pontuação de todos os requisitos registrados em um caso de uso e dividimos pelo número de requisitos. Ou seja, calculamos a pontuação média de cada caso de uso.

    Todas as idéias de solução propostas pelo parlamento também foram classificadas, como Simples, de Média Complexidade e Complexas. Assumiremos aqui os valores 1, 2 e 3 pontos, respectivamente. Como a complexidade foi avaliada por vários especialistas, também calculamos a pontuação média. Pronto, agora temos as coordenadas que permitirão o posicionamento de cada idéia na matriz SMBP.

    Todas as idéias que aparecerem no quadrante de “Sonho” devem ser consideradas. Todas são de fácil implementação e satisfazem requisitos que foram considerados fundamentais para o negócio. Podemos dizer que um projeto que só tem itens neste quadrante também é um projeto “dos Sonhos”. Pena que eles são raros. Existem também aquelas idéias cuja implementação é mais difícil. Como elas também representam alto valor para o negócio, as chamamos de “Mal Necessário”. Muito necessárias. Não podemos ignorá-las.

    Já os dois quadrantes da parte inferior da matriz representam itens que devem ser muito questionados. As “bobeirinhas” um pouco menos, já que sua implementação é relativamente simples. Mas das idéias “Pesadelo” devemos fugir. Além de representar pouco ou nenhum valor para o negócio, são todas de implementação difícil. Como justificá-las?

    Como eu disse, a ferramenta parece uma besteirinha. Mas é muito útil na tomada rápida de decisões. Permite que toda a equipe se concentre em itens que realmente fazem a diferença em um projeto. Didática, a própria matriz pode ser utilizada para justificar o escopo do projeto para um cliente. Permite também que se decida a meta de cada iteração ou o escopo de versões posteriores do produto em questão.

    O parlamento, uma reunião que deve durar algo entre 1 e 4 horas, fornece bases para que o AN desenvolva a melhor proposta ou estudo possível. Respeita as inevitáveis restrições de custos e tempo – “é pra ontem!” – ao mesmo tempo em que elimina riscos e armadilhas. Não todos, é claro, mas é óbvio que a proposta ou estudo gerado é mais forte, melhor fundamentado.

    É cara? Se comparada às propostas “bumba-meu-boi” e “balança-mágica” que algumas empresas elaboram, sim. Mas é um custo facilmente recuperado em um projeto que já começa em trilhos certos, sem desvios ou surpresas. E, claro, se estivermos falando de propostas comerciais, o método aqui sugerido aumenta consideravelmente as chances de vitória.

    .:.

    Notas:

    1. Sim, *Especialistas*. Não coringas-especialistas-generalistas que chutam com as duas. Isso não tem nada a ver com Taylor e afins. O papo é cansativo, mas insistirei: é papo de Drucker, que diz que “conhecimento, por definição, é especializado“. Todo trabalhador do conhecimento (knowledge worker) busca (ou deveria buscar) a especialização. Como sou especialista em chatice, explorarei mais o tema em futuros artigos. A citação de Drucker eu tirei de “O Advento da Nova Organização”, artigo publicado na Harvard Business Review em 1988 (edição jan-fev).
    2. Figura (indevidamente?) surrupiada do OpenUP (que não deveria ter Copyright).
    3. Adoro nossa criatividade quando o assunto é a geração de propostas. O método “bumba-meu-boi” parece ser o default: um cara de vendas (ou pré-vendas) vai lá no cliente, se esforça para entender suas “dores”, volta correndo pra casa e se desdobra para traduzir aquilo tudo em cifras. Sim, porque a primeira coisa que seu chefe quer saber é o valor do projeto. “Bumba meu boi bumbá – é melhor alocar e cobrar por mês!!”, hehe.
      A “balança mágica”, como o nome confessa, é bem mais sofisticada. Ouvi dizer que uma grande empresa a utiliza. Na verdade, uma versão adaptada d’uma balança que um dia foi usada para pesar outro tipo de coisa ilícita. É de altíssima precisão. Joga lá a RFP e vê quanto deu: 127,34 gramas? Então o preço é R$ 400k, arredondado, e o projeto demorará 6 meses!! hehehe… Imprime até etiquetinha!