10/11/2005

Triangle de McConnell

Parmi mes différentes lectures autour du Génie Logiciel, le livre Rapid Developpement a été pour moi un des plus importants. Son auteur est un des consultants senior du monde Software les plus reconnus Outre-Atlantique. Il a oeuvré au sein de Microsoft afin d'améliorer leurs processus et leurs "Best Pratices".

Steve McConnell définit dans cet ouvrage un concept essentiel, que j'appelerais le "McConnell's Triangle" (que d'autres appeleront, "Triangle of Truth" or "Gold Triangle").

Il s'agit en réalité de comprendre qu'en terme de réalisation de logiciels :

Le planning (schedule), le coût (cost), et le produit (product) forment un équilibre.

 

Prenons un exemple :

Vous êtes responsable de la nouvelle version 3 d'un superbe application de gestion... Vous souhaitez rattraper votre concurrent qui propose déjà un produit plus complet que le vôtre (ie la version 2.6 déjà sortie). Vous souhaitez rattraper ce manque fonctionnel... c'est d'ailleurs ce que demande votre département Marketing ! Mais dans le même temps, votre entreprise cherche à faire des économies et votre PDG a engagé un cost killer. Et pour couronner le tout, vos commerciaux font des pieds et des mains pour remporter un énorme appel d'offre, ce qui demande de livrer un produit en temps et en heure. Bref, vous avez à trouver un équilibre entre :

  • Product : Ce que vous voulez faire .... par exemple un large jeu de fonctionnalités ou alors un ensemble plus restreint mais offrant une meilleure ergomie et un meilleure productivité
  • Schedule : Quand votre produit sera sur le marché ... c'est à dire concilier le Time to Market (si je sors mon produit après que le marché soit équipé, la partie est perdue d'avance) et le Time to Build (neuf femmes feraient-elle un enfant en 1 mois ?)
  • Cost : Avec quels moyens vous allez réaliser votre produit ... allez-vous utiliser vos ressources internes ? rechercher des partenariats ? Bref, répondre à question Make or Buy ?... Ou même Make Offshore désormais.

Quel dilemme ! D'autant qu'il faudra, durant les spécifications, le développement et les tests, veiller à maintenir cet équilibre... et ce, jusqu'à la General Availability du produit ! Vous avez interêt à conserver ce schéma en tête qui vous aidera à répondre aux questions comme "Pourrait-on faire cette feature en plus ?" ou "Il me faut le produit dans 6 mois" (You said "Release Often" ?)

Pour conclure, je dois avouer que je suis réellement enthousiaste avec ce concept d'équilibre. Gérer les risques, négocier, comprendre les besoins internes et externes autour du produit, font des metiers de création de produit et de valeur des jobs attractifs et excitants. Non ?

PS: J'ai faillé appeler cette note "Triangle de Hausermann", tellement ces concepts me semblent être la "vérité"... mais rendons à César ce qui est à César ...