Modelo Kano: como classificar requisitos pela satisfação
Em quase todo projeto a lista de requisitos é maior do que o prazo e o orçamento comportam, e a pergunta "o que o cliente mais valoriza?" costuma ser respondida no grito. O modelo Kano troca a discussão por um critério: classificar cada requisito pela forma como a presença ou a ausência dele afeta a satisfação de quem vai usar a entrega.
A ideia central é que requisitos não pesam igual. Alguns só são notados quando faltam; outros aumentam a satisfação na proporção em que melhoram; e alguns surpreendem porque ninguém pediu. Tratar os três tipos do mesmo jeito leva a dois erros caros: gastar com sofisticação enquanto o básico falha, ou entregar o básico perfeito e nada que diferencie.
O modelo nasceu no estudo da qualidade de produtos, mas se aplica a qualquer projeto com usuário identificável: implantação de sistema, aplicativo, serviço público digital, evento. Abaixo estão as categorias, o questionário, a forma de tabular e como levar o resultado para o escopo.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
De onde vem o modelo Kano
O modelo foi apresentado pelo professor japonês Noriaki Kano e colegas no artigo "Attractive Quality and Must-Be Quality", publicado em 1984 no periódico da Sociedade Japonesa de Controle da Qualidade (JSQC). A contribuição foi separar duas dimensões que costumavam ser tratadas como uma só: o quanto um atributo está presente ou bem executado e o quanto o cliente fica satisfeito com isso. O modelo desmonta a suposição de que mais de qualquer atributo significa, sempre, mais satisfação.
Entre as ferramentas da qualidade em projetos, o Kano é uma das poucas voltadas para definir o que entregar, e não para analisar falhas. No gerenciamento da qualidade do projeto, ele entra na fase de definição: ajuda a decidir quais requisitos são condição de aceite e quais são diferenciais negociáveis. É por isso que ele conversa tanto com a coleta de requisitos quanto com os critérios de aceite.
As categorias de atributos do modelo Kano
| Categoria | Se estiver presente | Se faltar | Exemplo num sistema de agendamento de consultas |
|---|---|---|---|
| Obrigatório (must-be) | Ninguém elogia | Gera insatisfação forte | Confirmar o horário marcado sem erro |
| Unidimensional ou de desempenho (one-dimensional) | Satisfaz mais quanto melhor for | Insatisfaz na mesma proporção | Rapidez para encontrar um horário livre |
| Atrativo (attractive) | Surpreende e satisfaz | Ninguém sente falta | Sugerir o horário vago mais próximo de casa |
| Indiferente (indifferent) | Não muda a satisfação | Não muda a satisfação | Tema de cores personalizável |
| Reverso (reverse) | Gera insatisfação | Satisfaz | Lembretes por mensagem a cada hora |
Duas observações evitam erros de leitura:
- A categoria depende do público. O lembrete frequente que irrita um paciente pode ser atrativo para quem toma medicação contínua. Por isso a análise é feita por segmento, e não para "o cliente" em geral.
- As categorias migram com o tempo. O próprio Kano descreveu esse ciclo: o que surpreende hoje vira expectativa amanhã. Login com a biometria do celular já foi atrativo; em muitos aplicativos passou a ser esperado. Uma classificação de três anos atrás precisa ser refeita.
O gráfico do modelo Kano
O gráfico clássico tem no eixo horizontal o grau de atendimento do atributo (de ausente a plenamente atendido) e no vertical a satisfação (de insatisfeito a satisfeito). O obrigatório é uma curva que sobe da insatisfação até a neutralidade e para ali: atender muito bem não gera elogio. O unidimensional é uma reta diagonal. O atrativo é uma curva que parte da neutralidade e sobe rápido. O desenho ajuda a explicar ao patrocinador por que caprichar no obrigatório tem retorno limitado depois de certo ponto.
O questionário Kano: perguntas funcional e disfuncional
A classificação não vem da opinião da equipe, e sim de um questionário com duas perguntas para cada requisito:
- Funcional: "Se o sistema sugerir o horário vago mais próximo de sua casa, como você se sente?"
- Disfuncional: "Se o sistema não sugerir o horário mais próximo, como você se sente?"
As respostas são as mesmas cinco para as duas perguntas:
- Gosto disso.
- Já espero que seja assim.
- Tanto faz.
- Posso conviver com isso.
- Não gosto disso.
Cuidados na montagem:
- Descreva o requisito pelo efeito para o usuário, não pela solução técnica. "Sugerir o horário mais próximo" é compreensível; "geolocalização com API de mapas" não é.
- Mantenha o questionário curto. Com dois itens por requisito, uma lista longa cansa e piora as respostas do fim. Selecione os requisitos em que há dúvida real; os óbvios não precisam ir para pesquisa.
- Aplique ao público que vai julgar a entrega: usuários finais, atendentes, cidadãos. Pesquisar só os gestores do cliente mede a percepção dos gestores.
Como tabular as respostas: a tabela de avaliação
Cada par de respostas (funcional e disfuncional) é convertido numa categoria pela tabela de avaliação padrão. As linhas são a resposta funcional, e as colunas, a disfuncional. A = atrativo, O = unidimensional, M = obrigatório, I = indiferente, R = reverso, Q = questionável (resposta contraditória).
| Funcional \ Disfuncional | Gosto | Espero | Tanto faz | Convivo | Não gosto |
|---|---|---|---|---|---|
| Gosto | Q | A | A | A | O |
| Espero | R | I | I | I | M |
| Tanto faz | R | I | I | I | M |
| Convivo | R | I | I | I | M |
| Não gosto | R | R | R | R | Q |
Para cada requisito, conte quantos respondentes caíram em cada categoria. A forma mais simples de classificar é pela categoria mais frequente. Quando duas categorias ficam próximas, isso é informação: geralmente indica públicos diferentes misturados na amostra, e vale separar a análise por perfil.
Coeficientes de satisfação e insatisfação
Para comparar requisitos entre si, muitos praticantes usam dois coeficientes calculados com as contagens:
- Satisfação (better): (A + O) ÷ (A + O + M + I). Mostra quanto a presença do requisito aumenta a satisfação. Vai de 0 a 1.
- Insatisfação (worse): (O + M) ÷ (A + O + M + I), apresentado com sinal negativo. Mostra quanto a ausência dele derruba a satisfação. Vai de 0 a menos 1.
Exemplo ilustrativo: num grupo de 40 respondentes, o requisito "confirmar o horário sem erro" teve 2 A, 8 O, 28 M e 2 I. Satisfação = 10 ÷ 40 = 0,25. Insatisfação = 36 ÷ 40 = 0,90 (com sinal negativo, menos 0,90). Leitura: entregar bem quase não gera elogio, mas falhar derruba a satisfação de quase todos. É requisito de aceite, não de diferencial.
Num gráfico com satisfação no eixo vertical e o valor absoluto da insatisfação no horizontal, os requisitos se espalham em quatro quadrantes que reproduzem as categorias. É uma forma visual de levar o resultado para a reunião de escopo.
Como usar o resultado no escopo e na qualidade do projeto
A classificação só tem valor se mudar decisões. Uma regra de uso que funciona na maioria dos projetos:
- Obrigatórios viram critério de aceite. Entram no escopo sem discussão e ganham critérios de aceite testáveis. Se o orçamento não comporta todos, o problema é de viabilidade do projeto, não de priorização.
- Unidimensionais recebem meta de desempenho. Defina o nível que o projeto vai entregar ("encontrar horário em até três toques") e trate o restante como melhoria futura. São os itens em que o investimento tem retorno proporcional.
- Atrativos entram de forma seletiva. Escolha poucos, de custo baixo e alto coeficiente de satisfação. Um bom atrativo pode justificar a adoção de um sistema interno que a equipe resistia a usar.
- Indiferentes saem do escopo. São o lugar mais barato para cortar. Registre a decisão para não voltar à mesa.
- Reversos viram restrição. Escreva o que o projeto não deve fazer, ou ofereça como opção desligável.
O resultado também orienta o plano da qualidade. Testes e inspeções concentram esforço nos obrigatórios, porque é ali que a falha custa mais. O artigo de gerenciamento da qualidade do projeto mostra como esse esforço vira atividades de garantia e de controle.
Quando a decisão é entre projetos, e não entre requisitos de um mesmo projeto, a lógica é outra: critérios de negócio com peso. Para isso, a matriz de priorização de projetos da Projeto Diário pontua as iniciativas e mostra o ranking com a linha de corte pela capacidade.
Modelo Kano, MoSCoW e matriz GUT: o que cada um responde
| Técnica | Pergunta que responde | Quem decide |
|---|---|---|
| Modelo Kano | Como o usuário reage à presença ou ausência do requisito? | Os usuários, pelo questionário |
| MoSCoW | O que entra nesta entrega e o que fica para depois? | Equipe e cliente, em negociação |
| Matriz GUT | Qual problema atacar primeiro? | A equipe, com notas de 1 a 5 |
As três se completam. O Kano dá a evidência; o MoSCoW registra a decisão de escopo. Já a matriz GUT pertence a outro momento: serve para priorizar problemas e falhas, não requisitos novos. Para o backlog ágil, há ainda outras técnicas de priorização, como a ordenação por valor e esforço.
Limitações do modelo Kano
- Mede reação declarada, não comportamento. O que o usuário diz que vai sentir pode diferir do uso real. Combine com testes de protótipo quando a decisão for cara.
- Exige amostra e tempo. Para poucos usuários, como um sistema interno de dez pessoas, uma entrevista estruturada com as mesmas perguntas costuma bastar.
- Não considera custo. Um atrativo muito valorizado pode ser inviável. A decisão final cruza a classificação com esforço e prazo.
- Envelhece. Refaça a pesquisa a cada nova versão relevante do produto ou serviço.
Para aplicar no seu projeto, escolha os oito a doze requisitos em que a equipe mais discorda, monte o par de perguntas para cada um e aplique a um grupo representativo de usuários antes da reunião de escopo. Se você trabalha com produtos digitais e quer aprofundar descoberta, métricas e priorização, o curso de gestão de produto da Projeto Diário reúne videoaulas sobre descoberta, métricas, ciclo de vida e priorização.
