Technology Management & Leadership

Il y a de cela quelques mois, je naviguais sur un petit site Flash qui se vantait de pouvoir deviner mes pensées. Assoiffé de mystères à élucider, me voilà qui pense à un nombre, suis les instructions et surprise! Le symbole associé au nombre auquel j’ai pensé est affiché, auréolé d’étoiles.

Première pensée: Ils devinent avec les mouvements des comportements de ma souris.
Mais je continue à réfléchir, et après quelques microsecondes je ris de moi-même. Je recommence donc l’exercice, sans bouger la souris, et comme je m’y attendais ça fonctionne quand même.

Le truc est simple; il fallait choisir un chiffre entre zéro et cent. Une table à droite montrait des symboles à côté de chaque nombre. Il fallait additionner les deux chiffres du nombre, et soustraire ce résultat au nombre choisi. Par exemple, si on prend 75: 7+5=12, 75-12=63. Mais reprenons le calcul avec un autre chiffre, 72: 7+2=9, 72-9=63. Ah ha! On se rend compte que peu importe le chiffre qu’on choisit, ce sont toujours les mêmes quelques résultats qui reviennent. Il s’agit simplement de mettre le tout en forme, en mettant des symboles différents à chaque fois, tant que les mêmes nombres (63, 72, 81…) donnés aient le même symbole.

Après avoir envoyé ce petit truc à quelques amis, j’ai été étonné du retour. Première réponse que je reçois par messagerie instantanée: “Facile, ça détecte le mouvement de la souris.”

Ces gens savaient pertinemment que ce n’était pas le cas. Et s’ils doutaient, valider leurs doutes ne leur aurait pris qu’une seconde. Mais ce n’est pas ce qu’ils ont fait. Alors me voilà qui réfléchis. Pourquoi ce comportement? Il ne s’agit pas que de paresse. Il s’agit de comment nous traitons les acquis.

J’ai mes théories. Chaque jour des centaines de faits viennent à notre attention. Nous ne doutons pas de la justesse de notre perception de ceux-ci à chaque fois, c’est un comportement qui me semble tout à fait normal… lorsque nous n’avons pas à prendre une décision basée sur ces acquis. Si on fait le parallèle avec la programmation, combien de fois on appelle une méthode qu’on ne connaît pas en ne se basant que sur sa signature? Qu’on corrige un bogue avant même d’essayer de le reproduire? Un classique qui me hante personnellement est lorsqu’on m’explique quelque chose et qu’une conception logicielle se dessine dans ma tête. Lorsque des informations viennent la contredire, plutôt que de simplement l’ajouter à ma compréhension du problème, j’ajuste instinctivement ma première idée en conservant ses fondements. Éventuellement celle-ci n’est plus du tout adaptée au problème, mais je suis quand même convaincu qu’elle l’est.

Mais que faire? Peut-on se débarrasser de ce problème?

Je ne crois pas, non. Mais tout espoir n’est pas perdu! On peut certainement alléger les effets de ce réflexe naturel. Je ne suis pas psychologue, mais j’ai développé quelques trucs que vous pourrez mettre en pratique lorsque vous êtes dans une situation où une solution piétinne la problématique encore immature.

Première étape, définir les moments où les préconceptions causent problème. Ils ont un point en commun; ils commencent par une écoute ou une lecture d’un problème, font fait germer des idées dans votre esprit pendant un échange qui dure aux moins quelques minutes et se terminent par une responsabilité partielle ou complète de votre part pour revenir avec une solution.

Deuxième étape, identifier les préconceptions elles-mêmes. Si on y porte attention, c’est assez facile. Dès que vous avez une conception de la solution en tête avant que la problématique soit complète, vous prenez quelque chose pour acquis.

Troisième étape, se débarrasser du fardeau de l’idée. J’ai personnellement une mauvaise tendance à croire qu’une bonne idée ne doit pas se perdre, mais pensez-y; si la description du problème a donné naissance à un concept, pourquoi prenons nous tout le mérite? Après tout, sans problèmes il n’y aurait pas de vos solutions géniales! Bref, ayez confiance en vos aptitudes et ne vous accrochez pas aux bonnes idées. Il est bon de les noter, mais oubliez les détails. Liez les toujours au problème qui vous a inspiré. Si vous n’arrivez toujours pas à vous débarrasser de l’idée, qu’elle pousse malgré vous, demandez à vos interlocuteurs de faire une pause. Prenez quelques secondes pour y penser, établissez ensuite les raisons pour lesquelles vous avez eu cette idée. Finalement, validez avec les autres personnes si votre raisonnement est bon. Ne divulguez pas l’idée elle-même, car la discussion aurait de fortes chances de tomber sur l’implémentation, et le but est justement d’éviter cette chute. Par exemple, prenez cette situation:

Jules, l’analyste principal du projet, présente à l’équipe de développement les spécifications du système.

– L’utilisateur pourra donc entrer un numéro, énonce Jules, qui correspondra au code du système ABC. Il est important que l’étiquette liée au code soit affichée lorsqu’il valide le code. Il pourra ensuite continuer à remplir le formulaire.

Marc, un des développeurs de l’équipe, perd immédiatement son attention. Il se rappelle d’un article qu’il a lu au sujet des plug-ins. Mais voilà une occasion en or d’implanter ses connaissances! Son raisonnement va comme suit : De cette manière, si on doit changer le système ABC, ou même ajouter d’autres codes, ça sera facile comme tout! Mais Marc ne se laisse pas avoir, et réfléchis aux raisons qu’il l’ont amené à cette conclusion. Premièrement, un système externe est en jeu. Celui-ci peut changer. Ensuite, il s’agit d’une question ordinaire dans un formulaire qui pourrait très bien contenir d’autres cas où les données requises sont reliées à une logique externe au formulaire lui-même. Il pose donc ces questions:

– J’aimerais avoir des précisions. Il s’agit d’une question ordinaire? Est-ce que le système ABC est sous le contrôle de notre client? Finalement, est-ce qu’on prévoit d’autres cas où on devra communiquer avec un autre système?

Les réponses de Jules pourraient être variées. Peut-être que le système ABC est en réalité la base de données que vous devrez utiliser. Peut-être qu’après avoir appris qu’il s’agit d’un webservice déjà implémenté chez le client, vous ferez simplement une question configurée pour appeler un webservice. Peut-être vous rendrez-vous compte que votre idée s’applique toujours, mais dans tous les cas vous aurez les informations nécessaires pour passer à autre chose.

Quatrième étape, prendre du recul. Revenez de temps à autres sur toutes les informations que vous avez et imaginez-vous repartir de zéro. Révisez vos informations dans le désordre. Contredisez-vous, et obligez-vous à accepter qu’une solution ne sera valide que lorsque vous aurez toute l’information en main.

Mais vous n’aurez jamais toute l’information en main. Bienvenue dans le paradoxe de la conception logicielle!