Maîtriser La Technologie Transforme Les individus

L'appétit et l'approche du changement sont très personnels et varient considérablement d'une personne à l'autre. De par leur nature même, les technologues ont tendance à bien s'adapter au changement ; nous adoptons constamment de nouveaux matériels, langages ou concepts. Cependant, quand on est à l'avant-garde de tant de changement on oublie vite que d'autres personnes autour de nous subissent ces changements. Cet article nous rappelle qu'il est important de dépasser ces codes et ces processus et de prendre en compte les actions menées par les équipes techniques qui peuvent affecter nos utilisateurs dans leurs émotions. Il vise à instaurer une certaine façon de penser tout en les accompagnant dans les changements technologiques.

Les gens ne sont pas des systèmes

J'ai tendance à considérer les choses comme de gros systèmes compliqués, constitués de composants plus simples, ce qui colore ma pensée. Cette capacité à voir la simplicité dans la complexité tend à être une vision du monde partagée par les technologues, car nous ne pourrions pas remplir nos fonctions sans elle - nous serions constamment dépassés. Le fait de travailler sur un rôle où je décompose sans cesse ces problèmes complexes en sous-systèmes plus petits m'a donné une tendance à tout voir de cette façon. Je dois travailler dur pour ne pas essayer de diviser les pensées et les émotions des gens en unités trop simplistes parce que nous ne sommes pas des machines. C'est pourquoi nous sommes infiniment fascinants !

D'après mon expérience, ce qui doit être "changé" en fin de projet technique devrait encourager tout le monde à se concentrer sur la technologie. L'examen des paramètres techniques pour mesurer le succès est, bien sûr, vital ; par exemple, la réduction des temps de déploiement ou des temps de traitement des données, une augmentation du nombre de transactions traitées. Ces éléments seront et devraient toujours être pris en compte pour déterminer le succès. Cela dit, ce sont les éléments les plus faciles et les plus évidents à mesurer, si bien que des mesures qualitatives plus subtiles sont parfois ignorées. « Nos utilisateurs pensent-ils que cette version communication constitue un progrès ? » c'est une question beaucoup plus difficile auquel il faudarit pouvoir y répondre.

J'ai travaillé avec de nombreuses marques et elles consacrent beaucoup de temps à réfléchir sur nos sentiments envers la marque ; comme par exemple, "Avez-vous confiance en elle ?" "Vous sentez-vous plus sereine avec la marque ?" Je vois de nombreux critères de réussite sur des projets de logiciels qui omettent complètement cet aspect et j'aimerais qu'il y ait une approche plus équilibrée de cet aspect. En fin de compte, c'est cette réponse émotionnelle à une version ou à un produit que de nombreuses personnes utiliseront pour évaluer leur engagement à acheter plutôt que des tonnes de mesures.

Tenir compte de la réponse émotionnelle d'un utilisateur est important

Les changements apportés par les équipes techniques peuvent facilement affecter nos utilisateurs sans qu'on s'en rende compte. Il est indispensable de se rappeler que l'expérience des gens sur les logiciels ne se limitent pas à une série d'écrans, de boutons et d'actions ; ils ont également une réponse émotionnelle à donner. La palette de couleurs et la conception de l'interface utilisateur influencent la première impression des utilisateurs, mais l'utilisation prolongée d'un logiciel ou d'une interface conduit les utilisateurs à développer une relation avec celui-ci. Ils peuvent l'aimer ou le détester, mais ils auront appris à le comprendre (ainsi que ses limites et ses faiblesses). 

Une équipe technique peut se concentrer sur les parcours 'utilisateur' inefficaces, tandis qu'un utilisateur peut avoir le sentiment qu'il "vaut mieux un danger que l'on connaît". Si un utilisateur a trouvé un moyen de contourner un formulaire de saisie de données peu pratique dans un logiciel et que nous "nettoyons" soudainement cela, nous pourrions constater une augmentation du temps nécessaire pour remplir le formulaire ainsi qu'une certaine frustration. Si nous modifions l'ordre des onglets d'un utilisateur via les champs de saisie, nous pourrions même constater une augmentation de données erronées au mauvais endroit. Le niveau élevé de frustration qu'un utilisateur peut ressentir dans cette expérience peut commencer à briser la confiance de l'utilisateur envers le logiciel (et l'équipe qui le construit) : « Pourquoi s'amusent-ils à faire ça ! »

Lorsque les utilisateurs sont capables de prévoir avec précision leur efficacité grâce à un outil, même si cet outil lui-même est inefficace, ils peuvent fortement résister à un changement. J'ai travaillé sur un système de commerce au sein d'un vol aérien, celui-ci nécessitait une série d'étapes de rapprochement à effectuer à la fin d'un vol. L'équipage sait normalement combien de temps prend ce déroulement grâce à sa répétition et met de côté ce temps - ce qui est généralement une étape très stressante du vol. Le moment de l'atterrissage est aussi le moment où tout le monde veut quitter son siège ! Les changements apportés au logiciel (et donc au processus) autour du rapprochement, ont toujours été difficiles à faire accepter, car l'état de nervosité, quand on essai quelque chose de nouveau à un moment aussi critique dans la vie de l'équipage a toujours été vu comme difficile à vendre. Notre logiciel était l'une des multiples tâches en vogue à ce moment-là, et un changement dans une de ces tâches pouvaient entraîner une contre performance sur l'ensemble. Personne ne veut d'un équipage imprudent dans un avion. 

Les modifications apportées aux logiciels ou aux processus risquent de compromettre leur capacité à fournir des services prévisibles à l'entreprise, ce qui peut avoir des conséquences catastrophiques sur le rôle de l'utilisateur. Supposons qu'une équipe technique ne comprenne pas parfaitement comment des changements, même mineurs, influent sur la relation émotionnelle d'un utilisateur avec le logiciel ou les processus. Dans ce cas, elle peut se heurter à une résistance inattendue au changement et à l'innovation.

Problèmes de communication

L'enquête et le plaidoyer peuvent nous aider à mieux communiquer sur les problèmes. Aussi est-il nécessaire de dire à nos utilisateurs les changements que nous essayons de réaliser et pourquoi il est important. Plus précisément, formuler de la manière la plus adéquate, "c'est mieux" ne suffit pas.

Ce modèle d'enquête, donc de plaidoyer, est fondamental dans un processus de changement - vous devez passer par une étape de collecte d'informations suffisantes pour prendre une décision éclairée. Ensuite, vous devez "vendre" efficacement votre idée.

Un manque d'intérêt conduit à des propositions erronées, et si personne ne veut écouter, la qualité du plan n'a aucune importance. Les équipes techniques ont tendance à trouver des solutions très rapidement et sont probablement douées pour vendre cette solution au sein de leur entreprise. Néanmoins, le fait que le résultat ne soit pas tout à fait à la hauteur quand la solution est livrée est un problème très répandu.

Il est difficile de vendre du « temps de réflexion » (ou d'enquête) aux détenteurs de budget lorsqu'ils sont confrontés à une solution qui semble finie. À un niveau plus opérationnel, l'enquête et le plaidoyer sont les principes fondamentaux d'un modèle que j'aime. Il s'agit d'un modèle né de tragiques catastrophes aériennes où le personnel navigant n'a pas été en mesure d'apporter des informations importantes au capitaine, ce qui a entraîné une catastrophe.

Le modèle a été développé par Todd Bishop pour enquêter et défendre des idées en utilisant cinq étapes de déclaration assertive :

• Capter l'attention dès le début - Adressez-vous à la bonne bpersonne : "Hey Chef", ou "Capitaine Smith", ou "Bob", ou tout autre nom ou titre permettant d'attirer l'attention de la personne souhaitée.
• Exprimez votre inquiétude - Faites connaître tout de suite votre analyse de la situation tout en exprimant vos émotions à son sujet. "Je crains que nous n'ayons pas assez de carburant pour contourner cette tempête" ou "Je crains que le toit ne s'effondre".
• Énoncez le problème tel que vous le voyez - "Il ne reste que 40 minutes de carburant" ou "Ce bâtiment a un toit léger en treillis d'acier, et il se peut que le feu se propage dans la structure du toit".
• Proposez une solution - "Dirigeons-nous vers un autre aéroport pour faire le plein" ou "Je pense que nous devrions retirer quelques tuiles et jeter un coup d'œil avec la caméra thermique avant d'envoyer des équipes à l'intérieur".
• Obtenir l'accord (ou l'adhésion) - "Cela vous convient-il capitaine ?"

Wikipédia propose une excellente page à ce sujet - la gestion des ressources de l'équipage - et les exemples ci-dessus en sont tirés. Les exemples ci-dessus sont conçus pour le cockpit ou pour les situations où le temps est compté, mais la manière ciblée d'aborder le cœur du problème est très attrayante pour moi.

"Erreurs de l'expéditeur"

Quelles sont les erreurs courantes commises par les expéditeurs et qui peuvent entraîner une mauvaise interprétation d'un message ? L'expéditeur, bien sûr, est la personne (ou peut-être l'équipe pour nous) qui soulève le problème. Ces erreurs sont les suivantes (toujours d'après Wikipedia) :

• Absence de cadre de référence
• Omission d'informations
• Insertion de préjugés
• Méconnaissance du langage corporel
• Refus de répéter l'information
• Communication irrespectueuse

J'ai un faible pour cette liste car elle mentionne également certaines choses qui agacent vraiment les autres. J'ai vu d'excellentes idées de développeurs immédiatement rejetées parce que l'idée était présentée de manière "irrespectueuse". Une fois, j'ai vu une excellente solution technique être presque instantanément rejetée parce que le vendeur avait inclus la marque d'un concurrent dans sa présentation. Se dire que l'idée est si forte que seul un idiot la rejetterait est dangereuse. Le fait de savoir que votre démonstration physique, votre ton, votre approche, etc. peuvent provoquer une réaction si forte que les gens l'ignoreront (même sous peine de mort dans un avion) donne à réfléchir.

"Erreurs de réception"

Quelles sont les erreurs qu'on peut rencontrer à la réception de messages ? Je vais, encore une fois, citer Wikipedia :

• Écouter en ayant des préjugés
• Mauvaise préparation
• Anticiper sur ce que pense l'expéditeur
• Ignorer les signaux non verbaux
• Oublier de demander des éclaircissements
• Communiquer de façon irrespectueuse

Nous voyons ici que le "respect" et les signaux non verbaux reviennent, mais je pense que le problème le plus courant en technologie est le préjugé.

Les développeurs - mais potentiellement toute personne travaillant dans le domaine des produits et de l'architecture - ne peuvent s'empêcher de superposer leur propre expérience du problème dès le début. Il est rare qu'ils écoutent jusqu'à la fin de l'énoncé du problème avant même de commencer à réfléchir sur des solutions. Les personnes qui ne se sentent pas soumises à une pression intense ont tendance à être plus en mesure d'adopter cette approche plus approfondie de la résolution de problèmes, de sorte que tous les managers peuvent donner à leurs équipes le temps de la réflexion. Normalement, je peux voir dans les yeux d'un développeur le moment où il décide qu'il en sait assez pour résoudre le problème, et c'est presque toujours avant que je n'aie eu la possibilité de parcourir toutes les informations essentielles. C'est comme si leur compilateur interne commençait à fonctionner juste avant que le code ne soit complet.

Cette habitude d'écouter la première partie (facile) du problème sans aller jusqu'au bout est particulièrement problématique. Parfois, ce n'est qu'une fois les grandes lignes données par l'expéditeur que le développeur plonge dans les détails. Si j'ai déjà les yeux vitreux parce que "j'ai déjà fait ça avant, je vais encore le faire", alors je passe à côté du vrai problème. En outre, je manque de respect à l'expéditeur et c'est une manière terrible de commencer quelque chose !

Une mauvaise préparation est également quelque chose de courant et n'aide pas les équipes techniques. L'erreur qui consiste à croire qu'avoir plus de code va sauver la démo, ou que l'ajout de dernière minute va la faire basculer, est souvent fausse. Je ne compte plus le nombre de fois où j'ai entendu : "Ça fonctionnait, mais j'ai fait un changement rapide, et il semble que cela ait cassé cette partie". Se laisser du temps après le codage pour se fondre dans l'histoire, passer en revue la démo qui doit être donnée aux utilisateurs et travailler sur le message autour des problèmes (bons et mauvais) sont des utilisations vitales du temps qui ne devraient pas être abandonnées au profit du codage de dernière minute.

Réduire les risques d'erreur de l'expéditeur ou du destinataire

Devenir un meilleur communicant est un objectif pour quiconque veut exercer une influence au sein d'une organisation. J'aime le modèle expéditeur-récepteur, car il codifie non seulement la manière dont je délivre mon message, mais aussi la manière dont les gens l'écoutent. Pour moi, le simple fait d'être conscient de ce modèle m'amène à être un peu meilleur des deux côtés de l'équation. Je m'efforce davantage d'être clair et persuasif, mais aussi d'être un auditeur plus actif.

En étant plus conscient du processus et en essayant d'adopter ces règles dans notre approche tout en guidant nos collègues dans la même direction (avec des modèles de plan de communication qui englobent ces conseils, par exemple), l'approche est susceptible de déteindre, créant des modèles de communication plus efficaces dans l'entreprise.

En ce qui concerne les éléments plus intangibles tels que "Ne soyez pas irrespectueux", je pense que c'est le rôle d'un leader de ne pas soumettre son équipe à des situations où elles peuvent être mal interprétées. Par exemple, supposons qu'un membre de l'équipe de direction demande à des développeurs occupés de trouver des idées rapides au milieu d'un cycle de publication. Dans ce cas, le responsable risque d'obtenir des idées de qualité médiocre qui ne seront pas exprimées de manière utile. Il faut prévoir suffisamment de temps pour des réponses de qualité, et c'est le travail d'un manager de donner à l'équipe l'espace nécessaire pour répondre de manière professionnelle.

Bien sûr, si le ton des membres de l'équipe est tout simplement irrespectueux, alors vous devez le contester fermement et rapidement, tout comme vous le feriez avec un mauvais code.
 

Faire en sorte que le changement reste humain

Nous pouvons faire en sorte que le changement reste humain en étant nous-mêmes plus humains. L'accent est tellement mis sur les systèmes de travail que les individus sont mis à l'écart parce qu'il est difficile de les inscrire sur une feuille de calcul. Le travail est déjà assez difficile - cela semble très éloigné de ce pourquoi nous avons évolué - et nous ne devons pas y ajouter un stress supplémentaire. Soyez indulgent pour que le changement reste humain. Les gens ont de bons et de mauvais jours ; ils ont des caprices, des défauts et du chaos. Ils sont également brillants, créatifs et résilients. Donner de l'espace aux gens, physiquement ou intellectuellement, est vital. Le pardon renforce la loyauté. Votre plan doit être indulgent.

J'aime le concept selon lequel chaque personne qui vous entoure est un miroir. Si vous êtes toujours confronté au chaos, à la colère, au stress et au mal-être général, vous devrez peut-être regarder de façon plus attentive avant de vous lancer dans un changement.

J'aime beaucoup cette citation d'Oscar Wilde : "Soyez vous-même, les autres sont déjà pris". L'authenticité vous mènera loin car elle vous aide à établir la confiance.

La confiance vous mènera encore plus loin car la confiance est quelque chose que les hommes ne donnent qu'avec parcimonie et pas toujours par la logique même. Le fait d'être suffisamment humain pour s'en rendre compte signifie que vous pouvez être suffisamment empathique pour apporter des changements en célébrant ces caractéristiques plutôt qu'en essayant de les étouffer ou de les combattre.
 

A propos de l'auteur

Matt Overall est le PDG de SkuSpring, une entreprise qui apporte une vision disruptive du changement sur l'industrie publicitaire. En tant que leader technique, il a construit et géré des équipes qui travaillaient sur des solutions pour les marques les plus emblématiques à travers le monde. Si vous avez acheté des sandwichs sur un vol EasyJet, joué au Monopoly chez McDonald's ou essayé d'inventer une nouvelle saveur de Walkers Crisps, alors vous avez vu une partie de son travail. Cet article est tiré du discours Keeping Change Human donné par Overall à Stretch Online 2020. Stretch Online 2020.