PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

    Caso tenha perdido, aqui está a primeira parte. A encerrei relacionando quatro impedimentos para a adoção do Scrum na empresa YYZ (nome alterado). Importante lembrar: mais que ao Scrum, são impedimentos para a realização de sete objetivos da área de TI daquela empresa. O Scrum é só (!) um possível meio de atendê-los. Dos quatro ‘bloqueios’, um é mais crítico: os times consomem aproximadamente 80% de seu tempo cuidando de problemas do dia a dia. Como proteger os times? Há uma forma de blindagem minimamente inteligente? Abaixo, o desenrolar do enrolado causo.

    ?

    O impedimento crítico foi apresentado para uma equipe de coordenadores – quase todos os responsáveis pelos onze times que formam aquela unidade de TI. Seguiu-se um debate sobre alternativas de solução – opções de blindagem.

    A primeira, aparentemente bastante simpática aos coordenadores, considerava a alocação de poucos membros (20%) de cada vertical para o atendimento das demandas emergentes / urgentes. Além disso, todos os times dedicariam cerca de 20% de seu tempo para essas questões. Era, com certeza, a alternativa que menor impacto causaria na estrutura atual.

    O diagrama¹ acima destaca duas restrições principais para a sugestão. A primeira é “matemática”: mesmo que destacássemos 20% dos membros do time mais 20% do tempo de toda a equipe para cuidar dos requisitos urgentes, não seria possível atender todas as demandas (lembre-se: elas consomem atualmente 80% do tempo útil de todo o time). A consequência natural seria o acúmulo de demandas não atendidas, seguido do aumento da insatisfação dos usuários e assim por diante. Além disso, há o aspecto cultural que não pode ser negligenciado. Ele foi destacado na primeira parte: a empresa YYZ tem uma (honorável) política de portas abertas. Todo mundo pode falar com todo mundo praticamente a qualquer hora do dia (e da noite!). Fazer com que os usuários falassem apenas com determinados membros e/ou em período pré-determinado vai contra uma cultura estabelecida de longa data.

    A mesma questão cultural aparece como impedimento para a alternativa #2. Nela, conforme sugerido pelo responsável pela área de TI, todas as demandas seriam encaminhadas para a área de help desk. Muitos dirão que já deveria ser assim. De certa forma, é. A área de suporte da YYZ recebe uma média de seis mil (6k!) chamados por mês, 1500 deles relacionados ao ERP. E consegue fechar (bem) algo em torno de 85% deles. O resto? Sobra para as verticais de negócios. E junta-se aos requisitos que os usuários preferem apresentar de maneira direta (em uma mistura de demandas ditas “evolutivas” com simples alterações de telas, pequenos bugs etc). Como adiantei, há a questão cultural: os usuários não podem ser impedidos de se relacionar com as verticais que os espelham em TI. Mas há uma segunda e mais grave restrição para a segunda alternativa. Falta gente. Mais: falta gente qualificada. Cheguei a sugerir o deslocamento de analistas de negócios e desenvolvedores para lá. Propus engolindo. E engoli seco. Ninguém aceitaria um movimento que tinha cara e jeito de “rebaixamento”, por nobre que seja o serviço de suporte. O treinamento de novos integrantes foi cogitado. Mas, como o diagrama tenta indicar, é coisa que toma tempo. Muito tempo.

    Sobrou a terceira alternativa. Aquela que, como consultor, defendi. Partindo do princípio de que a blindagem total dos times é impossível, não resta outra opção que não seja a criação de um novo time. Um time que seja desconhecido pelo negócio e respectivos representantes. Ou seja, além de blindado ele também é invisível². Desta forma as verticais de negócios cuidariam exclusivamente do cotidiano – atendimento aos usuários e solução de pequenos problemas. Seriam também a porta de entrada para as chamadas “demandas evolutivas”. Para tanto, seguiriam contando com pessoal capaz de executar atividades de análise de negócios. Talvez um pouco mais que isso. O coordenador de cada área poderia vir a ser um Dono do Produto (Product Owner ou simplesmente PO, como queira). Eu sei, eu não curto muito esse papo de dublê de PO. Mas, neste caso, dado o invejável conhecimento do negócio que cada coordenador apresenta, os riscos inerentes ao desenho eram consideravelmente reduzidos. E haveria outro benefício: o novo time seguiria de fato invisível. Mas, quem integraria o novo time?

    Você se lembra que os coordenadores estavam dispostos a “sacrificar” 20% de seu time para cuidar exclusivamente das demandas não previstas? Bom, se pegarmos 20% de cada uma das sete verticais de negócios (que têm, em média, 8 integrantes) mais o time de controle de qualidade (pelo menos 60% dele – seis profissionais) temos uma nova composição com cerca de 17 pessoas. Praticamente 3,5 times de Scrum (considerando o tamanho ideal sugerido: 5 (+/- 2)). Claro, este time seria multidisciplinar, auto-organizado, dono de seus processos e, o mais importante, orientado por um e apenas um Product Backlog. Quase sem querer (querendo!) já atendemos o objetivo #1 da lista que foi apresentada na primeira parte: “Ter uma fila única de demandas”. Dois coelhos, talvez alguns mais, numa única porretada. Parecia tudo muito bom para ser verdade. Quais restrições para esta alternativa foram apresentadas?

    “Esse time não teria real domínio do negócio”, disseram alguns. Oras, para isso existem os PO’s e seus asseclas (analistas de negócios e afins), certo? Além disso, o novo time é formado por gente que já tem, em média, três anos de casa. E são provenientes de todas as verticais de negócios, o que representa um certo conhecimento e visão do todo. Sinceramente, isso não é restrição que se apresente. Porque ela não para em pé. Então, uma segunda restrição – aparentemente mais forte – foi colocada: “O <nome_do_responsável_por_ti> não quer que demandas evolutivas sejam separadas das corretivas”; “Além disso, o <nome_do_responsável_por_ti> não permite em hipótese nenhuma que duas equipes trabalhem nos mesmos artefatos“. Quantos traumas, quantas noites mal dormidas e quantos sistemas bisonhos de controle de versões são necessários para criar restrições tão… sei lá. Prefiro não adjetivar. Assim como preferi não gastar meu tempo com um estudo antropológico daquelas raízes pré-históricas. Me limitei a lembrar Peter Senge: “Os problemas de hoje vêm das soluções de ontem.”

    Percebi que não se tratava apenas de restrições do <nome_do_responsável_por_ti>. Os próprios coordenadores não gostaram nadinha da ideia de um novo time. Um time que provavelmente viveria sem a figura de um coordenador e que ficaria com o filé, enquanto eles seguiriam com o feijão com arroz do cotidiano. A antipatia deles pela sugestão é perfeitamente compreensível. Mas não é justificável.

    Faltou a eles enxergar um pouquinho além e entender que este desenho, como todos os outros, é temporário. Não entenderam que o novo time seria um “super” prestador de serviços para eles. E faltou acreditar que, com o tempo, o novo time poderia ser gradativamente incorporado às suas unidades. E que isso seria possível tão logo o tempo de resposta fosse reduzido para prazos que excedessem minimamente as expectativas dos usuários; o que os levaria para a fixação de acordos de níveis de serviços (objetivo #4 da lista original). Antes que você me chame de ingênuo e/ou simplório: resumi veredito e consequências.
    {Mas, caso queira explorar um pouco mais esta parte, por favor, comente! Acho que o assunto é bom demais para morrer aqui, só com minhas palavras.}

    Algumas Referências para a Alternativa #3

    Pois é, o artigo está ficando mais longo que o usual. Mas não quero fazê-la(o) esperar por uma terceira parte. Conto com mais um pouco de sua atenção.

    Já tem um bom tempo, creio que quatro ou cinco anos, que li um artigo sobre uma grande mudança que estava acontecendo na Promon. Eles estavam “duplicando” várias gerências. Uma cuidaria do dia a dia. A outra, nova, trabalharia apenas no “amanhã”. Me apaixonei pela ideia mas, infelizmente, não vi mais nada a respeito. Sei lá se foi mantida, muito menos o que conseguiram. Temo que, por considerar apenas os gerentes, a coisa não tenha vingado.

    Mais recentemente começaram a pipocar artigos e teses sobre “organizações ambidestras“. Apesar de algumas interpretações meio tortas e rebuscadas, a proposta central parece ser a mesma: separar o presente do futuro. E fazer com que as organizações trabalhem nas duas frentes com a mesma atenção e dedicação. Não necessariamente com o mesmo volume de recursos. Mas, desejavelmente, com princípios e processos em comum.

    Sinceramente, não vejo alternativa que não passe por uma divisão assim. O problema com esse tipo de mudança é que ela é drástica. O que significa dizer que a resistência a ela será igualmente forte. Pensando Scrum ou, mais precisamente, pensando Lean, não estamos mais falando de Kaizen (melhoria contínua) e sim de Kaikaku (mudança radical). E o que é necessário para a implementação de uma mudança radical? Coragem; sangue frio; apoio dos altos escalões; comprometimento com a solução… A lista é longa e não é estranha para você que conhece mudanças. Por isso vou tocar em um ponto relativamente incomum: quem promove uma mudança radical não alimenta a ilusão de que não haverão “mortos” e feridos. Muitos pularão do barco. E isso não é necessariamente ruim.
    {Está aqui outro ponto que podemos discutir bastante, não?}

    Epílogo

    Se você respeita o jeito Lean de pensar, então sabe que não pode tratar problemas (impedimentos ou bloqueios) com remendos rápidos e muito menos fazer vista grossa para eles. Você deve, literalmente, “parar a linha”, analisar as raízes do problema, encontrar e implantar uma solução para ele. Foi o que aconteceu com este serviço de consultoria. Interrompemos o processo, eu parei meu “relógio”, apresentei e propus discussões sobre os impedimentos. Um mês. Dois meses. Três meses…

    Fiquei sabendo que o <nome_do_responsável_por_ti> foi transferido para outro negócio da YYZ. Não sei dizer se as restrições que ele defendia permaneceram. Creio que não. Mesmo assim, não acredito que minha sugestão tenha uma nova chance. É assim mesmo: quantas vezes já fomos aconselhados a ter uma vida mais saudável, menos sedentária, mais preocupada com o amanhã? E quantas vezes seguimos os conselhos? São poucos os consultores, pais, esposas, médicos e afins que são de fato escutados. Menor ainda é o número dos que recebem prêmios milionários por seu poder de persuasão e objetivos alcançados.

    ?

    Observações:
    1. Não julgue o “diagrama” rabiscado, please! É só um resumo da apresentação das três alternativas e respectivas restrições. E, sim, é um Causal Loop Diagram (Diagrama de Círculos Causais). Caso você não conheça, a “o” (bolinha) ao lado de uma linha significa força (ou feedback) contrário (ou negativo). O “c” significa uma restrição (ou constraint). É uma ferramentinha que, pelo visto, está ganhando novo impulso. Na última segunda vi Jurgen Appelo utilizá-la para mostrar como esse negócio de desenvolver software é “doomed”. Mas pode ser salvo! Craig Larman também usou e abusou dela em seu último livro, “Scaling Lean & Agile Development” (Addison-Wesley, 2009).
    2. O aspecto “invisível” (do novo time) é desejável neste caso específico. Não o indicaria em ambientes que não tenham uma política tão aberta e generosa de “relacionamentos muitos-para-muitos 24×7”. Insisto, na YYZ o time só estaria 100% blindado se fosse “invisível”.
    3. “Trainee hatchings” é o título do cartoon de hoje. Como sempre, foi surrupiado do HikingArtist.
    4. Aquele xampu segue me provocando com o seu “Sistema de Blindagem Inteligente”.
  • Sistema de Blindagem Inteligente, Parte I

    Sistema de Blindagem Inteligente, Parte I

    Não é piada: o “sistema” que dá nome a este post aparece em uma embalagem de xampu. E me incomoda, a cada banho, há algumas semanas. Até xampu consegue fazer uma blindagem inteligente! Então por que seria tão difícil para algumas organizações isolar e proteger, ou seja, blindar um time de projetos? A questão passou a me atazanar com mais frequência depois que publiquei uma breve compilação sobre problemas mais comuns na adoção do Scrum. Aquele artigo passou batido pelo problema. Tentarei corrigi-lo agora. E vou fazê-lo através de um causo real minimamente maquiado por razões óbvias¹.

    ?

    A empresa YYZ, um imenso conglomerado com presença global, desenvolveu seu próprio ERP. Lá se vão anos desde que aquele imenso monolito viu a luz. Ele fora concebido para cuidar do núcleo do negócio e, claro, das finanças. Com o passar do tempo, ganhou inúmeras novas responsabilidades, da produção até a logística de armazenamento e entrega passando por tudo o que é possível existir entre estes polos. Ou, melhor dizendo, quase tudo. Não se aventurou a cuidar do RH, por exemplo. Apenas um detalhe. O fato é que o ERP, cimentado firmemente em um desenho Cliente/Servidor (de duas camadas e milhares de Stored Procedures), é grande. Quase imensurável.

    São onze os times que cuidam da manutenção e evolução do sistema. Sete deles cuidam de verticais específicas, como Vendas, Administração e Produção, por exemplo. Os outros quatro “prestam serviços” para eles. Bem, para dizer a verdade, eles não são vistos assim na maior parte do tempo. Um deles é o Controle de Qualidade. E não é tão comum assim ver este “departamento” sendo percebido ou se apresentando como um “Prestador de Serviços”. A verdade é que ninguém lá dentro precisava de um consultor para informar que a qualidade e seu respectivo controle deveriam ser incorporados aos times. Acho que apenas a própria área de qualidade. Consultor? Retomemos o causo.

    “Paulo, você nos ajuda a implantar o Scrum?” Claro, por que não? Mas, diga aí, por quê? Ops… perguntinha maldita, não? Alguns meses se passaram até que a contratação fosse fechada e, mais importante, até que a perguntinha maledeta fosse respondida:

    1. Ter uma fila única de demandas
    2. Saber o esforço que cada demanda consumiu
    3. Reduzir o tempo de entrega
    4. Fechar acordos de níveis de serviços (SLA) com áreas usuárias
    5. Tornar as demandas visíveis para as áreas usuárias
    6. Ter tempo para o planejamento estratégico
    7. Medir o desempenho dos integrantes das equipes

    Rabisquei o diagrama acima para determinar uma sequência de trabalho. Conclui que a realização do item 3, a redução do tempo de entrega, favoreceria a satisfação de todos os outros requisitos. E que o fechamento de SLA’s (item 4) só seria possível depois que todos os outros objetivos fossem minimamente atingidos. Portanto, o próximo passo era descobrir a razão das entregas serem tão demoradas (60 dias, em média, entre o registro da demanda e sua entrega definitiva para os usuários).

    Não nos custou um dia o diagnóstico dos quatro principais fatores que retardavam as entregas:

    • As especificações, elaboradas por analistas de negócios, são muito extensas (e de pouca ou nenhuma utilidade após as entregas);
    • A área de qualidade só sabe que algo é prioritário quando ouve gritos. No mais, administra uma fila que mistura tudo das sete verticais de negócios. E tem pouca gente para tanto trabalho, apesar de não cobrir 20% dos tipos de testes possíveis;
    • Dada a complexidade da distribuição – várias unidades espalhadas geograficamente – é compilada e entregue apenas uma “versão” por mês; e
    • Os desenvolvedores são atropelados diariamente por problemas, de bugs até o mal entendimento de determinadas funcionalidades pelos usuários, passando pelo que é mais grave: novas demandas urgentes.

    Me sinto à vontade para descrever o causo principalmente porque sei que os quatro problemas acima podem apontar para um sem número de empresas ao redor do globo. Não há nada de particular aqui, o que pode tornar este artigo realmente útil. Voltando para a história.

    Seria relativamente fácil solucionar os três primeiros problemas. Existe um padrão único para especificação de demandas. Requisitos imensos e minúsculos recebem o mesmo tratamento (burocrático), o que não faz sentido. Mais: toda a análise de impacto e definição do “como” (protótipos de telas, lista de alterações nos bancos de dados etc) é realizado pelos analistas de negócios, o que torna a vida dos desenvolvedores um sossego (e uma chatice só). Qualidade, o segundo problema, deveria ser incorporada (de fato e de direito) pelas verticais de negócios. Que deveriam ganhar também autonomia em relação a atualização de versões. Apesar do jeitão monolítico do ERP, vimos que era perfeitamente possível gerar mais de uma versão por mês. Daí a estimar (salivando) que seria possível uma redução de 60 para 15 dias do tempo médio de entregas foi um pulinho. Ingênuo pulinho.

    O quarto problema – o atropelo das verticais de negócios por questões do dia a dia – se apresentou monstruoso logo no primeiro dia da experiência com o Scrum. A empresa YYZ tem uma bela política de “portas abertas” para todos. Aliás, mal existem portas (e paredes). O que gera um efeito dramático na área de TI: usuários aparecem a qualquer momento com seus choramingos e requisitos. E não atendê-los está fora de questão.

    “Oras, Paulo, parece que fazes tormenta numa pequena caneca d’água! Não bastaria separar alguém do time ou parte do tempo de todo o time para o atendimento das demandas imprevisíveis?” Como, respondo perguntando, em um cenário onde elas consomem cerca de 80% do tempo útil de toda a equipe?

    O papo segue na parte II. Inté!

    ?

    Observações:

    1. Não revelo a identidade de meus clientes de consultoria exatamente para ter a liberdade de tratá-los como causos, aqui no {finito} e em meus cursos e palestras.
    2. Não, o xampu com “Sistema de Blindagem Inteligente” não é meu, ok?
    3. “getting away from it all” é outro cartoon que surrupio do HikingArtist.com

     

  • GESTÃO* na Berlinda

    GESTÃO* na Berlinda

    Antes que eu perca a última oportunidade de escrever alguma coisa em julho. Antes que reclamem que há tempo não coloco nada de novo em  nossa Biblioteca. E antes que a leitura dos livros abaixo me faça abandonar tudo e iniciar nova carreira, provavelmente cultivando milho orgânico e produzindo pamonhas, pamonhas, pamonhas…

    ?

    Um bom título alternativo para este artigo seria “Crise nas Infinitas Terras“. Porque o que vemos hoje, entre terras Exatas e Humanas, são crises que parecem não ter fim. “Infinitas Crises em nosso Mundinho” soaria melhor. Não importa. O que incomoda, ou deveria incomodar, é perceber que Economia, Administração, TI e vários outros “campos ou corpos de conhecimentos” passam por maus bocados. Arrisco dizer, com mínimo domínio de causa, que se trata de uma crise de meia idade. Não pretendo me aventurar pelo estranha situação da economia mundial. E, pelo menos nesta entrada, TI não interessa. Quero falar – na realidade, apresentar trabalhos que falam sobre a (triste porém estimulante) situação atual daquilo que conhecemos como GESTÃO (ou MANAGEMENT*).

    Um Livro Bom, Pequeno e Acessível sobre Estudos Organizacionais (2ª Edição) – Chris Grey (com ótima tradução de Raul Rubenich). Bookman (2010).

    Chris é professor de Comportamento Organizacional na Warwick Business School e resolveu, no início deste século (com a 1ª edição deste livro), jogar m… nos ventiladores do campo dos Estudos Organizacionais e da área que conhecemos como Administração. Jogou m…. com estilo, diga-se de passagem, com uma prosa limpa e livre de academicismos. Apesar de (ou justamente por) seu livro mirar, principalmente, os estudantes. Acho que consigo resumir sua “tese” através de um trecho surrupiado da página 65:

    “… a ideia de uma organização burocrática – ou de qualquer outro tipo de organização – voltada simplesmente ao estabelecimento de meios apropriados para atingir determinados fins é fundamental, irremediável e irrevogavelmente defeituosa.”

    Não espere explicações simples. Muito menos sugestões “aplicáveis”. Chris e poucos outros (dois deles apresentados abaixo) anunciam o início do fim reconhecendo humildemente sua incapacidade de desenhar o que viria depois. Conte, isso sim, com um livro bom, pequeno e acessível que: i) mostra zelo pela história da Administração, passando por Weber e Taylor até chegar em Tom Peters, autor (segundo Chris e para meu deleite) de um livro horrível (In Search of Excellence) “para jovenzinhos” (Drucker); ii) tem a imensa coragem de desafiar não um ou outro aspecto do ensino da administração, mas todo ele! (“O ensino da administração é movido para a produção do conformismo. Os imperativos da eficiência, da competição, das relações de mercado, etc. levam à conclusão de que as organizações têm, por necessidade, de manter-se da forma como se apresentam atualmente.”); e iii) dará um certo alívio para todos aqueles que, apesar dos estudos, diplomas e dedicação, seguem aturdidos (quando não perdidos) em seus esforços de GESTÃO e Administração. Alívio? Sim, porque apesar da infinidade de m… atirada ao vento, Chris é otimista: “Parece-me perfeitamente possível que o gerente ou candidato a gerente possa se preocupar com algo mais do que a racionalidade instrumental.”

    Management NÃO É o que Você Pensa – Henry Mintzberg, Bruce Ahlstrand e Joseph Lampel. Bookman (2011).

    Tema e preocupação idênticos – forma totalmente diferente do livro acima. O trio fez uma compilação de artigos, provocações e “máximas” que tenta (e consegue) mostrar que GESTÃO não é o que costumamos pensar. Livro conciso (150 págs.) e eficaz na mira do ventilador. Tanto que, apesar dos destaques que saltam em praticamente todas as páginas, pérolas brotam dos curtos textos. Como, por exemplo, a colocação de que as superstições são diretamente proporcionais as incertezas. E de que elas, as superstições,  “são o veículo pelo qual líderes carismáticos infundem sentimentos de certeza em tempos de incerteza.”

    Os autores (compiladores?) foram felizes na organização dos recortes em sete capítulos, além do “Mosaico” introdutório. Foi particularmente curioso ler um artigo que pareceu muito atual (“O que a Gestão Diz e o que os Gestores Fazem”, de Albert Shapero) e descobrir depois que se tratava de um texto publicado originalmente em 1976 na revista Fortune. Saca só:

    “Mais cedo ou mais tarde, a estranha cultura da GESTÃO baterá em retirada. A cada dia, centenas de milhares de gestores dedicam sua imensa boa vontade e aptidões naturais a compreender o enorme fosso existente entre a GESTÃO e a caótica realidade da vida cotidiana.”

    Mintzberg é conhecido, além de seus tratados sobre estratégia e outros temas, pelas suas críticas ao ensino de Administração e GESTÃO. O livro inclui seu famoso artigo “MBA?, Não, Obrigado!”. É preciso dizer que o livro acaba funcionando como uma bela propaganda  de seu “programa para desenvolvimento de gestores” conhecido como “Coaching Ourselves”. A propaganda (literalmente embutida na forma de um prospecto) não compromete.

    Management 3.0 – Jurgen Appelo. Addison-Wesley (2011).

    Ok, peço desculpas. Trata-se de uma entrada duplicada em nossa Biblioteca. Em fevereiro dediquei generosa resenha ao trabalho do Jurgen. Acontece que tenho duas boas justificativas para a redundância. A primeira, claro, é o fato deste livro ter tudo a ver com os outros dois apresentados acima. Mas, dos três, é o mais Construtivo (acho que deveria dizer “propositivo”). Jurgen apresenta sugestões organizadas em seis visões, todas amparadas em avaliações que reforçam as críticas descritas nos dois livros acima.

    Ok, o subtítulo desta obra promete a “Liderança de Desenvolvedores Ágeis” e o “Desenvolvimento de Líderes Ágeis”. Talvez eu não tenha sido tão claro naquela resenha, mas engana-se quem acha que se trata de um livro dedicado exclusivamente ao Gerenciamento de Organizações que desenvolvem sistemas. Sim, enganou-se o editor e aquele que bolou a chamada da capa. Paciência. Leia com a mente um pouquinho aberta e você perceberá um livro que fala de GESTÃO para organizações do século XXI. Propondo um modelo “errado”, como reconhece Jurgen. Porque, afinal, TODOS estão errados. “Mas alguns são úteis!”.

    Segunda justificativa para o repeteco: Jurgen Appelo estará no Brasil agora em agosto. Vai ministrar um treinamento na AdaptWorks e, graças aos esforços do grupo Rio Agile, apresentará uma palestra na Cidade Maravilhosa no dia 22/agosto. Trata-se de uma oportunidade única de conhecer as ideias deste cara que já é um dos mais requisitados palestrantes e instrutores do Mundo Ágil. Lembrando: não faça deste rótulo (“Ágil”) uma caixinha. E tente fazer o possível para assistir este evento único.

    ?

    Observações:

    • Grafei GESTÃO assim colando Mintzberg. Parece contraditório, mas apela para uma GESTÃO de fato maiúscula. E mantive o termo ciente de que alguns colegas preferem que “Management” seja traduzido como “Gerenciamento” ou “Administração”.
    • “Crisis!“, a imagem utilizada neste artigo, é de autoria de Richard “dipfan”.
    • Milho orgânico? Pamonhas?!? Perdão, apelação idiota. O que estas obras conseguiram de verdade foi me dar novos ânimo e horizontes. Torço para que façam o mesmo por ti. Inté!
  • Os Arquitetos (de Negócios) estão Chegando

    Os Arquitetos (de Negócios) estão Chegando

    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 com o conhecimento que eles vão precisar para fazer boas escolhas “. 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.

     

  • Maré Alta no Pantanal

    Maré Alta no Pantanal

    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.
  • Por que Precisa ser Feito?

    Por que Precisa ser Feito?

    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.
  • Lean Architecture

    Lean Architecture

    Autores: James O. Coplien e Gertrud Bjørnvig. Gertrud tem mais de 20 anos de experiência em desenvolvimento de sistemas e é especialista em requisitos Ágeis. James é pioneiro em projetos OO, padrões de arquitetura e desenvolvimento Ágil de software. É autor, dentre outros títulos, de “Organizational Patterns of Agile Software Development” (Prentice-Hall, 2004).

    Editora: Wiley (2010).

    Site: LeanSoftwareArchitecture.com

    Do que se trata: Arquitetura de Software, pensada e construída segundo princípios Lean e Agile.

    Indicado para: Arquitetos, Desenvolvedores e afins. Sim, eu entrei de gaiato no navio (porque há tempos não arquiteto nem programo). Mas gostei do que vi, como testemunho abaixo.

    Contra-indicações: Quem não conhecer o mínimo de OO, arquitetura de software e que tais sentirá uma certa dificuldade. Quem acha que arquitetura é burocracia, BDUF ou conversa pra boi dormir terá dois tipos de reação: espanto (positivo) ou um notável desconforto. Indiferente, acho que ninguém fica.

    Breve resenha: Eu não pego um livro (técnico) que não fale sobre o que precisa ser feito e/ou gerenciamento desde os idos de 2005 e 2006, quando cismei de estudar e falar sobre SOA, Reuso e afins. Acontece que o choque do livro anterior, “Management 3.0“, foi forte demais. Vai demorar para outro livro sobre o tema me abalar tanto. Resolvi mudar de assunto. E decidi que era hora de ver o que o “outro lado” anda fazendo. Não pesquisei muito até decidir pelo livro do Coplien e da Gertrud. Mesmo sabendo que encontraria linhas de código (em Java, C++, Ruby e outras) e conceitos que talvez fossem grandes demais para minha cabecinha.

    O que me chamou a atenção foi exatamente a presença da Gertrud como co-autora, dada sua especialização em requisitos. Desconfiei que não seria um livro tradicional sobre arquitetura de software. E estava certo. Vou arriscar um resumo em um parágrafo:

    Se você é verdadeiramente Ágil, a arquitetura projetada por ti deve saber acomodar mudanças. Não só em tempo de projeto, mas durante todo o ciclo de vida de um sistema. Para tal, desde o início você deve saber distinguir coisas que mudam com menos frequência daquelas que mudam ‘quase todo dia’. Os autores sugerem uma divisão bem simples: O-que-o-Sistema-É é uma parte mais estável, é a forma – o pensamento do usuário; O-que-o-Sistema-Faz é a porção mais dinâmica, mais suscetível a mudanças, é o comportamento – a ação do usuário. O respeito pelo ‘modelo mental do usuário’ e a preocupação em fazer com que todos os elementos da arquitetura sejam representações fiéis deste modelo guiam todo o livro. Os letrados a antenados já devem ter desconfiado que esse papo todo desemboca no uso dos padrões MVC-U (Model-View-Controller-User. Não se incomode, é o mesmo velho MVC demonstrando simpatia pela parte mais importante do problema) e seu novo complemento chamado DCI (Data, Context and Interaction), duas crias de Trygve Reenskaug.

    Resumo dado, tempo para outras considerações. Sim, esse papo de “representação fiel do modelo mental do usuário” rola, sem muito sucesso, desde a segunda metade da década de 1960 (quando surgiu OO). E sim, letrados e antenados não devem ver muito valor no livro. Como eles não são tantos assim, como atestam as aplicações que vemos por aí, o livro deve atrair um bom público. O público nerd, tratado exatamente desta maneira no texto, deve se satisfazer com as dezenas de páginas (de um total de 357) com puro código. Além de três capítulos nomeados “Coding it Up …”, o livro dispõe de seis apêndices tratando um mesmo exemplo em Scala, Python, C#, Ruby, Qi4j (segundo os autores, a melhor forma de implementar DCI em Java) e Squeak. E, como já coloquei, C++ e Java não são ignoradas. Se eu curti esse tanto de código? Olha, deu pra lembrar porque não programo mais. Mas, o código é bonito, elegante.

    Aliás, a proposta como um todo é bonita (e ver Beleza em coisas assim é atestado inconteste de que um pouco de sangue nerd ainda corre nestas veias). Sempre avalio uma sugestão de arquitetura através da tríade vitruviana: firmitas (robustez), venustas (beleza) e utilitas (utilidade / funcionalidade). Os autores, pelo menos na teoria, passam no teste do Vitruvius. E insistem em nos lembrar, pelo menos uma dúzia de vezes, a Lei de Conway.

    Para a turma d’o que precisa ser feito: Além do primeiro capítulo, uma Introdução, outros quatro ‘falam’ com a turma do negócio, analistas, donos de produtos e afins. São eles: “3 – Stakeholder Engagement“, “4 – Problem Definition“, “5 – What the System Is, Part I: Lean Architecture” e “7 – What the System Does: System Functionality“. Vou destacar os pontos que mais me chamaram a atenção.

    Gostei muito da separação incondicional de o-que-o-sistema-É de o-que-o-sistema-FAZ. Quando estudamos um negócio, também devemos ter esse tipo de preocupação. Separamos a Visão da Estrutura da Visão dos Processos, cientes da maior complexidade e volatilidade da segunda. Costumo dizer em meus treinamentos que a Visão dos Processos ocupará, no mínimo, 70% do tempo de um analista de negócios. Acontece que a aplicação tradicional ou indisciplinada de conceitos OO, em determinado momento, mistura tudo. Através do padrão DCI essa separação é sempre respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto é uma representação fiel de… um Caso de Uso!

    Qual não foi minha surpresa quando vi os autores ‘ressuscitando’ as Especificações de Casos de Uso. Segundo eles, de forma bem direta, o mundo Ágil reinventou a roda com as Histórias de Usuários e todos os seus ‘complementos’ (Mapas de Histórias, Dependências, Restrições, Test Cases etc). Casos de Uso oferecem, segundo os autores, consolidação de todas as informações necessárias para a construção d’o-que-o-sistema-FAZ. Há muito em comum entre a sugestão do livro e o modelo de casos de uso que aplico. Por exemplo: “O Fluxo Principal não deve ter mais que 7 passos!”; “Questões sobre interface do usuário e projeto do sistema são melhor representadas em outras ferramentas, não em casos de uso“. E por aí vai. E vai tão longe que merecerá um artigo específico.

    Por ora, fica minha curiosidade em saber como os desenvolvedores tupiniquins estão vendo a proposta. Fiz uma breve pesquisa no Google e em alguns grupos de discussão e não vi uma única menção ao termo DCI. Como a comunidade Ruby só faz crescer por aqui, pensei que acharia algo. Mas talvez eu não tenha procurado direito. Lá fora as reações são variadas e algumas bem iradas, como mostra esta thread. Aliás, estou para ver o dia em que novas ideias de nossa área não virarão um Fla X Flu.

    Enfim, duas coisinhas que me incomodaram: i) Não há um único diagrama UML no livro. Mesmo que os autores defendam fervorosamente a ‘modelagem com código’, deveriam entender que um ou outro diagraminha poderia facilitar a compreensão de alguns conceitos; ii) SOA morreu? Sinceramente, não esperava ler um livro sobre arquitetura de software escrito em 2010 que praticamente passa em branco pelo assunto. Os autores até justificaram no início do livro a ausência, mas não foram muito convincentes. Ou, de fato, SOA morreu?

  • Panelinhas na Prática

    Panelinhas na Prática

    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.
  • Formalizando Panelinhas

    Formalizando Panelinhas

    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.

  • Escritórios, Comunidades e Panelinhas

    Escritórios, Comunidades e Panelinhas

    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 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.