私自身とチームの両方で、ミスに対する責任などの重要な品質についてお話したいと思います。
私の意見では、開発者またはリーダーの決定が最も困難で不快なものの1つ（はい、それは常に難しい）、彼がリリースしようとしている製品またはリリースで彼のミスを見つけたとき、経営陣に行って伝えてください。 このエラーは製品版にありますが、これがユーザーにどのような影響を与えるかを理解しようとしています。」
これは自然で正常なことであり、そうであるべきですが、感覚は常に不快です。 また、リーダーとして、私のチームからそのようなニュースを聞きたいです。 誤解しないでください、私はそのようなニュースでテクニカルディレクターに行くのが好きなマゾではありませんが、間違いが重大であり、会社の費用がかかる場合は、そのようなニュースを受け取ることが非常に重要です。
あなたが開発者である場合、なぜあなたはそのようなケースについて話す必要がありますか？
製品のエラーを修正する必要があり、次のリリースで簡単に注ぐことができるように思えますが、なぜ頭を悩ますのですか？
上司に悪い知らせがあるのはなぜですか？
状況の制御（または可視性）。 上司が最後に望むのは、上級管理職が問題を彼に知らせることです。これは、状況が「沈黙」している場合にも起こります。
さらに、「何をするのが正しいか」という決定は、このような状況で頭が行うことができ、また行うべきであり、これは彼の責任のレベルです。 おそらく、リーダーは、会社の規模が小さい場合や災害の規模が大きい場合は、この状況の説明を上位のリーダーに、または所有者に伝えます。
エラーの結果の大きさを評価することが重要です。
想像してみてください。 金融システムで、顧客と会社の間の相互決済に関連するエラーが見つかりました。 また、エラーの規模を数値で推定することもできます-そうですか？ 彼らは少し間違え、クライアントの1％が5ルーブルではなく、5ルーブル、15コペックを請求されましたか？
この1％のクライアントでは、偶然（サンドイッチの法則など）、大規模なクライアントが侵入することができます。 誰もがエラーを持っていますが、システムがどのように機能し、会社がそれらを処理するかは非常に重要です。
- 金額をさかのぼって、口座にお金を戻すルールはありますか？ レポートは何もなかったように見えますか？
- アカウントに15セントで静かに戻り、これは別の動きで見ることができます
- 彼は謝罪の手紙と何がうまくいかなかったかの詳細な説明を送ります。それは報告書で見ることができ、調整が行われた場所です。これはすべて目に見えて透明です。
異なるアプローチは非常に異なる結果につながります。
そのような状況では、会社は評判の損失ほど多くの金銭的負担を負わない（時には彼らも）。 これを特別に担当する社内の人々、アカウントマネージャー、マーケティング、営業部門、一般的には給与を支払っている人々による評判の損失を評価し、軽減することをお勧めします。 これはIT部門ではありません。 多くの場合、このような重要なクライアントがシステムをテストしていることに気付かない場合がありますが、スーパーバイザーは状況を理解し、問題の範囲を正しく評価するために必要な情報を持っている場合があります。
決断を下す時です。 私が言ったように、おそらくあなたのスーパーバイザーは上記の情報で行くでしょう。 彼に状況を通知することにより、あなたは彼に不快な会話に備えるための余分な時間を与えます。
情報はマネージャーが効率的に管理するものであり、この部分をマネージャーから奪う必要はありません。 船員はこれを船長に報告することを恐れていたので、船に穴を開けて航海することはほとんどありませんか？ はい、もちろん、私たちは船乗りではありませんが、船長は正しい決定を下すために、システムまたは今後のリリースの問題を常に認識している必要があります。
頭のために
あなたがリーダーであり、あなたのチームが混乱した場合（特定の人がいることもあれば、数人である場合もあります）。 私はこれを行う方法について非常に良い先生（ありがとう、Ruslan）がいました、そして私はレッスンを学んだことを望みます：
レッスン1.引っ張らないでください。エラーはすでに発見されており、非常に重大であるため、すぐに報告してください。 通話を妨げることを恐れないでください。
レッスン2.より多くの事実。できるだけ乾燥して正確に説明してください。 チームがあなたにこのニュースを持ってきたことを忘れないでください、その顔を救おうとしてください、あなたとあなたのチームはあなたのリーダーのためのものです。 間違いを修正するために講じている対策を教えてください。もう一度繰り返さないでください。
規模を推定します（重大なエラーの場合、最初に報告してから規模を評価し、再通知する必要があります）。 情報を数字で表示-ユーザーの数、エラーが発生した日付、その場合は機能したなどをカウントします。 VIPクライアントが苦しんでいる人のリストにあるかどうかを確認し、顧客管理を担当する部門にリストを提供します。
レッスン3.誰が具体的に間違いを犯したか？誰が具体的に間違いを犯したかではなく、何が起こったかに焦点を合わせようとします。 あなたはあなたのリーダーを知っています、彼はあなたを知っていますが、彼はあなたのチームを知りません。 「Petya Sidorovが25回目に間違えられた」と言うと、「Petya」を解雇する必要があると思われるかもしれません。
私の意見では、そのような決定は自分に任せるのが最善です。 悪い知らせで私のところに来る従業員を解雇しません。 おそらく彼は訓練される必要があります。
プロセスの何が問題なのかを考えてみてください。エラーは予定通りにキャッチされなかったものです。 極端な場合、状況が繰り返され、プロセスの変更が役に立たない場合は、別の作業領域への移行を検討する必要があります。 従業員に対する制裁があってはなりません。 ですから、チームに、非常に悪いニュースであっても、私にニュースを安全に届けるように言ってください。
リーダーに戻りましょう。 私の意見では、あなたのリーダーが悪いニュースを正しく認識する準備ができていないことを知っているなら、あなたは怒りをとらなければならないでしょう。 はい、冗談ではありません。 オプション：
- 私たち（チーム）は間違っていましたが、これは...
- コードにエラーが見つかりましたが、これが原因で...
その他。
最終的には、あなたがあなた自身のチームほど責任を負わないという事実に対して支払われるお金の一部です。
結論として
この振る舞いは、多くの場合、会社にとってもキャリアにとっても良い結果につながります。 私はリーダーと幸運でした、そして、ニュースは開発者とリーダーとして持って来るのに安全でした。 そして何度か、解雇される可能性は低いが、「ペティア」はできるので、チームを閉じて、失敗したと言う方が安全だと気づいた時がありました。 リーダーには勇気があり、仕事を失うことを恐れる必要があります。私の意見では、リーダーの市場参入意欲は常に仕事を落ち着かせ、より良くしますが、これは別の記事のトピックです。