Entretien avec un développeur de logiciels : 6 exemples de feedbacks
Les retours d’information concrets sur les performances, souvent sous la forme d‘“évaluations de performances”, jouent un rôle central dans le développement des développeurs de logiciels. Dans cet article, nous montrons quelques exemples pratiques de la manière de donner du feedback aux développeurs de logiciels dans différentes situations, telles que les entretiens avec les employés, les évaluations annuelles des employés ou les évaluations de performances - c’est-à-dire dans toute forme d’entretien individuel et de contact.
L’importance du feedback pour les développeurs de logiciels
Pourquoi le feedback est-il si important (et difficile) pour les développeurs de logiciels ?
Un feedback motivant pour les développeurs de logiciels introvertis
Les développeurs de logiciels sont traditionnellement plus intéressés par le travail avec des détails techniques que par le travail avec d’autres personnes. Pour les cadres, communiquer un feedback de manière efficace et motivante peut donc être un défi, surtout pour les développeurs de logiciels plutôt introvertis*.
En tant que manager de développeurs de logiciels, tu dois cependant apprendre à communiquer les feedbacks positifs et négatifs de manière constructive lors des entretiens d’évaluation, afin que les développeurs de logiciels soient réellement motivés pour mettre en œuvre les potentiels de développement mis en évidence. Les exemples de feedback suivants dans cet article t’aideront à y parvenir.
Si tu souhaites une introduction générale aux réunions régulières en tête-à-tête, n’hésite pas à consulter notre post à ce sujet : Un guide : 6 conseils pour des entretiens 1 à 1 réussis.
Attention : évaluer les développeurs de logiciels individuellement
Pour info : des études montrent que les développeurs de logiciels sont traditionnellement plutôt introvertis. Cependant, la tendance est à la diversification des types de personnalité chez les développeurs de logiciels. Tu dois donc toujours te poser des questions individuelles et évaluer le type de personnalité qui se trouve en face de toi et communiquer en conséquence.
Source : Évolution du profil de personnalité des ingénieurs logiciels
Feedback : Questions et sondages
Questions & un sondage pour les entretiens de feedback
Entretien d’embauche développeur de logiciels : questions typiques
Une remarque avant de te donner de nombreux exemples, modèles et phrases pour ton entretien avec le développeur de logiciel : Bien sûr, dans de nombreuses situations, il est judicieux de mener par des questions afin de vérifier d’abord la compréhension commune du statu quo - pas seulement dans l’industrie informatique.
C’est pourquoi je t’ai préparé quelques questions pour les entretiens d’évaluation avec les développeurs de logiciels :
🎯 Questions individuelles pour les développeurs de logiciels : Focus
- Qu'est-ce qui interrompt ta concentration au travail ?
- Quand as-tu vécu un état de flow au travail pour la dernière fois ? Est-il facile pour toi d'entrer dans le flow ?
- Quand et où as-tu déjà remarqué que tu as dépassé ta limite personnelle de "Work In Progress" ? Que pourrions-nous changer pour t'aider à atteindre un WIP approprié à l'avenir ?
- Comment les contributions orales sont-elles réparties dans votre équipe ? Comment réfléchis-tu à ton rôle dans ce domaine ?
- Qui sont nos clients en tant qu'entreprise et comment ton travail contribue-t-il spécifiquement à répondre aux besoins des clients ?
- Quelles sont les choses que tu aimerais apprendre en pensant à tes collègues dans l'entreprise et au-delà ?
Cela devrait déjà te donner une bonne idée de la manière d’aborder intelligemment un tel entretien d’évaluation. Si tu souhaites également une enquête concrète, je peux également te donner un premier modèle.
Entretien avec un développeur de logiciels : une enquête
Les sondages correspondants peuvent aider à rendre mesurable le développement des employés des développeurs de logiciels au fil du temps.
Mais elles peuvent aussi très bien servir de base interactive pour une discussion commune.
L’enquête suivante se concentre sur quatre domaines différents qui sont importants pour les développeurs de logiciels. En général, ces affirmations sont évaluées sur une échelle de 1 (pas du tout d’accord) à 7 (tout à fait d’accord), par exemple.
🪞Enquête pour l'entretien avec les employés : Pour les développeurs de logiciels
- Je remets en question notre travail en fonction de ma compréhension de nos #TeamZiele et des besoins de nos #Kunden.
- Je contribue de manière proactive à l'amélioration continue de notre équipe. #TeamPlay
- Je connais les défis et les problèmes de nos #Kunden.
- Mes tâches de travail progressent généralement très rapidement, même si un #Feedback externe est nécessaire.
Remarque : Dans ce modèle d'entretien avec les employés, l'accord sur les éléments du bilan de santé (questionnaire) est demandé sur une échelle de 1 à 7.
Dans le logiciel Echometer One-on-One, tu trouveras, comme je l’ai dit, de nombreux modèles qui aident à développer les employés lors des entretiens avec les employés. En particulier pour les équipes agiles, il existe également des modèles partiellement interactifs et visuels. Tu trouveras un exemple simple ici - n’hésite pas à consulter notre outil via le bouton ci-dessous.
Modèle d'entretien individuel du logiciel Echometer
- Jetez un coup d'œil aux domaines indiqués ici. Selon vous, où vous et votre équipe avez-vous le plus grand potentiel d'amélioration ?
Source : logiciel d'entretien individuel Echometer
Comme tu peux le voir grâce au bouton vert, tu peux même utiliser ces modèles gratuitement dans notre outil de réunion 1 à 1 Echometer. Nous avons aussi beaucoup d’autres modèles de questions et des modèles de coaching complets.
Vous trouverez un autre article sur notre blog si vous êtes intéressé par des modèles détaillés pour différents entretiens individuels (par exemple, hebdomadaires, annuels, 1-1 avec des employés difficiles…) : 15 modèles de réunion 1-1 éprouvés à modifier (gratuits) .
Mais passons au texte proprement dit – passons à des exemples concrets et à des expressions pour le feedback aux développeurs de logiciels.
Modèle de feedback pour les développeurs de logiciels
Modèle général de feedback aux développeurs de logiciels
Évite les méthodes de feedback classiques comme le sandwich de feedback.
Souvent, les modèles de feedback lors des entretiens individuels sont basés sur la méthode du sandwich. Veuillez éviter cela avec les développeurs de logiciels. Les « tournures de phrase » lors des entretiens avec les employés n’aident personne, et les développeurs de logiciels en particulier y réagissent souvent de manière allergique (voir : Critique de la méthode sandwich pour le feedback).
Les développeurs de logiciels reconnaissent généralement, lorsque les dirigeants donnent un feedback positif générique, que ce n’est qu’un outil pour que l’autre personne se sente mieux.
Heureusement, ça va aussi mieux.
Radical Candor : La méthode de feedback qui fonctionne mieux pour les développeurs de logiciels
Au lieu d’enrober votre feedback d’entretien individuel dans un sandwich à feedback, je vous recommande d’utiliser la méthode Radical Candor comme base pour votre modèle de feedback. D’ailleurs, elle n’est pas seulement utile dans le secteur informatique des logiciels, mais aussi dans le domaine privé - approfondissons un peu le sujet.
Radical Candor signifie donner un maximum de feedbacks honnêtes et directs lors des entretiens d’évaluation. Mais en même temps, il faut faire preuve d’empathie et garder à l’esprit le bien-être de l’autre personne. Radical Candor montre qu’il n’est pas nécessaire de choisir l’un ou l’autre : Soit direct et honnête, soit empathique et attentionné. Au lieu de cela, les deux peuvent aller ensemble :
En savoir plus : Qu’est-ce que Radical Candor ?
Les développeurs de logiciels* te seront reconnaissants d’aller droit au but en cas de feedback négatif.
Modèle de feedback pour les développeurs de logiciels basé sur Radical Candor
Ce modèle est basé sur le modèle SBI (Situation, Behavior, Impact). Il t’aide à communiquer de manière sincère et directe tout en restant valorisant.
Voir aussi “Give Feedback Playbook”
Voici les instructions pour chaque partie du modèle de feedback :
Modèle de feedback partie 1 : préparation à l’avance
Avant le feedback, prends quelques minutes pour réfléchir aux points suivants :
- Situation : à quelle situation fais-tu concrètement référence ?
- Le comportement : Quel comportement as-tu observé chez la personne ?
- Impact : quel a été l’impact du comportement de la personne (sur toi et les autres) ?
- Souhait : Quel état souhaitez-vous atteindre et pourquoi ? (Attention : il ne s’agit pas ici de souhaiter directement un certain comportement, cela fait partie de la mesure (voir ci-dessous). Il s’agit plutôt du contexte plus large, de la raison pour laquelle l’impact est un problème pour vous.)
- Action : quelles sont tes suggestions pour la personne ? Quel changement de comportement pourrait nous rapprocher de l’état cible ? Quel soutien peux-tu offrir ?
Il est préférable de noter brièvement les points afin de n’oublier aucune partie lors de l’entretien.
Modèle de feedback, partie 2 : Début de la conversation
Au lieu de commencer par un sandwich de feedback de réunion en tête-à-tête exhaustif, tu peux maintenant commencer directement par la situation comme début de conversation :
- “Je voulais te parler de la situation quand nous…”
Décris la situation et demande ensuite
- “Tu te souviens de la situation ?”
Modèle de feedback partie 3 : Comportement
Ensuite, lors de l’entretien d’évaluation, tu peux aborder le comportement de la personne que tu as observée :
- “Tu as secoué la tête dans la situation et tu as dit…”
Avant de parler de l’effet, donne à ton interlocuteur la possibilité de commenter ta perception ou ton souvenir :
- “Est-ce que je le reflète correctement de ton point de vue ?”
Laisse la place à la personne de décrire sa perspective des choses. Essaie de laisser les deux perspectives s’exprimer sans les commenter. Limite-toi aux questions de fond sur la perspective de ton interlocuteur.
Modèle de feedback partie 4 : Impact
Ce n’est que dans cette partie qu’il s’agit de discuter des conséquences du comportement. Reste d’abord le plus objectif possible :
- “Mon impression était qu’après ton [comportement observé], le collègue Marc semblait très vexé et n’était plus disposé à continuer à travailler avec nous de manière coopérative”.
Si les conséquences t’affectent aussi, il est important de les partager. Bien sûr, tu dois rester professionnel, mais tu peux aussi montrer ton côté humain :
- “Moi aussi, j’étais honnêtement gêné dans cette situation et j’ai trouvé la conversation désagréable à partir de ce moment-là”.
Modèle de feedback partie 5 : Souhait
Exprime ton souhait concret dans cette partie de l’entretien d’évaluation :
- “Il est important pour moi que nous trouvions à nouveau une bonne base de collaboration avec notre collègue Marc”.
Replacer celui-ci dans son contexte :
- “Et même au-delà, c’est un grand besoin de ma part que nous nous assurions ensemble que nous entretenons une bonne coopération et de bonnes relations avec tous les services adjacents”.
Fais également le lien avec des objectifs pertinents qui expliquent pourquoi tu as ce souhait :
- “Ce n’est qu’à travers une bonne relation que nous pouvons atteindre nos objectifs en tant qu’équipe dans cette entreprise. De plus, il est important pour moi que nous jouissions d’une bonne réputation en tant qu’équipe dans l’entreprise”.
"J'aime l'employé, mais il n'atteint pas les performances souhaitées. Comment puis-je aborder ce problème dans les réunions individuelles ?"
Résoudre ce défi
"Souvent, je ne sais pas si j'étais trop dure – ou trop douce – dans mes 1:1 pour avoir un impact positif".
Résoudre ce défi
"Je ne vois pas de modèles ou de tendances dans mes 1:1. Tout semble isolé".
Résoudre ce défiModèle de feedback partie 6 : Action
Avant de présenter tes propres idées de solutions, tu peux demander ouvertement lors de ton entretien en tête-à-tête :
- “J’ai quelques idées à ce sujet. Mais avant, j’aimerais avoir ton avis : Comment penses-tu que nous pouvons atteindre l’objectif ?”
Ensuite, tu peux partager tes idées. Conviens ensemble d’un suivi obligatoire et concrètement défini. Fixe-le par écrit.
Modèle de feedback partie 7 : Sortie
Demande si l’entretien d’évaluation a été utile pour l’autre personne et si elle a encore des questions en suspens. Conviens d’un check-in pour savoir quand vous en parlerez la prochaine fois.
Montre ton appréciation pour la discussion ouverte et remercie la personne pour sa perspicacité et sa coopération.
Modèle de feedback partie 8 : Réfléchis rétrospectivement à ton feedback
À la fin de chaque entretien de feedback, tu devrais te poser la question suivante :
- Sincérité : est-ce que j’ai partagé mon feedback honnêtement et le moins possible ?
- Valorisation : est-ce que la personne se sent valorisée par mon feedback ?
Si tu peux répondre “oui” à toutes les questions, ton entretien de feedback s’est très bien passé. Si ce n’est pas le cas, ne t’inquiète pas. Réfléchis à la manière dont tu peux formuler différemment à l’avenir. Et encore une fois : la plupart de ces conseils ne s’appliquent bien sûr pas uniquement à l’industrie des logiciels informatiques.
Je tiens à préciser qu’il existe bien sûr des logiciels pour faciliter les conversations de feedback et le coaching à long terme des développeurs de logiciels.
Notre logiciel de réunion en tête-à-tête te propose divers modèles d’entretiens avec les développeurs de logiciels et permet même de mesurer le développement des employés. N’hésite pas à consulter notre outil en essayant le modèle suivant :
Pas de small talk, pas de pauses embarrassantes. 🥱 Ce modèle 1:1 fonctionne tout simplement à tous les coups.
💬 Extrait du modèle :
- De quelle réalisation es-tu fier, que je n'ai peut-être pas remarquée ?
- Quel petit changement améliorerait immédiatement ton travail ?
- Pour quoi voudrais-tu prendre plus de temps au travail ?
…
Maintenant, utilisons ce modèle d’entretien d’évaluation et jouons quelques exemples pratiques !
Réunion 1:1 Exemples de feedback : Qualité du code, appropriation
Exemples de feedback aux développeurs de logiciels lors de réunions en tête-à-tête
Exemple de feedback aux développeurs de logiciels lors de réunions 1 à 1 : qualité du code
Avec Tanja 👩🏼🦰 dans le rôle de chef d’équipe et Marc 👨🏽 dans le rôle de collaborateur.
Décrire la situation
« Lors de notre dernière revue de code, nous avons examiné votre demande de tirage pour l’implémentation de la nouvelle fonctionnalité dans le tableau de bord. Le code était fonctionnellement correct et répondait aux exigences. »
« Oui, je m’en souviens ! »
Comportement observé
“Ce faisant, j’ai commenté des passages qui étaient assez complexes et difficiles à lire. Par exemple, il y avait une méthode de plus de 50 lignes qui combinait plusieurs responsabilités. Cependant, tu n’as commenté ce commentaire que superficiellement et tu ne t’es pas étendu sur le sujet”.
“Pour moi, le commentaire ressemblait à une proposition optionnelle. Cela me semblait trop compliqué de modifier à nouveau la solution”.
Effet
“En tout cas, ton commentaire m’a fait me sentir un peu frustré, et au lieu d’insister pour que tu fasses des améliorations, j’ai simplement amélioré la méthode moi-même dans la foulée, parce que j’avais déjà pensé au code de toute façon”.
“Oh, je ne m’en étais pas rendu compte”.
Objectif et désir
“Notre objectif commun est que notre code ne soit pas seulement fonctionnel, mais aussi maintenable et facile à comprendre pour tous”.
“Je suis d’accord avec toi”.
Mesures à prendre
“Quelle est ta suggestion pour améliorer la qualité du code de manière plus fluide dans de tels cas à l’avenir ?”
“Cela m’aiderait s’il était plus facile de voir dans les commentaires si une amélioration est simplement suggérée ou réclamée”.
« D’accord, faisons-le : je vais en reparler lors de la réunion d’équipe. De plus, de mon point de vue, un suivi de votre part est également nécessaire. »
“Et si, pour le prochain sujet, nous allions directement ensemble dans une programmation en binôme, afin que tu puisses aiguiser encore une fois ma compréhension de l’exigence de qualité du code”.
Conclusion
“Cela ressemble à deux bons suivis ! Alors, prenons-en bonne note. N’hésite pas à me fixer un rendez-vous dans le calendrier pour le milieu de la semaine prochaine afin de commencer la programmation en binôme”.
“Très bien, j’ai hâte d’y être”.
Exemple de feedback aux développeurs de logiciels lors de réunions 1 à 1 : Ownership
Avec Tanja 👩🏼🦰 dans le rôle de chef d’équipe et Marc 👨🏽 dans le rôle de collaborateur.
Décrire la situation
« Marc, je voudrais te parler de la dernière tâche, au cours de laquelle nous avons développé la nouvelle fonctionnalité pour le processus d’exportation. La fonctionnalité est désormais en ligne, mais il y a eu quelques difficultés en cours de route. »
« Oui, je me souviens. Que veux-tu dire exactement ? »
Comportement observé
“J’ai remarqué qu’il y avait plusieurs fois des retards prolongés après la transmission du code au testing. Par exemple, certains commentaires n’ont pas reçu de réponse de la part des collègues QA avant plusieurs jours. Il est aussi arrivé que je doive te rappeler deux fois une révision manquante”.
“Hmm, je comprends. Honnêtement, il y avait pas mal de choses à faire, et je pensais que le testing se poursuivait en parallèle”.
Effet
“Quoi qu’il en soit, le résultat a été que nous avons dû reporter notre déploiement à cause de ce problème”.
“Oh, je ne m’en étais même pas rendu compte. Je croyais que tu m’appelais quand quelque chose était urgent”.
Objectif et désir
“Notre objectif est de minimiser les retards inutiles et que les développeurs vivent un esprit d’appropriation lors de la mise en œuvre. Cela signifie que chacun s’assure activement que son ticket passe bien du début à la fin – et cela inclut aussi la communication avec QA”.
“Je comprends ce que tu veux dire. Je veux absolument que les processus soient plus fluides”.
Mesures à prendre
“Que pourrions-nous faire, selon toi, pour que tu sois plus proactif et que tu fasses preuve d’appropriation dans de telles situations ?”
“Je pense que cela aiderait si nous définissions des attentes plus claires, comme le fait que je fasse un check-in quotidien concernant les sujets ouverts pendant la phase de test. Ainsi, je peux m’assurer que rien ne reste en suspens”.
“Cela semble bien. Et je te suggère que pour les prochaines tâches importantes, une fois le code terminé, tu fasses un plan rapide de la façon dont tu vas accompagner le sujet jusqu’à la mise en ligne. Tu peux me montrer ce plan à moi ou à un collègue QA”.
“Je suis d’accord. Comme ça, je pourrai mieux m’en occuper moi-même”.
Conclusion
“Super. Prenons les deux mesures ainsi : Tu fais des check-ins quotidiens pendant la phase de test et tu planifies le suivi pour ta prochaine grande tâche. Est-ce que c’est faisable pour toi ?
“Oui, c’est parfait. Je le mets directement sur mon calendrier”.
“Super. Je suis sûr que cela fera une grande différence. Lors de notre prochain entretien en tête-à-tête, nous regarderons à nouveau l’état de nos mesures. Merci à toi”.
Guider par des questions : modèle pour une réunion 1:1
Un adage de la littérature de management dit : diriger en posant des questions. Et c’est vrai.
Si vous organisez régulièrement et continuellement des entretiens individuels au cours desquels vous réfléchissez avec l’employé sur le thème du feedback (en posant des questions), les problèmes ne peuvent pas « s’accumuler ».
C’est pourquoi je voudrais te donner ici un autre modèle que tu peux utiliser dans notre outil Echometer avec ton collaborateur. En principe, tu peux aussi utiliser ce modèle régulièrement.
N’hésite pas à les essayer en cliquant simplement sur le bouton ci-dessous (pas besoin de se connecter) :
Début
- Comment s’est passée ta semaine jusqu’à présent ?
📊 Mises à jour du projet
- Comment se déroulent tes projets actuels ? Y a-t-il des succès ou des obstacles majeurs ?
- Y a-t-il des défis techniques dont tu souhaites discuter ou sur lesquels tu souhaites réfléchir avec nous ?
💻 Qualité du code et développement
- Comment te sens-tu par rapport à la qualité de ton travail ces derniers temps ?
- Y a-t-il des domaines dans lesquels tu souhaites t’améliorer ou acquérir de nouvelles compétences ?
🤝 Équipe, collaboration et prochaines étapes
- Comment se déroule la collaboration au sein de l’équipe ? Y a-t-il des lacunes en matière de communication ?
- Les outils et les processus que nous utilisons soutiennent-ils efficacement ton travail ?
- Comment imagines-tu ta carrière dans les deux prochaines années ?
- Comment puis-je t’aider à réussir ?
Conclusion
- Qu’est-ce qui t’enthousiasme le plus dans les prochains mois ?
- As-tu d’autres questions ou préoccupations ?
⁉️ Bilan de l’humeur (sondage)
Exemples de feedback de revue de performance : Travail d’équipe, appropriation
Exemples de feedback aux développeurs de logiciels dans la revue de performance
Une remarque : les revues de performance classiques sont plutôt mal vues, tant par les développeurs de logiciels que par les cadres supérieurs, et beaucoup argumentent que de bonnes réunions en tête-à-tête sont suffisantes et devraient remplacer les revues de performance. Voir “Les évaluations de performance sont inutiles et insultantes” par Forbes.
Souvent, le format des revues de performance est encore imposé dans l’entreprise. Bien sûr, cela ne doit pas t’empêcher de mener les revues de performance comme un dialogue d’égal à égal avec tes collaborateurs, au lieu de te limiter à donner des évaluations d’en haut. Les exemples suivants d’un entretien en tête-à-tête montrent comment cela peut fonctionner.
Remarque : comme nous l’avons dit, les modèles d’entretiens d’évaluation peuvent bien sûr aider à communiquer un feedback de manière constructive. Le billet de blog suivant peut t’aider si tu es plus intéressé par le sujet : 5 modèles pour les check-ins réguliers des employés .
Exemple de feedback aux ingénieurs logiciels dans les revues de performance : Travail d’équipe
Avec Tanja 👩🏼🦰 dans le rôle de chef d’équipe et Marc 👨🏽 dans le rôle d’ingénieur logiciel.
Décrire la situation
« Lorsque j’ai dû évaluer le point “Travail d’équipe” dans ton modèle d’évaluation des performances, je n’ai malheureusement pu attribuer que 5 points sur 10 possibles. J’aimerais t’expliquer pourquoi, afin de te donner une chance équitable de t’améliorer sur ce point. »
« Oh, d’accord. S’il te plaît, aide-moi à comprendre. »
Comportement observé
“J’ai remarqué que ces derniers mois, il y a toujours eu des situations où la collaboration avec l’équipe n’était pas optimale. Par exemple, lors de notre dernier sprint, il y a eu plusieurs cas où tu as travaillé seul sur des tâches alors qu’elles auraient pu être mieux résolues avec d’autres. Un exemple concret était l’intégration de la nouvelle API. Nous avions envisagé de te faire travailler ensemble avec Alex, mais tu as pris en charge la plupart des étapes seul, n’impliquant Alex que de manière minimale”.
“Je pensais qu’il serait plus efficace de le faire moi-même rapidement. Je n’avais pas réalisé que cela était considéré comme un problème”.
Effet
“Mais cela a fait perdre la transparence au sein de l’équipe. Alex a eu du mal à s’impliquer dans des tâches connexes parce qu’il ne savait pas exactement comment l’API était construite. De plus, les autres membres de l’équipe m’ont fait savoir qu’ils ne se sentaient parfois pas assez impliqués et qu’ils trouvaient difficile d’obtenir ton soutien lorsqu’ils avaient des questions”.
“Franchement, ça me surprend. Je pensais que je donnerais un coup de main si on me le demandait”.
Objectif et désir
“Notre objectif en tant qu’équipe est non seulement de travailler efficacement, mais aussi de partager les connaissances et d’impliquer tout le monde. Cela renforce la collaboration et fait en sorte que nous puissions tous nous représenter mutuellement. Je souhaite qu’à l’avenir, tu utilises davantage ton rôle de porteur de connaissances dans cette équipe pour partager activement les connaissances et enabler les autres membres de l’équipe. La productivité de l’équipe passe avant la performance individuelle”.
“Ok, je comprends ce que tu veux dire. Je crois que jusqu’à présent, j’ai simplement trop regardé ma propre productivité”.
Mesures à prendre
“Qu’est-ce qui pourrait t’aider à mieux faire attention à impliquer l’équipe dans ton travail et à partager les connaissances ?”
“Je pourrais prendre l’habitude de clarifier dès le début des tâches importantes qui peut y participer et comment. Peut-être pourrions-nous aussi établir une sorte de kick-off pour les tâches, afin d’y coordonner les décisions architecturales les plus importantes et d’identifier les tâches que quelqu’un d’autre devrait faire seul, ou même celles que nous devrions faire en pair programming”.
“Cela semble bien. J’ai aussi eu une idée : et si tu prenais l’habitude, lors de nos Weekly en équipe, non seulement de rapporter les progrès, mais aussi de donner un aperçu actif du code et des décisions architecturales ?”
“C’est un bon point. Cela pourrait aider nos collègues inexpérimentés à travailler plus facilement sur mon code plus tard”.
Conclusion
“Super. Alors, nous le gardons comme suivi dans notre modèle de revue de performance :
- À partir de maintenant, tu partageras de manière proactive tes connaissances et tes décisions architecturales avec l’équipe lors des Weekly.
- Désormais, tu feras un kick-off avec un autre développeur pour tes sujets, afin que vous élaboriez ensemble la solution et que vous vous répartissiez la mise en œuvre.
“Ça a l’air bien”.
« OK. Je noterais ces deux mesures pour un examen dans deux mois. Nous pourrons alors discuter de l’état d’avancement lors de notre entretien individuel et voir comment nous allons procéder. »
“Oui, et voyons si tu peux améliorer ton score de travail d’équipe. J’aimerais obtenir au moins un 8 sur 10”.
“Je suis content de l’entendre ! Je pense absolument que c’est réaliste et je te soutiendrai autant que je le peux”.
“Merci !”
Exemple de feedback sur les revues de performance des ingénieurs logiciels : Propriété
Passons à l’exemple suivant de conversation en tête-à-tête, où il s’agit de donner un feedback au développeur de logiciels sur le thème de l’appropriation.
Comme toujours, avec Tanja 👩🏼🦰 dans le rôle de chef d’équipe et Marc 👨🏽 dans le rôle d’ingénieur logiciel.
Décrire la situation
« Lorsque j’ai dû évaluer le point “Responsabilité” dans ton modèle d’évaluation des performances, je n’ai pu attribuer que 6 points sur 10. Je souhaite t’expliquer pourquoi il en est ainsi et te donner la possibilité de te développer dans ce domaine. »
« Wow, cela me surprend un peu. Après tout, j’ai participé à autant de projets que presque personne d’autre dans l’équipe. Merci de m’expliquer. »
Comportement observé
“Ces derniers mois, j’ai remarqué qu’il y avait souvent des retards dans tes tâches. Il y a quelques exemples où des commentaires QA ou des revues de code de ta part sont restés sans réponse pendant une longue période. Par conséquent, tes sujets n’ont été mis en ligne qu’après des semaines de retard. Un exemple concret était la correction de bugs pour l’exportation. Tu n’as répondu aux commentaires de l’AQ qu’après plusieurs demandes, et il a fallu trois semaines au total pour que les modifications soient en ligne”.
“Oui, je m’en souviens. J’avais travaillé sur deux autres sujets en parallèle et je n’ai pas eu le temps d’intégrer le feedback”.
Effet
“Cela a eu un impact sur la vélocité et la productivité de toute l’équipe. QA a dû relancer plusieurs fois, ce qui a mobilisé leurs capacités. Le plan de release a également dû être reporté. De plus, on a l’impression que tu n’assumes pas entièrement la responsabilité de l’achèvement de tes thèmes, ce qui pèse sur la dynamique de l’équipe. Certains membres de l’équipe m’ont fait comprendre qu’ils ne se sentaient pas sûrs de pouvoir compter sur toi en cas de dépendance”.
“Oh, je suis désolée. Je n’en avais pas conscience. J’ai essayé de faire les tâches en parallèle, mais apparemment ça n’a pas très bien marché”.
Objectif et désir
“Mon objectif est que tu te concentres sur moins de sujets, mais que tu accompagnes chaque tâche du début à la fin avec une responsabilité totale. Cela signifie que tu ne te contentes pas d’écrire le code initial, mais que tu t’assures que les commentaires QA sont traités en temps voulu et que le sujet reste dans les temps. Ainsi, nous pouvons éviter que des tâches restent ouvertes plus longtemps et en bloquent d’autres”.
“C’est logique. Je me suis souvent sentie dépassée parce que j’avais trop de sujets à traiter en même temps. Peut-être que c’est vraiment mieux de me concentrer sur moins de tâches”.
Mesures à prendre
“Comment pourrions-nous faire en sorte que tu te concentres sur un petit nombre de sujets tout en prenant la responsabilité de les mettre pleinement en œuvre ?”
“Je pourrais essayer de me limiter à deux sujets maximum par sprint et ne jamais travailler sur plus de trois sujets en parallèle. De plus, je devrais bloquer des créneaux fixes dans mon calendrier pour traiter régulièrement les commentaires et les revues afin de ne rien laisser en suspens”.
“Cela semble logique. De plus, je pense qu’il serait bon que tu demandes de l’aide de manière proactive dans nos standups si tu travailles sur trop de sujets en parallèle. En règle générale, il devrait y avoir quelqu’un qui peut reprendre un de tes sujets”.
“OK, juste”.
Conclusion
Fixons ces mesures comme objectif pour les deux prochains mois :
Moins de travail en parallèle :
- Tu prends en charge au maximum deux sujets par sprint et tu ne travailles pas sur plus de trois sujets en parallèle au total.
- Demander un soutien actif de l’équipe dans les standups
- Des créneaux fixes dans le calendrier pour traiter les commentaires et les évaluations.
“Cela semble réaliste. Faisons comme ça”.
“Super ! Nous pourrons voir dans deux mois, lors de la revue de performance, si ces mesures ont été efficaces et si nous pouvons remonter ton score dans la revue de performance pour ‘Ownership’”.
“Merci, Tanja. Je vais m’efforcer de mettre cela en pratique. Avant, j’avais toujours les meilleures notes en ‘ownership’. Penses-tu que j’y arriverai à nouveau d’ici le prochain examen de performance ?”
“Je suis très content. Oui, je pense qu’avec ces mesures, une amélioration rapide est tout à fait réalisable. Discutons de l’état de la situation lors de nos réunions bihebdomadaires en tête-à-tête et voyons si tu as besoin de soutien”.
“Merci ! Oui, je serais ravi si nous pouvions obtenir une amélioration sensible ici en quelques semaines seulement !”
Entretien annuel Feedback Exemples : Désir de changer de rôle
Exemples de feedback aux développeurs de logiciels lors de l’entretien annuel
Si tu as déjà des réunions régulières en tête-à-tête avec tes développeurs ou des revues de performance en cours d’année, il n’est probablement plus nécessaire d’avoir des entretiens annuels détaillés. L’échange sur les performances, le feedback et le développement devrait déjà être un dialogue continu :
Néanmoins, certaines entreprises exigent un entretien annuel classique.
💡
Si, en tant que cadre de développeurs de logiciels, tu as déjà des réunions 1:1 régulières ou des revues de performance, l’entretien annuel ne devrait être qu’une formalité :
Le feedback devrait déjà être connu du développeur de logiciels et les potentiels de développement devraient déjà être travaillés.
Si, en tant que manager de développeurs de logiciels, tu dois remplir la formalité d’un entretien annuel de fin d’année (éventuellement en plus d’entretiens réguliers en tête-à-tête), examinons également un entretien annuel avec un développeur de logiciels à titre d’exemple.
D’ailleurs, un autre conseil à ce sujet : Si ta première réunion en tête-à-tête avec un nouveau collaborateur est imminente, je te recommande notre article à ce sujet : 5 conseils pour les réunions en tête-à-tête avec les nouveaux employés .
Exemple d’agenda & modèle d’entretien annuel avec un développeur de logiciels
- Rétrospective et performance
- Réussites : quels projets ou tâches se sont bien déroulés ? Où les attentes ont-elles été dépassées ?
- Défis à relever : Qu’est-ce qui n’a pas bien fonctionné et pourquoi ? Comment ces défis peuvent-ils être surmontés à l’avenir ?
- Réflexion : comment le développeur lui-même voit-il sa performance ? Quels sont les retours de l’équipe ou du manager ?
- Collaboration et culture d’équipe
- Communication : comment est perçue la collaboration au sein de l’équipe et avec le responsable ?
- Climat de travail : y a-t-il un potentiel d’amélioration dans la culture d’équipe ou l’environnement de travail ?
- Feedback sur le leadership : comment le supérieur peut-il mieux soutenir le développeur ?
- Feedback du développeur : y a-t-il des suggestions pour améliorer les processus, les outils ou la culture de travail ?
- Equilibre entre vie professionnelle et vie privée : comment est perçue la charge de travail actuelle ? Y a-t-il des heures supplémentaires ou des facteurs de stress ?
- Ressources : les outils, les processus et le cadre sont-ils suffisants pour travailler efficacement ?
- Compétences, objectifs et développement
- Les points forts : Quelles sont les compétences techniques, méthodologiques ou sociales qui caractérisent le développeur ?
- Formation continue : Quelles nouvelles technologies ou compétences le développeur souhaite-t-il apprendre ? Y a-t-il des cours, des conférences ou des projets pertinents ?
- Objectifs de carrière : Quelle position ou responsabilité le développeur vise-t-il à moyen ou long terme ? Quelles sont les étapes pour y parvenir ?
- Orientation du projet : sur quels projets ou technologies le développeur souhaite-t-il travailler davantage ?
- Rémunération
- Rémunération basée sur la performance : faut-il adapter le salaire ou les bonus ?
- Conclusion
- Objectifs à court terme : Quels sont les objectifs concrets à fixer pour l’année à venir ?
- Les accords : Quels sont les prochains check-ins pour chaque mesure ?
Voici un exemple typique de feedback dans le cadre d’un bilan annuel ou d’un entretien d’évaluation annuel : Le souhait d’un collaborateur de changer de rôle.
Exemple de feedback lors de l’entretien annuel : Souhait de changer de rôle
Avec Tanja 👩🏼🦰 dans le rôle de chef d’équipe et Marc 👨🏽 dans le rôle d’ingénieur logiciel.
Entrée en matière et situation
« Marc, je suis content que nous puissions parler aujourd’hui de ton feedback annuel et de tes objectifs. Y a-t-il des sujets qui te tiennent particulièrement à cœur ? »
« Oui, j’ai réfléchi à mon évolution. Je pourrais m’imaginer évoluer vers l’architecture logicielle. Ce sujet me tente depuis longtemps et j’aimerais me pencher plus en profondeur sur les décisions d’architecture et la gestion stratégique des technologies. »
“C’est passionnant, Marc. Je suis content que tu aies des objectifs aussi clairs. Parlons de la façon dont nous pouvons te préparer à cela. Il y a quelques points sur lesquels je pense que tu dois encore progresser avant de passer à l’étape suivante”.
Donner un feedback
“Tout d’abord, je tiens à souligner que tu as fait de nombreux progrès cette année, notamment en ce qui concerne la qualité de tes implémentations et l’utilisation de nouvelles technologies. Tu as également montré que tu avais l’œil pour les grandes lignes, par exemple lors de l’introduction du nouveau système de mise en cache”.
“Merci, je suis content de l’entendre”.
“Quand je pense au rôle d’un architecte de logiciel, il y a cependant encore quelques exigences qui, à mon avis, ne sont pas complètement remplies actuellement. Par exemple, la communication avec l’équipe et l’implication des autres dans les décisions techniques est un élément central. Je vois encore du potentiel chez toi. Souvent, tu prends des décisions de manière autonome, sans impliquer l’équipe suffisamment tôt”.
“Ok, je comprends ça. Parfois, je ne voulais arrêter personne, mais je vois que ce n’est pas idéal pour le rôle d’architecte”.
Objectif et désir
“Exactement. Un architecte de logiciels est aussi un coach et un communicateur. Il s’agit d’entraîner les autres avec toi, de communiquer des concepts techniques et d’élaborer des solutions ensemble”.
“Cela a du sens. Je réalise aussi que je ne peux pas encore transmettre mes pensées sur l’architecture de manière aussi efficace aux membres de mon équipe”.
Planifier les mesures
“Je pense que nous pouvons travailler ensemble sur ce point pour que tu te qualifies pour le rôle dans les six prochains mois. Et si nous définissions des mesures concrètes ?”
“Avec plaisir. Qu’est-ce que tu as en tête ?”
“Je voudrais surtout te voir animer la prise de décision pour l’architecture logicielle, plutôt que de prendre la décision toi-même. Que dirais-tu d’animer un kick-off d’architecture pour chacun des prochains grands thèmes ? L’objectif serait de soutenir les collègues dans la prise de décision et de les laisser ensuite mettre en œuvre eux-mêmes la solution”.
« Cela semble bien. J’apprends ainsi à exercer mon influence en tant que coach au lieu de tout mettre en œuvre moi-même. »
« De plus, j’imagine qu’il existe de bons cours pour préparer les développeurs au rôle d’architecte logiciel. Ces cours aborderont certainement, outre les compétences techniques, les compétences non techniques nécessaires à ce rôle. »
« Oui, j’ai effectivement déjà trouvé un cours. »
Conclusion
« Super, je note donc les points suivants pour notre entretien annuel :
- Objectif de développement : Architecte logiciel
- Mesures à prendre :
- Animation de kick-offs d’architecture en équipe
- Participation au cours pour architectes de logiciels
Bien sûr, nous parlons continuellement de ces sujets lors de nos entretiens individuels, mais le prochain check-in officiel aura lieu lors de notre évaluation des performances dans 3 mois.
« Ça a l’air bien. D’ici là, nous devrions déjà avoir accompli pas mal de choses. »
« Je le pense aussi ! Si d’autres choses te viennent à l’esprit entre-temps et que tu penses que je peux t’aider dans cette démarche, n’hésite pas à m’en parler à tout moment. »
« Pouvons-nous également reparler de mon changement de rôle souhaité dans 3 mois ? »
« Bien sûr, je ne peux rien te promettre concernant le changement de rôle. Mais j’ai noté ton souhait et j’essaie de te soutenir au mieux. »
“Merci !”
Conclusion : Feedback aux ingénieurs logiciels lors des réunions 1:1, des revues de performance et des entretiens annuels
Conclusion : un feedback motivant pour les développeurs de logiciels*.
Les exemples et les modèles montrent qu’il ne doit pas être si difficile de donner un feedback motivant aux développeurs de logiciels* lors des entretiens en tête-à-tête et des entretiens de fin d’année, non ? Reste authentique et bienveillant, ne tourne pas autour du pot trop longtemps et montre que tu es intéressé par une solution commune.
Si tu réussis à mettre en œuvre la “Radical Candor” dans tes entretiens avec tes collaborateurs et au-delà, en faisant preuve d’appréciation et d’honnêteté, la réaction sera peut-être même plus positive et constructive que tu ne le penses.
Bonne chance pour tes prochains entretiens de feedback !
Et si tu aimes les hacks qui te facilitent la vie, je te recommande notre logiciel Echometer. Tu peux l’essayer complètement gratuitement.
Notre logiciel de réunion en tête-à-tête te propose divers modèles d’entretiens avec les développeurs de logiciels et permet même de mesurer le développement des employés. N’hésite pas à consulter notre outil en essayant le modèle suivant :
Pas de small talk, pas de pauses embarrassantes. 🥱 Ce modèle 1:1 fonctionne tout simplement à tous les coups.
💬 Extrait du modèle :
- De quelle réalisation es-tu fier, que je n'ai peut-être pas remarquée ?
- Quel petit changement améliorerait immédiatement ton travail ?
- Pour quoi voudrais-tu prendre plus de temps au travail ?
…
