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?
Dans l'un des derniers mouvements "WTF", mon patron a décidé que l'ajout d'un champ "Person To Blame" à notre modèle de suivi des bogues augmenterait la responsabilité (bien que nous ayons déjà un moyen de lier les bogues aux fonctionnalités/histoires). Mes arguments selon lesquels cela diminuerait le moral, augmenteraient le doigt et ne tiendraient pas compte des fonctionnalités manquantes/mal comprises signalées comme bogue sont restés inconnus.
Quels sont les autres arguments solides contre cette pratique que je peux utiliser? Y a-t-il des écrits sur ce sujet que je puisse partager avec l'équipe et le patron?
Dites-leur que ce n'est qu'un nom amateur pour le champ Root Cause utilisé par les professionnels (lorsque le tracker de problème n'a pas de champ dédié, on peut utiliser des commentaires pour cela).
Recherchez sur le Web quelque chose comme analyse de la cause première du bug du logiciel, il existe de nombreuses ressources pour justifier ce raisonnement 1 , 2 , , 4 , ....
... une cause profonde d'un défaut n'est pas toujours un seul développeur (ce qui est le point principal de ce domaine) ...
C'est exactement pourquoi la "cause profonde" est professionnelle tandis 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 racine couvrira certainement cela ( "erreur de codage commise par Bob lors de la validation) 1234, raté par Jim dans la revue 567 "). L'intérêt d'utiliser le terme cause profonde est de couvrir des cas comme celui-ci, avec des cas qui sortent du portée 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 la cause racine permet de le couvrir, tandis que "seul développeur à blâmer" se briserait simplement le flux suivi des problèmes .
Il en va de même pour les 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. Par exemple, 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 pas de sens.
Un autre résultat probable d'une telle politique est que les gens ne signaleront pas de bogue s'ils pensent être la "personne à blâmer", ce qui réduira donc le nombre de bogues signalés par l'équipe.
L'argument principal que j'utiliserais contre cela est de demander quel problème il essaie de résoudre. Il existe presque certainement de meilleures façons 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 d'arriver à la production. Si vous ne suivez pas toutes ces étapes, c'est peut-être la solution au problème que votre patron essaie de résoudre. Si vous êtes alors lequel est à blâmer? Ce n'est peut-être aucun d'entre eux, ce pourrait être un code hérité qui est à blâmer.
Il n'est pas bon d'avoir des gens qui se mordent le dos et pointent du doigt, essayant d'éviter une marque noire qui ne disparaîtra pas une fois réglée. Cela ne résout rien. Très peu de gens sont malveillants par négligence. Vous devez faire une rétrospective appropriée , voir ce qui s'est mal passé et ce que vous pouvez faire pour vous assurer que cela ne se reproduise pas.
À partir de cela, vous verrez clairement si une personne est régulièrement en faute et cela peut être un problème différent à résoudre.
L'astuce pour empêcher un gestionnaire de créer de la responsabilité est de l'offrir librement , mais d'une manière qui vous semble réellement logique.
Il y a au moins trois problèmes avec ce domaine.
La première est que blâmer les gens n'est pas bon pour le moral. D'accord. Mais peut-être qu'il ne se soucie pas du moral et veut virer les mauvais développeurs. Difficile de contester.
Le second est que la bonne gestion de ce champ va être difficile et un temps assez long. C'est plus complexe que de simplement découvrir qui a écrit le mauvais code. Et toute information potentiellement difficile à comprendre peut être mise en sac/trichée. Mais il est peut-être prêt à payer ce coût et à vérifier les informations. Bien.
Le problème le plus fondamental est que ce domaine ne sera pas une bonne mesure pour agir. Bien sûr, il aura un classement Nice dont le code cause le plus de défauts. Mais devinez qui sera en tête de cette liste? Probablement le fondateur de l'entreprise, ou peut-être un développeur de premier plan qui a un taux de défaut très faible mais qui est si productif qu'il écrit une partie disproportionnée du code. Il finira donc par licencier 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 par mois - de préférence des commentaires - sera probablement récompensé pour ses faibles nombres de défauts.
Encore une autre panne de métrique logicielle.
La cause profonde d'un défaut sur le terrain n'est jamais une seule personne. Des personnes parfaitement consciencieuses commettront des erreurs et un processus qui s'attend à ce qu'elles soient infaillibles est déraisonnable. Si vous ne vérifiez pas les modifications apportées aux systèmes de production avant le déploiement, manuellement ou par le biais de tests automatisés, les bogues sont inévitables.
Faux:
Bob a oublié de vérifier l'entrée et le programme s'est écrasé 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 la bonne gestion des entrées non valides. Le code a été corrigé et tous les nouveaux cas de test passent.
Changer "Personne à blâmer" en "Personne à louer"
La personne principale pour corriger les bugs y obtient son nom.
Réponse simple.
Le champ "Blame" ne sera utilisé que pour des boucs émissaires et des pointages, le moral s'effondrera, la confiance de l'équipe sera détruite et tout le monde essaiera de trouver des moyens de prouver que quelque chose n'est pas de leur 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 qu'un collègue ait des ennuis. C'est complètement contre-productif.
Quoi de plus important, de victimiser quelqu'un pour avoir fait une erreur honnête ou pour résoudre le problème le plus rapidement possible?
Votre patron semble penser que les bogues 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 pousse-t-il en un an?
Si vous êtes prêt pour une petite désobéissance civile, demandez à l'équipe d'accepter de mettre une liste de tous les développeurs dans ce domaine pour chaque bogue. Si cela ne vous convient pas, écrivez "Je suis Spartacus!" au lieu. Le fait est, bien sûr, que vous êtes tous responsables de tous les bogues, et que vous n'êtes pas content de devoir signaler la personne qui a créé un bogue.
Autre option: jouer avec. Ne faites rien de particulier - faites du bon travail et remplissez le champ aussi précisément que possible pendant quelques mois. Expliquez ensuite au patron que le fait de blâmer chaque bug rend tout le monde dans l'équipe mécontent et mal à l'aise. Dites-lui que vous pensez tous qu'il y a peu de corrélation entre les bugs créés et tout le reste (compétence, effort, santé mentale). (Cela vous aidera si vous pouvez exécuter des nombres qui montrent qu'il n'y a vraiment pas de corrélation.)
Gandhian Civil Disobedience: Mettez votre nom sur chaque champ (à moins que d'autres développeurs n'interviennent et mettent leur nom pour leurs bogues), et acceptez le blâme pour chaque bogue, que ce soit le vôtre ou non. Rien ne rendra ce domaine ou l'idée de blâmer quelqu'un plus inutile que cela. Si votre patron vous demande pourquoi est votre nom dans tous les domaines, alors vous pouvez expliquer "parce que je ne pense pas que le développement soit un jeu de blâme, si vous avez vraiment besoin que les gens blâment et crucifient, alors crucifiez-moi pour tout et laissez mon équipe travailler en paix . "
Un jour, un patron a mis en œuvre un système très similaire à celui-ci, et bien qu'il ne s'agisse pas de programmation (c'était la conception imprimée d'un quotidien), le concept et la réponse appropriée sont les mêmes.
Ce qu'elle a fait, au lieu d'ajouter un champ "personne à blâmer" sur nos documents, elle a donné à chacun des designers un ensemble d'autocollants colorés. Chaque designer a reçu un autocollant de couleur différente et a été informé que pour tout dessin travaillé ou même touché l'autocollant doit être ajouté à la paperasse de ce dessin.
L'objectif déclaré par le patron de "l'initiative de l'autocollant" était d'établir la source de toutes les erreurs de notre département (erreurs dans la paperasse, erreurs de classement, mauvaise copie, essentiellement l'équivalent imprimé des bogues)
Ce que nous avons fait a donné à chacun des autres designers un quart de nos autocollants afin que nous ayons chacun toutes les couleurs, et au lieu de mettre uniquement notre couleur sur chaque design, nous avons mis les quatre designers 'couleurs.
Ne vous contentez pas d'écrire votre nom dans la case [Blame] - mettez le nom de tous les membres de l'équipe/du projet et assurez-vous que toute l'équipe fait de même.
Nous avons travaillé ensemble contre sa garce orwellienne et, en conséquence, nous avons fini par nous surprendre les uns les autres et en parler les uns aux autres et, finalement, nous avons eu une réduction significative des erreurs. Elle était un gestionnaire de sh * t cependant, et au lieu de reconnaître que son initiative a fini par nous unir et augmenter la productivité, elle a été complètement blessée et a dissous le système d'autocollants et l'a déclaré un échec et nous a tous formellement réprimandé.
Cela ressemble beaucoup à quand Scott Adams a souligné la sagesse ratée d'un Bug Bounty lorsque le Boss Pointy Haired à Dilbert. Wally a annoncé qu'il allait aller lui "écrire un nouveau Mini Van".
Bande dessinée Dilbert du 13/11/1995 de l'archive officielle des bandes dessinées Dilbert.
Je me souviens une fois, lors du ski de neige, que quelqu'un a souligné que "ne pas tomber" n'était pas le signe d'un bon skieur, mais souvent le signe d'un skieur qui n'essaie rien (ou qui ne skie pas vraiment du tout).
Les bogues peuvent être introduits dans le code par une mauvaise programmation et une mauvaise conception; mais, ils peuvent également résulter de l'écriture de beaucoup de code difficile. Dinger les personnes qui produisent le plus de bogues est aussi susceptible aux développeurs pauvres Ding que ceux très productifs.
Il semble que votre patron soit frustré par le nombre de défauts. Les gens 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: changement des exigences, défaut de conception, défaut d'implémentation, etc. Même cela échouera à moins qu'il y ait un groupe de travail pour améliorer la qualité du produit.
Il finira par punir son programmeur le plus prolifique. Il y a de fortes chances qu'une ou deux personnes soient les meilleurs employés ayant travaillé sur le plus de projets. Si vous avez, dans un département de 10 personnes, un codeur qui n'est qu'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 que la personne qui écrit le moins de code est le meilleur programmeur.
Vous devriez peut-être le considérer comme "Qui est le mieux placé pour corriger le bogue?" Une partie de moi aussi ressent, tu l'as cassé, tu le répares. Il devrait y avoir une certaine reddition de comptes.
Je ne suis pas d'accord pour garder une sorte de score. Certaines personnes créent plus de bugs car elles travaillent sur des parties plus complexes du code. Si les lignes de code ne sont pas une mesure utile, je doute que les bogues par ligne 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.
Votre véritable question était de savoir comment changer la culture avant de quitter l'entreprise, en convaincant votre patron que l'ajout d'une personne à blâmer pour les rapports de bogues est une mauvaise idée. Mais bien sûr, changer la culture nécessite qu'il comprenne vraiment 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 y a le problème fondamental que les gens qui pensent aux solutions principalement en termes de blâme individuel sont généralement assez bien placés dans cet état d'esprit.
Vous avez demandé à écrire sur ce sujet, et Peopleware me vient à l'esprit. Il est très apprécié et parle en termes généraux de la façon de gérer les personnes qui font un travail créatif où le rendement est difficile à mesurer. Le problème est que le lire n'aidera pas beaucoup, votre patron devra le lire et en croire au moins une partie.
Curieusement, puisque le problème concerne davantage les personnes que les rapports de bogues, il appartient très probablement plus à Workplace qu'aux programmeurs. Mais le succès des projets logiciels est généralement assez fortement lié à l'interaction sociale humaine, de sorte que les vraies réponses concernent souvent les choses qui transcendent les logiciels.
Ma seule autre suggestion, à moitié sérieuse, est de dire (ou de convaincre un collègue de dire, puisque vous prévoyez de partir) que vous êtes prêt à assumer l'entière responsabilité de la réussite du projet, et votre nom devrait toujours aller sur le terrain, car même si quelqu'un d'autre a fait l'erreur directement, vous avez supposé la responsabilité de s'assurer que chaque membre de l'équipe effectue un travail de qualité.
C'est absurde, bien sûr, comment pourriez-vous soutenir cela, mais certaines personnes (en particulier les personnes qui sont très coupables) mangent vraiment ce genre de choses. Ronald Reagan avait l'habitude d'accepter publiquement sa responsabilité personnelle chaque fois qu'un membre de son administration était pris dans un scandale (et il y en avait plusieurs) et cela fonctionnait assez bien politiquement à chaque fois. La meilleure partie pour vous est que la responsabilité n'a généralement pas de conséquences réelles, ils pensent simplement que vous êtes un gars debout pour prendre la responsabilité.
Ou peut-être que ce n'est pas comme ça que ça va baisser. Cela n'a aucun sens pour moi, il est donc difficile pour moi de prédire quand cela fonctionnera, mais j'ai été témoin que cela fonctionnait alors qu'il ne semblait pas y avoir d'activité (sur le lieu de travail, pas seulement l'exemple Reagan).
Il est étrange que personne ne l'ait mentionné auparavant: l'ajout d'une telle fonctionnalité au traqueur de bogues motiverait les employés à essayer de jouer le système.
Il s'agit d'un problème courant pour des approches comme celle présentée par la question, entre autres idées similaires (paiement par nombre de lignes de code, paiement par nombre de bogues). Cela encouragera de nombreuses personnes à 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 propre blâme et le pousser sur quelqu'un d'autre peut conduire 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), ce qui a donné plus de temps et d'efforts pour résoudre le problème.
Les gens ne vont pas au travail avec l'intention de commettre des erreurs, et toute stratégie mise en place pour attacher spécifiquement la responsabilité de ce qui peut ou non être une erreur humaine est ridicule - sans parler de l'extrême manque de professionnalisme.
À tout le moins, une "partie responsable" chargée de prendre en charge et de "résoudre" le problème, ou d'élaborer un plan pour suivre et/ou empêcher que des événements similaires ne se produisent, serait une bonne chose. Parfois, la solution n'est rien d'autre 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 "temps payé par l'entreprise/temps de l'entreprise". Un endroit a même construit tout un "centre de formation", que le collège local "emprunte" à l'occasion, pour leurs cours de technologies industrielles.
Je travaille dans un environnement de fabrication depuis 20 ans, où les erreurs de programmation ne causent pas seulement des erreurs, elles détruisent physiquement des choses et/ou pire, elles blessent les gens. Cependant, une constante dans tous les domaines de la fabrication qui est solide, c'est qu'il n'y a jamais, en aucun cas, quelqu'un à blâmer. Parce que c'est un défaut du système, clair et simple - pas un défaut chez les gens. Regardez-le de cette façon - l'utilisation du correcteur orthographique - un outil très efficace, pour ceux qui ont moins de chance dans le domaine de la virtuosité textuelle, ou peut-être juste pour ceux un peu surmené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", fonctionnent en totale harmonie - ou quelque apparence de ceux-ci.
Lecture suggérée de la part de votre patron: Les 7 habitudes des gens très 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 - ou cela ne fonctionnera tout simplement pas, et à la fin, il tiendra le sac malgré tout.
Suggestions de lecture et/ou recherche de votre part:
Cherchez à savoir pourquoi l'analyse, l'analyse des causes profondes ... tout ce qui vous met en meilleure position pour offrir une solution, pas un problème . Et votre désaccord avec votre patron, c'est juste ça, un problème, pas une solution. Offrez-lui quelque chose de mieux, quelque chose qui a du sens, et même soyez prêt à lui permettre de prendre le crédit de l'idée.
À l'heure actuelle, il ne semble pas prêt à réparer quoi que ce soit, car il n'a pas une compréhension solide de ce qui est cassé, s'il y a quelque chose de cassé - à part sa mentalité de "je suis le patron".
Bonne chance! J'espère que vous réussirez à passer au travers, d'une manière acceptable pour tous, surtout en ces temps.
EDIT: Personnellement, d'après ma propre expérience ... "Allez-y, blâmez-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? Oui, vous l'a deviné ... moi, avec un grand sourire. "
Pour la responsabilité, je ne voudrais pas d'un person to blame champ, je voudrais un Person who knows the code champ ou person who can fix champ, pour que je sache où envoyer le ticket d'assistance.
Cela accélérerait le processus de correction du bogue lui-même et donnerait la responsabilité, un peu comme tuer deux oiseaux avec une pierre. Je lui en parlerais personnellement et je le laisserais décider si cela aiderait à remonter le moral et à rendre des comptes sans faire ressentir à personne l'échec. Les tests extrêmes ne détectent pas tous les bogues, sinon il n'y aurait pas de rapport de bogue.
Si mon patron faisait cela, ce qui se passerait, dans cet ordre exact:
1) Je commencerais immédiatement à chercher un nouvel emploi.
2) Chaque fois qu'un bug est signalé 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 que pour 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 en production via un script pour ne pas permettre l'erreur humaine? Ensuite, le processus de développement est interrompu, d'où le bogue. Un développeur est-il terrible? Alors le critère d'embauche est badm donc la faute du patron. Tous les développeurs font-ils des erreurs stupides par manque de repos car ils travaillent 12 heures par jour? Ensuite, le processus de développement est interrompu. Comme vous pouvez le voir, 100% des bugs sont la faute du boss.
En guise de remarque: tout bon gestionnaire de développement est conscient de ce que j'ai écrit ci-dessus. Et les stratégies Agiles sont destinées à montrer au patron ou à ses supérieurs pourquoi le développeur ralentit: Regardez, nous passons 50% de notre temps à corriger les bugs. Regardons les stratégies pour les réduire afin que nous puissions passer 40% du temps à corriger les bogues, puis revisiter ce problème pour le porter à 30%. etc.
Malheureusement, il semble que vous n'ayez pas un bon gestionnaire à cause du terrain. Je suggère donc de faire (1) et de ne pas en parler au manager (sauf lors de votre entretien de sortie)
Dites-lui que le "blâme" est négatif. Remplacez-le par "personne à corriger", puis au moins, il est formulé de manière positive, et le même travail est toujours effectué. Comment les gens peuvent-ils travailler s'ils sont "blâmés"?!
Si vous faites Agile, et il semble que vous soyez du commentaire features/stories . La personne à blâmer serait la personne QA qui a laissé passer le bug, ou le propriétaire du produit/client qui a accepté la fonctionnalité/l'histoire comme complète avec le bug dedans.
J'ai fait de la composition dans la journée, voici mon point de vue.
C'est comme blâmer un typographe pour les fautes d'orthographe et autres choses qu'un correcteur aurait dû trouver mais manquer. Le typographe a fait une faute d'orthographe, mais le relecteur l'a ratée, c'est donc le relecteur à blâmer pour l'erreur commise à imprimer, pas la personne qui a fait l'erreur en premier lieu.
Dans un environnement Agile, il est de la responsabilité des personnes d'AQ de détecter les erreurs (bugs) et il est de la responsabilité du Product Owner de ne pas accepter les choses qui ne sont pas correctes. Il s'agit de deux niveaux de relecteurs qui devraient isoler les développeurs des choses qui sont publiées, ce qui est la seule façon de classer quoi que ce soit en tant que bogue dans un Environnement agile.
Il semble que votre patron ne possède pas une compréhension approfondie des logiciels et qu'il n'en ait peut-être pas l'intention non plus. Il a donc une langue différente, une culture différente.
Quitter un emploi pour un problème comme celui-ci, avant même d'essayer d'avancer pour une solution, c'est juste être un abandon. Arrêter, c'est arrêter. N'abandonnez pas tant qu'il ne vous a pas assuré que vous ne vous comprendrez jamais. Pour en être sûr, vous devez d'abord essayer.
Puisqu'il ne connaît pas notre langue et qu'il est le patron, la première étape ici serait d'essayer de lui parler dans sa langue. Qu'est-ce que je veux dire avec la langue? Réfléchissons ensemble:
Nous, les logiciels, la plupart d'entre nous adorons notre travail, nous avons un lien profond avec ce que nous faisons. Sinon ça ne marche pas et on ne peut pas continuer longtemps dans ce métier sans l'aimer ou être complet ... on remplit les blancs ...
Il voit cependant les choses très différemment. Avec chaque rapport de bogue, alors que la plupart d'entre nous sont ravis de faire en sorte que la chose fonctionne mieux (non, même si c'est parfois vraiment très stressant, nous aimons les problèmes, admettons-le!), Il le voit comme un échec, une mesure d'être infructueux. La première chose qu'il devrait vouloir comprendre, c'est que les bugs sont bons. Les bugs font que les clients aiment l'entreprise. (Maintenant, c'est son langage) Lorsqu'un client signale un bug, ou quand nous en trouvons un nous-mêmes, après qu'il soit résolu, c'est bien mieux que la situation où cela ne s'est jamais produit. Les bogues créent la fidélité des clients (je suis sérieux!), Les bogues créent une excellente excuse pour la communication entre le consommateur et le producteur du logiciel.
Pour "augmenter le profit des bogues", vous devriez proposer de rendre les rapports de bogues encore plus ouverts. Avec chaque rapport de bogue et sa solution rapide, propre et bonne, les clients sentent et voient que "wow, ces gars sont géniaux! Ils travaillent vraiment dur. Regardez ces choses qu'ils résolvent. Nous ne savions même pas que le logiciel était si complexe chose!" bla bla et bla ...
Faites votre pas, parlez dans sa langue. Les bogues sont parfaits pour une société de logiciels, pas un problème. Ils nous font vivre.
Pour l'éthique de l'équipe, l'efficacité ou tout autre type de discussion que vous feriez pourrait fonctionner de la manière opposée que vous vouliez. Si vous voulez arrêter, il pensera "aha, ma solution a commencé à fonctionner dès le premier jour! Les mauvais liens ont déjà commencé à tomber d'eux-mêmes avant qu'ils ne soient exposés!" Il croit en son idée de retrouver les mauvais garçons dans l'entreprise et il est très difficile de le convaincre du contraire. Surtout quand vous pourriez être un de ces mauvais garçons!
Alors, concentrez-vous sur son vrai problème: les bugs. Montrez-lui que les bugs 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 bug est une excellente opportunité que vous pouvez utiliser pour augmenter le bonheur des clients.
C'est juste une chose que vous pouvez dire. Pensez à ses préoccupations et vous trouverez de nombreux autres articles à ajouter à votre liste. La GOLDEN KEY c'est d'offrir une alternative au lieu de se battre avec son idée!
Je pense que votre manager essaie de résoudre un problème avec la mauvaise solution. Je pense qu'il y a peut-être un problème selon lequel trop de bogues sont publiés et votre gestionnaire veut que les développeurs s'approprient et rendent davantage compte du code qu'ils écrivent.
L'utilisation du 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 lorsque quelqu'un commet du code qui "rompt la construction", un e-mail est envoyé à l'équipe pour signaler la personne à blâmer. Étant donné que 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 s'approprieront davantage, se sentiront plus en confiance et qu'il y aura moins de bogues dans le code de production.
Faites remarquer que si l'erreur d'une seule personne entraîne la fin d'un bug en production, il y a un problème avec votre méthodologie ou votre façon générale de développer un logiciel. Précisez que la prévention des bogues en production est de la responsabilité de toute l'équipe.
En utilisant l'un ou l'autre de ces deux arguments, voyez si vous pouvez persuader votre patron qu'avoir le champ "qui blâmer" comme champ à sélection unique serait trompeur; et que par conséquent, il est nécessaire de s'assurer que le champ "qui blâmer" est un champ à sélection multiple. Une fois que vous avez atteint cet objectif, assurez-vous que pour chaque bug, le nom de tout le monde est dans le champ. Votre patron verra finalement que tout reportage sur le terrain est inutile.
Pour donner un crédit au patron, le concept de "blâme" est déjà intégré dans des outils comme SVN , et une utilisation appropriée des données peut être constructive pour les développeurs dans "trouver à qui parler" pendant le 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 qu'un champ Cause fondamentale est une bonne chose, ce ne sont pas les mêmes informations et "dénormaliser" le champ pour parfois attribuer le (s) nom (s) de développeur précédent (s) pour la source affectée, et parfois avoir une description technique (par exemple "n'a pas été mis à l'échelle pour 10000 utilisateurs") ne fera que brouiller les eaux. Je recommanderais de conserver un champ Cause fondamentale clairement une description technique (par exemple, même en cas d'erreur de programmation claire, demandez-lui de capturer des détails tels que "IndexOutOfRange Exception lorsque fooData = 999 "). Cela peut potentiellement fournir des commentaires utiles lorsqu'ils sont examinés en masse, et permettre à certaines actions correctives d'être prises pour résoudre des classes entières de problèmes avec des changements d'architecture ou de cadre (par exemple, amélioration des classes de conteneurs 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 logicielle que la direction souhaite identifier et punir individuellement. les développeurs qui cassent le plus souvent le code. Je soupçonne que le gestionnaire pense que cet examen public incitera les développeurs à être plus prudents et à s'autoréguler pour éviter de mettre leur nom sur ce "mur de la honte", et ne comprend pas pourquoi les développeurs se sentiraient menacés par cela, surtout s'il est ajouté génériquement à chaque rapport de bogue.
Les problèmes liés à l'ajout d'un champ de bogue/d'une mesure potentielle sont faciles à commencer à énumérer:
- Les bogues sont très variables en difficulté à résoudre, et une simple statistique de nombre de bogues/développeur ne reflétera pas cela.
- Les développeurs ont des capacités très variables "" "" "" "" "" "
- De nombreux systèmes logiciels ont des composants qui doivent être refactorisés, mais le refactoring des composants hérités (en particulier si la base héritée n'a pas/peu de fonctionnalités de tests unitaires) introduira initialement des bogues. Les développeurs sont susceptibles d'être découragés de cette "bonne" activité, s'il y a une stigmatisation/peur associée à la génération de nouveaux bugs (même si ceux-ci sont triviaux à résoudre et que le résultat final est une amélioration majeure du système.)
- Les testeurs peuvent déposer 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-les avec l'indication de qui attendait quel comportement 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 à être sans valeur (sauf si le but est de nuire au moral et de provoquer un exode massif.)
Revenons au point de vue du patron, c'est OK qu'il/elle veuille savoir s'il y a des développeurs qui cassent le code à plusieurs reprises, et essayer de faire quelque chose (si tout va bien constructif) à ce sujet. 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 d'équipe, en intégrant (soigneusement) les informations apprises lors de réunions individuelles avec les membres de l'équipe et en se familiarisant avec les sous-systèmes le code (même s'ils ne peuvent pas lire le code.)
Laisser faire. Votre patron découvrira par lui-même que cela pose problème, si c'est le cas.
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 cela en vaut-il vraiment la peine? Je doute que cela dure plus de 3 mois avant de tomber en désuétude.
Mais saboter activement ou crier à ce sujet utilise simplement du capital politique qui est mieux économisé pour demander ce congé supplémentaire, la prochaine augmentation, la promotion ou lorsqu'une décision de conception vraiment critique va être prise.
À ce moment-là, quand cela compte vraiment, vous ne voulez pas que le patron 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 la table pour des décisions qui vont durer beaucoup plus longtemps.
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 est que c'est une chose avec laquelle les développeurs sont extrêmement mauvais. L'ajout d'outils qui suggèrent que le blâme est plus important qu'une analyse correcte des problèmes est contre-productif.
Au lieu de cela, vous avez besoin d'incitations pour améliorer les compétences sociales, et l'infrastructure de communication dont vous disposez devrait soutenir cela. Par exemple, faites-le positivement: nommez une personne qui est responsable d'un billet, qui s'en occupe.
Commencez également par des révisions de code afin que vous puissiez apprendre les uns des autres. Cela évite les reproches plus tard.
Envoyez-lui cette SO question. S'il est ouvert à la raison, les commentaires ici fourniront des vérifications d'intégrité pour son raisonnement. S'il n'est pas raisonnable, il est peu probable que vous le convainciez avec des raisons qui ont du sens. 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 à "avoir raison" dans le feu d'une conversation).
Vous pouvez également essayer de le renverser. Le champ pourrait être "des étapes possibles pour éviter qu'un bogue similaire ne se produise", ou quelque chose de plus court à cet effet. Ensuite, vous pourriez mettre en commun des solutions et voter sur celles à mettre en œuvre pour améliorer votre lieu de travail. Peut-être qu'une approche axée sur les solutions est plus productive et probablement mieux reçue (à condition qu'il y ait un suivi réel de la révision des suggestions).
Je vois deux possibilités ici: il veut pouvoir punir les gens qui font des erreurs, ou il n'a tout simplement pas réfléchi. Faites-lui savoir que tout le monde aura l'impression qu'il a l'intention de punir ceux qui commettent des erreurs. Demandez-lui si c'est la culture qu'il souhaite encourager.
mon patron a décidé que l'ajout d'un champ "Person To Blame" à notre modèle de suivi des bogues augmenterait la responsabilité
D'après mon expérience, lorsque la direction veut "rendre les gens plus responsables", ce qu'ils veulent dire, c'est qu'ils peuvent être en mesure d'exiger des sanctions pour échec. Que ce soit pour licencier de mauvais employés ou simplement pour les laisser se faire dinguer dans la revue annuelle des salaires ("Désolé, Bob, vous avez eu 17 bugs signalés comme votre faute, et c'est plus que la limite de 15"), c'est une punition.
Il dira probablement "Oh, non, nous ne voulons pas de ça", 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 sauf si vous allez l'utiliser. Veut-il soit sélectionner sur un critère donné ("Montrez-moi tous les bogues ouverts dans le sous-système créateur de rapport"), afin que vous puissiez travailler sur des choses, soit être en mesure d'obtenir des données agrégées ("Quel sous-système a le plus bugs "), afin que vous puissiez effectuer une analyse post mortem. Envisage-t-il une sorte de tableau d'échec où les gens peuvent être humiliés publiquement?
Alors, qu'entend-il? Veut-il pouvoir dire "Montre-moi tous les bugs qui sont la faute de Bob?" Pourquoi? Ou veut-il pouvoir dire "Montrez-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 aucune 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. Dans l'affirmative, il existe de meilleures façons de capturer ces informations qui ne créent pas une culture de pointage du doigt.