A maioria dos gerentes de projetos conhece a figurinha sobre gerenciamento de escopo abaixo.

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.

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:

• Atrativos
• Atributos que resultam em satisfação quando totalmente atingidos, mas sua ausência parcial não causa insatisfação
• Unidimensionais
• Atributos que produzem satisfação quando presentes e que geram insatisfação quando ausentes
• Necessários
• Atributos entendidos como inerentes ao produto, sua falta produz grande insatisfação e sua presença não produz aumento na satisfação
• Indiferentes
• Atributos que não afetam a satisfação / insatisfação dos consumidores
• Reversos
• Atributos cuja presença (ou excesso) produzem insatisfação

Mas por que nós, gerentes de projetos, devemos nos preocupar com o modelo de Kano da década de 80? Simples, os consumidores valorizam determinados atributos e acreditam que outros são inerentes ao produto. Analogamente, os stakeholders dos projetos também devem ter expectativas seguindo esse padrão.

Imagine que estamos organizando um show de Jazz. No dia e local do evento, poderíamos ter como requisitos:

• Banheiros – atributo necessário
• Você já foi a um evento / show que não havia banheiros? A insatisfação deve ter sido enorme. Porém, se você for a um evento que tenha banheiros, isso não aumenta sua satisfação
• Cobertura de TV – atributo indiferente
• Em princípio, para quem está presente, tanto faz se estiverem reproduzindo o show na TV ou não (isso deve fazer diferença para quem ficou em casa e queria assistir)
• Cadeiras confortáveis – atributo unidimensional
• Se forem confortáveis, aumenta minha satisfação. Se não forem, geram insatisfação
• Cocktail – atributo atrativo
• Se houver comida e bebida durante o show, produz (grande) satisfação. Sua ausência não gera insatisfação.
• Potência do som – atributo reverso
• Se o equipamento de som for o mesmo de um show de rock, provavelmente haverá insatisfação na platéia de jazz… as pessoas querem ouvir a música num volume adequado.

O modelo de Kano nos indica qual a medida ideal para os atributos sob a ótica do cliente, usuário ou consumidor. Isso permite definir melhor os requisitos e o escopo do produto (e do projeto) para melhor performance e eficiência.

 Na figura anterior, temos o eixo da percepção do cliente e o eixo da medida em que o atributo deve ser satisfeito.

Faça um exercício com um produto, enumere atributos nas categorias de Kano.

• Viagem de Avião (do ponto de vista do passageiro)
• Atrativos: maior espaço das poltronas
• Unidimensionais: serviço de bordo
• Necessários: cinto de segurança
• Indiferentes: economia de combustível
• Reversos: capacidade de passageiros

É um modelo bastante simples, ao mesmo tempo poderoso. Permite analisar diferentes pontos de vista dos stakeholders nos projetos, identificando suas expectativas e realizando tradeoffs dos interesses conflitantes para melhor performance geral. Isto é, para maior satisfação dos stakeholders. Isso é sucesso!

Sucesso de um projeto é medido pela satisfação dos stakeholders. (Hartman, 2000)

Até a próxima!