Catégories
Start-up et applications

Industry Watch: évaluer le travail et la valeur d'un développeur

C’est une nouvelle année et des organisations du monde entier donnent aux développeurs des objectifs pour la nouvelle année et revoient leurs efforts de l’année écoulée.

Une question que j’entends souvent est: «Comment évaluez-vous le travail d’un développeur et sa valeur pour l’organisation?»

Certaines organisations s'accrochent encore à la métrique des lignes de code produites par un développeur, ce qui – étant donné les responsabilités supplémentaires de test, de garantie de la sécurité, de respect des politiques et réglementations, etc. – pourrait ne pas être une juste évaluation dans le monde complexe d'aujourd'hui.

Cette méthode est ancrée dans le pointage du doigt du passé, ce que les organisations de développement modernes ont largement évité alors qu'elles cherchent à créer une culture irréprochable.

Les entreprises avant-gardistes examineront le rôle de l'équipe dans le développement, assemblée avec des ingénieurs logiciels, des testeurs, des experts en sécurité et des personnes du côté commercial, et examineront de manière globale les performances de cette équipe.

«Le nombre de lignes est une métrique terrible, et je pense que nous sommes tous d'accord là-dessus», a déclaré Chris Downard, vice-président de l'ingénierie chez Gigsmart, un site Web pour l'embauche de travailleurs de concert. «Il y a des moments… où cela pourrait être utile comme point de données supplémentaire, mais pas nécessairement pour information.»

Lorsque vous gérez des humains, a-t-il dit, réduire chaque action en points de données n’est pas bon. Il faut passer du temps à construire le contexte, car les données peuvent souvent déformer les choses. Chez Gigsmart, Downard a déclaré qu'ils n'utilisaient pas de sprints, mais adoptaient plutôt ce qu'il appelait «une approche de combat continue et non-stop». Mais ils utilisent des rapports de sprint, à partir de métriques capturées toutes les deux semaines, pour communiquer ce qui s'est passé pendant cette période.

Il a souligné qu'il savait ce que son équipe faisait entre les rapports de sprint – ils travaillaient dur, se jumelaient, et il a vu le nombre de demandes de fusion augmenter. «Mais l’un des indicateurs normaux de la productivité est le suivant:« Est-ce que nous déplaçons les choses d’un bout à l’autre de la ligne pour être livrées »au fur et à mesure que les points sont complétés», a-t-il déclaré, et ce nombre diminuait. Mais sur la base de leur connaissance de l’équipe et du contexte de tout ce qui se passe, ils ont réduit le nombre, sachant que la productivité de l’équipe était très, très élevée. «C'est juste la façon dont la billetterie a éclaté, produisant un point de données qui n'était pas nécessairement une indication de ce qui était exact», a-t-il noté.

En tant que leader organisationnel, a déclaré Downard, vous devez penser aux choses que vous voulez que l'organisation produise, puis réfléchir aux mesures qui indiqueront que vous réussissez ou que vous avez des difficultés. Différentes équipes, bien sûr, ont des objectifs différents.

"Si vous dirigez une équipe DevOps, vous vous souciez peut-être du temps de résolution, et si vous suivez la partie développement d'un service informatique, il peut s'agir d'un délai pour personnaliser les rapports et les données. Vous devez suivre les éléments qui comptent pour le succès de votre organisation. Donc, pour nous, je surveille le nombre de demandes de fusion pendant une semaine. Et nous ne faisons nécessairement rien avec ces données. Ce n’est pas un truc de la carotte et du bâton. C’est juste, cela me donne des informations supplémentaires. Un peu comme un médecin diagnostiquerait un patient.

Mais les points de données ne correspondent souvent pas à l'évaluation de la productivité des développeurs, car si une grande partie de la programmation implique le côté raisonnement logique du cerveau, elle implique également le côté créatif. Donc, pour Downard, les points de données brutes sont «généralement terribles. Mais ce que nous obtenons, ce sont de nombreux indicateurs souples. Vous obtenez des informations sur les mises à jour individuelles des personnes qui communiquent ce qu'elles pensent de ce qu'elles font. Vous obtenez des points de données concrets dans le sens où vous pouvez voir leur activité de validation, mais vous devez garder le contexte. » En tant que leader, a-t-il déclaré, vous devez défendre les développeurs et traduire ce qu'ils rencontrent à toutes les autres organisations du développement.

Downard a déclaré que Gigsmart utilise Bushido, le code de conduite des samouraïs qui définit les valeurs de la façon dont vous devez agir et vous conduire en tant qu'individu, comme son éthique organisationnelle. «Jason Waldrip, notre directeur technique et moi-même nous sommes assis et l'avons transformé en un ensemble d'idéaux pour conduire l'organisation, et j'utilise cela comme base pour tout ce que nous faisons. Donc, si je veux commencer à suivre quelque chose, il doit correspondre à une sorte de valeur à partir de là, car si j'essaie de suivre les choses qui ne correspondent pas bien à ces valeurs, je ne peux pas défendre ces valeurs avec le équipe. Ça ne va pas coller, ça va devenir creux. "

Les points de données, a-t-il dit, ne sont rien de plus que des signaux pour examiner quelque chose et commencer à poser des questions. «Et cela devrait toujours être exploratoire, pas accusatoire. C’est important pour nous.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *