私の上司は、すべてのバグレポートに「非難する人」フィールドを追加することにしました。それが悪い考えであることをどうやって彼に納得させることができますか？
私のボスは、最新の「WTF」の動きの1つで、バグ追跡テンプレートに「Person To Blame」フィールドを追加すると、アカウンタビリティが向上することを決定しました（バグを機能/ストーリーに結び付ける方法はすでにあります）。これにより士気が低下し、指さしが増加し、バグとして報告されていない機能や誤解されている機能は未然に報告されません。
私が使用できるこの慣習に対する他のいくつかの強力な議論は何ですか？このトピックについて、チームや上司と共有できる文章はありますか？
これは、専門家が使用する 根本原因 フィールドの素人の名前にすぎないことを伝えます（課題追跡に専用フィールドがない場合は、コメントを使用できます）。
ソフトウェアのバグの根本原因の分析のようなものをウェブで検索してください、この理由を正当化するための多くのリソースがあります 1 、 2 、、 4 、...。
...欠陥の根本的な原因は必ずしも1人の開発者であるとは限りません（これがこの分野の主要なポイントです）...
それがまさに「根本原因」が専門的であり、「非難する人」が素人的である理由です。個人の説明責任はすばらしいですが、単に開発チームの「外側」にいる場合もあります。
1人の開発者が責任を負うときが上司に知らせる、根本原因フィールドは間違いなく（）コミット1234のボブ、レビューでジムが見逃した567 "）。 根本原因という用語を使用するポイントは、そのようなケースをカバーすることです、に沿って開発チームの範囲外。
たとえば、バグの原因がハードウェアの障害である場合（責任を負うのは、それを購入してテストしたチームの外の誰かである）、根本原因フィールドでそれをカバーできますが、「単一の開発者の責任」は単に破るだけです 課題追跡 フロー。
同じことが、開発チーム外の誰かによって引き起こされた他のバグにも当てはまります-テスターのエラー、要件の変更、および管理上の決定。たとえば、管理者が災害復旧ハードウェアへの投資をスキップすることを決定した場合、データセンターでの停電について「1人の開発者を非難する」ことは意味がありません。
このようなポリシーのもう1つの考えられる結果は、「非難する人」であると思われる場合、人々はバグを報告しないため、チームによって報告されるバグの数が実際に減少することです。
私がそれに反対する主な議論は、彼が解決しようとしている問題を尋ねることです。同じ問題を解決するには、ほぼ確実に優れた方法があります。
一つには、非難する人が本当に一人だけいるのでしょうか？もしあれば、何か他のことをしています。優れたプロセスは、本番環境に到達する前に、アナリスト、プログラマー、レビュー担当者、テスターを介して作業を行います。これらの段階のすべてを実行していない場合は、それが上司が解決しようとしている問題の解決策かもしれません。あなたがしている場合、どちらが責任がありますか？それはそれらのどれでもないかもしれません、それは責任があるべきレガシーコードである可能性があります。
それが設定されたら消えない黒いマークを回避しようとして、人々が指を後ろから噛んで指さしているのはよくありません。それは何も解決しません。悪意を持って過失している人はほとんどいません。 適切なレトロスペクティブ を実行する必要があります。問題が発生したことを確認し、問題が再発しないようにするために実行できることを確認してください。
そこから、1人の人が定期的に過ちを犯しているかどうかがはっきりとわかります。これは、対処する別の問題である可能性があります。
アカウンタビリティを作成する上で設定されたマネージャーを停止するコツは 自由に提供する ですが、実際にはあなたにとって意味のある方法です。
その分野には少なくとも3つの問題があります。
第一に、非難する人々は士気に良くないということです。 OK。しかし、おそらく彼は士気を気にせず、悪い開発者を解雇したいと考えています。反対するのは難しい。
2つ目は、そのフィールドを正しく設定するのが難しく、かなりの時間のシンクになることです。それは、誰が悪いコードを書いたかを見つけることよりも複雑です。そして、理解するのが難しい潜在的な情報は、サンドバッグ/チートされる可能性があります。しかし、多分彼はその費用を払って情報を監査する用意がある。いいよ.
より根本的な問題は、このフィールドは行動を起こすのに適した指標にはならないということです。確かに、彼はそのコードが最も多くの欠陥を引き起こすニースのランキングを持っているでしょう。しかし、誰がそのリストのトップになると思いますか？おそらく、会社の創設者、または非常に低い不良率を持っているが生産性が非常に高いトップ開発者が、コードの不釣り合いな部分を書いているのでしょう。したがって、彼は最終的に彼の最高の開発者を解雇することになるか、または彼に彼がもはや彼の最高の開発者ではないほど遅くすることになるでしょう。そして、1か月に1行のコード（できればコメント）を書いている彼らは、おそらく彼の低い欠陥数に対して報酬を得るでしょう。
さらに別のソフトウェアメトリック障害。
フィールド化された欠陥の根本的な原因は決して一人ではありません。完全に良心的な人々は間違いを犯し、彼らが間違いがないと期待するプロセスは不合理です。展開前に手動または自動テストのいずれかで本番システムへの変更を検証しない場合、バグは避けられません。
違う：
ボブは入力をチェックするのを忘れ、プログラムはゼロで割ってクラッシュしました。
正しい：
ゼロ除算エラーに対して脆弱なコードは、展開前に検出されませんでした。無効な入力の適切な処理を検証するために、新しいテストケースが追加されました。コードが修正され、すべての新しいテストケースに合格しています。
「非難する人」を「賛美する人」に変更
バグを修正する主な担当者がその名前を取得します。
簡単な答え。
「非難」フィールドは、スケープゴーティングと指差し以外の目的には使用されず、士気は低下し、チームの信頼は破壊され、誰もがそれを修正するのではなく、自分のせいではないことを証明する方法を見つけようとします。また、同僚にトラブルを起こさせたくないので、バグを報告するのではなく、静かにする傾向があります。それは完全に逆効果です。
正直な間違いを犯したことで誰かを犠牲にしたり、問題をできるだけ早く修正したりすることの何がより重要ですか？
あなたの上司は、バグは怠惰またはだらしのしるしだと思っているようです。そうではありません。彼らは人生の事実です。 Microsoftは1年間にいくつのパッチをリリースしますか？
少しの不服従が必要な場合は、チームに各バグのすべての開発者のリストをそのフィールドに入れることに同意してもらいます。それが合わない場合は、「私はスパルタカスです！」代わりに。もちろん、要点は、すべてのバグの責任はすべてあなたにあり、1つのバグを作成した個人を指摘しなければならないことに不満があるということです。
別のオプション：一緒に遊ぶ。特に何もしないでください。数か月間できるだけ正確にフィールドに入力してください。次に、各バグに責任を割り当てるとチームの全員が不満で不快になることを上司に説明します。作成されたバグと他のもの（スキル、努力、健全性）の間にはほとんど相関関係がないと感じていることを彼に伝えてください。 （実際には相関関係がないことを示すいくつかの数値を実行できる場合に役立ちます。）
Gandhian Civil Disobedience：あなたの名前をすべてのフィールドに入力し（他の開発者がステップアップしてバグの名前を入力しない限り）、それがあなたのバグかどうかにかかわらず、すべてのバグのせいにしてください。その分野や誰かを非難する考えをこれ以上役に立たないものにするものはありません。上司がすべての分野でなぜあなたの名前なのか尋ねた場合、「開発は責任のないゲームではないと思うので、本当に人を責め、十字架につける必要があるのなら、私のためにすべてを十字架につけ、チームが平和に働くようにしましょう。 」
私はかつて上司にこれとよく似たシステムを実装させました。それはプログラミングではありませんでしたが（それは日刊紙の印刷デザインでした）、概念と適切な対応は同じです。
彼女がしたことは、私たちの書類に「責任者」フィールドを追加する代わりに、デザイナーのそれぞれにカラーステッカーのセットを与えました。各デザイナーは異なる色のステッカーを受け取り、作業中のデザインや触れたデザインについては、そのデザインの書類にステッカーを追加する必要があると指示されました。
上司が述べた「ステッカーイニシアチブ」の目標は、私たちの部門のすべてのエラーの原因を明らかにすることでした（事務処理の間違い、ミスファイリング、不正なコピー、本質的にはバグと同等の印刷物）
私たちがしたことは、他の各デザイナーにステッカーの4分の1を与えて、それぞれにすべての色を持たせることでした。各デザインに私たちの色だけを置く代わりに、4人のデザイナーすべてを置きました'色
[Blame]ボックスに自分の名前だけを入力しないでください。チーム/プロジェクトにいる全員の名前を入力し、チーム全体が同じことを確認してください。
私たちは彼女のオーウェルのビッチネスに対して協力し、その結果、実際にはお互いの間違いを見つけ、お互いに話し合うことになり、最終的にはエラーが大幅に減少しました。彼女はしゃれたマネージャーでした、そして、彼女のイニシアチブが私たちを団結させて生産性を向上させたと認める代わりに、彼女はすべての尻込みをして、ステッカーシステムを解体し、それを失敗と宣言し、正式に私たち全員を叱責しました。
これは、スコットアダムスがバグバウンティの失敗した知恵をディルバートの先のとがった髪のボスに指摘したときとよく似ています。ウォーリーは彼が行くと発表し、「彼に新しいミニバンを書く」と発表した。
1995年11月13日のディルバートコミックストリップは、公式のディルバートコミックストリップアーカイブから入手できます。
誰かがスノースキーで「落下しない」と指摘したのは、スキーヤーが上手いという兆候ではなかったことを思い出しました。
プログラミングとデザインが不十分なため、コードにバグが発生する可能性があります。しかし、それらは多くの困難なコードを書いた結果として生じることもあります。最も多くのバグを生成する人々をDingすることは、生産性の高い開発者と同じくらい貧しい開発者をDingする可能性があります。
上司は多くの欠陥に不満を感じているようです。あなたのグループの人々は品質に情熱を持っていますか？ 'who'フィールドではなく、原因に対して 'what'フィールドを作成すると、生産性が向上します。例：要件の変更、設計の欠陥、実装の欠陥など。製品の品質を向上させるためのグループの協力を得ない限り、これでも失敗します。
それは彼の最も多作なプログラマーを罰することになります。おそらく、1人か2人が最も多くのプロジェクトに取り組んだ最高の従業員かもしれません。 10人の部門で、出力の泉に過ぎず、インターフェイスコードの60％を記述したコーダーが1人いる場合、バグの60％がコードに含まれます。
このシステムは、最も多くのコードを書く人が最悪のプログラマーであり、最も少ないコードを書く人が最高のプログラマーであるように見せかけることを説明します。
たぶん、「バグを修正するのに最適なのは誰ですか？」私の一部も感じ、あなたはそれを壊し、あなたはそれを直します。ある程度の説明責任があるはずです。
ある種のスコアを維持することに同意しません。一部の人々は、コードのより複雑な部分で作業するため、より多くのバグを作成します。コードの行が有用な指標ではない場合、コードの行ごとのバグの方が良いとは思えません。コードはチェックインされません。
ある時点で、マネージャーは、誰が自分の仕事をしていて誰がやっていないのか、そしてチームの他のメンバーがやっているので誰がより上手にやっているのかを知る必要があります。
あなたの実際の質問は、会社を辞める前に文化を変える方法についてでした。上司にバグ報告の担当者を追加することは悪い考えだと説得することでした。しかしもちろん、文化を変えるには、彼が本当に理解する必要がありますなぜこれは悪い考えです。
これは難しい注文です。心を変えて顔を救うという問題の他に、主に個人のせいで解決策を考える人は、通常、その考え方にかなり固執しているという基本的な問題があります。
あなたはこのトピックについて書くように頼んだ、そして Peopleware が思い浮かぶ。それは高く評価されており、出力を測定することが難しい創造的な仕事をしている人々をどのように管理するかについて一般的な言葉で話します。問題は、それを読んでもあまり役に立たないことです。上司はそれを読んで、少なくともその一部を信じなければなりません。
奇妙なことに、ここでの問題はバグレポートよりも人に関するものであるため、プログラマよりもワークプレイスに多く属している可能性があります。しかし、ソフトウェアプロジェクトの成功は、通常、人間の社会的相互作用にかなり深く追跡可能であるため、実際の答えは、多くの場合、ソフトウェアを超えるものに関するものです。
私の唯一の、半分深刻な提案は、あなたが喜んでそうだと言う（またはあなたが去る予定なので同僚に言うように説得する）ことですプロジェクトの成功に全責任を負い、あなたの名前はalwaysでなければなりません。誰か他の人が直接ミスをしたとしても、あなたはチームの全員が質の高い仕事をするようにする責任。
もちろんそれはナンセンスですが、どうやってそれをバックアップすることができますか。しかし、一部の人々（特に非難されている人々）は実際にそれを食べています。ロナルド・レーガンは、彼の政権のメンバーがスキャンダルに巻き込まれるたびに（そしてかなりの数があった）、個人の責任を公に受け入れていましたが、それは実際に毎回かなり政治的にうまくいきました。あなたにとって最良の部分は、責任は一般に実際の結果を伴わず、彼らはあなたが責任を取るために立ち上がった男であると考えているということです。
または、それがダウンする方法ではないかもしれません。私にはまったく意味がないので、いつ機能するかを予測するのは難しいですが、ビジネスが機能していないように見える場合（職場では、レーガンの例だけではない）に機能しているのを目にしました。
誰もこれについて前に触れたことがないのは奇妙です。そのような機能をバグ追跡に追加すると、従業員はシステムをゲームで試すに動機付けられます。
これは、他の同様のアイデアの中で、質問が提示したようなアプローチの一般的な問題です（コード行数で支払う、バグ数で支払う）。これは多くが彼らが取り組んでいるソフトウェアに関連する問題を解決するのではなく、良いスコアを得ることに集中することを奨励します。
たとえば、自分のせいを少なくするために文言を付けてバグレポートを提出し、それを誰かに押し付けようとすると、開発者が問題の原因を誤解する可能性があります（または、そのセクションを知らない別の開発者に作業が渡されます）最も多くの問題に取り組んでおり、バグの主な原因となったコードと同じくらい優れたコード）により、問題の修正により多くの時間と労力が費やされました。
人々は間違いを犯すことに熱心に取り組みませんし、人為的ミスであるかどうかを明確に非難するために設定された戦略はばかげています-非常に専門的でないことは言うまでもありません。
少なくとも、担当して問題を「修正」するように割り当てられた「責任者」、または同様のイベントの発生を追跡および/または防止するための計画を考え出すことが望ましいでしょう。時々、解決策は追加のトレーニングに過ぎません。私は多くの会社で働いていて、それがあなたの仕事の説明の一部だったので、「会社が支払う/会社の時間」の教育を受けるようになりました。 1つの場所では、地元の大学が産業技術コースのために時々「借りる」「トレーニングセンター」全体を構築しました。
私は過去20年間製造環境で働いてきました。プログラミングのミスは単にエラーを引き起こすだけでなく、物理的に物事を破壊し、さらに悪い場合には人々を傷つけます。しかし、強いものであるすべての製造分野における定数の1つは、いかなる状況においても非難される人がいないことです。それはシステムの欠陥であるため、人々の欠陥ではありません-ではありません。このように見てください-スペルチェッカーの使用-非常に効果的なツールです。テキストの妙技の領域で不幸な人や、少しだけ機能しすぎた人のために...しかし、決して責任や説明責任の方法ではありません。
作業環境は、どのような種類、またはどのような目的で使用される場合でも、システムです。個々のコンポーネントで構成されたシステムは、適切に「調整」されている場合、完全に調和して機能します-またはそのようなものに似ています。
上司側の推奨される読み物： 非常に効果的な人々の7つの習慣
彼は現実のチェックではないにしても、少し謙虚さを使うことができるように思えます。彼は他の皆と同じようにチームの一員であり、彼はそれを理解する必要があります-またはそれはうまくいかず、結局のところ、彼は関係なくバッグを保持します。
あなたの側で提案された読書や研究：
分析、根本原因分析の5つの理由を調べてください。問題ではなく、解決策を提供するために解決策を提供するためのあらゆること上司との意見の相違は、それが問題であり、解決策ではありません。より良い何か、理にかなった何かを彼に提供し、彼がアイデアを信用できるようにする準備をしてください。
今のところ、彼は何かを修正する準備ができているようには見えません。なぜなら、彼の「私はボスです」という考え方以外に、何が壊れていても、何が壊れているのかをしっかりと理解していないからです。
幸運を！特にこれらの時代において、すべての人に受け入れられる方法で、これを乗り越えることができれば幸いです。
編集：個人的に、私自身の経験から...「どうぞ、私を非難してください。十分に確信しているので、私はそれを修正し、将来、それが再び起こったら、誰がその日を救うためにそこにいますか？うん、あなたそれを推測した...私、大きなオレの笑顔。」
説明責任のために、私はperson to blameフィールド、Person who knows the codeフィールドまたはperson who can fixフィールド。サポートチケットの送信先がわかるようにします。
これは、バグ自体を修正するプロセスを高速化し、1つの石で2羽の鳥を殺すような、説明責任を与えます。私は個人的にこれを彼に持ってきて、これが失敗したように誰も気付かずに士気と説明責任を高めるのに役立つかどうか彼に決めさせます。極端なテストはすべてのバグをキャッチするわけではありません。そうでなければ、バグレポートはありません。
上司がそうした場合、次のことがこの順序で行われます。
1）すぐに新しい仕事を探し始めました。
2）責任者と一緒にバグが報告されるたびに、上司の名前が表示され、チームの悪いプロセスが原因である理由に関するコメントが表示されます。そして、それを上司にCCします（できればバッチで）。単体テストはありますか？そうでない場合、それは開発プロセスが壊れていることを意味し、したがってバグです。すべての外部システムとの継続的な自動統合テストを行っていますか？その後、開発プロセスが壊れ、バグが発生します。人的エラーを許容しないように、スクリプトを使用してすべての環境を本番環境で同一にする機能はありますか？その後、開発プロセスが壊れ、バグが発生します。 1人の開発者はひどいですか？その場合、採用基準は上司のせいです。すべての開発者は1日12時間作業しているため、休息がないために愚かな間違いをしていますか？次に、開発プロセスが壊れます。ご覧のとおり、バグの100％は上司の責任です。
余談ですが、すべての優れた開発マネージャーは、私が上に書いたことを知っています。また、アジャイル戦略は、開発者が減速している理由を上司またはその上司に指摘することを目的としています。つまり、バグの修正に50％の時間を費やしています。バグを修正するために40％の時間を費やすことができるようにそれらを減らすための戦略を見てみましょう。その後、この問題を再検討して30％にします。等.
残念ながら、フィールドのために優れたマネージャーがいないようです。だから私は（1）を実行し、それをマネージャーに持ち込まないことをお勧めします（出口インタビューを除く）
「非難」が否定的であることを彼に伝えます。 「修正担当者」に変更すると、少なくともポジティブな方法でフレーム化され、同じ作業が引き続き行われます。 「非難」されている場合、人々はどのように働くことができますか？！
あなたがアジャイルをやっていて、あなたがfeatures/storiesコメントから来ているように聞こえる場合。 責任者は、バグをすり抜けさせるQA担当者、または機能/ストーリーを完了したと認めた製品所有者/顧客です。それのバグ。
私はその日に植字をしました、これが私の見解です。
これは、校正者が見つけたはずのスペルミスなど、タイプミスを非難するようなものです。タイプセッターがつづりを間違えましたが、校正者はそれをミスしました。そのため、印刷を間違えたのは校正者の責任ですnot最初にエラーを犯した人。
アジャイル環境では、エラー（バグ）をキャッチするのはQA担当者の責任であり、正しくないものを受け入れないのは製品所有者の責任です。これは、リリースされるものから開発者を隔離する2つのレベルのプルーフリーダーです。これは、bugとして分類される必要がある唯一の方法ですアジャイル環境。
あなたの上司はソフトウェアを深く理解していないようで、おそらく彼もそうするつもりはありません。だから彼は異なる言語、異なる文化を持っています。
このような問題のために仕事を辞めることは、解決策に向かって前進する前であっても、単にやめるべきことです。終了は終了です。彼があなたがお互いを決して理解することができないと確信するまで、やめないでください。それを確かめるために、あなたは最初に試みるべきです。
彼は私たちの言語を知らず、彼は上司なので、ここでの最初のステップは彼と彼の言語で話すことです。言語とはどういう意味ですか？一緒に考えましょう：
私たちはソフトウェアの人々であり、私たちのほとんどは私たちの仕事を愛しています。さもなければそれはうまくいきません、そしてそれを愛するかまたは完全であることがなければこの人に長い間続けることができません...あなたは空白を埋めます...
しかし、彼の見方は大きく異なります。すべてのバグレポートで、私たちのほとんどは事態を改善することに興奮しています（いいえ、それが時々本当に非常にストレスが多いとしても、私たちは問題を愛し、それを認めるだけです）、彼はそれを失敗、つまり存在の尺度と見なしています失敗。彼が最初に理解したいことは、バグは良いことです。バグはクライアントに会社を愛してもらいます。 （現在、これは彼の言葉です）顧客がバグを報告したとき、または自分でバグを見つけたとき、それが解決された後、それが発生したことのない状況よりもはるかに優れています。バグは顧客の忠誠心を作り出します（私は真剣です！）、バグはソフトウェアのコンシューマーとプロデューサー間のコミュニケーションの素晴らしい言い訳を作ります。
「バグの利益を増やす」には、バグレポートをさらにオープンにする必要があります。すべてのバグレポートとその迅速でクリーンで優れたソリューションにより、顧客は「すごい、これらの人は素晴らしいです！彼らは本当に一生懸命働いています。彼らが解決しているこれらのことを見てください。ソフトウェアがこんなに複雑であることさえ知りませんでした事！」何とか何とか何とか...
あなたの行動を起こし、彼の言語で話しなさい。バグはソフトウェア会社にとっては問題ではなく素晴らしいものです。彼らは私たちに生計を立てています。
チームの倫理、効率、またはあなたが行うあらゆる種類の話では、意図したとおりに機能しない可能性があります。あなたがやめたいのなら、彼は「ああ、私のソリューションは最初の日から機能し始めました！悪いリンクは、公開される前にすでに自然に落ち始めています！」彼は会社で悪い男の子を見つけるという彼の考えを信じており、そうでなければ彼を説得することは非常に困難です。特にあなたがそれらの悪い男の子の一人かもしれないとき！
それで、彼の本当の問題であるバグに注目してください。バグが非常に役立つことを彼に示してください。問題なく、関係は退屈です。あなたを殺さないものはすべてあなたを強くします。すべてのバグは、お客様の幸せを高めるために使用できる素晴らしい機会です。
これはあなたが言うことができるただ一つのことです。彼の懸念について考えると、リストに追加する他の多くの項目が見つかります。ゴールデンキーは、彼のアイデアと戦うのではなく、代わりのものを提供することです。
あなたのマネージャーは間違った解決策で問題を解決しようとしていると思います。おそらく、リリースされているバグが多すぎるという問題があり、上司は開発者が書いたコードに対してより多くの所有権と説明責任を持たせたいと考えています。
テスト駆動開発を使用し、継続的インテグレーションサーバー（ Jenkins など）を設定すると、「非難ゲーム」を導入することなく、この問題を解決するのに役立ちます。継続的インテグレーションサーバーが重要なのは、「ビルドを壊す」コードを誰かがコミットすると、その人に責任があることを示すメールがチームに送信されるためです。このコードは実稼働環境にリリースされていないため、このタイプの非難はより積極的であり、励みになります（そして楽しい！）。
その結果、開発者はより多くの所有権を取り、自信が増し、製品コードに含まれるバグが少なくなります。
一人の間違いがバグを本番環境で発生させる場合は、方法論またはソフトウェア開発の全体的な方法に問題があることを指摘してください。バグが本番環境に到達しないようにするのはチーム全体の責任であることを指摘してください。
これらの2つの引数のいずれかを使用して、「誰に責任があるか」フィールドを単一選択フィールドとして持つことは誤解を招くであろうと上司を説得できるかどうかを確認してください。そのため、「誰のせいにするか」フィールドが複数選択フィールドであることを確認する必要があります。これを達成したら、すべてのバグについて、全員の名前がフィールドにあることを確認してください。上司は最終的に、フィールドに関するレポートがすべて無駄であることを確認します。
上司に信用を与えるために、「非難の割り当て」の概念はすでに [〜＃〜] svn [〜＃〜] のようなツールに組み込まれており、データの適切な使用は開発者にとって建設的です。デバッグ中の「会話する相手を見つける」の例： http://www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html
上記のgnatの応答に同意しますが、Root Causeフィールドは良いことですが、これは同じ情報ではなく、フィールドを「非正規化」して影響を受けるソースに以前の開発者名を割り当てたり、技術的な説明（例：「10000ユーザーにスケーリングしない」）を設定したりすると、水が濁ってしまいます。 Root Causeフィールドを明確に技術的な説明（たとえば、明確なプログラマエラーの場合でも、 "IndexOutOfRange Exception when fooData = 999 "）これは、まとめてレビューしたときにいくつかの有用なフィードバックを提供する可能性があり、アーキテクチャまたはフレームワークの変更に関する問題のクラス全体を解決するためにいくつかの修正アクションを実行できます（たとえば、カスタムコンテナクラスの改善、トップレベルの例外処理） ）
つまり、Person To Blameフィールドを追加すると、非常に悪いメッセージと破壊的なメッセージがソフトウェアチームに送信され、管理者が個人を特定して罰したいと考えることになります最も頻繁にコードを壊す開発者。私はマネージャーがこの公開審査により開発者がこの「恥の壁」に名前を付けるのを避けるためにより注意深く自己規制するようになると考えており、特に追加された場合、開発者がなぜこれに脅かされるのか理解していません一般的にはすべてのバグレポートに。
これをバグフィールド/潜在的なメトリックとして追加することに関する問題は、簡単に列挙できます。
- バグは解決が非常に変化しやすく、バグ数/開発者の単純な統計ではこれを反映しません。
- 開発者は機能が非常に変動します "" "" "" "" "" "
- 多くのソフトウェアシステムにはリファクタリングが必要なコンポーネントがありますが、レガシーコンポーネントをリファクタリングすると（特に、レガシーベースにユニットテスト機能がない/制限されている場合）、最初にバグが発生します。新しいバグの生成に関連する不名誉/恐怖が存在する場合、開発者はこの「良い」活動に落胆する可能性があります（これらが解決するのが簡単で、最終的にシステムに大きな改善があったとしても）。
- より詳細な分析が行われない限り、テスターは同じ問題に関連する非常にさまざまな数のバグを提出する可能性があり、その結果、非常に歪んだバグ数/開発者になります。
それは氷山の一角にすぎません。これらを、誰がどのAPI動作を期待するか、テストで誤った期待される結果、および「チェーンの前の方」の問題が正しくない/欠落しているという問題を組み合わせて、このようなメトリックが無価値であると運命づけられていることは明らかです（ただし、目標は士気を損ない、大量脱出を引き起こすことです。）
上司の視点に戻ると、コードを繰り返し破壊している開発者がいるかどうかを確認し、それについて何かを（うまくいけば建設的に）試したいと思うことは問題ありません。バグレポートにフィールドを追加してこの情報を取得しようとしても、上記の理由により、意味のある情報は提供されません。私の経験では、この情報は、チームに接続し、ほとんどのチームミーティングに参加し、時折1対1のミーティングでチームメンバーと学んだ情報を（注意深く）統合し、サブシステムに慣れることで学習できます。コード（コードを読み取れない場合でも）
手放すだけ。上司は、問題が発生した場合、それが問題の原因であることを自分で発見します。
率直に言ってください、あなたには意見があります。彼はあなたのマネージャーであり、彼の意見は勝つものです。
はい、あなたはこの問題について戦争に行くことができますが、それは本当に価値がありますか？それが使用されなくなるまでに3か月以上続くとは思えません。
しかし、これを積極的に妨害したり、それについて叫んだりすると、余分な休暇、次の昇給、昇進、または非常に重要な設計決定が行われる時期を求めるために節約された政治的資本が使い果たされます。
その瞬間、それが本当に重要であるとあなたが考えた場合、あなたは「あなたが非難する人」という彼の考えを積極的に妨害した人であることを上司に覚えてもらいたいのです。
あなたが決定を尊重しなくても、オフィスを尊重してください。
ずっと長く続くであろう決定のためのストレスとテーブルドキドキを保存してください。
チームでの成長には社会的スキルが必要であることを上司に伝えます。彼はうなずくかもしれない。
しかし問題は、これが開発者にとって非常に悪いことです。非難を示唆するツールを追加することは、適切な問題分析が逆効果になることよりも重要です。
代わりに、社会的スキルを向上させるためのインセンティブと、それをサポートする必要がある通信インフラストラクチャが必要です。たとえば、積極的にそれを作成します。チケットの責任者であり、チケットの面倒を見る人に名前を付けます。
また、コードレビューから始めて、お互いから学ぶことができるようにします。それは後で責任を免れます。
SO質問。さらに、彼は会話の外にある理由を読むことができます（会話の真っ只中に「正しい」という動機が取り除かれているため、より説得力がある場合があります）。
また、向きを変えてみることもできます。このフィールドは、「同様のバグの発生を回避するための可能な手順」、またはその効果よりも短い何かである可能性があります。次に、ソリューションをプールして、職場を改善するために実装するソリューションに投票できます。おそらく、ソリューション指向のアプローチの方が生産性が高く、受け入れられる可能性が高くなります（提案の再検討に実際のフォロースルーがある場合）。
私はここに2つの可能性があると考えています。彼は間違いを犯した人々を処罰できるようにしたい、またはそれをまったく考えていなかっただけです。誰にでも知覚は間違いを犯した人を罰するつもりであるということを彼に知らせてください。それが彼が奨励したい文化であるかどうか彼に尋ねなさい。
上司は、「Person To Blame」フィールドをバグ追跡テンプレートに追加すると説明責任が増えると判断しました
私の経験では、経営陣が「人々に説明責任を負わせたい」と望むとき、彼らが意味することは、彼らは失敗に対する正確な処罰ができるようになりたいということです。貧しいパフォーマーを解雇することであろうと、年次給与レビューで彼らをうんざりさせることであろうと（「申し訳ありません、ボブ、あなたのせいとして報告されたバグは17個あり、それは15の制限を超えています」）、それは罰です。
彼はおそらく「ああ、いや、私たちはそれを望んでいない」と言うでしょうから、そのデータがどのように使用されるかを彼に尋ねます。使用する場合を除いて、データベースにデータポイントを追加しないように注意してください。彼は与えられた基準（「レポートクリエーターサブシステムで未解決のバグをすべて表示」）を選択して、物事に取り組めるようにするか、または集約データを取得できるようにしますか（「どのサブシステムで最も多くのバグ」）。これにより、事後分析が可能になります。彼は人々が公に屈辱を受けることができるある種の失敗のトートボードを想定していますか？
それで彼はどちらを意図していますか？彼は「ボブのせいであるすべてのバグを見せて」と言えるようになりたいですか？どうして？それとも、彼は「ほとんどの場合、誰が間違っているのか見せてくれ」と言えるようになりたいのでしょうか？どうして？最初の1つは意味がなく、2番目は懲罰的です。または、3番目のオプションは、彼には本当の理由がないということです。
私は彼が彼らのスキルを向上させるのに助けが必要なチームのプログラマーを探している可能性があることを認めます。もしそうなら、指を指す文化を作らない、この情報をキャプチャするより良い方法があります。