Je ne suis pas d'accord avec l'affirmation que les gestionnaires ne regardent pas le code. Lorsque j'ai géré des équipes, j'ai examiné les résultats de chaque ingénieur - l'un des plus importants étant le code. Mais ce n’est pas le seul - courriels, documents de conception, livres blancs - tout est pris en compte.
Mais ce n'est certainement pas le seul facteur. Si un type est assis dans un coin et écrit un code brillant , mais qu'il est une bête à qui parler, ne répond pas aux questions, ne partage pas le statut et ne fait pas de compromis lorsque des problèmes de développement se présentent - je ne suis pas sûr qu'il soit un atout pour l'équipe. Surtout comparé à un gars qui écrit du code modérément décent mais qui peut faire tout ce qui précède.
Voici quelques éléments que je regarde quand je suis en mesure de donner des récompenses, mais avec l'énorme mise en garde qu'il s'agit absolument d'une réaction intestinale, car rien de tout cela ne peut être quantifié:
- Statut - est-il clair, précis et opportun? Lorsque discuté, la personne est-elle au-dessus du statut ou est-elle un peu floue sur les problèmes actuels? La personne a-t-elle le bon jugement pour lever un drapeau rouge lorsque quelque chose a pris feu?
- Résolution de problèmes - à la fois demander et répondre est important. La personne sait-elle quand demander de l'aide ou à quel endroit elle tourne indéfiniment? Mieux encore, lorsque les autres ont des problèmes, la personne aide-t-elle à trouver la solution ou à faire partie du problème? Même avoir le bon sens de faire marche arrière lorsque le problème ne relève pas de votre domaine de compétence vaut quelques points. Il existe également des points pour sortir du groupe ou de la société et accéder à des sites comme celui-ci, ou à d'autres réponses Internet.
- Attention au processus - cela est généralement assez évident - même dans une entreprise non réanimale, si quelqu'un bousille le système, cela se voit dans le chaos qu'ils laissent derrière eux. Si d'autres personnes nettoient les fonctionnalités d'une autre personne parce qu'elles ne respectaient pas les directives ou l'architecture, nous avons un problème. Les points bonus sont destinés à ceux qui trouvent des moyens de rendre la cohérence et la qualité plus faciles .
- Taux d'achèvement vs bugs vs complexité - accomplissez des tâches, mais faites-les correctement. Tout le monde a quelques bugs, mais si le gars fait les choses rapidement et buggy, nous avons un problème. Je trouve généralement que ce n’est pas quelque chose que vous pouvez évaluer au sens quotidien du terme. Il faut regarder en arrière une version, une phase ou un trimestre fiscal.
Et la contribution des autres. Je me suis souvent retrouvé dans une position où différents ingénieurs étaient en charge de différentes parties du projet. Parfois, les chefs d'équipe, et parfois juste les propriétaires d'un élément de sortie particulier (comme "le gars de la construction"). Les gens aiment parler des extrêmes - des actes d'héroïsme ou de la frustration des enfants à problèmes. Habituellement, dans le suivi de ces questions, je découvre beaucoup de choses sur les DEUX parties.
Il y a aussi un facteur dans la gestion des humains . Aucun ingénieur n'est exactement comme les autres. Donc, ils ne brillent pas tous de la même manière. L'un écrit un code sans bug, mais un autre aide à résoudre les problèmes de coupe qui cassent le code de chacun. On est super en personne, on est meilleur en écriture. L'un est incohérent à 9h00, l'autre à 15h00. Il ya un certain besoin de prendre du recul, de déterminer ce qui est le plus bénéfique pour l’équipe et ce qui pourrait être un facteur de partialité personnelle (comme le désir de tuer ce déchiqueteur à 4 heures du matin, simplement parce que je ne peux pas fonctionner avant 11 heures: 00h00).