Priorização

Por Mitch Lacey.Proprietário, Mitch Lacey & associados, Inc, uma empresa de consultoria especializada em adoções e aprimoramentos de agile e scrum.

Janeiro de 2012

Neste artigo, Mitch Lacey discute três métodos que provou ser muito benéfico para muitas equipes Agile: o Modelo Kano de Satisfação do Cliente, uma série de Jogos de Inovação por Luke Hohmann e o modelo do Peso Relativo de Karl Weigers.Qualquer uma deles pode ajudar você a mudar de uma priorização irregular da sua reserva para um pedido preciso que pesa satisfatoriamente o risco, a importância e a satisfação do cliente.

Aplica-se a

Gerenciamento do ciclo de vida do aplicativo; Team Foundation Server

Neste artigo:

• Introdução

• Modelo Kano de Satisfação do Cliente

• Jogos de inovação

  • Aplique o Prune na árvore do produto

  • Comprar um recurso

• Ponderância relativa – Karl Weigers

• Conclusão

Para manter sua equipe ágil funcionando na verdade, você deve ordenar os itens na sua reserva do produto por prioridade e então atualizar essas prioridades enquanto o projeto progride.Todas as reservas do produto devem ser priorizadas com base no valor de negócio e risco.Reconhecendo esta ordem de prioridade, sua equipe pode melhorar o foco nos recursos que são mais prováveis de incluir no sucesso do produto.Uma reserva bem ordenada e priorizada compensa não somente na satisfação da equipe e do cliente, mas também nos ganhos básicos dos negócios.Para obter informações sobre reservas, consulte Desenvolver e gerenciar a lista de pendências de produto, Criar ou adicionar à lista de pendências de produto e Limpar e estimar a lista de pendências.

Ao pedir e e dar prioridade à sua reserva de produto, você deve considerar vários fatores como também conseguir garantir suas decisões.Ao começar uma reserva do produto bruto, o processo pode parecer. quase incontrolávelFelizmente, você não precisa ordenar perfeitamente cada item na sua reserva imediatamente.Em Estimativa, eu descrevo uma técnica chamada "a Grande Parede", que é uma maneira eficaz de estimar rapidamente uma lista de pendências do produto e trabalho com participantes para chegar a uma priorização bruta.

Essa priorização bruta é um bom ponto de partida e pode ser boa o suficiente para suas circunstâncias.Em alguns casos, no entanto, você pode querer refinar estas prioridades ou chegar em uma lista de pendências prioritária de uma forma mais científica.Você pode fazer isso usando várias técnicas.No seguinte artigo, eu discuto três métodos que provaram ser muito úteis para muitas equipes Agile: o Modelo Kano de Satisfação do Cliente, uma série de Jogos de Inovação por Luke Hohmann e modelo de Peso Relativo de Karl Weigers.Qualquer uma deles pode ajudar você a mudar de uma priorização irregular da sua reserva para um pedido preciso que pesa satisfatoriamente o risco, a importância e a satisfação do cliente.

Modelo Kano de Satisfação do Cliente

O modelo Kano de satisfação do cliente foi desenvolvido nos anos 80 pelo professor Noriaki Kano da Tokyo Rika University.Seu modelo fornece um esquema de classificação simples que distingue entre atributos essenciais e diferenciados.Uma abordagem baseada em questionário, o modelo é uma maneira poderosa para exibir características do produto e estimular o debate dentro da equipe de design.

Em Kano, fizemos uma série de perguntas em duas formas diferentes: funcional e disfuncional.Por exemplo, vamos que estamos perguntando aos clientes sobre o sistema de navegação GPS para carros.Fazemos primeiro a forma funcional de pergunta:

• Como você sentiria se este carro tivesse um sistema de navegação de GPS?

Nós limitamos as reações às seguintes respostas:

• Eu gosto desta maneira

• Eu esperava que fosse desta maneira

• Eu sou neutro

• Eu poderia conviver com isto dessa forma

• Eu não gosto desta maneira

Para esse exemplo, vamos dizer que nossos clientes imaginários responderam com “Eu gosto dessa forma”.

Em seguida, fazemos a pergunta de modo disfuncional:

• Como você sentiria se este carro não tivesse um sistema de navegação de GPS?

Nossos clientes fictícios podem escolher qualquer uma das respostas listadas.No entanto, a resposta pode muitas vezes ser, e geralmente é, diferente.Para esse exemplo, vamos dizer que nossos clientes imaginários responderam “Eu espero que essa seja a forma” para a forma disfuncional da pergunta.

Quando fazemos isso para um projeto atual, podemos solicitar esta lista de perguntas adversas a vários grupos de clientes, ou seja, conjuntos diferentes de pessoas que representam funções diferentes de organização de clientes.Você pode ter um grupo de marketing, um grupo de contabilidade, um grupo de manufatura e assim por diante.Para fins de compreensão do modelo, no entanto, vamos imaginar que nós fazemos apenas uma pergunta de apenas um grupo de clientes.Depois de criarmos nossos pares de respostas (as respostas ao formulário funcional e disfuncional), mapeamos para uma grade, como a Tabela 1 mostra.

Tabela 1 – Mapeamento de Kano

Observe que, no exemplo, nossos clientes imaginários responderam desejável à pergunta funcional e esperado à pergunta disfuncional.Quando mapeamos esse par para a grade, podemos ver que a interseção desses dois atributos é um E, visto que o quadrado amarelo realçado indica.Vamos examinar o que isso significa para nossa lista de pendências de prioridade.

• E = Excitadores.Esses são os recursos que o cliente não esperava e que realmente diferenciam um produto de seus concorrentes.Eles são difíceis de se identificar, especialmente no início, pois pode ser difícil levantar perguntas que produzam recursos estimulantes.Por esse motivo, os excitadores tendem a imergir e aumentar na prioridade enquanto o projeto progride e comentários do cliente começam.

  • Os clientes recebem grande satisfação desses recursos e estão dispostos a pagar um preço maior para tê-los.Por exemplo, o iPod da Apple deleitou os clientes com sua capacidade intuitiva para girar o conteúdo para corresponder à orientação da tela.A ausência deste recurso não diminuiria a satisfação, no entanto, porque o cliente não saberia o que esperar.

  • Em nosso exemplo, ter a navegação de GPS seria um recurso interessante.Explorar esse recurso, pelo menos até o ponto de receber comentários do cliente, deve ser uma prioridade relativamente alta.

• B = Linha de base.Esses recursos devem estar no produto.São recursos indispensáveis, de alta prioridade.

  • Não importa se esses atributos básicos são bem ou mal executados, o cliente permanecerá neutro em relação ao produto.Um processador de texto, por exemplo, deve ter as funções “criar documento” e “salvar documento”.São o custo de entrada.

  • Se tivéssemos perguntado ao nosso grupo de clientes sobre cintos de segurança, a maioria das pessoas responderia que eles esperariam um novo carro vir com cintos de segurança e que não gostam quando não tem.Se nós mapeamos estas duas respostas na grade, descobriríamos que os cintos de segurança são uma linha de base (B), recurso indispensável.

• L = Linear.Também conhecido como requisitos de desempenho, os recursos lineares estão correlacionados diretamente à satisfação de cliente.Eles se enquadram logo abaixo dos recursos da linha de base em prioridade, mas devem ser equilibrados em relação ao custo.

  • Funcionalidade aumentada ou qualidade de execução aumenta a satisfação do cliente.A funcionalidade diminuída diminui a satisfação.

  • O preço do produto geralmente é relacionado a esses atributos.

• I = indiferente.Esses recursos são os menos importantes para o cliente e, assim, devem ser os menos importantes para o produto.Eles vão provavelmente retornar pouco ou nenhum valor de negócio.

A tabela 1 também mostra Q e R.

• P: Duvidoso – a pergunta provavelmente está incorreta ou resposta é suspeita.

• R: Inverso – a combinação de respostas não bate.Leve o sistema de navegação GPS – se alguém responder que espera estar presente, mas que também acha que não, é uma resposta R.

Se um par de respostas é classificada Q ou R, você deve investigar suas perguntas ou pares de respostas mais profundidade.

Jogos de inovação

Os Jogos de Inovação são ferramentas para ajudá-lo a desenvolver pesquisas de mercado primário.Com essas ferramentas, os clientes “jogam” com o objetivo de gerar feedback e lançam informações sobre um produto ou serviço.Luke Hohmann criou e descreveu mais de 12 destes jogos em seu livro, Jogos de Inovação, que é uma grande adição a qualquer biblioteca.Estes são os dois jogos que eu mais gosto de jogar para a priorização de uma lista de pendências: Prune the Product Tree e Buy a Feature, que o Luke descreve neste trecho do livro (usado com permissão):

Aplique o Prune na árvore do produto

Árvores de ameixa seca para controlar seu crescimento.Às vezes a poda é artística e nós terminamos com arbustos com forma de animais ou formas abstratas interessantes.Quase sempre, as árvores são podadas para crescerem de forma homogênea e gerarem frutos de boa qualidade.O processo não é tem a ver com “recortar” – e sim com “dar forma”. Use esta metáfora para ajudar a criar o produto que seus clientes desejam.

O Jogo

Inicie desenhando uma grande árvore em um painel ou papel ou imprimindo uma imagem gráfica de árvore como um pôster de formato grande.Os membros grossos representam as principais áreas de funcionalidade em seu sistema.A borda de árvore — suas ramificações mais extremas — representa os recursos disponíveis na versão atual.Compor novos recursos em potencial em vários cartões de indexação, moldados preferencialmente como folhas.Solicite aos seus clientes para colocar os recursos desejados em torno da árvore, definindo a próxima etapa do seu crescimento.Eles estruturam uma árvore que está crescendo de maneira balanceada?Um ramo, talvez um recurso central do produto, obtém o volume de crescimento?Um aspecto não utilizado da árvore se torna mais forte?Sabemos que as raízes de uma árvore (a infraestrutura de suporte e cuidados com o cliente) precisam se estender pelo menos até seu dossel.E os seus?

Árvore do Produto – Hohmann

Como funciona

Você e seus clientes sabem que os recursos variam em importância.Portanto, nós tendemos colocar nossos esforços nos recursos mais importante, os que fornecem o maior valor para os clientes.Infelizmente, às vezes isso significa que colocamos muito pouco esforço por trás de recursos que são necessários para concluir o produto.O jogo Prune the Product Tree oferece a seus clientes uma maneira de opinar no processo de tomada de decisão examinando o conjunto de recursos que compreendem o produto de uma maneira holística.

Comprar um recurso

Qual recurso atrairá os clientes para comprar seu produto?Qual recurso fará os clientes atualizarem?Qual recurso fará os clientes tão felizes que poderão ignorar ou tolerar os recursos que você deseja corrigir ou remover?

Os planejadores de produto debatem infinitamente esses e outros tipos de questões.Escolhendo o conjunto de recursos correto para adicionar a uma versão geralmente marca a diferença entre a falha a curto prazo ou sucesso a longo prazo.Infelizmente, planejadores demais do produto fazem esta opção não envolver as pessoas a mais afetadas por ele –– seus clientes.O jogo Comprar um Recurso melhorar a qualidade dessa decisão pedindo aos seus clientes para ajudar para fazê-lo.

Comprar um recurso – Sterne

O Jogo

Crie uma lista de possíveis recursos e forneça cada um com um preço.Assim como em um produto real, o preço pode ser baseado nos custos de desenvolvimento, no valor do cliente, ou qualquer outra coisa.Embora o preço possa ser o custo real que você pretende para cobrar pelo recurso, isto não é geralmente necessário.Os clientes compram recursos que desejam na próxima versão do produto usando dinheiro de jogo você os dá.Certifique-se de que alguns recursos são fixados alto suficiente que nenhum cliente possa alternar comprá-lo.Incentiva os clientes a agrupar seu dinheiro para comprar recursos caros e/ou especialmente importantes.Isso ajudará a motivar as negociações entre os clientes em relação a quais recursos são mais importantes.

Esse jogo funciona melhor com quatro a sete clientes em um grupo, para que você possa criar mais oportunidades para que os clientes agrupem seu dinheiro em uma negociação.Ao contrário do jogo Product Box, o jogo Buy a Feature é baseado na lista de recursos que provavelmente estão no mapa de desenvolvimento.

Como funciona

Os planejadores de produto costumam cair na armadilha de pensar que os clientes têm prioridades claramente definidas.Alguns sim.Mas a maioria não tem.Quando apresentados com um conjunto de opções, vários clientes dirão simplesmente "Eu quero todas elas“ e colocarão em seus ombros a responsabilidade de priorizar as solicitações deles.Como alternativa, os diretores de produto frequentemente coletam prioridades de recursos trabalhando com clientes pessoalmente e no processo e talvez sem perceber, novamente assume a responsabilidade pelos recursos de priorização.Incentivando clientes como um grupo e fornecendo uma quantidade limitada de recursos, da a você a oportunidade de priorizar seus desejos como um grupo.Mas isso não é onde a mágica se encontra.A mágica se encontra em estruturar as conversas para que seus clientes negociem recursos específicos entre eles.Esta negociação é que melhora a sua compreensão do que seus clientes realmente querem.

Ponderância relativa – Karl Weigers

Outro método excelente para priorização é a Relevância Relativa, que Karl Weigers introduziu em 1999.Esse método não apenas fornece um mecanismo para os requisitos de prioridade com base na entrada e nos comentários do usuário, mas também inclui o julgamento da equipe.Como jogos de Kano e de inovação, a relevância relativa permite que o proprietário do produto melhore o indexador que apresenta para implementar e na ordem de prioridade.

A primeira etapa é atribuir um peso ao benefício relativo de um recurso.Um benefício é a vantagem para usuários de ter o recurso no produto final.Em seguida, é importante atribuir a penalidade relativa.A penalidade é a consequência para usuários que não possuem o recurso no produto final.(Avaliar os benefícios e as penalidades realiza a mesma coisa que o formulário funcional e disfuncional do método de Kano da pergunta.) Os pesos são números arbitrários que representam como sua empresa avalia os benefícios e os riscos dos recursos.É muito semelhante à forma como um professor determina o peso dado a lição de casa, atendimento, questionários e testes para determinar a classificação total, que variará de professor para professor.Se você decidir que os benefícios superam as sanções, torne o peso maior do que a sanção seja qual for a razão que achar adequada.Se você decidir que as sanções superam os benefícios, ajustar a ponderação de acordo.No exemplo na tabela 2, nós demos o benefício em relação ao peso de 2 e a penalidade um peso relativo de 1, o que significa que o benefício será um fator maior na determinação da prioridade final.

Da mesma forma, nós determinamos o peso da porcentagem de custo e porcentagem de risco.No exemplo seguinte, o risco não era tanto quanto uma preocupação com o projeto, assim a porcentagem do custo foi dado peso de 1 e o percentual de risco um peso de 0.5.(Observe que, embora o benefício e a penalidade sejam pesados antes da porcentagem do valor ser calculada, o custo e o risco são pesados como porcentagens.) Se você tem um projeto de alto risco, você pode arriscar o peso superior ao custo.

Agora que os pesos foram definidos, solicitamos que os usuários avaliem a vantagem relativa e a penalidade relativa de cada recurso.Cada benefício e penalidade é avaliado em uma escala - Weigers recomenda 1-9, mas você pode escolher uma escala diferente contato que seja consistente.A vantagem relativa é o valor que o recurso irá oferecer; a penalidade relativa é o potencial impacto negativo de não fazer o recurso.

Por exemplo, vamos dizer um recurso possível é “Tornar a conformidade de widget com os regulamentos Sarbanes-Oxley”. Não há praticamente nenhuma vantagem em relação aos usuários, mas a penalidade relativa ao negócio é grande - não fazê-lo pode falir a empresa.Como tal, nós pudemos ver uma contagem de 1 ou 2 para a vantagem relativa e uma contagem de 8 ou 9 para a penalidade relativa.

No exemplo seguinte, os usuários avaliaram o benefício relativo do recurso "Status de consulta de um pedido do fornecedor" como um 5.Eles avaliaram a penalidade relativa como 3.Para derivar o valor total desse recurso, nós multiplicamos os dois números por seus pesos relacionados e os agrupamos:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

Neste caso, o valor total para o recurso é de 13 pontos.

Quando obtemos o valor relativo e a porcentagem do valor total para os recursos, nós movemos para além dos usuários para obter ideias sobre a equipe.Pedimos que a equipe estime o custo relativo para implementar cada recurso que usa a mesma escala.Karl Weigers explica, "os desenvolvedores estimam as avaliações dos custos com base nos fatores como a complexidade do requisito, a extensão de trabalho da interface do usuário necessária, a capacidade potencial para reutilizar designs ou código existentes, e os níveis de teste e de documentação necessários."

Depois de estimar o custo relativo, estimamos o risco relativo.Além disso, Weigers informa, "Os desenvolvedores estimam o grau relativo de técnico ou outro risco associado com cada recurso em uma escala de 1 a 9.Uma avaliação de 1 significa que você pode programar para seu modo de espera, quando 9 indica preocupações sérias sobre a possibilidade, a disponibilidade de pessoas com a experiência necessária ou o uso de ferramentas e tecnologias não aprovadas ou estranhas.A planilha irá calcular a porcentagem de risco total que vem de cada recurso”.

Depois de observar os valores para o benefício relativo, a penalidade, o custo e o risco, nós somamos cada coluna.Esses totais serão usados para calcular as porcentagens.

• Porcentagem total de valor: Dividir o valor da soma do benefício relativo e a penalidade pela soma total na parte inferior.No exemplo a seguir, este é 13/154 = 8%.

• Porcentagem dos custos relativos: dividir o valor relativo dos custos pela soma dos custos relativos totais na parte inferior.No exemplo a seguir, este é 2/42 = 4,8%.

• Porcentagem dos riscos relativos: dividir o valor relativo dos riscos pela soma dos riscos relativos totais na parte inferior.No exemplo a seguir, este é 1/33 = 3%.

• Prioridade: dividir o valor percentual por (custo percentual * peso do custo) + (valor percentual * peso do valor).No exemplo seguinte, este seria 8.4% / ((4.8% * 1) + (3% * 0.5).Isso fornece o valor de prioridade (1,345).

Depois de obter os valores de prioridade, nós classificamos a coluna de prioridade em ordem decrescente de modo que os itens de prioridade mais alta estejam na parte superior.Como itens são adicionados à reserva do produto ou mais informações sobre um artigo surgem, precisaremos de fazer nova avaliação de prioridade.

No final, a folha parece como esta tabela:

Realizando essa abordagem, você pode compreender melhor os intervalos que funcionam para a equipe e para os participantes.Também ajuda a melhorar discussões de base porque pode ser difícil levar em consideração, de forma objetiva, elementos como o benefício, a penalidade, o custo e o risco para cada recurso.

O Weigers explica como fazer o modelo corresponder melhor à realidade:

“Calibre esse modelo para seu próprio uso com um conjunto de requisitos ou recursos concluídos de um produto anterior.Ajuste os fatores de ponderação até que a sequência de prioridade calculada concorde com sua avaliação após o fato de como os requisitos são importantes em seu conjunto teste realmente era.Esse modelo também pode ajudá-lo a tomar decisões de conflito de escolha quando você está avaliando novos requisitos propostos.Estimar sua prioridade usando o modelo para dizer como eles correspondem em relação aos requisitos existentes, para que você possa escolher uma sequência de implementação apropriada.Todas as ações realizadas para mover priorização de requisitos da arena política para um objetivo e analítico aumentará a capacidade de projeto para fornecer as funcionalidades mais importantes na sequência mais adequada.”

Karl Weigers escreveu dois livros que entram em mais detalhes em ponderação relativa: Requisitos de Software, Segunda Edição e Mais sobre Requisitos de Software: Questões Espinhosas e Conselhos Práticos

Se você usar um desses métodos ou alguma outra técnica, lembre-se de que a reserva do produto é uma coisa ativa.Você não prioriza apenas uma vez e a colocá-la de lado-a repriorização é uma parte que se espera da manutenção de uma reserva íntegra.Para manter seu projeto na trilha, você deve fazer constantemente nova avaliação de artigos, a importância para o projeto, e como as novas informações afetam a reserva.Você deve se esforçar para manter os participantes e clientes envolvidos em todo o projeto.Além disso, você deve de lembrar que a estimativa de um item é essencial para determinar a sua prioridade.Não permita que suas reservas envelheçam e morram.Investir tempo e esforço na orientação e preparação de sua lista de pendência - você verá os resultados não apenas no produto final mas também em seus lucros.

Consulte também

Conceitos

Comece como equipe

Planejamento ágil e iterações

Solicitação e comentários de Stakeholder processo por meio do acesso da Web da equipe

Acompanhar o trabalho e gerenciar o fluxo de trabalho

1. Requisitos de software ágeis, Dean Leffingwell, Addison-Wesley

   “Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol.14, N° 2, outubro de 1984.O artigo original de Kano.

2. http://www.processimpact.com/articles/prioritizing.html