🕗 🏔️ 👲🏻 Técnicas de priorização e pontuação 🏇🏽 🌙 👨🏽‍🏫

Bem, como estão seus planos de isolamento? Coisas de inverno removidas? Você já assistiu os filmes cobiçados? Você leu os livros empoeirados? E, como sempre, não há tempo para serviços públicos. Vamos lá, não dê desculpas. Para aqueles que não conseguem fazer uma hora para assistir ao vídeo em nosso canal do YouTube, criamos um artigo digestível. Tenha consciência, apenas 15 minutos em vez de 60 :)

Hoje, abordamos o gerenciamento de produtos e analisamos a priorização de pendências. O gerenciamento de produtos custa um pouco mais alto que o gerenciamento de projetos: trata-se mais de gerenciamento de produtos em geral e está intimamente relacionado ao marketing. Para um lanche, vejamos técnicas de pontuação e avaliação de tarefas.

Situação

Quando há uma lista de pendências, o gerente precisa priorizá-la de alguma forma. Scrum diz que as tarefas mais importantes do ponto de vista comercial devem ser as primeiras. Mas existem dois problemas.

O primeiro é um momento justo de subjetivismo: muitas vezes as prioridades são definidas da maneira que o empresário vagueia. na cabeça. Mas, às vezes, o proprietário pode "alucinar" fortemente e carregar um absurdo franco, mas tenha certeza de que tudo está assim.

O segundo problema: muitas partes interessadas de alto nível por parte dos negócios em grandes projetos ou em grandes empresas. Cada um deles pode ter seus requisitos conflitantes. Se você reunir, por exemplo, cinco chefes de uma grande empresa e solicitar que priorizem seus requisitos, provavelmente todos irão argumentar que suas tarefas têm prioridade zero e que precisam ser concluídas agora.

A boa notícia é que existem algumas técnicas que ajudam nesse caso:

concordar com prioridades - escolha o que é mais importante e o que pode ser adiado;
estabeleça critérios para priorizar a lista de pendências (um pouco menos subjetivo do que a alucinação de alguém - infelizmente, é impossível fazer sem subjetividade).

Métodos para priorizar tarefas

Como é a lista de pendências?

A lista de pendências é uma tabela. Em uma coluna - uma lista de algo (alguma lista de desejos), existe uma coluna com uma estimativa (estimativa) e há uma coluna com prioridades. As prioridades são alguns números, geralmente grandes. Grande para que haja "buracos" entre as prioridades, onde você pode adicionar novas tarefas (ou alterar facilmente a prioridade).

De acordo com os clássicos, as prioridades são definidas em termos de Valor comercial (valor comercial) - o que uma empresa precisa, antes de tudo, será trabalhar no primeiro estágio. Mas existem outras maneiras de priorizar que são mais convenientes - especialmente se você tiver várias tarefas heterogêneas.

Mapeamento de histórias

Suponha que você tenha muitas tarefas, elas são pequenas e geralmente sem prioridades e vinculativas a qualquer grupo. O que fazer com eles? Divida-os no Mapeamento de História. Como funciona:

Etapa 1. Criamos uma sequência de como os usuários usarão seu produto e quais etapas serão executadas. Um exemplo simples:

Etapa 2. Escrevemos nos adesivos quais detalhes estão disponíveis para cada um desses processos - quanto menor o adesivo de cada estágio, menor a sua prioridade.

Resultado: a lista inteira de tarefas é dividida em etapas do caminho do usuário, além de cada recurso ter prioridades (quanto mais baixo o recurso estiver na planilha, menor será sua prioridade em termos de todo o caminho do usuário).

Onde e como se inscrever

Vamos dizer que você realmente tem muitas tarefas. Em seguida, você as escreve em adesivos e faz o Mapeamento de histórias. Melhor - em equipe.

Outra opção - você tem um brainstorm, cria o que será mais o seu produto e quais recursos levar para o trabalho. A equipe tem muitas idéias, algum tipo de marketing de lista de desejos "derramado" para você - você precisa entender como agrupar tudo. O mapeamento de histórias funciona especialmente bem nessa situação.

Isenção de responsabilidade: este método é aplicável precisamente do ponto de vista do gerenciamento de produtos, quando há muitas tarefas, não está claro qual delas é a primeira a ser considerada. É rude quando pensamos no produto em si e em qual funcionalidade ele incluirá. Em seguida, ele já é cortado em pedaços dos quais você pode criar sprints e entra no trabalho.

Profissionais do mapeamento de histórias

O método permite criar conexões no sistema, com base nas quais é mais fácil formar sprints.
Quando existem muitas partes interessadas e muitas pessoas que têm interesse no projeto, o método permite que você chegue a um acordo sobre prioridades reais - o que é mais importante e o que é menos.

Valor e esforço (ou priorização enxuta) para idéias

Outro bom método que permite criar prioridades em escala é o Valor e esforço (ou Priorização Lean).

Etapa 1. Primeiro você toma 2 escalas:

— , « » . , — . , , , Value. , , .
,

, (estimate), . Story Point- ( ) -.

Etapa 2. Você avalia todos os recursos por esses dois parâmetros: por significância e contribuição do trabalho. Existem sistemas externos (como Hygger ou Airfocus Priorities & Roadmaps ) que permitem dispersar automaticamente seus recursos de alguma forma nessa placa. Os eixos nesse caso não são zero - eles se adaptam às estatísticas que você obteve.

Quais recursos levar em primeiro lugar? Os mais significativos e mais leves, mais próximos dos eixos - ambos são importantes no topo e em valor adequado:

Se em primeiro lugar tiramos barato e bom, depois - caro, mas legal:

A seguir estão todos os outros. Recursos muito caros e sem significado, você sai "para mais tarde" ou joga fora.

Onde e como se inscrever:

com o desenvolvimento personalizado, isso faz sentido com o cliente se:

ele mesmo ficou confuso
gera idéias e requisitos estranhos,
ele tem uma certa restrição orçamentária e não entende a melhor forma de distribuí-la.

A última situação é frequente. Sempre somos limitados por orçamentos ou recursos e precisamos entender com base no que distribuí-los. Além disso, ao gerenciar projetos, podemos gerenciar apenas a atenção de nossa equipe e de
nossos clientes - nada mais, de fato. Esse método permite que você se concentre no mais importante e no mais barato ou no caro, mas muito importante, e ajuda a escolher exatamente o que apostar no momento.

Essa técnica não faz você acreditar cegamente no algoritmo e executar com precisão as tarefas recomendadas por ele, mas, graças a ele, você terá pelo menos uma dica em que direção se mover. Se você adicionar novas tarefas ao sistema, ele poderá ser reconstruído. Afinal, acontece que você não tem muita certeza de suas estimativas e, com o tempo, os analistas as refinam, ou você mesmo refina as estimativas da complexidade dos programadores - nesse caso, o sistema também pode ser reconstruído em dinâmica. Devido a isso, você terá uma imagem mais adequada do mundo.

Moscou

Outra maneira de categorizar recursos em vários grupos é o método MoSCoW. No interior, existem parâmetros muito simples:

M - Must Have : funcionalidade que você não pode prescindir. Sem ele, você não poderá liberar, seu produto não funcionará e nem será necessário.

S - Deveria ter : a funcionalidade que deveria estar no projeto, mas outras coisas são iguais, você pode, de alguma forma, ficar sem ele.

C - Poderia ter : funcionalidade desejada para lançamento.

W - Teria : a funcionalidade menos prática - por assim dizer, “tudo o resto”.

, . Must Have , , , . Should Have — , , . Could Have — . , Must Have MVP.

Muitas vezes acontece que as prioridades são reduzidas de cima para baixo, dos negócios, e estão concentradas em algumas “Lista de Desejos” de Deveria, Poderia Ter, Teria, pontuando em coisas importantes (Deve Ter). Normalmente, observamos isso, por exemplo, no desenvolvimento do design de uma loja online ou no design de algum tipo de projeto, em que a taxa é colocada por último, mas não menos importante, no sistema de pagamento de entrega ou em algo que realmente gera um benefício para os negócios. Por quê? Porque trabalhar com o Must Have é doloroso e assustador: você precisa pensar em como será monetizado e ninguém gosta de entrar nele, embora isso esteja errado.

Kano

Outra maneira de categorizar os recursos provenientes do marketing. A essência é simples: existem dois eixos: "satisfação do usuário" e "funcionalidade", e há uma divisão do funcional em grupos. Para cada grupo de recursos, você precisa entender como a satisfação do usuário muda ao adicionar essa funcionalidade.

O primeiro grupo é a funcionalidade necessária: o mesmo deve ter no MoSCoW. Se esses recursos são - já são bons. Não há questão de satisfação: ninguém precisa de um produto sem eles. Além disso, com o tempo, as funções que foram o destaque do projeto a princípio se tornam cada vez mais obrigatórias. Exemplo: para software de servidor, o Kanban-board já foi uma espécie de tipo, mas agora é o mesmo cabeçalho.

Outro grupo são funções unidimensionais. Isso significa que existe uma correlação direta entre a satisfação do usuário e a disponibilidade dessa função. Assim que uma função aparece, a satisfação cresce linearmente. Se você voltar ao exemplo da criação de um carro, pode haver controle climático lá.

O terceiro grupo são características atraentes. Isso é o que o usuário não esperava, mas quando viu pelo menos alguma implementação disso em seu produto, ele enlouqueceu e disse "oh, legal!". Aqueles que voaram por aeroflot provavelmente viram como as crianças recebiam "subornos" para anexá-las emocionalmente à marca.

Presentes para as crianças a bordo do Aeroflot são a fonte.Depois

que essa função aparece mesmo em uma implementação medíocre, a satisfação aumenta. E quanto mais íngreme a implementação, maior o cronograma de satisfação.

Outro grupo são funções sem importância. Você pode fazê-los, você não pode fazê-los - todos serão indiferentes.

O último grupo é de recursos indesejáveis. Quando eles se vão - tudo fica bem, assim que aparecem - tudo fica ruim. Tais antifichi :)

Esse método é um tanto duvidoso, pois não está claro como as prioridades são selecionadas para os recursos. Em teoria, você precisa entrevistar os usuários: como eles pensam, esse recurso é bom ou não e, em seguida, agrupa com base nas opiniões dos usuários. Ao mesmo tempo, os próprios usuários também devem ser divididos em grupos-alvo e observar como cada função pertence a qual grupo-alvo.

As pessoas nas pesquisas costumam falar bobagens e simplesmente mentir. Eles podem dizer que esse é um recurso muito importante, mas na verdade eles nunca pagarão dinheiro por isso. Além disso, se você entrevistar usuários, o feedback do produto pode ser muito tóxico.

Exemplo

Você está planejando fazer os próximos lançamentos e está entrevistando um grupo de pessoas. Alguns deles podem dizer: "Mas você fez uma função paga lá, por causa disso o produto piorou, fii!" Só porque é por dinheiro, essa função parece desnecessária para alguém. Embora para os negócios, isso pode ser a principal coisa que gera lucro.

Portanto, o método Kano está absolutamente fora do marketing, mas como estratégia de longo prazo, há um lugar para se estar.

O método clássico de priorizar listas de bugs

No centro, há uma lista de prioridades de 0 a 8:

0 - Erros críticos
Quando o testador apareceu e não pode mais verificar quando o sistema trava ou algo quebra - em geral, quando é impossível.

1 - Usabilidade crítica e recursos esquecidos
Aqui aplicamos, incluindo o método de backlog de pintura, especificações técnicas ou um protótipo (dependendo do que temos em mãos) para determinar se perdemos alguma coisa.

2 - Bugs não críticos
Existem bugs , mas eles não interferem no teste do produto, ou permitem que você percorra toda a cadeia do pedido ou de qualquer outra coisa - ou seja, eles permitem a verificação completa do produto.

3 - Usabilidade não crítica

4 - Textos

8 -Lista de desejos / não faremos isso / a critério do gerente

Sim, o intervalo entre 4 e 8 foi feito intencionalmente - o gerente, se necessário, pode provar outras tarefas lá.

Para listas de bugs, o método é bom, mas tem um problema. Em geral, estamos otimizando a métrica "pronto - não pronto" nas listas de bugs. O escopo do trabalho é claro. Mas muitas vezes é descoberto que, na usabilidade não crítica, eles tentam empurrar algo que está à beira de, ao que parece, usabilidade e parece bom fazê-lo, mas na verdade atrai algum recurso muito sério.

Outro problema é a subjetividade do testador, que geralmente precisa ser verificado duas vezes. Às vezes, essa é uma história bastante demorada quando você olha pessoalmente todas as listas de bugs: veja o que ele escreveu lá e decida o que jogar fora e o que deixar.

Esse método não é adequado para priorizar listas de pendências - elas precisam de critérios completamente diferentes.

Avaliação de tarefas

Qualquer priorização deve basear-se nas avaliações que nos foram dadas. Afinal, a complexidade realmente afeta a prioridade de uma função. Mas como determinar a complexidade e em que momento vale a pena discutir os custos de mão-de-obra com um programador? Afinal, antes disso, o gerente ainda precisa definir pelo menos estimativas aproximadas.

Mas, falando sério, geralmente existem três opções.

- « » , , . , , - -, - -. :)

( ). - , - . , . , , ( - ).
: , , , .

: ( + ( * 3) + ) / 6.

, .

, , . , , , : , — . . — .

, , , . - , , , «» — . — 1 , , .

, « », . , .
Planning Poker

«» , - , , . .

Planning Poker — , . Story Mapping, ( , — ).

Planning Poker
1. , ;
2. , — ( , «»).

Eles ajudam na priorização de tarefas em um backlog em condições de incerteza - quando você planeja e avalia apenas o efeito da introdução de uma função específica.

Pontuação ICE

A abreviação consiste em três parâmetros:

Impacto - o impacto no produto, do ponto de vista comercial, ou quanto dinheiro trará, ou o que esse recurso oferecerá, como é legal. O parâmetro é definido no intervalo de 1 a 10.
Confiança - confiança na avaliação da complexidade ou na avaliação do impacto dos recursos. Por exemplo, você criou algum tipo de função e acha que isso terá um bom efeito no projeto. Não houve análises, os dados são imprecisos e, até agora, a prioridade se baseia apenas na sua opinião pessoal. Quanto menor a confiança em sua opinião pessoal, menor a taxa. Também é definido no intervalo de 1 a 10.
Facilidade - custos de mão de obra ou facilidade de implementação. Também pode ser definido de 1 a 10. Quanto mais simples a função, maior a pontuação.

Impacto

Para avaliar o efeito de um determinado recurso, vale a pena considerar vários critérios:

melhora conversões,
ela atrai novos usuários
mantém usuários existentes
ela agrega valor ao produto.

Se a função as responder, ela terá um alto impacto no produto. Para avaliação, você pode fazer uma escala de 1 a 10, você pode fazer de 1 a 100. Este último é mais conveniente, pois há uma corrida de decolagem.

Confiança

Pode ser baseada em:

opinião pessoal, a opinião da equipe, a opinião de especialistas externos;
Pesquisa UX;
sondagens
entrevista;
observações, incluindo concorrentes;
MVP
Testes A / B;
pesquisa de terceiros;
análise;
principais chamadas para suporte técnico;
principais solicitações de gerentes de vendas;
principais solicitações de clientes.

É melhor usar aqueles onde existem métricas e números específicos, deixar a opinião das pessoas para "mais tarde".

Como medir o nível de confiança - a fonte

Para obter o ICE, você precisa multiplicar esses três parâmetros - essa será a prioridade da implementação.

Prós : rápido e fácil.

Contras : o método tem uma escala bastante limitada - você pode obter muitas tarefas de alta prioridade, porque as instruções serão claras, as tarefas serão simples e parecerão importantes.

Pontuação do RICE

4 parâmetros são usados aqui:

Alcance - cobertura: quantos usuários desse recurso obterão pelo menos alguma satisfação, observe esse recurso ou o use. Pode ser medido quantitativamente: por exemplo, 500 milhões de usuários experimentarão esse recurso. Pode ser medido como uma porcentagem - por exemplo, 30% dos usuários usarão esse recurso.
Influência do impacto: quanto realmente precisamos dessa função, quanto ela nos ajudará, como é legal a função.
Confiança - confiança: semelhante à pontuação do ICE, confiança em nossas estimativas e previsões de influência.
Esforço - laboriosa.

Funções que oferecem grande cobertura, das quais estamos confiantes e que têm um bom efeito no produto e ao mesmo tempo baratas em termos de custos de mão-de-obra, estão no topo por prioridade no backlog.

Software para priorização

Existem vários programas para priorização automática - por exemplo, Hygger . Este é um sistema para Proprietários de produtos, onde existem muitos modelos diferentes que permitem "brincar" com as tarefas.

Como é o Hygger por dentro - a fonte

A mesma coisa em qualquer Google Dock: basta adicionar três parâmetros, coletar dados - será contado. Essas serão suas prioridades. E então você mesmo escolhe o que levar no sprint.

Às vezes, os gerentes usam o Jira para armazenar todos os tickets e tarefas. Infelizmente, não é muito conveniente para a priorização - ele é voltado para o fato de alguém priorizar manualmente, simplesmente arrastando tickets para cima e para baixo na lista de pendências. É legal se o backlog não tiver 1000 linhas, mas em algum momento se tornará tedioso para você fazer isso com as mãos.

O Jira tem algumas maneiras de classificar tarefas em épicos, componentes, liberações e você pode marcar tarefas com algumas tags. Existem vários plugins para pontuação ( Issue Score for Jira ,Calculadora de pontuação prioritária ), mas não são muito funcionais.

De mais ou menos adequado - sistemas externos Hygger e Airfocus . Eles se integram com Jira, mas custam quase o mesmo que ela. Portanto, a maneira mais fácil é integrar o Google Dock e o Jira: faça o upload de backlogs de forma síncrona e aplique suas fórmulas conforme necessário.

Como fazer amigos Jira e Google Docs para priorização

Além das prioridades, sempre há um problema em como distribuir a implementação de determinadas tarefas no tempo. Quando existem apenas prioridades, não há garantia de que obteremos um sistema conectado (por exemplo, você planejou fazer uma cesta, mas acabou que ainda não havia catálogo). Portanto, além das prioridades, também vale a pena usar os diagramas de Gantt para ver as conexões no sistema, como ele funciona corretamente pelos componentes e com a distribuição ideal dos recursos da equipe ao longo do tempo.

Infelizmente, no Jira, na "caixa", essa opção não está muito bem implementada, portanto, vários plugins também podem ser úteis:

Portfólio (também caro);
BigPicture (pesado);
Projeto MS ;
Projeto Merlin para MacOS.

Como um resultado

Não nos livramos da subjetividade - ela permanece em todos os níveis. No momento em que dizemos “essa é uma função importante” ou “essa é uma função sem importância” e quando damos algumas avaliações, a subjetividade é preservada. Mas, graças aos métodos acima, podemos dividir essa subjetividade em componentes: pelo menos a imagem será mais clara.

Se você usar um parâmetro como "confiança na avaliação", poderá "torcer" essa confiança ao longo do tempo. Por exemplo, você tem uma boa função que afeta o produto de maneira positiva e barata, e a cobertura dá muito, mas a confiança nele é baixa. Verifique através de métricas, análises, um pedido de especialistas, perguntas aos programadores - e especifique.

Bom para classificações de Poker de planejamento, além de analisarmos vários métodos para categorizar tarefas. Se você tiver uma sessão estratégica com um cliente, tente o Mapeamento de histórias com adesivos e distribua-os de acordo com as etapas do usuário. Em produtos internos, o mesmo método o ajudará a escolher os recursos que valem a pena ser utilizados em versões futuras. Para pedidos em atraso, a pontuação do RICE é melhor que o restante para avaliar quais tarefas irão para onde.

Mas lembre-se de que a decisão final depende sempre do gerente, e os números obtidos usando os métodos definem apenas a direção.

Vejo você nos novos vídeos em nosso canal do YouTube !

Técnicas de priorização e pontuação