Modelo de Kano

REQUISITOS – MODELO DE KANO
A maioria dos gerentes de projetos conhece a figurinha sobre gerenciamento de escopo abaixo. Escopo do Projeto
Ela é famosa por ser engraçada e pelo seu fundo de verdade. Em um post anterior, defendi o escopo como sendo o mais importante no gerenciamento de projetos, o que gerou bastante discussão.
Fato é que uma grande causa de fracasso nos projetos é a falta de compreensão e de clareza nos objetivos, levando a um escopo incompleto ou mesmo incorreto.
Quando estamos coletando requisitos, precisamos observar sob a perspectiva do cliente e dos usuários. Em geral, eles não são especialistas e, portanto, vão ter dificuldade em expressar suas necessidades. O gerente de projeto e sua equipe é responsável por coletar os requisitos dos stakeholders para a Statement of Needs, documento que registra aquilo que os stakeholders desejam atingir (ou ser capazes de fazer) com o resultado do projeto. “Arrancando” requisitos dos stakeholders
Os requisitos passarão por uma cascata rastreável desde os stakeholders´ requirements até os component requirements, passando por systems´ requirements e architecture´s requirements em diferentes níveis de abstração. Isso já vimos nos posts sobre engenharia de sistemas.
Hoje vamos falar do modelo de Kano. Se você não conhece o modelo de Kano, pode literalmente “entrar pelo cano” quanto estiver definindo requisitos.
Trata-se de um modelo relacionado ao desenvolvimento de produtos criado por Noriaki Kano. Ele estava preocupado com a satisfação dos clientes (ou consumidores, no caso do produto) e definiu cinco categorias de preferência:
1. Atrativos
Atributos que resultam em satisfação quando totalmente atingidos, mas sua ausência parcial não causa insatisfação.
2. Unidimensionais
Atributos que produzem satisfação quando presentes e que geram insatisfação quando ausentes
3. Necessários
Atributos entendidos como inerentes ao produto, sua falta produz grande insatisfação e sua presença não produz