mercredi 24 septembre 2014

1) Réécrire un logiciel de A à Z ou ne rien faire, où comment sortir du statu quo


Introduction

Vous avez peut être déjà été confrontés au choix de ré-implémenter un logiciel de taille conséquente soit de zéro, soit de le faire évoluer. La facilité ou la difficulté de faire évoluer un logiciel dépend de plusieurs critères :
  • l'architecture plus ou moins pertinente et sa complexité,
  • la façon dont le code est écrit, documenté,
  • les librairies utilisées qui peuvent être obsolètes et plus supportées,
  • la couverture de tests (idéalement automatisés),
  • les diverses documentations du logiciel (installation, exploitation, guide utilisateur...).

Une évolution sur un logiciel ancien peut s'apparenter à un jeu de mikado, où régressions et instabilités peuvent surgir parfois assez facilement. 

Quels sont les enjeux ?

Si le produit est vraiment en fin de vie, et que l'on prépare son successeur dans une autre équipe pourquoi ne pas le laisser tel quel ? Cela peut se justifier si les technologies sont très différentes (passage de .NET à Java par exemple), mais attention toutefois à la phase de transition et de migration pour les clients, qui risque d'être longue, voire de ne jamais se faire pour certains !

Si le produit logiciel est sur un marché à potentiel intéressant, le ré-implémenter de A à Z peut conduire à une perte de marché. En effet, pendant une période significative, le nouveau produit ne sera pas disponible. L'ajout de nouvelles fonctionnalités augmentera d'autant les délais. Hors plus la sortie du produit sera tardive, et plus il est probable qu'il y ait des pressions pour intégrer des évolutions retardant encore la sortie du produit. Le risque est donc sérieux pour l'entreprise.

Pour chaque équipe, le coût de la non qualité se traduit par une moindre capacité à produire. Opter pour le statu quo c'est laisser le projet aller à la dérive. Qui plus est, faire travailler des personnes sur un vieux projet avec des technologies anciennes, et sans possibilité pour elles de contribuer à l'amélioration de la situation peut être démotivant et source de turnover.

Il y a donc 3 enjeux assez interdépendants:
  1. Avoir les moyens de développer l'activité, et pour cela retrouver / maintenir un avantage concurrentiel,
  2. Réduire les coûts et les délais pour améliorer la rentabilité du projet,
  3. Avoir des équipes motivées, impliquées.

Que décider ?

Dans certaines entreprises, on peut rester pendant des mois voire des années sans prise de décision sur un produit. J'y vois plusieurs raison possibles :
  • On a peur des conséquences pour l'entreprise (et pour soi!) si on prend une décision audacieuse et donc risquée. 
  • On préfère opter pour des améliorations générales non spécifiques au produit.
  • On se sent coincé et donc on se montre fataliste en reportant la responsabilité sur le produit ou sur les objectifs à court terme.
  • Les objectifs mêmes de l'entreprise peuvent contribuer à ne pas prendre de décision, par exemple si le focus est mis sur d'autres produits.
Pourtant, entre tout réécrire et ne rien faire, il y a une troisième possibilité qui peut permettre d'aller vers un mieux en limitant les risques, mais cela nécessite un minimum d'investissements, et de courage. Nous allons voir dans la suite de cet article, qu'il est possible :
  • d'agir sur l'environnement,
  • d'agir sur le produit lui même,
  • et de gérer le risque humain.

Aucun commentaire:

Enregistrer un commentaire