1
resposta

[Projeto] Modelo Kano em prática - aplicada a um exemplo de aplicativo de ponto

Pessoal, acho que a tabela "em branco" que foi colocada na proposta de exercício levou a um problema de interpretação da proposta por alguns colegas.

Pelo que entendi, a tabela não vai ser preenchida com as funcionalidades. A tabela é fixa e vai servir, na verdade, para classificar a funcionalidade.

Para cada funcionalidade, devemos perguntar aos clientes/usuários como ele se sente: 1. Se houver a funcionalidade; 2. Se não houver a funcionalidade.

Vou usar como exemplo o aplicativo de ponto que foi usado por outros colegas. Simulando aqui as respostas dadas por um usuário:

  • Funcionalidade: Login do app
    • Se houver: Espero
    • Se não houver: Não ligo.
  • Funcionalidade: Configuração do app
    • Se houver: Gosto
    • Se não houver: Sobrevivo
  • Funcionalidade: Redefinir senha
    • Se houver: Espero
    • Se não houver: Sobrevivo
  • Funcionalidade Consulta de históricos
    • Se houver: Gosto
    • Se não houver: Sobrevivo
  • Funcionalidade: Registro do ponto
    • Se houver: Espero
    • Se não houver: Não gosto
  • Funcionalidade: Informações sobre o app
    • Se houver: Não ligo
    • Se não houver: Não ligo
  • Funcionalidade: Upload de foto
    • Se houver: Sobrevivo
    • Se não houver: Espero
  • Funcionalidade: Consulta de banco de horas
    • Se houver: Espero
    • Se não houver: Sobrevivo
  • Funcionalidade: Cadastro de nova conta
    • Se houver: Gosto
    • Se não houver: Não ligo

Considerando a tabela de avaliação:

Tabela de avaliação do modelo Kano

Ao "combinar" as respostas com a tabela de avaliação, teremos a classificação de cada uma das funcionalidades:

  • Funcionalidade: Login do app
    • Se houver: Espero
    • Se não houver: Não ligo.
    • Classificação: Indiferente
  • Funcionalidade: Configuração do app
    • Se houver: Gosto
    • Se não houver: Sobrevivo
    • Classificação: Exciter
  • Funcionalidade: Redefinir senha
    • Se houver: Espero
    • Se não houver: Sobrevivo
    • Classificação: Indiferente
  • Funcionalidade Consulta de históricos
    • Se houver: Gosto
    • Se não houver: Sobrevivo
    • Classificação: Exciter
  • Funcionalidade: Registro do ponto
    • Se houver: Espero
    • Se não houver: Não gosto
    • Classificação: Must
  • Funcionalidade: Informações sobre o app
    • Se houver: Não ligo
    • Se não houver: Não ligo
    • Classificação: Indiferente
  • Funcionalidade: Upload de foto
    • Se houver: Sobrevivo
    • Se não houver: Espero
    • Classificação: Indiferente
  • Funcionalidade: Consulta de banco de horas
    • Se houver: Espero
    • Se não houver: Sobrevivo
    • Classificação: Indiferente
  • Funcionalidade: Cadastro de nova conta
    • Se houver: Gosto
    • Se não houver: Não ligo
    • Classificação: Exciter

Com isso, se formos desenvolver esse sistema para esse usuário, fica claro que não pode ficar de fora a funcionalidade "Registro de ponto", que foi classificada como "must". Depois, seria mais interessante implementar as funcionalidades "exciters" do que as "indiferentes".


Bom, isso foi o que entendi. Espero estar no caminho certo.

1 resposta

Olá, Gustavo!

Você está no caminho certo! O Modelo Kano é uma excelente ferramenta para entender e priorizar as funcionalidades de um produto com base na satisfação do usuário. A tabela que você mencionou é usada para classificar cada funcionalidade de acordo com as respostas dos usuários sobre como eles se sentem se a funcionalidade existe ou não.

Bons estudos!