Organiser les évolutions après la mise en service

Un outil interne n'est jamais terminé. Les activités changent, les règles évoluent, les utilisateurs découvrent des besoins qu'ils n'imaginaient pas avant de s'en servir. La question n'est donc pas de savoir s'il y aura des évolutions, mais comment les organiser sans repartir dans un projet à chaque demande.

Rassembler les demandes au même endroit

Les demandes arrivent par tous les canaux : une remarque en réunion, un message, une conversation de couloir. Sans point de collecte unique, les plus insistantes passent avant les plus utiles. Créez une liste unique, accessible aux personnes concernées, où chaque ligne comporte :

• la demande formulée du point de vue de l'utilisateur : qui, quelle action, pour quel résultat ;
• le demandeur et la date ;
• la gêne actuelle et son contournement éventuel ;
• le nombre de personnes concernées ;
• son état : reçue, acceptée, planifiée, livrée, écartée.

Une demande écartée reste visible, avec sa raison. C'est ce qui évite qu'elle revienne tous les trois mois sous une autre forme.

Séparer ce qui corrige de ce qui ajoute

Ce dernier point est souvent négligé. Les composants d'une application reçoivent des correctifs de sécurité ; les reporter indéfiniment finit par coûter plus cher que les appliquer, comme l'explique l'article sur la maintenance corrective et évolutive.

Décider par cycles réguliers

Plutôt que d'arbitrer au fil de l'eau, fixez un rendez-vous régulier où les demandes sont revues. Une réunion courte suffit :

1. Ce qui a été livré depuis la dernière fois, et ce que les utilisateurs en disent.
2. Les demandes nouvelles, présentées brièvement.
3. L'ordre de grandeur de l'effort, donné par l'équipe technique.
4. La décision : le contenu du prochain lot, et ce qui attend.

Une personne désignée tranche en cas de désaccord. Ce rythme de petites livraisons décidées ensemble correspond à la méthode agile appliquée à la vie courante d'un outil.

Livrer sans perturber le travail

• Des lots courts et prévisibles, plutôt qu'une grosse livraison annuelle risquée.
• Un environnement de test où la nouveauté est vérifiée avant d'atteindre la production.
• Une mise en production à une heure creuse, avec une possibilité de revenir en arrière.
• Une annonce avant et après : ce qui change, pour qui, à partir de quand.
• La documentation mise à jour dans le même mouvement, sans quoi les fiches deviennent trompeuses.

Surveiller les effets d'une évolution

Après chaque livraison importante, vérifiez ce qui se passe réellement : la fonction est-elle utilisée, a-t-elle fait apparaître de nouvelles anomalies, les demandes qu'elle devait éteindre ont-elles cessé ? Une évolution livrée puis jamais utilisée est une information précieuse pour les décisions suivantes.

Éviter l'accumulation sans fin

Une liste de demandes qui ne fait que grossir décourage tout le monde. Faites régulièrement le ménage : écartez ce qui n'a plus de sens, fusionnez les doublons, fermez les demandes dont l'auteur a quitté le sujet. Mieux vaut une liste courte et vraie qu'un inventaire exhaustif que personne ne lit.

NexSecure fait évoluer les applications qu'elle suit, dans le cadre de son offre de maintenance.