Eliminer les sources de gaspillage : les 7 gaspillages Lean des projets informatiques

Posté par jc-QualityStreet le 27 août 2008

C’est le principe N° 1 du Lean Software Development. C’est à la fois une façon de pensée et un concept trés opérationnel qui se traduit par l’examen attentif de 7 sources de gaspillage potentielles (”Muda”) qu’on retrouve dans la conception d’applications informatiques:

WAIT! There is more to read… read on »

Le modèle de KANO: si précieux pour …

Posté par jc-QualityStreet le 13 décembre 2007

Comprendre les besoins de vos utilisateurs
Cerner les usages
Prioriser vos développements
Piloter votre stratégie (par exemple au travers de votre backlog Scrum)

Ou tout simplement CONNAITRE votre produit.

Pourtant le modèle de Kano a presque 25 ans…
mais vous pouvez toujours aussi facilement l’appliquer, à vos propres réalisations, comme aux nouvelles applications en ligne de Google ou à tout autre service ou produit IT.

Les clés de son succès : sa simplicité, et surtout le recours aux UTILISATEURS qui font de ce modèle d’aide à la décision un pur outil de Conception Centrée Utilisateurs, utilisable notamment par l’ergonome ou les chefs de produit.

En bref, le modèle de KANO se propose de mettre en relation satisfaction des exigences (réponse aux besoins) et satisfaction Client, en distinguant notamment 3 types d’exigences, véritables piliers stratégiques, dont le degré de mise en oeuvre influencera différemment le degré de satisfaction du Client.

Exigences obligatoires (”Basic needs”, “Must Have”)

Ces exigences basiques ne sont pas toujours exprimées; elles sont pourtant évidentes pour le Client et doivent être impérativement satisfaites. Ce n’est pas un levier de satisfaction , en revanche si vous les avez pas, “vous êtes mort !” Elles ne sont pas forcément prioritaires en terme de développement mais devront être là le jour J.
(ex: Freins d’une voiture; un lit dans une chambre d’hôtel …)

Exigences exprimées, linaires (”Performance needs”, “Linear”)

Le besoin est exprimé et la satisfaction du client est proportionnelle au niveau de performance (et de qualité) de ce qui est implémenté. C’est un fort levier de satisfaction Client et un axe prioritaire pour le Développement, à faire valider très vite par les Utilisateurs.
(ex: la taille d’une chambre d’hôtel…).

Exigences latentes, attractives (”Exciters”, Delighters”)

Ces exigences correspondent à un besoin pas forcément exprimé, parfois inconscient. C’est l’heureuse surprise qui peut faire la différence, source de satisfaction importante parfois à peu de frais ! En revanche, l’absence de cette fonctionnalité ne sera pas source d’insatisfaction, de frustration. En terme de développement, elles ne sont donc pas prioritaires (sauf stratégie produit spécifique).
(ex: la coupe de champagne à l’arrivée, le wifi dans l’avion …).
C’est aussi le levier de l’innovation par excellence.

Évidemment une fois établi, le modèle n’est pas figé et telle ou telle fonction aura tendance à descendre (vers le Must have) au bout de quelques temps. Regardez ce qui se passe dans l’univers mobile.

AU FAIT, COMMENT CA MARCHE ?

C’est très simple, sélectionnez un panel d’utilisateurs représentatif (20…30), passez leur un questionnaire, analysez les réponses et prenez les bonnes décisions.

Temps 1: Consultation des utilisateurs (par questionnaires principalement) sur chaque fonction par l’intermédiaire d’une paire de questions (fonctionnelle et dysfonctionnelle)

Temps 2: Analyse des réponses pour chaque fonction et pour chaque utilisateur interrogé : au final 6 catégories possibles (I= Indifférente; Q=Incertaine; R=Inversée, et les 3 principales)

Temps 3 : Distribution et résultat final de chaque fonction.

La fonction x est un “Must Have”
La fonction y est un besoin exprimé “Linear”
La fonction z est une exigence attractive “Exciter”
…

La synthèse vous apportera entre autres de précieux éléments pour définir l’ordre d’implémentation des exigences.
Alors Convaincus ?