私の上司は、すべてのバグレポートに「責任者」フィールドを追加することにしました。どうすれば悪い考えだと彼に納得させることができますか？

最新の「WTF」の動きの1つで、上司はバグ追跡テンプレートに「Person To Blame」フィールドを追加すると、説明責任が増えると判断しました（ただし、機能/ストーリーにバグを結び付ける方法は既にあります）。これは士気を下げ、指さしを高め、バグが前代未聞になったとして報告された機能の欠落/誤解を説明しないだろうという私の主張。

私が使用できるこの実践に対する他の強力な議論は何ですか？このトピックについて、チームやボスと共有できる文章はありますか？

これは専門家が使用する根本原因フィールドのアマチュア名にすぎないことを伝えます（問題トラッカーに専用フィールドがない場合は、コメントを使用できます）。

以下のようなものをウェブで検索ソフトウェアのバグの根本原因の分析、この推論を正当化するためのリソースがたくさんあります^{1、2、3、4、...}。

...欠陥の根本的な原因は常に単一の開発者ではありません（この分野の主なポイントです）...

それがまさに「根本原因」が専門的であり、「非難する人」が素人的である理由です。個人的な説明責任は優れていますが、単に開発チームの「外部」に置かれる場合があります。

責任を負う開発者が 1人いる場合は上司に伝えてください。根本原因フィールドは間違いなくそれをカバーします（「コミット1234でボブが犯したコーディングの間違い、レビュー567でジムが逃した」）。根本原因という用語を使用するポイントは、そのようなケースを、開発チームの範囲外のケースとともにカバーすることです。

^{たとえば、バグの原因がハードウェアの障害である場合（責任者がチームの外で購入してテストした人である場合）、根本原因フィールドでそれをカバーできますが、問題追跡の流れ。}

^{開発チーム以外の誰かが引き起こした他のバグ（テスターのエラー、要件の変更、管理の決定）にも同じことが当てはまります。たとえば、管理者が災害復旧ハードウェアへの投資をスキップすることを決定した場合、データセンターの停電について「単一の開発者を非難する」ことは意味がありません。}

このようなポリシーのもう1つの可能性のある結果は、自分が「責任者」であると考える場合、バグを報告しないため、実際にチームが報告するバグの数を減らすことです。

私がそれに対して使用する主な議論は、彼が解決しようとしている問題を尋ねることです。同じ問題を解決するためのほぼ確実なより良い方法があります。

一つには、責める人は本当に一人しかいないのでしょうか？ある場合、あなたは何か間違ったことをしている。優れたプロセスでは、アナリスト、プログラマー、レビュアー、テスターを経て、本番に移行します。これらのすべての段階を実行していない場合は、おそらく上司が解決しようとしている問題の解決策でしょう。その場合、どちらが責任があるのでしょうか？それらのどれでもないかもしれません、それは責任があるレガシーコードかもしれません。

ひとたび噛み付いたり指を向けたりして、一度設定されると消えない黒いマークを避けようとするのは良くありません。それは何も解決しません。悪意を持って怠慢な人はほとんどいません。適切なレトロスペクティブを行う必要があります。何がうまくいかなかったか、また何ができるかを確認して、それが再び間違っていないことを確認します。

そのことから、ある人が定期的に過失に陥っているかどうか、そして別の問題に対処する必要があるかどうかを明確に確認できます。

説明責任の作成に設定されたマネージャーを停止するコツは、それを自由に提供することですが、実際にはあなたにとって意味のある方法です。

その分野には少なくとも3つの問題があります。

最初の理由は、人々を非難することは士気に合わないということです。OK。しかし、おそらく彼は士気を気にせず、悪い開発者を解雇したいと考えています。反論するのは難しい。

2つ目は、そのフィールドを正しく取得することは難しく、かなり大きな時間の無駄になることです。誰が悪いコードを書いたのかを見つけることよりも複雑です。そして、把握するのが困難な可能性のある情報は、サンドバッグ/不正行為される可能性があります。しかし、おそらく彼はその費用を支払い、情報を監査する用意ができているでしょう。いいよ

より根本的な問題は、このフィールドがアクションを起こすのに適したメトリックではないことです。確かに、彼は誰のコードが最も多くの欠陥を引き起こしているかの素晴らしいランキングを持っているでしょう。しかし、誰がそのリストのトップにいると思いますか？おそらく、会社の創設者か、欠陥率は非常に低いがトップレベルの開発者であり、生産性が非常に高いため、彼はコードの不均衡な部分を書いています。そのため、彼は最高の開発者を解雇するか、彼がもはや彼の最高の開発者ではないほど遅くなります。そして、月に1行のコード（できればコメント）を書く人は、おそらく彼の低い欠陥数に対して報われるでしょう。

さらに別のソフトウェアメトリックエラー。

フィールド化された欠陥の根本的な原因は決して一人ではありません。完全に誠実な人々は間違いを犯しますが、間違いを犯さないことを期待するプロセスは不合理です。手動または自動テストにより、展開前に運用システムへの変更を検証していない場合、バグは避けられません。

違う：

ボブは入力の確認を忘れ、プログラムはゼロで割ってクラッシュしました。

右：

ゼロ除算エラーに対して脆弱なコードは、展開前に検出されませんでした。無効な入力が適切に処理されることを確認するために、新しいテストケースが追加されました。コードが修正され、すべての新しいテストケースが合格しています。

「責任者」を「称賛する人」に変更します

バグを修正する主な担当者は、その名前を取得します。

簡単な答え。

「Blame」フィールドは、スケープゴーティングやフィンガーポインティング以外には使用されず、士気が低下し、チームの信頼が破壊され、誰もが何かを修正するのではなく自分のせいではないことを証明する方法を見つけようとします。また、同僚にトラブルを起こしてほしくないので、人々はバグを報告するよりも静かにしたいと思うでしょう。それは完全に非生産的です。

さらに重要なことは、正直な間違いを犯したことで誰かを犠牲にするか、問題をできるだけ早く修正することです。

あなたの上司は、バグは怠またはずさんな兆候だと考えているようです。そうではありません。彼らは人生の事実です。マイクロソフトは1年にいくつのパッチを公開しますか？

あなたが少しの市民的不服従をしているなら、各バグに対してその分野のすべての開発者のリストを置くことにチームを同意させてください。それが合わない場合は、「I'm Spartacus！」と書きます。代わりに。もちろん、ポイントはすべてのバグに対してあなたがすべての責任を負い、1つのバグを作成した個人を指摘しなければならないことに満足していないということです。

別のオプション：一緒に遊ぶ。特に何もしないでください-良い仕事をして、数か月間できるだけ正確にフィールドに記入してください。次に、各バグに責任を割り当てると、チームの全員が不幸で不快になると上司に説明します。作成されたバグと他の何か（スキル、努力、正気度）の間にほとんど相関がないと感じていることを彼に伝えてください。（実際には相関関係がないことを示す数値を実行できると便利です。）

Gandhian Civil Disobedience：すべてのフィールドに名前を付けて（他の開発者がステップアップしてバグに名前を付けない限り）、それがあなたのものであるかどうかにかかわらず、すべてのバグの責任を受け入れます。その分野や誰かを非難するという考えをこれ以上役に立たないものは何もありません。上司がすべての分野でなぜあなたの名前なのかと尋ねたら、「開発は非難ゲームだとは思わないので、本当に人々が非難し、十字架にかける必要があるなら、私をすべてのものに十字架につけ、私のチームを平和に働かせてください」と説明できます」

私はかつて上司にこれと非常によく似たシステムを実装させましたが、それはプログラミングではありませんでした（日刊紙の印刷デザインでした）が、コンセプトと適切な対応は同じです。

彼女がしたことは、私たちの書類に「責任者」フィールドを追加する代わりに、デザイナーのそれぞれに色の付いたステッカーのセットを与えました。各デザイナーは異なる色のステッカーを手に入れ、デザインに取り組んだり触ったりしたデザインの場合は、そのステッカーをそのデザインの書類に追加する必要があると指示されました。

「ステッカーイニシアチブ」に対する上司の明確な目標は、部門のすべてのエラー（書類のミス、ファイリング、不良コピー、本質的にはバグに相当する印刷）の原因を特定することでした

私たちがやったのは、他のデザイナーそれぞれに4分の1ステッカーを与えて、それぞれがすべての色を持つようにし、各デザインに自分の色だけを置くのではなく、デザイナーの4色すべてを置くことでした。

[Blame]ボックスに名前を書くだけではなく、チーム/プロジェクトに参加している全員の名前を入力し、チーム全体が同じことを確認してください。

私たちは彼女のオーウェル風の雌犬に対して協力しました。その結果、実際にお互いのミスをキャッチし、それについてお互いに話し合い、最終的にエラーを大幅に減らしました。彼女はsh * tマネージャーでしたが、彼女のイニシアチブが私たちを団結させ生産性を向上させることに気付いた代わりに、彼女はすべてのバターを得てステッカーシステムを解散し、それを失敗と宣言し、私たち全員を正式にre責しました。

彼の最も多作なプログラマを罰することになります。おそらく、ほとんどのプロジェクトに取り組んできた最高の従業員が1〜2人かもしれません。10人の部署に、出力の噴水にすぎず、インターフェイスコードの60％を書いたコーダーが1人いる場合、バグの60％は自分のコードにあります。

このシステムは、最も多くのコードを書く人が最悪のプログラマであり、最も少ないコードを書く人が最高のプログラマのように見えることを説明します。

これは、スコット・アダムズがディルバートの先のとがった髪のボスがバグ報奨金の失敗した知恵を指摘したときのように聞こえます。ウォーリーは彼が行って「彼に新しいミニバンを書く」と発表した。

公式ディルバートコミックストリップアーカイブからの1995年11月13日のディルバートコミックストリップ。

誰かが「落ちない」と指摘したスノースキーは、スキーが上手であることを示すものではありませんでしたが、多くの場合、何も試さない（またはまったくスキーをしない）ことを示すものでした。

プログラミングと設計の不備により、コードにバグが発生する可能性があります。しかし、それらは多くの難しいコードを書くことの結果として来ることもあります。最も多くのバグを生成する人々を丁寧に扱うことは、生産性の高い開発者と同じくらい貧しい開発者を丁寧に扱う可能性が高いです。

上司は欠陥の数にイライラしているようです。グループの人々は品質に情熱を注いでいますか？「誰」フィールドではなく、原因の「何」フィールドを作成すると、生産性が向上します。例：要件の変更、設計の欠陥、実装の欠陥など。製品の品質を改善するためのグループバイインがない限り、これでも失敗します。

たぶん、「バグを修正するのに最適な立場にいるのは誰か」と考えるべきでしょう。私の一部も感じています、あなたはそれを壊し、あなたはそれを修正します。何らかの説明責任があるはずです。

なんらかのスコアを維持することに同意しません。一部の人々は、コードのより複雑な部分で作業するため、より多くのバグを作成します。コードの行が有用なメトリックでない場合、コードの行ごとのバグの方が良いとは思えません。コードはチェックインされません。

ある時点で、マネージャーは誰が自分の仕事をしているのか、誰が仕事をしていないのか、そしてチームの他のメンバーが仕事をしているので誰がそれをうまくやっているのかを知る必要があります。

これまで誰もこれについて言及していなかったことは奇妙です。このような機能をバグトラッカーに追加すると、従業員はシステムをゲームしようとするようになります。

これは、他の同様のアイデア（コード行の数で支払う、バグの数で支払う）など、質問が提示したようなアプローチの一般的な問題です。これにより、多くの人が、取り組んでいるソフトウェアに関連する問題を解決するのではなく、良いスコアを取得することに集中するようになります。

たとえば、自分の責任を軽減するために文言でバグレポートを送信しようとすると、開発者が問題の原因を誤解する可能性があります（または、そのセクションを知らない別の開発者に作業が与えられる）最も多く取り組んでおり、バグの主な原因であるコードと同じくらい良いコード）、問題を修正するためのより多くの時間と労力につながります。

あなたの実際の質問は、会社を辞める前に文化を変える方法についてでした。バグレポートの責任者に人を加えることは悪い考えだと上司に納得させることによって。しかしもちろん、文化を変えるには、なぜこれが悪い考えであるかを本当に理解する必要があります。

これは大変な注文です。彼の心を変えた後、顔を救うという問題に加えて、個々の責任に関して主に解決策を考える人々は通常、その考え方にかなり設定されているという基本的な問題があります。

あなたはこのトピックについて書くことを求めました、そして、Peoplewareは思い浮かびます。それは高く評価されており、一般的には、出力の測定が困難な創造的な仕事をしている人々をどのように管理するかについて語っています。問題は、それを読んでもあまり役に立たず、上司がそれを読んで、少なくともその一部を信じなければならないことです。

奇妙なことに、ここでの問題はバグレポートよりも人に関するものであるため、プログラマよりも職場に属している可能性が非常に高いです。しかし、ソフトウェアプロジェクトの成功は、通常、人間の社会的相互作用にかなり大きく追跡可能であるため、実際の答えは、ほとんどの場合、ソフトウェアを超越するものに関するものです。

その他、半分の深刻な、提案があること（あなたが残すことを計画しているため、または言って同僚を説得）と言うことです私の唯一のあなたはプロジェクトの成功のための完全な責任を取って喜んで、あなたの名前がすべき常にフィールドに行きます、他の誰かが直接ミスを犯した場合でも、チームの全員が質の高い仕事をするようにする責任を負っています。

もちろん、それをバックアップすることはできませんが、何人かの人々（特に非難が大きい人）は本当にそのようなものを食べます。ロナルドレーガンは、政権のメンバーがスキャンダルに巻き込まれるたびに個人的な責任を公然と受け入れていました（そしてかなりの数がありました）。あなたにとって最良の部分は、責任は一般に実際の結果を伴わないことであり、彼らはあなたが責任を取るための立派な男だと思うだけです。

または、それがダウンする方法ではないかもしれません。私にはまったく意味がありませんので、いつ機能するかを予測するのは難しいですが、ビジネスをしていないように思えるときにそれが機能するのを目撃しました（レーガンの例だけでなく、職場で）。

人は間違いを犯そうとはせず、人的ミスであるかもしれないし、そうでないかもしれないことの責任を明確に定めるために設定された戦略は馬鹿げている-非常に専門的でないことは言うまでもない。

少なくとも、責任を負い、問題を「修正」するように割り当てられた「責任者」、または同様のイベントの発生を追跡および/または防止する計画を立てることが良いでしょう。解決策は、追加のトレーニングにすぎない場合があります。私はそれがあなたの職務記述書の一部である多くの会社で働いて、「会社が支払った/会社の時間」の教育を受けました。ある場所では、産業技術コースのために、地元の大学がときどき「借りる」「トレーニングセンター」全体を構築しました。

過去20年間、私は製造環境で働いてきました。プログラミングのミスはエラーを引き起こすだけでなく、物を物理的に破壊したり、さらに悪いことに人々を傷つけたりします。しかし、製造業のあらゆる分野で強力な1つの定数は、どのような状況においても、責任を負わないことです。それはシステムの欠陥であり、単純で単純なものだからです- 人々の欠陥ではありません。このように見てください-スペルチェッカーの使用-非常に効果的なツール、テキストの妙技の分野で不幸な人、または多分少し働きすぎた人のために...しかし、決して非難や説明責任の方法はありません。

作業環境は、その種類や目的に関係なく、システムです。個々のコンポーネントで構成されたシステムは、適切に「調整されている」場合、完全に調和して動作します-またはそのような類似性。

上司側の推奨読書：非常に効果的な人々の7つの習慣

彼は現実チェックではないにしても、少し謙虚さを使うことができたようです。彼は他の皆と同じようにチームの一員であり、それを理解する必要があります-またはそれがうまくいかないので、最終的には彼はバッグを保持します。

あなたの側で推奨される読書や研究：

分析、根本原因分析など、問題ではなく解決策を提供するためにあなたをより良い位置に置く5つの理由を調べてください。そして、上司との意見の相違は、それは問題であり、解決策ではありません。より良いもの、理にかなったものを彼に提供し、さらに彼がそのアイデアを信用できるように準備してください。

現在、彼は何かを修正する準備ができていないようです。何が壊れているのか、「私はボスだ」という考え方以外には、何が壊れているのかをしっかりと理解していないからです。

幸運を！特にこれらの時代に、すべての人に受け入れられる方法で、あなたがこれを乗り切ることを願っています。

編集：個人的には、私自身の経験から...「先に行って、私を責めなさい。それは...私、大きなオレのニヤリと笑った。」

説明責任のためにperson to blame、私はフィールドが欲しくなく、Person who knows the codeフィールドまたはフィールドが欲しいperson who can fixので、サポートチケットをどこに送るべきかを知っています。

これにより、バグ自体の修正プロセスが高速化され、説明責任が与えられます。これは、1石で2羽の鳥を殺すようなものです。私は個人的にこれを彼に持ち込み、これが失敗したと誰にも感じさせずに士気と説明責任を高めるのに役立つかどうかを彼に決定させます。極端なテストではすべてのバグが検出されるわけではありません。そうでない場合、バグの報告はありません。

「非難」は否定的だと彼に言ってください。それを「修正する人」に変更すると、少なくとも前向きな方法で組み立てられ、同じ仕事が行われます。彼らが「非難されている」場合、どのように人々は働くことができますか？！

上司がこれを行った場合、次のことがこの順序で発生します。

1）私はすぐに新しい仕事を探し始めます。

2）バグが責任者に報告されるたびに、そこに私の上司の名前が表示され、チームの悪いプロセスがそれを担当している理由に関するコメントが表示されます。そして、それを彼の上司に（できればバッチで）CCしましょう。ユニットテストはありますか？そうでない場合は、devプロセスが壊れている、つまりバグであることを意味します。すべての外部システムとの絶え間ない自動統合テストがありますか？その後、開発プロセスが壊れ、バグになります。スクリプトを介して本番環境のすべての環境を同一にし、人為的エラーを許可しないようにしますか？その後、開発プロセスが壊れ、バグになります。ある開発者はひどいですか？その場合、採用基準は悪条件であるため、上司の責任です。すべての開発者は1日12時間働いているため、休息がないために愚かな間違いを犯していますか？その後、devプロセスが壊れます。

サイドノートとして：すべての優れた開発マネージャーは、私が上に書いたことを知っています。また、アジャイル戦略は、開発者が減速している理由を上司またはその上司に指摘することを目的としています。バグの修正に50％の時間を費やしています。バグを修正するのに40％の時間を費やすことができるようにそれらを削減する戦略を見てみましょう。その後、この問題を再検討して30％にします。等

残念ながら、フィールドのためにあなたには良いマネージャーがいないようです。（1）を行うことをお勧めします。マネージャーに持ち出すことはお勧めしません（退社インタビューを除く）

あなたの上司はソフトウェアを深く理解しておらず、おそらく彼も意図していないようです。そのため、彼は異なる言語、異なる文化を持っています。

このような問題を解決するために仕事を辞めることは、解決策を求めて前進する前でさえ、ただのやめに過ぎません。終了は終了です。彼はあなたがお互いを理解することは決してできないことを確認するまで終了しないでください。そのことを確認するには、まず試してみてください。

彼は私たちの言語を知らず、彼は上司なので、ここでの最初のステップは彼の言語で彼と話をしようとするでしょう。言語とはどういう意味ですか？一緒に考えましょう：

私たちソフトウェアの人々は、私たちのほとんどが私たちの仕事を愛しており、私たちがやっていることと深いつながりを持っています。さもなければ、それは機能せず、愛するか完全であることがなければ、このビジネスで長い間続けることができません...あなたは空白を埋めます...

しかし、彼は物事を非常に異なって見ています。すべてのバグレポートで、私たちのほとんどは物事をより良くすることに興奮していますが（いや、時には非常にストレスが多い場合でも、私たちは問題を愛し、それを認めるだけです！）、彼はそれを失敗、つまり存在の尺度とみなします失敗しました。彼が理解したい最初のことは、バグが良いということです。バグにより、クライアントは会社を愛するようになります。（これが彼の言語です）顧客がバグを報告したとき、またはバグを自分で見つけたとき、それが解決された後、それは決して起こらなかった状況よりもはるかに優れています。バグは顧客の忠誠心（私は真剣です！）を生み出し、バグは消費者とソフトウェアのプロデューサーとの間のコミュニケーションに大きな言い訳を生み出します。

「バグの利益を増やす」ためには、バグレポートをさらにオープンにすることを提案すべきです。すべてのバグレポートとその迅速でクリーンで優れたソリューションにより、顧客は「すごい、これらの人たちはすごいです。彼らは本当に一生懸命働いています。解決しているこれらのことを見てください。事！」何とか何とか...

彼の言語で話してください。バグは問題ではなく、ソフトウェア会社にとって素晴らしいものです。彼らは私たちを生計を立てます。

チームの倫理、効率性、またはあなたが行うあらゆる種類の話のために、あなたが意図した反対の方法で働くかもしれません。あなたが辞めたいなら、彼は「ああ、私のソリューションは最初の日から機能し始めました！悪いリンクは公開される前にすでに自分でドロップし始めています！」と思うでしょう。彼は会社で不良少年を見つけるという彼の考えを信じており、そうでなければ彼を説得することは非常に困難です。特にあなたがそれらの悪い男の子の一人であるかもしれないとき！

それで、彼の本当の問題、バグに焦点を合わせてください。バグが非常に役立つことを彼に示してください。問題なく、関係は退屈です。あなたを殺さないすべてがあなたを強くします。すべてのバグは、顧客の幸福度を高めるために使用できる素晴らしい機会です。

これはあなたに言えることの一つです。彼の懸念について考えれば、リストに追加する他の多くのアイテムが見つかります。ゴールデンキーは、彼のアイデアと戦うのではなく、代替物を提供することです！

アジャイルをしている場合、機能/ストーリーのコメントから来ているように聞こえます。非難する人はそれのバグと同様に、完全な機能/物語を受け入れたバグがすり抜けせQA担当者、またはプロダクトオーナー/お客様のだろう。

私はその日に植字をしましたが、ここに私の見解があります。

これは、スペルミスなど、校正者が見つけたはずのミスをタイプセッターのせいにするようなものです。タイプセッターはつづりを間違えましたが、校正者はそれを逃しました。そのため、最初にエラーを犯した人ではなく、印刷ミスを責めるのは校正者です。

アジャイル環境では、エラー（バグ）をキャッチするのはQAの責任であり、正しくないものを受け入れないのはプロダクトオーナーの責任です。これは、開発者をリリースされるものから隔離する2つのレベルの証明リーダーです。これは、アジャイル環境で何かをバグとして分類する唯一の方法です。

あなたのマネージャーは間違った解決策で問題を解決しようとしていると思います。あまりにも多くのバグがリリースされており、あなたのマネージャーは開発者に彼らが書いたコードに対してより多くの所有権と説明責任を負わせたいという問題があるのではないかと思います。

テスト駆動開発を使用し、継続的統合サーバー（Jenkinsなど）をセットアップすると、「非難ゲーム」を導入することなく、この問題を解決するのに役立ちます。誰かが「ビルドを壊す」コードをコミットすると、責任者を示すメールがチームに送信されるため、継続的インテグレーションサーバーはこれにとって重要です。このコードは実稼働環境にリリースされていないため、この種の非難はより積極的で勇気づけられます（そして楽しい！）。

その結果、開発者はより多くの所有権を持ち、自信を持ち、本番コードのバグが少なくなります。

一人のミスが本番でバグを引き起こす場合、あなたの方法論、またはソフトウェアの全体的な開発方法に何か問題があることを指摘してください。バグが本番環境に到達するのを防ぐことはチーム全体の責任であることを指摘してください。

これらの2つの引数のいずれかを使用して、「whom to blame」フィールドを単一選択フィールドとして持つと誤解を招く可能性があることを上司に説得できるかどうかを確認します。そのため、「責任者」フィールドが複数選択フィールドであることを確認する必要があります。これを達成したら、すべてのバグについて、全員の名前がフィールドにあることを確認してください。上司は、最終的には、フィールドに関するレポートがすべて無駄であることを確認します。

ボスに信用を与えるために、「非難の割り当て」の概念はすでにSVNなどのツールに組み込まれています。デバッグ中に「話をする相手を見つける」開発者にとって、データの適切な使用は建設的です。 /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

上記の根本原因フィールドは良いことであるというgnatの応答に同意しますが、これは同じ情報ではなく、フィールドを「非正規化」して、影響を受けるソースに以前の開発者名を割り当てることがあります。技術的な説明（たとえば、「10000ユーザーにスケールしませんでした」）は、単に濁ります。私は根本原因を維持することを支持しますフィールドは明確に技術的な説明（例：明確なプログラマーエラーが発生した場合でも、「fooData = 999のときIndexOutOfRange Exception」などの詳細をキャプチャします）。これにより、まとめてレビューしたときにいくつかの有用なフィードバックを提供し、修正アクションを実行できますアーキテクチャまたはフレームワークの変更（たとえば、カスタムコンテナクラスの改善、トップレベルの例外処理）に関する問題のクラス全体を解決するため

ただし、Person To Blameフィールドを追加すると、非常に悪いメッセージと破壊的なメッセージをソフトウェアチームに送信できます。マネージャーは、この公的な精査により、開発者はこの「恥の壁」に名前を載せないように、より慎重かつ自主規制するようになると考えており、特にこれが追加された場合、開発者がこの脅威にさらされると感じる理由を理解していない一般的にすべてのバグレポートに。

これをバグフィールド/潜在的なメトリックとして追加することの問題は、列挙を開始するのが簡単です。

1. バグの解決は非常に多様であり、バグカウント/開発者の単純な統計にはこれが反映されません。
2. 開発者の能力は非常に多様です "" "" "" "" "" "
3. 多くのソフトウェアシステムにはリファクタリングが必要なコンポーネントがありますが、レガシーコンポーネントのリファクタリング（特にレガシーベースにユニットテスト機能がない/制限がある場合）は、最初にバグを導入します。開発者は、新しいバグの生成に関連したスティグマ/恐怖がある場合、この「良い」アクティビティを思いとどまる可能性があります（これらが解決するのが簡単で、最終的にシステムの大幅な改善があったとしても）。
4. テスターは、より詳細な分析が行われない限り、同じ問題に関連する非常に多様な数のバグを提出する可能性があり、その結果、バグの数/開発者の歪みが大きくなります。

それは氷山の一角にすぎません。これらを、誰がどのAPIの動作を期待しているのか、テストで間違った期待結果、間違った/欠落している要件に関する「チェーンの初期」の問題と結び付けてください。目標は、士気を損ない、大量脱出を引き起こすことです。）

ボスの視点に戻ると、コードを繰り返し破壊している開発者がいるかどうかを知り、それについて何か（できれば建設的）を試してみることは問題ありません。バグレポートにフィールドを追加してこの情報を取得しようとしても、上記の理由から意味のある情報を提供することはできません。私の経験では、この情報は、チームにプラグインされ、ほとんどのチーム会議に参加し、時折行われる一対一の会議で学んだ情報をチームメンバーと（慎重に）統合し、コード（コードを読み取れない場合でも）

手放してください。上司は、問題が発生した場合、それが問題を引き起こすことを自分で発見します。

率直に言って、あなたには意見があり、彼もそうです。彼はあなたの上司であり、彼の意見が勝者です。

はい、あなたはこの問題をめぐって戦争に行くことができますが、本当に価値がありますか？私はそれが不使用になる前に3ヶ月以上続くとは思わない。

しかし、積極的にこれを妨害したり叫んだりすると、余分な休暇、次の昇給、昇進、または非常に重要な設計決定が行われる時期を求めるために保存されている政治資本を使い果たします。

その時点で、本当に重要だと思ったら、nptは、あなたが「非難する人」の考えを積極的に妨害した人物であることを上司に思い出してもらいたいと思います。

決定を尊重しない場合でも、オフィスを尊重してください。

ずっと長く続く意思決定のためのストレスとテーブルドキドキを保存します。

チームでの開発にはソーシャルスキルが必要であることを上司に伝えます。彼はうなずくかもしれません。

しかし問題は、これが開発者にとって非常に悪いことだということです。適切な問題分析が非生産的であるよりも、非難を示唆するツールを追加することが重要です。

代わりに、ソーシャルスキルを向上させるためのインセンティブが必要であり、それをサポートするコミュニケーションインフラストラクチャが必要です。たとえば、積極的にそれを作成します。チケットを担当し、それを処理する人に名前を付けます。

また、コードレビューから始めて、お互いから学ぶことができるようにします。それは後で非難を免れます。

彼にこのSO質問をメールしてください。彼が理性に寛容であれば、ここのコメントは彼の理性の健全性チェックを提供します。彼が合理的でない場合、あなたは理にかなっている理由で彼を説得することはまずありません。さらに、彼は会話以外の理由を読むことができます（会話の熱中に「正しい」という動機が取り除かれたために、より説得力がある場合があります）。

また、方向転換を試みることもできます。フィールドは、「同様のバグの発生を回避するための可能なステップ」、またはその効果より短いものである可能性があります。その後、ソリューションをプールし、職場を改善するために実装するソリューションに投票できます。おそらく、ソリューション指向のアプローチの方が生産性が高く、好評を博している可能性があります（提案の再検討に実際のフォロースルーがある場合）。

ここに2つの可能性があります：彼は間違いを犯した人を罰したいのか、それとも考えていなかったのです。誰にでも認識しているのは、間違いを犯した人を罰するつもりだということです。それが彼が奨励したい文化であるかどうか彼に尋ねてください。

私の上司はバグ追跡テンプレートに「Person To Blame」フィールドを追加すると説明責任が増すと判断しました

私の経験では、経営者が「人々に説明責任を持たせたい」とき、彼らが意味するのは、失敗に対する罰を正確に受けたいということです。成績の悪い人を解雇するのか、それとも年次給与レビューで彼らを汚すのか（「ごめん、ボブ、あなたのせいで17のバグがあり、それは15の制限を超えている」）、それは罰です。

彼はおそらく「ああ、いや、私たちはそれを望んでいない」と言うだろうから、そのデータがどのように使われるかを彼に尋ねる。使用する予定がない限り、データベースにデータポイントを追加しないでください。特定の条件（「レポート作成者サブシステムの未解決のバグをすべて表示する」）で選択して、作業を行うか、集計データを取得できるようにしますか（「どのサブシステムが最もバグ」）、事後分析を行うことができます。彼は、人々が公に屈辱を受けるようなある種の失敗のトートボードを想像していますか？

それで彼はどちらを意図していますか？彼は「ボブのせいであるすべてのバグを見せて」と言いたくありませんか？どうして？または、彼は「ほとんどの場合、障害のある人を見せてください」と言いたいですか？どうして？最初のものは意味がなく、2番目のものは懲罰的です。または、3番目のオプションは、彼には本当の理由がないということです。

チームの中で、スキルの向上に支援が必要なプログラマーを探している可能性があることを認めます。もしそうなら、この情報をキャプチャするより良い方法がありますが、それは指さしの文化を作成しません。

ここで注目すべき重要な側面は、「ボス」に対するチーム内のコミュニケーションがどの程度オープンであるか、またはその逆であると考えています。しかし、管理の観点からは、指を指すことは決して良いことではありません。開発者の1人が同じ問題に何度か陥った場合、この繰り返しの問題を克服する手助けをしようとするかもしれません（たとえば、ジョンは適切にテストしていません）コード：過去3か月間に3つの本番バグ、チェックリストを提供して、コードがどのようになっているのか、どのようにテストするのかを覚えておきましょう）。

開発の観点からは、「非難」はすでにSVNなどの主流のツールに組み込まれているため、「ジョン、書いたがらくたを修正してください」に名前を付けても問題はありません。それ。JIRAには、バグを報告するときに人の名前も組み込まれます（このフィールドは、それを担当する人にとって実際には意味がありませんが、だれかが修正するほどのものです）。

バグが発生した場合、開発者、テスター、QA、マネージャーに共通の責任があります。ある時点であなたの上司が電話で怒っているクライアントを「ごめんなさい、ジョンはこれを適切にテストしなかった」などのことで処理したら、間違いなく別の仕事を探しているでしょう。良い上司は、「これを処理します」と言ってください。名前も、指先も、ソリューションもありません。

繰り返しますが、私はそれがすべてのコミュニケーションにあると信じています。おそらく、上司がやりたいのは、開発チームで誰が問題を抱えているか、チームがどのような問題を抱えているかを確認することです（おそらくトレーニングセッションですか？）。あなたが上司やチーム全体と話をしない限り、決定（または、より良い言い方をすれば、私たちのポスター/読者）です。