Comment convaincre votre patron et vos collègues développeurs que vous avez raison (et ils ont tort).

En tant que développeur, j’ai découvert des habitudes et des bonnes pratiques non négociables au fil des ans. Mais parfois, j'ai dû travailler avec des personnes qui n'étaient pas sur la même longueur d'onde que moi. La plupart du temps, c’est la direction.

Vous ne pouvez convaincre personne de rien. Vous ne pouvez leur donner que la bonne information, afin qu'ils se convainquent.
- Eben Pegan

La raison principale est généralement que nous examinons différemment les problèmes et leurs solutions. Nous savons par expérience que les moindres problèmes nous seront communiqués sous forme de dette technique ou simplement de frustration.

J'écris cet article pour vous montrer comment vous pouvez changer l'opinion de votre responsable, voire de celle de votre pair.

Communiquer correctement

Votre message peut être très important, mais si vous ne le livrez pas, c’est votre faute. Voici un moyen de transmettre efficacement votre message:

«Pour communiquer efficacement, nous devons atteindre les gens par leur tendance, pas la nôtre»
-Gretchen Rubin

Comme vous le savez, les gens ne sont pas les mêmes. Il peut être facile de raisonner quelqu'un, et quelqu'un d'autre peut être têtu. Selon Gretchen Rubin, nous pouvons classer les personnes en quatre tendances principales.

Gretchen a écrit un livre intitulé Les quatre tendances. Elle a remarqué cette division entre les gens et comment nous pouvons les utiliser et en tirer parti dans nos vies. Ces tendances sont Upholder, Obliger, Questioner et Rebel.

Voici une blague rapide qui aide à les décrire:

Comment obtenez-vous un Upholder pour changer une ampoule?
Réponse: il l'a déjà changé.

Comment obtenez-vous un questionneur pour changer une ampoule?
Réponse: Pourquoi avons-nous besoin de cette ampoule de toute façon?

Comment obtenez-vous un obligé pour changer une ampoule?
Réponse: demandez-lui de le changer.

Comment obtenez-vous un Rebel pour changer une ampoule?
Réponse: Faites-le vous-même.

Une étude de cas

Supposons que vous avez un produit propriétaire (PO) sur un nouveau projet. Le bon de commande ne se concentre que sur ce que vous livrez. Ils ne veulent pas que vous passiez du temps sur autre chose, comme écrire des tests.

Voici quatre façons différentes de convaincre votre ordre que l’écriture de tests est importante. Mais n’oubliez pas qu’il ne s’agit que d’un exemple - vous devriez pouvoir utiliser ces frameworks dans n’importe quel contexte.

Et c'est parti.

1. Un bon de commande

Selon Gretchen,

Les questionneurs aiment la recherche, trouver des efficiences et éliminer les processus irrationnels. Ils rejettent les explications paresseuses comme ceci:
"C’est ce que nous avons toujours fait."
Parce que les interrogés ont une grande confiance en leur analyse et leur jugement, ils peuvent être convaincus de la justesse de leurs points de vue et refuser d'être persuadés du contraire.

Lorsque vous traitez avec un questionneur, amenez le raisonnement à la table. Avoir un argument valable soutenu par des preuves.

Voici un exemple de conversation avec un bon de commande nommé Alex:

Moi: Bonjour Alex, pouvons-nous parler des meilleures pratiques pour un moment?

Alex: Bien sûr, qu’avez-vous à l’esprit?
 
Moi: Je pense que nous mettons trop d’efforts pour fournir les fonctionnalités sans penser à notre dette technique. Nous n’avons pas beaucoup de temps pour les tests.

Alex: Eh bien, je ne suis pas convaincu que consacrer beaucoup de temps aux tests nous aidera à fournir des résultats meilleurs et plus rapides. Nous corrigeons les bugs au fur et à mesure et cela semble fonctionner.
 
Moi: J'ai regardé combien de temps nous passions en corrigeant les bugs, et le nombre augmente avec le temps. J'ai travaillé sur beaucoup de projets similaires. Au début, il est plus rapide d’ignorer les tests, mais vous allez arriver à un point où cela n’est plus efficace. Je pense que nous sommes maintenant à ce point.
 
Alex: Hmm mais je ne veux pas embaucher une autre personne pour faire les tests, nous n’avons pas de budget pour cela.

Moi: j’ai une solution: ajoutons des tests à la portée de chaque ticket. Cela rendra les développeurs heureux et vous pourrez comparer la vitesse. Si vous souhaitez en savoir plus, j'ai quelques exemples de livres et d'articles sur l'importance des tests.
 
Alex: Ok, rappelez-le-moi lors de notre prochain planning de sprint, et je veillerai à ce que tout le monde soit sur la même page.

Moi: merci

2. Un bon de commande

Les tenants peuvent faire d'excellents collègues. Ils sont autonomes et ils sont très intéressés par la performance. Mais les défenseurs deviennent parfois impatients lorsque d’autres luttent pour répondre aux attentes.

Je ne pense pas que vous deviez convaincre un Upholder de l’importance d’écrire des tests. Ils réagiraient comme ceci:

Moi: Bonjour Alex, je pense que nous sommes sur le point de passer plus de temps à écrire des tests. Notre dette technique augmente.
 
Alex: Je suis d'accord avec ça. N'hésitez pas à écrire plus de tests et à faire du refactoring. Mais assurez-vous que nous proposons toujours les fonctionnalités promises.

3. PO comme Obliger

Les obligés répondent aux attentes que les situations de travail suscitent presque inévitablement - avec des délais, des évaluations et des livrables.

Donc, pour les convaincre, nous pouvons utiliser un autre facteur de motivation qu’ils suivent.

Moi: Bonjour Alex, je pense que nous sommes sur le point de passer plus de temps à écrire des tests. Notre dette technique augmente.

Alex: Nous avons une date limite à traiter - est-ce que ça va l'affecter?
 
Moi: Nous pourrions être retardés dans le prochain sprint. Mais en écrivant plus de tests, nous pourrons réduire le temps de développement. Nous devrions donc être plus rapides à la prochaine étape et respecter facilement le prochain délai. L'écriture de tests est également une meilleure pratique de développement. Je peux vous montrer un tas d’études qui le soutiennent si cela vous intéresse.

4. Un PO rebelle

Je me sens un peu machiavélique à propos de celui-ci. Voici un exemple tiré du livre:

Un enfant rebelle pourrait mieux répondre si vous lui demandiez: "Avez-vous l’impression de jouer du piano maintenant?" Alors qu’un enfant Upholder serait heureux d’être rappelé, "Il est temps de pratiquer le piano".

Donc, si je voulais convaincre un propriétaire de produit Rebel de faire des tests, je ne sais pas trop ce que je ferais. Je passerais probablement du temps à faire des tests et à refactoriser le code sans me le demander.

Gretchen note qu’ils «attachent une grande importance à la liberté, au choix, à l’identité et à l’expression de soi». Ainsi, en réagissant de mon côté et en prenant soin de certaines choses, j’entrerais dans cette spécification. Je serais le rebelle!

En fin de compte, vous devez savoir qui est votre public. Vous devriez découvrir quelles sont les priorités de votre projet. Rendez ensuite votre argument plus convaincant en mentionnant ces priorités.