L’évolution d’une gamme de produits est dictée par l’évolution des besoins. Ces changements de besoins peuvent provenir d’un certain nombre de sources, telles que le marché, les besoins futurs de l’entreprise ou le désir d’introduire de nouveaux produits dans la ligne de produits.
Garder le contrôle du périmètre et de la dette technique (gestion de l’obsolescence et des choix techniques d’implémentation) de la ligne de produit via une gouvernance forte est un enjeu majeur dans sa maintenance et son évolution.
Parmi les principaux écueils, on notera :
- Il n’existe pas de gouvernance ou pas de gouvernance solide (c’est à dire qui n’est pas reconnue dans l’entreprise ou outrepassée par d’autres processus – par les projets par exemple);
- Une gouvernance trop rigide ou décorrélée des besoins opérationnels qui ne permet plus de s’adapter aux changements du marché;
- Le projet qui vient forcer la ligne de produit à faire une modification et in-fine dénaturer la ligne de produit;
- Gestion de l’obsolescence :
- On s’accroche à toutes les fonctionnalités, même à celles qui ne sont plus d’actualité, ce qui conduit à une charge de maintenance trop élevée;
- L’obsolescence des composants non prise en compte dans la création conduit à un coût de maintenance trop élevé de la ligne de produit, voire la met en péril;
- La création et la maintenance sont découplées et n’ont pas de règles communes.
Voici quelques bonnes pratiques à prendre en compte :
- Mettre en place une rétroaction des projets vers la ligne de produit au sein de la gouvernance pour réinjecter ce qui pourrait être réutilisé et comprendre ce qui n’est pas utilisé;
- Il faut faire en sorte que la maintenance et l’évolution de la ligne de produit soit faite au bon moment c’est-à-dire au moment où on a besoin de faire une instanciation. Cela implique un pilotage de la ligne de produit en fonction des temporalités projet;
- Faire bouger les architectes entre la maintenance de la ligne de produit et les projets pour améliorer la pertinence des architectures vis à vis des besoins projets;
- Avoir maillé lors de la création de la ligne de produit l’architecture documentaire (de la spécification jusqu’aux tests) sur l’architecture de la ligne de produit afin de favoriser la capitalisation sur projet et la gestion de la configuration;
- Ne pas hésiter à élaguer certains éléments/features voire faire une nouvelle ligne de produit si on se rend compte que la maintenance ou l’évolution de la ligne de produit ne fait plus sens opérationnellement ou économiquement.
Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette phase :
“ Aujourd’hui il nous arrive de passer beaucoup de temps à retrouver des rapports de tests, les justifications des choix de design etc… par manque de maillage entre la documentation et l’architecture, et de partage entre les différentes entités.
“ On travaille surtout en extension de lignes de produit (en ajoutant de nouveaux artefacts) pour gagner en efficacité voire adresser de nouveaux marchés plus rapidement.
“ Les environnements de développement varient énormément sur des séries très longues : nous sommes obligés de garder de vieux PC uniquement pour faire des modifications en cas de soucis sur ces anciens produits.
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.