Aprendizado Interprojetos – PAULO FERNANDO VASCONCELLOS NOGUEIRA https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br My WordPress Blog Thu, 17 Mar 2011 18:11:56 +0000 pt-BR hourly 1 https://wordpress.org/?v=7.0 Panelinhas na Prática https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/03/17/panelinhas-na-pratica/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/03/17/panelinhas-na-pratica/#comments Thu, 17 Mar 2011 18:11:56 +0000 http://www.pfvasconcellos.eti.br/blog/?p=1783 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.
]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2011/03/17/panelinhas-na-pratica/feed/ 2
Aprendizado Interprojetos https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2008/05/02/aprendizado-interprojetos/ https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2008/05/02/aprendizado-interprojetos/#respond Fri, 02 May 2008 21:49:49 +0000 http://www.pfvasconcellos.eti.br/blog/2008/05/02/aprendizado-interprojetos/ Quinze meses mergulhado em um mesmo assunto, mesmo que ele seja amplo e saboroso, cansa. Aproveitei o feriado e meu 3º aniversário para “oxigenar” o cérebro. Trouxe de Sampa, na semana passada, a última edição da MundoPM. Não curto muito a (cara) revista, mas uma chamada de capa me pegou: “Gestão do Conhecimento Interprojetos: como evitar custos imensos de reinvenção e oportunidade a cada projeto“. Caramba… há 4 anos eu não via nada sobre o tema. Este foi o assunto do primeiro trabalho que publiquei aqui no finito, resultado de um estudo que fiz entre 2003 e 2004 (compilado neste PDF de 240kb e 21 páginas – versão revista hoje!).

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

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

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

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

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

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

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

]]>
https://paulofernandovasconc1781614199000.0291847.meusitehostgator.com.br/2008/05/02/aprendizado-interprojetos/feed/ 0