Kano

La méthode Kano

La méthode Kano, nous vient du Japon, et plus précisément du japonais Noriaki Kano en 1984 qui affirme que la satisfaction et l’insatisfaction ne sont pas deux sentiments diamétralement opposés.

Si votre client est en attente d’un gâteau aux pommes et que vous le lui apportez dans un délai raisonnable, accompagné en plus d’un café, il sera satisfait. Il aurait été satisfait sans le café également.

En revanche, si vous lui apportez une tarte au citron, vous conviendrez que votre client ne sera pas satisfait, même avec un café.

On distingue donc plusieurs attentes du client que la méthode Kano classe comme suit :

• Les attentes "de base" (Basic Needs, Must have). En l’occurrence, le gâteau aux pommes. Le lui apporter dans un délai raisonnable rend le client satisfait, sans surprise. Les fonctionnalités sont obligatoires, ne pas les avoir est une cause réelle d’insatisfaction du client.

• Les attentes dont les degrés de satisfaction sont proportionnelles à la fonctionnalité demandée (Performance Needs ,Linear). Plus vite vos servirez votre gâteau aux pommes, plus votre client sera satisfait.

• Les heureuses surprises (Exciters, Delighters) , qui correspondent à des besoins non exprimés, mais utiles malgré tout. Vous apportez également un café.

Les risques

Vous apportez un café, mais votre client ne boit que du thé.
La fonctionnalité supplémentaire ne servira jamais, le temps passé, le coût, le risque pris (de renverser la tasse par exemple) n’auront servi à rien. Pire encore, le client aurait été encore plus satisfait si vous lui aviez apporter le gâteau plus vite, eu lieu de perdre du temps à faire ce café. Peut être devrait on alors questionner au préalable le client ?

Vous apportez un café, mais il est froid.
La fonctionnalité plait au départ, mais a été développé avec moins de rigueur et de sérieux que celles explicitement demandées. Du coup, elle se retrouve erronée, incomplète. Vous avez pris le risque de décevoir le client par rapport à une fonctionnalité non demandée. Ce risque en vaut il la chandelle ?

Vous apportez un café, mais votre gâteau aux pommes est trop sucré.
Le client est d’abord heureux de voir le gâteau et le café arriver, mais se dit ensuite qu’il aurait été préférable de passer plus de temps à faire correctement le gâteaux, que de faire du café.

Vous apportez un café, mais votre client avait déjà anticipé de vouloir un cappuccino.
La fonctionnalité apportée entrave les futurs plans de votre client.

Vous apportez un café, que vous renversez malencontreusement sur le gâteau.
Votre fonctionnalité en sus à des effets de bord sur les attentes de base. Le risque pris est trop important, vous devez refaire votre gâteau…. Votre client est totalement insatisfait.


Il s’agit bien de se placer du point de vue du client, par rapport à une fonctionnalité proposée, mais initialement non exprimée par le client. Et à chaque fois, se poser la double question :

* que se passe t’il si cette fonctionnalité manque
* que se passe t’il si cette fonctionnalité existe


De toutes les façons, ajouter un «Delighter», c’est prendre le risque de contrarier le client. Je pense que le mieux, est de tout simplement jouer la carte de la communication, en lui proposant la fonctionnalité, avant de l’implanter et de la lui livrer dans la version suivante.

En effet, seul le client est à même de déterminer si la fonctionnalité proposée à une valeur ajoutée.

Le principal piège est de sous-évaluer le développement de cette nouvelle fonctionnalité, son impact sur le reste du projet, sa maintenance... il faut bien voir que chaque modification d’un code existant est la porte grande ouverte à de nombreux bugs et autres régressions. L’ingénieur développeur a déjà du mal a maîtriser la qualité de son logiciel, est il utile d’augmenter encore sa complexité ?

De plus, le seul à être en mesure de juger de la valeur ajoutée d’une fonctionnalité est le client utilisateur. En tant que développeur, vous connaissez peu de chose sur son métier, son organisation, sa vision à court/moyen/long terme. Et qui vous dit, même si la solution est bonne, qu’il s’agit de la meilleure ?