Quelle est la meilleure façon d'évaluer vos développeurs et ingénieurs ?

Artisan du web et profil fortement recherché par les entreprises, le développeur et ces compétences techniques n’en demeure pas moins difficile à évaluer, en particulier lorsqu’il s’agit de bâtir un parcours carrière personnalisé. 

D’abord parce qu’évaluer cet expert tech au nombre de lignes de code écrites n’aurait évidemment aucun sens. Ensuite parce que le métier est soumis à des cycles d’innovation technologiques de plus en plus courts (les pratiques de programmation évoluent constamment). Un paradigme qui oblige une réactualisation régulière des connaissances. Sans compter que se fonder sur les seules compétences techniques serait méconnaître un point fondamental, le métier est foncièrement collaboratif. C’est pour cela qu’un feedback bienveillant et transparent allié à une bonne intégration s’annoncent cruciaux pour la pérennité de la mission et la productivité du collaborateur. 

‍

Construire des parcours de carrière agiles et inspirants via les skills matrix

Collaborateur clé dans l’accélération de la transformation numérique des entreprises, le développeur est un accro à la nouveauté. Mais attention tous ces enthousiastes tech ne sont pas animés du même désir en matière de développement : certains sont avant tout attirés par la dimension technique d’une technologie donnée (intelligence artificielle, réalité virtuelle, blockchain…) quand d’autres préfèrent agir sur l’expérience utilisateur et son comportement vis-à-vis de cette technologie (UX). 

Autre chose, le développeur est quelqu’un qui ne supporte pas les processus lourds et veut voir rapidement son impact et le résultat de son travail de longue haleine sur le produit. 

Devant l’obsolescence programmée des outils numériques et des méthodes de programmation, il est primordial pour l’entreprise de mettre au point un parcours de carrière encourageant la montée en compétences des développeurs. 

Il ne s’agit ni de les cantonner à un seul langage de programmation (Javascript/TypeScript, Rust, Python, Ruby, C++, PHP…) ni à un framework (Spring, Ruby on Rails, Angular JS) mais d’apprendre de nouvelles choses. Un objectif pouvant être rempli via des formations complémentaires in-house et une auto-formation permanente qu’il s’agit d’encourager. 

Le test & learn est clairement leur seconde nature. Ce n’est pas pour rien que la plupart de ces passionnés du code se sont formés sur des blogs tech, des ouvrages spécialisés ou encore des meetups. 

Il convient donc de prévoir des voies d’évolution d’expertise répondant aux besoins technologiques et organisationnels de l’entreprise mais aussi aux attentes des développeurs en matière de responsabilité et de contribution au sein de l’entreprise. 

Pour épauler un développeur souhaitant manager mais devant perfectionner ses qualités de leadership, des modules de formation extra-tech s’avèrent utiles comme le développement de la prise de parole, les méthodes de productivité et d’organisation ou encore l’amélioration de la confiance en soi. 

Chez Elevo, la formalisation d’un parcours de carrière favorisant une attitude MVP (minimum viable product, autrement dit une version initiale minimale mais cohérente) est la bonne astuce. L’idée est de proposer une track tech avec une bifurcation manager si besoin. Car, oui, si le développeur aime partager des idées créatives, concevoir et tester de nouvelles solutions et être incollable sur “ce qu’il y a sous le capot” d’une technologie donnée, tous n’aspirent pas à un poste de manager. La plupart voulant continuer dans leur voie d’expertise. Pour repérer les aspirants managers, il peut être utile de décliner des skills matrix au delà des items techniques intrinsèquement liées à la profession comme la capacité d’innovation ou la qualité du code. C’est ainsi que des axes comme la compréhension business, la communication, la participation, le leadership/prise de décision et la pédagogie sont à explorer. Pour l’équipe qui aurait besoin de plusieurs profils différents, il s’agit de mener des “tracks” suivant des thématiques génériques comme infrastructure, design, architecture, sécurité…

Feedback par les pairs : élément clé dans la montée en compétence de l’équipe de développeurs

Le feedback à l'écrit et à l'oral est nécessaire afin de s’assurer qu’une même vision du projet est partagée et ça tombe bien, le développeur est demandeur de feedback. 

Faire appel au feedback par les pairs pour évaluer individuellement chaque développeur s’avère critique. D’abord parce que le travail du développeur étant intrinsèquement collectif, le seul manager n’aura qu’une vue partielle de la performance d’un des membres de son équipe. Ensuite parce qu’a priori un feedback par les pairs, hors manager du développeur, renforcerait le risque de copinage lors du processus d’évaluation.  Or sur ce point, il n’en est rien : cette entraide peut au contraire inciter à responsabiliser les membres de l’équipe. 

Travaillant de manière asynchrone, distribuée et avec une flexibilité horaire comme spatiale, ces discussions sont nécessaires pour se coordonner. L’engagement et la performance du développeur est directement corrélé à la qualité de son intégration au sein d’une équipe. Ce qui veut dire que si son engagement est en berne au sein de son équipe actuelle, il y a tout lieu de penser qu’il puisse mieux performer au sein d’une autre équipe. S’il dispose d’une culture spécifique avec son jargon technique, ses références, il demeure particulièrement attaché à une relation hiérarchique horizontale. Tout développeur dispose de nombreux points et réunions propices au feedback : code reviews, réunion de lancement de sprints, sprints/itérations, REX. Mais attention à bien anticiper les risques de conflits et d’incompréhension lors de la mise en place d’un système évaluation, il convient d’expliquer votre démarches auprès des équipes. Dans la pratique, si le manager tech est expérimenté dans la programmation, il bénéficiera d’une légitimité et d’une résonance supérieure à quelqu’un d’extérieur. Dans le cas contraire, il faudra qu’il se familiarise avec les contraintes communément rencontrées par les développeurs.  

Le feedback permet, à l’instar du code review qui consiste à examiner la qualité du code source par une tierce personne, de réduire la dette technique et de limiter le risque de bugs mis en production. Ces codes reviews doivent, d’ailleurs, être intégrés dans le planning des développeurs. En d’autres termes, un feedback régulier signifie fixer un cap au développeur, lui offrir une marge de manoeuvre suffisante pour perfectionner son code et repérer suffisamment tôt toute erreur technique qui aurait pour effet de retarder le lancement du produit/service et donc engendrerait un coût supplémentaire pour l’entreprise. 

Ces discussions doivent être l’occasion de donner du sens à la collaboration. Pour ce faire, il s’agit de contextualiser son intervention et de lui donner des clés de compréhension sur son rôle opérationnel comme stratégique. Ce sera au manager de repérer le potentiel de ses équipes de développeurs. Libre à lui d’inciter certains collaborateurs à prendre part des barcamps ou à intervenir lors de meetups. Outre le rôle de manager, d’autres fonctions valorisantes peuvent permettre de diversifier leur compétences comme le fait d’être mentor auprès des nouveaux arrivants ou encore ambassadeur/représentant tech de l’entreprise. 

Des objectifs majoritairement collectifs, garants de la solidité de l’équipe de devs

Métier par essence collaboratif, l’évaluation du travail du collaborateur développeur peut difficilement se fonder sur des livrables individuels précis. 

De nombreux paramètres peuvent être mesurés ou tout du moins appréciés comme la qualité du code soumis, la rapidité et l’efficacité des retours à ses collègues sur le nouveau code (code reviews), le nombre de bugs créés, trouvés et résolus, l’écart entre les prévisions et la deadline de la release. 

Le développeur est aussi quelqu’un qui porte un vif intérêt pour les side-projects (hackathons, challenges, conférences, meetups) et qu’il convient d’intégrer dans le planning. 

Vous l’aurez compris, un développeur est avant tout un collaborateur s’inscrivant dans une véritable aventure d’équipe. Celle-ci a à coeur de résoudre des problèmes techniques complexes à travers des solutions créatives. Il convient donc de voir l’évaluation des développeurs à travers l’image du  rubik’s cube : il n’y a pas une mais plusieurs solutions envisageables pour réussir ses challenges quotidiens. 

Une règle d’or à retenir : pensez agile. Il faut que les parcours de carrière soient évolutifs et participatifs. A cette fin, appliquez le feedback à votre propre système. Chez Elevo nous travaillons avec de nombreux clients avec un ADN tech et nous pouvons vous accompagner sur ces dimensions. 

Contactez nous pouvoir comment cela se passe concrètement (et conviez votre directeur technique 😄)

A retenir : 

Tout développeur n’aspire pas un poste de manager. Il s’agit donc de bâtir un parcours de carrière “développeur” évolutif et participatif. L’idée est de proposer un seul parcours avec une bifurcation manager si besoin. Cela peut consister à mettre en place des modules de formation extra-tech comme communication orale, organisation ou confiance en soi. De même il s’agit de donner une impulsion à l'apprenance en suggérant des médias spécialistes, des livres, des conférences/webinars…

Privilégier les objectifs d’équipes pour fonder votre feedback comme la qualité du code soumis, la rapidité et l’efficacité des retours, la résolution des bugs, le respect des délais. L’objectif individuel n’est pas mort pour autant : il s’agit de le lier aux axes de développement à savoir la compréhension business, la communication, la participation, le leadership/prise de décision et la pédagogie.

‍La productivité et la motivation d’un développeur vont de pair avec sa bonne intégration dans l’équipe. Ainsi si un développeur ne donne pas le meilleur de lui-même dans une équipe donnée, il y a de forte chance qu’il révèle tout son potentiel dans une autre équipe. Même si le risque de biais demeure, un questionnaire 360° demeure tout indiqué pour évaluer la qualité de la collaboration. Dans le cas où les collaborateurs se donnerait une bonne note, dîtes vous bien que l’entraide favorise la responsabilisation.‍

Lors de la mise en place d’un système d’évaluation des développeurs il s’agit d’anticiper les risques de conflits et d’incompréhension en expliquant votre démarches auprès des équipes. L’idée n’est pas d’évaluer à la ligne de code écrite mais d’offrir des clés de lecture pour orienter les collaborateurs vers des fonctions liées à leurs attentes et leurs centres d'intérêts.

Afin de responsabiliser les collaborateurs développeurs tout en renforçant la cohésion de groupe, il est important d’intégrer un feedback par les pairs, hors managers, dans les processus d’évaluation. Attention toutefois ce type de feedback est avant tout adapté pour une évaluation collective et non individuelle.