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:
- Avoir les moyens de développer l'activité, et pour cela retrouver / maintenir un avantage concurrentiel,
- Réduire les coûts et les délais pour améliorer la rentabilité du projet,
- 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.
