?

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.

?

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.

?

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

?

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

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.

?

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.

?

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.

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.

.:.

Tivemos cinquenta participantes. Me lembrei das primeiras edições do FAN. Já chegamos a atender setenta pessoas, um número pra lá de exagerado em eventos desta natureza. Mas a quantidade de pessoas não comprometeu em nada o curso, pelo contrário. Criou um clima de trabalho onde todos pareciam realmente motivados. E mesmo aqueles que tradicionalmente gostam de ficar quietos em seu canto colocaram a mão na massa. Grupos de 6~8 pessoas emulavam times Scrum. E em um time Scrum é difícil alguém fingir que está trabalhando.

Comecei o evento confessando um ‘frio na barriga’ mais gelado que o normal. Era uma estreia. De um programa que fez algumas apostas arriscadas: i) ‘Esticar’ o framework Scrum de forma a contemplar as etapas de Visualização e Especulação (criação da Visão do Produto; planejamento de Releases; definição da primeira versão do Backlog do Produto); e ii) Reapresentar componentes básicos do Scrum, criticando alguns pontos dos checklists oficiais.

Não eram pré-requisitos para participar do evento o conhecimento ou experiência com o Scrum. Pouco mais da metade da plateia já trabalhava com o Scrum. Foi de parte deles que ouvi alguns “ah’s!”. Tipo: “não foi bem assim que nos ensinaram, mas acho que é disso mesmo que a gente tá sentindo falta”. Como coloquei na revisão anterior, os trabalhos clássicos sobre o Scrum partem de uma Visão pré-estabelecida. Apesar dos alertas (que não são poucos), muitos acreditam que o trabalho começa ali, traçando histórias e empilhando-as em um backlog. É preciso reforçar que um backlog frouxo, fruto de uma visão embaçada, é um dos principais suspeitos em implementações Scrum que “não vingam”.

Mas eu errei na segunda aposta. Não na reapresentação (dos componentes básicos do Scrum), mas no momento. Segundo avaliação da própria turma – ao vivo e tête-à-tête – eu deveria ter concentrado tal apresentação no início do curso, quando optei por um simples “Scrum em 15 minutos” Ao salpicar estas revisões no decorrer do curso e, principalmente, por acumular boa parte delas no finalzinho do dia, acabei quebrando o ritmo (e o clima). A turma vinha quente de três atividades consecutivas, com a mente centrada no projeto e, de repente, vê seu pique freado por uma sequência de “blá-blá-blás”. Insisto: bla-blá-blá necessário, porém mal posicionado. Mensagem que não esquecerei nunca mais: coloque toda a parte “chata” do evento no período da manhã – o pessoal prefere “chatice” concentrada do que diluída. Mas não abrem mão dela, da tal “teoria”.

Assim como não abrem mão de exemplos. Alguns participantes sugeriram a apresentação de resultados pré-elaborados. Não curto isso, porque eles são naturalmente artificiais (hehe!). Mas entendo a necessidade. E tentarei saciá-la através da demonstração dos resultados pelos próprios grupos. Contribuo mais criticando os resultados do que apresentando um só meu. O problema é o cronograma…

A outra dica / reclamação principal eu já esperava: um dia é muito pouco! Praticamente não tivemos atropelos – cancelamos apenas uma atividade prática – e todo o programa (“teórico”) foi cumprido. Eram 17h55 quando a turma foi “dispensada”. Mas ficou – se não em todos, na grande maioria – a sensação de “quero mais”. Eles queriam tempo para debater cada exercício, ver exemplos e trocar experiências entre os grupos. Apenas estes pequenos reviews exigiriam algo em torno de duas horas adicionais. Por um único motivo (custos!), meu parceiro e eu gostaríamos de manter o FDP com carga de 7 horas. Somos voto vencido. Precisarei de um tempinho para redesenhar a oficina – não gostaria de repetir a fórmula dos dois dias consecutivos já consagrada no FAN. Sei lá porque mas não gostaria.

Um ponto chamou a atenção de quem já tinha mais experiência com Scrum: a preocupação com a definição e medição do *Valor*. Em uma pequena grande série de artigos, publicada no meio do ano, eu já havia adiantado parte de minhas ideias. Surrupiei sugestões do Jim Highsmith e as misturei com técnicas que já utilizava (particularmente com a Matriz hiper-mega-super Simples de Priorização). A montagem e priorização do backlog do produto não é uma atividade trivial. Tentei mostrar como a definição do Valor e o debate sobre a complexidade ou riscos técnicos podem (ou devem) acontecer no mesmo momento e com envolvimento de todos – DP, ScrumMaster e Time – inclusive de outros representantes das áreas usuárias. Aquela tal matriz nasce neste encontro. E facilita demais a montagem de um Backlog.

Por incrível que possa parecer, a percepção do *Valor* (do que o negócio ganhará com aquele produto) parece ser difícil. A impressão que fica é que as pessoas não têm o costume de falar sobre isso. Muito menos de tratar tal definição como O fator crítico de sucesso para um projeto. Aliás, a própria definição de sucesso ou fracasso depende desta definição. Eu até tentava compreender quando notava essa dificuldade em Analistas de Negócios. Agora, falando com Donos de Produtos, a luz vermelha piscou e a sirene berrou.

.:.

A estreia do FDP ficou muito acima de minhas expectativas. Com certeza foi “sorte de estreiante”. E não tenho dúvidas de que a turma destoou: era muito boa e muito participativa. Já encontrei várias assim no FAN. E é pela experiência com ele que sei que encontrarei turmas mais arredias, selvagens, sonolentas ou simplesmente meio-desligadas. Só espero que elas não apareçam logo na segunda ou terceira edições. Prefiro encontrá-las quando a oficina estiver um pouquinho menos verde.

Assim como aconteceu com o FAN, tentarei registrar aqui todo o processo de maturação. Transparência ingênua? Não! A certeza de que só o seu feedback pode fazer o FDP amadurecer de fato. Aos que já participaram e seguirão participando meu sincero agradecimento. Inté!

.:.

Observações:

1. Cometi uma injustiça danada na lista de referências bibliográficas publicada na primeira revisão. Me esqueci de mencionar o livro “Scrum Product Ownership“, de Bob Galen (RGCG, 2009). Foram os seus escritos que motivaram e inspiraram boa parte das “licenças poéticas” do FDP. Forma, com”Agile Project Management“, de Jim Highsmith, e “Agile Product Management with Scrum“, de Roman Pichler, a base para a Formação de Donos de Produtos. Ou seja, a base (teórica) do FDP.
2. Todas as fotos publicadas neste artigo foram tiradas pelo fiel escudeiro e parceiro Anderson Oliveira, da Tempo Real Eventos. O cara tá ficando bom nisso! Outras fotos podem ser vistas no Flickr.

.:.

Um treinamento sobre Scrum ou fortemente baseado nele, como é o caso do FDP, deveria ser planejado, construído e apresentado como produto de um esforço guiado pelo próprio Scrum. Sem artimanhas ou enfeites baratos – ou até com alguns deles, como mostrarei na sequência – mas preocupando-se e ocupando-se com a experiência e a contínua melhoria do produto. Daí a necessidade de aparição aqui e das possíveis conversas que virão. Daí o fato da última atividade prevista, de um total de sete, ser uma revisão informal do próprio evento. As fichas de avaliação, por exigência do parceiro, seguirão existindo. Mas todos os participantes serão convidados para um Sprint Review no final do dia. Papo informal que deve escorregar para um etílico happy-hour. Mas é papo sério!

Ainda são poucos os trabalhos, livros e eventos dirigidos especificamente para os Donos de Produtos (DP’s). Meu trabalho de exploração, além das experiências práticas, se baseou principalmente em dez títulos (apresentados no final deste artigo). Como adiantei no programa e em outros lugares, esta oficina está repleta de “licenças poéticas”. Explico: apesar de respeitar integralmente as diretrizes do Scrum e práticas mais aceitas (ou comuns), precisei adaptar e incluir várias coisinhas que são ignoradas pela gramática oficial do framework.

Dediquei especial atenção ao momento inicial de um projeto. E incorporei elementos do framework APM (Agile Project Management) apresentado por Jim Highsmith no livro homônimo. As etapas de Visualização (Envision) e Especulação (Speculate) são cruciais para o DP. Mas elas são ignoradas em trabalhos clássicos sobre métodos ágeis ou mesmo sobre Scrum. A grande maioria deles parte de uma Visão já existente e não se preocupa em mostrar como ela é construída. Por isso dediquei dois “capítulos” do programa só para isso, “O Produto” e “Roadmaps, Releases, Sprints…”. Os participantes vão elaborar a Visão de um produto e derivar dela o Backlog do Produto. Das seis atividades práticas, quatro têm esta finalidade.

Outro relativo “buraco negro” da gramática oficial do Scrum é a definição do Valor: a relevância de determinada funcionalidade, requisito, história ou tarefa para o negócio ou para a realização do produto. Incorporei parte do método que sugiro no FAN, mas o temperei com o algoritmo de definição de Pontos de Valor também sugerido por Jim Highsmith. Gostei tanto da brincadeira que adaptei o Planning Poker para o debate sobre o Valor de cada item do Backlog. Os participantes ganharão um jogo de cartas personalizado. Para a definição de pontos de valor utilizamos um conjunto menor da escala de Fibonacci. Mas, como já estava com a mão na massa mesmo, fiz um baralho que pode ser utilizado no Planning Poker tradicional.

Aliás, o baralho é um dos “enfeites baratos” que citei acima. Aquilo que chamei de “Kit do DP Moderno” também é composto por fichas para anotação de Histórias de Usuários, um modelinho para especificação de Casos de Uso (mesmo utilizado no FAN), um Risque & Rabisque com um Quadro Scrum e, claro, post-it’s.

Os enfeites, que pra falar a verdade não são assim tão baratos, evitam improvisos e perda de tempo. E são ferramentas que o DP utilizará em seu dia a dia. Mas ai de quem aparecer na oficina só para ganhar brinquedinhos.

Não é fácil consolidar em um evento com sete horas de duração uma boa simulação da vida de um DP em um projeto. Só a primeira execução me dará uma boa noção da distribuição do tempo, mas eu estimo que teremos algo entre 2h30 e 3 horas de atividades práticas. É pouco, eu reconheço. E está aqui o principal ponto de extensão (para uma possível versão com carga horária maior).

Já sei que estamos com sala praticamente lotada (40+ inscritos). Levarei também alguns convidados – gente que não pisa em cascas de ovos quando vai me criticar. É um feedback mais que necessário para um evento totalmente novo. Resta torcer para que eu não tenha cometido muitos erros. Na próxima semana eu conto o resultado. Inté!

.:.

Os Principais Livros Utilizados:

• Agile Project Management – Second Edition
  Jim Highsmith | Addison-Wesley (2010)
• Agile Product Management with Scrum
  Roman Pichler | Addison-Wesley (2010)
• Kanban e Scrum – Obtendo o Melhor de Ambos
  Henrik Knibert e Mattias Skarin | InfoQ (2009)
• Succeeding with Agile
  Mike Cohn | Addison-Wesley (2010)
• Agile Estimating and Planning
  Mike Cohn | Prentice-Hall (2006)
• Coaching Agile Teams
  Lyssa Adkins | Addison-Wesley (2010)
• Subject to Change
  Peter Merholz et al | O’Reilly (2008)
• REWORK
  Jason Fried e David H. Hansson | Crown Business (2010)
• Sistema Toyota de Desenvolvimento de Produtos
  James M. Morgan e Jeffrey K. Liker | Bookman (2006)

A imagem utilizada neste artigo, “Walking in Circles“, é de HikingArtist.com.

.:.

O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

Um DP por Projeto – Um Projeto por DP

Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

Colocado e Falante

De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

O Passo Esquecido

Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

Os Passos Executados

Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

Aos Donos com Carinho

Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

.:.

Observações:

1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

Faltou dizer:

Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!