Aviso: Este artigo NÃO é exaustivo no esforço de encontrar alternativas de medição de valor. Não existe escolha errada, ou método não aplicável; e todos são bem-vindos para sugerir novas ideias.

Antes que alguém pule da cadeira, deixo claro: não existe nenhuma medição de valor que substitua receita. Em uma situação ideal, você deve ser capaz de medir tudo que faz em $$. No entanto, situações ideais são raras. Se não é este o caso, como você mede valor?

Na minha experiência, o cenário mais comum é: você tem clientes ou stakeholders. Eles exigem que alguma funcionalidade seja priorizada no seu backlog. Você procura entender suas necessidades e descobre que o que eles têm em mente é diferente daquilo que é necessário desenvolver para trazer os resultados que eles querem. Você refina seu backlog mais uma vez e diz “Ok! Agora que todos concordamos e sabemos o que vamos fazer, preciso definir quanto valor isso agrega para o produto. Vocês podem me ajudar a definir métricas para isso?”.

Uma página em branco

Geralmente, este é o momento em que eles começam a fazer cara de paisagem. Você diz “então, gente… Definição de valor? Quanto devemos ganhar ao implementar este item? Ou quanto vamos economizar…?”.

Nada.

Ok, então eles apresentaram essa necessidade premente a você – já descontando que tentaram enfiar uma solução técnica pela sua goela abaixo – e insistiram que ela era vital para o negócio e absolutamente urgente. Talvez, tenham temperado um pouco e dito “vai vender mais” ou “vamos poupar dinheiro”, mas quando você pergunta quanto, a melhor resposta que eles têm para oferecer é “muito!”. Não só você descobre que não há qualquer tipo de base em dados para fundamentar esta suposição, como também não há qualquer expectativa de métricas sobre como aferir se a suposição se provará verdadeira ou falsa. E aí que você pensa “meu backlog estava tão legal antes…”.

Se você for um tipo de unicórnio de TI, você conseguirá ser firme e dizer para seu cliente/ stakeholder que ele tem que conseguir ao menos algum tipo de base de informações antes de vir conversar sobre esse assunto novamente. Porém, se você é uma pessoa de verdade, no mercado de TI de verdade, você terá que encontrar outra forma de medir valor e priorizar seu backlog.

Existem 10 tipos de pessoa…

A forma mais simples de determinar valor por item de backlog é pedir para seus stakeholders pontuarem cada item de 1 a 10 em importância e fazer uma média. Se alguém decidir perverter a métrica pontuando todos os itens como 10, você pode pegar um item que você sabe ser menos relevante e dizer “já que estão empatados, vamos fazer esse aqui primeiro” e assistir enquanto eles surtam.

Pela pontuação média, você conseguirá priorizar o backlog completo, mas lembre-se de que é útil manter um registro da pontuação atribuída por cada stakeholder para comparação posterior, frente aos resultados.

F de Fibonacci

Esta é mais familiar para quem já trabalha com times que usam planning poker pontuado com Fibonacci. Entreviste seus stakeholders, distribua as cartas, explique por que times ágeis usam Fibonacci e comece um poker de priorização para definir o valor de cada item de backlog.

Este método funcionará bem se seus stakeholders tiverem a agenda disponível, uma relação amigável entre si e uma relação próxima com você. Lembre-se apenas de que, se começar a medir valor em Fibonacci (ou qualquer outro método), você tem que usar o mesmo em todo o backlog, senão será impossível priorizar por valor.

RUT não é uma pessoa, mas é sua amiga

Depois de algumas experiências bem sucedidas usando a pontuação de 1-10 e Fibonacci, resolvi voltar minha atenção para os casos em que eu não podia contar com métrica de receita esperada, mas em que estes métodos também não estavam funcionando. Lembrei de ter estudado um método de priorização chamado GUT, mas ele também não funcionou como eu esperava.

Sendo um monstrinho pragmático, decidi fazer adaptações ao GUT, e criei a RUT, minha grande amiga até hoje.

O motivo pelo qual RUT funciona em cenários em que outros métodos de priorização falham é porque ela força você e seus stakeholders a avaliarem de forma objetiva cada aspecto do item de backlog e elencá-los usando definições específicas, o que minimiza a subjetividade do processo.

Funciona assim: para cada item de backlog, você deve criar 3 colunas:

• Relevância
• Urgência
• Tendência.

Em cada coluna, você irá responder uma pergunta sobre aquele item, escolhendo uma das 5 possíveis respostas abaixo.

Relevência: quão importante é este item?

1 = não é importante. Seria bom ter, mas ficaremos bem sem ele

2 = desejável, seria bom ter

3 = importante

4 = muito importante

5 = é vital e tem muito valor

Urgência: quão imediata deve ser a implementação?

1 = implementar agora não faz diferença. Dá para esperar

2 = não é confortável, mas dá para esperar

3 = é muito desconfortável, é importante lançar na próxima release

4 = é urgente, teremos problemas se não estiver na próxima release

5 = é irritante, urgente, e não podemos nos dar ao luxo de esperar para lançar.

Tendência: Como fica o cenário, à medida que o tempo passa sem esta implementação?

1 = a primeira impressão não é boa, mas o usuário se acostuma

2 = pode ser problemático continuar sem isso

3 = teremos problemas se não implementarmos em breve

4 = quanto mais tempo passa, mais problemático fica

5 = piora a cada dia, é extremamente desgastante

Você pondera e registra o resultado e, em seguida, multiplica as três colunas. O backlog deve ficar parecido com isso:

Posteriormente, você pode dividir o valor pelo esforço e priorizar seu backlog levando em consideração também o custo que um item irá representar, ou seja, usando uma métrica de ROI. Isso ajudará a identificar que itens devem ser feitos primeiro, não só porque agregam maior valor, mas também porque têm um maior retorno sobre o custo investido.

Nunca esqueça o feedback

É muito bom termos um leque de métodos para medir o valor esperado do nosso trabalho. No entanto, é necessário lembrar que isso não é suficiente.

Acima de tudo, você deve encontrar formas de validar estes atributos após a implementação (com ferramentas como analytics, pesquisas etc) e oferecer feedback para seus stakeholders, de forma a mostrar se a percepção que eles têm de valor está realmente se traduzindo em valor agregado ao produto.

Assim, você poderá, inclusive, melhorar a forma como você trabalha essa expectativa, tanto para você mesmo, como para o seu cliente.

O que acha? Ficou alguma dúvida ou tem alguma sugestão? Aproveite os campos abaixo!