PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • RenDanHeYi

    RenDanHeYi

    Um pouco antes de morrer, Taiichi Ohno — o pai do Sistema Toyota de Produção — foi perguntado: o que você está fazendo? Ele respondeu: pensando em formas de reduzir o tempo gasto entre o pedido do cliente e a entrada do dinheiro¹.

    Do Sistema Toyota derivamos o Lean e muito do que vemos no mundo Agile. A grande constante — obsessão? — é o tempo. Por isso falamos tanto sobre fazer o dobro do trabalho na metade do tempo, otimizar fluxos, entregar continuamente etc. Talvez tenha chegado a hora da China nos sugerir um modelo — um sistema. A obsessão é outra: espaço. E isso pode mudar bastante as nossas conversas.

    Rén d?n hé y? (????), segundo o Google Translate, significa um único. Se Ohno brigava para reduzir o tempo entre o pedido e a grana embolsada, a proposta chinesa visa eliminar a distância entre o cliente e o negócio. Gary Hamel e Michele Zanini explicam assim²: “transmite a ideia de uma relação estreita entre o valor criado para o cliente e o valor recebido pelos funcionários.” É provável que aqui no ocidente a gente comece a falar em Distância Zero. A conversa já começou³.

    E vem de uma maneira muito diferente da forma como iniciamos o movimento Ágil. Porque tudo na China parece superdimensionado. O RenDanHeYi nasceu grande. Hamel e Zanini estudaram a Haier, a maior fabricante mundial de eletrodomésticos. Ela tem 75 mil funcionários. Todos organizados em microempresas que têm entre 10 e 15 pessoas. Ou seja, aquele imenso dragão é um emaranhado com mais de 4 mil microempresas (MEs).

    Existem apenas três tipos de MEs: usuária (200), incubação (50) e junção (3800). As primeiras estão na linha de frente, voltadas para o mercado. Em incubação ficam as novas ideias e apostas (startups, como queira). As junções (nodes) são contratadas — e demitidas — pelas outras duas. Elas representam todo o resto da organização: vendas, design, manufatura, apoio (RH, contabilidade, TI etc). O artigo de Hamel e Zanini detalha os sete fatores que fazem o modelo funcionar. Não vou chover no molhado².

    Coincidências Felizes

    O modelo, por querer, lembra a Web. São diversas partes pequenas fracamente acopladas e organizadas em plataformas. Existem apenas dois níveis hierárquicos entre as MEs e o CEO. O que sugere bastante autonomia e alinhamento. A organização é fractal e a existência de um sistema 4 de verdade — as MEs de incubação — deixaria Stafford Beer feliz da vida. Não apenas por isso, mas principalmente porque parece que a Haier entende e aplica a Lei de Ashby: “Só a Variedade absorve Variedade”.

    Preciso repetir a primeira frase acima: o modelo da Haier copia a Web. É uma grande fábrica que não se vê em uma cadeia de valor e sim numa Rede de Valor. Tom Stewart, que inspirou este velho post, deve ter dado um sorriso sarcástico: uma fábrica funcionando como rede de valor! Dave Gray, de A Empresa Conectada (Novatec, 2013), rabiscou a diferença e riu junto.

    Não há monopólios internos. As MEs usuárias nunca se tornam reféns de junções que não entregam. Elas têm total autonomia para contratar alternativas, estejam elas dentro ou fora da Haier, num desenho que deixaria Russell Ackoff muito satisfeito. Porque ele escreveu, há muito tempo, que essa seria uma característica fundamental de uma organização do século 21. Oras, se realmente acreditamos na economia de mercado, o que justifica a existência de monopólios dentro das nossas empresas?

    Talvez os links dos três parágrafos anteriores apenas dedurem um viés de confirmação. Eu desconfio que eles apontam padrões que a Haier, em uma década, descobriu ou desenhou de forma empírica.

    Seja como for, o fato é que a Haier não é apenas uma colcha de ideias e padrões relativamente raros. O que dá cola e sentido para todo o modelo é a sua diretriz principal, a Distância Zero. E isso é novo.

    Ainda é muito cedo para dizer se este modelo será tão influente quanto o Sistema Toyota. Mas vale a pena prestar atenção³.

    Notas

    1. Citação encontrada em Freedom from Command and Control, de John Seddon (Productivity Press, 2005). Se você quer ter uma visão mais prática do que significa Lean na área de serviços, este é o livro. Que apresenta outra possível coincidência: Seddon insiste bastante na proximidade com os clientes. Sua leitura do que é ser Lean, se devidamente espalhada no mundo ágil, nos teria poupado de alguns mal entendidos. Como algumas brigas contra a variedade, por exemplo.
    2. Em artigo de capa da edição de nov/18 da Harvard Business Review. A versão em inglês está disponível para leitura. Hamel e Zanini vão detalhar a proposta em Humanocracy: creating organizations as amazing as the people inside them(programado para jan/2020).
    3. Em 9/mar uma busca no Google por rendanheyi retornou 7.410 resultados. Hoje (23/mar) já são 43.300.
    4. O Six Sigma abre espaço para o Rendanheyi na GE. Artigo da Bloomberg, de 8/2/19. (Obrigado Cattai!)
    5. Ilustrei aqueles artigos de cinco anos atrás com imagens do QThomas Bower. Faz sentido manter o padrão com a bela Lemon Lime — Fractal Mosaic.
  • A Caixa de Ferramentas do PO

    A Caixa de Ferramentas do PO

    Não são poucos nem triviais os trabalhos do PO. Para inspirar e orientar o desenvolvimento de produtos ele precisa de boas ferramentas. Estamos cheios delas. E isso não é necessariamente bom. Sobram sobreposições e redundâncias. Faltam interfaces para que as ferramentas se comuniquem e possibilitem a construção de uma narrativa lógica e coesa. A organização da caixa de ferramentas do PO dá trabalho¹.Uma caixa de ferramentas bagunçada é uma contradição. Ferramentas devem nos tornar mais produtivos – ágeis de fato. O problema é que vivemos numa era de grandes ideias isoladas e quase herméticas. JTBD, OKR, canvases mil, jornadas de clientes e usuários, User Stories, Job Stories, Value Stories e por aí vai. Existem diversos livros, artigos ou cursos sobre cada uma delas. Mas não são comuns os trabalhos que proponham um conjunto ou, melhor dizendo, um sistema.

    Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

    Mapa Rico

    São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

    Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

    Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

    Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

    O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

    As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

    Notas

    1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
    2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
    3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
    4. Rectilinear, de Stuart Caie, ilustra este artigo.
  • Os Trabalhos Essenciais do PO

    Os Trabalhos Essenciais do PO

    O Dono de Produtos deve inspirar e orientar o desenvolvimento de soluções criativas. Para tanto, ele assume a responsabilidade por dez trabalhos essenciais¹. A matriz ao lado sugere a distribuição dos trabalhos em um ciclo com quatro fases²: Descoberta, Exploração, Desenvolvimento e Entrega. Cada fase requer um tipo de raciocínio e lida com matérias-primas bem diferentes (concreto ? abstrato).Aos trabalhos:

    • Entender o Problema: parece uma coisa à toa, mas como é que a gente voa e gera desperdícios quando não começa direito. Problemas são definidos e compreendidos de forma diferente pelos envolvidos, por isso precisamos
    • Conhecer as Pessoas: e seus interesses. Não é apenas uma questão de gerar um mapinha de stakeholders ou desenhar personas. Sem empatia o PO não vai a lugar nenhum. Se não conhecer os interesses em jogo, como o PO conseguiria
    • Negociar Objetivos: identificar e fixar os (poucos) indicadores que servirão como bússola. Da descoberta passamos para a etapa de exploração. O PO começa a
    • Elaborar Hipóteses: cogitando alternativas de solução, comparando as diversas opções concorrentes e validando tendências. As dúvidas mil – inevitáveis neste momento – são atacadas quando o PO seleciona hipóteses e começa a
    • Criar e Testar Protótipos: levando ideias para o mundo real. Essa peneira, depois de alguns ciclos, permitirá ao PO tomar decisões e
    • Criar a Visão e o Roadmap do Produto: um momento chave. O PO inspira através da visão apresentada. A proposta deve ser comprada por clientes e usuários. O desafio precisa ser comprado pelo time. Passado o decisivo teste, é hora de
    • Desenhar o Produto contando Histórias: User Stories, Job Stories, Use Cases? O que menos importa é o formato. As histórias precisam ser coerentes e mostrar com clareza sua contribuição para a realização dos objetivos. Essas histórias compõem um roteiro, um backlog. É responsabilidade do PO
    • Gerenciar o Backlog: definindo prioridades e informando ao time o que precisa ser feito e quais resultados precisam ser obtidos em determinado momento. Além disso, o PO vai
    • Apoiar o Time: tirando dúvidas, orientando e testando, diariamente, o que está sendo desenvolvido. É o olho do dono que engorda o boi. É a presença e cooperação do PO que orienta o time. Em ciclos bem ou mal definidos, o PO deve
    • Acompanhar a Evolução do Produto: monitorando os (pouco) indicadores; Interagindo com clientes e usuários; Se preocupando com a disposição e evolução do time; e se preparando para começar (quase) tudo de novo.

    Falando assim, até parece que é simples a vida de um PO. Não é. Mas a sua formação não precisa ser complicada. 

    Coincidências

    1. Um trabalho é essencial quando sua falta ou má execução compromete o resultado esperado. O mesmo conceito foi utilizado na elaboração do programa FAN – Formação de Analistas de Negócios. Neste caso, são oito os trabalhos essenciais. Quase há uma coincidência com os trabalhos do PO. Quase! Porque, para o PO, o buraco é mais em cima.
    2. A matriz sugerida coincide com o ciclo OODA (Observe, Oriente, Decida, Aja). O destaque para a etapa de Orientação (Exploração) também coincide. Mas a verdadeira inspiração vem de Takeuchi e Nonaka, os vovôs do Scrum (Gestão do Conhecimento – Bookman, 2008). Para saber mais do modelo, veja este vídeo. Para debatê-lo, participe do evento SEA: Sistêmico, Enxuto e Ágil.
    3. Clay Cutter foi compartilhada via flickr por christy sheffield.
  • Os Trabalhos Essenciais do PO

    Os Trabalhos Essenciais do PO

    O Dono de Produtos deve inspirar e orientar o desenvolvimento de soluções criativas. Para tanto, ele assume a responsabilidade por dez trabalhos essenciais¹. A matriz ao lado sugere a distribuição dos trabalhos em um ciclo com quatro fases²: Descoberta, Exploração, Desenvolvimento e Entrega. Cada fase requer um tipo de raciocínio e lida com matérias-primas bem diferentes (concreto ? abstrato).Aos trabalhos:

    • Entender o Problema: parece uma coisa à toa, mas como é que a gente voa e gera desperdícios quando não começa direito. Problemas são definidos e compreendidos de forma diferente pelos envolvidos, por isso precisamos
    • Conhecer as Pessoas: e seus interesses. Não é apenas uma questão de gerar um mapinha de stakeholders ou desenhar personas. Sem empatia o PO não vai a lugar nenhum. Se não conhecer os interesses em jogo, como o PO conseguiria
    • Negociar Objetivos: identificar e fixar os (poucos) indicadores que servirão como bússola. Da descoberta passamos para a etapa de exploração. O PO começa a
    • Elaborar Hipóteses: cogitando alternativas de solução, comparando as diversas opções concorrentes e validando tendências. As dúvidas mil – inevitáveis neste momento – são atacadas quando o PO seleciona hipóteses e começa a
    • Criar e Testar Protótipos: levando ideias para o mundo real. Essa peneira, depois de alguns ciclos, permitirá ao PO tomar decisões e
    • Criar a Visão e o Roadmap do Produto: um momento chave. O PO inspira através da visão apresentada. A proposta deve ser comprada por clientes e usuários. O desafio precisa ser comprado pelo time. Passado o decisivo teste, é hora de
    • Desenhar o Produto contando Histórias: User Stories, Job Stories, Use Cases? O que menos importa é o formato. As histórias precisam ser coerentes e mostrar com clareza sua contribuição para a realização dos objetivos. Essas histórias compõem um roteiro, um backlog. É responsabilidade do PO
    • Gerenciar o Backlog: definindo prioridades e informando ao time o que precisa ser feito e quais resultados precisam ser obtidos em determinado momento. Além disso, o PO vai
    • Apoiar o Time: tirando dúvidas, orientando e testando, diariamente, o que está sendo desenvolvido. É o olho do dono que engorda o boi. É a presença e cooperação do PO que orienta o time. Em ciclos bem ou mal definidos, o PO deve
    • Acompanhar a Evolução do Produto: monitorando os (pouco) indicadores; Interagindo com clientes e usuários; Se preocupando com a disposição e evolução do time; e se preparando para começar (quase) tudo de novo.

    Falando assim, até parece que é simples a vida de um PO. Não é. Mas a sua formação não precisa ser complicada. 

    Coincidências

    1. Um trabalho é essencial quando sua falta ou má execução compromete o resultado esperado. O mesmo conceito foi utilizado na elaboração do programa FAN – Formação de Analistas de Negócios. Neste caso, são oito os trabalhos essenciais. Quase há uma coincidência com os trabalhos do PO. Quase! Porque, para o PO, o buraco é mais em cima.
    2. A matriz sugerida coincide com o ciclo OODA (Observe, Oriente, Decida, Aja). O destaque para a etapa de Orientação (Exploração) também coincide. Mas a verdadeira inspiração vem de Takeuchi e Nonaka, os vovôs do Scrum (Gestão do Conhecimento – Bookman, 2008). Para saber mais do modelo, veja este vídeo. Para debatê-lo, participe do evento SEA: Sistêmico, Enxuto e Ágil.
    3. Clay Cutter foi compartilhada via flickr por christy sheffield.
  • PO: Quem se Habilita?

    PO: Quem se Habilita?

    Não é fácil ser Dono de Produtos. Mas não precisamos levantar restrições como aquelas colocadas pela Toyota para seus engenheiros-chefe. Doze anos de formação? Não precisamos de tanto. Dez mil horas de prática? Não faria o menor sentido.

    Um PO justifica a oportunidade e o poder que recebe quando demonstra conhecimento, comprometimento, criatividade e todo o pacote de soft skills requerido de quem pretende interagir com um sem número de pessoas. Repare: com exceção do primeiro item, não é o tipo de coisa que validamos através de provas, certificados e afins. Exigir tempo de casa ou de experiência também não faria muito sentido. Quantos com tempo de casa não têm raízes profundas em estruturas e hábitos que precisamos evitar ou questionar? Até que ponto a intervenção de um não-especialista ou de gente de fora não seria desejável? E se ela trouxer aquela dose de criatividade que falta?

    Talvez o melhor caminho seja a busca por voluntários. Dado o desafio, ainda que muito mal definido (e assim ele estará), perguntamos: quem se habilita? É provável que o candidato óbvio surja naturalmente. Assim como é possível que a pergunta gere dois tipos de problemas.

    Pior cenário: ninguém se apresentou! Das duas, uma: 1) o desafio não é nada atraente; ou 2) as pessoas estão sufocadas, desmotivadas, desorientadas. Dependendo do caso e da gravidade, talvez nem seja a hora de lançar uma nova iniciativa. A menos que ela seja uma maneira de reverter a situação. A mensagem é: não finja que não viu fidbeque tão negativo.

    Melhor cenário: várias pessoas toparam o desafio. O problema é bom porque você ganhou opções e sua decisão não precisa ser difícil. Sugestão: peça que cada voluntário apresente seu entendimento do desafio e a forma como pretende lidar com ele. Debata as sugestões com os principais envolvidos. Normalmente, o candidato ideal emerge desse processo. Vá com ela/e.

    Pra pensar

    • Provas, certificações e afins são marcas de um tempo mecanicista e reducionista que a gente tentou deixar para trás através do Manifesto Ágil.
    • As fontes primárias, genuínas e sustentáveis de motivação e inspiração são os bons desafios. O resto é doping.
    • Não é fácil delimitar o stack de conhecimentos e habilidades que um PO deve dominar. Isso é bom. Um PO é antidisciplinar (ou indisciplinado) por definição.
    • Aproveite enquanto ninguém fecha um BoK (corpo de conhecimentos) full stack para POs.  E não fique espalhando esse tipo de ideia por aí, por favor!
  • PO: Quem se Habilita?

    PO: Quem se Habilita?

    Não é fácil ser Dono de Produtos. Mas não precisamos levantar restrições como aquelas colocadas pela Toyota para seus engenheiros-chefe. Doze anos de formação? Não precisamos de tanto. Dez mil horas de prática? Não faria o menor sentido.

    Um PO justifica a oportunidade e o poder que recebe quando demonstra conhecimento, comprometimento, criatividade e todo o pacote de soft skills requerido de quem pretende interagir com um sem número de pessoas. Repare: com exceção do primeiro item, não é o tipo de coisa que validamos através de provas, certificados e afins. Exigir tempo de casa ou de experiência também não faria muito sentido. Quantos com tempo de casa não têm raízes profundas em estruturas e hábitos que precisamos evitar ou questionar? Até que ponto a intervenção de um não-especialista ou de gente de fora não seria desejável? E se ela trouxer aquela dose de criatividade que falta?

    Talvez o melhor caminho seja a busca por voluntários. Dado o desafio, ainda que muito mal definido (e assim ele estará), perguntamos: quem se habilita? É provável que o candidato óbvio surja naturalmente. Assim como é possível que a pergunta gere dois tipos de problemas.

    Pior cenário: ninguém se apresentou! Das duas, uma: 1) o desafio não é nada atraente; ou 2) as pessoas estão sufocadas, desmotivadas, desorientadas. Dependendo do caso e da gravidade, talvez nem seja a hora de lançar uma nova iniciativa. A menos que ela seja uma maneira de reverter a situação. A mensagem é: não finja que não viu fidbeque tão negativo.

    Melhor cenário: várias pessoas toparam o desafio. O problema é bom porque você ganhou opções e sua decisão não precisa ser difícil. Sugestão: peça que cada voluntário apresente seu entendimento do desafio e a forma como pretende lidar com ele. Debata as sugestões com os principais envolvidos. Normalmente, o candidato ideal emerge desse processo. Vá com ela/e.

    Pra pensar

    • Provas, certificações e afins são marcas de um tempo mecanicista e reducionista que a gente tentou deixar para trás através do Manifesto Ágil.
    • As fontes primárias, genuínas e sustentáveis de motivação e inspiração são os bons desafios. O resto é doping.
    • Não é fácil delimitar o stack de conhecimentos e habilidades que um PO deve dominar. Isso é bom. Um PO é antidisciplinar (ou indisciplinado) por definição.
    • Aproveite enquanto ninguém fecha um BoK (corpo de conhecimentos) full stack para POs.  E não fique espalhando esse tipo de ideia por aí, por favor!
  • O PO é uma Solução Simples

    O PO é uma Solução Simples

    Simples, não simplista nem simplória. O Dono de Produtos nos ajuda a lidar com a complexidade sem complicação. Sua função é inspirar e orientar o desenvolvimento de soluções criativas. É fácil explicar e justificar o PO. A gente é que complica.

    O Dono de Produtos é, por natureza, um Integrador¹. Um recurso utilizado pelas organizações para promover cooperação desafiando silos e amarrando pontas soltas. Um integrador é muito diferente dos coordenadores, supervisores e afins. A falta destes não é sentida quando executamos um trabalho. O mesmo não pode ser dito dos integradores. Dependemos deles. E eles têm todo o interesse em participar e cooperar. Porque têm “a pele em jogo”. E, para tanto, têm poder.

    A última palavrinha – poder – sintetiza boa parte dos problemas colocados anteriormente. “Poder” carrega uma bagagem pesada, consequência do mau uso e péssimos exemplos. Não precisa ser assim. Se o poder é utilizado para promover cooperação, ele não tem nada de negativo. Também é preciso entender que o poder, assim como o conhecimento, não é reduzido quando compartilhado, pelo contrário².

    Não é recomendado que gerentes de produtos ou equivalentes assumam a função de PO. Porque eles têm outros compromissos e prioridades. Um PO deve se dedicar exclusivamente à sua criação. Segundo Sutherland³, metade do tempo com os clientes e usuários e a outra metade com o time de desenvolvimento. Podemos ser mais flexíveis no rateio da agenda. Na dedicação em período integral, não.Por isso o gráfico ao lado, sugerido por Mike Cohn em Succeeding with Agile (Addison-Wesley, 2009), é uma entre outras coisas da literatura Agile “clássica” que precisamos desaprender. O PO começa com carga máxima. Aliás, a escolha do PO é o nosso primeiro desafio. Experimente, Meça (inspecione), Desaprenda e Aprenda – sem parar! Quando fortalece o PO um gerente de produtos não está perdendo nem um pouco de seu poder. Além disso, ele está satisfazendo um requisito fundamental para a verdadeira agilidade: autonomia.

    Ah, mas o gerente não confia em ninguém para assumir as responsabilidades de um PO. Ninguém? Quem contratou essa gente? Quem pediu ou autorizou a contratação? Se ninguém serve, pra que serviu o gerente?

    O PO é uma solução simples. A gente é que complica.

    Notas

    1. Reforçar Integradores é a segunda das seis regras simples – Six Simple Rules, de Yves Morieux e Peter Tollman (HBR Press, 2014).
    2. A terceira regra fala em aumentar a quantidade total de poder. Para as outras regras: compre o livro, continue seguindo o finito e considere um mergulho no SEA.
    3. Scrum (Leya, 2014).
    4. Simple & Obvious foi compartilhada por Emma Jane Hogbin Westby no flickr.
  • É Difícil Abrir Mão do PO

    É Difícil Abrir Mão do PO

    Quais são as alternativas ao Dono de Produtos (PO)? Um comitê? Não seria muito ágil. Um portão escancarado para as demandas? Aumentaria exponencialmente os riscos de desalinhamento e desperdício. Analistas de negócios? Não são diferentes dos POs sem poder. Quando entendemos o valor do recurso PO, fica difícil abrir mão dele.

    Imagine que o grupo com todos os envolvidos – clientes, usuários e desenvolvedores – tenha 20 pessoas. Vamos considerar que há apenas um tipo de relação entre elas. Sendo assim, n(n-1)/2, temos um total de 190 relacionamentos possíveis. Aumente o número de pessoas (n) e perceba o tamanho da bagunça – da variedade. POs são filtros de variedade – dos ruídos, interesses conflitantes e picuinhas mil.

    Mas não se trata de um filtro qualquer, desses que a gente pode transformar num algoritmo ou tratar como um processo de triagem. Esse filtro seria apenas uma restrição. E a gente não quer que o PO seja visto assim.

    Uma palavra nos basta: CRIATIVIDADE. Dos limões o PO faz limonada. A partir de toda a cacofonia de desejos, necessidades, vontades e caprichos o PO orienta um processo de criação. Repare, ele não cria nada sozinho. Seu valor está em fazer uso inteligente e criativo de pessoas inteligentes e criativas. Para tanto, o PO inspira essas pessoas.

    Podemos entender, então, que o PO é um tipo de facilitador, coach ou palestrante motivacional? Por favor, não! Porque um pequeno detalhe, formado por quatro letras, o diferencia dessa turma divertida: ele é o DONO do produto. No final das contas, é ele quem presta contas¹. Como diria um Taleb tupiniquim, “é o dele que está na reta”. Isso faz toda a diferença. E nos faz pensar duas vezes antes de abrir mão do PO.

    Notas

    1. Segundo o mestre Clóvis Rossi, é esta a melhor tradução para o termo accountability.
    2. A singela imagem utilizada foi compartilhada no flickr por Direct Relief. 
  • É Fácil se Livrar do PO

    É Fácil se Livrar do PO

    Jeff Sutherland se inspirou¹ no Engenheiro-Chefe da Toyota para criar o papel do Dono de Produtos (PO). O que aproveitamos desse modelo? Um EC é visto como um “super-engenheiro e líder”. Sua formação não dura menos do que doze anos. Sua posição é a mais cobiçada entre os engenheiros daquela empresa japonesa². Quanto disso nós trouxemos para os nossos POs? Quase nada.

    Ok, a nossa realidade é diferente. Não fabricamos carros. E aquele morro ali ao lado não é o monte Fuji. Mas isso não pode justificar o que vemos por aí com relativa frequência. A palavra DONO não carrega nenhuma ambiguidade. Mas não são poucas as organizações que inventaram donos de mentirinha. Gente sem autonomia para dizer nem sim nem não.

    Cansados da situação, alguns simplesmente se livraram do papel. Via Negativa! Isso tem se tornado relativamente comum: jogar fora tudo que parece difícil e não funciona logo. POs, estimativas, sprints e agora projetos. Sabe-se lá quantos bebês vão junto com a água suja. É preciso entender que uma restrição pode ser, sob outra perspectiva, um recurso.

    Um PO, para funcionar bem, precisa ser percebido como um recurso à disposição de todos os envolvidos. Um recurso verdadeiramente útil tanto para clientes e usuários quanto para o time de desenvolvimento.

    Nós não ajudamos a criar essa percepção quando afirmamos que o PO: foca no ROI; cria a Visão (sozinho); é a única voz das partes interessadas perante o time; cria a Visão do Produto e estabelece fronteiras. Essas afirmações, extraídas de alguns best-sellers da área³, reforçam o lado antipático: o PO é uma restrição, gargalo, mala, elo mais fraco, ponto único de falha etc.

    Justificar a eliminação de restrições chatas é fácil.
    Se livrar de recursos úteis, nem tanto.

    Notas

    1. Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo (Leya, 2014). Já tem uns quatro meses que esse livro figura no topo da lista de mais vendidos publicada aos sábados na Folha de São Paulo. Que bom! Mas que não seja pela desastrada promessa do subtítulo.
    2. Segundo James Morgan e Jeffrey Liker em Sistema Toyota de Desenvolvimento de Produto (Bookman, 2008).
    3. Agile Project Management with Scrum – Ken Schwaber (MS Press, 2004).
      Scaling Lean & Agile Development – Larman e Vodde (Addison-Wesley, 2009).
      Essential Scrum – Kenneth Rubin (Addison-Wesley, 2013).
      Succeeding with Agile – Mike Cohn (Addison-Wesley, 2010).
    4. Day 168 / 365 – Post-It Luv Gone Bad, de Anita Hart, decora este texto.
  • Checkup Ágil – Parte III

    Checkup Ágil – Parte III

    Terceira e última parte da série. Já conversamos sobre eficácia e eficiência, particularmente sobre a necessidade de rever nossos processos de forma a dar um pouquinho mais de atenção para o domínio do problema. Nada disso fará sentido se não considerarmos a parte mais frágil, complexa e fundamental da coisa toda. Estou falando da gente.O quinto princípio do Manifesto Ágil diz que nós devemos “construir projetos ao redor de indivíduos motivados”. Nesses tempos estranhos, as conversas sobre motivação também suscitam posições extremas. De um lado, um zelo exagerado que beira a infantilização. Do outro, um pragmatismo falso que reduz tudo ao dinheiro.

    Incoerente, vou cometer um pecado que vivo recriminando nos outros. Vou propor uma sigla pretensiosa / pegajosa:

    • Projeto/Produto: pessoas criativas gostam de trabalhar em projetos ou produtos. Uma organização, por si só, é atraente até a página três.
    • Instigante: ou inspirador. O produto ou  projeto deve representar um belo desafio.
    • Necessário: o valor prometido pelo produto / projeto, tanto para o negócio quanto para o cliente, deve ser claro. Criativos gostam do processo – do jogo jogado – mas querem se comprometer com resultados: gol!
    • Didático: o que é didático facilita a aprendizagem; é destinado a instruir. O criativo precisa perceber que vai crescer com aquele trabalho.
    • Atual: afinal, que motivação sobrevive quando descobrimos que estamos presos em uma tecnologia ou negócio ultrapassados?

    PINDA! Pindá, em tupi, significa anzol¹. Pescou?

    “Construir projetos ao redor de indivíduos motivados”. Se o projeto é bom, a motivação emerge naturalmente. Acho que seria mais correto dizer: “Construir produtos e projetos que valham a pena – que motivem”.

    Qualquer doping (metas, prêmios, badges etc) é desperdício. O doping – a motivação extrínseca e não natural – é necessário quando o trabalho não é PINDA. Ou quando outro fator – ambiente tóxico, time ruim, processo capenga, salário muito baixo – joga contra. Talvez eu tenha simplificado demais um tema complexo. Mas, para início de conversa, é só isso mesmo. Parafraseando uma propaganda de nossa pré-história², bons projetos ou produtos motivam e atraem um monte de gente boa³.

    Abaetetuba³

    Avaliar pessoas e times é sempre algo tão arriscado e com potencial para injustiças que, se a gente pudesse, evitaria. Ferramentas como a ADKAR e afins geralmente demandam muito esforço e não evitam ambiguidades nem suscetibilidades feridas. O Mapa de Talentos (Matriz Will X Skill, na versão original) abre a possibilidade de um autoexame coletivo. No eixo X capturamos as habilidades e conhecimentos de cada integrante do time. Na outra dimensão registramos sua disposição – a motivação para o trabalho. Se usado de forma aberta e sincera, este mapa permite a elaboração de um diagnóstico rápido e eficaz. Deste diagnóstico podemos derivar um plano de ação.

    Será preocupante um número grande de pessoas no quadrante C. É sinal de que o trabalho não é PINDA ou de um problema não relacionado diretamente com o projeto ou produto. Qualquer doping é paliativo e perigoso. No médio prazo, o que pode ser feito?

    Pessoas no quadrante B só querem um pouquinho de atenção e investimento. Aquelas ao seu lado direito (A) só vão virar problema se forem minoria ou panelinha do mal. Por fim, os integrantes do quadro D devem estar esperando por duas coisas: investimento ou uma carta de demissão.

    Como coloquei, o potencial de injustiças e estragos desse tipo de avaliação é imenso. Use com moderação e carinho sincero.

    Essencialismo

    Nenhum sistema, particularmente a gente, trabalha acima de 75% de sua capacidade o tempo todo. A gente cansa e quebra. A sobrecarga de informações e opções nos deixa desnorteados. O excesso de decisões e reviravoltas desmotiva. O Manifesto Ágil, em seu décimo princípio, dá a receita: “Simplicidade: a arte de maximizar o trabalho que não precisou ser feito”. O que é simples é objetivo. E o que é objetivo, concreto, nos motiva. O gráfico acima foi sugerido por Greg McKeown em Essencialismo (Sextante, 2015). Quando conhecemos e nos comprometemos com o Objetivo Essencial, simplificamos o trabalho e eliminamos milhares de decisões. É a tal bússola que citei anteriormente nesta série. Isso é ser verdadeiramente Enxuto e Ágil. Aliás, sistemicamente falando, é Ágil porque é Enxuto. Para encerrar, quem precisa de palestras motivacionais, berreiros e joguinhos quando o trabalho é inspirador por si só?

    Autoexame

    • Como fica o Mapa de Talentos da sua equipe? Algum quadrante predomina? Ele é do tipo preocupante?
    • No Mapa de Talentos, troque a palavra Disposição por Desafio. Indique naquele eixo o quão instigante o seu projeto atual é para cada integrante do time. Há mudanças em relação ao desenho anterior? Se sim, o que essa mudança significa? Você já ouviu falar no FLUXO do Csikszentmihalyi? E no ShuHaRi?
    • Você sabe dizer qual é o Objetivo Essencial de sua organização, produto ou projeto? O seu time também?
    • Agora ficou claro o que chamo de VALOR PARA O TIME? Percebe como ele é indissociável do VALOR PARA O CLIENTE e do VALOR PARA O NEGÓCIO?

    Autocrítica

    Reduzir uma transformação Ágil ou coisa do tipo em três pequenos exames é quase um desrespeito. Existem diversos outros fatores em jogo. Nesta série eu tentei destacar três pontos chave: Valor, Processo e Gente. Porque acredito que todas as outras variáveis derivam destes três pontos. No próximo artigo pretendo apresentar uma síntese na forma de um modelo.

    Notas

    1. Pedindo licença aos etimólogos, preciso dizer que PINDA e pindaíba tem origens bem diferentes. Pindaíba vem do quimbundo, uma língua africana, e significa uma situação bem difícil. Pindá é um radical tupi. Ex: Pindamonhangaba é um lugar onde se faz anzol. Tudo indica que os rios daquela região do interior de São Paulo, bastante sinuosos, inspiraram o nome da cidade. Suas curvas parecem anzóis.
    2. Dr. Bauer devia ser uma espécie de Zuckerberg dos anos 1960. Num anúncio da Informatics Inc. ele apresentou a sua segunda lei: “O talento vai onde a ação está”. Os tempos são outros. A lei segue valendo.
    3. Mais tupi: Abaetetuba significa um monte de gente boa.
    4. Bleep, Blip, Bloop – a imagem de hoje – foi compartilhada por Anita Hart no flickr.