Mon patron a décidé d'ajouter un champ «personne à blâmer» à chaque rapport de bogue. Comment puis-je le convaincre que c'est une mauvaise idée?


694

Dans l'un des derniers mouvements "WTF", mon patron a décidé que l'ajout d'un champ "Personne à blâmer" à notre modèle de suivi des bogues augmenterait la responsabilisation (même si nous avons déjà un moyen de lier les bogues aux fonctionnalités / histoires). Mes arguments selon lesquels cela diminuerait le moral, augmenterait l'indication des doigts et ne tiendrait pas compte des fonctionnalités manquantes / incompris rapportées comme des bogues sont passés inaperçus.

Quels autres arguments forts contre cette pratique puis-je utiliser? Y a-t-il une écriture sur ce sujet que je puisse partager avec l'équipe et le patron?


79
Salut les gars, je suis le "patron" qui a introduit le champ WTF. Voici pourquoi j'ai ajouté un champ "peson à blâmer" à notre système de suivi des bogues: news.ycombinator.com/item?id=4179298
Jason

98
"Aurais-je pu le nommer quelque chose de plus politiquement correct pour ne pas blesser les sentiments? Bien sûr. Mais quel est l'intérêt de cela? Le but était de sensibiliser au nombre de bugs de production après chaque publication, alors pourquoi ne pas en jeter une petite dose Et pour être clair, le but du champ, et finalement le but de la métrique, n’est pas de déterminer la cause du bogue, c’est la merde qui se passe et nous avons mieux à faire. la métrique est un rappel pour que chaque développeur soit meilleur chaque jour. " --- Je pense que toutes ces "raisons" sont intrinsèquement fausses.
ulty4life

31
@Jason au lieu d'inventer les champs de Jira, envisagez de recruter un ou deux testeurs . BTW dans votre cas ayant un champ de cause première (peu importe comment vous le nommez) a peu d'importance pour moi parce que vous avez déjà créé un lien entre l'absence de testeurs et l' augmentation du nombre de bogues de production .
Gnat

68
@Jason Le bogue est dans le code, pas dans un développeur. Vous devez être l'une de ces personnes qui pensent que les révisions de code sont destinées à l'examen des développeurs, et non du code.
Danny Varod

81
Votre patron est la "personne à blâmer",
inscrivez

Réponses:


675

Dites-leur qu'il ne s'agit que d'un nom amateur du champ Cause d'origine utilisé par les professionnels (lorsque le suivi des problèmes n'a pas de champ dédié, on peut utiliser des commentaires pour cela).

Rechercher sur le Web pour quelque chose comme le logiciel bug analyse des causes profondes , il y a beaucoup de ressources pour justifier ce raisonnement 1 , 2 , 3 , 4 , ... .


... une cause fondamentale d'un défaut n'est pas toujours un développeur unique (qui est le point principal de ce champ) ...

C'est exactement pourquoi "la cause fondamentale" est professionnelle alors que "la personne à blâmer" est amateur. La responsabilité personnelle est excellente, mais il y a des cas où elle se situe simplement à l'extérieur de l'équipe de développement.

Dites à votre patron quand il y a un seul développeur à blâmer, le champ de la cause fondamentale couvrira définitivement cela ( "erreur de codage faite par Bob dans le commit 1234, manquée par Jim dans le commentaire 567" ). L'intérêt d'utiliser le terme cause racine est de couvrir de tels cas, ainsi que des cas sortant du cadre de l'équipe de développement.

Par exemple, si le bogue a été causé par un matériel défectueux (la personne à blâmer étant une personne extérieure à l'équipe qui l'a acheté et testé), le champ de cause première permet de couvrir ce problème, tandis que "le développeur à blâmer" casserait simplement le flux de suivi des problèmes .

La même chose s'applique aux autres bogues causés par une personne extérieure à l'équipe de développement - erreurs de testeur, modification des exigences et décisions de gestion. Supposons que si la direction décide de ne pas investir dans du matériel de reprise après sinistre, "blâmer un seul développeur" pour une panne d'électricité dans le centre de données n'aurait tout simplement aucun sens.


13
C'est un bon point. Cependant, une cause fondamentale d'un défaut n'est pas toujours un développeur unique (qui est le point principal de ce champ). En conséquence, identifier un seul développeur responsable d'un défaut fait plus de mal que de bien, IMO.
MK_Dev

326
+1 pour avoir redirigé l'idée du patron vers quelque chose de plus productif (toujours plus facile de gagner une bataille de cette façon)
benzado

16
La "cause fondamentale" couvre également (espérons-le la majorité!) Des cas où aucune personne n'est à blâmer, des choses comme "défaillance logicielle du fournisseur", "erreur de documentation de l'API", "Volume supérieur à celui attendu".
James Anderson

29
Génial. Même votre exemple pour un seul responsable comprend deux personnes, illustrant parfaitement la stupidité de l'exercice.
Urs Reupke

15
N'oubliez pas que des "causes contributives" seraient également utiles car elles sont souvent plus faciles à traiter. Par exemple, si "la cause première" était "une erreur de codage dans le commit 5678" et que "la cause contributive" était "le commit 5678 n'a pas été examiné car les exigences sont arrivées trop tard", alors vous ne pouvez pas éviter toutes les erreurs de codage, mais vous pouvez être plus strict retarder la livraison la prochaine fois que les exigences sont retardées.
Jan Hudec le

272

Un autre résultat probable pour une telle politique est que les personnes ne signaleront pas de bogue si elles pensent être la "personne à blâmer", ce qui réduira en fait le nombre de bogues signalés par l'équipe.


300
Eh bien, le patron sera content! Il y aura moins de rapports de bugs, et par conséquent, la qualité doit avoir été améliorée .
nicodemus13

5
Le patron est probablement sur la rémunération liée aux performances et un indicateur de performance clé est le nombre de bugs signalés. Espérons qu’il partagera son bonus avec l’équipe de développement à la fin de l’année.
Matt Wilko

54
Par expérience, ce n'est pas un résultat "probable", il est à 100% certain que cela se produira, car les développeurs sont des personnes intelligentes. Vous constaterez également une augmentation considérable du temps passé à discuter violemment avec les testeurs que leurs "bugs" ne sont pas des bugs.
Joris Timmermans

La personne qui signale le bogue ne sera probablement pas la personne que root causeje veux dire, je pense à essayer de trouver une erreur dans votre propre code après 36 heures d'écriture de code cette semaine?
Malachi

141

L'argument principal que j'utiliserais contre cela est de demander quel problème il essaie de résoudre. Il y a presque certainement de meilleurs moyens de résoudre le même problème.

D'une part, n'y a-t-il vraiment qu'une seule personne à blâmer? Si c'est le cas, vous faites autre chose de mal. Un bon processus nécessite un travail effectué par un analyste, un programmeur, un réviseur et un testeur avant sa mise en production. Si vous ne faites pas toutes ces étapes, c'est peut-être la solution au problème que votre patron tente de résoudre. Si vous êtes alors lequel est à blâmer? Ce n'est peut-être aucun d'entre eux, ce pourrait être le code hérité qui est à blâmer.

Il ne sert à rien que les gens piquent et pointent du doigt, essayant d'éviter une marque noire qui ne disparaîtra pas une fois fixée. Cela ne résout rien. Très peu de personnes font preuve de malveillance par négligence. Vous devez faire une rétrospective appropriée , voir ce qui ne va pas et ce que vous pouvez faire pour vous assurer que cela ne se reproduira plus.

À partir de là, vous verrez clairement si une personne est régulièrement en faute et le problème peut être différent.

L'astuce pour empêcher un responsable de créer de la responsabilité est de l' offrir librement , mais d'une manière qui a du sens pour vous.


5
Un très bon processus évite que l’analyste et le programmeur soient deux personnes différentes - mes expériences avec des analystes qui ne peuvent pas programmer et des programmeurs qui ne peuvent pas analyser étaient vraiment mauvaises. Néanmoins, +1 pour votre réponse.
Doc Brown

@ DocBrown bien que mes expériences avec l'analyste et le programmeur d'être deux personnes différentes ont été plutôt positives jusqu'à présent. Bien que dans mon cas, c’était plutôt des analystes capables de comprendre la logique de programme et des programmeurs pouvant participer à l’analyse :)
gnat Le

@gnat: à mon humble avis, si l'analyste est l'un des programmeurs de votre équipe, il peut améliorer votre vitesse et votre qualité de développement d'un ordre de grandeur.
Doc Brown

3
Ce livre vous aidera à trouver les mots qui vous tiennent
tête

2
Le lien pour "offrez-le librement" est cassé.
Tom Fobear

79

Il y a au moins trois problèmes dans ce domaine.

La première est que blâmer les gens n'est pas bon pour le moral. D'accord. Mais peut-être ne se soucie-t-il pas du moral et veut-il renvoyer les mauvais développeurs. Difficile de discuter contre.

Deuxièmement, il sera difficile de réussir dans ce domaine et de perdre beaucoup de temps. C'est plus complexe que de trouver qui a écrit le mauvais code. Et toute information potentiellement difficile à comprendre peut faire l’objet d’un sac de sable. Mais peut-être qu'il est prêt à payer ce coût et à vérifier l'information. Bien.

La question la plus fondamentale est que ce domaine ne sera pas un bon indicateur pour prendre des mesures. Bien sûr, il aura un bon classement du code qui cause le plus de défauts. Mais devinez qui sera en tête de cette liste? Probablement le fondateur de la société, ou peut-être un développeur de haut niveau qui a un taux de défauts très bas mais qui est si productif qu'il écrit une partie démesurée du code. Il finira donc par renvoyer son meilleur développeur ou le ralentira tellement qu'il n'est plus son meilleur développeur. Et le gars qui écrit une ligne de code chaque mois - de préférence des commentaires - sera probablement récompensé pour ses faibles nombres de défauts.

Encore un autre échec de métrique de logiciel.


16
Je suis surpris que personne d'autre n'ait mentionné le fait que l'analyse de l'historique d'une erreur dans des tentatives d'attribution de blâme va être un énorme gouffre temporel. Si aucun autre argument ne mord, ça devrait.
un CVn

Vous corrigez donc les erreurs sans chercher à connaître l'historique et la cause première? À ce stade, vous corrigez les symptômes et vous ignorez peut-être les problèmes fondamentaux légitimes. S'il s'agit réellement d'un problème avec une personne, il est utile de savoir pourquoi cette personne a commis l'erreur afin que celle-ci puisse être corrigée. S'il s'agit d'un matériel défectueux, celui-ci peut être remplacé par quelque chose de plus stable.
Jordanie

Je vais bien avec blâmer / louer des individus. Mais cela doit être fait avec beaucoup de soin, car il est facile de causer de plus gros problèmes en essayant de le faire que le problème initial. Le champ "coupable" ne ressemble pas à une approche "très prudente".
ptyx

68

La cause première d'un défaut sur le terrain n'est jamais une seule personne. Des personnes parfaitement consciencieuses commettront des erreurs, et un processus qui les attend infaillibles est déraisonnable. Si vous ne vérifiez pas les modifications apportées aux systèmes de production avant le déploiement, que ce soit manuellement ou via des tests automatisés, les bogues sont inévitables.

Faux:

Bob oublie de vérifier les entrées et le programme a planté en divisant par zéro.

Droite:

Le code vulnérable à une erreur de division par zéro n'a pas été détecté avant le déploiement. De nouveaux cas de test ont été ajoutés pour vérifier le traitement correct des entrées non valides. Le code a été corrigé et tous les nouveaux cas de test réussissent.


6
Encore mieux: les directives / normes de codage et les listes de contrôle de révision du code ont été mises à jour pour éviter que cela ne se reproduise.
Bizarre pensées

Et si les bugs sont inévitables? Quel est le problème avec blâmer quelqu'un pour eux? Je pense que votre option "Wrong:" est plus claire que votre option "Right:". Le mauvais est vraiment simple. Le «droit» est celui qui parle.
Adam Bruss

3
@Adam: Ma réponse ne répond-elle pas directement à votre question exacte "Pourquoi ne pas blâmer quelqu'un ...?"
Kevin Cline

54

Changer "Personne à blâmer" en "Personne à louer"

La personne responsable de la correction des bugs porte son nom.


9
Je ne pense pas que cela réponde à la question. C'est un bon sentiment, mais ne fournit pas d'arguments contre un tel champ.
Bryan Oakley

21
De plus, vous savez qu'un gars présentera des centaines de bugs "accidentellement" puis les corrigera tous, en espérant qu'un manager idiot sera assez stupide pour se dire qu'il est le meilleur correcteur d'insectes ...
MGOwen

Très souvent, vous voulez savoir qui a écrit le code et qui est le mieux qualifié pour le réparer en cas de problème. Une partie du contrecoup de "personne à blâmer" est que cela implique que quelqu'un est blâmé.
Muz

49

Réponse simple.

Le champ "Blame" ne sera utilisé que pour les boucs émissaires et les doigtés, le moral va s'effondrer, la confiance de l'équipe sera détruite et tout le monde tentera de trouver le moyen de prouver que quelque chose n'est pas de sa faute au lieu de le réparer. Les gens seront également plus enclins à garder le silence sur les bugs au lieu de les signaler, car ils ne veulent pas que leurs collègues aient des problèmes. C'est complètement contre-productif.

Quoi de plus important, victimiser quelqu'un pour avoir commis une erreur honnête, ou avoir résolu le problème le plus rapidement possible?

Votre patron semble penser que les insectes sont un signe de paresse ou de négligence. Ils ne sont pas. Ils sont une réalité de la vie. Combien de correctifs Microsoft envoie-t-il en un an?


8
+1, une culture de la faute mène toujours à une culture de la garde du silence sur les bugs et en espérant que personne ne le remarque
Carson63000

45

Si vous êtes prêt pour un peu de désobéissance civile, demandez à l'équipe d'accepter de mettre une liste de tous les développeurs dans ce champ pour chaque bogue. Si cela ne vous convient pas, écrivez "Je suis Spartacus!" au lieu. Bien entendu, le fait est que vous êtes tous responsables de tous les bogues et que vous n'êtes pas content de devoir désigner la personne qui a créé un bogue.

Une autre option: jouer le long. Ne faites rien de particulier, faites du bon travail et remplissez le champ aussi précisément que possible pendant quelques mois. Puis expliquez au patron que l’attribution d’une faute à chaque bogue rend tous les membres de l’équipe malheureux et inconfortables. Dites-lui que vous avez tous l'impression qu'il y a peu de corrélation entre les bugs créés et toute autre chose (compétence, effort, santé mentale). (Cela vous aidera si vous pouvez utiliser des chiffres montrant qu'il n'y a pas vraiment de corrélation.)

Désobéissance civile gandhienne: Indiquez votre nom sur tous les domaines (à moins que d'autres développeurs n'interviennent et signalent leurs bogues), et acceptez de blâmer chaque bogue, qu'il soit vôtre ou non. Rien ne rendra ce champ ou l'idée de blâmer quelqu'un plus inutile que cela. Si votre patron vous demande pourquoi vous vous appelez dans tous les domaines, vous pouvez expliquer "parce que je ne pense pas que le développement est un jeu de reproches, si vous avez vraiment besoin que des personnes soient blâmées et crucifiées, alors crucifiez-moi pour tout et laissez mon équipe travailler en paix." . "


15
Je voterais pour le premier paragraphe, mais le second me semble douteux. D'après mon expérience, les types de personnes qui proposent des idées comme un champ de blâme ne sont pas ceux qui craignent de rendre les gens mal à l'aise.
GordonM

@GordonM Cela dépend vraiment de la personnalité du patron. Un type plutôt honnête, souffrant-sans-imbéciles pourrait ne pas bien regarder l'approche de Spartacus, mais pourrait tout de même être disposé à admettre que le domaine crée plus de problèmes que d'avantages. Si l’opérateur et l’équipe montrent qu’ils respectent le chef assez pour qu’il teste son idée, il les respectera peut-être assez pour l’écouter quand ils lui diront par la suite que cela ne semble pas utile. En outre, il sait peut-être que le PO n’a pas connaissance de quelque chose, comme par exemple le fait qu’il est sur deux, hérite de quelques perdants d’une autre équipe et veut être en mesure de collecter des mesures.
Caleb

3
De plus, l'équipe souffrira encore. Tout simplement pour prouver que le patron avait tort?
Oleg V. Volkov

29
J'y mettais toujours le nom du responsable. "Dans toute organisation, le travail est au fond des choses, tandis que la responsabilité flotte au sommet"
David Schmitt le

3
@ David: La crème et l'écume flottent vers le haut. De quoi avez-vous affaire dans votre organisation?
Donal Fellows

32

Un jour, un patron a mis en place un système très similaire à celui-ci. Bien que ce ne soit pas une programmation (il s’agissait d’une conception imprimée pour un quotidien), le concept et la réponse appropriée sont les mêmes.

Au lieu d'ajouter un champ «personne à blâmer» sur nos documents, elle a remis à chacun des concepteurs un ensemble d'autocollants colorés. Chaque concepteur a reçu un autocollant de couleur différente et a été informé que pour toute conception travaillée ou même touchée, la vignette devait être ajoutée à la documentation de cette conception.

L'objectif déclaré du patron pour "l'initiative des autocollants" était de déterminer la source de toutes les erreurs de notre service (erreurs dans la paperasserie, erreurs de classement, copie incorrecte, essentiellement l'équivalent imprimé de bugs).

Ce que nous avons fait a été de donner à chacun des autres concepteurs un quart de nos autocollants afin que nous puissions chacun avoir toutes les couleurs. Au lieu de simplement mettre notre couleur sur chaque motif, nous avons mis les quatre couleurs des concepteurs.

N'écrivez pas simplement votre nom dans la case [Blame] - indiquez le nom de chacun dans l'équipe / le projet et assurez-vous que toute l'équipe fait de même.

Nous avons travaillé ensemble contre sa chienne orwellienne et, en conséquence, nous avons fini par rattraper les erreurs des uns et des autres et à nous en parler, ce qui a finalement abouti à une réduction significative des erreurs. Cependant, elle était une gestionnaire de bord et, au lieu de reconnaître que son initiative avait fini par nous unir et accroître sa productivité, elle a tout obtenu, a dissous le système de vignettes et l'a déclaré échec. Elle nous a tous officiellement réprimandés.


1
Votre histoire était drôle et répond presque à la question. Vous pourriez envisager d’ajuster le ton et le verbiage pour une lecture plus positive. Sinon, vous continuerez à avoir un vote négatif. (J'ai voté pour votre réponse.)
Evik James Le

20

Cela finira par punir son programmeur le plus prolifique. Les chances sont, une ou deux personnes pourraient être les meilleurs employés qui ont travaillé sur la plupart des projets. Si vous avez, dans un département de 10 personnes, un codeur qui est juste une source de sortie et qu'il a écrit 60% du code d'interface, alors 60% des bogues seront dans son code.

Expliquez que ce système donnerait l’impression que la personne qui écrit le plus de code est le pire programmeur, et la personne qui écrit le moins de code est le meilleur programmeur.


20

Cela ressemble beaucoup à la situation où Scott Adams avait souligné la sagesse manquée du Bug Bounty lorsque le chef aux cheveux pointus de Dilbert. Wally a annoncé qu'il allait lui écrire une nouvelle mini fourgonnette ".

Bande dessinée Dilbert du 13/11/1995 dans les archives officielles de la bande dessinée Dilbert.

Je me souviens d'une fois, quand Snow Skiing, quelqu'un a fait remarquer que «ne pas tomber» n'était pas le signe d'un bon skieur, mais souvent celui d'une personne qui n'essaie pas (ou ne skie pas du tout).

Des bogues peuvent être introduits dans le code en raison d'une mauvaise programmation et d'une mauvaise conception. mais, ils peuvent aussi être la conséquence de l'écriture de nombreux codes difficiles. Dinger les personnes qui produisent le plus de bugs est tout aussi probable pour les développeurs Ding pauvres que les plus productifs.

Il semble que votre patron soit frustré par le nombre de défauts. Les membres de votre groupe sont-ils passionnés par la qualité? Créer un champ "quoi" pour la cause plutôt qu'un champ "qui" pourrait être plus productif. Ex.: Modification des exigences, défaut de conception, défaut de mise en œuvre, etc. Même si cela échouera, à moins d'un groupe pour améliorer la qualité du produit.


19

Peut-être devriez-vous le regarder comme "Qui est le mieux placé pour corriger le bogue?" Une partie de moi aussi sent, tu l'as cassé, tu le répares. Il devrait y avoir une certaine responsabilité.

Je ne suis pas d'accord avec garder une sorte de score. Certaines personnes créent plus de bogues car elles travaillent sur des parties plus complexes du code. Si les lignes de code ne sont pas une métrique utile, je doute que les bogues par lignes de code soient meilleurs. Le code ne sera jamais enregistré

À un moment donné, un manager devrait savoir qui fait son travail et qui ne le fait pas, ainsi que qui le fait mieux parce que le reste de l'équipe le fait.


19

Il est étrange que personne ne l’ait mentionné auparavant: l’ajout d’une telle fonctionnalité au système de suivi des bogues inciterait les employés à essayer de jouer au système .

C'est un problème courant pour des approches telles que celle présentée dans la question, parmi d'autres idées similaires (payer en fonction du nombre de lignes de code, payer en fonction du nombre de bogues). Cela en encouragera beaucoup à se concentrer sur l'obtention d'un bon score, au lieu de résoudre les problèmes liés au logiciel sur lequel ils travaillent.

Par exemple, essayer de soumettre un rapport de bogue avec un libellé pour atténuer son blâme et le renvoyer à quelqu'un d'autre peut amener les développeurs à mal comprendre la cause du problème (ou le travail confié à un autre développeur qui ne connaît pas cette section de un code aussi bon que celui qui y travaillait le plus et qui était la principale cause du bogue) nécessitant plus de temps et d’efforts pour résoudre le problème.


18

Votre question portait sur la manière de changer la culture avant de quitter l'entreprise, en convaincant votre patron que le fait d'ajouter une personne à blâmer pour les rapports de bogues est une mauvaise idée. Mais bien sûr, pour changer de culture, il doit vraiment comprendre pourquoi c'est une mauvaise idée.

C'est un défi de taille. Outre la question de sauver la face après avoir changé d'avis, il existe un problème fondamental: les personnes qui pensent aux solutions principalement en termes de reproches individuels sont généralement bien ancrées dans cet état d'esprit.

Vous avez demandé à écrire sur ce sujet, et Peopleware vient à l’esprit. Il est hautement considéré et parle en termes généraux de la façon de gérer les personnes qui font un travail créatif lorsque le résultat est difficile à mesurer. Le problème, c'est que si vous le lisez, cela ne vous aidera pas beaucoup, votre patron devrait le lire et en croire au moins une partie.

Bizarrement, étant donné que le problème ici concerne davantage les personnes que les rapports de bogues, il appartient probablement davantage au lieu de travail qu'aux programmeurs. Mais le succès des projets logiciels dépend généralement beaucoup de l’interaction sociale entre l’homme et les vraies réponses portent donc souvent sur des choses qui transcendent les logiciels.

Ma seule autre suggestion, légèrement sérieuse, est de dire (ou de convaincre un collègue de dire, puisque vous envisagez de partir) que vous êtes prêt à assumer l'entière responsabilité de la réussite du projet et que votre nom doit toujours aller sur le terrain. car même si quelqu'un d'autre a commis l'erreur directement, vous avez la responsabilité de vous assurer que tous les membres de l'équipe effectuent un travail de qualité.

C'est absurde, bien sûr, comment pourriez-vous jamais revenir en arrière, mais certaines personnes (surtout les gros coupables) mangent vraiment ce genre de choses. Ronald Reagan avait l'habitude d'assumer publiquement sa responsabilité personnelle chaque fois qu'un membre de son administration était pris dans un scandale (et il y en avait plusieurs) et que tout se passait plutôt bien politiquement. La meilleure partie pour vous est que la responsabilité n'entraîne généralement aucune conséquence réelle, ils pensent simplement que vous êtes un type à prendre pour la responsabilité.

Ou peut-être que ce n'est pas comme ça que ça va aller. Cela n’a aucun sens pour moi, alors il m’est difficile de prédire quand cela fonctionnera, mais j’ai été témoin du fait que cela fonctionnait alors qu’il semblait ne pas y avoir d’affaires (sur le lieu de travail, pas seulement l’exemple de Reagan).


+1 pour avoir suggéré d'expliquer de manière positive comment gérer les travailleurs de l'information, plutôt que de simplement attaquer cette idée.
Bizarre pensées

14

Les gens ne vont pas au travail avec la ferme intention de commettre des erreurs, et toute stratégie mise en place pour imputer de manière spécifique la responsabilité de ce qui peut être ou non une erreur humaine est ridicule - pour ne pas mentionner un manque de professionnalisme extrême.

Au minimum, une "partie responsable" chargée de prendre en charge et de "régler" le problème, ou d'élaborer un plan pour suivre et / ou empêcher que de tels événements se produisent, serait une bonne chose. Parfois, la solution n'est rien de plus qu'une formation supplémentaire. J'ai travaillé pour un certain nombre d'entreprises où cela faisait partie de votre description de travail, pour obtenir une formation "entreprise rémunérée / temps passé en entreprise". Un endroit a même construit tout un "centre de formation", que le collège local "emprunte" à l'occasion, pour ses cours sur les technologies industrielles.

Je travaille dans un environnement manufacturier depuis 20 ans, où les erreurs de programmation ne font pas que causer des erreurs, elles détruisent physiquement des choses et / ou, pire, elles blessent des gens. Cependant, dans tous les domaines de la fabrication, une constante est qu’il n’ya jamais de responsable. Parce que c'est un défaut du système, clair et simple - pas un défaut du personnel. Examinez-le de la manière suivante: l’utilisation du correcteur orthographique - un outil extrêmement efficace, pour les moins fortunés dans le domaine de la virtuosité textuelle, ou peut-être simplement ceux qui sont un peu trop travaillés… mais en aucun cas une méthode de blâme ou de responsabilité.

Un environnement de travail, quel que soit son type ou son objectif, est un système. Un système composé de composants individuels qui, s’ils sont correctement "accordés", fonctionne en totale harmonie - ou un semblant de ce genre.

Suggestions de lecture de la part de votre patron: Les 7 habitudes des personnes extrêmement efficaces

On dirait qu'il pourrait utiliser un peu d'humilité, sinon une vérification de la réalité. Il fait tout autant partie de l'équipe que tout le monde et il doit se rendre compte que cela ne fonctionnera tout simplement pas et qu'en fin de compte, il tiendra le sac malgré tout.

Suggestions de lecture et / ou de recherche de votre part:

Examinez les raisons pour lesquelles l'analyse, l'analyse des causes fondamentales ... tout ce qui vous permet de mieux proposer une solution, pas un problème . Et votre désaccord avec votre patron, c'est juste que, un problème, pas une solution. Offrez-lui quelque chose de mieux, quelque chose qui a du sens, et soyez même prêt à lui permettre de prendre le crédit pour cette idée.

À l'heure actuelle, il ne semble pas qu'il soit prêt à réparer quoi que ce soit, car il ne comprend pas bien ce qui est brisé, s'il y a quelque chose de brisé, à part sa mentalité "je suis le patron".

Bonne chance! J'espère que vous réussirez à vous en sortir, d'une manière qui soit acceptable pour tous, surtout en ces temps difficiles.

EDIT: Personnellement, de ma propre expérience ... "Allez-y, reprenez-moi. Parce que bien sûr, je vais le réparer, et sur la route, quand cela se reproduira, qui sera là pour sauver la journée? Yep, vous deviné ... moi, avec un grand sourire. "


"vous met dans une meilleure position pour offrir une solution, pas un problème." - Ouais, qui est le point principal de ce post. Je ne m'attendais pas à ce que ça explose comme ça.
MK_Dev

En fin de compte, ce sera soit un succès d'équipe, soit un échec d'équipe - et quel que soit le plan d'action (y compris le jeu du blâme) ne fonctionnera pas, ou même sera prouvé une mauvaise idée, s'il n'est pas suivi jusqu'à réalisation ou échec. En d’autres termes, l’alternative à la mutinerie peut en réalité consister simplement à suivre votre plan à la lettre, avec la participation active de tous - en vue de la collecte inévitable de données fiables, pour peser en faveur ou à l’encontre de la poursuite de ce chemin. de la raison.
Tahwos

10

Pour la responsabilité, je ne voudrais pas d'un person to blamechamp, je voudrais un Person who knows the codechamp ou un person who can fixchamp, afin de savoir où envoyer le ticket d'assistance.

Cela accélèrerait le processus de correction du bogue lui-même et donnerait une responsabilité, un peu comme tuer deux oiseaux avec une pierre. Personnellement, je le lui demanderais et le laisserais décider si cela contribuerait à améliorer le moral et la responsabilisation sans que quiconque ait l'impression qu'ils ont échoué. Les tests extrêmes ne détectent pas tous les bogues, sinon il n'y aurait pas de rapport de bogue.


9

Dites-lui que "le blâme" est négatif. Changez-le en "personne à réparer" alors au moins, il est encadré de manière positive, et le même travail est toujours fait. Comment les gens peuvent-ils travailler s'ils se font "blâmer"?!


2
Vous ne pouvez pas "réparer une personne" ...
SandRock

1
Nous avons le champ "personne à réparer". Ce n'est pas assez
MK_Dev

9

Si mon supérieur hiérarchique agissait de la sorte, voici ce qui se passerait dans cet ordre:

1) Je commencerais immédiatement à chercher un nouvel emploi.

2) Chaque fois qu'un bogue est blâmé avec une personne à blâmer, le nom de mon patron y apparaît, et un commentaire expliquant pourquoi un mauvais processus dans l'équipe en est responsable. Et CC ça à son patron (de préférence en lot). Avez-vous des tests unitaires? Sinon, cela signifie que le processus de développement est interrompu, d'où le bogue. Avez-vous des tests d'intégration automatisés constants avec tous les systèmes externes? Ensuite, le processus de développement est interrompu, d'où le bogue. Avez-vous la possibilité de rendre chaque environnement identique dans la production via un script pour éviter toute erreur humaine? Ensuite, le processus de développement est interrompu, d'où le bogue. Un développeur est-il terrible? Ensuite, le critère d’embauche est le badm, donc la faute du patron. Tous les développeurs font-ils des erreurs stupides par manque de repos parce qu’ils travaillent 12 heures par jour? Ensuite, le processus de développement est brisé.

Remarque: chaque bon responsable du développement est conscient de ce que j'ai écrit ci-dessus. Et les stratégies Agiles ont pour but de montrer au patron ou à son supérieur pourquoi le ralentissement du développement ralentit: Regardez, nous passons 50% de notre temps à réparer les bugs. Examinons des stratégies pour les réduire afin que nous puissions passer 40% du temps à réparer les bogues, puis réexaminons ce problème pour le ramener à 30%. etc.

Malheureusement, il semble que vous n’ayez pas un bon manager à cause du terrain. Je suggère donc de faire (1) et de ne pas en parler au responsable (sauf lors de votre entretien de départ)


8

Il semble que votre patron n’a pas une connaissance approfondie des logiciels et qu’il n’en a peut-être pas l’intention. Donc, il a une langue différente, une culture différente.

Quitter un emploi pour un problème comme celui-ci, avant même d'essayer de trouver une solution, c'est simplement être un lâcheur. Quitter, c'est quitter. N'abandonnez pas avant qu'il ne vous assure que vous ne pourrez jamais vous comprendre. Pour en être sûr, vous devriez d'abord essayer.

Puisqu'il ne connaît pas notre langue et qu'il est le chef, la première étape serait d'essayer de lui parler dans sa langue. Qu'est-ce que je veux dire avec la langue? Pensons ensemble:

Nous, spécialistes des logiciels, la plupart d’entre nous aimons le travail que nous accomplissons, nous avons un lien profond avec ce que nous faisons. Sinon, cela ne fonctionne pas et on ne peut pas continuer longtemps dans cette affaire sans l'aimer ou en être un complet ... vous remplissez les blancs ...

Cependant, il voit les choses très différemment. Avec chaque rapport de bogue, alors que la plupart d’entre nous sont enthousiastes à l’idée de rendre le système plus performant (non, même si c’est parfois très stressant, nous adorons les problèmes, admettez-le juste!), Il le voit comme un échec, une mesure d'être infructueux. La première chose qu’il devrait comprendre, c’est que les bugs sont bons. Les insectes font que les clients aiment l'entreprise. (Maintenant, c'est sa langue) Lorsqu'un client rapporte un bogue, ou lorsque nous en trouvons un nous-mêmes, une fois résolu, le problème est bien meilleur que la situation ne s'est jamais produite. Les bugs créent la fidélité des clients (je suis sérieux!), Les bugs constituent une excellente excuse pour la communication entre le consommateur et le producteur du logiciel.

Pour "augmenter le bénéfice des bogues", vous devez proposer de rendre les rapports de bogues encore plus ouverts. Avec chaque rapport de bogue et sa solution rapide, propre et efficace, les clients ressentent et constatent que "wow, ces gars-là sont géniaux! Ils travaillent très dur. Regardez ce qu'ils sont en train de résoudre. Nous ne savions même pas que le logiciel était si complexe. chose!" bla bla et bla ...

Fais ton geste, parle dans sa langue. Les bugs sont parfaits pour une entreprise de logiciels, pas un problème. Ils nous font vivre.

Pour l’éthique d’équipe, l’efficacité ou tout autre type de discours que vous feriez peut-être fonctionner de la manière opposée. Si vous voulez arrêter de fumer, il va penser "aha, ma solution a commencé à fonctionner dès le premier jour! Les mauvais liens ont déjà commencé à disparaître d'eux-mêmes avant d'être exposés!" Il croit en son idée de trouver les mauvais garçons de la compagnie et il est très difficile de le convaincre du contraire. Surtout quand vous pourriez être l'un de ces mauvais garçons!

Alors, concentrez-vous sur son vrai problème: Bugs. Montrez-lui que les insectes peuvent être très utiles. Sans aucun problème, une relation est ennuyeuse. Tout ce qui ne vous tue pas vous rend plus fort. Chaque bogue est une excellente occasion d’augmenter le bonheur de vos clients.

Ceci est juste une chose que vous pouvez dire. Pensez à ses préoccupations et vous trouverez de nombreux autres éléments à ajouter à votre liste. La clé d'or est d'offrir une alternative au lieu de se battre avec son idée!


5
Pas le vote négatif, mais la question disait explicitement que de nombreuses tentatives avaient été faites pour convaincre le patron que c'était une mauvaise idée. Le deuxième paragraphe de votre réponse n'était donc pas approprié.
Larry Coleman

8
Je ne suis absolument pas d'accord avec l'idée qu'il est stupide de quitter un emploi quand l'entreprise le fait. Ce n'est pas votre problème de réparer l'entreprise. Si mon départ confirme la propre logique du patron à ses yeux, c'est son problème. cela a cessé d'être le mien au moment où je suis sorti de la porte.
Nate CK

Je préfère essayer de résoudre tout ce que je peux. Dans une telle situation, si j'arrête, l'entreprise restera sans solution, du moins par moi. Si je peux facilement réparer quelque chose au lieu de commencer à autre chose à partir de rien, je préfère essayer de réparer. Pour moi, dans cette situation particulière, il s’agit de calculer la différence d’effort, de temps et de stress / investissement psychologique de toute façon, ainsi que le résultat que je peux atteindre ... Merci beaucoup pour votre commentaire. Il est beau que nous ayons tous une vue du monde différente :)
hasanyasin

Évidemment, si je voulais cesser de fumer, ce poste n'existerait pas. @Hasanyasin, merci pour la perspective post-intéressante. Le chef, cependant, est un technicien, un développeur et un technicien, ce qui ne fait que rendre ce problème plus problématique.
MK_Dev

@hasanyasin À propos de la bonté de bug - Il est excellent! Je suis triste je ne peux pas mettre deux upvotes! Je vais l'utiliser moi aussi!
Gangnus

8

Si vous faites de l’agile, cela ressemble à du commentaire sur les caractéristiques / histoires . La personne à blâmer serait la personne d'assurance qualité qui aurait laissé le bogue passer au travers, ou le propriétaire du produit / client qui aurait accepté la fonctionnalité / l'histoire comme complète avec le bogue qu'il contenait.

J'ai fait la composition dans la journée, voici mon point de vue.

Cela revient à blâmer un compositeur pour des fautes d’orthographe et autres choses qu’un correcteur aurait dû trouver mais qu’il aurait manquées. Le dactylographe a mal orthographié, mais le relecteur l'a manquée. C'est donc le relecteur à blâmer pour l'erreur d'impression, et non la personne qui a commis l'erreur au départ.

Dans un environnement agile, il incombe aux personnes responsables de l'assurance qualité de détecter les erreurs (bugs) et aux propriétaires de produits de ne pas accepter des choses qui ne sont pas correctes. Il s’agit de deux niveaux de lecteurs d’épreuves qui doivent isoler les développeurs des éléments publiés, ce qui est la seule façon de classer tout ce qui doit être classé comme un bogue dans un environnement Agile.


3
Pour aggraver les choses, les développeurs sont maintenant aussi des QA. Je sais ...
MK_Dev

Quelle attitude dérangeante.
pdr

1
Agile, toute l'équipe est "la personne à blâmer". Agile valorise l’équipe sur les individus et c’est toute l’équipe qui développe l’application; chaque bogue est donc le problème de toute l’équipe. Pensez à la situation lorsqu'une construction échoue sur un serveur CI. Toute l'équipe doit cesser de travailler et voir si ce qui doit être fait. Au moins c'est ce que cela devrait être!
Sgoettschkes

@Sgoettschkes Je suis théoriquement d'accord avec vous à 100%, toute l'équipe est responsable du produit fabriqué. Mais si vous essayez de sélectionner une personne en particulier, ce sont les personnes qui vérifient le travail qui sont le plus responsables de le laisser passer.

7

Je pense que votre responsable essaie de résoudre un problème avec la mauvaise solution. Je pense que le problème est peut-être que trop de bogues ont été publiés et que votre responsable souhaite que les développeurs prennent davantage en charge le code qu’ils écrivent.

Le développement piloté par les tests et la mise en place d’un serveur d’intégration continue (comme Jenkins ) aideront à résoudre ce problème, sans introduire le "jeu du blâme". Un serveur d'intégration continue est important pour cela, car lorsqu'une personne commet un code qui "rompt la construction", un courrier électronique est envoyé à l'équipe pour lui montrer le responsable. Puisque ce code n'a pas été publié dans un environnement de production, ce type de blâme est plus proactif et encourageant (et amusant!).

Le résultat est que les développeurs vont s'approprier davantage, se sentir plus en confiance et qu'il y aura moins de bugs dans le code de production.


Je suis d'accord avec votre première déclaration à 100%. C’est à peu près ce que j’ai dit lorsque j’ai parlé de la question.
MK_Dev

7

Indiquez que si l'erreur d'une seule personne entraîne la fin d'un bogue dans la production, votre méthodologie ou votre méthode globale de développement de logiciels présente un problème. Indiquez que toute l'équipe est responsable d'empêcher que des bugs n'atteignent la production.

En utilisant l’un ou l’autre de ces arguments, voyez si vous pouvez convaincre votre patron qu’avoir le champ "à blâmer" en tant que champ à sélection unique serait trompeur; et que, par conséquent, il est nécessaire de s’assurer que le champ "à blâmer" est un champ à sélection multiple. Une fois que vous avez réalisé cela, assurez-vous que pour chaque bogue, le nom de tout le monde est sur le terrain. Votre patron finira par se rendre compte que tout compte rendu sur le terrain est inutile.


6

Pour donner un peu de crédit au patron, le concept d '"attribution de responsabilité" est déjà intégré dans des outils tels que SVN , et une utilisation appropriée des données peut aider les développeurs à "trouver à qui parler" lors du débogage, par exemple: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Bien que je sois d’accord avec la réponse de gnat ci-dessus selon laquelle un champ de cause principale est une bonne chose, il ne s’agit pas de la même information, et il est parfois "dénormalisant" le champ pour attribuer le ou les noms de développeur précédent (s) à la source affectée. Une description technique (par exemple, "n'a pas évolué jusqu'à 10000 utilisateurs") ne fera que brouiller les pistes. Je préconise de garder une cause fondamentaleIndiquez clairement une description technique (par exemple, même si une erreur de programmation est claire, demandez-lui de saisir des détails tels que "Exception IndexOutOfRange lorsque fooData = 999"). Cela peut potentiellement fournir des informations utiles lorsqu’elles sont examinées en masse et permettre l’adoption de mesures correctives. pour résoudre des classes entières de problèmes avec des modifications d'architecture ou de structure (par exemple, amélioration des classes de conteneur personnalisées, gestion des exceptions de niveau supérieur)

Cela dit, l'ajout d'un champ Personne à blâmer peut clairement envoyer un très mauvais message et un message destructeur à une équipe de logiciels que la direction souhaite identifier et punir les développeurs individuels qui paient le plus souvent le code. Je pense que le responsable pense que cet examen public poussera les développeurs à être plus prudents et à s'autoréglementer pour éviter de se faire nommer sur ce "mur de la honte", et je ne comprends pas pourquoi les développeurs se sentiraient menacés par cette situation, surtout si elle est ajoutée. génériquement à chaque rapport de bogue.

Il est facile de commencer à énumérer les problèmes liés à l'ajout de cela en tant que champ de bogue / métrique potentielle:

  1. Les bugs ont des difficultés de résolution très variables, et une simple statistique de nombre de bogues / développeur ne le reflétera pas.
  2. Les développeurs ont des capacités très variables "" "" "" "" "" "
  3. De nombreux systèmes logiciels comportent des composants nécessitant une refactorisation; toutefois, les composants existants (en particulier si la base existante ne dispose d'aucune installation de test unitaire / limitée) introduiront initialement des bogues. Les développeurs risquent d'être découragés de cette "bonne" activité, s'il existe une stigmatisation / peur associée à la génération de nouveaux bogues (même s'ils sont triviaux à résoudre et que le résultat final est une amélioration majeure du système.)
  4. Les testeurs peuvent générer un nombre très variable de bogues liés au même problème, ce qui entraîne un nombre de bogues / développeur très asymétrique, à moins qu'une analyse plus détaillée ne soit effectuée.

Ce n'est que la pointe de l'iceberg. Combinez ces éléments avec l'indication précise du comportement attendu de l'API, des résultats attendus incorrects dans les tests et des problèmes "plus tôt dans la chaîne" avec des exigences incorrectes / manquantes, et il devrait être évident qu'une métrique comme celle-ci est vouée à l'échec le but est d’endommager le moral et de provoquer un exode massif.)

Pour revenir au point de vue du patron, il est normal qu’il / elle cherche à savoir s’il existe des développeurs qui enfreignent le code à plusieurs reprises et essaie de faire quelque chose (de manière constructive, à cet égard). Essayer d'obtenir ces informations en ajoutant un champ aux rapports de bogues ne fournira pas d'informations significatives pour les raisons énumérées ci-dessus. D'après mon expérience, ces informations peuvent être apprises en étant connectées à l'équipe, en participant à la plupart des réunions de l'équipe, en intégrant (avec soin) les informations apprises lors de réunions individuelles avec des membres de l'équipe, et en se familiarisant avec les sous-systèmes de le code (même s'ils ne peuvent pas lire le code.)


6

Laisser faire. Votre patron découvrira seul que cela cause un problème, si cela se produit.

Soyons francs, vous avez une opinion et lui aussi. Il est votre manager et son opinion est celle qui gagne.

Oui, vous pouvez faire la guerre à ce sujet, mais est-ce que cela en vaut vraiment la peine? Je doute que cela dure plus de 3 mois avant de tomber en désuétude.

Mais saboter activement ou crier dessus utilise simplement un capital politique mieux sauvegardé pour demander un congé supplémentaire, une prochaine augmentation, une promotion ou lorsqu’une décision de conception vraiment critique sera prise.

À ce moment-là, quand cela compte vraiment, vous ne voulez pas que le chef se souvienne que vous êtes la personne qui a activement saboté son idée de "personne à blâmer".

Respectez le bureau même si vous ne respectez pas la décision.

Économisez le stress et battez-vous à la table pour prendre des décisions qui dureront beaucoup plus longtemps.


+1 pour une solution raisonnable (même si j'ai ajouté une réponse personnelle) :-)
Homer6

2
Ce genre de personnes prend de la politesse et de la sensibilité pour la faiblesse. La prochaine fois, il viendra avec quelque chose de bien pire. Et seront encore moins désireux d'écouter les opinions. Même maintenant, il dit que faire du mal aux gens, c'est amusant. Si vous travaillez avec de telles personnes, vous devrez également devenir sadique ou masochiste.
Gangnus

5

Dites à votre patron que le développement en équipe nécessite des compétences sociales. Il pourrait même hocher la tête.

Mais le problème, c’est que c’est une chose avec laquelle les développeurs sont extrêmement mauvais. L'ajout d'outils suggérant blâmer est plus important qu'une analyse correcte du problème est contre-productif.

Au lieu de cela, vous avez besoin d'incitations pour améliorer les compétences sociales, et l'infrastructure de communication que vous avez doit le supporter. Par exemple, exprimez-le de façon positive: nommez une personne responsable d’un ticket, qui s’occupe de celui-ci.

Commencez également par des revues de code afin que vous puissiez apprendre les uns des autres. Cela épargne les reproches plus tard.


Rappelez-lui que dans la plupart des cas, il peut être la personne à blâmer. Pression de temps, membre de l'équipe, priorités gérées, outils sélectionnés / approuvés ...
BillThor

Oh mec, je connais les développeurs. Ils cherchent souvent la cause par quelqu'un d'autre. Et ils ne sont pas timides à discuter. Je dirais que les développeurs doivent chercher de manière proactive à améliorer leurs compétences sociales et leur responsabilité. Le champ responsable ne peut être qu'un symptôme indiquant que quelque chose ne va pas dans le processus de développement. Je parie que les développeurs ont leur responsabilité dans ce problème. Le directeur a aussi, on dirait que les insectes se développent au-dessus de leurs têtes. Ils devraient donc mieux analyser pourquoi le bugrate les a mis hors de portée du développement.
hakre

4
-1 pour avoir suggéré cela developer == no social skills. Les deux sont entièrement indépendants. Vous pouvez être bon dans l’un ou les deux, et mauvais dans l’un ou les deux, et il n’ya pas de lien.
Daenyth

@Daenyth: C'était censé être une provocation, c'est gentil de te voir provoqué. Bien sûr, ces corrélations ne sont naturellement pas vraies, et il est stupide de le dire (préjugés). Cependant, les développeurs n’ont souvent aucune compétence sociale. Surtout ceux qui travaillent dans une entreprise qui est gérée de la manière décrite par OP, je suppose.
hakre

@hakre: Si c'est le cas où il travaille, c'est uniquement parce que les plus adroits ont quitté l'entreprise en raison de la direction
Daenyth

2

Envoyez-lui cette question SO. S'il est ouvert à la raison, les commentaires ici fourniront des contrôles de cohérence pour son raisonnement. S'il n'est pas raisonnable, il est peu probable que vous le convainciez avec des raisons sensées. De plus, il sera capable de lire les raisons en dehors d'une conversation (ce qui peut parfois être plus convaincant en raison de la motivation retirée pour "avoir raison" dans le feu de la conversation).

Vous pouvez également essayer de renverser la situation. Ce champ pourrait être "les étapes possibles pour éviter un bogue similaire", ou quelque chose de plus court à cet effet. Vous pourrez ensuite mettre en commun les solutions et voter sur les solutions à mettre en œuvre pour améliorer votre lieu de travail. Une approche axée sur les solutions est peut-être plus productive et probablement mieux accueillie (à condition que les suggestions soient réexaminées).


1

Je vois deux possibilités ici: il veut pouvoir punir les gens qui font des erreurs, ou il n'y a tout simplement pas réfléchi. Dites-lui que chacun aura l’impression de vouloir punir ceux qui commettent des erreurs. Demandez-lui si c'est la culture qu'il veut encourager.

mon patron a décidé que l'ajout d'un champ "Personne à blâmer" à notre modèle de suivi des bogues augmenterait la responsabilité

Selon mon expérience, lorsque la direction veut «responsabiliser davantage les gens», elle veut simplement pouvoir punir les personnes qui échouent. Qu'il s'agisse de licencier des personnes peu performantes ou simplement de les laisser se perdre dans la révision annuelle des salaires ("Désolé, Bob, vous aviez 17 bogues signalés comme étant votre faute, et c'est au-dessus de la limite de 15"), c'est une punition.

Il dira probablement "Oh, non, nous ne le voulons pas", alors demandez-lui comment ces données seront utilisées. Rappelez-lui que vous n'ajoutez pas de points de données à une base de données à moins que vous ne l'utilisiez. Veut-il sélectionner un critère donné ("Montre-moi tous les bogues non résolus dans le sous-système créateur de rapport"), afin de pouvoir travailler sur des choses ou obtenir des données agrégées ("Quel sous-système a eu le plus de problèmes?"). bugs "), afin que vous puissiez faire une analyse post-mortem. Envisage-t-il une sorte de plateau d'échec où les gens peuvent être humiliés publiquement?

Alors qu'est-ce qu'il a l'intention? Veut-il pouvoir dire "Montre-moi tous les bugs qui sont la faute de Bob?" Pourquoi? Ou veut-il pouvoir dire "Montre-moi qui est en faute la plupart du temps?" Pourquoi? Le premier n'a pas de sens et le second n'est que punitif. Ou la troisième option est qu'il n'a pas de vraie raison.

J'admets qu'il est possible qu'il recherche des programmeurs de l'équipe qui ont besoin d'aide pour améliorer leurs compétences. Si tel est le cas, il existe de meilleurs moyens de capturer ces informations sans créer de culture de pointage du doigt.


-3

Je pense que l'aspect clé à surveiller ici est le degré d'ouverture de la communication dans l'équipe envers le «patron» et vice-versa. Il n'est jamais bon de pointer du doigt du point de vue de la gestion. Si un de vos développeurs tombe plusieurs fois dans le même problème, il peut être temps d'intervenir et de l'aider à surmonter ce problème répétitif (par exemple, John ne teste pas correctement le code: 3 bogues de production au cours des 3 derniers mois, donnons-lui une liste de contrôle afin qu'il se souvienne de la manière dont son code est censé être et comment il devrait le tester).

Du point de vue du développement, "blâmer" est déjà intégré dans un outil grand public tel que SVN, donc je ne vois vraiment pas de mal à dire "John, corrige ce bordel que tu as écrit" et place un nom à côté de il. JIRA incorpore également le nom d’une personne lorsque vous enregistrez un bogue (toutefois, le champ n’est pas vraiment destiné à la personne qui en est responsable, c’est assez bien pour que quelqu'un le répare).

Cependant, comme beaucoup d’entre eux l’ont mentionné plus haut, si un bogue se présentait, c’est une responsabilité partagée: des développeurs aux testeurs, en passant par le contrôle qualité, en passant par les gestionnaires. Si, à un moment donné, votre patron traite un client en colère au téléphone avec des choses telles que " Je suis vraiment désolé, John n'a jamais testé cela correctement ", alors je chercherais certainement un autre emploi. Un bon patron devrait aller "nous nous en occupons". Pas de noms, pas de doigt, juste des solutions.

Encore une fois, je crois que tout est question de communication. Peut-être que la seule chose que votre patron veut faire est de voir qui a des problèmes dans l’équipe de développement, ou quel genre de problèmes l’équipe a (peut-être pour des séances d’entraînement?), Mais je ne pense pas que vous saurez exactement ce qui se cache derrière son décision (ou plutôt, nous affichons / lecteurs) sauf si vous parlez à votre patron et à votre équipe.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.