Impacto e Esforço - PM, você não precisa esperar o time

Impacto e esforço são os dois principais mecanismos para que PMs consigam gerenciar expectativas de delivery. Geralmente o PM se foca muito no impacto, delegando esforço para o tech lead ou para o time de devs. Na minha visão, tudo errado.

Alguns pontos:

• Para começar confundimos vazão com esforço. As duas coisas são conectadas, mas não são o mesmo;
• PMs entendem que medição de vazão/esforço é tarefa do Agilista ou do TechLead/Time;
• Poucos PMs sabem medir impacto, criando uma confusão sobre o tipo de impacto e como medir esse impacto;
• PMs não colocam na conta esforço do time de design;
• Impacto não necessariamente precisa ser percebido pelo usuário;

Foca na vazão e não esforço

PMs são as pessoas que controlam o fluxo de trabalho para o time. Se você colocar 10 coisas para fazer, o time tentará pegar essas 10 coisas para fazer. Se colocar 5, o time pegará 5.

O time é responsável por falar sobre o esforço de trabalho que cada uma das iniciativas. O esforço é exatamente a estimativa do que eles entendem que precisa ser executado para uma história ser executada. Aqui já começa os primeiros problemas;

• Time tem que começar a ter a visão a partir do épico, não da história;
• Os épicos são conectados em iniciativas maiores. O Tech Lead ou o responsável pelo time técnico, e o líder de design (ou o próprio designer) precisam ter participar ou ter conhecimento detalhado das iniciativas, entendendo quais as oportunidades aquela iniciativa irá impactar e quais KRs temos que movimentar;
• O líder técnico, designer, dados e PM (ou quem mais precisar), definem o quanto da iniciativa é viável de execução;

O esforço de fazer isso, será medido pelo time. E você, como gestão de produto, não precisaria, teoricamente, utopicamente, se preocupar com o esforço, pois você sabe que o que foi contemplado dentro dessas iniciativas (épicos), são totalmente viáveis de serem executadas. Isso se você tiver já um portifólio de iniciativas/oportunidades bem feito e gerenciado... Mas essa é outra história.

Não deveria interessar para você se a história é de tamanho G, se é um chiuaua ou é 233 no Fibonacci. O esforço daquele item (geralmente história), é de preocupação do time.

Bom, se o time está calculando o esforço de um item, é porque esse item foi priorizado. Se ele foi priorizado, é porque você sabe que aquela coisa pode ser feita em tempo hábil... Por que foi você que escreveu a história e como você é alguém competente, tomou o cuidado de escrever uma história mais ou menos no mesmo tamanho de todas as outras anteriores... Guia básico de PM aqui, certo?

Saindo de pressuposto de escrita de história do mesmo tamanho... é você que controla quantas histórias o time fará. Logo, você controla a vazão do time. E como você sabe qual a vazão do time? Oras, simples: você lê o livro do Raphael Albino e descobre o que é Leadtime e Throughput.

PMs acham que medir leadtime e throughput do time é uma responsabilidade do agilista. Eu acho que, na verdade, o agilista, o time e o techlead precisam ser bastante interessados nesses números. Mas o PM é talvez o segundo maior interessado (depois do time, na minha opinião), pois com esses números você consegue garantir a gestão de expectativa de entrega com os stakeholders e com a empresa.

Logo, saber que o time entrega 5 tarefas na semana, ou 20-25 no mês, serve como base para você se comprometer com as entregas. Melhorar esse número, é responsabilidade do time com o techlead. Conhecer esse número e criar acordos/promessas/comprometimento de entrega de roadmap, é responsabilidade do PM. Claro, bons TechLeads/Tech Managers são parceiros incondicionais dos PMs e líderes de produto nesse contexto.

Impacto

Para começar, o que é impacto? A gente confunde muito quando falamos sobre impacto, por que geralmente as pessoas acham que impacto é só uma coisa, imutável, e que a definição dependerá do produto ou da empresa.