Oui, ça pourrait
Mais seulement si vous le concevez très soigneusement, sinon cela pourrait se retourner contre vous. J'ai fait quelques commentaires mais j'ai pensé résumer ma position
Pour la réputation, l'objectif principal devrait être de fournir une mesure que les employés peuvent utiliser pour suivre leur amélioration des compétences au fil du temps. Concevez-le très soigneusement en gardant cela à l'esprit, le plus difficile est de trouver de bons moyens de mesurer les compétences, je ne peux pas du haut de ma tête le faire.
Les badges sont principalement une chose "amusante", je les garderais principalement à l'écart des problèmes plus axés sur les compétences. C'est-à-dire des badges comme "cette semaine, le hibou" ou un groupe "expédié! Badge" serait ok. Si vous avez des badges basés sur les compétences comme "Correction de la plupart des bogues" ou "Rapport de la plupart des bogues", réfléchissez très attentivement à la façon dont cela pourrait être perçu et joué. Les badges devraient davantage mettre l'accent sur la mise en évidence du comportement que sur sa promotion à l'OMI. Assurez-vous d'avoir des badges d'équipe et individuels.
Je recommanderais fortement contre les badges négatifs, ces choses devraient être amusantes et faire peur aux gens de faire des erreurs est dangereux. Générez plutôt un e-mail convivial et convivial pour ces cas.
Je déconseille fortement de les laisser décider et voter sur les badges. Les gens peuvent envoyer leurs suggestions de badges, mais comme leur effet sur les gens peut être assez grave, les badges utilisés doivent être déterminés par une décision prudente d'une personne qui sait ce qu'ils font et non par un vote majoritaire.
Les révisions de code sont une idée intéressante et je suppose que l'une des façons de générer une valeur de compétence. Mettre en évidence le code et en discuter pourrait être très utile. Cependant, cela pourrait se retourner, si tout le monde sait qu'ils sont jugés sur tout ce qu'ils écrivent, le développement peut ralentir. Surtout avec le développement itératif où vous écrivez parfois quelque chose rapidement et ensuite refactorisez vous ne voulez pas ce comportement.
Cela pourrait peut-être être compensé soit par la personne qui soumet le code elle-même, soit par quelqu'un d'autre qui ne peut soumettre que le code d'un certain âge. Néanmoins, il peut être difficile de savoir quels effets il y aura
À la fin, je pense que vous devrez l'essayer et voir ce qui fonctionne et ce qui ne fonctionne pas, il y a un bon livre intitulé Reality is broken qui pourrait être intéressant. Le livre "Drive" de Daniel Pinks est également à lire absolument.