PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Dono do Produto

  • 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.
  • O Problema do Cliente

    O Problema do Cliente

    Hoje o problema não é nosso. Mas a gente quer que seja. Pretendemos desenhar um produto ou serviço que melhore a vida de um cliente. Por onde devemos começar? Quais ferramentas podem nos ajudar? Quais hábitos e mal entendidos colocam em risco a nossa empreitada?Ideias não faltam. Estamos cheios de hipóteses. Mas elas não são um bom ponto de partida para o desenho de um novo produto ou serviço. Por estranho que pareça, é preciso dizer: antes da solução deve haver um problema. A formulação de boas hipóteses requer o entendimento e a definição do problema. Necessidades, tendências e ofertas concorrentes são estopins tradicionais. O mundo está cheio de exemplos de como essas fontes de inspiração podem ser frágeis e traiçoeiras. Microsoft Zune, os óculos do Google, Segway e a Antarctica Sub Zero não me deixam mentir sozinho. Lá se vão vinte e cinco anos desde que a Teoria JTBD (Jobs to be Done – Trabalhos a Executar) foi apresentada¹. Parece que agora ela pegou. Em que ela é diferente dos estopins tradicionais? No olhar de fora para dentro. Na preocupação com o entendimento de um contexto, causas e motivações. Entender o porquê, num primeiro momento, é mais importante do que elucidar quem e o quê. JTBD não são inventados. Nós os descobrimos. Nesta sequência de artigos mal acoplados eu tenho insistido na palavra descoberta. Na conversa anterior eu mostrei como a ferramenta enxuta 5 Porquês, devidamente amparada em modelos sistêmicos, nos ajuda a descobrir a verdadeira raiz de um problema. JTBD é uma teoria e ferramenta mais específica. Mas parte do mesmo princípio: precisamos descobrir – esclarecer, revelar uma situação.

    Lavar roupa em casa.
    Tornar menos desagradável a espera no consultório médico.
    Ir do endereço A para o endereço B com conforto, rapidez e sem gastar muito.
    Comunicar o estado de um projeto respeitando o tempo e a inteligência de todos os envolvidos.
    Afastar a filha do smartphone por duas horas consecutivas.

    Ao apreciar um JTBD devemos considerar três dimensões:

    • Funcional: qual é, de fato, o trabalho a ser feito. Aqui sempre temos um verbo – uma ação devidamente contextualizada.
    • Emocional: como a pessoa espera se sentir ao executar aquele trabalho. Ou ao se ver livre dele.
    • Social: como a pessoa quer aparecer. Não leve em conta apenas as questões narcisísticas. Mas não as ignore.

    Completamos o quadro ao listar as principais coisas que o cliente quer e aquilo que ele não quer (receber, sentir, arcar) ao executar aquele trabalho. Essas informações podem ser capturadas na forma de um Mapa de Expectativas. Uma ferramenta que permite que o negócio também descubra o que ele quer e não quer quando fornece determinada solução.Essas fotografias nos ajudam a entender por que um cliente contrata determinada solução e demite outra(s). Repare nesse jeito de pensar: o cliente não compra produtos ou serviços, ele contrata soluções para se livrar de problemas. Nem sempre essas decisões estão relacionadas com aspectos funcionais. Aliás, dependendo do JTBD, a dimensão funcional pode ser a menos importante.

    Isso basta? JTBD é uma varinha mágica que nos leva para o mundo da solução perfeita? Longe disso. Agora é que o trabalho de análise começa a ficar divertido.

    O Mapa de Transformações

    JTBD bem capturados nos mostram o que precisa ser feito. No mapa ao lado eles aparecem no eixo vertical. A dimensão horizontal nos permite brincar com o como: COMO o trabalho será realizado, contratado, precificado, distribuído e suportado. Enfim, neste eixo nós começamos a cogitar alternativas de solução. Vamos conhecer melhor o mapa. Sua origem é um diagrama apresentado no livro Dual Transformation, de Scott Anthony, Clark Gilbert e Mark Johnson (HBR, 2017). Na falta de um nome, o batizei Mapa de Transformações. Ele é composto por quatro áreas.

    A primeira, no canto inferior esquerdo, representa o Core Business – no caso de uma empresa já existente, está aqui o JTBD que ela atende. A segunda área é representada pela seta ADJACÊNCIAS. Ela acomoda outros JTBD. Repare: todos eles compartilham o modus operandi, ou seja, o COMO. Pense na Amazon vendendo livros, brinquedos ou roupas. O JTBD muda. O COMO é praticamente o mesmo.

    A terceira área do mapa é chamada de Transformação A (seta horizontal). Aqui brincamos de reinventar o hoje. Formulamos hipóteses sobre como criar, entregar, precificar, cobrar e suportar determinada solução para um JTBD. A Netflix mudou dos átomos (DVDs) para os bits (streaming). O JTBD é o mesmo: curtir filmes e séries no conforto de nossas casas. A forma de realizá-lo ficou radicalmente diferente.

    Na quarta e última área do mapa somos convidados a criar o amanhã. É a seta diagonal, a Transformação B. Nela contemplamos novos JTBD e novos modelos de operação, comercialização e suporte. Sua intenção é nítida: resolver o que Clayton Christensen chamou de O Dilema da Inovação (MBooks, 2011). Quem fica bitolado, se iludindo com melhorias incrementais numa zona confortável (Transformação A), pode ser surpreendido por um sanguinário e impiedoso cisne negro. A Transformação B, combinada ao jeito Ágil de pensar, come cisnes negros no café da manhã². A Amazon Web Services é um bom exemplo desse tipo de transformação.

    Conclusão

    Essa combinação de três ferramentas (JTBD, Mapa de Expectativas e Mapa de Transformações) nos ajuda a dar os primeiros passos no sentido de descobrir um problema. O Mapa de Transformações facilita a descoberta e classificação de hipóteses. E nos joga na cara a importância de tratar simultaneamente o hoje e o amanhã. Pense em como essa classificação pode ser útil na elaboração de um portfólio e de roadmaps de produtos, por exemplo.

    Quando comecei esta série falei que deveríamos compreender e diferenciar o VALOR PARA O CLIENTE, o VALOR PARA O TIME e o VALOR PARA O NEGÓCIO. Scott Anthony, em outro trabalho (The First Mile – HBR, 2014), fala da tríade da primeira milha. São três perguntas que precisamos responder:

    1. Há um Trabalho a Executar? A quem ele interessa?
    2. A gente dá conta de criar uma solução viável? Esse trabalho nos motiva?
    3. Essa solução cria valor para o nosso negócio? Quanto?

    O próximo artigo, a terceira parte de nosso Checkup Ágil, vai tratar do segundo ponto acima e explicar o que chamo de VALOR PARA O TIME. Na sequência, eu acho que devo sintetizar as ideias apresentadas nesses nove artigos em um modelo.

    Notas

    1. Anthony  Ulwick é o pai e explorador da criança. Clayton Christensen a popularizou através de seus artigos e livros. Do primeiro há este livro gratuito e um Canvas JTBD. Pois é, mais um canvas…
      Do Christensen eu sugiro a leitura de Muito Além da Sorte (Bookman, 2017), que trata só da Teoria JTBD e suas aplicações.
    2. É muito legal ver como o Movimento Ágil é percebido em situações muito distantes do desenvolvimento de software. Em The Social Labs Revolution (Berrett-Koehler, 2014) Zaid Hassan escreve que “O Ágil come cisnes negros no café da manhã”. Ele mostra como o Scrum ajuda ONGs e similares a resolver problemas realmente complexos, como desnutrição, doenças e analfabetismo em regiões paupérrimas ao redor do mundo. São exemplos que ajudam a rebater alguns mal entendidos que pipocam aqui e ali no mundo Ágil. Mais que isso: mostram como o Movimento ficou grande e maduro por causa e apesar da gente de TI.
    3. Apple of StickyNotes é o título da imagem acima. Compartilhada por StephenMitchell no flickr

  • FDP – Sprint Review II

    Prometi esta segunda revisão para a semana passada. Mas a agenda e o medo de que meu entusiasmo contaminasse a avaliação me impediram. Entusiasmo? Sim – o evento foi bom pra caramba! Tanto que só consegui baixar a adrenalina lá pelas duas da matina, depois de incontáveis rodadas de chopps. Agora, com o espírito crítico devidamente calibrado, tentarei escrever uma honesta prestação de contas.

    .:.

    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.

  • FDP – Sprint Review I

    No artigo que escrevi sobre “O Dono do Produto” prometi mostrar um pouco mais sobre a oficina “Formação de Donos de Produtos“. Vou fazê-lo em duas partes. Na próxima semana, logo após a estreia, publicarei uma prestação de contas com avaliações dos participantes. Hoje, neste primeiro Sprint Review, tentarei explicar a mecânica e filosofia do evento.

    .:.

    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.