Expliquer un concept avant de le nommer

Au fil des années, j’ai appris à expliquer un concept avant de le nommer.

Partir d’un problème, décrire les différentes solutions envisagées, leurs avantages et inconvénients. Ce n’est qu’une fois que l’équipe a compris et adhéré à l’approche que l’on peut nommer cette dernière. Mais pourquoi fonctionner ainsi ?

Car derrière chaque pratique se cache des « buzzwords ». De mon expérience, ces derniers sont généralement perçus négativement, indépendamment de ce que les pratiques associées peuvent apporter (ou non). Entendre des termes « marketing » ou popularisés peut entrainer biais et préjugés, mais peuvent aussi générer des prises de décisions précipitées et sans réelles réflexion.

Par exemple, dans une équipe précédente, nous avions des problèmes de couplage fort entre les différentes couches de code d’un projet. Nous avons donc réfléchi aux différentes solutions possibles. Nous avons commencé à modifier l’architecture du projet. Séparer le fonctionnement de l’application, des règles à appliquer sans dépendre du framework que nous utilisions.

Le résultat ? Une architecture projet qui avait une adhésion naturelle de l’équipe. Chacun avait le « pourquoi » avant de connaitre le « comment ». Le nom de cette architecture: l’architecture hexagonale. Pourtant, nombreux sont les membres de l’équipe qui voyaient cette dernière comme inutilement complexe et sans intérêt.

Les buzzwords ne sont pas forcément le problème. Ils le deviennent quand ils biaisent la réflexion et qu’ils servent d’arguments d’autorité plutôt que de support à la conversation. Expliquer avant de nommer c’est comprendre ce qu’on souhaite mettre en place plutôt que de réagir sur la forme.

Et, comme j’aime souvent à le dire: « il est essentiel de comprendre les différents outils et pratiques, savoir pourquoi ils ont été créés » afin d’être en mesure de les challenger. C’est ainsi que l’on peut juger de leur bien-fondé dans une situation donnée.