Dire poliment à un volontaire incompétent d'un projet logiciel qu'il est trop inexpérimenté

Il suffit de leur dire que la partie du projet qu'ils peuvent aider de manière réaliste est maintenant terminée (puisqu'elle l'est, c'est tout à fait vrai) et que vous les recontacterez si quelque chose d'autre se présente pour lequel ils peuvent aider. Cela présente des avantages clés :

• Vous ne brûlez aucun pont.
• Cela peut inciter le développeur junior à en apprendre davantage afin d'acquérir des compétences plus pertinentes pour le projet.
• Vous ne les renvoyez pas ou n'insinuez pas du tout qu'ils sont incompétents.
• C'est normal pour les projets collaboratifs de temps libre. A un moment donné, les choses qu'une personne sans certaines compétences peut faire prennent fin.

En utilisant cette stratégie, vous évitez complètement le problème de devoir les “virer” du tout.

Alternativement, vous pouvez les réaffecter à des tâches qui doivent être faites mais qui n'ont pas besoin d'un développeur pour les faire, ou à des tâches qui sont secondaires (c'est bien). En général, cela comprend :

• Rédaction de documents
• Révision de code
• Tests approfondis de Q/A

Soyez à l'affût des tâches qui ne vous coûtent rien si elles sont mal faites mais qui aident beaucoup lorsqu'elles sont accomplies avec enthousiasme.

Je ne suis pas sûr qu'il faille les virer entièrement du projet, vous pourriez aussi les placer dans une position où ils ne bloquent pas les autres personnes (y compris vous).

Tout d'abord, il semble que le principal problème pour vous soit le coaching - alors réduisez le coaching. Vous pourriez dire quelque chose comme :

Hé Bob, il se passe beaucoup de choses dans ma vie en ce moment et je ne trouve tout simplement plus le temps pour nos sessions de formation [ou quel que soit le nom que vous leur donnez], désolé.

Ensuite, déplacez-les “hors du chemin” en leur assignant une ou deux tâches simples avec une priorité non urgente. S'ils peuvent apprendre et accomplir la tâche par eux-mêmes : génial, donnez-leur quelque chose de plus difficile et répétez jusqu'à ce que vous ayez trouvé leur niveau de compétence. Sinon, revenez vers eux lorsque la tâche est devenue plus prioritaire (lorsqu'elle sera bientôt nécessaire). Si vous voulez faire preuve de diplomatie, vous pourriez alors dire :

Hé Bob, nous avons besoin de la documentation / des traductions / des tests exécutés / pour bientôt. Pourriez-vous vous en occuper et je prendrai le relais sur le défroisseur en attendant ?

Cela aide vraiment si vous pouvez vous convaincre que la documentation et les tests sont des tâches importantes - parce qu'elles sont. Beaucoup de développeurs ne veulent pas écrire de documentation et cela scelle le sort de nombreux petits projets de logiciels libres : leur logiciel résout certains problèmes mais la plupart des gens ne savent pas comment l'utiliser, donc personne ne l'utilise.

Enfin : vous mentionnez “Je n'ai jamais travaillé avec d'autres développeurs auparavant” et je ne vois pas très bien comment vous organisez le travail dans votre projet. L'organisation du développement de logiciels est un ensemble de compétences très précieux, vous voudrez donc peut-être profiter de cette occasion pour apprendre et vous développer. Apprenez à décomposer le travail en tâches et sous-tâches, à comprendre les dépendances, à estimer le temps nécessaire, à établir des priorités entre ce qui est important et ce qui peut attendre, à évaluer qui peut faire quoi. Apprenez à communiquer au mieux avec vos collègues développeurs et à planifier à nouveau lorsque les choses ne se passent pas comme vous l'aviez prévu. Utilisez les outils de collaboration (issue tracker, système de versionnement, etc.).

Peut-être que les méthodologies en vogue dans le monde des affaires en ce moment (Scrum, Kanban, etc.) vous donneront des indications utiles.

Tout d'abord, je suis d'accord avec la partie qui consiste à remercier le volontaire pour le temps et les efforts qu'il a consacrés jusqu'à présent, et à dire que la partie du développement primaire pour laquelle vous aviez besoin de lui est terminée.

Puis-je vous recommander, dans votre intérêt à tous les deux, d'investir dans une session de tutorat supplémentaire. Le sujet : montrer à son mauvais moi comment écrire des tests unitaires. Ensuite, dites-lui que s'il veut faire plus d'aide technologique (par opposition à d'autres types d'aide), il devrait commencer à développer l'écurie de DeepL. Les avantages :

• Vous obtenez des tests unitaires !

• Le volontaire est initié à la nature importante des tests unitaires !

• Si le volontaire est lent ou bloqué, cela n'interfère pas avec le développement principal

Ensuite, comme pour les autres réponses, vous pouvez demander plus de formation, car vous avez perdu du mou dans votre emploi du temps.

Comme ils sont volontaires, je ne pense pas qu'il soit nécessaire de les “virer” du tout, car une formulation comme celle-là semblerait assez grossière. Il serait peut-être plus approprié de dire que le travail bénévole pour lequel vous avez besoin d'eux est terminé pour l'instant. Aussi, assurez-vous de les remercier gentiment pour le travail qu'ils ont déjà accompli, commentez leur succès et leur croissance personnelle, mais ne leur donnez pas de nouvelles tâches.

Cela fonctionne particulièrement pour les volontaires car ils n'ont jamais été employés techniquement, n'aidant que là où ils étaient nécessaires et si vous pouvez le formuler de manière à montrer qu'ils ont réussi à accomplir leur tâche, alors le fait de ne plus recevoir de tâches devrait être accueilli avec des sentiments positifs plutôt que négatifs.

Merci beaucoup {nom}, {X} une partie du projet est en place et fonctionne bien ! Vous avez fait tout ce dont j'avais besoin, mais si vous êtes d'accord, je pourrais vous demander de faire un peu plus de travail à l'avenir…

Demander si vous êtes d'accord pour quelque chose qu'ils aimeraient, c'est très pratique car cela permet de garder le pont métaphorique que vous avez mentionné, cela les met d'accord avec vous, cela leur donne des options et, quel que soit leur choix, vous atteignez votre objectif de les empêcher de travailler sur le projet actuel et c'est poli.

Malheureusement, cela ne fonctionnera pas dans tous les cas et je ne connais pas les détails de votre projet / ce qui lui a été assigné. Si vous devez choisir entre être un peu plus franc ou mentir, être franc vous aidera probablement à long terme (cela ne veut pas dire que vous devez vous concentrer sur le mauvais !).

Vous nous avez aidés et vous vous êtes beaucoup améliorés, mais je pense qu'il serait préférable que {d'autres} et moi achevions les tâches restantes.

et

Si quelque chose de mieux adapté à vos compétences se présente à l'avenir, je ne manquerai pas de vous l'envoyer.

Pourrait être plus approprié dans certains cas.

Ma lecture de cette situation est… disons un peu cynique. On conseille constamment aux nouveaux développeurs d'obtenir leur nom sur les demandes d'emploi afin de renforcer leur crédibilité auprès des employeurs potentiels. Sur d'autres sites, on conseille constamment aux nouveaux développeurs de rejoindre un projet open source afin d'acquérir de l'expérience. Cette expérience se fait au prix du temps passé à encadrer les développeurs plus expérimentés sur ces projets.

Bien que oui, les développeurs débutants abandonnent leur temps libre - je ne le vois pas comme tel. Il s'agit d'un jeune développeur qui bénéficie d'un mentorat gratuit et qui reprend la construction au détriment d'un projet bénévole que vous dirigez. (À mon avis) le coût du mentorat dans le cadre d'un projet de volontariat vaut rarement le temps, à moins que la personne ne soit engagée dans le projet et n'y ait un intérêt réel au-delà du crédit GitHub.

Il y a deux voies à envisager.

Mentoriser le junior dev. Vous continuerez à superviser chaque engagement et à vous assurer que le matériel soumis est conforme à vos normes pour le projet. Votre rôle principal est celui d'un mentor qui s'assure que votre projet et les engagements du jeune développeur sont conformes à vos attentes.

Ne conseillez pas le jeune développeur. Votre temps de bénévolat pour travailler sur votre projet est tout aussi précieux, sinon plus, que son temps. Il est probable que de nombreuses personnes ferment boutique pour se préparer à dire “c'est fait” et à passer à un autre projet. Il s'agit souvent de tâches fastidieuses et ennuyeuses, mais elles doivent tout de même être accomplies. Des choses telles que : - documentation - demandez à une autre personne de lire tout le texte écrit et assurez-vous qu'il est correctement orthographié, ponctué, grammatical, formaté, etc. - nettoyage du style - prenez votre linter préféré et faites-y passer le code selon le style que vous voulez. Enregistrez tous les éléments de nettoyage de style comme problème par fichier à nettoyer. - écriture de test - travaillez sur l'amélioration de la couverture du code. Il y a toujours des tests à écrire.

Réalisez et rappelez-vous que s'il y a une tâche qui vous prendra 4h pour la faire vous-même, ou 3h de votre temps et 8h du temps du junior dev, il n'y a pas beaucoup de sens commercial/temporel à faire faire par le junior dev à moins que vous ne preniez en compte la valeur de l'expérience du junior dev.

Examinez ce que chaque personne (vous et le junior dev) obtient de l'arrangement. Vous êtes tous deux volontaires. Si un volontaire n'a rien à faire, c'est pas grave.

Soyez franc et honnête et exposez les faits tels que vous les avez présentés ici :

• Avec le recul, vous constatez que l'aide dont ils ont besoin prend beaucoup de temps. Cela a commencé à entraver votre propre capacité à travailler sur le projet.
• Vous êtes en train de mettre fin au projet. Vous approchez d'un point où vous ne travaillerez plus sur le projet. Faites-en connaître les raisons. (Par exemple, il est peut-être remplacé par un nouveau projet bénéficiant d'un meilleur soutien/financement ou il ne reste tout simplement plus beaucoup de travail à faire).
• Remerciez-les pour tous les efforts qu'ils ont consacrés à ce projet et dites-leur que vous espérez que l'expérience a été utile pour développer leurs capacités.
• Proposez éventuellement de les aider à trouver un autre projet dans lequel ils pourront continuer à faire du travail de développement, peut-être un autre projet correspondant à leur niveau de compétence actuel.

Sachez qu'ils pourraient répondre en demandant s'ils peuvent continuer à travailler sans une supervision aussi étroite. Si c'est possible, vous pouvez envisager d'adopter une approche plus distante et de ne revoir leur travail que lorsqu'il est fini (par exemple, en tant que demande de retrait). C'est à vous de décider si c'est viable. Si vous pouvez trouver un petit changement à mettre en œuvre, vous pourriez l'envisager. Si vous l'essayez et que cela ne se passe pas bien, vous pouvez leur montrer précisément ce qui ne va pas dans leur travail, et vous devrez peut-être revenir sur cette discussion concernant le manque de temps et la fin du projet.

Choses à ne pas dire :

• Vous les renvoyez.
• Vous n'appréciez plus le projet à cause d'eux.
• Ils sont incompétents ou tout autre chose concernant leur capacité innée.

Parfois, il vaut mieux ne pas dire tout ce que vous pensez et ressentez. Non pas parce que vous êtes malhonnête, mais parce que vous savez que vos sentiments et vos pensées ne sont pas totalement objectifs. Nos jugements sont parfois obscurcis par nos désirs insatisfaits, alors parfois nous nous taisons sur des pensées et des sentiments que nous savons ne pas être vraiment valables.

Oui, il y a un risque inhérent que vous puissiez blesser leurs sentiments. Toute approche ici comporte des risques. Ne rien faire risque de vous rendre frustré et de vous libérer de manière non constructive, et mentir ou embrouiller la vérité risque de faire découvrir à l'autre personne ce qui s'est réellement passé. Être honnête a la vertu de faire confiance à l'autre personne pour évaluer la situation par elle-même et en arriver à voir les choses comme vous le faites. La personne peut voir que vous n'êtes pas injuste et que vous essayez d'aborder la situation de manière objective. Si elle ne comprend pas votre point de vue, il est normal d'en parler avec elle et de lui expliquer ; ce n'est pas vraiment possible si vous n'êtes pas franc.

Si vous sentez que l'autre personne commence à douter que votre amitié va se poursuivre, dites-lui clairement que vous voulez la poursuivre. La manière de le faire dépasse le cadre de cette question, car elle dépend de la manière dont l'autre personne réagit.