# data[].attributes.body
A Buy a Feature  é uma técnica de priorização bem interessante que utiliza o conceito de Retorno sobre Investimento (Return on Investment – RoI) onde os itens de um backlog são ordenados de forma colaborativa. A primeira parte deste técnica é similar ao método dos 100 pontos de Dean Leffingwell e Don Widrig (2003), onde o cliente possui 100 pontos para votar nos itens que entende ser mais prioritários. A segunda parte a técnica, utiliza o Planning Poker para estimar o esforço e assim poder calcular o RoI.  Veja mais detalhes no post abaixo.

# data[].attributes.attachment_link.readable_text
Muitos times têm dificuldade de priorizar quais as próximas coisas devem ser feitas do que está no backlog. Uma forma simples de priorizar é utilizando o Retorno sobre Investimento (Return on Investment - RoI). Podemos simplificar o RoI como uma equação onde o Retorno esperado é dividido pelo investimento que temos que fazer para construir algo.

Está sem tempo para ler? Experimente ouvir este artigo!

Quando conseguimos utilizar dinheiro para medir o RoI, as coisas ficam bem fáceis, todavia nem sempre conseguimos fazer tal coisa. Como então podemos priorizar o nosso backlog? Neste artigo veremos duas técnicas colaborativas que podemos utilizar para encontrar o Retorno e o Investimento.

Estimando o Retorno com Buy a Feature

Buy a Feature (Compre uma funcionalidade) é uma técnica criada por Luke Hohmann e apresentada em seu livro Innovation Games: Creating Breakthrough Products Through Collaborative Play (2006). Para utilizá-la é necessário que já tenhamos um backlog mínimo definido. Idealmente esse backlog não é muito extenso. Quanto maior, mais difícil será utilizar a técnica e é provável que tenhamos ido longe demais na definição de escopo.

Como exemplo, vamos imaginar que tenhamos o seguinte backlog composto por os itens A, B, C, D e E. Imaginemos também que há três stakeholders nessa reunião. A dinâmica é a seguinte:

1. Reúne-se um grupo de stakeholders, pessoas interessadas no produto / serviço que estamos construindo. Se possível, os consumidores finais.

2. Apresentamos os itens de valor descritos no backlog.

3. Cada pessoa receberá 100 moedas. Você pode utilizar dinheiro de jogos, fichas de poker ou apenas post-its indicando o valor.

4. As pessoas devem "comprar" os itens de backlog. Para tal, elas distribuirão as 100 moedas conforme elas desejarem.

No final, para cada item do backlog, somamos quantas moedas ele ganhou. O RETORNO é o somatório de moedas que o item recebeu. Aqui cabe uma dica importante. Caso existam itens que não receberam moedas, pense se não vale a pena descartá-los, afinal, os stakeholders não viram valor neles. Ordene o Backlog pelo retorno estimado.

Vantagens dessa técnica:

é colaborativa;

utiliza a inteligência coletiva do grupo;

permite que todos opinem;

é rápida;

independe de base histórica.

Desvantagens:

não é possível avaliar se o resultado obtido foi igual ao esperado;

não permite a comparação entre dois ou mais produtos ou serviços;

depende do know-how das pessoas que estarão presentes.

Estimando o investimento com Planning Poker

Planning Poker foi uma técnica criada por James Grenning em 2002 e divulgada em seu artigo Planning Poker or How to avoid analysis paralysis while release planning. O seu objetivo primário proporcionar um momento para que as pessoas que irão construir o produto possam conversar sobre como essa construção será feita. Ela é uma dinâmica de facilitação também evita que gastemos horas e horas de discussão para estimar o investimento necessário para construir um item do backlog. Antes de explicarmos o método, vejamos algumas considerações.

Esforço

No Planning Poker o investimento será o esforço necessário para construir um item do backlog. Esse esforço deve levar em consideração três aspectos:

Trabalho braçal: Para construir o item não há tanta complexidade, porém será necessário muito esforço manual. Exemplos: Copiar uma série de valores de um arquivo texto desestruturado para uma planilha.

Complexidade: Passaremos mais tempo pensando em como construir o item do que de fato construindo. Exemplo: Algoritmos complexos, alteração de esteiras de produção que já estão em funcionamento (sem pará-las).

Incerteza: Não sabemos exatamente como construir o item. Haverá alguma pesquisa prévia e algumas hipóteses técnicas serão validadas.

Escala de valores

Os valores que o esforço pode assumir são baseados na série de Fibonacci. Nela, a soma dos valores anteriores é igual ao próximo valor da série. Por exemplo: 1 + 2 = 3; 2 + 3 = 5...

Por que 8+13 ≅ 20 e não = 21? Porque sabemos que depois de certo ponto começamos a ter muitas incertezas e não temos mais precisão na estimativa.

Por que 13 + 20 = 40 e 20 + 40 = 100? Neste caso o esforço é tão alto que a imprecisão se torna igualmente elevada. Itens que recebem tais esforços são tão grandes e com tantas incertezas que representam um risco para construí-los. O melhor é fatiá-los.

Quem participa do Planning poker?

Só pontuará esforço quem participa ativamente da construção. Caso estejamos utilizando os papéis do Scrum, apenas o Time de Desenvolvimento. O Scrum Master facilita o Planning Poker e o Product Owner tira dúvidas, mas nenhum deles pontua.

"Só pontua quem suja a mão de graxa"
(Rodrigo de Toledo)

Setup

1. O Product Owner apresenta os itens do backlog para o Time de Desenvolvimento. Preferencialmente, após a estimativa de Retorno. A ordem de apresentação é dos mais valiosos para os menos valiosos.

2. O Time de Desenvolvimento escolhe o item mais fácil de ser construído e atribui o valor 2 para esse item.

3. A partir daí, o time irá comparativamente definir o esforço dos demais itens tendo o mais simples como base.

Para a próxima etapa, cada membro do Time de Desenvolvimento terá um baralho com as cartas indicando a escala de valores. Esses baralhos podem ser comprados, fabricados e até mesmo recebido em eventos sobre agilidade. Há também Apps que podem ser encontradas nas lojas de aplicativos como Google Play e App Store.

Por que estimar com o valor 2 e não o valor 1? Durante a vida do produto ou serviço é possível que encontremos um item que seja mais simples do que aquele que inicialmente pontuamos. Nesses casos, utilizaremos o valor 1.

Evite utilizar valores quebrados como ½ , pois só complicam as contas e não apresentam uma informação valiosa.

Execução do Planning Poker

Olharmos os itens do backlog. Para cada um:

O Product Owner lê o item.

1. Cada membro do Time de Desenvolvimento deve estimar o esforço que acredita que aquele item exigirá para ser construído levando em consideração os três aspectos (trabalho braçal, complexidade e incerteza) e o item base. Com o intuito de evitar que as estimativas de membros mais experientes interfiram na estimativa dos menos experientes, ninguém deve mostrar o esforço escolhido para ninguém.

2. O Scrum Master pede então para que as pessoas "joguem" (apresentem as suas estimativas).

3. Caso todos tenham dado o mesmo valor, esse é o esforço para executar o item. Podemos ir para o próximo e repetir toda a dinâmica.

Caso os valores não sejam iguais

Nesses casos temos que ir para o desempate. Imagine que para o Item A, os membros do time deram as seguintes estimativas: Beto 2 pontos, Ana 5 pontos, João 13 pontos, Maria 5 pontos e Miguel 8 pontos.

Quem deu os valores extremos, mais baixo e mais alto, devem explicar por que deram esses valores. Por que isso? É possível que a pessoa que deu o valor mais baixo não esteja consciente da complexidade, incerteza ou esforço braçal para concretizar o item de backlog. Por outro lado, a pessoa que deu a estimativa mais baixa pode conhecer mais sobre o assunto e esse será o momento dela explicar o caminho das pedras para os outros membros do Time de Desenvolvimento.

Uma vez apresentada as explicações. Todos os membros do time escolhem sua estimativa e jogam novamente. Esse processo se repete até que as estimativas convirjam para um único valor.

Não seja cri, cri (perfeccionista)

"Ninguém ganha dinheiro estimando."
Rodrigo de Toledo

Digamos que ao jogar o Planning poker para o item C, esse time imaginário tenha dado as seguintes estimativas: Beto 2 pontos, Ana 2 pontos, João 3 pontos, Maria 3 pontos e Miguel 3 pontos. Por regra há divergência e deveríamos jogar novamente. Todavia a distância é muito pequena e nem sempre valerá a pena fazer uma ampla discussão sobre o item. Pergunte se os que deram 2 pontos aceitariam trocar para 3 e siga para o próximo item do backlog.

Concluindo o Planning Poker

Ao final do Planning Poker teremos o Investimento (esforço necessário para construir cada item).

Quando fazer?

A estimativa de valor poderá ser feita sem a participação do time, desde que o Product Owner consiga a presença dos stakeholders. Já o Planning Poker deve ser feito nas Reuniões de Refinamento da Sprint.

Caso não dê tempo para estimar o retorno e nem o esforço antes da Sprint Planning (Planejamento da Sprint), eles terão que ser feitos durante ela. Nesse caso, leve biscoito, frutas e café, pois será demorado.

Duração?

Se tudo for feito com , no geral essas reuniões não passarão de 2 horas por Sprint. Caso a Sprint seja de uma semana, 1 hora de reunião para realizar as estimativas.

Cálculo do RoI do Backlog

Agora temos um Backlog com o Retorno Esperado e o Investimento. Podemos calcular o RoI.

Para cada item, dividimos o Retorno obtido pela técnica de Buy a Feature pelo Investimento obtido através do Planning Poker.

Agora podemos priorizar os itens de Acordo com o RoI. Os itens com RoI mais elevados devem ser feitos primeiro.

Algumas considerações

Quick Wins

Neste exemplo tivemos o item D que não possui muito valor, porém o investimento é baixo. Normalmente são os Quick Wins (vitórias rápidas). O item tem valor e o time gastará pouco o esforço para realizá-la.

Por favor, fatie.

Também tivemos o item B que tem muito valor, mas um RoI baixo. Esses casos podem ser um indicativo para que o Product Owner fatie o item. Quanto melhor o faturamento, maior o RoI.

Chegou um novo item no Backlog. O que fazer?

Algumas vezes não conseguiremos reunir os stakeholders para fazer o Buy a Feature. Quando isso acontecer, temos que ter em mente que estamos abrindo mão de algumas coisas. Nós podemos:

Aguardar enquanto juntamos mais histórias e convocar uma reunião com os stakeholders. Nesse caso, o Backlog ficará incompleto por mais tempo.

Utilizar a inteligência coletiva do Time Scrum para estimar o retorno. Utilizaremos mais tempo do time para estimar.

Product Owner estima. Não utilizamos a inteligência coletiva e aumenta a carga sobre o Product Owner.

Fatiei uma história. O que faço com as fatias?

Em tese, todo o processo é repetido. Use o bom senso.

Devo utilizar essas estimativas sempre?

Particularmente, prefiro utilizar métricas mais pragmáticas, tangíveis e comparativas. Para medição de Retorno, Métricas de Eficácia: Net Promoter Score (NPS), Receita, Churn, Conversões, Interações do consumidor final com o produto ou serviço, etc. Para o Investimento utilizo Métricas de Eficiência: Customer Lead Time, System Lead Time, Dependências Externas, etc.

Enquanto essas métricas não existem, usamos as estimativas.

Quer aprender mais sobre isso. Veja o nosso treinamento de Certified Scrum Product Owner (CSPO). Faça exemplo na prática e aprenda muitas técnicas essenciais para evoluir na sua carreira de PO.

# data[].attributes.attachment_link.description
Muitos times têm dificuldade de priorizar quais as próximas coisas devem ser feitas do que está no backlog. Uma forma simples de priorizar é utilizando o Retorno sobre Investimento (Return on Investment - RoI).

# data[].attributes.body
Técnica de priorização bem simples que consiste em comparar duas histórias a partir do topo da lista e ir corrigindo a sua posição no backlog conforme o entendimento de prioridade, poderá ser necessária diversas iterações até o completa priorização dos itens. A técnica se torna inviável caso a quantidade de itens no backlog seja muito grande. Mais detalhes sobre o algoritmo Bubble sort, acesse o link abaixo.

# data[].attributes.attachment_link.readable_text
Os algoritmos de ordenação servem para colocar um conjunto de itens (geralmente numericamente ou lexicalmente) em uma ordem. A entrada é uma lista de itens e o retorno do algoritmo é a lista, de forma que deve seguir a ordenação estabelecida.

Vale lembrar também que a aplicação de algoritmos de ordenação são extremamente importantes para operações que incluem outros tipos de algoritmo tais como: busca binária e união de itens. Em outras palavras - existem algoritmos que possuem a premissa de que a lista esteja ordenada para assim aplicá-los.

Neste primero artigo será explicado sobre o bubble sort. A ideia daqui para frente é em cada artigo descrever as ideias, vantagens, desvantagens e um exemplo em código implementando cada tipo de algoritmo.
Vamos ao Bubble Sort
Este algoritmo é um dos mais simples levando em conta a implementação, apesar de não ter um bom desempenho se comparado a outros tipos de algoritmos de ordenação

A ideia é sempre iterar toda a lista de itens quantas vezes forem necessário até que os itens estejam na ordem correta.

Durante a iteração, o algoritmo deve comparar e ordenar pares de valores: O item que se está iterando e o seu vizinho à direita (não se preocupe se não entender, pois o processo e implementação do mesmo será detalhado a seguir).

Seu tempo de execução depende da ordem que a lista se encontra.

O melhor caso para o bubble sort é enviar uma lista com itens já ordenados na entrada, pois o algoritmo percorrerá a lista apenas uma vez, dado que após a primeira iteração os itens estarão já ordenados. Logo, seu tempo de execução no melhor caso é percorrer toda a lista uma vez, o que chamaremos de N.

Exemplificando: ao executar o bubble sort emuma lista já ordenada com cinco itens (Exemplo: 1, 2, 3, 4, 5), o algoritmo precisa irá iterar do primeiro ao quinto elemento, totalizando em cinco operações.

O pior caso é quando os menores elementos se encontram ao final da lista (na verdade, o pior é caso é uma lista em ordem decrescente). Serão necessárias muitas iterações na lista para "trazer" esses números menores para suas posições correspondentes na ordenação.

Exemplificando: no caso de ordenar uma lista decrescente com os valores [5, 4, 3, 2, 1] (de novo, não se preocupe, pois o funcionamento do algoritmo será explicado a seguir), teríamos vinte processos (ou mais precisamente, a diferença entre o número de elementos na lista ao quadrado e o tamanho da lista -> n² - n, neste caso 25-5 = 20):

Processo 1: [4, 5,3, 2, 1]

Processo 2: [4, 3, 5, 2, 1]

Processo 3: [4, 3, 2, 5, 1]

Processo 4: [4, 3, 2, 1, 5]

Processo 5: [3, 4, 2, 1, 5]

Processo 6: [3, 2, 4, 1, 5]

Processo 7: [3, 2, 1, 4, 5]

Processo 8: [3, 2, 1, 4, 5]

Processo 9: [2, 3, 1, 4, 5]

Processo 10: [2, 1, 3, 4, 5]

Processo 11: [2, 1, 3, 4, 5]

Processo 12: [2, 1, 3, 4, 5]

Processo 13: [1, 2, 3, 4, 5]

Processo 14: [1, 2, 3, 4, 5]

Processo 15: [1, 2, 3, 4, 5]

Processo 16: [1, 2, 3, 4, 5]

Processo 17: [1, 2, 3, 4, 5]

Processo 18: [1, 2, 3, 4, 5]

Processo 19: [1, 2, 3, 4, 5]

Processo 20: [1, 2, 3, 4, 5]

Para o exemplo, será utilizada uma lista de itens com seis elementos ([5, 3, 1, 2, 4, 0]).

Serão comparados respectivamente os valores do primeiro e o segundo item da lista.

Neste caso, sim: o primeiro item é maior que o segundo. Então para manter a ordem, devemos trocá-los de posição!

. Precisamos também dizer ao algoritmo que houveram alterações e portanto, mesmo que os itens fiquem ordenados nesta primeira iteração, a lista deverá ser percorrida novamente utilizando as mesmas regras de ordenação posteriormente.

Agora, deve-se comparar o segundo item da lista com o terceiro, seguindo a mesma lógica acima:

Novamente, sim! Notificamos o algoritmo da mesma forma que houveram itens que não estavam ordenados na iteração. Logo, devemos trocar seus valores de posição

Seguimos com a mesma lógica. Para não ficar repetitivo, será apenas demonstrar o que ocorre com a lista até o final do processo explicado acima.

Ao final da primeira iteração, a lista estará então dessa forma:

Como o algoritmo foi "notificado" para continuar iterando(novamente - isso sempre ocorre quando houver troca de valores na iteração atual), utilizaremos o mesmo processo descrito anteriormente.

Para não ficar repetitivo,n ão será explicado tão detalhadamente como na primeira iteração, pois a ideia é exatamente igual: se o valor do item à esquerda for maior que o seu vizinho à direita, os valores devem ser trocados de posição e o algoritmo notificado que ao término desta iteração, o processo deve ser realizado novamente.

Ao final da primeira iteração, a lista estará então dessa forma:

Como o algoritmo foi "notificado" para continuar (pois houveram troca de valores na primeira iteração), utilizaremos o mesmo processo descrito anteriormente.

Ao final da terceira iteração, a lista estará então dessa forma:

Como o algoritmo foi "notificado" para continuar (pois houveram troca de valores na terceira iteração), utilizaremos o mesmo processo descrito anteriormente.

Ao final da quarta iteração, a lista estará então dessa forma:

Como o algoritmo foi "notificado" para continuar (pois houveram troca de valores na quarta iteração), utilizaremos o mesmo processo descrito anteriormente.

Apesar da lista finalmente estar ordenada, houveram troca de valores entre posições e portanto, uma iteração adicional será necessária

Note que desta vez, não houve quaisquer alterações ao percorrer a lista. O que isso significa?

A lista está finalmente ordenada! O algoritmo não precisa mais percorrer!
Implementação
Abaixo segue uma implementação em Python:

if __name__ == '__main__':def bubble_sort(items): had_swapwhile had_swap: #Enquanto na iteração houver troca de valores (swap)
 had_swap = def swap(items, index):
 print(bubble_sort([5, 4, 3, 2, 1]))
 items[index], items[index + 1] = items[index + 1], items[index] False #Configura como falso inicialmente
 for i in range(len(items) - 1):
 if items[i] > items[i + 1]: #Caso os elementos sendo comparados estejam desordenados
 swap(items, i) #Realiza a troca de valores nas posições
 had_swap = True #Como houveram troca de valores, deve-se continuar a iteração  = True #Inicializa como True para passar ao menos uma vez no laço return items

E com isso, encerramos nosso primeiro algoritmo de ordenação \o/!

# data[].attributes.attachment_link.description
Os algoritmos de ordenação servem para colocar um conjunto de itens (geralmente numericamente ou lexicalmente) em uma ordem. A entrada é uma lista de itens e o retorno do algoritmo é a lista, de forma que deve seguir a ordenação estabelecida.

# data[].attributes.body
Este método é muito utilizado principalmente para priorizar uma lista de problemas do produto. A priorização é realizada com base nos critérios Gravidade, Urgência e Tendência. Acesse o link abaixo para ver detalhes de como utilizar essa técnica.

# data[].attributes.body
O modelo KANO é um framework de priorização que utiliza uma pesquisa das funcionalidades do produto direto para os clientes. É um método que exige mais esforço para a realização da priorização e é ideal para ser mais assertivo na escolha das funcionalidades.

# data[].attributes.attachment_link.readable_text
O Modelo Kano é uma dos muitos frameworks de priorização, desenvolvido pelo Dr. Noriaki Kano, professor de gestão da qualidade na Universidade de Ciências de Tóquio 1984. O Modelo Kano se baseia na satisfacão dos clientes em relação as funcionalidades oferecidas, onde os recursos podem ser divididos em 4 categorias: performance, esperadas, atraentes e indiferente.
Você, como gerente de produto, se olhar para seu backlog, aposto que tem uma infinidade de features que precisam ser desenvolvidas - tem contribuições de sua equipe, stakeholders, clientes, clientes em potencial e qualquer pessoa com uma palavra a dizer sobre o produto.

Claro, que você não vai construir tudo que as pessoas estão solicitando. Você tem alguns palpites do que funciona e do que não é o ideal para o produto, mas você como um bom gerente de produto, você precisa de dados para tomar uma decisão.

Os dados existem para ajuda-lo a tomar uma decisão de impacto. Mas como você consegue saber:

Como medir a satisfação do usuário?

Como escolhemos o que construir para fornecê-lo?

Como vamos além da satisfação para o deleite ?

É aqui que uma ferramenta como o modelo Kano pode ser útil. É uma técnica simples e versátil para decidir quais recursos um produto ou serviço deve ter.

Neste artigo, examinamos as origens e os detalhes do Modelo Kano e exploramos um guia de cinco etapas para usá-lo para ajudá-lo a desenvolver um produto ou serviço que irá encantar seus clientes - sem levar seu negócio à falência!

O Dr. Noriaki Kano, professor de gestão da qualidade na Universidade de Ciências de Tóquio, criou o modelo em 1984. Como o autor Dave Verduyn , o Dr. Noriaki desenvolveu essa estrutura enquanto pesquisava os fatores que contribuíam para a satisfação e a lealdade do cliente.

Kano diz que um produto ou serviço envolve muito mais do que apenas funcionalidade. É também sobre as emoções dos clientes. Por exemplo, todos os clientes que compram um carro novo esperam que ele pare quando pisar no freio, mas muitos ficarão maravilhados com seu sistema de assistência ao estacionamento ativado por voz.

O modelo incentiva você a pensar sobre como seus produtos se relacionam com as necessidades de seus clientes, enquanto muda de uma abordagem "mais é sempre melhor" para o desenvolvimento de produtos para uma abordagem "menos é mais". Os 3 princípios básicos são:

O valor atrai clientes,

A qualidade mantém os clientes e cria fidelidade,

A inovação é necessária para se diferenciar e competir no mercado.

O Modelo Kano (pronuncia-se "kah-no") é uma abordagem para priorizar recursos em um roadmap de produtos com base no grau em que eles provavelmente satisfarão os clientes. As equipes de produto podem avaliar um recurso de alta satisfação em relação aos custos de implementação, para determinar se a inclusão ou não no roadmap é uma decisão estratégica.

O modelo identifica cinco categorias de reações de clientes em potencial a um novo recurso, variando de insatisfação a indiferença, até o que muitos chamam de prazer ou excitação do cliente.

Usando o modelo, as equipes de produto reúnem uma lista de novas features em potencial que disputam recursos e espaço de desenvolvimento no roadmap. A equipe avaliará essas features de acordo com dois critérios concorrentes:

Seu potencial para SATISFAZER os clientes.

O INVESTIMENTO necessário para implementá-los.

O gráfico do modelo apresentado a seguir pode ser útil na definição de cada uma das categorias listadas. O eixo y é a satisfação do cliente e o eixo x é a implementação de features.

A estrutura do Modelo Kano é baseada em 3 fatores de analise:

A satisfação dos clientes com as features de produto depende do nível de funcionalidade oferecido;

As features podem ser classificados em quatro categorias ;

Você identifica como os clientes se sentem atravês de um questionário de avaliação .

* Satisfação vs Funcionalidade

Satisfação. O modelo Kano propõe uma dimensão que vai da satisfação total (também chamada de excitação) à total insatisfação (ou frustração), onde essa dimensão é anotada com diferentes níveis de satisfação.

Funcionalidade. Também chamada de Investimento ou Implementação, ela representa quanto de uma determinada feature o cliente obtém, quão bem o implementamos ou quanto investimos em seu desenvolvimento. Essa dimensão vai desde a ausência de funcionalidade até a melhor implementação possível. É por isso que o termo "Investimento" também é muito bom para esse conceito.

Essas duas dimensões juntas são a base do Modelo Kano e determinam como nossos clientes se sentem sobre as features de nosso produto..

* As 4 categorias de features

Kano classifica as features em quatro categorias, dependendo de como os clientes reagem ao nível de funcionalidade fornecido.

1 - Performance (Performance)

A primeira categoria de features são as de perfomance. As características de perfomance são 1) cuidadosamente avaliadas pelo cliente e levadas em consideração ao fazer uma compra, 2) aumentam a satisfação do seu cliente quanto melhor você as implementar.

Por causa dessa relação proporcional entre Funcionalidade e Satisfação, essas features têm um efeito linear na satisfação do cliente (inclusive muitas vezes são chamadas de "linear"). Eles trarão satisfação para os usuários finais quando presentes e insatisfação quando ausentes.

Por exemplo, ao comprar um carro, o consumo de combustível geralmente é um atributo de desempenho. Outros exemplos podem ser a velocidade de sua conexão com a Internet; vida útil da bateria do laptop; ou o espaço de armazenamento em sua conta Dropbox. Quanto mais você tem de cada um deles, maior sua satisfação.

No gráfico do modelo, vemos a dinâmica de reação dos clientes a esse tipo de feature. Cada aumento na funcionalidade leva a uma maior satisfação. Também é importante ter em mente que quanto mais funcionalidades adicionamos, maior o investimento que temos que fazer (por exemplo, a equipe para construí-lo, os recursos necessários, etc.)

2 - Esperadas (Must-be)

A segunda categoria de features são as esperadas pelos clientes. Se o produto não os tiver, será considerado incompleto ou simplesmente ruim. Esse tipo de features é geralmente denominado Obrigatório ou Expectativas básicas .

O problema com esse tipo de feature é: da perspectiva do cliente, os recursos de limite estão presentes ou não. Eles têm um efeito binário sobre a satisfação: se os usuários esperam uma certa capacidade e ela não funciona, eles ficam frustrados, mas quando funcionam bem, isso não os agradará. Essas características podem, no máximo, atingir uma satisfação neutra.

Além disso, eles não são fáceis de identificar, pois os usuários raramente os afirmam: eles simplesmente parecem óbvios demais para serem mencionados. Neste caso, repense a questão e em vez de perguntar, por exemplo:

Esperamos que nossos telefones sejam capazes de fazer chamadas. Nosso quarto de hotel deve ter água corrente e uma cama. O carro deve ter freios. Ter qualquer um deles não nos deixará felizes, mas a falta deles certamente nos deixará com raiva do produto ou serviço.

Observe como a curva de satisfação se comporta no gráfico acim. Mesmo o menor inveastimento contribui muito para aumentar a satisfação. Mas também observe como a satisfação nunca atinge o lado positivo - não importa o quanto investimos na feature, nunca deixaremos nossos clientes mais satisfeitos com o produto. A boa notícia é que, uma vez atingido um nível básico de expectativas, você não precisa mais investir nele.

3 - Atraente (Attractive)

Existem características inesperadas que, quando apresentadas, causam uma reação positiva. Essas são chamados de Atraentes. Podemos ter reações que variam de atratividade moderada a deleite absoluto, e ainda ter tudo se encaixando sob o nome "Atrativo".

Esses tipos de features não resultam em insatisfação quando ausentes, e a experiência não é de forma alguma afetada negativamente, uma vez que nunca foram previstos. No entanto, se bem executado, surpreender os clientes com um atributo de prazer pode causar sua excitação excessiva com o produto (e possivelmente incentivar uma recomendação boca a boca).

A primeira vez que usamos um iPhone, não esperávamos uma interface de tela sensível ao toque tão fluida, e isso nos surpreendeu. Você sabe, aquela sensação que você tem quando experimenta algo além do que você conhece e espera de produtos semelhantes.

Um ponto muito importante ao avaliar features atraente" é fundamental avaliarmos o contexto do usuário e a experiência geral: os prazeres não funcionam com usuários frustrados cujas expectativas básicas não atendem. Você simplesmente precisam garantir as duas extremidades.

Além disso, investir em empolgação encanta os usuários, mas eles costumam ter vida curta.

O que costumava ser legal se torna ultrapassado em nenhum momento, especialmente na economia digital. O que antes era "a melhor coisa depois do pão fatiado" se torna comum, e o que costumava agradar os clientes se torna básico, esperado e necessário.

Depois que os concorrentes começam a implementá-los junto com todos os outros no mercado, os prazeres gradualmente mudam seu caminho para as expectativas básicas. Em conseqüência, novos devem ser fornecidos continuamente.

Dica: não precisamos ficar extremamente surpresos para que algo se enquadre nessa categoria. Pode ser qualquer coisa que te faça pensar: "Ei, que legal!".

Isso é melhor explicado graficamente. Veja como até mesmo algum nível de Funcionalidade leva ao aumento da Satisfação e com que rapidez ela aumenta. Esse fato é a chave para controlar o investimento que fazemos em um determinado recurso. Além de um certo ponto, estamos apenas exagerando.

4 - Indiferente (Indifferent)

Naturalmente, também existem características para as quais nos sentimos indiferentes . Aquelas cuja presença (ou ausência) não faz diferença real na nossa reação ao produto.

Esses recursos estão no meio da dimensão Satisfação (onde o eixo horizontal os cruza). Isso significa que não importa quanto esforço colocamos neles, os usuários realmente não se importarão. Essa é outra maneira de dizer que devemos realmente evitar trabalhar nisso, porque você pode desperdiçar recursos valiosos.

Bonus: Reversas

O recurso é considerado reverso quando sua ausência traz a satisfação do cliente e sua presença resulta em insatisfação. Esses são os que você deseja identificar e manter fora do seu produto. A implementação de tais recursos aumenta os custos de design e desenvolvimento, enquanto diminui o valor do produto para os clientes.

Um pequeno exemplo desse tipo de qualidade foi o pequeno "ajudante de clipe de papel" da Microsoft. A maioria das pessoas não gostava e era ainda mais irritante porque era difícil desligá-lo, a menos que você soubesse o segredo para desativá-lo.

* O questionário de percepção Kano

Para descobrir as percepções de nossos clientes em relação aos atributos de nosso produto, precisamos usar o questionário Kano. Ele consiste em um par de perguntas para cada feature que queremos avaliar:

1. Como se sentem SE possuem a feature; Essa primeira pergunta é chamada de forma funcional

2. Como se sentiriam SE NÃO tivessem a feature; A segunda pergunta é chamada de forma disfuncional (também são chamadas de positiva e negativa por Jan Moorman )

Essas perguntas não são aplicadas como uma pergunta aberta, na verdade, fazemos essa pergunta e usamos uma Escala Likert para a resposta. Para cada "como você se sentiria se tivesse / não tivesse essa feature", as respostas possíveis são:

Com as respostas mapeadas, nós fazemos uso da tabela de avaliação que combina as respostas funcionais e disfuncionais em suas linhas e colunas (respectivamente) para chegar a uma das categorias descritas anteriormente. Cada par de respostas leva a uma dessas categorias e a mais algumas decorrentes do uso desse formato de pergunta.

Modelo Kano - Tabulação dos Resultados
Tabela revisada de Fred Poulio

Dado o fato de que estamos perguntando dos dois lados da mesma coisa, seremos capazes de dizer se:

Alguém não entendeu totalmente as perguntas ou features que estamos descrevendo;

O que propomos é na verdade o oposto do que eles querem.

Devemos tentar internalizar como cada categoria é derivada de um par de respostas, para entender melhor o modelo e evitar a necessidade de consultar a tabela todas as vezes:

R - Reverso. Se alguém disser que "não gosta" da versão funcional e "gosta" da versão disfuncional, essa pessoa claramente não está interessada no que estamos oferecendo e talvez realmente queira o oposto.

Q - Questionável. Ao obter respostas conflitantes (como "Gosta" e "Gosta") para ambas as perguntas, você tem uma resposta questionável.

P - Perfomance. São aqueles em que os clientes "Gosta" de tê-los e "Não gosta" de NÃO tê-los . Essa reação extrema traduz a relação linear "mais é melhor" entre essas duas dimensões.

M - Must-be (obrigatórios). Features obrigatórios são os casos restantes em que o cliente "não gosta de não tê-los". Os clientes esperam ter a feature.

A - Atraentes.Features atraentes são encontrados quando um cliente "gosta de ter" e não ficou surpreso pela sua existência. Essa é outra maneira de dizer que o que estamos propondo é novo e atraente.

I - Indiferentes. Eles ocorrem para qualquer resposta "Eu sou neutro" ou "Eu posso tolerar isso", para as questões Funcionais ou Disfuncionais. Ou seja, ocupam as células intermediárias da tabela.

Agora que temos uma compreensão da estrutura do Modelo Kano, é hora de entender o passo a passo para coloca-lo em prática e analisar os resultados. Nosso objetivo como gerentes de produto é determinar quais features levam a clientes mais satisfeitos e usar essas informações para nos ajudar a priorizar o que precisamos construir.

Etapa 1 - Escolha as features e usuarios
* Escolhendo as features
As features que você escolhe são aquelas que o usuário vai receber um benefícios ao utiliza-la. Como estamos medindo a satisfação do cliente com nosso produto, precisamos avaliar features que ele irá fazer uso. Por isso, não adicione débitos técnicos, mudanças de framework ou fornecedor.

Faça uma lista com todas as features que você vai avaliar. Você pode ver um exemplo na tabela abaixo:

Dica: limite a quantidade de features que você inclui em sua pesquisa, especialmente se estiver fazendo o estudo com participantes voluntários. Isso deve melhorar seus níveis de participação e a atenção disponível de seus assuntos.
* Selecionando os clientes
Ao selecionar clientes (ou prospectos) para participar de seu estudo, você deve considerar algum grupo demográfico ou persona a que pertençam. Sua base provavelmente não é homogênea e o que eles pensam de sua feature também não é. Mas se você levar em consideração algum agrupamento ao qual eles pertencem, você pode reduzir significativamente o ruído em sua análise.

Por exemplo, suponha que você esteja trabalhando em um SaaS B2B. Se você está pensando em adicionar uma feature que permite aos usuários associar faturas a pedidos de compra, sua atratividade para uma pequena empresa é muito diferente de um cliente corporativo.

Etapa 2 - Obtenha os melhores dados dos usuários
* Escreva perguntas claras
Escreva suas perguntas o mais claras e sucintas possível. Cada um deve representar uma unica feature e se a feature for complexo e exigir várias etapas e subprocessos, você provavelmente deve analisar a questão.

Suas perguntas devem ser formuladas em termos de benefícios para o usuário , e não em termos do que o produto será capaz de fazer. Por exemplo, " se você pode melhorar automaticamente a aparência da sua foto, como você se sente?" é melhor que " se você tem MagicFix, como se sente? ".

Atenção: Tenha cuidado com as palavras polares dos pares de perguntas. Ou seja, a questão disfuncional não é necessariamente o oposto da funcional; é apenas a ausência da funcionalidade.
* Mostre as features
Sempre que possível, descreva os benefícios de uma feature, em seguida, mostrar um protótipo e wireframes, e por fim, faça a pergunta sobre como ele se sente. Por ter essa "explicação" visual e dinâmica, o usuário pode ter uma compreensão mais clara do que está sendo proposto a ele.

Dica: lembre de perguntar como ele se sentiria logo após o uso ou apresentaçao da feature. Dessa forma sua memória ainda esta fresca.
* Pergunte a importância da feature
Um acréscimo importante ao framework Kano é incluir a pergunta " pergunta aos clientes o quão importante um determinada feature é para eles " após o par funcional / disfuncional. Esta informação é útil para saber quais features são as mais relevantes para os clientes.

A pergunta de importância pode ser feita no seguinte formato: " Quão importante é ou seria se: <requisito>? ". Por exemplo, "Quão importante é ou seria se: a exportação de vídeos sempre leva menos de 10 segundos?".

Dica: As respostas devem ser na forma de uma escala de 1 a 9, indo de "Nada importante" a "Extremamente importante".

Etapa 3 - Analise os resultados

Depois de tabular e processar os resultados, devemos ser capazes de categorizar as features e obter insights sobre a melhor maneira de priorizá-los.

Existem dois níveis de análise em que podemos entrar: discreta e contínua. Esses não são termos oficiais, mas foi o que eu encontrei nas minhas pesquisas. Ambos são referências a conceitos matemáticos e se relacionam com a forma como eles mapeiam as respostas dos participantes às categorias de Kano.

* Análise discreta

A maneira mais simples de trabalhar com os resultados do Kano é:

1. Divida os respondentes pelos critérios demográficos / pessoais que os definem;

2. Categorize as respostas de cada entrevistado usando a tabela de avaliação;

1. Etapa 1 - Para cada feature que deseja avaliar;

2. Etapa 1 - Faça as 2 perguntas para respondente;

3. Etapa 1 - E categorize na tabela de avaliação;

3. Calcule o total de respostas em cada categoria;

4. O resultado será a resposta mais frequente;

5. No caso de resultados próximos entre categorias, use a seguinte regra (ganha mais à esquerda): Esperada (must-have) -> Performance -> Atrativa -> Indiferente;

6. Se você pediu aos entrevistados uma classificação de importância declarada (e deveria), faça a média para cada característica.

Você acabará com uma mesa como esta:

Se você estiver vendo vários resultados sem uma categoria clara, pode haver perfis de clientes ocultos que você não está considerando. Nesse caso, você provavelmente deve voltar às respostas do cliente para procurar padrões; tente verificar quais respostas dos clientes geralmente são iguais às de outros clientes, para encontrar "grupos demográficos" que você pode estar perdendo.

Este tipo de análise é ótimo para lhe dar um primeiro nível de compreensão e é útil em muitos contextos onde você não precisa de uma abordagem mais rigorosa. Por exemplo, testar ideias de design ou fazer um rascunho de seu roadmap.

RESULTADO: Na tabela de resultados, você pode classificar as features de acordo com sua importância. Depois disso, a regra geral a ser usada ao priorizar é ir atrás de todos os features "Esperada", adicionar o máximo de features de "Perfomance" que puder e, finalmente, incluir alguns "Atrativas".

* Análise continua

Primeiro, cada opção de resposta é traduzida em um valor numérico dentro de uma escala de potencial de satisfação , indo de -2 a 4. Quanto maior o número, mais uma resposta reflete o quanto o cliente deseja a feature. A importância também é pontuada de 1 a 9, como antes.

Funcional : -2 (não gosta), -1 (vive com), 0 (neutro), 2 (deve ser), 4 (gosta);

Disfuncional : -2 (gosta), -1 (deve ser), 0 (neutro), 2 (viver com), 4 (não gosta);

Importância : 1 (Nem um pouco importante), ..., 9 (Extremamente importante.)

Pontuações mais altas (positivas) significam maior potencial de satisfação. No caso de respostas disfuncionais, "Não gostar" de algo significa que há uma forte discordância com a ausência da feature. Assim, haveria mais potencial de satisfação se fosse incluído e por isso tem uma pontuação maior.

A razão para esta escala assimétrica (começando de -2 em vez de -4) é que as categorias que você obtém de respostas na extremidade negativa (reversa e questionável) são mais fracas do que você obtém na extremidade positiva (deve ser e desempenho) . Assim, DuMouchel decidiu enfatizar esse lado da escala.

Essas pontuações levarão à categorização de nossas características dentro de um plano bidimensional. Com este método, não há mais necessidade da tabela de avaliação padrão .

Nosso foco deve estar no quadrante positivo, que contém as respostas mais fortes. Fora dele, encontramos respostas mais fracas, bem como categorizações questionáveis ​​e reversas. Se uma feature terminar como "Reversa", você sempre pode usar o truque de defini-lo como o oposto e alternar as pontuações "Funcional" e Disfuncional, para que seja classificado em outra categoria Kano; você também pode retirá-lo de seu estudo.
* Categorizando as features
Se tivermos números para cada resposta possível, isso significa que podemos trabalhar com médias. Aqui está o que precisamos calcular para cada feature:

1. Os valores médios funcionais, disfuncionais e de importância de todas as respostas;

2. O desvio padrão para as pontuações Funcionais, Disfuncionais e Importância.

Pegando as pontuações Funcionais e Disfuncionais de cada feature, podemos colocá-los no plano de categorização:

É claro que estamos falando sobre médias e o que elas escondem são as variações possivelmente grandes em nossos dados. É por isso que é útil adicionar o desvio padrão ao nosso gráfico na forma de barras de erro, para que tenhamos uma noção de como nossas categorizações estão dentro ou fora do alvo.

A camada final a ser adicionada é a pontuação de importância. Podemos visualizar essa dimensão adicional convertendo os pontos do gráfico de dispersão em bolhas, com tamanhos proporcionais à sua importância. Dessa forma, podemos comparar facilmente as features com posicionamento semelhante.

A regra geral de priorização apresentada na seção de análise discreta ainda é válida:
Esperadas (must-have) -> Perfomance -> Atrativas -> Indiferente
Para pequenos conjuntos de features, outra maneira de visualizar isso é por meio de uma lista de classificação de lista. Ele usa três colunas para classificar as features, nesta ordem (da pontuação mais alta para a mais baixa): potencial de insatisfação, potencial de satisfação e importância.

Em nosso caso, as duas primeiras colunas são as pontuações disfuncional e funcional, respectivamente.

O Modelo Kano pode ser um framework útil para equipes de produtos com tempo e recursos limitados, e que desejam garantir que priorizam o mix apropriado de features para trabalhar a seguir.

Essa abordagem é mais eficaz para as equipes que precisam de orientação para descobrir quais são os recursos mínimos que precisam criar, quais recursos de desempenho começarão a investir agora e quais recursos de satisfação do cliente oferecerão o maior cliente "Uau!".

Como o consultor de gerenciamento de produtos Daniel Zacarias: "Existem muitas razões diferentes pelas quais você pode precisar incluir umm determinada feature, mas o que você faz para saber quais deles farão seus (futuros) clientes felizes e preferem isso a outros?"

O Modelo Kano pode ajudar as equipes de produtos a responder a essa pergunta muito importante.

Não há solução mágica quando se trata de priorizar os recursos de nosso produto. Embora tenhamos que considerar muitas dimensões diferentes, a satisfação do cliente é provavelmente a mais importante. Isso nos levou às perguntas das quais partimos:

Como medimos a satisfação?

Como escolhemos o que construir para fornecê-lo?

Como vamos além da satisfação para o deleite ?

Essas perguntas não têm respostas definitivas (se houver, todos nós precisamos procurar outro emprego)

O Modelo Kano é uma estrutura útil para equipes de produtos que procuram uma abordagem sistemática para priorizar features. Ajuda as equipes interessadas em priorizar as funcionalidades que eles acreditam que irão encantar os clientes.

Se tiver duvidas sobre como escolher o melhor framework de priorização para seu time, escrevi um artigo para ajuda-lo nessa tarefa, basta clicar no link a seguir.
Referências:

Folding Burritos - Complete guide Kano Model (LINK);

Wikipedia - Noriaki Kano (LINK);

MindTools - Kano Model Analysis (LINK);

Jan Moorman, "Measuring User Delight using the Kano Methodology";

Gary Burchill, "Observação do uso do método de Kano" em "Métodos de Kano para compreender a qualidade definida pelo cliente", Center for Quality of Management Journal, outono de 1993;

Robert Blauth, Reinhart Richter e Allan Rubinoff, "Experiência no uso dos métodos de Kano na especificação da BBN RS / 1 versão 5.0" em "Métodos de Kano para compreender a qualidade definida pelo cliente", Center for Quality of Management Journal, outono de 1993;

Mike Timko, "An Experiment in Continuous Analysis" on "Kano's Methods for Understanding Customer-defined Quality", Center for Quality of Management Journal, outono de 1993;

UX Collective - Choosing the Right Features with Kano Model (LINK);

Airfocus - Kano Model (LINK\);

Pouliot, Fred, "Theoretical Issues of Kano's Methods" on "Kano's Methods for Understanding Customer-defined Quality", Center for Quality of Management Journal, outono de 1993;

# data[].attributes.attachment_link.title
O framework de priorização: Modelo Kano - Vida de Produto

# data[].attributes.attachment_link.description
O Modelo Kano é uma dos muitos frameworks de priorização, desenvolvido pelo Dr. Noriaki Kano, professor de gestão da qualidade na Universidade de Ciências de Tóquio 1984. O Modelo Kano se baseia na satisfacão dos clientes em relação as funcionalidades oferecidas, onde os recursos podem ser divididos em 4 categorias: performance, esperadas, atraentes e indiferente.

# data[].attributes.body
Acrônimo para as categorias Must Have (Tenho que fazer), Should Have (Devo fazer), Could Have (Poderia fazer) e Won’t Have (Não vou fazer), essa é uma ótima ferramenta para priorização de histórias de um backlog. Mais detalhes no link abaixo.

# data[].attributes.body
Também é uma matriz de priorização que ajuda o gestor a priorizar projetos ou funcionalidades que terão maior retorno para a empresa. Esta priorização é baseada do Reach (alcance), Impact (impacto), Confidence (confiança) e Effort (esforço). No artigo abaixo vocês encontram detalhes sobre essa matriz de priorização

# data[].attributes.body
Ferramenta de fácil aplicação que pode nos auxiliar na priorização de histórias ou projetos. Os itens a serem priorizados são colocados nos quadrantes de acordo com o Custo e o Benefício, no exemplo abaixo os itens do quadrante azul serão as melhores opções (Baixo custo e Alto benefício).

# data[].attributes.body
Variação da matriz GUT, esta é uma técnica de priorização que leva em consideração a Relevância, Urgência e a Tendência de uma história de usuário. Técnica fácil de aplicar, mas que requer consenso dos stakeholders na valoração dos critérios utilizados para a priorização. Acesso o link e veja os detalhes.

# data[].attributes.attachment_link.readable_text
Existem algumas dores que todos os Product Owners e times que trabalham com projetos vivenciam. Os prazos impossíveis, os riscos imprevisíveis, e o absoluto desespero na hora de priorizar o que deve ser feito primeiro são bons exemplos.

De todos os desafios, a priorização é o que mais me encanta. Ela está no coração do agilismo, e é imprescindível para a saúde mental do Product Owner, sabendo que ele cumpriu seu papel para com os membros do time e stakeholders.

O cenário mais comum é que seus stakeholders estejam sendo afetados por todos os tipos de vieses cognitivos, e reforcem constantemente para você que tudo é importante. O problema é que quando tudo é importante, nada realmente é.

Durante meus 10 anos trabalhando com projetos de software, venho testando várias formas de ajudar os stakeholders e o time a priorizar o trabalho. Algumas tentativas falharam, outras funcionaram, mas uma se destacou, então vou compartilhar minha experiência sobre ela com vocês.

GUT e o início de tudo

Em 2008, fui apresentada a uma metodologia de priorização chamada GUT (Gravidade x Urgência x Tendência), como uma maneira de ordenar bugs para tratamento. Ela funcionava lindamente com defeitos, mas ao tentar aplicar a mesma em um backlog de produto, falhei miseravelmente. Depois de gastar algum tempo analisando o motivo, me veio a luz: a Gravidade não fazia sentido quando estávamos discutindo novas funcionalidades.

Decidi que precisava adaptar e testar novamente, então comecei a brincar com conceitos que pudessem substituir a Gravidade no momento de discussão sobre um novo produto. E a Relevância apareceu.

O consenso faz a diferença

Observando, também me dei conta que esta técnica precisava ser baseada em consenso. O maior problema que enfrentamos com priorização é que a prioridade varia entre stakeholders, eles têm dificuldade de entender que o que eles vêem como imprescindível é na verdade uma hipótese, e o que é urgente para um deles pode sequer ser algo desejável para o outro. Este tipo de abismo é o que faz times virarem noites, e torna uma estratégia de MVP impossível de alcançar.

Comecei a fazer experiências com um sistema de votos com a mão, que consistia em uma escala de 1-5 para cada um dos três critérios. Eu precisava evitar a ancoragem e incentivar o debate, então me baseei na técnica de planning poker para fazer minhas cobaias - digo, testadores - só revelarem seus votos simultaneamente, e então discutir as maiores divergências.

O resultado foi impressionante. Começamos a pensar coletivamente em soluções alternativas, que permitissem minimizar o esforço e aumentar o valor, e realmente priorizar apenas os itens que apostávamos que iriam gerar sucesso para o produto.

Testando na vida real

Comecei a testar com stakeholders e times em situações reais. O resultado foi ainda melhor, e quando eu chegava no 5o item de backlog, eu tinha stakeholders usando termos do RUT para contra-argumentar com outros stakeholders, e garantir a saúde do produto do ponto de vista de estratégia.

Como funciona

Para cada item do backlog do produto, você deve ler sua definição (a história e critérios de aceite) para todos os participantes. Pergunte a eles se há dúvidas sobre a história apresentada, e esclareça o que for necessário. Mostre a matriz abaixo e explique os 5 graus da Relevância. Peça a cada um deles para escolher um dos números e, quando você disser já, todos mostrarem o número escolhido com a mão, ao mesmo tempo.

# data[].attributes.attachment_link.title
Priorizando sem trauma - como ordenar seu backlog de produto

# data[].attributes.attachment_link.description
Existem algumas dores que todos os Product Owners e times que trabalham com projetos vivenciam. Os prazos impossíveis, os riscos imprevisíveis, e o absoluto desespero na hora de priorizar o que deve ser feito primeiro são bons exemplos. De todos os desafios, a priorização é o que mais me encanta.

# data[].attributes.body
Essa ferramenta tem como objetivo ajudar na priorização de projetos de uma organização. Apesar de não estar relacionada a priorização de itens de um backlog, achei interessante compartilhar😉. A priorização é realizada com base nos critérios Benefícios para a Organização, Abrangência dos Resultados, Satisfação do Cliente interno, Investimento Requerido, Cliente Externo Satisfeito e Operacionalidade Simples.

# data[].attributes.body
Outra ferramenta de fácil aplicação que pode nos auxiliar na priorização de problemas, histórias ou projetos, identificando quais itens de fato são importantes e que precisam ser priorizados. Os itens são colocados nos quadrantes de acordo com a Urgência e a Importância. Maiores detalhes no link abaixo.

# data[].attributes.attachment_link.readable_text
Escrito por Fernando Collela

(Por Fernando Colella)
Dwight D. Eisenhower foi um general de cinco estrelas do Exército Americano que se tornou o 34º presidente dos EUA em 1953, permanecendo no exercício de seu mandato até o ano de 1961. A ele é atribuída a seguinte frase: "O que é importante é raramente urgente, e o que é urgente é raramente importante".

A organização de tarefas, classificando-as como urgentes ou importantes, é uma das mais conhecidas técnicas de administração do tempo, a matriz urgente-importante. O conceito, conhecido como "Princípio Eisenhower", foi reproduzido pelo Dr. Stephen R. Covey em seu famoso livro "Os 7 Hábitos das Pessoas Altamente Eficazes".

Como o título sugere, Covey nos apresenta sete hábitos compartilhados por pessoas bem sucedidas em sua pesquisa, que contempla 200 anos de literatura sobre o sucesso. É no terceiro hábito ( "primeiro o mais importante") que o autor trata da priorização daquelas atividades mais alinhadas aos nossos valores e propósitos. Apenas podemos gerenciar nosso tempo e nos tornar mais assertivos em nossas ações, se soubermos priorizar o que é importante, em detrimento das urgências.

A partir da prática do segundo hábito ( "começar com o objetivo em mente"), podemos reconhecer com mais facilidade as tarefas importantes, aquelas que devem ser resultados de nossas escolhas conscientes e ações planejadas. Para controlar as urgências, ou seja, aquelas atividades que exigem nossa atenção imediata, devemos nos dedicar ao primeiro hábito ( "ser proativo"). É estando proativamente no comando da própria vida que podemos planejar nossas tarefas, fazendo escolhas mais alinhadas com nossos valores e evitando o estresse e a frustração típicos de quem vive apagando incêndios.

Para melhor conhecer a natureza de nossas ações segundo o "Princípio Eisenhower" e compreender onde de fato investimos o nosso tempo, Covey propõe uma ferramenta simples e eficaz: a Matriz Urgente-Importante. Trata-se de uma grade composta por quatro áreas, que nos permite dividir as tarefas de acordo com a importância e a urgência de cada uma. Basicamente, o que temos de fazer é distribuir todas as nossas atividades ao longo dos quatro quadrantes da matriz, de acordo com os critérios de urgência e importância indicados na figura abaixo:

Para o Quadrante I irão todas as tarefas que são importantes, mas que por imprevistos, falta de prevenção ou má gestão do tempo, tornaram-se também urgentes. Incluem atividades como projetos atrasados, reuniões de última hora, crises ou mesmo emergências de saúde. Quando temos a maior parte de nossas ações localizadas nessa área, tendemos a nos sentir estressados e ansiosos, muitas vezes por vivermos apenas administrando problemas e nos movendo de uma crise para outra.

O Quadrante II será composto pelas tarefas importantes, mas com tempo hábil para serem executadas. Por não terem o aspecto da urgência, é comum que acabem recebendo pouca atenção da maioria das pessoas, mas é o mais valoroso quadrante da matriz. Aqui permanecerão as atividades relacionadas ao planejamento estratégico, desenvolvimento pessoal e profissional, aumento de competências, avaliação de riscos, bem como quaisquer ações concernentes a uma boa qualidade de vida. O tempo gasto nesse quadrante é, em geral, de qualidade. A sensação de controle que as atividades planejadas nos proporcionam ajuda a lidar com a maioria dos problemas antes que eles surjam e a permanecer com foco no que realmente importa.

No Quadrante III serão incluídas tarefas urgentes, mas sem importância. Aqui residem as interrupções que, por vezes, nos levam a perder tanto tempo, como telefonemas que precisamos atender, reuniões sem importância, relatórios desnecessários, pessoas que temos de dar atenção imediata, ou mesmo checagem excessiva de e-mails. Quem tem grande parte de suas atividades nessa área tende a se sentir improdutivo e impotente diante de tantas demandas externas e da falta de controle sobre suas ações.

Por fim, para o Quadrante IV irão as atividades que não possuem urgência e nem importância. São as distrações, representadas por tarefas como trocas de mensagens irrelevantes, mau uso das redes sociais, televisão em excesso, jogos eletrônicos em momentos inadequados ou mesmo pensamentos de autocrítica. Geralmente é um tempo mal gasto, e em muitas ocasiões as ações desse quadrante se devem à procrastinação ou fuga. Quando dedicamos muito tempo a essa área da matriz, tendemos aos atrasos em nossos prazos e comumente utilizamos a falta de tempo como justificativa para não realizar as tarefas mais importantes. Cansaço, falta de energia e até depressão podem ser sintomas de quem tem a maior parte de suas atividades localizada nesse quadrante.

O mais importante aqui é fazer um inventário coerente de todas as atividades cotidianas e distribuí-las corretamente na matriz, para que possamos clarificar de que forma utilizamos o tempo e direcionamos nosso foco. Após concluída essa tarefa, devemos simplesmente nos questionar: em qual quadrante concentramos um maior número de atividades e dedicamos mais tempo? Pessoas eficazes e proativas gastam a maior parte do seu tempo no segundo quadrante, mas se esse não for o nosso caso, cabe uma reflexão sincera.

Se o nosso tempo estiver sendo utilizado predominantemente no Quadrante I, até que ponto nos deixamos ser escravizados pelas crises e como gerenciamos o estresse? Caso nossa vida esteja sendo monopolizada pelas interrupções do Quadrante III, não seria hora de aprender a dizer "não" para os outros? Mas se a maior parte das ações estiver concentrada nas distrações do Quadrante IV, que tal encontrar formas de dizer "não" para si mesmo? O último passo é fazer os ajustes necessários para priorizar as tarefas mais relevantes e se comprometer com as mudanças essenciais à meta.

A Matriz Urgente-Importante é uma ferramenta poderosa de gestão de tempo e priorização de atividades, que pode ser utilizada por coaches, para ajudar clientes a serem mais focados e organizados, ou por líderes, para obter melhor desempenho de seu time. É um modelo simples o suficiente para ser utilizado também por não-profissionais interessados em melhorar sua vida produtiva ou mesmo para grupos fechados, em oficinas ou dinâmicas sobre produtividade pessoal.

# data[].attributes.attachment_link.title
A Matriz Urgente-Importante - Blog SBCoaching

# data[].attributes.attachment_link.description
Escrito por Fernando Collela (Por Fernando Colella) Dwight D. Eisenhower foi um general de cinco estrelas do Exército Americano que se tornou o 34º presidente dos EUA em 1953, permanecendo no exercício de seu mandato até o ano de 1961.

# data[].attributes.body
Mais uma ferramenta no modelo de quadrantes, elas são de fácil aplicação e utilização para a priorização de problemas, histórias ou projetos. Neste caso os itens são colocados nos quadrantes de acordo com o Esforço e o Impacto.

# data[].attributes.attachment_link.readable_text
Escrito por Fernando Collela

(Por Fernando Colella)
Um dos maiores desafios na gestão do tempo é o das escolhas pelas tarefas prioritárias. Quantas vezes você já se sentiu perdido diante de um mar de informações que chegam o tempo todo e uma quantidade sem fim de tarefas a serem executadas, não sabendo exatamente o que ou como priorizar? E nem sempre o que gostaríamos de fazer é realmente aquilo que temos de fazer. A procrastinação é uma das consequências desse conflito, estando quase sempre associada à falta de capacidade de planejamento e priorização. E se você é coach, sabe que esse é um dos problemas típicos que nossos clientes costumam trazer para as sessões, tanto no trabalho com indivíduos, como nas empresas.

Como lidar com essa questão em nossa vida pessoal ou profissional? Trata-se de um tema que uma infinidade de livros de autoajuda e artigos em revistas e blogs pretendem responder, e de fato há um sem número de técnicas e ferramentas com propostas para lidar com a dificuldade da priorização de tarefas. Em um passado recente, apresentei neste blog uma das abordagens mais conhecidas para trabalhar com essa questão, a Matriz Urgente x Importante, divulgada por Stephen Covey, que propõe a priorização das ações importantes em detrimento das urgentes.
Menos conhecida, mas não menos útil, hoje abordarei um outro modelo para gerenciamento de tempo: a Matriz Impacto x Esforço. Parecida com a ferramenta anteriormente apresentada, esta técnica também se baseia em uma grade composta por quatro áreas para a distribuição de tarefas entre elas. Neste caso, a ordenação deverá ocorrer de acordo com o esforço gasto em cada ação e o impacto que ela representa no projeto ou objetivo trabalhado. Em outras palavras, fazemos um levantamento das tarefas a serem executadas e as distribuímos pela matriz considerando a energia ou esforço despendido (horizontalmente) e o resultado ou impacto representado (verticalmente) para cada ação. A figura abaixo ilustra o modelo:

Esta ferramenta poderá ser usada sempre que você ou seu cliente de coaching tiver projetos importantes ou muitas tarefas a cumprir. Também poderá ser considerada para o planejamento de atividades da semana ou de um dia de trabalho. A grande vantagem dessa técnica é a possibilidade de identificar os ganhos rápidos maximizando a produtividade, e assim poder priorizar as ações que trazem maiores resultados com menor esforço. Que tal gastar alguns momentos para construir uma estratégia assertiva das suas atividades programadas? Basta seguir os passos adiante:

1. Liste todas as tarefas que precisam ser realizadas na semana ou para a execução de um projeto.
2. Em seguida, distribua-as ao longo dos quadrantes da Matriz Impacto x Esforço.
3. Marque as ações prioritárias, aquelas que precisam impreterivelmente serem feitas logo ou que possuem um prazo curto para serem cumpridas. Localize em quais quadrantes elas se encontram.
4. Verifique então onde você tem utilizado a maior parte de sua energia, estabelecendo a porcentagem de tempo gasto em cada quadrante.
5. A partir desta análise, elabore uma estratégia para gastar o seu tempo de forma diferente, considerando novas ações ou mudanças de atitude que priorizem o primeiro quadrante, ou seja, baixo esforço e alto impacto.
Para elaborar uma boa estratégia, considere as seguintes dicas:
As tarefas do Quadrante I são as mais produtivas, por impactarem um maior resultado com menor esforço. Execute-as tantas quanto puder e, na medida do possível, procure priorizá-las para obter resultados mais rápidos e permanecer motivado. Tente se forçar a executar ao menos uma dessas atividades diariamente, pois seus ganhos rápidos servirão de incentivo para manter uma gestão positiva do tempo. Pergunte-se ainda se não existem tarefas que você tem evitado executar por parecerem difíceis, mas que poderiam perfeitamente fazer parte deste quadrante. Estas poderão ser priorizadas.
As ações do Quadrante II são importantes por trazerem resultados relevantes, mas com a desvantagem da difícil execução. É possível que a maior parte de suas tarefas se localizem nesta área, portanto é importante que você crie uma disciplina específica para elas. Procure fazer um bom planejamento, clareando os resultados desejados e o esforço exato a ser empreendido, e procure bloquear tempo na sua agenda especialmente para essas ações. Se possível, divida grandes tarefas em partes menores, gerando ações de baixo esforço que possam ser transferidas para o Quadrante I. Vale ainda identificar as tarefas que precisam ser concluídas antes de começar as próximas, pois estas precisam ser tratadas como prioridade.
As tarefas do Quadrante III precisam ser tratadas com cuidado, pois apesar do pouco esforço, seus resultados são de baixo impacto. Pergunte-se, em primeiro lugar, se essas ações são realmente necessárias. Em caso afirmativo, procure fazê-las em lacunas de tempo curtas, não maiores que 30 minutos. Aproveite um intervalo curto de tempo entre atividades maiores ou compromissos relevantes, ou ainda, se possível, execute-as quando estiver ocioso em alguma sala de espera. Graças ao baixo esforço deste quadrante, suas ações também podem ser úteis para aqueles momentos em que você está cansado ou sem energia, mas deseja se manter produtivo.
O Quadrante IV é certamente o mais crítico, pois não há nada mais desestimulante do que se dedicar a tarefas que exigem muito esforço e rendem pouco resultado. Mais uma vez, é importante questionar-se a respeito da necessidade de execução dessas ações. É possível que encontre alguns tópicos deste quadrante que podem ser descartados, mas caso se tratem de atividades imprescindíveis, considere se não podem ser delegadas a outra pessoa, ou se não existem formas melhores ou mais criativas de executá-las. Caso você seja a única pessoa apta ou disponível a realizá-las, tenha em mente que essas são as tarefas que exigem maior nível de concentração e foco, já que é muito fácil se desviar das ações pouco motivadoras. Procure desafiar-se a cumpri-las e considere se conceder um prêmio ao terminá-las.
A Matriz Impacto x Esforço é mais uma poderosa ferramenta de gestão de tempo e priorização de atividades, útil para coaches, líderes ou simplesmente para elaboração de planejamento pessoal. Gostaria de experimentá-la? Que tal contar-nos um pouco mais sobre suas impressões, sucessos e aprendizados com a utilização desta técnica? Boa semana!

# data[].attributes.attachment_link.title
A Matriz Impacto x Esforço - Blog SBCoaching

# data[].attributes.attachment_link.description
Escrito por Fernando Collela (Por Fernando Colella) Um dos maiores desafios na gestão do tempo é o das escolhas pelas tarefas prioritárias. Quantas vezes você já se sentiu perdido diante de um mar de informações que chegam o tempo todo e uma quantidade sem fim de tarefas a serem executadas, não sabendo exatamente o que ou como priorizar?