Priorização

Por Mitch Lacey. Proprietário da Mitch Lacey & Associates, Inc, uma empresa de consultoria especializada em adoções e melhorias baseadas em Agile e Scrum.

Janeiro de 2012

Neste artigo, Mitch Lacey descreve três métodos comprovados muito vantajoso para muitas equipes Agile: o Kano modelo 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 um deles pode ajudá-lo a mudar de priorização aproximada da lista de pendências para uma ordenação precisas que pondera satisfatoriamente risco, importância e satisfação do cliente.

Aplica-se a

Gerenciamento do Ciclo de Vida de Aplicativos; Team Foundation Server

Neste artigo:

• Introdução

• Modelo Kano de satisfação do cliente

• Jogos de inovação

  • Aparar a árvore do produto

  • Comprar um recurso

• Peso relativo – Karl Weigers

• Conclusão

Para manter sua equipe agile funcionando com eficiência, você deve solicitar os itens da lista de pendências de produto por prioridade e, em seguida, atualize as prioridades conforme o andamento do projeto. Todas as listas de pendências de produto devem ser priorizadas com base no valor comercial e risco. Reconhecendo essa ordem de prioridade, sua equipe melhor pode se concentrar nos recursos que têm mais probabilidade de influenciar o sucesso de seu produto. Uma lista de pendências bem ordenada e priorizada compensa não apenas em equipe e satisfação do cliente, mas também no final de sua empresa. Para obter informações sobre listas de pendências, consulte Compilar e gerenciar a lista de pendências do produto, Criar sua lista de pendências, e Limpar e estimar a lista de pendências.

Quando ordenar e priorizar sua lista de pendências de produto, você deve considerar vários fatores bem como ser capaz de justificar suas decisões. Se você estiver começando com uma lista de pendências de produto bruto, o processo pode parecer quase assustadora. Felizmente, você não precisa solicitar perfeitamente todos os itens da lista de pendências imediatamente. Em Estimando, descrevi uma técnica chamada "The Big Wall," que é uma maneira eficiente de estimar uma lista de pendências de produto bruto rapidamente e trabalhar com acionistas para chegar a uma priorização aproximada.

Essa priorização aproximada é um bom ponto de partida e talvez seja bom o suficiente para suas circunstâncias. Em alguns casos, no entanto, você talvez queira refinar essas prioridades ou chegar a uma lista de pendências priorizada de maneira mais científica. Você pode fazer isso usando muitas técnicas. O seguinte artigo, falarei sobre três métodos comprovados muito vantajoso para muitas equipes Agile: o Kano modelo 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 um deles pode ajudá-lo a mudar de priorização aproximada da lista de pendências para uma ordenação precisas que pondera satisfatoriamente risco, importância e satisfação do cliente.

Modelo Kano de satisfação do cliente

O Kano modelo de satisfação do cliente foi desenvolvido na década de 1980 por Professor Noriaki Kano da Universidade de Rika Tóquio. O modelo fornece um esquema de classificação simples que faz distinção entre atributos essenciais e diferencial. Uma abordagem baseada em questionário, o modelo é uma maneira eficiente de visualizar as características de produto e stimulating debate dentro da equipe de design.

Em Kano, podemos pedir uma série de perguntas de duas formas diferentes: funcionais e não funcionais. Por exemplo, digamos que estão pedindo aos clientes sobre um sistema de navegação GPS carros. Primeiro, solicitamos o formulário funcional da pergunta:

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

Nós limitamos as respostas para as respostas a seguir:

• Eu gostaria que ele dessa forma

• Espero que ele seja dessa forma

• Estou neutro

• Eu poderia viver com ele dessa forma

• Não seria gosto dessa forma

Neste exemplo, vamos supor que nossos clientes fictícios responderam com "Gostei dessa forma."

Em seguida, perguntamos o formulário não funcionais da pergunta:

• Como você se sentiria se esse carro fez não têm um sistema de navegação GPS?

Nossos clientes fictícios podem escolher qualquer uma das respostas listadas. No entanto, a resposta pode ser e geralmente é, diferente. Neste exemplo, vamos supor que nossos clientes fictícios responderam "Esperado para ser dessa maneira" para o formulário não funcionais da pergunta.

Quando isso é feito por um projeto real, podemos fazer essa lista de opostas perguntas a vários grupos de clientes, ou seja, diferentes conjuntos de indivíduos que representam funções diferentes da organização do cliente. Você pode ter um grupo de marketing, um grupo de estatística, um grupo de fabricação e assim por diante. Para fins de Noções básicas sobre o modelo, no entanto, vamos imaginar que solicitamos apenas uma questão de apenas um grupo de clientes. Depois, compilar nosso par de resposta (as respostas ao formulário não funcionais e funcional), podemos mapeá-lo em uma grade, como mostra a tabela 1.

Tabela 1 – Kano mapeamento

Observe que, em nosso exemplo, nossos clientes fictícios respondeu como à pergunta funcional e esperar à pergunta não funcionais. Quando vamos mapear esse par à grade, podemos ver a interseção desses dois atributos é uma E, como destacado quadrado amarelo indica. Vamos examinar o que isso significa para nossa lista de pendências priorizada.

• E = Exciters. Esses são recursos que o cliente não esperava e que realmente diferenciar um produto de seus concorrentes. Elas são difíceis de identificar, especialmente inicialmente, pois pode ser difícil encontrar perguntas que extrair recursos interessantes. Por esse motivo, exciters tendem a surgir e aumentar prioridade conforme o andamento do projeto e comentários do cliente começa.

  • Os clientes recebem grande satisfação desses recursos e estiver dispostos a pagar um preço tê-los. Por exemplo, o iPod da Apple prazer clientes com sua capacidade intuitiva para transformar o conteúdo para corresponder à orientação da tela. A ausência de recurso seria não diminuíram satisfação, no entanto, porque o cliente não tiver conhecido esperado.

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

• B = a linha de base. Esses recursos devem ser no produto. Eles são o indispensável, recursos de alta prioridade.

  • Independentemente de como esses atributos básicos são executados, o cliente permanecerá neutro para o produto. Um processador de texto, por exemplo, deve ter "criar o documento" e "salvar o documento" funções. Eles são o preço de entrada.

  • Se tivesse perguntamos nosso grupo de clientes cintos, daria a maioria das pessoas que eles esperar um carro novo para acompanham cintos e que eles não gosto quando não. Se Mapeamos essas duas respostas na grade, podemos encontraria cintos são uma linha de base (B), recurso indispensável.

• L = Linear. Também conhecido como requisitos de desempenho, recursos lineares correlacionam diretamente a satisfação do cliente. Eles cair abaixo de recursos de linha de base em prioridade, mas devem ser ponderados em relação a seu custo.

  • Maior funcionalidade ou qualidade de execução aumenta a satisfação do cliente. Funcionalidade reduzida diminui satisfação.

  • Preço do produto geralmente está relacionado a esses atributos.

• Eu = indiferente. Esses recursos são menos importantes para o cliente e, assim, devem ser menos importantes para o produto. Eles provavelmente retornará pouco ou nenhum valor comercial.

A tabela 1 mostra também p e R.

• P: questionável – a pergunta provavelmente está incorreta ou a resposta é suspeito.

• R: inversa – não computa a combinação de respostas. O sistema de navegação GPS – se alguém responder que esperam que ele esteja aqui, mas que eles também como ele se não for, é uma resposta de R.

Se um par de resposta é classificada como p ou R, você deve investigar suas perguntas ou o par de resposta mais profundamente.

Jogos de inovação

Jogos de inovação são ferramentas para ajudá-lo a desenvolver primário de pesquisa de mercado. Com essas ferramentas, os clientes jogam "" com o objetivo de gerar comentários e informações sobre um produto ou serviço. Luke Hohmann criadas e descreve a mais de 12 desses jogos em seu livro, jogos de inovação, que é uma ótima adição a uma biblioteca. Meus jogos favoritos dois reproduzir para obter uma lista de pendências priorizada são aparar a árvore do produto e comprar um recurso, que descreve Luke neste trecho de livro (usado com permissão):

Aparar a árvore do produto

Jardineiros remove as árvores para controlar seu crescimento. Às vezes, a remoção é artística e, acabaremos com mudas com formato de animais ou formas abstratas interessantes. Grande parte do tempo que a remoção foi projetada para criar uma árvore balanceada que produz frutas de alta qualidade. O processo não é sobre "abrangente" – sobre "shaping." Use essa metáfora para ajudar a criar o produto desejado pelos seus clientes.

O jogo

Comece desenhando uma árvore grande em um papel de quadro de comunicações ou butcher ou imprimir uma imagem gráfica da árvore como um pôster de formato maior. Limbs espessas representam as principais áreas de funcionalidade dentro do seu sistema. A borda da árvore — suas ramificações externas — representa os recursos disponíveis na versão atual. Gravar possíveis novos recursos em várias placas de índice, o ideal é a forma de folhas. Pergunte aos clientes para colocar recursos desejados ao redor de árvore, definindo a próxima fase do seu crescimento. Eles estruturar uma árvore que está crescendo de forma equilibrada? Faz uma ramificação, talvez dos principais recursos do produto, obtenha a maior parte do crescimento? Um aspecto subutilizado da árvore se tornará mais forte? Sabemos que as raízes de uma árvore (seu suporte e customer care infra-estrutura) precisa estender pelo menos no que diz respeito a abóbada. Fazer sua?

Árvore de produto – Hohmann

Por que ele funciona

Você e seus clientes ambos os sabem que recursos variam em importância. Portanto, nós tendemos a colocar nossos esforços por trás de recursos mais importantes — os recursos que fornecem o maior valor aos clientes. Infelizmente, às vezes, isso significa que podemos colocar muito pouco esforço por trás de recursos que são necessárias para concluir o produto. A remover o jogo de árvore de produtos fornece aos seus clientes uma maneira de fornecer entradas sobre a decisão de tornar o processo examinando o conjunto de recursos que compõem o produto de forma abrangente.

Comprar um recurso

Qual recurso será convencer os clientes a adquirir o produto? Qual recurso fará com que os clientes a atualização? Qual recurso fará muito felizes que irá ignorar ou tolerar os recursos que desejarem você corrigir ou remover clientes?

Planejadores de produto infinitamente debater esses e outros tipos de perguntas. Escolha o conjunto certo de recursos a serem adicionados a uma versão geralmente marca a diferença entre a curto prazo falha ou sucesso a longo prazo. Infelizmente, muitos planejadores de produto fazer essa escolha sem envolver as pessoas mais afetadas por ela — seus clientes. A comprar um jogo de recurso melhora a qualidade dessa decisão pedindo a seus clientes para ajudar a torná-lo.

Comprar um recurso – Sterne

O jogo

Crie uma lista de possíveis recursos e fornecer cada um com um preço. Assim como em um produto real, o preço pode ser baseado no valor ao cliente, os custos de desenvolvimento ou algo mais. Embora o preço pode ser o custo real que você pretende carregar para o recurso, isso geralmente não é necessário. Os clientes compram recursos desejados na próxima versão do produto usando play dinheiro que você lhes. Certifique-se de que alguns recursos são cobrados tão alto que ninguém cliente adquiri-los. Estimule os clientes agrupem dinheiro para comprar recursos especialmente importantes e/ou caros. Isso ajudará a motivar negociações entre os clientes quais são os recursos mais importantes.

Este jogo funciona melhor com quatro a sete clientes em um grupo, para que você possa criar mais oportunidades para os clientes seu dinheiro com negociação do pool. Ao contrário do jogo da caixa do produto, a comprar um jogo de recurso baseia-se na lista de recursos que devem estar em seu roteiro de desenvolvimento.

Por que ele funciona

Planejadores de produto geralmente se encaixam a interceptação de pensar que os clientes tenham definido claramente prioridades do produto. Algumas fazem. A maioria não. Quando apresentado com um conjunto de opções, muitos clientes serão simplesmente dizer "Quero-los todos." e coloca a responsabilidade para priorizar suas solicitações nos seus ombros. Como alternativa, gerentes de produto geralmente reunir prioridades de recurso ao trabalhar com clientes individuais e, no processo e talvez sem mesmo perceber, mais uma vez assumir a responsabilidade para priorizar recursos. Por clientes atraentes como um grupo e dando-lhes uma quantidade limitada de recursos, você lhes fornece a oportunidade de priorizar seus desejos como um grupo. Mas isso é não onde está a mágica. A mágica está na estruturação de conversas para que seus clientes estão negociando entre si para recursos específicos. É essa negociação que aumenta sua compreensão do que seus clientes realmente desejam.

Peso relativo – Karl Weigers

Outro método excelente para priorização é pesagem relativa, que Karl Weigers apresentado em 1999. Esse método não apenas fornece um mecanismo para priorizar os requisitos com base nos comentários e entrada do usuário, mas também inclui a opinião da equipe de especialistas. Como Kano e jogos de inovação, peso relativo permite que o proprietário do produto ao medidor melhor os recursos implementar e em qual ordem de prioridade.

A primeira etapa é atribuir um peso para o benefício relativo de um recurso. Um benefício é a vantagem para os usuários de ter o recurso no produto final. Em seguida é atribuir a penalidade relativa. A caneta é a conseqüência para usuários de não ter o recurso no produto final. (Avaliar benefícios e as penalidades realiza a mesma coisa que o formulário funcionais e não funcionais do método Kano da pergunta.) Os pesos são números arbitrários que representam sua empresa como os valores benefícios e riscos de recursos. É muito semelhante a como professor determina qual peso atribuir lição de casa, presença, testes e testes para determinar a classificação geral; ele irá variar professor de professores. Se você decidir que os benefícios superam as penalidades, verifique o peso maior do que a penalidade por qualquer razão que desejar. Se você decidir que penalidades superam os benefícios, ajuste a ponderação adequadamente. No exemplo da tabela 2, demos o benefício um peso relativo de 2 e a penalidade um peso relativo de 1, que significa que o benefício será um maior fator para determinar a prioridade final.

Da mesma forma, podemos determinar o peso de percentual de custo e a porcentagem de risco. No exemplo a seguir, o risco foi nem como muito uma preocupação ao projeto, então porcentagem dos custos foi fornecido um peso de 1 e o risco de porcentagem um peso de 0,5. (Observe que, embora o benefício e penalidade são ponderadas antes do valor percentual é calculado, custos e riscos são ponderadas como porcentagens.) Se você tiver um projeto de alto risco, talvez peso maior do que o custo do risco.

Agora que os pesos são definidos, pedimos aos usuários classificar benefício relativo e penalidade relativa de cada recurso. Cada benefício e penalidade é classificado em uma escala de conjunto — Weigers recomenda 1 a 9, mas você pode escolher uma escala diferente enquanto você está consistente. O benefício relativo é o valor que fornecerá o recurso; penalidade relativa é o possível impacto negativo não fazendo o recurso.

Por exemplo, digamos que um recurso possível é "Tornar o widget cumprir com as leis Sarbanes-Oxley". Não há praticamente nenhum benefício relativo aos usuários, mas a penalidade relativa para a empresa é ótima - não fazê-lo poderia colocar a empresa em atividade. Como tal, veríamos uma pontuação de 1 ou 2 para o benefício relativo e uma pontuação igual a 8 ou 9 para a penalidade relativa.

No exemplo a seguir, os usuários classificada como o benefício relativo do recurso "Consultar o status de uma ordem de fornecedor" como 5. Eles classificada como sua penalidade relativa como um 3. Para obter o valor total do recurso, podemos multiplicar dois números por seus pesos relativos e adicioná-los juntos:

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

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

Nesse caso, o valor total para o recurso é 13 pontos.

Quando obtemos o valor relativo total e a porcentagem do valor para os recursos, podemos abandonar os usuários obter conhecimentos sobre o equipe. Pedimos a equipe para estimar o custo relativo para implementar cada recurso usando a mesma escala. Karl Weigers explica, "desenvolvedores estimam as classificações de custo com base em fatores como a complexidade do requisito, a extensão do trabalho de interface de usuário obrigatório, a capacidade potencial de reutilizar código, ou os projetos existentes e os níveis de teste e a documentação necessária."

Depois, podemos estimar o custo relativo, podemos estimar risco relativo. Novamente, Weigers diz: "desenvolvedores estimam o grau relativo de técnico ou outro risco associado a cada recurso em uma escala de 1 a 9. Uma estimativa de 1 significa que você pode programá-lo no modo de suspensão, enquanto 9 indica preocupações sérias possibilidade, a disponibilidade da equipe com o conhecimento necessário ou o uso de tecnologias e ferramentas não comprovadas ou desconhecidas. A planilha calculará a porcentagem do total risco proveniente de cada recurso."

Depois, observe os valores de benefício relativo, penalidade, custo e risco, vamos resumir cada coluna. Esses totais serão usados para calcular os percentuais.

• Total de porcentagem do valor: dividir o valor da soma dos benefícios relativo e penalidade pela soma total na parte inferior. No exemplo a seguir, isso é 13 / 154 = % 8.

• Relativo ao porcentagem dos custos: dividir o relativo ao valor de custo pela soma total custo relativo na parte inferior. In the following example, this is 2 / 42 = 4.8%.

• Porcentagem de risco relativo: dividir o valor de risco relativo pela soma total de risco relativo na parte inferior. In the following example, this is 1 / 33 = 3%.

• Prioridade: Dividir a porcentagem do valor por (porcentagem de custo * custo peso) + (porcentagem de riscos * peso de riscos). No exemplo a seguir, seria 8.4% / ((4.8% * 1) + (3% * 0,5). Assim, o valor de prioridade (1.345).

Depois que podemos obter os valores de prioridade, podemos classificar a coluna de prioridade em ordem decrescente, para que os itens de prioridade mais alta estão na parte superior. Como os itens são adicionados à lista de pendências de produto ou obter mais informações sobre uma história surge, precisaremos reavaliar prioridade.

No final, a folha de aparência nesta tabela:

Com essa abordagem, você pode entender melhor os intervalos que funcionam para a equipe e para os participantes. Ele também ajuda a Terra melhor discussões porque pode ser difícil de forma objetiva leve em elementos como benefício, penalidade, custo e risco para cada recurso.

Weigers explica como fazer o modelo que mais correspondem a realidade:

"Calibrar esse modelo para uso com um conjunto de requisitos concluídos ou recursos de um produto anterior. Ajuste os fatores de ponderação até que a sequência de prioridade calculado concorda com a sua avaliação após o fato importante como os requisitos de seu conjunto de teste eram realmente pacientes. Esse modelo pode ajudá-lo a tomar decisões de compensação ao avaliar novos requisitos propostos. Estime sua prioridade usando o modelo para informá-lo como eles com com requisitos existentes, assim você pode escolher uma sequência de implementação apropriada. Quaisquer ações que você pode tomar para mover priorização de requisitos de área da política em um objetivo e analíticos uma melhora a capacidade do projeto para fornecer a funcionalidade mais importante na sequência mais apropriada."

Karl Weigers escreveu dois livros em mais detalhes no peso relativo: requisitos de Software, Second Edition e mais sobre requisitos de Software: delicada problemas e conselhos práticos.

Se você usar um desses métodos ou alguma outra técnica, lembre-se de que a lista de pendências de produto é uma coisa de vida. Não priorizá-los apenas uma vez e, em seguida, feche-a — reprioritization é uma parte normal da manutenção de uma lista de pendências íntegra. Para manter seu projeto sob controle, você sempre deve reavaliar as histórias, sua importância para o projeto, e como novas informações afetam a lista de pendências. Você deve tomar dificuldades para manter suas partes interessadas e clientes envolvidos em todo o projeto. Além disso, você deve se lembrar de que a estimativa de um item é essencial para determinar sua prioridade. Não deixe que suas listas de pendências tornam-se obsoletos e chip. Investir o tempo e esforço no setor e sua lista de pendências de manutenção, você verá os resultados não só o produto final mas também em sua linha inferior.

Consulte também

Conceitos

Colaboração (mergulhe mais fundo) [redirecionado]

Colaborar [redirecionado]

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

Acompanhar trabalho e gerenciar fluxo de trabalho [redirecionado]

1. Requisitos de Software Agile, Dean Leffingwell, Addison Wesley

   "Qualidade atraente e deve-ser qualidade" Noriaki Kano, qualidade JSQC, Vol. 14, No.2, outubro de 1984. O artigo original da Kano.

2. Comecemos pelo primeiro: priorizar os requisitos de por e Karl. Wiegers