Bonjour,Vous avez probablement reçu un lien vers ce site web parce que vous avez commis l'une des erreurs courantes du travail à distance :
- Vous avez entamé une conversation en écrivant "Salut", ou "Bonjour", ou même peut-être "Bonjour Sebastien, j'ai une question". Puis vous avez attendu. Et attendu. Et attendu pendant des minutes (ou des heures si j'étais occupé et que vous étiez patient) sans un seul mot pour expliquer le problème auquel vous étiez confronté.
- Vous m'avez demandé un "appel rapide" (ou peut-être simplement un "appel"
sans expliquer de quoi vous vouliez parler dans l'espoir que je laisse tout tomber et que je me mette immédiatement à vous aider. - Vous m'avez invité à une réunion sans description ni ordre du jour.
Ne vous inquiétez pas, je ne vous en veux pas. Ce sont des erreurs courantes que les gens commettent lorsqu'ils travaillent à distance. Peut-être travaillez-vous dans un environnement où la productivité est faible, de sorte que tout le monde a le temps de passer un appel rapide ou de discuter avec vous chaque fois que vous le demandez. Ou peut-être êtes-vous un manager et personne n'a le courage d'expliquer que toutes ces interruptions sont néfastes et de vous montrer comment les rendre un peu moins néfastes. Il y a une autre possibilité : vous êtes paresseux et égoïste, et vous ne vous souciez pas de l'impact de vos interruptions sur les autres parce que vous avez besoin d'une réponse immédiate à vos questions avec un minimum d'effort de votre part. Mais je suis sûr que ce n'est pas le cas. Nous sommes tous des personnes aimables et travailleuses qui se soucient beaucoup des membres de leur équipe, et nous avons parfois besoin d'un peu d'aide supplémentaire.
Permettez-moi de vous expliquer pourquoi ces trois erreurs en matière de travail à distance sont mauvaises, comment vous pouvez faire mieux et pourquoi il est bon pour vous de les éviter à l'avenir.
Pas de "Bonjour"
Cette erreur est tellement courante qu'il existe déjà un magnifique site web nohello.net qui explique pourquoi il vaut mieux poser sa question directement plutôt que de commencer par "Bonjour" et d'attendre une réponse avant de poser la question proprement dite. Je ne vais pas répéter ce que dit le site, mais l'essentiel est que si vous écrivez votre question tout de suite, vous obtiendrez une réponse beaucoup plus rapidement. Il n'est vraiment pas nécessaire d'attendre que je vienne vous saluer avant de commencer à écrire votre problème. D'autant plus qu'il se peut que je sois à nouveau occupé et que le temps d'attente s'allonge.
Mais le problème du "Bonjour" ne se limite pas à cela, surtout si vous voulez demander une assistance technique.
Permettez-moi de vous montrer différentes façons de poser une question sur le même sujet, en allant de la pire à la meilleure. Supposons que j'aie ajouté un nouvel argument à une fonction appelée frobnicate, mais que j'aie oublié de mettre à jour l'utilisation de cette fonction à tous les endroits du code. Vous êtes maintenant confronté à un problème causé par cet oubli et vous décidez de demander de l'aide :
- "Bonjour", "Salut", ou même "Bonjour, j'ai une question". C'est la pire façon d'entamer une conversation lorsque vous avez un problème. Je n'ai aucune idée de ce que vous voulez ou de l'urgence de la situation. Et vous attendez que je sois autour de mon clavier pour répondre à "Bonjour" avant d'avoir l'occasion d'expliquer votre problème.
- "Bonjour, la fonction frobnicate ne fonctionne pas". Ok, au moins nous avons un peu de contexte sur le sujet de notre conversation. Mais je n'ai toujours aucune idée de ce que vous entendez par "ne fonctionne pas". La fonction génère-t-elle une erreur ou ne fonctionne-t-elle pas comme prévu ? Est-ce que cela se produit sur votre ordinateur, ou est-ce qu'elle a cessé de fonctionner en production, et l'entreprise perd des millions chaque minute ?
- "Bonjour, j'ai essayé d'exécuter la fonction frobnicate dans l'environnement staging, mais elle affiche Error : missing argument 'count'. Je suis sur la branche de code 'feature-123'". Super, on y est presque. Je sais quelle fonction vous appelez, dans quel contexte, et quelle erreur vous obtenez. Mais nous pouvons encore faire mieux.
- Il existe une autre version très trompeuse de cette question qui peut nous mettre tous les deux sur la voie du débogage d'un mauvais problème. Comparez la version précédente avec la suivante : "Bonjour, j'ai essayé d'exécuter la fonction frobnicate dans l'environnement staging, mais il y a une erreur à propos de l'argument count. Je suis sur la branche de code 'feature-123'". Imaginez maintenant que vous ayez simplement mal orthographié le mot "count" dans votre fonction, ce que je remarquerais immédiatement si je voyais l'erreur complète. Mais je n'ai pas vu l'erreur complète et j'ai supposé à tort que le problème venait de la fonction frobnicate elle-même. Nous nous lançons donc tous les deux dans une aventure complètement inutile consistant à modifier des parties aléatoires du code et à nous gratter la tête pour savoir pourquoi rien ne fait disparaître l'erreur. Je finis par perdre des heures à cause d'une faute de frappe. C'est pourquoi je recommande fortement d'inclure la trace de la pile dans votre message (et pas seulement la dernière erreur, mais toute la trace de la pile, car la partie cruciale se trouve souvent quelque part au milieu). Ou au moins de coller le message d'erreur exact au lieu d'essayer de décrire avec vos mots ce que vous pensez ne pas fonctionner.
- "Bonjour, j'ai essayé d'exécuter la fonction frobnicate dans l'environnement staging, mais je reçois Error : missing argument 'count'. Je suis sur la branche 'feature-123'. J'ai comparé avec l'environnement de production, et cela fonctionne. J'ai également récupéré les derniers changements de Steve. Voici la trace de pile complète : (...)". C'est l'exemple parfait d'une demande d'aide en ligne. Non seulement il donne le message d'erreur exact et le contexte dans lequel il se produit, mais il explique également ce que vous avez essayé jusqu'à présent, ce qui me permet d'éviter de vous donner des conseils tels que "Comparez avec l'environnement de production" ou "Avez-vous récupéré le dernier code ?" parce que je sais que vous avez déjà essayé. Honnêtement, cette demande est tellement bonne et concrète que je ferai probablement l'effort supplémentaire d'au moins réfléchir à la solution possible, même si je suis en train de faire quelque chose d'autre.
Pas d'"Appel rapide"
Il s'agit d'un problème très similaire à celui de "Bonjour", sauf que vous voulez maintenant passer d'une méthode asynchrone de résolution du problème à une méthode synchrone. Et comme pour le "Bonjour", le fait de demander un "Appel rapide" pose quelques problèmes :
- Un appel est plus distrayant qu'un message de chat. Je peux répondre à un ou deux messages simples dans un chat sans perdre le contexte de ce sur quoi je suis en train de travailler. En revanche, pour les appels, je dois me concentrer davantage, et il me faut donc beaucoup plus de temps pour récupérer. Vous pouvez penser que vous avez pris 30 secondes de mon temps, mais c'est toujours plus.
- Parfois, un message suffit. Certains appels sont équivalents à l'échange de quelques messages sur le chat. Félicitations, vous venez de vous épargner 10 secondes de rédaction de votre question.
- Parler (ou plutôt écrire) votre problème peut vous aider à le résoudre. Le débogage à l'aide d'un canard en caoutchouc fonctionne vraiment. J'ai été témoin d'innombrables cas où, après avoir expliqué le problème, le message a été supprimé ou suivi d'un "peu importe" parce que mon interlocuteur avait trouvé comment résoudre le problème.
- Les appels sont éphémères. Les messages écrits sont éternels. Du moins jusqu'à ce que les serveurs tombent en panne ou que l'entreprise qui héberge votre application de chat préférée fasse faillite. Mais ce qu'il y a de mieux avec les mots écrits, c'est que vous pouvez toujours revenir plus tard et retrouver cette conversation, vous rappelant comment résoudre un problème spécifique ou pourquoi vous avez décidé de le résoudre d'une manière spécifique.
Ainsi, lorsque je réponds à votre "Appel rapide ?" par "Quel est le problème ?", c'est vraiment pour votre bien 😉 . Je veux que vous réfléchissiez au problème et que vous ayez une réponse écrite pour l'avenir sans me distraire complètement de mon travail.
Une grande partie de ce que j'ai écrit sur l'"Appel rapide" peut également s'appliquer au dernier cavalier de la perte de temps dans un environnement distant qui va suivre. Toutefois, cette métaphore n'a pas beaucoup de sens s'il n'y a que trois cavaliers. Vous voulez m'aider à trouver le quatrième cavalier ? Laissez un commentaire sur les autres façons de perdre le temps des gens qui méritent ce titre.
Réunions "sans ordre du jour"
Vous est-il déjà arrivé d'être invité à une réunion et de n'avoir aucune idée de son contenu jusqu'à ce que vous y participiez ? Ahh, oui, les réunions "sans ordre du jour" ou, comme j'aime à les appeler, les "réunions surprises". Apparemment, pour certaines personnes, perdre le temps d'une seule personne n'est pas suffisant, alors elles invitent plusieurs personnes "au cas où on aurait besoin d'elles". Et qui a besoin d'un ordre du jour lorsque tous les points de discussion sont stockés en toute sécurité dans votre tête ?
J'essaie d'appliquer la règle "pas d'ordre du jour, pas de présence" (ce qui signifie que j'essaie de refuser les réunions sans ordre du jour). Si cette règle me convient, je ne pense pas que d'autres puissent se trouver dans une situation aussi confortable et avoir des responsables aussi compréhensifs.
L'existence d'un ordre du jour ou au moins d'une description détaillée présente tellement d'avantages que rien ne justifie les réunions "sans ordre du jour" :
- Si je connais l'ordre du jour à l'avance, je peux me préparer à la réunion. Si je dois vérifier quelque chose ou me rafraîchir la mémoire, je peux le faire à l'avance sans faire perdre de temps à tout le monde. Si nous devons prendre une décision, je peux réfléchir aux options possibles et préparer une liste des avantages et des inconvénients si la décision est difficile à prendre.
- Si je peux répondre à toutes les questions de l'ordre du jour par un message, félicitations, nous venons de faire gagner du temps à tout le monde en évitant une réunion !
- L'ordre du jour donne à la réunion un objectif et une liste de contrôle. Sommes-nous là pour prendre une décision ? Parfait, nous pouvons clore la réunion dès que nous en aurons pris une. Sommes-nous là pour comprendre certains sujets ? Parfait, préparons une liste de contrôle pour nous assurer que nous restons sur la bonne voie et que nous n'oublions rien. Avec un ordre du jour, il est plus facile de voir si nous avons déjà discuté de tout ce qui était nécessaire ou si nous avons atteint l'objectif de la réunion.
- Je peux ainsi voir si ma présence est nécessaire à cette réunion. Parfois, je suis invité à une réunion uniquement parce que je dirige un projet ou une équipe, mais la réunion n'est absolument pas technique et ne requiert aucune contribution de ma part. Il arrive même que je sois invité à une réunion qui n'a rien à voir avec mon projet. Si je connaissais d'emblée le sujet de la réunion, je pourrais l'éviter ou planifier mon temps en conséquence. Par exemple, si je sais que la réunion ne nécessitera probablement pas beaucoup de contributions de ma part, mais que je dois tout de même participer au cas où une question technique serait soulevée, je prévoirai simplement de faire quelques révisions de code pendant que la réunion se déroulera en arrière-plan.
Si vous invitez une personne technique comme moi à une réunion, il est fort probable que vous souhaitiez l'une des trois choses suivantes :
- Vous voulez que je vous explique quelque chose de complètement nouveau. Si je sais d'emblée de quoi il s'agit, je peux vous envoyer un lien vers la documentation correspondante. En général, l'une des deux choses suivantes se produit.
- Vous trouvez toutes les réponses dans la documentation et la réunion n'est plus nécessaire.
- Vous lisez ou survolez la documentation et avez au moins une compréhension de base de ce dont nous allons parler, de sorte que la réunion sera beaucoup plus productive.
- Vous souhaitez poser une question technique spécifique. Il est préférable de la poser par écrit, car je peux réfléchir à ma réponse et faire les recherches nécessaires à mon propre rythme. Je ne vous ferai pas perdre votre temps (et peut-être celui d'autres personnes) pendant la réunion en cherchant la réponse ou en vous donnant une mauvaise réponse parce que vous m'avez pressé et que je n'ai pas eu le temps d'examiner attentivement tous les facteurs.
- Vous voulez me poser une question sur quelque chose que j'ai fait dans le passé. Comme pour le point précédent, j'ai besoin d'un peu de temps pour me rafraîchir la mémoire et me préparer. La technologie est un environnement qui évolue très rapidement. Cette fonction que j'ai créée il y a deux mois ? Entre-temps, j'ai probablement développé trois autres choses, et j'ai complètement oublié comment fonctionne la chose sur laquelle vous voulez me poser une question. Passer 10 minutes seul à préparer la réunion est une approche efficace. C'est mieux que de passer 30 minutes pendant la réunion à parcourir frénétiquement le code, en essayant de me rappeler ce que fait chaque fonction, et de répondre à vos questions pendant ce temps ou de sentir le poids du silence lorsque vous regardez mon écran et toutes les erreurs que je fais en tapant. Sans parler du fait que nous perdrions 30 minutes de temps pour plusieurs personnes.
Le contexte (pas le contenu) est roi
Lorsque l'on travaille à distance, il suffit souvent de quelques touches pour demander de l'aide. Il est donc tentant de demander "rapidement" de l'aide à quelqu'un lorsque l'on est bloqué. Mais contrairement à ce qui se passe dans un bureau, il est difficile de savoir si l'autre personne est occupée et si vous risquez de l'interrompre (à moins qu'elle n'ait réglé le statut "ne pas déranger" dans l'application de messagerie).
Mais pour obtenir la meilleure aide possible, vous devez aussi faire un effort :
- Décrivez le problème auquel vous êtes confronté avec autant de détails que possible.
- Essayez d'expliquer votre problème par écrit avant de prendre un appel.
- Lorsque vous planifiez une réunion, laissez tout le monde se préparer en établissant un ordre du jour clair pour la réunion.
Croyez-moi, cela rendra toutes vos interactions en ligne plus efficaces et vous résoudrez vos problèmes beaucoup plus rapidement. Cela donnera également envie à vos pairs de vous aider au lieu de prendre une grande respiration et de fermer la fenêtre de discussion chaque fois qu'ils recevront un message de votre part du type "Bonjour" ou "Appel rapide".
Source : "No "Hello", No "Quick Call", and no Meetings Without an Agenda"
Et vous ?
Pensez-vous que ces suggestions sont crédibles ou pertinentes ? Quel est votre avis sur le sujet ?Voir aussi :
29 % des professionnels de la sécurité déclarent que leur plus grande frustration est que leurs conseils sont ignorés et qu'ils travaillent dans une culture ou un environnement de sécurité inadéquat Revue de code : un guide en 5 étapes pour que vos collègues vous détestent, par Mensur Durakovic J'aime la programmation informatique, mais je déteste l'industrie de la programmation, par deathbyabstraction Peut-être que la programmation ne vous rend pas malade, c'est tout ce qui vient presque nécessairement avec la programmation pour gagner sa vie 
Envoyé par PomFritz
