Polêmica! Ainda esses dias, conversava com um responsável pelo capítulo de agilidade de uma startup sobre reports de projeto sedutores e o mal que eles podem fazer.

A situação é a seguinte: não habituados com a forma como as métricas de projetos ágeis são apresentadas – CFDs, histogramas de Throughput, Lead Time etc. – e na ânsia de mostrar que tudo vai bem, um dos POs pede para um designer experiente criar um report mais bonitinho. O designer cria um dashboard lindão com alguns semáforos, barras de progresso mostrando percentuais de completude, acelerômetros e uma série de pirotecnias para comparar o avanço das iniciativas que estão em paralelo. Seduzido pela beleza daquele report, o head de produtos “sugere de maneira convincente” aos outros POs a utilização daquele formato lindoso. E aí é que começam os problemas.

Nos tempos em que o PMBoK reinava como padrão inquestionável de boas práticas em gestão de projetos, começaram a surgir os PMOs (escritórios de projetos) corporativos e também a maior parte das distorções na interpretação dessas boas práticas. Logo, PMO virou um papel. O PMO (pessoa), quando empoderado pela corporação, rapidamente lançava sua MGP (Metodologia de Gestão de Projetos), acompanhada de seu “Kit PMO”, composto de template de termo de abertura, 3 planilhas, “Template de Change Request”, e, pra fechar o kit, o famoso “Template Powerpoint de Status Report”.

A abordagem ágil simplifica tremendamente os reports. Para quem usa “ágil básico” como Scrum, o mais comum é usar medidas de velocidade e gráficos de Burndown. Numa abordagem ágil mais avançada, podemos usar Throughput, Burnup, Lead Time dentre outras variações. Essas abordagens costumam ser bem mais precisas, mas não são tão elegantes quanto os reports “dashboard style”; Mais que isso, ainda não existe massa crítica cultural suficiente para adoção dessas métricas e várias pessoas que são gestores atualmente foram “educadas” com as métricas tradicionais. Talvez uma abordagem híbrida possa ajudar, mas pra chegar lá precisamos entender, afinal, porque fazemos esses reports.

Mas afinal, para que servem os Reports?

Reports de projeto tem duas funções básicas:

• Manter as expectativas dos stakeholders alinhadas: um projeto envolve investimento e expectativas. É muito ruim frustrar essas expectativas. Pior que isso, é frustrar essas expectativas tarde demais. Os reports buscam manter as expectativas sob controle, diluir a frustração ao longo do projeto.
• Transparecer a situação do projeto e tomar ações de controle: É normal um projeto não sair conforme o planejado. O que não pode faltar, entretanto, são ações para trazer o projeto de volta a uma situação saudável. Mas você só consegue tomar ações de controle e adaptar o projeto se tiver a consciência da situação do projeto.
  Como o PMBoK aborda os reports?De maneira resumida, o PMBoK propõe que esses objetivos sejam obtidos através de 3 visões:
  • Passado: Progress Report, ou relatório de progresso;
  • Presente: Status Report, ou relatório de status/situação do projeto
  • Futuro: Forecast Report, ou relatório de previsões/projeções

Para gerar essas visões, o PMBoK utiliza “Baselines“, ou linhas de comparação. O conceito é bem simples: comparar o planejado contra o realizado. O baseline representa o planejado. O realizado é obtido através das medições que você faz ao longo do projeto.

O PMBoK propõe também o uso do método do valor agregado. A ideia originalmente é boa: desenhe uma linha do tempo do projeto numa dimensão horizontal.  Essa linha representa o baseline de tempo, também chamado de Cronograma. Desenhe também uma linha representando os custos na dimensão vertical.

Entenda quanto custa cada entregável do projeto e em que momento ele deveria ser entregue. Plote uma linha de “Valor Planejado Acumulado”, que representa quanto você deveria gastar ao longo do projeto. Essa linha representa o baseline de custos, também chamado de Orçamento;

Ao longo do projeto, desenhe uma segunda linha representando a grana que você realmente gastou no projeto. Essa é a linha de custos. Apresente também uma terceira linha com o valor planejado inicialmente das entregas realizadas. Essa é a linha do valor agregado, que mede o escopo entregue. Nessa única visão você representa os baselines de tempo, custo, e escopo, nas dimensões de planejado e realizado. Assim, você é capaz de dizer se o projeto está adiantado, atrasado e se o orçamento está sendo cumprido ou se você está torrando grana além do necessário. No exemplo abaixo você pode notar que o Valor Agregado está abaixo do valor planejado, portanto foi produzido menos do que era esperado para aquela data. Logo, é um sinal de que o projeto está atrasado.

Adicionando nessa mesma visão o custo real do projeto, você pode dizer se está abaixo ou acima do orçamento, se vai precisar de mais grana ou a grana prevista inicialmente vai dar pro gasto. No exemplo abaixo, o Custo Real está acima do planejado na data do status, logo, o projeto está gastando mais grana do que deveria:

Usando os índices de performance obtidos pela comparação do planejado contra o realizado, você consegue fazer projeções de tendências como as da figura abaixo e dizer quando o projeto terminará e quanta grana vai precisar além daquilo que previu. Consegue calcular percentuais de completude do projeto e desenhar indicadores super precisos.

SÓ QUE… essa visão tem algumas premissas muito claras:

• Você sabe exatamente qual é o custo de cada entregável do seu projeto: Essa premissa é ótima para trabalhos preditivos, mas não servem para o trabalho do conhecimento, onde as entregas são “soft” e é impossível determinar o custo exato de cada pacote ou entrega;
• Você controla os custos do seu projeto por entregável: A maior parte da força de trabalho das organizações hoje é composta por trabalhadores do conhecimento. Isso faz com que os custos dos projetos, incluindo mão de obra, materiais etc., seja alocado principalmente em forma de bolsões, para facilitar a gestão. Isso faz com que na maioria dos projetos, no máximo,  seja controlado o apontamento de horas e nunca por entregável (pelo menos eu nunca vi);

• Existe pouca variabilidade no escopo: Numa abordagem preditiva, seu nível de risco em relação ao escopo é pouco; Isso permite que você tenha uma visão do projeto como um todo e por consequência um nível de conforto para se comprometer com o escopo num ponto muito próximo ao início do projeto, tornando essas projeções mais valiosas

Essa distorção entre a teoria baseada em projetos preditivos e a prática da gestão de projetos na vida real faz com que esses reports baseados em valor agregado gerem a falta de transparência. Como é impossível calcular corretamente esses percentuais no trabalho do conhecimento, sempre (pelo menos eu nunca vi não acontecer) os gestores responsáveis acabam inferindo alguns valores e gerando os famosos indicadores melancias: aqueles que são verdinhos por fora, mas por dentro, na verdade são vermelhos. O gestor do projeto reporta que está tudo bem, mas na verdade o projeto está com problemas. Isso fere os pilares de transparência e adaptação da agilidade.

O PMBoK também propõe algumas “regras” como forma de avaliar o percentual de completude das entregas de um projeto, para evitar inferências e a síndrome dos 99%, também conhecida como barra de progresso do Windows, que ocorre quando o 1% final do trabalho de uma entrega leva mais tempo que os outros 99% juntos:

• 20/80: Quando o trabalho é iniciado, são reportados 20% de progresso. Os outros 80% são reportados apenas quando o trabalho é concluído.
• 50/50: Quando o trabalho é iniciado, são reportados 50% de progresso. Os outros 50% são reportados apenas quando o trabalho é concluído.
• 0/100: Não tem meio termo. O progresso é medido apenas quando o trabalho é concluído.

Abordagem Agile

Minha intenção com esse artigo não é explicar em detalhes como funcionam métricas numa abordagem ágil. Se você quiser se aprofundar, sugiro você fazer o curso por email do meu colega Raphael Albino, que já escreveu até livro sobre o assunto. Limitar-me-ei a citar alguns exemplos, na profundidade suficiente para que possa rolar uma comparação entre a proposta do PMBoK, que é mais preditiva, com a proposta mais adaptativa:

• O Burnup é o MVP da Curva S.

Como não conseguimos estimar custos em trabalhos do conhecimento, surgiu então uma versão simplificada da curva “S”, o “Burnup”, que traz apenas as dimensões de tempo e escopo.

Veja que o burnup permite acompanhar o progresso e também fazer projeções, igualzinho ao que era proposto pelo método do valor agregado, só que de forma bem mais simples.

• Dá pra fazer Forecast até quando o escopo não está fechado.

Uma outra questão que surge quando trabalhamos com Agile é que o escopo não tem um limite claro. Quando a gente trava o escopo por sprint, por exemplo, podemos usar o burndown para acompanhar esse progresso, mas fica complicado fazer um burndown para a iniciativa como um todo, pois a flexibilidade do escopo pode distorcer essa projeção.

Quando trabalhamos com sistema puxado e queremos saber quanto tempo  alguma coisa vai demorar para ficar pronta depois de iniciada, podemos usar uma análise de “lead time”, baseado no histórico de entregas, bastando para isso o cuidado de manter os pacotes medidos com tamanhos similares.

• No Agile é sempre 0/100

A principal medida de progresso é software em funcionamento. Princípio 7/12 do manifesto ágil. Substituamos software por produto/serviço. Significa que para contar progresso de verdade, só vale quando aquilo que você está produzindo atingir sua “Definição de pronto”. Aí você pode reportar progresso.

Uma abordagem híbrida – Tá quantos por cento pronto?

Gostaria de compartilhar com vocês uma abordagem que eu utilizei para conseguir reportar em formato lindoso, com percentuais de completude, a Sponsors e Stakeholders que não estavam acostumados com métricas ágeis. Você também pode usar isso como estratégia de transição.

Utilizei essa abordagem em projetos nas seguintes situações:

1. Medir o progresso da especificação de um novo sistema: Nessa ocasião estava prevista a construção de aproximadamente 200 Casos de Uso para um sistema de controle jurídico para um grande banco. Ah! Mas Caso de Uso não é Agile. Fazer essa especificação toda é cascata. Pois é, eu sei disso. Peço que ignore essa parte e mantenha o foco no escopo desse projeto: Trabalho do conhecimento, produzir 200 itens de tamanho variado. Necessidade de acompanhar o progresso do projeto em percentuais para um público que não fazia ideia do que era Agilidade.
2. Criar uma base de conhecimento de lições aprendidas e melhores práticas para gestão de incidentes e gestão de problemas num grande banco: Esses problemas envolviam toda a área de tecnologia, passando por sistemas, infraestrutura de servidores, telecomunicações etc. Os itens também tinham tamanhos variados.
3. Um programa de otimização do value stream de desenvolvimento de sistemas, com diversos projetos, sendo que alguns adotavam abordagens ágeis e outros não, mas o report do programa precisava ser feito de maneira unificada.
4. Construção de um novo sistema usando métodos ágeis; Construir um sistema novo usando Scrum, mas reportando para alguns stakeholders que só entendiam abordagens preditivas.

A receita que veremos a seguir é bem simples; No final, você sai com um percentual de completude realista e consegue montar reports lindosos com ajuda de designers experientes.

Passo 1: Tenha um backlog para a iniciativa.

Essa parte é fácil, todo mundo que trabalha com Agile tem um backlog. Quem trabalha com o modelo preditivo também. Basta fazer uma lista das suas entregas do projeto.

Passo 2: Escolha uma das regras de completude.

Eu sei que pra Agile é 0/100, mas o problema com essa visão é que, num projeto de longa duração ou num projeto híbrido, que também tenha entregáveis preditivos, o progresso pode demorar muito para acontecer. Essa abordagem, apesar de mais realista e conservadora, pode gerar muita ansiedade nos stakeholders. Por vezes, essa ansiedade pode se transformar em pressão para voltar às abordagens preditivas, o que é “não bom˜.

No exemplo abaixo, escolhi aplicar a regra de 20/80; Significa que os itens que ainda não foram iniciados serão reportados com 0% de progresso; Os itens que já foram iniciados serão reportados com 20% de progresso; Os itens concluídos serão reportados com 100% de progresso.

Passo 3: Apure o percentual de completude dos itens do seu projeto

Thchanaaam!!! Note que dos itens iniciados, um deles está no início da esteira (item 4, em construção) e outro já está num passo mais avançado (item 2, em QA). Mas usando essa abordagem, ambos são reportados com 20% de completude.

O percentual de completude do projeto é obtido através da média dos percentuais de cada item. No caso (0% + 20% + 100% +20%) / 4 itens = 35%. Já imaginou o tipo de coisa bonita que você pode fazer com essa informação?

Passo 4: Faça as previsões.

Esse é o principal valor dos reports: Manter as expectativas alinhadas. Sugestões de coisas que você pode fazer:

• Se você tem uma data alvo, você pode calcular o percentual de progresso necessário por semana do projeto e estabelecer um baseline de qual o progresso necessário para atingir essa data. Aí você pode fazer um burndown para demonstrar o progresso!
• Você pode pegar o progresso semanal e fazer uma projeção para calcular quantas semanas serão necessárias para chegar no 100%. Aí você pode fazer um burnup para demonstrar seu forecast!
• Você pode construir barrinhas de progresso divididas por semana, para ter uma visão do passado.
• Você pode aproveitar o status para reportar possíveis impedimentos aos itens que já estão na esteira produtiva.
• Você pode acrescentar outras variáveis ao seu backlog e calcular percentuais de progresso independentes, por exemplo: Épicos, frentes de trabalho. Se estiver gerindo um programa, você pode demonstrar equipe responsável ou o projeto.

Passo 5: Cuidado!

Veja, essa é uma abordagem híbrida. Ela está sujeita aos mesmos desvios comportamentais que os relatórios de progresso dos kits PMO tinham ao tentar aplicar abordagens preditivas a trabalhos do conhecimento.

Coisas que podem rolar e você tem que ficar esperto:

• Alguns stakeholders podem se sentir tentados a iniciar itens e abrir muito WIP, só pra ganhar os 20% do progresso inicial e aparecerem bonitos na foto, digo, no report. Nesse caso você tem algumas saídas: mude a regra de progresso para 0/100; mantenha rígida a regra de limite de WIP; Use outras métricas ágeis para demonstrar o efeito negativo de muito WIP aberto: CFD costuma ser uma boa, mas vale Lead Time e Throughput também.
• O percentual de completude pode regredir em algumas situações;

• O aparecimento de defeitos pode fazer com que se gere um certo retrabalho. Para lidar com isso você pode: reforçar na sua definição de pronto que somente itens com defeitos resolvidos são considerados prontos.

• O crescimento do backlog por débitos técnicos, descobertas e refinamento vai fazer o percentual de completude total regredir. Se esse for um problema mais constante, você pode calcular a taxa de crescimento do backlog e fazer uma projeção baseada nessa taxa. Você pode também demonstrar o percentual  de completude apenas dos itens cuja produção já está acordada e não do backlog completo. É o ponto do replenishment do Kanban ou do planning do Scrum. Você cria uma cerimônia para assumir o compromisso e nessa cerimônia você já informa que o escopo do projeto aumentou e que portanto o percentual de completude irá regredir. 

É isso minha gente, espero que com essas dicas você tenha ampliado sua “caixinha de ferramentas” e possa escolher a abordagem de reports mais adequada! As abordagens híbridas cabem muito bem em contextos onde está ocorrendo a transição para abordagens ágeis, como forma de minimizar a resistência à essa mudança. Cabem também nos contextos de escala de programas, para ter um report padronizado quando onde a melhor abordagem para parte das entregas é preditiva e outra parte é adaptativa. Deixe seus comentários, feedbacks e conte pra gente sua história com reports de projetos sedutores.