J’ai la chance de vivre présentement une première expérience de Go Live dans le cadre d’un projet dans lequel je suis impliqué au travail (pour ceux qui ignore ce qu’est un Go Live, c’est ainsi que l’on nomme généralement le moment où l’on procède à la mise en ligne d’un nouveau système informatique).

C’est surprenant de voir à quel point tout ce qu’on s’amuse à nous enseigner à l’école est vrai. L’utilisateur final doit vraiment être impliqué à fond dans le processus d’élaboration des spécifications du nouveau système, sans quoi l’application risque de ne pas être acceptée ou pire, non utilisée. Ou encore, comme disait un de mes profs dans un cours de bac, [il faudrait que je retrouve cette citation dans mes notes!]

Cependant, il est aussi intéressant de voir que malgré tous les efforts mis par l’équipe d’analyse à rencontrer les gens, étudier leurs façons de faire ou valider avec eux les solutions proposées, il reste toujours un écart entre la solution finale élaborée afin de répondre à leurs besoins et la vraie réalité de leurs tâches. C’est encore plus vrai quand plusieurs groupes d’utilisateurs, aux intérêts pas toujours convergents et aux tâches interreliées!

La gestion du changement post-go live demeure donc un défi. Il faut répondre de façon instantanée aux commentaires des usagers afin de conserver leur fragile enthousiasme pour la nouvelle application, tout en jonglant avec les nouvelles demandes qui semblent émerger de nulle part et qui sont toutes aussi critiques les unes que les autres.

J’ai hâte que le tout se stabilise d’ici les prochaines semaines afin de pouvoir identifier quelles sont les raisons qui ont entraîné ces écarts. Résistance au changement de la part des usagers, collecte des besoins incomplètes?

C’est à suivre!