Ivar Jacobson liberou, agora em dezembro, um pequeno livro eletrônico chamado “Use Case 2.0: The Definitive Guide“. Como ele mesmo alerta, não se trata de uma atualização da ferramenta. Afinal, “casos de uso ainda são casos de uso”. Mas o texto propõe alguns novos elementos – novos artefatos de trabalho. Este artigo pretende avaliar as principais alterações sugeridas comparando-as com alternativas já conhecidas.

∞

Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
O que ela traz de novo a ponto de merecer o “2.0″? Antes disso, qual a motivação para uma nova versão?

Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: ”casos de uso são a cola de todo o ciclo de vida do processo [de desenvolvimento]“. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos [na elaboração] e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0″, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

∞

Observações:

1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

Artigos relacionados:

1. Um Novo Modelo para Casos de Uso
2. Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
3. O Mundo Ágil precisa de Analistas de Negócios?
4. Agile BA Parte III – Criando Caso
5. UMA Modesta Arquitetura

Related posts brought to you by Yet Another Related Posts Plugin.

Aconteceu na última semana, em Porto Alegre, a 1ª Conferência Brasileira de Análise de Negócios – o BA Brazil 2011. Transcrevo neste artigo minhas experiências e considerações sobre o evento. E trago para cá conversas e provocações que, acredito, merecem reflexões e debates.

∞

Se fosse preciso resumir tudo em uma única palavra ela seria: Show! Show de organização. Show diversificado. Show com lotação praticamente esgotada. O BA Brazil provou a força da comunidade e como o trabalho voluntário move e remove montanhas. Se alguém ainda tem dúvidas sobre a combinação dos termos “planejamento” e “métodos ágeis” ou sobre a utilização dos últimos fora da seara do desenvolvimento de sistemas é porque não viu o BA Brazil. Créditos para o time do IIBA e todos os parceiros que ajudaram a viabilizar o evento. Evito citar nomes para não cometer nenhuma injustiça. Todos estão de parabéns.

Infelizmente, por problemas de agenda, não pude ver praticamente nada dos dois dias de palestras e espaços abertos. Mas tive tempo suficiente para rever amigos de Brasília, Floripa, Sampa e Rio. E, claro, pude assistir a palestra de abertura ministrada por Shane Hastie. Shane explicou “porque precisamos de Análise em Projetos Ágeis”. Você acha estranho que esse tipo de “explicação” ainda seja necessária? Eu achava. Mas a conversa do Shane foge do lugar comum. E mira dois alvos: também fala sobre métodos ágeis para analistas de negócios. Seu discurso é sereno, objetivo e bem ilustrado. Seria impossível e injusto destacar algum ponto. Prefiro resumir assim: eu queria que mais executivos e agilistas tivessem a oportunidade de ouvir e conversar com Shane. Só isso.

Eu tive essa oportunidade, em cafés, viagens de táxi e jantares. E as primeiras coisas que você nota em Shane, além do profundo conhecimento dos temas que aborda, são sua humildade e generosidade. Em questão de pouquíssimas horas “viajávamos” pelas necessárias revisões do BABoK®, a sentida ausência dos casos de uso no draft da extensão ágil¹, a corrupção no Brasil (e suas similaridades com a África do Sul, país onde Shane morou por alguns anos), a beleza das mulheres de Porto Alegre, churrasco, caipirinhas (with two you get to the limit of liability!) e nossas experiências profissionais. Não necessariamente nessa ordem.

Em outro dia, quando compartilhávamos a mesa com Suzandeise Thomé, Luiz Parzianello, Marcelo Neves e Willen Dijkgraaf, chamei a atenção para a forma como Shane destacava sua não concordância com algum tema. Por exemplo: “Arquitetura Corporativa”. Shane desacelera e calibra a dicção, frequentemente soltando um “fundamentally wrrrrrong!”.  Aquele “Wrrrrrong” soa como um trovão. E não deixa a menor dúvida sobre sua posição. O que não significa que a conversa tenha se encerrado, pelo contrário. Está apenas começando!

Acompanhei de longe a repercussão do restante do evento. Pelos comentários a única conclusão possível é de um retumbante sucesso. E a certeza de que a versão 2012 é só questão de tempo. Que assim seja!

Reflexões

Minha palestra aconteceu logo na sequência, ainda na manhã da quinta-feira. Falar logo após a abertura do Shane já era uma responsabilidade e tanto. De carona no presente-provocação sugerido pelo Luiz Parzianello, uma responsabilidade quase insuportável. Quando me convidou, Parzianello sugeriu o título de minha fala: “Para você, o que é Análise de Negócios?”

Abri o papo confessando a dificuldade em condensar em quarenta e cinco minutos uma resposta que, a primeira vista, deveria ser muito simples e direta. Mostrei que apelei para um oráculo (Bob Dylan?!?) e para o pai dos burros (Houaiss) em uma busca infrutífera por inspiração. Quem leu meu artigo anterior já conhece o final da história. Meu problema não era definir a Análise de Negócios mas sim justificar a definição. E não havia mais nenhuma razão para manter implícitas ou autocensuradas duas provocações:

1. Há, no meu ponto de vista, exagerada e arriscada ênfase na macrodisciplina  ”Análise de Negócios” em detrimento de seus praticantes principais, os Analistas. Algo como: “o importante é que a Análise seja feita, não importa por quem”. Concordo que a área não carece de muros ou testes como aqueles que vemos em Direito, Medicina, Engenharia e afins. Por outro lado, se não existirem profissionais especializados e orgulhosos de sua área, como podem a disciplina e respectivo corpo de conhecimentos evoluir? Não é de hoje que é notória a baixa autoestima dos Analistas de Negócios, particularmente dos tupiniquins. Existem razões mil para tanto – sendo a principal a confusão com “tiradores de pedidos²”. Mas não melhoramos a situação com o discurso vigente. Em suma: se queremos uma Análise de Negócios forte e reconhecida precisamos fortalecer e reconhecer os Analistas de Negócios. Eles não são nada menos que fundamentais para o futuro da disciplina.
2. Não estava escrito em nenhum slide que utilizei mas acho que falei mais ou menos assim: “Se tivermos legítima preocupação com a Análise de Negócios em médio e longo prazos, então é hora de decretar sua independência de TI“. Reconheci que devemos ser eternamente gratos pelo fato de TI ter ressuscitado e viabilizado a área. Mas é chegada a hora de debater se queremos ou podemos limitar o uso da disciplina exclusivamente em problemas de negócios que envolvam Tecnologia da Informação. Apresento novamente mea culpa. Tenho vinte e cinco anos de vida profissional e sempre trabalhei com TI. Meu trabalho se limita a TI. Mas meu trabalho é só um grãozinho de areia, sem falsa modéstia. Quero crer que o público presente, pelas questões apresentadas, entendeu bem o recado. Até quando sugeriu, para minha concordância, que o Analista de Negócios é o Novo Novo Analista de Organização & Métodos.

Testando o {FAN}

Se o {FAN} 2012 precisava ser puxado até o limite, ele conseguiu em PoA. Foram duas turmas, uma delas não programada originalmente. E entre os quase setenta participantes uma diversidade grande, muita sede, muitas dúvidas e bastante colaboração. Ligeiras conclusões:

• O programa está perigosamente no limite de sua carga horária. Já penso seriamente em uma versão com 20 horas distribuídas em três ou cinco dias. Na próxima semana, em turma fechada e com 24 horas ao meu dispor, farei novo teste.
• Algumas atividades podem “sujar” mais paredes. A turma via o curso do Shane ao lado e gostava de todos aqueles displays.
• Aliás, posso contemplar em algumas turmas o trabalho de derivação de casos de uso em histórias e tarefas. E tornar a montagem de diagramas PUCS uma atividade mais interativa, fazendo toda  a sala montar um único diagrama.
• Preciso rever o último sprint, que acontece logo após um coffee-break. É um tour-de-force com cerca de duas horas de duração e sem nenhuma interrupção – nenhuma atividade prática. É uma longa história que conto, mostrando como os analistas de negócios trabalham em conjunto com o time de desenvolvimento em busca de uma solução. É legal – acho que todos gostam. Mas chego ali estourado, com voz e pernas extenuados. Ok, preciso melhorar minha condição física. Mas acho que é possível quebrar aquela história de forma a torná-la menos cansativa.

Tks!

Suzandeise Thomé, Luiz Parzianello e Marcelo Neves, pelo voto de confiança e pela oportunidade. Oferecer tão generoso espaço para um chato e crítico frequente do IIBA é prova incontestável da maturidade e do espírito democrático dos Chapters brasileiros. Vocês sabem, seguirei chato e crítico. Mas seguirei também um fã incondicional do trabalho de vocês. Parabéns!

Thank you, Mr. Shane Hastie, for your generosity, the shared knowledge and the patience with my bumbling english. 

Simone Kosmalski, pela hospitalidade, atenção e organização.

Melissa Trevisan e Marta Py, pelo trabalho, força e confiança.

Willem Dijkgraaf, pelo apoio e pelo feedback.

E muito obrigado a todos que tornaram o BA Brazil 2011 possível.

Observações:

1. Shane justificou a ausência (de casos de uso na extensão ágil do BABoK®) dizendo que a técnica já está devidamente coberta no BABoK® 2.0. Mas alertei, a ele e ao Parzianello (que também trabalha naquela extensão), que talvez o texto esteja passando a impressão (equivocada) de que no mundo ágil só se trabalha com histórias de usuários. Prometi ser mais específico na leitura crítica que publicarei antes para eles e depois aqui no {finito}.
2. Perdi a oportunidade de fazer um teste de DNA e tirar dúvidas sobre a paternidade do termo “tirador de pedidos”. Mas aproveito para registrar aqui outra coisa que o Analista de Negócios NÃO é: “traficante de picuinhas!” Qualquer dia compilo todos os “criativos” termos criados para desmerecer e desmotivar o mau uso da profissão.

Artigos relacionados:

1. BABoK: Uma Leitura Crítica
2. O Giro em Falso das Rodas Reinventadas
3. Um Corpo de Verdade
4. Reflexões
5. BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios

Related posts brought to you by Yet Another Related Posts Plugin.

Lancei na última semana, em São Paulo, a versão 2012 do {FAN} Formação de Analistas de Negócios. É uma versão especial porque celebra o quinto ano do programa. Aproveitei o impulso do BA Brazil, que acontece daqui a duas semanas em Porto Alegre, para antecipar o lançamento. Apresento neste artigo a estrutura, alterações e extensões da oficina.

∞

Não acredito que um dia o núcleo duro do {FAN} seja alterado. Desde o longínquo junho de 2007, quando foi apresentada ao público pela primeira vez, esta oficina está estruturada em torno de duas grandes disciplinas: Modelagem de Negócios e Requisitos. Aprendi depois de um tempo que deveria utilizar uma explicação relativamente simplista para justificar a estrutura: a primeira disciplina nos ajuda a entender um negócio; a outra concentra-se no entendimento das necessidades e restrições de usuários e outros interessados. Cada uma merece 50% da carga horária. A divisão arbitrária – um dia para cada disciplina – tem fins didáticos. Os participantes devem entender que lançam mão de ambas simultaneamente durante toda a sua participação em um projeto. Eles entendem.

Assim como entendem o fato deste evento não se basear na estrutura proposta pelo BABoK®. É fácil fazer um ‘de-para’ quando necessário. Como o foco da oficina não é a certificação, mas o trabalho prático com a Análise de Negócios, nunca ninguém reclamou. Cito o corpo de conhecimentos oficial quando necessário, seja para destacar algum problema ou boa solução. Tanto que falo até hoje sobre a versão 1.6 e seu bom capítulo sobre “Elicitação” de requisitos.

Deixo a impressão, até aqui, de que não mudou muita coisa no {FAN}. É que comecei pelo que não mudou. Vamos às alterações. A versão anterior, que utilizei até outubro deste ano, tinha 200 slides no arquivo de apresentação. A nova versão conta com exatos 299! Um acréscimo de praticamente 50% e a mesma carga horária? Como isso seria possível?

Fiz um levantamento de todos os tópicos que, a partir da interação com os participantes, exigiam improvisos em um quadro branco. Apesar de gostar de toda aquela dinâmica, percebi que perdia um tempo precioso rabiscando. Pior: ficava muito tempo de costas para a plateia. Todos os improvisos que ficaram frequentes mereceram slides. Praticamente todo um novo tópico sobre estimativas, priorização e definição de escopo brotou dessa decisão.

Eliminei também o ridículo “ditado” de uma especificação de caso de uso que servia como exemplo. Mantenho a apresentação passo-a-passo de um caso, mas agora os alunos ficam livres para prestar atenção no que de fato interessa. Três atividades práticas os deixam rabiscar e abusar do novo modelo que apresentei no artigo anterior.

E por falar em atividades práticas: são 11 no total. E, a partir de agora, nenhuma é opcional. Elas totalizam cerca de 240 minutos, quatro horas de um total de quatorze. Ou seja, cerca de 30% da oficina é totalmente prática. Parece pouco, mas me lembro dos tempos em que o {FAN} era FAN e tinha apenas 4 atividades. E de sua “pré-história”, quando não havia exercício algum.

Todos os exercícios são posicionados de forma a reforçar ou demonstrar a parte teórica recém apresentada. E são baseados em um mesmo problema de negócio. Mantenho a estratégia de não fixá-lo nas apresentações ou na apostila. Isso permite que a cada turma eu possa sugerir um novo. Também possibilita que em cursos fechados sejam utilizados projetos reais dos clientes. Na última edição eu ressuscitei o imbróglio do ‘seu’ Moreira – português fabricante de pãezinhos que precisa dobrar a produtividade de seus vendedores. Em PoA eu devo trocar a nacionalidade do preocupado e seu produto: de pão para vinho.

Outra mudança significativa está no número de ferramentas apresentadas, particularmente no módulo de modelagem. Incorporei novas sugestões, inspirado principalmente por dois trabalhos: Business Model Generation¹ (o ‘canvas’) e Gamestorming². Mantenho o Pensamento Visual como método de modelagem, mas sem a ênfase que ele mereceu nas versões anteriores. Ao ‘esconder’ o método e apresentá-lo apenas no final do primeiro dia eu consegui, por incrível que pareça, facilitar seu entendimento.

No final do segundo dia também acontece um momento flashback, desta vez revendo todo o evento e demonstrando um método para definição do escopo inicial de um projeto. Conto uma história onde o analista tem dez dias úteis para entender um problema e, junto com o time, tentar descobrir a melhor solução. Funciona realmente como uma grande revisão da oficina, da famosa fotografia 2km X 2cm até o detalhamento de casos de uso. É uma das partes que eu costumava improvisar e que ficou muito melhor com o apoio visual pré-concebido.

Agora deixei a impressão de que foi tudo perfeito no ‘teste beta’ que executei, o que não é verdade. Peguei uma turma que ficou muito silenciosa (assustada?) no primeiro dia. No segundo, se soltaram e interagiram bem mais, comigo e entre eles. Mas fiquei com a pulga atrás da orelha: a sobra de trinta minutos em cada dia é real? Só terei certeza depois das duas oficinas no BA Brazil. Encontrei um bug mais sério só no segundo dia, o mal posicionamento da atividade #8. Mas foi muito pouco para evento tão extenso. Sorte de principiante? Hehe… pode ser.

Outro probleminha: a apostila está mais bonita, melhor diagramada. Agora ela tem espaço para a resolução dos exercícios. Não pretendo mais distribuir blocos separados para eles. Acontece que o pessoal ficou com dó da apostila. Muitos não quiseram rabiscá-la. Mesmo com minha promessa de que a versão digital está disponível para download. O que fazer? Ah, se eles vissem como trato meus livros de papel…

Meio & Mensagem

Mudanças cosméticas; inserção pontual de ferramentas; maior cuidado com atividades práticas. O {FAN} nunca ficou parado no tempo e em seus quatro anos e meio de vida sempre apostou que podia ser bem melhor. Mas a nova versão traz uma mudança maior, não citada até agora.

Em meu entendimento, a “onda” em torno da Análise de Negócios passou. Assim como já ficou para trás a “moda” Scrum. É uma aposta que torno pública: vocês verão muitos entusiastas de primeira hora vestindo novas roupas, estampando novas cores e reciclando promessas. Trata-se do melhor momento de todas as ondas. Porque o que fica é o que de fato interessa. O que passou era entusiasmo (e oportunismo) e nada além disso.

O {FAN} 2012 incorpora esse espírito. Entende que a Análise de Negócios, que a necessidade dela, sempre existiu e sempre vai existir. Mas há um tanto de mea culpa no novo discurso. Motivado, principalmente, pelo advento dos Arquitetos de Negócios. Eles não seriam sugeridos se nós, envolvidos com a formação de analistas de negócios, tivéssemos feito um bom trabalho. Mas é só outra moda. Não deve preocupar.

Preocupa, isso sim, que os bons analistas de negócios não desanimem. Para isso acho que é fundamental provar sua criticidade no cotidiano de uma organização. Não apenas na solução de problemas de TI. Analistas de negócios não dão manutenção em sistemas! Analistas de negócios não são “tiradores de pedidos”! Analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios. Qualquer tipo de problema.

Posicionados a partir da definição acima os analistas de negócios se verão desafiados por domínios cognitivos de maior dificuldade. Não basta a análise – o estudo das diversas partes de um todo (Houaiss). O analista não é nada menos que fundamental na síntese – na destilação da tese proveniente daqueles que têm problemas e da antítese colocada pelos eventuais provedores de soluções. É peça fundamental – meio e mensagem – em um diálogo verdadeiramente produtivo.

Enfim, o {FAN} 2012 traz uma mensagem otimista embalada em belos desafios. Desenha-se em torno de duas disciplinas que definem as habilidades técnicas que um analista de negócios deve desenvolver. Mas é guiado por um conjunto que, por falta de termo melhor, tenho chamado de Habilidades Essenciais: Solução de Problemas, Análise, Síntese, Gestão do Conhecimento e Aprendizagem Organizacional, Comunicação Corporativa, Pensamento Criativo, Pensamento Sistêmico, Pensamento Visual, Teoria da Complexidade etc. Eu sei, assusta. Mas posso garantir: é apaixonante. Por isso seguirei teimando que essa é uma das melhores profissões do século XXI. Quem sobreviver (à onda), verá.

Extensões do {FAN}

Há meses brigo com uma ideia: liberar módulos curtos, com três horas de duração, para apresentação e aprofundamento de tópicos específicos do programa {FAN}. Como é impossível prever sua aceitação, farei testes reais em janeiro do próximo ano. Não exigirei participação prévia no {FAN} tradicional de 14 horas. Esta primeira geração do que estou chamando {FAN Fast} é formada por quatro módulos:

• Introdução à Análise de Negócios: apresentação da área, seu corpo de conhecimentos & habilidades e as responsabilidades de um analista de negócios em uma organização e em projetos. Tiro curto dirigido a todos que ainda precisam conhecer a função/profissão e saber como tirar melhor proveito dela em suas empresas.
• Aprendendo Requisitos, Contando Causos e Histórias: aprendizagem, estruturação e desenvolvimento de requisitos de forma prática e direta. Há tempo muita gente tenta contratar apenas o segundo dia do {FAN}, aquele que trata especificamente de requisitos. Este módulo é para eles e todos que queiram mergulhar um pouco mais no tema.
• Conversando (e Rabiscando) a Gente se Entende: novamente inspirado pelos livros citados acima. Ferramentas práticas que facilitam a comunicação com usuários, clientes e outros interessados. Outras ferramentas, além daquelas apresentadas no {FAN}, serão exercitadas aqui.
• Trabalhando com Scrum e outros Métodos Ágeis: para analistas e gente de negócios que precisam saber como se comportar (hehe) em projetos guiados pelo framework Scrum ou outros métodos ágeis. O que muda na atuação de um analista? E o que não deveria mudar? Evento prático e divertido que mostra a importância de um analista na formação de um “time de (dono de) produto” e no trabalho com métodos ágeis.

Todos os módulos são ‘levemente acoplados’. Ou seja, você contrata apenas aquele ou aqueles que te interessar. Não haverão (muitas) referências cruzadas, nem mesmo com o {FAN} tradicional. Nesta primeira leva, apenas uma restrição: os módulos acontecerão durante a semana, em dias consecutivos e em período noturno. Em breve publico as páginas dos eventos e divulgo a agenda.

Upgrade

Em 2010 ofereci, de graça, um FAN Upgrade. Foi muito curto e serviu para rever amigos. Passados quase dois anos, hora de agendar uma nova atualização. E ela se dará através da participação no evento tradicional, com 14 horas de duração! Desta vez o evento será pago (assim quem se inscreve realmente participa, né?) Mas terá descontos progressivos. Quanto mais antiga sua participação no FAN, menos você paga. Quem participou das turmas de 2007 e 2008, por exemplo, tem desconto de 50%.

O Upgrade está agendado em programação especial de férias: acontecerá em São Paulo, nos dias 13 e 14 de janeiro. O site da Tempo Real Eventos já está recebendo inscrições: http://www.temporealeventos.com.br/?area=15

∞

Observações:

1. Business Model Generation – Inovação em Modelos de Negócios
   Alexander Osterwalder – Alta Books (2011)
2. Gamestorming – A playbook for Innovators, Rulebreakers, and Changemakers
   Dave Gray, Sunni Brown e James Macanufo – O’Reilly (2010)
3. “Creating Solutions”, de HikingArtist.com, é o título do cartoon utilizado neste artigo.

Artigos relacionados:

1. Um Roadmap para Analistas de Negócios
2. FAN :: Os Novos Módulos do Programa
3. O Giro em Falso das Rodas Reinventadas
4. BABoK: Uma Leitura Crítica
5. Os Arquitetos (de Negócios) estão Chegando

Related posts brought to you by Yet Another Related Posts Plugin.

Apresento neste artigo um novo modelo para a especificação de casos de uso. Foram dois os empurrões que me trouxeram para esta nova proposta. Vários participantes de meus treinamentos pediram por um modelo que não tivesse apenas fins didáticos. Algo que eles pudessem adotar em seu dia a dia. Além disso, ideias recentes apresentadas por James Coplien, Gertrud Bjørnvig e Ivar Jacobson me fizeram rever alguns pré-conceitos em relação à ferramenta. Mantive boa parte do desenho original – a preocupação com a estruturação dos requisitos – mas incorporei vários novos elementos. Como ainda não tive muitas oportunidades para testar o novo modelo, contarei com seu retorno.

∞

Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).

Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.

O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.

Cabeçalho

Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.

Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.

O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.

“Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.

Contexto, Pré e Pós-Condições

Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.

Fluxo Principal

A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.

Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.

Fluxos Alternativos / Instruções para Testes

Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.

Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).

Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.

∞

Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!

Obs.:

1. Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
2. Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.

Artigos relacionados:

1. Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
2. Use Case 2.0: Você precisa dele?
3. Um Roadmap para Analistas de Negócios
4. EPBE: Um Meta-Modelo Básico
5. História de Aprendizado – Modelo

Related posts brought to you by Yet Another Related Posts Plugin.

Estão chegando os arquitetos (de negócios). E a tendência (nova moda?) estava tão fácil de ser percebida que não me perdoo. Fiquei uma hora batendo minha cabeça no teclado e berrando, entre gritos de dor, “beócio! É a arquitetura (de negócios), beócio!”. Brincadeirinha. E nem posso me condenar tanto assim. Afinal, em outubro do ano passado eu já estava falando sobre Arquitetura do Negócio. O assunto estava tão gelado na época que mereceu dois comentários, além de minhas respostas. Agora, oito meses depois, acho que ele sai do frio para o morno rapidinho. Justifico minha suspeita neste artigo.

∞

Anteontem, dia 14/junho, o InfoWorld publicou uma lista com as seis “mais quentes” novas profissões em TI¹. Hottest job nº 1? Arquiteto de Negócios. Peço desculpas antecipadas pelo veneno que escorrerá na sequência, mas o InfoWorld não ajudou: o trabalho mais quente em TI não é de TI?!? Está lá no texto: “o arquiteto do negócio é um membro da organização do negócio e reporta-se ao CEO”. E o que ele faz? “fashionaliza (ai!) a estratégia de alto nível da empresa com a tecnologia em mente”. Perdão, mas nem o Google Translate conseguiu trazer “fashioning” para o português. E como temos vários adoradores de termos chiques e da moda aportuguesados nas coxas, porque não fashionalizar? O problema é o Tite começar a se preocupar com a fashionabilidade de seu time. Chega! Meu corretor ortográfico não suporta mais neologismos bestas.

O advento da Computação na Nuvem (leia-se, aplicativos muito sexy e algumas vezes úteis que estão a um clique de distância) deixa gerentes de negócios com água na boca e coceira nos dedos. Por que esperar meses ou anos por um projeto da área de TI se posso contratar um serviço na Internet em questão de minutos? Segundo o artigo da InfoWorld, “o trabalho do arquiteto de negócios é armar os gerentes [de negócios] com o conhecimento que eles vão precisar para fazer boas escolhas [na Nuvem]“. Seria, em outras palavras, “adeus CIO, tchau departamento de TI, bye bye, so long, farewell…”? O texto não responde. Aliás, ele nem faz a pergunta. Afinal, onde entram CIO e sua área neste negócio? (Perdão pelo trocadilho).

Quem tem ou começa a ter cabelos brancos, como este que vos escreve, já viu este filme antes. Em preto e branco, digo, em fósforo verde. Tem início lá na segunda metade dos anos 1980, quando a microinformática começou a invadir as empresas. Foi assim que nasceu o que hoje conhecemos como “planilhódromo”, outro neologismo besta que resume aquela incomensurável quantidade de planilhas eletrônicas que tapa buracos dos softwares empresariais. Aquele foi o primeiro grito de independência de nossos queridos usuários insatisfeitos com nossa agilidade em atender suas demandas. Pelo visto, a Nuvem e suas suculentas e fáceis ofertas dão argumentos para o segundo grito. Seria esta a justificativa para a “invenção” de um arquiteto de negócios? Segundo a InfoWorld, sim. Se for, salve-se quem puder. E para o mundo porque eu vou descer agora.

Eu acho, e apenas acho, que eles acertaram o remédio mesmo com um diagnóstico muito equivocado da doença. Como escrevi naquele velho artigo, temos duas grandes motivações para desenhar e cuidar da arquitetura de um negócio: i) Entendê-lo; e ii) Avaliar a prontidão de TI (ou de qualquer outra área de apoio). E não é de hoje, nem de ontem, que tento mostrar que os analistas de negócios desempenham esta função. Querendo ou não, de forma estruturada e pensada ou não. Avaliar se determinada tecnologia, aplicativo ou brinquedinho (gadget) é adequado para um negócio é, desde o início dos tempos, uma das diversas atribuições que podem ser delegadas para analistas de negócios.

Não tem muito tempo que inventamos o Arquiteto Corporativo. Agora, chega esse Arquiteto de Negócios. Até quando seguiremos inventando falsas especializações e acreditando que este tipo de trabalho é coisa para uma pessoa só?

O BABoK® vem na Cola?

Um passarinho me contou que sim². Disse que o IIBA estaria trabalhando em uma nova extensão para o BABoK, uma extensão que falaria exclusivamente sobre Arquitetura do Negócio. Outra bullshitagem passageira? Pergunto porque, um ano atrás, anunciaram uma tal “Extensão Ágil”. Depois de um comedido bafafá e um ridículo draft de 24 páginas, não vi mais nada sobre o assunto. Espero estar errado. Aquela extensão é necessária.

Assim como é necessário que o BABoK saiba falar sobre Modelagem de Negócios. Mesmo que isso se dê pela via torta (e pelo chique nome da moda) da Arquitetura de Negócios. Só é uma pena que a comunidade de AN’s, particularmente a tupiniquim, gaste tanto tempo com picuinhas, festinhas e eventos chuchu (que repetem ad nauseam as maravilhas do BABoK). Se gastassem 10% de seu precioso tempo na evolução daquele “corpo de conhecimentos” o mundo seria um lugar melhor para se viver.

Os Arquitetos já Estão entre Nós

Chegaram em um dos meus clientes. Mas ele não sabia que InfoWorld e IIBA falariam sobre isso. Na realidade, por uma série de motivos, o cliente resolveu dividir o papel dos analistas de negócios em dois: Arquitetos de Negócios e Analistas de Requisitos. Os primeiros atuariam de forma mais próxima ao negócio, apoiando desde a definição do portfólio de projetos até o ponto em que um trabalho mais braçal possa ser delegado para os segundos. Não gosto do desenho, mas entendo e respeito as justificativas para ele. Como é um trabalho que mal começou, ainda não posso falar sobre os resultados. Espero poder fazê-lo em breve.

Conclusão?

Preciso mesmo concluir? Meu encosto-writer acha que sim. Posso dar uma de Dr. House? Então, lá vai: Se você é ou pretende ser um Analista de Negócios, então esqueça o papo sobre Arquitetos de Negócios. É só outro nome que inventaram para você que já foi, é ou pretende ser: analista de requisitos, analista de processos, analista de processos de negócios, business designer, use-case specifier, requirements reviewer etc³. Mas, atenção: siga com curiosidade e carinho tudo o que se refere a Arquitetura de Negócios. Inté!

Observações:

1. As outras cinco profissões também parecem ser bem divertidas. Não me segurei e as apresento brevemente, e sem tanto veneno, lá no GRAFFiTi.
2. Apesar de confiar bastante no passarinho, fui dar uma conferida (preguiçosa) no amigo Google. Não encontrei nada sobre a extensão, mas vi muito evento do IIBA (ou de gente do instituto) falando sobre Arquitetura do Negócio. Separei dois exemplos: 1, 2.
   Ganha um picolé de chuchu o primeiro que começar a falar por aqui sobre como um AN pode “alavancar” a Arquitetura de um Negócio. Depois da crise de 2008, o termo “leverage” e seu risível correspondente tupiniquim “alavancar” deveriam ser banidos dos dicionários.
3. Se assustou com a extensão da lista? Saiba que um dia ela já pintou, por exemplo, no RUP. E aceite que é assim, e talvez agora como Arquiteto de Negócios, que muitas empresas tratam e seguirão tratando aquela(e) que por aqui é conhecida(o) como Analista de Negócios.
4. “sigurd lewerentz, florist, 1969“, a imagem utilizada neste artigo, é de seier+seier e foi liberada sob licença CC-by.

Artigos relacionados:

1. [SOA # 3] – É o Negócio, Estúpido!
2. Arquitetura do Negócio
3. Repensando o Papel do Analista de Negócios
4. (Pensando alto sobre) Arquitetura Corporativa
5. O Analista de Negócios Perfeito

Related posts brought to you by Yet Another Related Posts Plugin.

Participei, na última semana, do Maré de Agilidade Edição Pantanal. Faz tempo que parei de publicar rendicontis – prestações de contas de minhas participações em eventos. A experiência agora foi muito diferente. Por isso merece este post.

∞

Estou curado. Foi assim que encerrei a palestra de sábado. Me referia ao meu jeito ‘bicho do mato’ – são raras as vezes em que participo de eventos coletivos. As razões são várias e algumas não merecem nosso tempo. Tenho algumas restrições (pré-conceitos?) e existem algumas caçarolas bem vedadas. Raramente sou convidado para eventos de Análise de Negócios, por exemplo. Apesar de seus organizadores viverem elogiando, pelo menos pessoalmente, minha “inestimável contribuição” para a disciplina. Exageram no elogio e na distância. Há tempo estou conformado e confortável com essa fronteira – cada um no seu canto, a sua maneira, tentando aprender e colaborar. Qual não foi minha surpresa quando Saulo Arruda (@sauloarruda), da Jera Software Ágil, me convidou para a Edição Pantanal do Maré de Agilidade. Afinal, se sou estrangeiro na “minha área”, o que dizer de minha relação com a Comunidade Ágil?

Saulo encomendou dois produtos: uma versão especial do FAN (programa para Formação de Analistas de Negócios) e uma palestra. O FAN deveria falar de maneira mais direta com o público de um evento Ágil. A palestra tinha que puxar o papo para outros domínios. Decidi aproveitar a oportunidade para testar o FAN4Scrum. Teria uma carga horária de 12 horas para tanto.

Contei com 35 participantes no curso, uma turma bastante diversificada, motivada e compreensiva. Explico, de trás pra frente: era de fato um teste do programa de treinamento, e eles ficaram sabendo disso logo nos primeiros minutos de aula. No último dia precisei de uma horinha adicional. Todos toparam chegar mais cedo e sair mais tarde. Estavam motivados porque são carentes desse tipo de papo. E, exatamente por isso, exploraram bem a oportunidade. Nas três manhãs a interação foi constante e, quero crer, muito proveitosa. Por fim, a turma era bastante heterogênea. Tinha gente da administração pública e da iniciativa privada; haviam gerentes, escritor(es), desenvolvedores, professores e… analistas. Sempre curto uma turma com origens e anseios diversos. O papo fica mais rico.

Descobri que o FAN4Scrum, ao contrário do FDP (Formação de Donos de Produtos), não funcionará com carga mínima (7 horas). A menos que eu me contradiga e elimine 50% do programa, hehe. Ou apele para uma solução que não me agrada: tornar o FAN um pré-requisito para este curso. Trouxe para casa um saboroso problema que preciso resolver até o início do próximo semestre, quando espero lançar o FAN4Scrum em outras praças.

Meus cinco dias em Campo Grande foram uma combinação de altos papos, muita comida boa, uma quantidade saudável de cerveja e, nas tardes vagas, muito trabalho. Decidi que montaria só lá, em cima da hora, a palestra de cinquenta minutos que apresentaria no sábado. O tema, que virou uma gaiola, precisou ser definido com antecedência. E cometi o “Analistas de Negócios no Mundo Ágil”. Não precisei de muito tempo para descobrir a ‘varada n’água’ que o título representava. Soa muito 2007 ou 2008 essa dicotomia. Por que eu desperdiçaria uma oportunidade daquelas voltando páginas?

Fui alertado que 99% do público do evento de sábado, estimado em 180 pessoas, seria formado por desenvolvedores. Eu esperaria algo diferente do Maré de Agilidade? Sei que o alerta veio, principalmente, por causa do título da palestra. E de um detalhe: ela seria a primeira do dia!

Depois da abertura tocada pela dupla¹ @Jeffmor & @Porkaria, a bola estava comigo. Auditório praticamente lotado, não demorei para perceber que era o mais velho ali (apesar dos cabelos brancos do @AleGomes). Havia a possibilidade de uma única alma viva estar ali por causa do título de minha palestra? Melhor não perguntar. Preferi deslizar uma série de 10 slides que traziam no título: “This isn’t a Troll”. Tipo: ok, sou meio estranho no ninho, mas acho que esses assuntos precisam ser debatidos. E lá se foram: Todo projeto precisa de Times de Produtos (formados por PO’s e AN’s, por que não?); “Arquitetura é importante demais para ser deixada apenas nas mãos do arquiteto.” (James Coplien); “User Stories não são suficientes” (idem); Casos de uso são legais, completos e ágeis pra caramba!; e, em outras palavras, “temos pouca grana para bons projetos porque as empresas torram fortunas mantendo código porco”.

Pintado frito recheado com provolone². Acho que pareceu confuso assim. Mas, pela reação geral, acho que entreguei o meu peixe.

Agora a sessão “jogando pra galera”: foi legal poder conhecer pessoalmente, além dos citados acima e pela ordem, Felipe Rodrigues (@Felipero), Celso “Carioca” Martins (@Celsoavmartins), Alexandre Gomes e Paulo Silveira (@Paulo_Caelum), além de toda a turma muito hospitaleira de Campo Grande. Também pude rever um antigo contato, o Gustavo Malheiros (@Gumalheiros). Por fim, mas não menos importante, é preciso destacar o trabalho do pessoal da Jera na organização do Maré. Em três palavras: Show de Bola! E põe na conta a minha “cura”. Inté!

∞

Observações:

1. Ney Matogrosso (do Sul!) e Luan Santana que se cuidem! Com JeffMor nas cordas e vocais e Porkaria na bateria, formando um tipo de White Stripes pantaneiro-pop-folk-alternativo influenciado pela Sandy e pelo Júnior, vem aí a próxima bomba que agitará o mundo do Sertanejo Universitário (blergh!). Vocês PERDEM por esperar!
2. Pintado frito recheado com provolone. Pode parecer estranho, mas é um tira-gosto acachapante.
3. A foto acima foi tirada pelo @AleGomes lá do fundão do auditório. Se vc prestar atenção, perceberá nossos White Stripes lá na frente do palco, numa performance “a capela”.
4. Uma ideia me acompanha desde sábado, inspirada pelo Maré de Agilidade. Me livrei dela lá no GRAFFiTi.

Artigos relacionados:

1. FAN :: Os Novos Módulos do Programa
2. Para que serve o Analista de Negócios?

Related posts brought to you by Yet Another Related Posts Plugin.

Este será um post diferente¹.

Há algumas semanas participei de uma pequena reunião com especialistas de diversas áreas. Mistura de comunidade de prática com think tank – sem frescuras, pura troca de experiências e dicas. Distribuí meu risque & rabisque e, de bate pronto, recebi a pergunta: por que a questão “o que precisa ser feito?” mereceu tanto destaque? Contei rapidamente a história: Drucker disse, lá no final do século passado, que era a pergunta mais importante que um executivo poderia fazer. Meu interlocutor completou: “Pode ter sido. Hoje, a questão mais importante e difícil é: por que precisa ser feito?”

Não preciso ir muito longe para descobrir inúmeras evidências que provam que meu colega está certo. A amiga Thais, trabalhando na administração pública, não sabe o que fazer para priorizar as demandas de dezenas de secretarias. Um cliente, que é uma SA, também não sabe o que fazer com seu backlog volumoso, amorfo e desordenado. Buscamos pistas no topo do topo da pirâmide – o que estariam dizendo o plano diretor daquela cidade ou a área de relação com investidores daquela empresa? – e seguimos perdidos. Para onde quer que eu olhe é quase sempre o mesmo: tudo é prioritário. Sendo assim, nada é prioritário.

Não é de hoje que a questão me incomoda. No ano passado escrevi alguns artigos sobre estratégia e priorização {1, 2}. Sugestões inúteis se não temos as diretrizes iniciais. Cada vez mais parece que o buraco “está mais em cima”!?!

Caramba, se o Capitão não sabe dizer para onde dirige seu barco, quem saberá? E o que dizer dos efeitos imediatos de tamanha falta de sentido? Primeiro, tem um monte de gente correndo adoidado para entregar ou se livrar de tudo o que aparece pela frente. Segundo, esse monte de gente trabalha no automático, sem objetivos. Como saber se um trabalho é bem feito se não conhecemos sua razão? Como acordar de manhã e ir trabalhar se não entendemos a motivação?

O que a turma lá de cima tanto faz que esqueceu de sua principal atribuição? Será que estão todos presos nos mesmos problemas cotidianos? Se toda a pirâmide de uma organização está concentrada no presente, detonando a única justificativa plausível para uma estrutura hierárquica, quem sobrou para projetar o amanhã e o depois de amanhã?

Enfim, encerrando a irritante sequência de interrogações, o que poderia ter criado esse mundo repleto de barcos sem mapas nem bússolas?

∞

Observações:

1. Sei lá quando criei a restrição (mania) de publicar apenas artigos longos e (teoricamente) mais elaborados. O fato é que, com a agenda meio insana que assumi, corria o risco de deixar o {finito} às moscas por um longo período. Por isso vou tentar ser menos chato e publicar posts como este, mais curtos. É uma forma de dar sinal de vida, certo?
2. “Experts at Sea“, cartoon que ilustra este post, é um trabalho do HikingArtist.com disponibilizado via Flickr.

Artigos relacionados:

1. Priorizar
2. Benefícios / Custos
3. O Mundo Ágil precisa de Analistas de Negócios?
4. Classificando e Priorizando Projetos
5. Valorizando Projetos

Related posts brought to you by Yet Another Related Posts Plugin.

Conclui o artigo anterior prometendo ilustrar o funcionamento das Comunidades de Prática através de dois casos de uso: uma comunidade de gerentes de projetos e outra de analistas de negócios. Descobri depois que precisarei de mais de um artigo para contar toda a história. Começo hoje com o caso de uma panelinha de gerentes de projetos. Ficção inspirada em acontecimentos reais.

∞

Era uma vez uma agitada empresa de serviços de TI que dia sim e no outro também enfrentava ‘probleminhas’ em seus projetos. Probleminhas dos mais diversos tipos e origens mas com um alvo em comum: o gerente do projeto. A empresa crescera ou inchara – dependia do ponto de vista – e os tropeços em projetos se multiplicaram. Os clientes se mantinham fiéis porque reconheciam a excelente capacidade técnica dos profissionais que ali trabalhavam. Mas não poupavam críticas à forma como os projetos eram conduzidos. Reclamavam principalmente das más notícias – atrasos e estouros – que só chegavam quando era tarde demais.

A empresa, que contava com 11 gerentes de projetos, ouviu de um deles que a solução seria a montagem de um Escritório de Projetos. Um órgão que centralizaria discussões sobre métodos de trabalho e cuidaria para que os projetos obedecessem um padrão de qualidade. Os outros gerentes não gostaram da ideia. Desconfiavam, com certa razão, que ganhariam mais um cobrador, além do patrão e dos clientes. “Não precisamos de mais ninguém cobrando resultados – precisamos de alguém que ajude a entregar!” – foi a justificativa que apresentaram ao Poderoso Chefão (PC). Mas concordaram que as coisas não podiam continuar como estavam. Prometeram apresentar uma alternativa ao escritório de projetos. “Na próxima segunda, sem falta!”

Assim a ‘hora feliz’ da sexta-feira se transformou numa quente reunião de trabalho. Os onze estavam ali no início. Mas o Gil, aquele que defendia a fundação do escritório, ao perceber que era voto mais que vencido, abandonou o barco e meio copo de chopp na mesa. Os demais tocaram o papo como se nada tivesse acontecido. “Temos que mostrar números e nos comprometer com alguns deles”, disse João. “Só assim podemos convencer o PC”, concordou Maria. “É fácil”, explicou José: “O escritório custará, no mínimo, 320 horas por mês. 160 do novo poderoso chefinho mais 160 de um auxiliar que, com certeza, ele vai demandar. 320 horas de fiscalização em cima de nossos 17 projetos, exigindo relatórios de status, cronogramas atualizados, pautas de reuniões etc. E se a gente pedir metade, 160 horas, pra gente debater nossos problemas e tentar, em grupo, encontrar as melhores soluções?”

Era uma pechincha aos olhos e bolsos do PC: metade do custo¹ do escritório. Mas significaria quatro horas de trabalho a menos, por semana, de todos os gerentes. PC pesou prós e contras e decidiu fazer uma experiência: “Vocês terão 1 mês para provar que essa tal Comunidade de Prática pode ter mais valor que um escritório. Serão 4 reuniões semanais, sempre nas tardes de sexta-feira. Mas, lembrem-se: não quero nenhum cliente me ligando para reclamar que vocês deixaram alguma ponta solta. Não quero amolação, ainda mais no começo do final de semana. Ficou claro?”

Ficou, apesar de todos concordarem que um mês era muito pouco tempo. Mas era pegar ou largar. Pegaram. E decidiram elaborar, no mesmo dia, a pauta do primeiro encontro. Sabiam que deveriam priorizar as questões que dessem resultado em curtíssimo prazo. Cada membro se comprometeu a apresentar três sugestões de temas. Adiantaram que cada sugestão seria avaliada sob dois pontos de vista: percepção do cliente e do PC sobre aquela possível melhoria e a complexidade de sua implantação. Esperavam, no pior cenário, a apresentação de 33 sugestões (contando com a improvável participação do Gil, aquele que defendia a criação de um escritório). Como sabiam que alguns problemas eram comuns, esperavam um número menor de sugestões a debater. Foi o que aconteceu: ao equalizar o entendimento de todos, terminaram com 12 sugestões de temas. Duas delas apresentadas pelo Gil, para surpresa de todos. Ele seguia com cara de poucos amigos e um tanto negativo, mas participou.

E ficou surpreso quando, no início da primeira reunião, a turma pediu que ele apresentasse os principais benefícios de um escritório. “Vocês não acham que é tarde demais para isso? Já se arrependeram?” Ouviu que o pessoal queria conhecer melhor a alternativa e que o grande e praticamente único temor deles era o de ‘ganhar outro chefe’. Evitaram a armadilha da conversa que não leva a lugar nenhum insistindo na apresentação dos benefícios em apenas quinze minutos. Não haveria debate. Afinal, eles só tinham quatro horas.

E aprenderam que, além de servir como ponto único de contato entre gerentes e o PC, o escritório também deveria: i) fixar padrões de métodos e práticas (uma metodologia); ii) ajudar gerentes de projetos em questões pontuais; iii) treinar gerentes de projetos; e iv) indicar gerentes para os projetos.

Logo perceberam que o foco em ‘questões pontuais’ tornaria o grupo uma alternativa bem mais pobre que o escritório. Revisaram a lista de sugestões e, por sorte, não encontraram ali nenhuma proposta que não pudesse ser aplicada em mais de um projeto. Se de cada proposta emergisse pelo menos uma sugestão de método ou prática, eles começariam a atender o primeiro objetivo de um escritório. O terceiro, treinar gerentes, viria do aprendizado coletivo daquele determinado método ou prática. Já se deram por satisfeitos. E decidiram usar a próxima hora na priorização dos temas. Sobrariam pouco menos de duas horas para debater pelo menos um deles.

Como priorizar os temas? Partindo da definição original de uso de duas perspectivas (percepção do cliente e/ou PC e complexidade de adoção), Maria foi até o quadro branco e desenhou uma matriz (ela, assim como este aqui rabisca, tem uma queda irremediável por ‘matrizes de apoio à decisão’). No eixo Y Maria anotou a escala de percepção do cliente ou PC. Decidiram que utilizariam cores para diferenciar temas que afetassem apenas um deles ou ambos: “rosa afeta o PC; azul o cliente; amarelo ambos.” Em X o número de semanas necessárias para adoção da possível solução encontrada para determinado tema. Debateram se valeria a pena o risco de adotar soluções cuja implantação durasse quatro semanas. Decidiram que não e concordaram que priorizariam soluções que demandassem o prazo máximo de três semanas.

A turma gostou, mas destacou uma distorção: eles não estavam se preocupando com seus times, com a percepção deles. Acordaram que, dado o curto prazo, iriam privilegiar temas cuja melhoria fosse percebida pelos clientes ou pelo PC. Se e quando a comunidade vingasse, poderiam utilizar a mesma matriz para cuidar de temas que tivessem reflexo no time – o que chamaram de “questões internas” (ou “intrínsecas”, como quis o Gil, que já estava começando a gostar do rumo da conversa).

∞

E você, gostou do rumo da conversa? Espero que sim. Assim como espero que aguarde os próximos capítulos. Vou ilustrar o preenchimento da matriz e as prioridades definidas pela Comunidade de Prática. Um outro artigo será necessário para exemplificar uma comunidade de analistas de negócios. Tentarei evitar que a pauta do {finito} fique muito monótona intercalando pelo menos um artigo diferente entre os próximos. Inté!

Observações:

1. Conto com sua compreensão para a ‘conta de padaria’ aqui registrada. Sei que 160 horas de 10 (11) gerentes de projetos podem custar muito mais que 320 horas de um ‘chefe’ de escritório e seu auxiliar.
2. “Under Pressure“, a foto da panelinha de pressão que ilustra este artigo, é do Anderson Mancini.

Artigos relacionados:

1. Escritórios, Comunidades e Panelinhas
2. Formalizando Panelinhas
3. BABoK: Uma Leitura Crítica
4. Reuso: Prática Sistemática
5. Onde Mora o Analista de Negócios?

Related posts brought to you by Yet Another Related Posts Plugin.

Continuação de “Escritórios, Comunidades e Panelinhas“. Naquele artigo sugeri que Comunidades de Prática podem ser uma alternativa mais eficaz e barata que Escritórios (de Projetos, de Análise de Negócios etc). Hoje tentarei mostrar como uma organização pode identificar, negociar e formalizar uma Comunidade de Prática. As comunidades ou panelinhas já existem e seguirão existindo, queira a gerência ou não. Sua formalização pode representar ganhos em termos de aprendizagem organizacional, ambiente de trabalho e agilidade. Três A’s que devem justificar este tipo de investimento. E que podem ser facilmente medidos.

∞

Até uma gerência muito mecânica e dura, baseada em Comando & Controle, sabe da existência de panelinhas entre seus “gerenciados”. A Identificação delas pode ser simples, mas merece alguns cuidados. Em ambientes de trabalho ruins, deteriorados por uma série de razões, as panelinhas ocupam-se demais com chororôs e reclamações diversas. O que une aquelas pessoas é um “inimigo” comum e não um interesse comum. Nestes casos é um tanto mais difícil a seleção de um grupo que possa vir a formar uma comunidade de prática. Se o gerente não for o “inimigo” comum (e ele sabe quando o é), deve tentar participar das rodas de conversas para avaliar quanto conhecimento bom circula por ali. Se pelo menos 20% ou 30% do tempo não for dedicado à chiadeiras em relação ao trabalho já é um bom indício. Sinal de que aquela panela pode ser mais produtiva.

As panelinhas, por constituírem uma estrutura marginal e não reconhecida pela organização, funcionam nas brechas, nos horários vagos e geralmente em locais abertos, públicos. Reúnem-se ao redor de máquinas de café, nos restaurantes, bares e até em quadras esportivas. E costumam valorizar demais seu tempo e espaço. Por isso a intromissão de um gerente ou equivalente deve ser bem medida e cheia de tato. E silenciosa. Tudo o que ele quer é ouvir. Desnecessário dizer que um gerente boa praça e com ficha relativamente limpa não deve encontrar muitas dificuldades neste momento.

Vamos supor que o interesse comum de determinado grupo seja a “arte” do gerenciamento de projetos. Entre choramingos, comentários sobre a roupa de fulana e os resultados dos jogos do final de semana, vez por outra as pessoas daquele grupo vão “falar de trabalho”. Este papo, normalmente censurado nas happy-hours de sexta-feira, é o que pode interessar para a organização. A conversa é rica? As pessoas estão realmente trocando experiências? Quantas dicas e momentos a-ha aparecem em um encontro? Os membros sentem-se à vontade para criticar? As críticas são bem recebidas? Não há trollagem (sic) nem rivalidade mal administrada? É fácil perceber quando uma conversa é boa, quando ela gera o que chamei acima de “bom conhecimento”. Se for o caso, acabamos de identificar um excelente candidato à Comunidade de Prática.

Iniciamos então a etapa de Negociação. Espera-se que o gerente já tenha combinado previamente com a alta direção da organização. É dela que ele receberá os parâmetros negociáveis. E, sinceramente, é nesta negociação prévia que encontramos as maiores dificuldades. Como estamos muito distantes do costume de “formalizar panelinhas”, tudo pode soar muito estranho para os donos da grana: “Como assim, CEDER 4 horas semanais para o grupo? Por PRAZO INDETERMINADO? E EMPRESTAR uma sala de reuniões? E NÃO COBRAR resultado nenhum? Como assim?”

Destaquei nas questões acima aquelas que considero ofertas mínimas que uma organização pode apresentar para uma comunidade de prática. Revendo:

• Uma fração da jornada normal de trabalho, no mínimo 10%. Seria uma sacanagem sugerir encontros fora do horário de expediente. A panelinha já o faz e em lugares mais aprazíveis que as tradicionais salas de reunião. E não é nada eficaz colocar alguma condição para o uso dessas horas. É preciso criar costume, criar cultura. Sempre achei que a tarde das sextas-feiras existe exclusivamente para atividades “lúdicas”.
• Uma Comunidade de Prática não é um projeto nem trabalha em um. Por isso sua existência não tem prazo de validade. Se um dia o grupo descobrir que não está aprendendo mais nada – que sua relação se esgotou – então ele pode decidir pelo encerramento de suas atividades. A organização, em casos extremos, também pode extinguir um grupo. Mas deve estar ciente das consequências negativas de sua decisão.
• O grupo merece um local adequado para suas discussões. Por adequado entenda: minimamente isolado de outras áreas e equipado de recursos básicos (quadro branco, mesas, cadeiras etc).
• Por fim, mas não menos importante – muito pelo contrário, o compromisso de não cobrar resultados de uma comunidade de prática. Se ela não é nem está em um projeto, não há metas ou objetivos específicos justificando sua existência. Talvez este seja o ponto mais controverso e mal compreendido de uma comunidade de prática. É claro que uma empresa pode avaliar a qualidade das conversas e do conhecimento que está sendo gerado ali (sobre isso eu falo abaixo). Eventualmente, pode até sugerir algum tema ou problema específico para a pauta do grupo. Mas é fundamental que o grupo não seja percebido como ou confundido com um departamento ou time de projeto, estruturas que são responsabilizadas e cobradas por resultados específicos.

Fechando o tópico Negociação, é factível supor que a grande maioria das panelinhas receberá de braços abertos uma oferta como a sugerida acima. Ou seja, a negociação com elas tende a ser fácil e rápida. Os maiores riscos que podem existir referem-se à ambiguidade dos parâmetros ou fragilidade da decisão de formalizar uma comunidade de prática. Se os parâmetros acima foram bem costurados com alta direção e membros da panela, não há o que temer. Resta formalizar.

A Formalização de uma Comunidade de Prática é uma etapa burocrática com valor simbólico. Se uma organização de fato acredita no potencial deste tipo de estrutura para aprender mais e melhor, então ela deve tornar seu apoio explícito. Ao comunicar para todos a iniciativa, a empresa aponta um caminho e uma referência. Na esperança de que outras panelinhas almejem destino semelhante. A boa inveja move montanhas. E talvez a organização descubra várias cumbucas com conteúdo apetitoso e muito relevante em relação aos seus planos e projetos.

Acompanhando uma Comunidade

No início do artigo adiantei a existência de três A’s que devem justificar a existência de uma comunidade de prática e também ajudar a avaliá-la: Aprendizagem Organizacional, Ambiente de Trabalho e Agilidade. Hora de explicá-los.

Conhecimento é um negócio bem difícil de ser medido. Mas o número de vezes que repetimos os mesmos erros não. Uma organização percebe o valor de uma comunidade de prática longe dela, no trabalho cotidiano de seus integrantes. Se eles continuarem batendo cabeça em questões recorrentes ou repetindo erros, é claro sinal de que a comunidade não está funcionando como deveria – ninguém está aprendendo. Na realidade, existem três estágios de evolução que devem ser percebidos:

• Cognitivo: foi gerado conhecimento novo. E houve também um nivelamento de conhecimentos. Uma diferença que poderia ser bastante perceptível no início do grupo tende a ser reduzida drasticamente ao longo do tempo. Difícil fixar um prazo, mas é de se esperar que em doze meses  (48 reuniões ou 192 horas depois) o grupo esteja muito mais homogêneo em termos de conhecimentos (de práticas e métodos conhecidos e exercitados por todos, por exemplo).
• Comportamental: surge um padrão de comportamento positivo. Positivo porque não anula individualidades, mas reforça um denominador comum nos modos de pensar e agir.
• Melhoria do Desempenho: por fim, a organização deve perceber ganhos quantificáveis: qualidade superior do trabalho, prazos respeitados, menor número de reclamações de outras áreas etc.

A organização também deve perceber uma mudança em seu ambiente de trabalho. A comunidade não é um órgão fiscalizador ou repressor. Pelo contrário, é uma estrutura autônoma baseada na conversa franca e aberta entre membros que se autoselecionam. Se dessa cumbuca não brotar um ambiente de trabalho mais agradável, difícil supor o que conseguiria tal feito.

O terceiro A é de Agilidade. Mesmo que se limite a encontros (formais) semanais, espera-se que o conhecimento flua e se espalhe de maneira mais rápida entre os integrantes da comunidade e deles para toda a organização (como normalmente ocorre com uma fofoca ou notícia ruim). Não há pontos de checagem e raramente existirão documentos dando forma para aquele conhecimento. Estamos falando de conhecimento tácito que não nasceu para morrer no papel. Estamos falando de experiência, de saber fazer e saber decidir.

Uma Comunidade de Prática, bem chamada pelo Leandro Mendonça (em comentário) de “Rádio-Peão”, torna-se um grande amplificador e difusor de bons conhecimentos. Pois é, quem diria que panelinhas e rádios-peão virariam peças bem vindas no jogo dos negócios?

∞

Artigos como este que aqui se encerra, teóricos e um tanto genéricos, são necessários. Mas provavelmente deixam em ti a mesma vontade que sinto: de ver o outro lado, o lado prático. Por isso no próximo artigo vou mostrar como funcionariam duas comunidades de prática: uma de Gerentes de Projetos e outra de Analistas de Negócios. Inté!

ps: A “Panelinha” utilizada hoje é do Guilherme Kardel e foi obtida no Flickr.

Artigos relacionados:

1. Panelinhas na Prática
2. Escritórios, Comunidades e Panelinhas
3. Métodos, Ferramentas e Produtos
4. Aplicabilidade
5. Comunidades de Prática

Related posts brought to you by Yet Another Related Posts Plugin.

Somos trabalhadores do conhecimento. De maneira sucinta, meio risível e quase leviana podemos dizer que nosso trampo se limita a adquirir, desenvolver e transferir conhecimentos. Em uma organização é o conhecimento que nos une ou separa. As uniões podem ser temporárias – casamentos e projetos! – ou imunes a deadlines, desquites e processos litigiosos. Separações são concebidas para a eternidade. Até que uma reestruturação (ou recaída) as questione.

Abertura inspirada, não? O tema deste artigo é a forma como organizamos trabalhadores do conhecimento. Trata de maneira mais específica de escritórios (de projetos, de análise de negócios etc) e comunidades de prática. Tese que deve levá-lo até o final do texto ou para outro lugar da Internet neste exato momento: Escritórios são desperdício de tempo e dinheiro (na maioria das organizações).

∞

Caso Real #1

Reunião urgente e não programada. Desenvolvedores, analistas de negócios, arquitetos, gente de infra e outros (diversos) estão reunidos e ansiosos. É fim de tarde de uma sexta-feira de uma semana nada agradável (para variar). Pauta: metodologia. Ou: “a gente não trabalha do jeito que o cara tá ensinando no curso.” Trinta por cento de interessados. Trinta por cento de apressados. Quarenta por cento com ouvidos e olhos em outro lugar. Até que entra o “chefe” do PMO (Project Management Office ou simplesmente Escritório de Projetos). Se coloca na turma dos apressados e determina: “Vamos trabalhar assim [da forma nova] e quem não se encaixar vai para o olho da rua“. Rápido, rasteiro e… desastrado. Fiquei sabendo que ainda sobreviveu alguns meses no cargo.

Caso Real #2

Reunião tranquila porque mais ou menos programada. Gerentes, desenvolvedores, arquitetos, gente de suporte e outros (diversos) estão reunidos e ansiosos. A terça-feira agitada aproxima-se do final e ainda há muito o que fazer – muitos problemas a resolver. Pauta: uma melhor maneira para se lidar com *muitos problemas*. Plateia menor (que do Caso #1) e, talvez por isso, cem por cento interessada. Lá pelas tantas, com a pauta discutida, resolvo matar uma curiosidade: “E o PMO? Por que não está aqui?” Resposta: “Não existe mais… para nosso alívio.”

Interpretação dos Casos

Ambos aconteceram em grandes empresas. Os PMO’s chegaram lá primeiro e, pelo visto, por lá ficaram. Ou tentaram ficar. Claro que os casos acima não servem para ilustrar o “estado atual dos escritórios de projetos”. Muitos ainda existem, e sobrevivem, inclusive naquela empresa do Caso #1. Vou utilizar os casos para colocar algumas questões.

Com pequenas variações, normalmente são aceitas como principais responsabilidades de um escritório de projetos¹:

• Oferecer consultoria em projetos;
• Desenvolver e manter padrões e métodos para o gerenciamento de projetos;
• Treinar gerentes de projetos; e
• Prover gerentes de projetos para a organização.

O escritório de projetos, como indica a bem intencionada lista acima, presta serviços para a organização. Bom, deveria ser assim. Como ilustra o Caso #1, em muitas organizações o PMO se intromete na cadeia de autorizações. Representa um nível hierárquico a mais, exigindo que parte da organização *responda* para ele. Uma nítida inversão das intenções originais. Naquele extremo caso #1, teria até autoridade para mandar alguém “para o olho da rua”.

É fácil rastrear  a origem de tal distorção. Basta ver quem montou os escritórios. Foram os gerentes ou coordenadores de projetos mais experientes. Gente que expandiu a *autoridade* de seus conhecimentos e ganhou o direito de julgar, penalizar ou, no mínimo, exigir “relatórios de status“. Não têm culpa se tal *autoridade* lhes foi formalmente atribuída. Na maioria dos casos que conheço eles foram, vamos dizer, “pró-ativos”. Ninguém pediu, mas também ninguém os proibiu de exercer tamanho domínio. Ao deixar o perfil de servidor (prestador de serviços) em segundo plano os escritórios de projetos ganharam a antipatia que os caracteriza em tantos lugares. Fizeram por merecer. Por isso a turma do caso #2 se sentiu aliviada com a extinção de seu PMO.

Joguemos nesta cumbuca já tão cheia de condimentos mais algumas pimentinhas:

• Quem trabalha em um escritório de projetos não tem tempo para trabalhar nos projetos – raramente coloca a mão na massa. E, quando o faz, é porque o bicho tá pegando. Vou colocar de outra maneira: o PMO não agrega valor real para uma organização. Sua contribuição é sempre indireta, através dos serviços prestados (e/ou dos julgamentos realizados).
• O escritório deve ser formado por gente experiente (leia-se *cara*). É uma tentativa (desesperada?) de fazer com que todo aquele conhecimento se espalhe de maneira homogênea por entre os coordenadores e gerentes menos experientes (leia-se *mais baratos*). Pense nisso: não posso alocar meu melhor gerente de projetos em minha iniciativa mais crítica porque ele está ocupado ensinando (e/ou fiscalizando) os menos experientes (em iniciativas de menor relevância para o negócio).

Escritórios de projetos são uma péssima ideia? Longe disso. Em seu conceito original é uma estrutura fundamental para alguns tipos de empresas e órgãos públicos. O problema está em sua adoção torta e mal concebida por empresas que viram nele um elixir do século XIX, aquele remédio que curava tudo. São as mesmas empresas que já caíram ou ainda vão cair no conto do CMMI, MPS.br e vários outros. Gente que não lê bulas e quase sempre morre de raiva de quem as torna públicas.

Alternativas

A definição de Comunidades de Prática, se não for anterior, é contemporânea dos Escritórios de Projetos². Mas as Comunidades nunca tiveram um apelo “pop”. Provavelmente porque nunca ninguém ganhou muito dinheiro montando ou ajudando a montar uma. Provavelmente porque tal montagem deve ser orgânica e natural (leia-se: é lenta!), ao contrário dos escritórios que podem ser instituídos e financiados com uma simples canetada, literalmente da noite para o dia.

Toda empresa tem várias comunidades de prática não reconhecidas. Aqui no Brasil elas são chamadas de ‘panelinhas’. São aqueles grupos informais de quase-iguais, gente que compartilha interesses e conhecimentos. Suas trocas de experiências (e fofocas e maledicências) ocorrem de maneira não muito programada, ao lado das máquinas de café, nos restaurantes e botecos. As ‘panelinhas’ são auto-organizadas e seus membros se auto-selecionam. Por isso o termo ‘panelinha’ tem um ‘p’ de pejorativo: para quem ficou de fora, uma ‘panelinha’ é sempre um grupo antipático, elitista, segregador. Enfim, uma panelinha.

Acontece que, para quem está dentro, a mesma ‘panelinha’ é um ambiente estimulante, reconfortante e agregador. Seus membros aprendem trocando experiências e contando histórias. Mesmo estando alocados em projetos ou departamentos distintos, quando na ‘panela’ suas experiências e histórias são valiosas. Porque seus interesses são comuns: quem está lá quer, acima de tudo, aprender³.

Uma organização, de qualquer porte ou ramo de atividades, tem muito a ganhar ao reconhecer e apoiar suas ‘panelinhas’. E, quando o fizer, poderá chamá-las de Comunidades de Prática – um termo bem mais aceitável. Não será exigido que, por apoiar uma, a organização seja obrigada a apoiar todas as outras. Uma comunidade que compartilhe interesses em culinária vegana ou sexo tântrico talvez não esteja alinhada com os objetivos estratégicos da empresa. Já uma comunidade de gerenciamento de projetos poderia assumir quase todas as responsabilidades que normalmente são atribuídas ao PMO. Por uma pequena fração do custo este representa.

Uma organização pode identificar as comunidades que mais lhe interessem e negociar sua formalização. Sei que já escrevi sobre o tema aqui no finito. Mas faz tanto tempo (foi lá pelos idos de 2004), que vale a pena uma reescrita. Fiquei particularmente motivado pelo assunto depois que vi sugestões para montagem de “Escritórios de Análise de Negócios”. Antes que a ideia se espalhe como fogo em mato seco, gostaria que considerassem uma alternativa. No próximo artigo falarei especificamente sobre a identificação, negociação e formalização de uma Comunidade de Prática. Depois, se o papo render, farei uma comparação dos Escritórios versus Comunidades de Prática. Inté!

∞

Observações:

1. Lista parcialmente surrupiada de The Project Office (Best Management Practices), de Thomas R. Block e J. Davidson Frame (Crisp Publications, 1998).
   Acabei de visitar a página do livro e acho que ganhei outro argumento (contra os PMO’s). Você sabe que tem alguma coisa *muito* errada com o tema quando se depara com um livro chamado “Business Driven PMO Setup“. Com 528 páginas?!? E você ainda ganha acesso a 150 podcasts? Meu, só falta mandar um bode expiatório como brinde. Com todo respeito… aos bodes!
2. Ao que tudo indica, as Comunidades de Prática apareceram no radar no início da década de 1990. Segundo a Wikipedia, em 1991. Eu acho que Escritórios de Projetos vieram um pouquinho depois, em meados da mesma década. E se espalharam como fogo em mato seco a partir do ano 2000.
3. Por isso as e-Panelinhas, extensões virtuais conhecidas geralmente como Grupos de Discussão, ainda não representam boa alternativa para as organizações. Alguns não estão lá para *aprender* e sim para *aparecer*. Detonam a intenção original e criam um sem número de efeitos colaterais indesejáveis. Talvez eu fale um pouco mais sobre isso em um futuro artigo. Se o estômago deixar.
4. A “Panelinha” que ilustra este artigo é do Felipe Skroski e foi surrupiada legalmente do Flickr.

Artigos relacionados:

1. Formalizando Panelinhas
2. Panelinhas na Prática
3. Extensibilidade das Comunidades de Prática
4. Comunidades de Prática
5. Reflexões

Related posts brought to you by Yet Another Related Posts Plugin.