PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Gerenciamento de Projetos

  • Para Trabalhar

    Para Trabalhar

    O artigo anterior mostrou a escalada dos dados até a sabedoria, passando por informações, conhecimento e compreensão. Hoje subiremos em outra escada, das ferramentas até as metodologias. São novas entradas em nosso glossário comentado. Definições e redefinições necessárias em tempos de muita confusão.O gancho para este artigo apareceu na definição de conhecimento – “a capacidade de agir”. Se com informações respondemos as questões o que, quem, quando, onde e quanto, é com conhecimento que respondemos como (know-how). Para a realização de um trabalho qualquer, basta saber como executá-lo?

    Você seguiu passo a passo a receita daquele prato fantástico. Ficou tão gostoso quanto o da sua avó? João pensa ter executado os mesmos movimentos clássicos de Leônidas e Pelé. Fez o gol de bicicleta? Maria tentou se lembrar de todas perguntas essenciais ao desenvolver alguns requisitos. Os engenheiros entenderam o que ela quis dizer?

    Pois é, entre a teoria e a prática – dependendo do trabalho – pode haver um abismo. E não existem atalhos. Só praticando, errando, aprendendo e repetindo tudo de novo é que desenvolvemos habilidades.

    Inventamos ferramentas para facilitar os trabalhos. Podemos contar a nossa história através delas. Um dia tivemos pedras lascadas. Hoje carregamos smartphones repletos de apps. Existem ferramentas físicas (martelo, carro, liquidificador) e ferramentas conceituais (matemática, lógica e teoria da informação, por exemplo).

    Quando falamos sobre técnica, nos referimos ao modo de realizar um trabalho e/ou utilizar determinada ferramenta.

    Um método é um guia que nos ajuda a selecionar ferramentas e técnicas. Neste ponto nós bagunçamos bastante o coreto. Passamos a falar de processos, frameworks, metodologias e métodos como se esses termos fossem intercambiáveis.

    Processo pressupõe repetição: mesmas entradas, mesmo trabalho, mesmas saídas. Confundi-lo com projetos não cai bem. Porque cada projeto, por definição, é único: tem entradas, trabalho e saídas diferentes. “Processos são à prova de idiotas“, escreveu Dave Gray¹. Alguém tomou todas as decisões antes; Seu executor está dispensado de pensar. Ainda não inventamos uma maneira de abrir mão de cérebros em um projeto. Por isso, para estes, faz mais sentido falar em método – guia. 

    Framework, algo como “modelo de trabalho”, deveria ir para o mesmo balaio dos offs, sale, black fridays, stakeholders, ideation, elicitation, embromation e afins.

    Chegamos, enfim, em metodologia. Uma metodologia traduz para a prática uma teoria. Toda metodologia parte de princípios. E orienta a seleção de métodos de trabalho. Metodologia também significa o estudo dos métodos. Por definição, ela sempre propõe melhorias. Deveria…

    Resumindo: uma metodologia nos ajuda a escolher métodos. Métodos guiam a seleção de ferramentas e técnicas. Ferramentas, quando utilizadas com a devida técnica, nos ajudam a realizar um trabalho de forma produtiva.

    O trabalhador do século 21 é um atencioso curador e colecionador de métodos e ferramentas. Mas não se limita a utilizá-los. Ele também os combina, altera e até inventa novos. Quando chega nesse nível, nem o céu é um limite.

    “O bom trabalhador é conhecido pelas suas ferramentas.”
    – Provérbio

    Notas

    1. A Empresa Conectada, p. 201 (Novatec, 2013).
    2. Russell Ackoff é a fonte do texto acima, pra variar.
    3. Stairway to Heaven é o título da inspirada imagem de hoje. Por svenwerk, no flickr.
      Ooh, it makes me wonder…
  • Para Trabalhar

    Para Trabalhar

    O artigo anterior mostrou a escalada dos dados até a sabedoria, passando por informações, conhecimento e compreensão. Hoje subiremos em outra escada, das ferramentas até as metodologias. São novas entradas em nosso glossário comentado. Definições e redefinições necessárias em tempos de muita confusão.O gancho para este artigo apareceu na definição de conhecimento – “a capacidade de agir”. Se com informações respondemos as questões o que, quem, quando, onde e quanto, é com conhecimento que respondemos como (know-how). Para a realização de um trabalho qualquer, basta saber como executá-lo?

    Você seguiu passo a passo a receita daquele prato fantástico. Ficou tão gostoso quanto o da sua avó? João pensa ter executado os mesmos movimentos clássicos de Leônidas e Pelé. Fez o gol de bicicleta? Maria tentou se lembrar de todas perguntas essenciais ao desenvolver alguns requisitos. Os engenheiros entenderam o que ela quis dizer?

    Pois é, entre a teoria e a prática – dependendo do trabalho – pode haver um abismo. E não existem atalhos. Só praticando, errando, aprendendo e repetindo tudo de novo é que desenvolvemos habilidades.

    Inventamos ferramentas para facilitar os trabalhos. Podemos contar a nossa história através delas. Um dia tivemos pedras lascadas. Hoje carregamos smartphones repletos de apps. Existem ferramentas físicas (martelo, carro, liquidificador) e ferramentas conceituais (matemática, lógica e teoria da informação, por exemplo).

    Quando falamos sobre técnica, nos referimos ao modo de realizar um trabalho e/ou utilizar determinada ferramenta.

    Um método é um guia que nos ajuda a selecionar ferramentas e técnicas. Neste ponto nós bagunçamos bastante o coreto. Passamos a falar de processos, frameworks, metodologias e métodos como se esses termos fossem intercambiáveis.

    Processo pressupõe repetição: mesmas entradas, mesmo trabalho, mesmas saídas. Confundi-lo com projetos não cai bem. Porque cada projeto, por definição, é único: tem entradas, trabalho e saídas diferentes. “Processos são à prova de idiotas“, escreveu Dave Gray¹. Alguém tomou todas as decisões antes; Seu executor está dispensado de pensar. Ainda não inventamos uma maneira de abrir mão de cérebros em um projeto. Por isso, para estes, faz mais sentido falar em método – guia. 

    Framework, algo como “modelo de trabalho”, deveria ir para o mesmo balaio dos offs, sale, black fridays, stakeholders, ideation, elicitation, embromation e afins.

    Chegamos, enfim, em metodologia. Uma metodologia traduz para a prática uma teoria. Toda metodologia parte de princípios. E orienta a seleção de métodos de trabalho. Metodologia também significa o estudo dos métodos. Por definição, ela sempre propõe melhorias. Deveria…

    Resumindo: uma metodologia nos ajuda a escolher métodos. Métodos guiam a seleção de ferramentas e técnicas. Ferramentas, quando utilizadas com a devida técnica, nos ajudam a realizar um trabalho de forma produtiva.

    O trabalhador do século 21 é um atencioso curador e colecionador de métodos e ferramentas. Mas não se limita a utilizá-los. Ele também os combina, altera e até inventa novos. Quando chega nesse nível, nem o céu é um limite.

    “O bom trabalhador é conhecido pelas suas ferramentas.”
    – Provérbio

    Notas

    1. A Empresa Conectada, p. 201 (Novatec, 2013).
    2. Russell Ackoff é a fonte do texto acima, pra variar.
    3. Stairway to Heaven é o título da inspirada imagem de hoje. Por svenwerk, no flickr.
      Ooh, it makes me wonder…
  • Peopleware

    Peopleware

    Outro Clássico com “C” maiúsculo que há tempos pede entrada em nossa biblioteca. Escrito por Tom DeMarco e Timothy Lister, mereceu duas edições, ambas publicadas pela Dorset House. A primeira em 1987. A segunda, com oito capítulos adicionais, em 1999. Salvo engano, apenas a primeira mereceu uma versão em português do Brasil, pela Makron Books em 1990. Nem preciso dizer que encontra-se esgotada (mas disponível nos bons sebos da vida, por enquanto. A versão original em inglês sempre está disponível). É impressão minha ou naqueles tempos éramos melhor servidos por nossas editoras? Deixa pra lá, o tema aqui é outro.

    Se nosso mundo, particularmente as organizações de TI, tivesse evoluído nos últimos vinte e poucos anos, este livro estaria defasado. O reli para elaborar esta entrada. E fiquei assustado com sua atualidade. Mesmo o conteúdo original de 1987, suas críticas e sugestões, permanece inteiramente válido. Até quando a dupla de autores se mete a falar sobre a ausência de janelas e o aspecto opressor e barulhento de muitas salas que acomodam desenvolvedores.

    O livro é estruturado em seis partes: Gerenciando o Recurso Humano¹; O Ambiente do Escritório; As Pessoas Certas; Fomentando Equipes Produtivas; Deveria ser Divertido o Trabalho aqui; e Filho de Peopleware (que contém os oito novos capítulos). A escrita é simples, sem rodeios. Contundente em diversos momentos porque a mensagem é séria e os autores são sinceros. Como eles colocam no prefácio, Peopleware é uma coleção de histórias. “Cada princípio apresentado tem a sua história”. Boas histórias, oriundas de mais de 50 anos de experiência (somadas as de Tom e Timothy na época da publicação).

    Os autores dialogam com o Gerente. Mas o livro não é direcionado apenas para eles. Todos que trabalham com TI, particularmente os desenvolvedores, têm muito a aprender e, por que não, se divertir com o texto. Compilei abaixo alguns dos diversos melhores momentos (traduzidos livremente da segunda edição) só para deixá-la(o) curiosa(o):

    Se você se achar concentrado nas questões tecnológicas ao invés das sociológicas, você estará agindo como aquele personagem de vaudeville, que perde a chave em uma rua escura mas opta por procurá-la na via adjacente porque, como ele explica, “a luz é melhor aqui”.

    A principal razão pela qual nos concentramos nas questões tecnológicas ao invés das humanas é porque elas são mais fáceis.

    Nosso negócio é muito mais sociológico do que tecnológico, é mais dependente de nossas habilidades para conversar com outras pessoas do que das habilidades para conversar com máquinas.

    Um ambiente que não tolera erros torna as pessoas mais defensivas.

    Muitos gerentes agem como se as pessoas fossem peças intercambiáveis. Agem como se existisse uma mágica Loja de Pessoas onde eles podem ordenar: “Me mandem um novo Mark Zuckerberg, menos arrogante desta vez, por favor!”
    N.T. Mark só tinha três aninhos quando essas linhas foram escritas. Claro que não é ele o citado na obra original. Mas não é que inventaram mesmo as mágicas Lojas de Pessoas? Teve gente que ficou milionária com isso, mesmo sem nunca contar com Zuckerbergs, Torvalds e Goslings em seus estoques. 

    Estatísticas sobre leitura² são particularmente desencorajadoras: desenvolvedores, por exemplo, não possuem um único livro da área e nunca leram um. Fato horripilante para qualquer pessoa preocupada com a qualidade do trabalho neste campo; para caras que, como nós, escrevem livros, é trágico.

    Produtividade deve ser definida como o Benefício dividido pelo Custo.³

    Um centavo poupado no ambiente de trabalho é centavo ganho, diz a lógica. Aqueles que cometem tal julgamento são culpados por fazerem uma análise custo/benefício sem se beneficiar de um estudo do Benefício.
    N.T. Mantive o jogo original com a palavra benefício. Não deixe de ler a nota 3 abaixo.

    Pessoas sob pressão não trabalham melhor; elas apenas trabalham mais rápido.

    A qualidade, muito além daquela requerida pelo usuário final, é um meio para a alta produtividade.
    N.T. Neste trecho os autores também mostram a relação direta entre qualidade e autoestima. Ninguém se motiva com software escrito nas cochas.

    Qualidade é grátis, mas apenas para aqueles dispostos a pagar muito por ela.

    Em um ambiente de trabalho saudável, as razões pelas quais as pessoas não performam são falta de competência, falta de confiança ou falta de afinidade com os outros membros do time e com os objetivos do projeto. Elas não precisam de mais pressão para trabalhar. Precisam de uma nova posição, possivelmente em outra empresa.

    A função do gerente não é fazer as pessoas trabalhar, mas sim tornar possível que elas trabalhem.

    Existem milhões de maneiras de perder um dia de trabalho. E nenhuma para trazê-lo de volta.

    Se sua empresa tem uma planilha para controle de horas trabalhadas, é possível que ela aponte o tempo de corpo presente, não de cérebro presente.
    N.T. Então a dupla se preocupava muito com poluição sonora e telefones. Mal sabiam que a situação se degradaria a níveis impressionantes depois dos IM’s, redes sociais, smartphones e afins. A multitarefa é um mito que custa caro aos índices de produtividade de um desenvolvedor. Mas, definitivamente, tão ou mais equivocadas estão aquelas organizações que proíbem o uso das facilidades da vida moderna. 

    Se sua empresa anda muito preocupada com um padrão formal de vestimenta, brocotó. Sinal de que ela está nos estágios finais da morte cerebral. Não há remédio. Procure outro emprego.

    A supervisão visual é uma piada para desenvolvedores. Supervisão visual é para prisioneiros.

    Pessoas que escrevem metodologias são espertas. Aquelas que as seguem podem ser idiotas. Elas não precisam ligar seus cérebros. Basta que comecem da página um e sigam pela Yellow Brick Road, como obedientes macaquinhos, até o final do projeto. A metodologia toma todas as decisões. As pessoas, nenhuma.

    Documentação volumosa é parte do problema, não da solução.
    N.T. Os autores citam, em outro trecho, pesquisa que mostra que 30% do trabalho de desenvolvimento é “papelório”, burocracia. Quanto os números mudaram nos últimos 20 anos?

    Acreditar que os trabalhadores irão aceitar os objetivos corporativos de forma automática é sinal de ingênuo otimismo dos gerentes.

    Você não pode se proteger da incompetência de seu pessoal. Se eles não estão a altura do trabalho a ser executado, você falhará.
    N.T. Na tradução rápida encerrei com “você falhou”. Afinal, você os contratou. Mas mantive o tempo do verbo original, menos pessimista.

    O cara gastou R$150 em um pôster bonitão onde se lê: “Qualidade é nosso trabalho número 1!”. Ah, tá falando sério? Caramba, juro que a gente pensava que era o trabalho número 21 ou 117 antes desse pôster ser pendurado ali na parede. Pensávamos que talvez estivesse entre “reduzir a cera dos ouvidos” e “fazer coleta seletiva do lixo” na escala de valores corporativos.

    Aqueles caras maravilhosos que nos brindaram com a Metodologia com “M” maiúsculo não ficaram parados. Sua última proposta, o Movimento para Melhoria de Processos, é nova, brilhante, melhor, esfuziante e muito mais ambiciosa… Desta vez, eles levaram o “tamanho único” ao extremo. Seu modelo não atenderá apenas sua empresa, mas o mundo todo.
    N.T. Pensou em CMMI, MPS.br e que tais? Não? Saca só:

    Se você é um CMM nível 2 ou superior, lembre-se: os projetos que mais valem a pena são aqueles que o moverão para baixo em sua escala de maturidade.

    Você nunca melhora se nunca muda.

    O aprendizado é limitado pela capacidade de uma organização em manter seu pessoal.

    Deve estar enterrada em algum lugar de nossa memória ancestral a noção de que o trabalho deve ser penoso. Se você sente prazer em algo, não deve ser trabalho. Deve ser pecado. E você não deveria estar recebendo por isso. Encontre outra coisa para fazer, algo que realmente se pareça com trabalho. Assim você poderá se sentir entediado, cansado e desiludido como todo mundo.

    Notas

    1.  Será que, se fosse escrito hoje, o livro ainda falaria de “Recursos Humanos”? Creio que sim, apesar da ditadura de uma escola neozenbudista que grita aos quatro ventos “não sou recurso” enquanto, no frio da teoria, segue sendo. Toda vez que é contratado para executar um trabalho.
    2. Dias atrás foi publicada uma pesquisa que diz que o brasileiro lê, em média, 4,1 livros por ano. Se tirarmos os livros escolares (obrigatórios?), o número cai para 1,1. Qual será a média de nossos desenvolvedores, analistas e gerentes?
    3. Já tem um tempinho que toco nesse assunto no {FAN}. Só não me lembrava que era inspirado pelo Peopleware. Costumo dizer que o termo “análise custo X benefício” (também apresentado assim: custo-benefício) carrega dois grandes equívocos. O primeiro é matemático. Faça as contas. Acho que faz mais sentido uma divisão, tendo o custo como denominador. Ah, não pretendiam que o termo funcionasse como uma operação? Então compute o terceiro erro. Porque o segundo é outro, de ordem psicológica. Colocando o benefício antes do custo sinalizamos que ele deve merecer mais atenção. A ordem usual (custo X benefício) soa mesquinha. E gera comportamentos mesquinhos. Como daquele cliente que pega sua bela proposta e vai direto para a última página conferir o preço e lamentar: “Isso tudo?”

     

  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • 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

     

  • 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.
  • 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.
  • 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.
  • Management 3.0

    Management 3.0

    Autor: Jurgen Appelo, holandês que se apresenta como escritor, palestrante, instrutor, desenvolvedor, empreendedor, gerente, blogueiro, leitor, sonhador, líder e pensador livre. Figura relativamente nova na Comunidade Ágil. Este é seu primeiro livro.

    Editora: Addison-Wesley (2011).

    Promessa do Subtítulo: Liderando Desenvolvedores Ágeis, Desenvolvendo Líderes Ágeis

    Do que se trata: GERENCIAMENTO. O autor dirige o livro para gerentes “de linha” (de áreas de Desenvolvimento ou Departamentos de TI) reforçando que não se trata de (mais) um livro sobre Gerenciamento de Projetos. Também “filtra” um pouco mais a seleção colocando que o livro é sobre Gerenciamento Ágil. Mas parece que todo mundo que já teve o prazer de conhecer esta obra descobriu que se trata de um trabalho sobre Gerenciamento no século XXI, o século da Complexidade. GERENCIAMENTO em seu sentido mais amplo.

    Três ponto zero?: O gerenciamento 1.0 foi aquele chamado de científico, caracterizado por hierarquias e originado no início do século passado. O gerenciamento 2.0 brota em meados dos anos 1980 e é caracterizado pelas manias e modismos, por patches e add-ons (TQM, BPR, TOC, BsC, Six Sigma etc) que tentavam “corrigir” a versão anterior.

    Então veio a teoria da complexidade e sua aplicação na matemática, biologia, economia e sociologia. Aí chega o Jurgen, mergulha na teoria e em sua aplicação nos mais diversos domínios, e a destila em um modelo que ele chamou de Management 3.0.

    Indicado para: Gerentes, líderes, desenvolvedores, empreendedores, sonhadores, pensadores livres e todos que queiram entender a razão de tudo neste mundo parecer um tanto complicado e/ou complexo e porque todo sucesso não passa de um adiamento do fracasso.

    Contra-indicações: Puristas, extremistas, conservadores, preconceituosos, adoradores de ângulos retos e eleitores do Jair Bosonaro podem sentir um certo desconforto em diversos trechos do livro.

    Breve Resenha: Quem lê livros técnicos sobre um mesmo tema com uma certa frequência vive com a sensação de déjà-vu. Nos últimos tempos engoli, total ou parcialmente, mais de uma dúzia de livros sobre o Desenvolvimento Ágil de Sistemas. Poucos realmente colocaram assunto novo na mesa. Dois deles mereceram entrada nesta biblioteca. O resto girou em torno dos mesmos temas, problemas e sugestões. Às vezes mudando nomes, outras tantas reciclando histórias.

    Jurgen Appelo acaba de colocar o assunto “Agile” em outro patamar.

    Não se trata de um reset, pelo contrário. Jurgen conhece e respeita toda a história que no próximo dia 13 de fevereiro completará dez anos (data da publicação do Manifesto Ágil). Mas ele se apresenta como um pensador livre. E é. Por isso busca coisas com milhares ou milhões de anos de idade ou situações bobas do cotidiano para ilustrar suas colocações e tornar mais palatáveis as ideias e teorias que sustentam seu modelo. Estratégia mais que necessária, porque Jurgen parte de um Corpo de Conhecimentos de Sistemas formado por coisinhas espinhosas como: Teoria Geral dos Sistemas, Cibernética, Teoria dos Sistemas Dinâmicos, Teoria dos Jogos, Teoria do Caos e Teoria da Evolução. Não se assuste ainda. Esta é apenas parte da história que ele conta para justificar o uso do Pensamento da Complexidade (ou Teoria da Complexidade ou ‘simplesmente’ Complexidade, hehe) como base para o seu modelo.

    Perdão, não há motivos para sustos. Jurgen apresenta essas teorias e conceitos para “humanos normais” como você e eu. Primeiro em um único capítulo, o terceiro, pavimentando o caminho que seguiremos. Depois em capítulos que concentram toda a parte teórica de cada Visão proposta no modelo Management 3.0. Cada uma das seis visões da Martie (o monstrinho que Jurgen desenhou para representar o modelo) é apresentada em dois capítulos, um teórico e outro prático. Essa sacada, além de facilitar a compreensão de suas sugestões, permite o planejamento de nossos estudos. Este é um livro para ser estudado, não simplesmente lido. Optei por estudar um visão por dia: o capítulo teórico na parte da manhã, o prático bem depois do almoço.

    Hora de apresentar, afinal, os seis “olhos” da simpática Martie:

    • Energizar Pessoas: “Penso que as pessoas são as partes mais importantes de uma organização e que os gerentes devem fazer de tudo para mantê-las ativas, criativas e motivadas.”
    • Fortalecer¹ Times: “Acredito que os times podem se auto-organizar, e isto requer delegação de poderes, autorização e confiança por parte dos gerentes.”
    • Alinhar Restrições: “Expliquei que a auto-organização pode resultar em qualquer coisa, portanto é necessário proteger as pessoas e os recursos compartilhados e dar para as pessoas propósitos claros e objetivos definidos.”
    • Desenvolver Competência: “Também acredito que os times não podem atingir esses objetivos se seus integrantes não forem capazes, e que os gerentes devem contribuir para o desenvolvimento da competência de cada um deles.”
    • Desenvolver² Estrutura: “Muitos times trabalham no contexto de uma organização complexa, por isso estou convencido de que é importante considerar as estruturas para melhorar a comunicação.”
    • Melhorar Tudo: “Também penso que as pessoas, times e organizações devem continuamente melhorar tudo de forma a adiar o fracasso o máximo possível.”
    • “Finalmente, acho que a apresentação acima está bem fácil de entender, o que significa que ela provavelmente está errada.”

    O resumo acima é apresentado lá no finalzinho do livro, quando o autor confessa: “Sim, meu modelo está ‘errado’”. “Todos Estão Errados, mas alguns são úteis” é o título do capítulo 16. O humor e a honestidade de Jurgen, além, claro, do tanto que ele conhece e estudou, fazem deste livro um marco. Suecos (e seus 1.217 mosquitos), belgas, cubanos e eleitores do Bosonaro terão alguns motivos para reclamar do livro. Acho que nenhum relacionado ao que ele ensina sobre GERENCIAMENTO.

    Alguns Trechos Selecionados, Surrupiados e Livremente Traduzidos:

    “Acho que o Movimento Ágil negligenciou a importância dos gerentes (de linha). Se os gerentes não sabem o que fazer nem o que esperar de uma organização Ágil, como esperar que eles se envolvam na transição para o desenvolvimento Ágil de software? Qual é a mensagem do Movimento Ágil aqui? Se for apenas ‘não precisamos de gerentes’, então não causa espanto saber que transições para o Ágil estão sendo obstruídas ao redor do globo.”

    “Lembre-se que valores Ágeis não são listas fixas com cinco, sete ou doze itens. Este livro é sobre complexidade, não sobre respostas simples.”

    “Nenhum sistema³ que se auto-organiza existe fora de um contexto. E é o contexto que restringe e direciona a organização de um sistema.”

    “Gerentes inteligentes sabem que devem tomar o menor número de decisões possível.”

    “Acredito que um ‘ponto fraco’ do Manifesto Ágil é o fato dele não reconhecer (explicitamente) que todos os projetos de software precisam de pessoas inteligentes, disciplinadas e atentas. O paradigma ‘pessoas mais que processos’ é jóia, até você descobrir que seu time se limita a dois duendes, um papagaio, uma cabeleireira e um gerente de projetos aparentemente brilhante mas que é cego, surdo e mudo. Não há coaching no mundo que faça este time se auto-organizar e entregar um produto bem sucedido.”

    “Disciplina * Habilidade = Competência”

    “A melhor maneira de implementar processos Ágeis é fazê-lo do seu jeito.”

    “Modelos de maturidade são pouco úteis, talvez até um pouco ofensivos.”

    “Se eles podem escovar seus dentes todos os dias para se livrar de cáries, por que não podem escovar o código diariamente para se livrar dos bugs?”

    “Gerentes de projetos estão ali para servir os times, não para controlá-los. Gerentes de projetos estão ali para gerenciar projetos, não pessoas.”

    “Se você introduzir um novo produto de software em um ambiente, o ambiente vai mudar, consequentemente os requisitos para o produto também mudarão.”

    “O valor percebido de uma mudança é proporcional à dor que se sente por não mudar.”

    “Compañero, no hay camino. Se hace camino al andar.”

    Observações:

    1. O termo original é “empower”. Optei por “fortalecer” (times) como tradução porque empowerment normalmente é entendido apenas como “delegação de poderes”. O autor tem objetivos mais amplos e ambiciosos para a palavra.
    2. Outro termo comum que ainda me atrapalha é “grow”. Simples: é crescer… ou aumentar, germinar, florescer, produzir. Optei por “desenvolver” por achá-lo mais coerente com a intenção do autor: “grow structure”.
    3. A palavra “sistema” é utilizada no livro em seu sentido mais amplo. Empresas, times, pessoas e bactérias são sistemas.
    4. Esta entrada ficou longa, muito longa! O livro, em cada uma de suas 413 páginas, fez por merecer. De tempos em tempos me deparo com um título que realmente me “melhora”. Muito. Não vejo a hora de estudá-lo de novo.