Lors de nos articles précédents, nous avons développé les 4 premiers axes de performance des équipes de développement : alignement, qualité, productivité et évolutivité. Le cinquième élément important à prendre en compte pour évaluer la performance d’une équipe de développement est le caractère prévisible des résultats obtenus.

Selon diverses études évoquées notamment par Tech’In France dans le livre blanc sur la conduite de l’innovation : 58% des logiciels achetés ne sont jamais mis en production, seulement 13% des projets informatiques sont livrés dans les délais et 30% des projets sont purement et simplement arrêtés. C’est dire l’enjeu qui demeure encore sur cet axe pour piloter et prévoir les projets de logiciels.

Evidemment, il est très difficile de comparer le niveau de prédictibilité d’une équipe de développement réalisant des applications de gestion dans un marché relativement stable fonctionnellement et celui d’une équipe de recherche et développement d’un éditeur de logiciels innovant dans un domaine technologique proche de la recherche.

Néanmoins, la finalité de toute équipe de développement est d’obtenir des résultats, que ceux-ci soient des prototypes de recherche, des logiciels devant être commercialisés ou des applications à usage interne. Dans l’univers des applications de gestion, et avec l’état de l’art actuel, il nous semble particulièrement faisable d’obtenir des résultats réguliers, dans des délais et pour des coûts que l’on peut évaluer à l’aide de critères macroscopiques relativement simples et limités.

Pour des éditeurs de logiciels, il faut pouvoir formaliser une feuille de route (roadmap) et sortir des versions régulièrement. Même s’il est notoire que ces feuilles de route sont rarement respectées, des décalages trop importants peuvent mener à la catastrophe, car les prévisions financières y sont souvent liées. Voici un exemple de feuille de route traditionnelle traitant de Microsoft Visual Studio sur les années passées :

 

L’évolution vers le “Software as a Service”, où la concurrence est rude, nécessite en général des diffusions plus régulières, avec une approche comparable aux entreprises “Web” (dont le modèle d’affaires est basé sur Internet comme par exemple AlloCiné). Il faut alors intégrer des améliorations en permanence mais cela revient aussi à une feuille de route. Dans ce 2e cas, elle est simplement construite dans l’autre sens, avec des dates figées et une variation de ce qui peut “rentrer” dans une version donnée, généralement alignée sur une saison ou un semestre. Voici un exemple pour l’offre Microsoft Dynamics CRM :

 

Enfin, notons que pour les éditeurs, il est souvent nécessaire de faire émerger de nouveaux produits, pour se différencier de la concurrence et conserver une place sur le marché.

Pour des grandes entreprises, la problématique est finalement assez similaire, car il faut pouvoir orchestrer la diffusion d’applications métier au sein de celles-ci, en préparant le déploiement, la formation et le support aux utilisateurs. Idéalement, les cellules développement du département informatique des grandes entreprises devraient se comporter comme de petits éditeurs de logiciels. Nous voyons d’ailleurs de plus en plus ce point s’exprimer, car les organisations évoluent de façon à provoquer ce type de situation, par exemple par le jeu des rachats ou des cloisonnements entre entités juridiques distinctes ou filiales internationales autonomes.

De notre expérience, beaucoup d’échecs sont dus à un décalage entre le résultat attendu et ce qui est produit. Ce décalage est souvent issu d’une rupture voulue entre conception et développement. L’off-shore est un des facteurs qui a contribué à renforcer cet état de fait.

En tentant d’imiter des modèles issus de l’industrie traditionnelle, certains ont oublié que – contrairement à l’industrie de matières “physiques” – la phase de réalisation d’un logiciel n’est jamais la reproduction d’un processus effectué à l’identique. Chaque développement est par nature unique (puisqu’il est immatériel et peut ensuite être répliqué à coût nul).

Le raisonnement transposé dans l’univers du développement logiciel a désormais démontré ses limites et un mouvement de reflux de ces modèles à bas coût commence à se faire jour… avec désormais des problèmes liés à la pénurie de ressources que ce modèle a créée.

Nous avons d’ailleurs publié l’article suivant Le mythe du mois-homme indien afin de rappeler que la mesure d’un projet en jour-homme est une aberration dénoncée depuis 1975 mais qui n’a pas empêché le mouvement vers l’off-shore.

Il est également fréquent, notamment lors de ruptures technologiques, de trouver des équipes qui perdent la maîtrise du calendrier et des projets de R&D peuvent prendre plusieurs mois voire des années de retard, avec des budgets qui gonflent dans les mêmes proportions et des déficits colossaux. Ce phénomène est très marqué chez les éditeurs de logiciels, car les grandes vagues d’investissement se font parfois à plus d’une décennie d’écart, avec un saut culturel important qui n’est pas évalué par le management ni par les équipes.

Il est donc indispensable de disposer de jalons réguliers comprenant des livraisons de versions et des mises à jour de fonctionnalités afin d’éviter l’effet tunnel de certains grands projets qui peuvent créer un énorme “trou” dans les éléments “produits”.

C’est pourquoi les méthodes agiles constituent aussi un rempart intéressant pour éviter l’effet tunnel en maintenant un alignement entre les détenteurs de la vision “produit” et les équipes de réalisation. Certains indicateurs de prédictibilité sont d’ailleurs intégrés à ces méthodes, sous la forme d’un pourcentage réalisé de chaque itération par rapport à ce qui est prévu en début d’itération.

Même si cet aspect est clairement utile et intéressant, il ne faut pas se tromper de débat pour autant. La prédictibilité à atteindre dépasse le cadre du travail mesuré au niveau de chaque itération – généralement 2 à 3 semaines – et se doit d’être atteinte à un niveau plus macroscopique comme évoqué précédemment au niveau de la feuille de route.

Pour conclure, notons que l’enjeu de la prédictibilité est plus fort qu’il n’y parait, car, au-delà des conséquences financières directes d’un retard, lorsque la perte de confiance s’installe, la dynamique devient rapidement un cercle vicieux. Les calendriers prenant du retard, les responsables fonctionnels “chargent la barque” car ils savent qu’ils attendront longtemps des fonctionnalités reportées à une version ultérieure, et le projet devient de plus en plus exposé à des risques d’échec majeur.