Skip to content

Modelo Kano e análise de negócios: qual a relação?

O modelo Kano (ou Kanel model) é uma teoria voltada para o desenvolvimento de produtos e para a satisfação de clientes que pode, facilmente, ser adaptada para a análise de negócios, proporcionando grandes benefícios para a área.

No método, a gestão de qualidade é o foco, de forma que a busca por melhorias de processos, de produtos e de serviços é constante. Fundado por Noriaki Kano, que dá nome à metodologia, nos anos 80, a base do conceito está no fato de que seu criador percebeu que as informações dadas pelos clientes poderiam ser categorizadas.

Análise de negócios, por sua vez, é a junção de diversas técnicas e ferramentas voltadas para o aproveitamento de oportunidades e para o mapeamento de problemas (que são evitados), a fim de que empresas sejam impulsionadas e cresçam com mais performance.

Para que isso aconteça, metas alinhadas a objetivos são estipuladas. Assim, se tornam ações, que culminam no crescimento da organização e na validação de soluções que, anteriormente, poderiam ser hipóteses.

Pessoas no escritório, conversando, sentadas em sofás e nos corredores.
É fundamental que haja alinhamentos para que o modelo Kano e a análise de negócios sigam próximos.

A expressão ‘cereja do bolo’, por sua vez, se refere ao diferente, que cativa o olhar. É aquilo que tira da zona de conforto e que surpreende positivamente a partir de algo que não se esperava. Esse termo, evidentemente, pode ser aplicado na entrega de softwares.

Se aprofundando nos assuntos

Tendo em mente os conceitos básicos acima, vamos para a definição de análise de negócios feita pelo Guia BABOK (IIBA):

É a disciplina constituída de práticas e ferramentas que tem como objetivo permitir a mudança em um contexto organizacional, através da definição de necessidades e recomendação de soluções que entregam valor às partes interessadas.

Conforme esse mesmo guia, a análise de negócios se divide em seis grandes áreas de conhecimento: planejamento e monitoramento da análise de negócios, elicitação, gerenciamento e comunicação de requisitos, análise corporativa, análise de requisitos e avaliação e validação.

Post-its para estruturação do modelo Kano na parede.
A análise de negócios é pautada em processos para definir o que será feito e como isso será feito.

Antes de falarmos sobre modelo Kano e sobre cerejas, vamos nos aprofundar no termo “elicitação” A base para o conceito é formada pelo conhecimento sobre o contexto do sistema a ser desenvolvido, incluindo as fontes de requisitos a serem analisadas e investigadas. Existem três fontes principais de requisitos: stakeholders (partes interessadas), documentos e sistemas em operação.

O modelo Kano, como já citado, foi desenvolvido na década de 1980 pelo professor Noriaki Kano, focado no desenvolvimento de produtos e na satisfação do cliente. O mesmo elicitou três fatores que determinam essa satisfação: fatores básicos de satisfação (dissatisfiers) , fatores esperados de satisfação (satisfiers) e fatores inesperados de satisfação(delighters).

Os fatores do modelo Kano

Os fatores básicos de satisfação (dissatisfiers), que também podem ser requisitos ou histórias de usuário, devem sempre serem atendidos. Caso não seja, as partes interessadas ficarão decepcionadas. Por se tornarem óbvios demais, quando são concluídas apenas evitam descontentamento. Esses itens podem ser encontrados em técnicas de observação e de documentos.

Os fatores esperados de satisfação (satisfiers), diferentemente dos básicos, são amplamente exigidos e declarados. Ao atendê-los, as partes interessadas ficam felizes e satisfeitas. Por outro lado, caso estejam faltando, podem impedir a entrega do produto. Esses itens podem ser elicitados com técnicas de pesquisa.

Pessoa usando aparelho celular.
Os fatores esperados são aqueles já conhecidos pelos usuários ao utilizar softwares e aplicativos.

Os fatores inesperados de satisfação (delighters), na maioria das vezes, são reconhecidos somente quando a parte interessada pode testar ou quando o analista de negócios as propõe. Técnicas de criatividade são as mais indicadas para elicitar esse tipo de fatores, a famosa cereja do bolo.

Entretanto, muito cuidado ao propor delighters, pois, dependendo do tempo que demorar para entregar e da viabilidade, seus stakeholders passarão a vê-lo como um fator esperado (ou ainda como fatores básicos), conforme ele vai se acostumando com as características do sistema.

Para exemplificarmos, vamos avaliar os serviços entregues em aplicativos de transporte. Baseado no modelo existente de táxi, o fator básico entregue está em ter acesso a carros disponíveis.

Já o fator esperado de satisfação pode ser a possibilidade de solicitar sem necessidade de ligação telefônica. Para fatores inesperados, por fim, podemos destacar a possibilidade de acompanhar, em tempo real, o local do carro solicitado, a cor do veículo e o preço já calculado em qualquer corrida.

Note que, ao entregar os fatores inesperados (delighters), abre-se precedente para virarem fatores básicos conforme o passar do tempo, pois, quando estão em nosso cotidiano, fica fácil nos acostumarmos com essas facilidades, hoje consideradas “essenciais”.

Ao fazer a análise dos itens de backlog elicitados, tente encaixá-los em uma classificação com a ajuda de seu cliente. Assim, você poderá constatar se seu produto está recebendo apenas itens essenciais ou se consegue entregar algumas cerejas.

Lembre-se que a satisfação do cliente, dependerá de uma mistura desses itens. Entregar muitos recursos extraordinários e esquecer dos fatores básicos poderá ser mais custoso e decepcionante para seu cliente.

O modelo Kano é uma excelente forma de pensar em inovações dentro das aplicações, que deixam o usuário surpreso e garantem, dessa forma, a cereja do bolo nas entregas.

Gostou deste conteúdo e quer aprender mais sobre tecnologia? Então assine a newsletter do Grupo DB1 e receba artigos e dicas exclusivas no seu e-mail!

Clique para assinar a newsletter do Grupo DB1.

Sobre a autora

Kássia é uma analista de negócios apaixonada por resolver problemas que não são seus. Formada em Sistemas de Informação pela UNIBAVE e pós-graduada em Engenharia de Software pela ESUCRI, com certificação em requisitos CPRE-FL e SCRUM, faz parte da equipe DB1 Global Software. É entusiasta em divulgar novas e antigas maneiras de fazer análise de negócios.

Fale com a Kássia no LinkedIn.

Compartilhe:

This Post Has 0 Comments

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Back To Top