18 novembre 2019 admin

Iron Triangle

L’« Iron Triangle » est un concept développé par Dr. Martin Barnes dans le début des années 1970, s’identifiant par un triangle dont chaque sommet représente les trois composantes cruciales d’un projet et leur interrelations, que sont (ces trois points peuvent être différents selon les sources, parfois :

  • Les ressources : les coûts à immobiliser pour ce faire
  • Le temps : la priorisation et le temps imparti pour le projet
  • Le périmètre défini du projet : les fonctionnalités prévues

Pourquoi « Iron Triangle »?

Parce que l’on ne peut changer une des contraintes sans impacter les deux autres composantes

Dans l’Iron Triangle traditionnel, seulement les fonctionnalités définies au préalable vont rester fixes. Les ressources et le temps vont être estimés au mieux, mais seront les variables à considérer pour mener à bien un projet avec tout ce qui a été demandé. En d’autres termes, c’est une approche « Cycle en V » ou encore « Waterfall » du product development.

Et dans le monde agile ?

Contrairement aux projets cycle en V, dans un projet AGILE les composantes de temps et de ressources sont fixées à l’avance. C’est dans ce cas où les fonctionnalités ne seront pas forcément définies à l’avance, bien au contraire. Un socle de base est souvent convenu pour test de fonctionnalités (ce que l’on appelle le MVP pour Minimum Viable Product).

Cette approche permet de répondre, notamment dans le domaine du développement, aux délais de mise sur le marché en développant les fonctions essentielles du produit mais en sacrifiant certaines fonctionnalités jugées non indispensables. Etant très flexible, le but est de récupérer un maximum de retours des utilisateurs sur la valeur (à le service/fonctionnalité mises en avant) délivrée. Ceci permettra une adaptation du produit en retirant, ajoutant définitivement ou créant des fonctionnalités compte tenu des retours utilisateurs récupérés.

Image 1

Mais comment définit-on la valeur afin de mener à bien un projet AGILE ?

Comme dit plus haut, ce sont les retours des utilisateurs qui vont pouvoir beaucoup aider à cerner les fonctionnalités attendues afin de prioriser les futures améliorations. Néanmoins, la valeur ne se limite pas à ça.

Le Modèle de Kano développé par Noriaki Kano 1984, permet de prendre en compte les attentes explicites ainsi que de faire émerger certains besoins latents ou implicites des potentiels clients.

Image 2

Ci-dessus le modèle de Kano schématisé sur le point de vue de la perception client

Cet outil est souvent piloté par un questionnaire en deux parties distinctes :

  • La première pour traiter les perceptions du client devant des caractéristiques produit.
  • La seconde partie pour traiter les perceptions client en l’absence de ces mêmes caractéristiques. (I.e. les questionnaires de satisfaction que l’on reçoit régulièrement par email sont un exemple de ce style de questionnaire, souvent orientés pour déceler de potentiels besoins pour adresser de nouvelles fonctionnalités, services, etc.)

Après la réalisation de cette étape cruciale, et une fois les besoins bien identifiés, ceux-ci doivent être priorisés. Cette étape est extrêmement importante pour pouvoir être réactif au vu des attentes client.

Une méthode est très utilisée, notamment dans le domaine du développement : la méthode MoSCoW. En d’autres termes :

  • Must have : Les besoins vitaux pour l’utilité produit
  • Should have : Les besoins qui seraient nécessaires
  • Could have : les besoins qui seront plus perçus comme du confort
  • Won’t have : des besoins que l’on peut qualifier un peu de “luxe” et qui n’ont qu’un impact faible

Une fois ces deux étapes effectuées, cela permet d’avoir une vision beaucoup plus claire des besoins des clients. Cela aura aussi permis de mettre en avant tous les points clés d’un produit en posant des questions aux clients, et par conséquent d’aligner les parties prenantes du projet pour mener à bien celui-ci.

Pour conclure, ceci n’est qu’un aperçu du sujet mais il existe d’autres étapes intéressantes pour maximiser le ciblage de ces besoins. Néanmoins le framework qu’offre la méthode AGILE est beaucoup plus dynamique et orienté sur le besoin client du moment. Les remises en question et adaptations sont donc fréquentes. La valeur à fournir n’est pas quelque chose qui est défini au prime abord, mais évolue durant tout le cycle du produit.

 

François N.

Sources :
Source 1  Source 2  Source 3 Tagged: ,

Contact

N’hésitez pas à nous solliciter pour vos projets ou pour en savoir plus sur nos expertises, nos offres et nos domaines de compétences.