Comme beaucoup de projets d’évolution d’outils, un des points les plus importants, c’est l’accompagnement au changement – avec le recueil des besoins1 des utilisateurs.
Par exemple, j’ai organisé pas mal de migrations d’outils structurants dans la façon de travailler (Eclipse -> IntelliJ, SVN -> Git + Merge Request, etc). À chaque fois au moins une personne m’a opposé que cette migration ne de devrait pas être faite parce que « un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail) ».
Eh bien, la migration s’est toujours bien passée, et les plus râleurs ne reviendraient en arrière pour rien au monde.
Évidemment, réussir une migration de ce type n’est ni facile ni immédiat. Il y a une longue phase de recueil des besoins, de préparation de la migration, d’explications en amont pour que les personnes concernées puissent s’approprier le projet, d’explication des attendus, d’indication de ce qui sera plus pratique, plus efficace, plus agréable et aussi plus difficile à faire2 et plus complexe. Ensuite il y la bascule proprement dite, et le soutien aux équipes tant que le nouvel outil n’est pas maitrisé – sans jugement ni pression excessive.
Mais, en un mot comme en cent : un usage ou un flux de travail, ça se modifie très bien. Le fait qu’il y ait un usage en place, un outil ou une organisation de travail particulière, ça n’est en rien un argument valable à lui seul pour interdire une modification. C’est un argument parmi d’autres dans une procédure de décision de changement, mais certainement pas le seul.
On parle bien besoins et pas envies des utilisateurs. Le classique, c’est l’utilisateur qui va faire des pieds et des mains pour exiger que rien ne change parce qu’il n’a pas envie de changer sa façon de faire, alors qu’il pourrait être beaucoup productif et de façon beaucoup plus confortable avec un nouvel outil. Un autre classique, c’est les demandes de gadgets. Il y a aussi toute cette catégorie d’irritants dont les gens n’ont même pas conscience et qu’ils ne peuvent donc pas verbaliser, parce que le problème est tellement intégré qu’ils ne savent pas qu’on peut faire différemment. ↩
Note : ça peut être une bonne chose que quelque chose devienne plus difficile à faire. Comme « pousser du code qui ne compile pas sur le HEAD » par exemple. ↩
[^] # L’accompagnement au changement
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 6.
Comme beaucoup de projets d’évolution d’outils, un des points les plus importants, c’est l’accompagnement au changement – avec le recueil des besoins1 des utilisateurs.
Par exemple, j’ai organisé pas mal de migrations d’outils structurants dans la façon de travailler (Eclipse -> IntelliJ, SVN -> Git + Merge Request, etc). À chaque fois au moins une personne m’a opposé que cette migration ne de devrait pas être faite parce que « un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail) ».
Eh bien, la migration s’est toujours bien passée, et les plus râleurs ne reviendraient en arrière pour rien au monde.
Évidemment, réussir une migration de ce type n’est ni facile ni immédiat. Il y a une longue phase de recueil des besoins, de préparation de la migration, d’explications en amont pour que les personnes concernées puissent s’approprier le projet, d’explication des attendus, d’indication de ce qui sera plus pratique, plus efficace, plus agréable et aussi plus difficile à faire2 et plus complexe. Ensuite il y la bascule proprement dite, et le soutien aux équipes tant que le nouvel outil n’est pas maitrisé – sans jugement ni pression excessive.
Mais, en un mot comme en cent : un usage ou un flux de travail, ça se modifie très bien. Le fait qu’il y ait un usage en place, un outil ou une organisation de travail particulière, ça n’est en rien un argument valable à lui seul pour interdire une modification. C’est un argument parmi d’autres dans une procédure de décision de changement, mais certainement pas le seul.
On parle bien besoins et pas envies des utilisateurs. Le classique, c’est l’utilisateur qui va faire des pieds et des mains pour exiger que rien ne change parce qu’il n’a pas envie de changer sa façon de faire, alors qu’il pourrait être beaucoup productif et de façon beaucoup plus confortable avec un nouvel outil. Un autre classique, c’est les demandes de gadgets. Il y a aussi toute cette catégorie d’irritants dont les gens n’ont même pas conscience et qu’ils ne peuvent donc pas verbaliser, parce que le problème est tellement intégré qu’ils ne savent pas qu’on peut faire différemment. ↩
Note : ça peut être une bonne chose que quelque chose devienne plus difficile à faire. Comme « pousser du code qui ne compile pas sur le HEAD » par exemple. ↩
La connaissance libre : https://zestedesavoir.com