La résistance au changement s’oppose à l’amélioration des processus, c’est devenu un lieu commun. Parmi les nombreux facteurs en jeu, il ne faut pas négliger la dimension outillage.
Les processus de développement de projet peuvent être handicapés par l’outillage associé. Il ne suffit pas d’avoir une collection d’outils de génie logiciel. Si la valeur et la qualité des outils, leur intégration, leur interopérabilité est jugée déficiente par les équipes projet, le déploiement des bonnes pratiques, dont l’outillage est le soutien, sera handicapé. D’autant plus que les utilisateurs sont des professionnels de la fabrication du logiciel.
Le facteur de résistance au changement réside dans le cout d’usage (trop) élevé pour les utilisateurs. Voici quelques exemples que chacun peut confronter à sa situation :
- Stress associé à la lenteur de fonctionnement d’outils fréquemment utilisés (sous-dimensionnements, capacités sous évaluées)
- Rework pénible du fait des saisies manuelles redondantes fréquemment demandées dans divers outils (doublonnages des informations à la charge de l’utilisateur)
- Risque d’incohérence lorsque de mêmes informations doivent être fréquemment mises à jour manuellement dans plusieurs outils
- Solutions partielles obligeant à effectuer des opérations manuellement. (ex : outillage de gestion en configuration sans baselining).
- Stress issu de la multiplication des logins pour les différents outils
- Rework fastidieux en l’absence de moyen simple de reprise des données dans l’outillage.
- Réticences à effectuer du reporting ou de la diffusion d’information en l’absence de simple capacité d’exportation des données vers des formats populaires (eg XL)
- Dispersion et divergence des pratiques si l’outillage n’a pas la capacité à définir des templates structurants et des règles de bon emploi.
- Difficultés à piloter des processus par les indicateurs, en cas de carence de métriques paramétrables dans l’outillage, et sans capacité de présentation de tableaux de bord d’indicateurs
- Manque de traçabilité dans l’outillage sur l’historique des modifications, les versions, les statuts et les validations, et leurs auteurs.
- Réticences à produire des artefacts uniquement pour démontrer les preuves lors de revues AQ ou lors des évaluations SCAMPI. Cas d’outillage n’ayant pas la capacité naturelle à tracer et à historiser les modifications, activités, versions, étapes/statuts, les validations, et leurs auteurs.
Ces difficultés relevées sur le terrain sont autant d’opportunités de compléter les exigences d’une suite d’outils pour faciliter leur appropriation. Une bonne partie de ces exigences dérive des General Practices CMMI et les autres relèvent du bon sens. Et bien sur dans tous les cas, au delà des outils eux-mêmes, il faut assurer également des activités de formation de support à l’outillage.
Prendre en compte ces besoins des utilisateurs n’est pas un luxe, c’est s’assurer d’une bonne adoption des pratiques et de l’outillage associé.
