Mais sobre priorização de roadmaps

Como comentei em meu artigo anterior, priorização é uma das principais tarefas de um PO e de um PM, e é o diferencia um PO de um BA. Escrevi um artigo sobre as várias formas de priorização e sobre como dizer não aos inúmeros pedidos que recebemos tanto dos clientes quanto das pessoas de dentro da empresa.

Como o passar do tempo aprendi mais maneiras de se priorizar um roadmap e queria compartilhá-las aqui.

Sequenciador de Funcionalidades

O Sequenciador de Funcionalidades foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

O Sequenciador de Funcionalidades ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o sequenciador de funcionalidades irão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

De acordo com Paulo Caroli, em seu livro Direto ao Ponto, Criando produtos de forma enxuta, o Sequenciador de Funcionalidades funciona da seguinte forma:

Feature é a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: imprimir nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrição de uma feature deve ser o mais simples possível. O usuário está tentando fazer uma coisa. O produto deve ter uma feature para isso. Que feature é essa?

Cada cartão de feature possui uma cor representado o nível de incerteza, e marcações para o nível de esforço e o valor de negócio. Por exemplo, a figura acima mostra features em index cards, nas quais foram adicionadas marcações de $, $$ ou $$$, respectivamente, para valor de negócio alto, muito alto e altíssimo, bem como E, EE, ou EEE, respectivamente, para nível de esforço baixo, médio e alto. O nível de incerteza é representado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente.

O nível de incerteza da Feature refere-se ao grau em que a Feature é incerta, a partir do ponto de vista do entendimento de negócio e do entendimento técnico. Isso é indicado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente. O entendimento da Feature de acordo com os desafios técnicos, e os requisitos de infraestrutura. Você já fez isso antes? Você sabe como fazê-lo? Um sim bem firme indica elevado nível de entendimento técnico. A clareza do objetivo da Feature, o benefício para o negócio e o que deve ser feito. O que fazer? Uma resposta direta e clara indica um alto nível de concordância.

Esforço da Feature

O nível do trabalho que precisa ser feito para a Feature. O entendimento da equipe de acordo com a dificuldade e o trabalho que vai ser necessário para completar a Feature.

Valor do Negócio da Feature

O valor de negócio, o ROI (Return On Investment) associado a Feature, uma medida do negócio sobre o valor previsto para tal feature. Qual é o retorno no investimento ou a economia que a Feature vai trazer?

As regras do sequenciador de features

Features serão adicionadas a cada onda. A seguir, as seis regras para adicionar features às ondas. Tais regras foram definidas depois de aplicar esta forma de planejamento e priorização inúmeras vezes.

- Regra 1: Uma onda pode conter no máximo 3 features.

- Regra 2: Uma onda não pode conter mais de uma feature em cartão vermelho.

- Regra 3: Uma onda não pode conter três features, somente em cartões amarelos e vermelho.

- Regra 4: A soma de esforço das features não pode ultrapassar 5 Es.

- Regra 5: A soma de valor das features não pode ser menos de 4 $s.

- Regra 6: Uma onda tem de conter no mínimo 2 features.

A regra 1 limita o número de features que estão sendo trabalhados ao mesmo tempo. Isso evita o acúmulo de features parcialmente completas, aumentando o foco para as poucas features priorizadas por onda. As regras 2 , 3 e 4 evitam um período de trabalho desequilibrado com muita incerteza, ou muito esforço. As regras 5 e 6 garantem o foco constante na entrega de alto valor para o negócio.

Os MVPs no sequenciador de features

Além dos cartões de features (sequenciados), o sequenciador de features mostra claramente o agrupamento de features para cada MVP. Isto é representado por post-its no canto direito sobre a linha que delimita uma onda.

As ondas não terão necessariamente uma relação de um para um com os MVPs. O intuito é de organizar features em ondas para entregar valor o mais rápido possível, entretanto respeitando as dependências entre as features

RICE

Quando cheguei na ContaAzul me deparei com outro método de priorização adotado pelo time de produtos, o RICE.

RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa irá alcançar num determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100%, para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

A melhor ferramenta de priorização

Tanto o índice RICE quanto o sequenciador de funcionalidades são excelentes ferramentas para o gestor de produtos poder ter mais confiança em sua priorização. Contudo, como eu disse no meu primeiro artigo sobre o tema:

…existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. Ou seja, o que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que priorização de roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas, mas sempre que esse método falhar em um determinado item que temos certeza que seria melhor fazer antes ou depois do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso, ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

E por que é preciso incluir o bom senso como mais uma ferramenta de priorização? Porque para priorizar é preciso entender os objetivos dos usuários de seu produto de software e do dono do software. Esse objetivos podem ser conflitantes e, provavelmente, existem mais variáveis do que alcance, impacto, confiança, esforço, retorno, valor, custo, satisfação e necessidade para ajudar a quantificar esses objetivos. Como se não bastasse a grande quantidade de variáveis e os objetivos conflitantes dos usuários do produto de software e do dono de software, há ainda a variável tempo, ou seja, esses objetivos podem mudar ao longo do tempo.

Toda priorização é uma decisão e todo processo decisório é composto de incertezas. As ferramentas acima ajudam a remover um pouco das incertezas. Contudo, com essa grande quantidade de variáveis, é muito difícil, diria até que impossível, remover 100% das incertezas. Por esse motivo, para fazer uma boa priorização, pode ser útil usar uma ou mais dessas ferramentas descritas, mas é importante usar também o instinto, a experiência e o bom senso.

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

• Definições e requisitos
• Ciclo de vida de um produto de software
• Relacionamento com as outras funções
• Gestão de portfólio de produtos
• Onde usar gestão de produtos de software

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!