Trabalho e ensino outros a trabalharem com Scrum desde 2010. Independente das empresas adotarem ou não a metodologia ágil mais utilizada (e com mais cases de sucesso conhecidos) no mundo, sempre há o que aprender com seus métodos inusitados e com a cultura que permeia este mundo ágil em geral. Um dos pontos-chave em qualquer projeto, seja com Scrum ou não, é a priorização de tarefas – tema do artigo de hoje.

Alguns especialistas que conheço, dizem que basta perguntar ao cliente o que ele quer e depois, o que ele quer primeiro.

Pergunte ao seu usuário e/ou cliente tudo o que ele quer no software e você terá uma pilha de documentos com vários centímetros de altura e dezenas (talvez centenas) de páginas. Depois pergunte à ele o que é mais importante e ele vai lhe responder que tudo é importante. Pergunte o que é mais urgente e ele vai te responder que tudo é urgente. Esqueça, isso não funciona. Pelo menos dessa forma tão direta, não.

Como fazer então?

Cortando o escopo

Simplesmente nunca teremos tempo hábil – e nem faz sentido – desenvolver tudo o que o cliente acha que precisa no software. Principalmente na primeira versão (já ouviu falar em MVP?) e é o seu dever ensinar isso a ele.

Gerentes de projeto tem de lidar com escopo, custo e prazo nos projetos. Dificilmente conseguimos equilibrar essas três variáveis e, na minha opinião, escopo é a que faz mais sentido cortar. Não apenas porque manter um equilíbrio nessa balança de três pratos é quase utópico, mas porque é o mais inteligente a se fazer, pensando no sucesso do projeto como um todo.

Jason Fried fala no seu livro Getting Real que é melhor fazer meio-software do que um software meia boca. E eu concordo com ele.

É no escopo onde temos sempre a maior quantidade de desperdício em um projeto. E desperdício aumenta os custos e estoura os prazos, simples assim. A Toyota passou a GM com seu método Lean, focando em apenas uma coisa: reduzir o desperdício.

Mas como reduzir o desperdício de escopo?

Princípio de Pareto

Use o Princípio de Pareto ou a “regra do 80/20”, como muito bem apontada por Tim Ferriss em seu best-seller “Trabalhe 4h por semana“. Pareto determina uma relação de 80/20 ou simplesmente maioria/minoria que é aplicada há muitas coisas em nosso cotidiano. Por exemplo, 80% do uso de um software se dá em apenas 20% das funcionalidades.

Isso quer dizer que apenas 20% de tudo que for desenvolvido será utilizado realmente. O restante cairá no esquecimento.

Scrum enfatiza o foco na geração de valor para o cliente a cada entrega e a chave para geração de valor é reduzir o desperdício, priorizando muito bem o que deve ser DONE em cada Sprint. Ok, dentro do Scrum isso é uma tarefa para o Product Owner, mas se você leu até aqui, é porque de alguma forma está envolvido com as decisões de produto também, certo?

Atualmente trabalho em um banco, e como todo banco, temos alguns processos e projetos inchados, burocráticos e cheios de desperdícios. Alguns são culpa do Banco Central, outros são culpa nossa mesmo. Algumas vezes parece que Agile e Lean jamais andarão de mãos dadas com a palavra banco, mas essa é a minha função lá e tem sido um trabalho bem interessante.

Cito o case do banco, pois lá eu tenho cuidado da priorização de tarefas para os times de desenvolvimento, além das minhas atribuições normais como Scrum Master. Um app de cartão de crédito, por exemplo, é cheio de features, por mais que pareça algo simples como comprar-e-pagar. É troca de senha, de data de vencimento, aviso de viagem, solicitação de mais limite, ajuste do limite atual, etc. Se deixar, a equipe de negócios se empolga e quer um Nubank pronto em duas sprints. Quem nunca passou por isso?

Minha estratégia neste projeto foi bem simples: priorização. Não vamos entregar um Nubank em duas sprints, mas consegui priorizar as features baseado no que agregaria mais valor ao cliente o mais rápido possível. Assim, em três sprints teremos um app de cartão funcional com os 20% de features que trazem 80% dos benefícios. E sim, nós vamos entregar, pois falta apenas uma das três sprints e já estamos com boa parte das funcionalidades essenciais prontas.

Conhecendo seu produto

Mas como saber o que é mais prioritário dentre centenas de features que aparecem no backlog todos os meses?

O jeito mais óbvio é conhecendo o seu produto, o seu time e entendendo o seu mercado. Óbvio que isto não é algo simples de se alcançar e existem diversos outros fatores que impactam na priorização. Se você está lançando uma versão nova de um produto, olhar o que os usuários realmente usam na sua aplicação pode ajudar bastante a decidir o que deve entrar ou não em uma nova versão. Se está lançando um novo produto, tente entrevistar usuários de produtos concorrentes, vai lhe ajudar a entendê-los e fazer algo superior à concorrência.

Quais são as dores do seu usuário? Priorize o que “dói mais”. Se o que o usuário mais reclama é de não ter um bom limite de crédito nos cartões concorrentes, foque em fazer uma análise de crédito automatizada, eficiente e que forneça um crédito condizente com a realidade (e histórico) de cada cliente. Permitir que ele escolha a cor do seu cartão pode ficar pra depois.

O que seu usuário mais utiliza no dia-a-dia? Entregue primeiro o que ele espera como “mínimo viável” em produtos do seu nicho. Se o usuário consulta o limite disponível no cartão todos os dias, mas apenas viaja para o exterior anualmente, o que você acha que deve ser feito primeiro: consulta de limite ou aviso de viagem? Se seu usuário troca de senha do cartão apenas uma vez por ano (no máximo), mas paga faturas todos os meses, qual funcionalidade deve ser o foco nas primeiras entregas?

Este tipo de raciocínio, sem muita técnica, ajuda bastante a priorizar o que é realmente importante e deve ser posto na frente em um projeto de software.

Buy a Feature Game

Obviamente existem diversas técnicas que podem ser utilizadas pra fugir do “achismo” e até mesmo lidar com conflitos de egos que muitas vezes irrompem em reuniões para priorização de backlog. Vou falar da minha favorita: a técnica Buy a Feature Game, que é bem simples, lúdica e eficiente.

Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas aquelas que já estão no roadmap próximo e/ou são minimamente importantes ao projeto. Cada card postado na mesa deve ser lido com a atenção de todos. O ideal é que cada card possua um “preço” também, que pode ser a estimativa de horas para desenvolvimento ou os story points, mas se não estiver tudo estimado, não invalida a dinâmica, apenas reduz um pouco a sua eficiência.

Para cada um dos envolvidos na priorização (de 4 a 7), geralmente stakeholders ou até mesmo usuários, entregue à eles um maço de notas falsas, tipo Banco Imobiliário. Se todas as tarefas estiverem estimadas e com “preço”, some os preços, divida o valor pelo número de participantes e distribua esta quantia em notas para cada participante (poucas notas grandes, muitas notas pequenas).

O dinheiro da dinâmica pode ser apenas post-its com os valores escritos ou dinheirinho de brinquedo, à venda em bazares. Apenas não permita a fabricação de dinheiro falso ao longo da dinâmica nem injeção ou lavagem de dinheiro aproveitado de outras dinâmicas.

Se você estiver trabalhando com story points ou horas e já souber quanto o seu time entrega por sprint, divida essa quantia entre os participantes em notas, seguindo aquela mesma lógica do Banco Imobiliário – poucas notas grandes, muitas notas pequenas. Você pode jogar o B-a-F Game uma vez para várias sprints, por exemplo, somando a capacidade das sprints na hora de distribuir as notas.

Se suas sprints são de 15 dias e você entrega 30 pontos em cada sprint, você pode priorizar uma vez a cada 30 dias, emitindo 60 pontos de notas para os participantes, por exemplo. Para que os valores não fiquem muito limitados, sugiro multiplicar story points por $10 ou até $100 mesmo, enquanto que horas geralmente não possuem esse problema.

Sem nenhuma regra, cada participante pode depositar o seu dinheiro sobre cada card, representando o seu interesse e/ou o quanto aquela feature vale a pena ser implementada. Aqui, cada um terá a sua própria percepção de prioridade, mas como o dinheiro é limitado, eles serão obrigados a trabalhar com esta limitação na hora de distribuir as notas.

Esta limitação de dinheiro ilustra bem as limitações reais de um projeto como a verba, as horas-homem e etc. Ajuda os stakeholders a “sofrerem” com as decisões difíceis que o gerenciamento de um projeto exige. Caso seus cards possuam outras limitações, como precedência, crie combos de produtos do tipo “para comprar esse, tem de comprar o outro primeiro”.

Quando todos terminam sem dinheiro (deixe que discutam e troquem as notas de lugar até o final da dinâmica), basta somar quanto cada card recebeu e os que receberam mais dinheiro são os mais prioritários. Opcionalmente, se estiver trabalhando com as estimativas, uma feature só vira de fato prioridade se ela recebeu um valor mínimo equivalente ao valor necessário para sua compra.

Se uma feature exige 100h de desenvolvimento, ela não entrará na próxima sprint se não alcançar $100 de ‘doações’ dos stakeholders, por exemplo.

Permita uma pequena discussão sobre o resultado da distribuição de notas logo após exibir os cards que se mostraram mais prioritário (i.e. que receberam mais $). Isso tende a gerar algumas movimentações de capital, o que é perfeitamente normal, mas ao término da sessão, o que ficou definido é o que será utilizado como prioridade do backlog e orientará os times nas próximas semanas.

Obviamente que nenhum método é perfeito, mas assim como o Planning Poker, este método baseia sua eficácia no consenso entre os envolvidos no projeto e o conhecimento que cada um tem do produto e do mercado para priorizar de uma maneira caótica, mas organizada.

E aí, o que achou desta técnica? Conhece alguma outra? Compartilhe nos comentários!