{"id":20758,"date":"2017-04-21T14:57:19","date_gmt":"2017-04-21T12:57:19","guid":{"rendered":"http:\/\/e3mag.com\/?p=20758"},"modified":"2022-05-01T08:23:27","modified_gmt":"2022-05-01T06:23:27","slug":"lagilite-avec-laquelle-les-gens-reagissent-au-changement","status":"publish","type":"post","link":"https:\/\/e3mag.com\/fr\/lagilite-avec-laquelle-les-gens-reagissent-au-changement\/","title":{"rendered":"Dans quelle mesure les personnes r\u00e9agissent-elles avec agilit\u00e9 aux changements ?"},"content":{"rendered":"

\"Chris<\/a>Le point de d\u00e9part de cet article est un grand projet de d\u00e9veloppement et d'introduction d'un nouveau logiciel SAP pour plus de mille utilisateurs dans une grande entreprise internationale.<\/p>\n

Pour ce faire, certaines fonctionnalit\u00e9s essentielles pour le client ont d\u00fb \u00eatre enti\u00e8rement d\u00e9velopp\u00e9es en plus des fonctionnalit\u00e9s standard d\u00e9j\u00e0 pr\u00e9sentes dans le syst\u00e8me, et les processus existants ont d'abord \u00e9t\u00e9 analys\u00e9s et en partie optimis\u00e9s.<\/p>\n

Les m\u00e9thodes agiles sont sur toutes les l\u00e8vres et sont souvent pr\u00e9sent\u00e9es comme le \"sauveur\" de toutes sortes de probl\u00e8mes connus dans les projets de d\u00e9veloppement de logiciels d'autrefois. L'approche relativement rigide et lin\u00e9aire de la m\u00e9thodologie (de projet) classique en cascade, qui consistait \u00e0 passer de l'analyse des besoins \u00e0 la d\u00e9finition de la solution, puis \u00e0 la phase de d\u00e9veloppement et de test, souvent longue, en vue d'obtenir un r\u00e9sultat final enti\u00e8rement d\u00e9fini d\u00e8s le d\u00e9but du projet, comportait de nombreux risques de ne pas atteindre le r\u00e9sultat souhait\u00e9 au final.<\/p>\n

Trop d'impr\u00e9vus pouvaient survenir pendant la longue dur\u00e9e du projet : Les exigences ne pouvaient pas \u00eatre enti\u00e8rement d\u00e9finies dans les moindres d\u00e9tails au d\u00e9but, les parties prenantes changeaient pendant la dur\u00e9e du projet, les technologies \u00e9taient d\u00e9j\u00e0 obsol\u00e8tes \u00e0 la fin du projet ou les exigences initiales avaient tout simplement chang\u00e9 pendant une longue phase de d\u00e9veloppement ou \u00e9taient soudainement devenues obsol\u00e8tes.<\/p>\n

L'approche it\u00e9rative des m\u00e9thodes de projet et de d\u00e9veloppement agiles promet une flexibilit\u00e9 et une s\u00e9curit\u00e9 nettement plus grandes pour pouvoir r\u00e9agir aux changements qui surviennent.<\/p>\n

Des cycles de d\u00e9veloppement courts, g\u00e9n\u00e9ralement d'une \u00e0 deux semaines, permettent de d\u00e9finir et de livrer des paquets de d\u00e9veloppement g\u00e9rables et moins complexes pour les \"sprints\" et de pouvoir r\u00e9agir de mani\u00e8re flexible \u00e0 l'\u00e9volution des exigences lors des revues de sprint r\u00e9currentes avec les donneurs d'ordre qui s'ensuivent.<\/p>\n

On a presque l'impression que tout projet (de d\u00e9veloppement) organis\u00e9 de mani\u00e8re agile devrait logiquement et automatiquement \u00eatre un succ\u00e8s. Malheureusement, ce n'est pas le cas.<\/p>\n

L'ach\u00e8vement r\u00e9ussi des travaux de d\u00e9veloppement ne d\u00e9finit pas la r\u00e9ussite d'un grand projet de d\u00e9veloppement de logiciels. Le logiciel peut avoir \u00e9t\u00e9 enti\u00e8rement red\u00e9velopp\u00e9, adapt\u00e9 ou \u00e9tendu en cons\u00e9quence, aussi bien et de mani\u00e8re aussi cibl\u00e9e que possible, pour aboutir \u00e0 un r\u00e9sultat final fonctionnel, et les exigences des donneurs d'ordre peuvent \u00e9galement \u00eatre pleinement satisfaites :<\/p>\n

Le v\u00e9ritable succ\u00e8s du projet n'est atteint que lorsque le nouveau logiciel a \u00e9t\u00e9 d\u00e9ploy\u00e9 avec succ\u00e8s dans l'entreprise et qu'il est accept\u00e9 et utilis\u00e9 par une grande masse d'utilisateurs.<\/p>\n

L'introduction d'un nouveau logiciel s'accompagne g\u00e9n\u00e9ralement de l'introduction de processus nouveaux ou modifi\u00e9s. Les processus qui sont v\u00e9cus par des personnes ne peuvent toutefois pas \u00eatre introduits ou modifi\u00e9s de mani\u00e8re \"agile\", car les personnes sont toujours soumises \u00e0 des vitesses de changement diff\u00e9rentes.<\/p>\n

Aucune m\u00e9thode de projet ou de d\u00e9veloppement, aussi agile soit-elle, ne peut y rem\u00e9dier. Si le \"facteur humain\" n'est pas per\u00e7u et pris au s\u00e9rieux \u00e0 temps, m\u00eame le projet logiciel le plus agile se soldera, dans le meilleur des cas, par un super logiciel qui plaira certes au donneur d'ordre et peut-\u00eatre \u00e0 quelques parties prenantes, mais qui ne sera pas du tout utilis\u00e9 par la grande masse des utilisateurs ou seulement de mani\u00e8re inefficace.<\/p>\n

L'exp\u00e9rience montre que le risque de r\u00e9ussite augmente avec la taille du groupe d'utilisateurs (ou de l'entreprise), car il arrive souvent qu'aucun groupe repr\u00e9sentatif des utilisateurs finaux n'ait \u00e9t\u00e9 impliqu\u00e9 dans les sessions de feedback des diff\u00e9rents cycles de d\u00e9veloppement.<\/p>\n

D'une part, dans la composition des parties prenantes, en particulier celles qui sont charg\u00e9es des revues de sprint, on a tendance \u00e0 choisir des collaborateurs d\u00e9j\u00e0 engag\u00e9s et plut\u00f4t enclins au changement.<\/p>\n

En outre, il s'agit tout simplement d'un probl\u00e8me de masse : avec plus de 1000 utilisateurs finaux concern\u00e9s et \u00e9ventuellement plusieurs processus concern\u00e9s, il est tr\u00e8s probable que le petit groupe de base aupr\u00e8s duquel un feedback est activement demand\u00e9 pendant la phase de sprint ne soit tout simplement pas repr\u00e9sentatif.<\/p>\n

Que faire alors pour mener au mieux un projet de d\u00e9veloppement de logiciel avec un grand nombre d'utilisateurs concern\u00e9s sur la voie du succ\u00e8s ?
\nDe notre point de vue, il s'agit de combiner les avantages des m\u00e9thodes modernes et agiles avec ceux des m\u00e9thodes classiques de gestion de projet et de d\u00e9veloppement organisationnel : d\u00e9velopper de mani\u00e8re agile, d\u00e9ployer de mani\u00e8re classique.<\/p>\n

Dans le projet d'introduction de logiciel \u00e0 la base de cet article, avec plus d'un millier d'utilisateurs concern\u00e9s, on a eu recours \u00e0 la proc\u00e9dure de projet Sirius, qui a fait ses preuves et qui combine les avantages de la m\u00e9thodologie agile Scrum avec les proc\u00e9dures classiques de gestion de projet et la gestion des changements organisationnels.<\/p>\n

Il s'agit de mettre en place le plus t\u00f4t possible plusieurs canaux de communication et d'interaction avec le plus grand nombre possible d'utilisateurs finaux (potentiellement tous).<\/p>\n

Nous estimons que l'int\u00e9gration de quelques \"utilisateurs cl\u00e9s\" s\u00e9lectionn\u00e9s ne suffit pas pour obtenir l'acceptation du nouveau logiciel \u00e0 introduire et, le cas \u00e9ch\u00e9ant, des changements de processus \u00e0 venir. Il faut au contraire investir beaucoup plus - et ce d\u00e8s le d\u00e9but du projet - dans les th\u00e8mes complexes de la communication et de la gestion du changement, qui sont souvent laiss\u00e9s de c\u00f4t\u00e9 par manque de temps, d'argent et de ressources.<\/p>\n

Il n'y a jamais trop d'informations et de transparence sur les changements \u00e0 venir - seulement trop peu !<\/p>\n

\"Sirius<\/a><\/p>\n

Phases de la m\u00e9thodologie de projet Sirius<\/h3>\n

Concr\u00e8tement, il s'est \u00e0 nouveau av\u00e9r\u00e9 utile, dans le cadre du pr\u00e9sent projet, d'accorder une attention toute particuli\u00e8re aux points suivants lors des diff\u00e9rentes phases du projet :<\/p>\n

Scoping<\/h4>\n