リスク管理の分野でのカスタネシアの戦士

リスク管理とは何か、忍者の器用さに対処する方法を知りたいですか？

それから、キャットへようこそ！



（この記事では、Tom DeMarcoの作品から着想を得た考えの概要を説明します。おそらく、この記事は、彼の作品に既に精通している人にとっては興味のないものでしょう。









1988年、デンバー市は古い空港の代わりに新しい空港を建設することを決定しました。 当時存在していた空港は、成長する都市のニーズを満たしておらず、拡張には不向きでした。 予算が割り当てられ、建設が始まりました。 しかし、残念ながら、プロジェクトを予定どおりに完了できませんでした。 遅延の理由は時間ソフトウェアに書かれていませんでした。 空港には、荷物を運ぶために設計された低く狭いトンネルが装備されていました。 ソフトウェアは、荷物のバーコードをスキャンし、トンネルのネットワークを介して正しい方向に向けることを想定していました。 ソフトウェアが不完全なため手荷物が不可能だったため、空港はソフトウェアの準備が整うまで待機していました。 空港の建設は巨額の設備投資に関連しているため、急いでいるプログラマーが追いつくためにこの資本がすべて凍結されました。 そして時は金なりです。 損失利益+損失は5億ドルに達しました...メディアは、ソフトウェアプロバイダーとしての組織の評判を破壊し、すべての責任を負いました。



そして、このプロジェクトのマネージャーが貴重な時間の半日を費やし、ブレインストーミングによるリスク評価に従事したと想像してみましょう。 滑走路やソフトウェアが時間通りに準備できなかった場合にどのような損失が発生するかを収集して分析し、不可抗力の場合に損失を減らす方法を考えたと想像してください。 簡単に言えば、小さなトンネルのネットワークが荷物を運ぶ唯一の方法ではありません！ わずかに広いトンネルの建設に数百万ドルを費やした場合、荷物は安価な労働力または小型トラックの助けを借りて輸送できます。 200万は5億をはるかに下回っています。 最終的には、トンネルの拡張に投資することさえできず、そり犬を使用することができます！ 犬のハンドラーを雇って、野良犬の最寄りの犬小屋の所有者と手配し、トレーニングを開始します。 ソフトウェアが時間通りに準備できていれば、シャワルマ空港ではホットドッグの価格は変わらないでしょうが、困難な場合にはそり犬が状況を救うことができました。 いずれにせよ、これは少なくともある種のセーフティネットです。 しかし、一つだけあります。 そのようなことについては、事前に考える必要があります。 プロジェクトの配信の指定日に、請負業者が「ボス、すべてが失われました！」と叫びながら走ります。その後、新しいトンネルや犬を訓練するのは遅すぎます。これを終えると、請負業者の仕事はおそらく論理的な結論に達するでしょう。

用語

プロジェクトの予算に潜在的なリスク損失とリスクの確率を掛けると、これはリスク抑制と呼ばれます 。 リスクが生じるかどうか。 そうでない場合、あなたのお金はあなたに残ります。 もしそうなら、おそらくあなたが予算に入れた余分なお金は十分ではないでしょう。 しかし、すべてのリスクを評価し、それらの一部が発生し、一部は発生しない場合、 おそらく予算を満たします。



リスクの損失を最小限に抑えるために事前にお金をかける場合、これをリスク軽減と呼びます 。 たとえば、犬を訓練するために犬のハンドラーを雇うとき。 リスクがあるかどうかは関係ありません。犬の飼い主はあなたの費用で食事をして楽しみます。







空港建設のリスクの緩和と抑制の割合を示してみましょう。

同様のプログラムが、別のプログラマチームによって2倍の長さで作成されたことが知られています。 さらに、プログラマはスケジュールに追いつくことができないと絶えず不満を言うので、最新の状態を維持できる確率は50％であると想定します。 実際、リスクチャートに精通している場合、可能な限り最適なシナリオが発生する確率はナノパーセントに等しいことに同意しますが、私たちは建設マネージャーと同様に期待をわずかに上回り、成功の確率は50％であると想定します。 ひげを生やしたジョークのように、成功するかしないかのどちらかであるため、50％です。 一般にITでは、ほとんどの場合、一時的および確率的推定値は直感的に「天井から」与えられます。 したがって、リスクの確率は1 \ 2、価格は5億、リスクを抑えるために5億の半分を置きます。 リスクを軽減するには、数ヶ月に渡るドッグハンドラーの給料、1トンのドッグフード、および未完成の空港に住んでいる犬を掃除する管理人の給料が必要になります。 さて、またはより広々としたトンネルの価格はあなたの好みです。 次のようになります。







ご覧のとおり、この特定のケースでのリスク軽減ははるかに有益です。 もちろん、リスクが発生しない場合、あなたは費やしていないかもしれないリソースを費やすことになります。 しかし、一方で、それが来て、あなたが安全でなかった場合、結果は悲惨なものになります。 これは、綱渡りをするときに安全ロープでお金を節約するようなものです。 リスクを軽減することは、リスクを抑えるよりもはるかに安価であり、そのメリットは明らかです。 しかし、逆の状況を見てみましょう-リスク抑制がそれを軽減するよりもはるかに安い場合はどうでしょうか？ これは、この場合、リスクを抑える必要があるということですか？ 実際、常にではありません。 ここでは、戦士の哲学が私たちを助けます。







こののんきな農家をご覧ください。 彼は、自分の畑に水をまき、雑草を取り除くほど、豊かになることを知っています。 のんきな農家の世界の写真は次のようになります。







私が試してみるほど、私は多くを得ました。 依存関係は指数関数的です。一定の上限に達するまで、時間の経過とともに、同じ努力に対してより多くの報酬（資格や社会での地位の増加、受動的所得の増加など）が得られます。 すべてが予測可能でシンプルです。







そして、これは大胆不敵な戦士です。 戦士は千の小さな傷を受けるかもしれませんが、彼の足でしっかりと立ち続けます。 致命的な打撃を受けるまで。 両者の対立の間、各当事者は敵の致命的なリスクを最大化しようとします。 敵を死に追いやるのは、心臓に計算された打撃を与えるよりもはるかに効果が低い。 戦士にとって、「より多くの努力-より多くの報酬」という式は機能しません。 彼は1つの間違いのためにすべてを失う可能性があります。 両方の哲学は、リスクの概念-地主と戦士の両方-に当てはまりますが、それでも戦士の概念はより密接です。 リスクが生じるかどうか。 これにより、プロジェクトが失敗するかどうかが決まります。 シールド付きまたはシールド付き。 一方、私たちは古代日本に住んでいません。理解できない状況で犯罪者の頭を左右に切るのは慣習ではありません。 失敗したすべてのプロジェクトが組織の内訳やマネージャーのキャリアの終了を意味するわけではありません。 いずれにせよ、それは最も絶望的な状況のように思われます。少なくともいくつかの利点を引き出すことができます。 機能を減らしてプロジェクトを完了し、ターゲットオーディエンスを変更し、次のプロジェクトで達成した成果を使用し、プロジェクトの失敗の理由について結論を導き、これが将来発生しないようにすることができます。 この失敗から失敗に終わることはありませんが、少なくともあなたの努力の一部は報われるでしょう。

2つの力の対立におけるリスクの例

ホワイトはナイトを次の動きでe5に移動します。 黒が女王を倒した場合、マットは次のようになります。

7 ... C：d1黒い象が白い女王を切り取る

8. C：f7 + Kp：e7馬のカバーの下にある白い象は、チェックを黒で表示します。 黒は、e7の王による唯一の可能な動きを持っています。

9. K：d5＃d5の2番目の馬。 チェックメイト



対戦相手の女王を切り倒してチェックする機会がありますが、対戦相手が発生したリスクを認識できる場合、ゲームに負けます。 これは、パーティーにとって致命的な（または重大な）リスクです。







チームの知的なゲーム-DotAの例を考えてみましょう。各チームは5人で構成されています。 これまたはそのプレイヤーが地元で小競り合いをするほど、キャラクターが強くなり、チームがゲームに勝つ可能性が高くなります。 しかし、たとえ1つのチームが何度も勝ち、もはや希望がないように思えても、支配的なチームのプレイヤーが犯した1つのミスは、チーム全体の損失を意味する場合があります。 チェスでの目標が王を倒すことである場合、DotAでの目標は、対戦相手のチームの強さの源（「白人」の世界樹または「黒人」の魔法の氷の玉座）を削減することです。 プレーヤーは、相手チームの弱いプレーヤーを攻撃するか、一緒に攻撃することでリスクを取ることがあります。 リスクは、実際にはトラップになる可能性があり、プレイヤーが待ち伏せから保険をかけられることです。 2人のプレイヤーがよく組織された待ち伏せに巻き込まれた場合、最も近いプレイヤーは「復活」の前にしばらくの間「殺され」、ゲームから除外され、2番目のプレイヤーは彼を救おうとするかもしれません（しばらくゲームから除外されるリスクがあります）または相手チームが最初のプレイヤーを扱うのと同じくらい速く走ります。 2番目のプレイヤーがリスクを負い、「死ぬ」場合、チームは少数派のままになります。 その後、敵チームは本格的な攻撃を開始し、数値的な利点を活用して、防御を破壊し、敵の「強さの源」を破壊することができます。



これは、アクションムービーの最後のバトルに似ています.1人のキャラクターが戦いを通して多くのリュウリを受け取り、一般的に戦いのお気に入りを完全な弱虫として見ますが、最後には奇跡によって敵をノックアウトに送ります。 はい、戦士の哲学は、彼女です。 さらに投げ、高くジャンプし、激しく打ち、より多くの経験を持つだけでは十分ではありません。 可能性のあるリスクを予測するには、知恵と勇気が必要です。



負けたチームが何を間違えたか見てみましょう。 たぶん彼らは攻撃して、待ち伏せをするべきではなかったのでしょうか？ 実際、それは価値がありました。 リスクと利益は密接に関連しています。 有料のリスクは勝利を近づけます。 誰もリスクを負わない、彼はシャンパンを飲まない。 別のことは、 賢明にリスクを取る必要があるということです 。 この場合、2番目のプレーヤーは、揚げたような匂いがすることに気付いたとき、パートナーではなくチームを救う価値がありました。 一方、困っている友人を捨てざるを得ない場合、これはあなたが何か間違ったことをしているという明確な兆候です。 この場合、偵察を実施した後、リスクを軽減する必要がありました 。 はい、これには追加のリソースと時間が必要になりますが、リスクは大幅に削減されます。 さらに、チームが支配し、インテリジェンスにいくつかのリソースを費やす余裕がありました。 どうやら、差し迫った勝利の感覚が彼らを困惑させ、彼らは起こりうるリスクを完全に忘れていました。 敵を軽視することは致命的な間違いです。 人々の間の関係は、相互尊重の上に構築されることを忘れないでください。



さて、質問に戻って、リスク抑制がそれを軽減するよりもはるかに安い場合、この場合のリスクを抑える価値はありますか？ リスクの封じ込め=リスクの確率*リスクの発生による損失であることを思い出させてください。 リスクが発生した場合、全額を支払う必要があります。これは、リスクを封じ込めることに固有の額の数倍になる場合があります。 この金額を支払う機会がなく、これがプロジェクトの失敗を示している場合、私の意見では、リスクの軽減に対処する方が良いでしょう。 リスクを軽減できない場合は、このプロジェクトに取り組む価値があるかどうかを慎重に検討する価値があります。 私の意見では、すべてを失うリスクよりも潜在的な利益の半分を得る方が賢明です。 もちろん、すべてのリスクを制御することはできません。 リスクと利益は密接に関係しているため、チャンスをつかむことが理にかなっている場合があります。 tomorrow石が明日あなたの家に落ちないことを保証することはできませんが、これはあなた自身の住宅を取得しない理由ではありません。 たぶんそれは落ちるでしょうが、そうでないかもしれません。 しかし、それは価値があります！ しかし、一方で、これは、万が一落下した場合に安全でない理由ではありません。 数ヶ月間賃貸住宅に十分な銀行の小額のお金には、路上での寒さによる凍結のリスクが含まれている可能性があります。



革新的な技術の場合、リスク管理は非常に微妙なゲームになります。 一方では、新しいテクノロジーを使用することは多くのリスクの前兆となりますが、他方では、それを利用するリスクを冒さないことは、競合他社があなたを回避できるリスクを負うことを意味します。 この場合、リスクを冒さないことは、リスクを取ることよりもはるかに大きなリスクです（かなり複雑に聞こえますよね？）。 私が言ったように、私の意見では、すべてを失うリスクよりも潜在的な利益の半分を得る方が賢明です。 もちろん、ここでは特定の状況の評価が必要です。 最初に袖に切り札がなかった場合、利益を減らすことで、競合他社に市場から追い出されることになります。 この場合、何らかのアクションのユニバーサルアルゴリズムを作成することはできません。 ヘルムート・フォン・モルトケ元Marが言ったように、敵との戦闘衝突に耐えることができる計画は一つもありません。 予測と並行して現在の状況を理解することは、プロジェクトのあらゆる段階で役立ちます。

リスク管理プロセスにおけるあなた自身の過ちから学ぶ

デンバーの空港の状況では、責任と損失は実際に市町村に下がったものの、すべての責任は特定のパフォーマーに割り当てられました。 マネージャーは、自分が何か間違ったことをしたことをどのように理解できますか？ 私は次のパターンに気付きました： 小さな失敗がより大きくより重大な結果につながる場合、リスク管理のどこかで間違いが発生します。 たとえば、ソフトウェアが利用できないために、空港全体がアイドル状態になっている場合。 または、たとえば、停電のために信号灯が機能しない場合（そのような場合は、バックアップ発電機を用意することができます）。 間違ったボタンを誤って押したために、地球の半分が断片の形で宇宙に飛び込んできた場合。 しかし、ロビーのコーヒーメーカーのコーヒーを注ぐボタンの隣に、核のスーツケースのボタンを配置する必要はありません。 マネージャーにとって、これは次のように見えます。あるアーティストがミスをし、間違ったボタンを押したが、今は地球がなく、すべての欠点はアーティストにあります。 まあ、彼は少し間違えたように見えますが、不眠症は間違ったボタンを押しただけです。 エラーの重要性が感じられず、それが信じられそうに聞こえる場合、これはリスク管理が非常にひどく行われたというシグナルです。 もちろん、これは人類を破壊した実行者を正当化するものではありません。 しかし、企業の方針では、すべてのコーヒーマシンに核のブリーフケースのボタンが存在する必要があるオフィスで働く必要はありません。 まあ、または少なくとも、これらのマシンに3メートルよりも接近する必要はありません。 また、企業ポリシーの変更を実現したり、これらのマシンをフェンスで囲んだりすることもできます。 残念ながら、ほとんどの企業では「イニシアチブは処罰されます」ので、個人の時間にお金のためにフェンスを設置する必要があります。また、管理者でなく権限や能力を持っていなくても、これらのフェンスに関連するすべてのリスクに対しても責任を負う必要がありますこれらのリスクを管理します。

別のケースも考えられます-リスクが表面にある場合、定期的に多くの問題を引き起こしますが、誰もがそれを無視すると、パフォーマーは、彼らがもたらす問題のように間違いは避けられないと考えます。 中毒は問題に発展するので、エラーの重要性とその結果の重要性の感覚はありませんが 、起こっていることの地獄の感覚があります。

ITからの話をいくつか考えてみましょう。

歴史1.疑わしいリーダー。

昔々、1つのスタートアップの利益のために、異なる都市で2つのチームが働いていました。 最初のチームは、製品パートナー（副ディレクター）と彼のアシスタントで構成されていました。 どちらもマネージャー、アナリスト、テスターの機能を組み合わせました。 2番目のチームは、複数のプログラマ、テスター、チームリーダーで構成されていました。 彼らは、インターネットから取得した情報の自動収集と処理、およびウェブサイトでの公開に従事していました。 情報が収集されたソースは異なる形式であり、これらのソースの開発者の気まぐれで変更される可能性があるため、それらから情報を正しく収集することは常に可能ではありませんでした。 この目的のために、テスターは24時間体制でソースからの情報とプロジェクトWebサイトの情報を比較しました。 エラーを発見したテスターは、ボード上のバグで対応するカードを起動し、プログラマーがそれを修正し、プログラムの次のバージョンでは、そのような情報がソースから正しく受信されます。 また、別の都市では、別のテスター-アシスタントアシスタント-が品質を管理しています。 彼は長年の、すでに修正されたバグを見つけますが、カードを起動しませんが、product-ovnerに報告します。 その後、プログラマは彼らの言うことを元気よく報告します。このバグはすでに修正されており、この特定のケースの情報を最新のアルゴリズムで再配布しただけで、すべてがエラーなしで進みました。 所有者はプログラマーを信頼せず、彼らは自分自身とバグを見つけられないテスターをカバーすると信じていました。 残念ながら、プロジェクトの仕様により、新しいバージョンがリリースされるたびにソースからすべての情報を転送することはできませんでした。まず、情報の量が多く、次に情報の関連性と価値が失われました。 一般に、しばらくして、遠隔チームに状況の深刻さを伝えるために、パートナーはテスターの解雇とチーム全体の罰を脅かし始め、チームリーダーはアシスタントアシスタントに目を向けることをためらわず、職場の雰囲気はあまりうまくいきませんでした。

この状況は事前に予測できたでしょうか？ 簡単ではありませんが、可能です。 プロセスの各参加者の場所で順番に自己紹介し、彼の仕事の責任を考慮し、彼が何をし、どのような困難に遭遇するかを想像するだけで十分でした。 別の都市のovnerは、リモートチームが冷たくて怠けないようにし、プロジェクトの全体的な戦略的方向性を設定する必要があります。 アシスタントはこれで彼を助けるべきです。 チームは動作するはずです。 当然のことながら、プロセスの完全な透明性がないと、疑いが雄羊の頭に潜入する可能性があります。 さらに、パートナーもアシスタントもプログラミングに関与したことがなく、リモートチームの生産性を客観的に評価できなかったため、完全な透明性を実現できませんでした。 したがって、競合を防ぐ唯一の方法は、「反対者」が何かの過失を見つけられないようにすることです。 このリスクを予測し、行動を起こす必要がありました。 しかし、リスクが発生した場合でも、チームリーダーとパートナーは問題を解決する方法を探しませんでした。 彼らは有罪を探し始めました。 プログラマーは、テストサイトで毎週前月のデータを削除して補充することを提案することで問題を部分的に解決し、アシスタントアシスタントが最新のアルゴリズムで受信したデータのエラーを探すようにしました。 ここでの主な問題は、異なる都市のチーム間の信頼と尊敬の欠如であり、この問題は解決されていません。 しかし今では、パートナーは少なくとも文句を言う必要がありません。

道徳：問題を解決し、責任をシフトしません。 （プロジェクト全体の責任は、プロジェクトマネージャーにあります。詳細については、 マネージャーのブラックブックを参照してください。）問題の解決とは、状況を分析し、問題の根本的な原因を見つけ、リスクの軽減が適切かどうかを評価して、将来の問題の再発を防ぐことです。部下へのリスクを軽減するための対策の割り当て、これらの対策の実施の監視。 もちろん、これの前に、リスクの結果を排除する方法について指示を与える必要があります。

歴史2.新しいプログラムへの急激な移行

アカウンティング用のプログラムが1つあり、それをプログラムAと任意に呼びます。データベースを介してプログラムAにデータを転送する新しいプログラムBを作成することが決定されました。 生産プロセスに関するより詳細なデータが古いプログラムAよりも新しいプログラムBに導入され、必要なデータがBで計算されてAに転送されました。ユーザーはBにデータを入力し、古いプログラムAを使用する必要がありました。 Aのデータだけでなく、ユーザーにいくつかの新機能を提供しました。 新しいプログラムBの開発者は、プログラムAのビジネスロジックと、それが記述されたDelphi言語を知らなかったため、著者Aがどのデータとどのテーブルを転送するかを明確にしました。

残念ながら、この組織にはテスト部門がなく、ビジネスロジックを知っているアナリストはパートタイムのボスであり、テストと部分的な分析を部下のプログラマーに転送することを好みました。 プログラマーがアナリストのかなり抽象的な技術的タスクを誤解した場合、未検証で誤って実装されたプログラムがユーザーに送信されました。

ユーザーが古いプログラムにデータを入力し続けないように、そのような機会をユーザーから強制的に削除し、テストが不十分な新しいプログラムに突然移行することにしました。 マネージャは、古いプログラムの作成者にタスクを与えて、データの入力を禁止する変更を加え、すぐにタスクを完了しました。 古いプログラムの作者は、今回はテストが実施されたと単純に信じていたかもしれません。 おそらく、問題の不可避性に慣れるという上記の問題が役割を果たしたのでしょう。 なるほど、彼はリスクについては言わなかった。 まあ、多分彼は無意識のうちに、古いプログラムのビジネスロジック（もちろんマネージャーアナリストを除く）を知っている唯一の人物として、テストを実施しなければならず、彼が現在のタスクの条件に失敗することを理解しました。 それはともかく、テスト不足のプログラムは強制的にユーザーに配信されました。 いくつかの特定のケースが考慮されていないことが判明したことが予想されました。 このため、ユーザーの作業は数時間にわたって数回停止され、プログラムに急いで変更が加えられました。 これに対する責任は、新しいプログラムの開発者にボスによって割り当てられました。

このケースで管理者の観点からどのような間違いが行われたかを見てみましょう。 前の話で、チームリーダーがリスクを理論的に予測し、リスクを軽減することができた場合、プログラミングに関与したことがないこのマネージャーはそのような機会を得ることができませんでした。 リーダーはITプロセスを管理しなければならなかったので、彼女はそれを理解していなかったため、より多くの責任を、それらを理解した人々、つまり最終的な執行者に移そうとしました。 しかし、彼女は暗黙のうちにそれをしました。 つまり、いくつかの誤って計算されたリスクの後、プログラマーは上司の完全に明確で隠されていない位置に気付いているはずです：あなたはプログラマーであり、私が何も理解していないあらゆる種類の魔法のことを行い、あなたはプロジェクトで起こるすべてに責任があります しかし、リスク管理の研究と開始のタスクは誰にも直接発行されませんでした。 リーダーがいくつかの問題で無能であることが起こりますが、特定のタスクを任せることができる部下がいるため、これは問題ではありません。 描く方法がわからない場合-デザイナーに任せる、ウェブサイトの書き方がわからない-プログラマに任せる、リスクを管理する方法がわからない-上級プログラマーに任せる、リスク管理の有効性を確認する方法がわからない-アウトソーシングする 主なことは、誰が何に対して責任があるのか​​を明確に理解することです。 雇用時に労働責任が交渉されるとき、それは良い形と見なされます。 この場合、実質的に誰もリスク管理に関与していません。 まあ、ほとんどのマネージャーが優れたリーダーを持っていることを忘れないでください。 プロジェクトマネージャーがプロジェクト全体を担当する場合、シニアマネージャーはユニット全体のプロジェクト全体を担当します。 したがって、リードすることができないアナリストがプロジェクトの管理に従事しているという事実、そしてアナリストでさえ自分の仕事を貧弱にしています。 彼自身の上司-これはより高いリーダーの間違いです。 ピーターの行動の原則 。 残念ながら、優秀なプログラマーよりも優秀なマネージャーはさらに少ない。

歴史3. 「 甘やかされた電話」による 「継続的な統合 」

過去の履歴からテスト部門を持たない組織では、ユーザーによる戦闘テスト中にバグを検出した場合にパッチを緊急にアップロードするメカニズムが提供されていました。 ユーザーはバグを見つけ、最初のサポートラインにリクエストを送信します。 サポートの最初のラインは、それ自体で問題を解決できない場合、プロジェクトマネージャーにリクエストを送信します。プロジェクトマネージャーは、これがバグであることを確認し、バグを装って販売しようとしているユーザーの予期しない希望ではなく、プログラマにリクエストを送信します。原則として、特定のプロジェクトをサポートするために、1人の特定のプログラマが割り当てられます。プログラマーは、実行可能ファイルを所定のフォルダーに入れ、サポートの最初の行にそれについて書き込みます。サポートの最初の行は、システム管理者向けに書かれています。管理者はパッチを投稿し、サポートの最初のラインに報告します。サポートの最初の行はプログラマーに報告されます。プログラマーはユーザーに報告します。ユーザーは、バグが修正されたことを確認します。パッチをレイアウトするこの「緊急事態」は、実際にはどのように機能しますか？多くの場合、バグに関する情報は半日遅れでプログラマに届きます。このアプリケーションに割り当てられたサポートの最初のラインの人、半時間離れることができます。プログラマーがパッチが投稿された場​​合にサポートの最初の行を定期的に尋ねない場合、彼はおそらく、この日に彼がまったく投稿されたかどうかを知らないでしょう。

パッチが長期間機能しなかった場合。次に、パッチが投稿されたと報告しました。しかし、ユーザーのバグは消えませんでした。ユーザーにリモートで接続し、パッチがまだ投稿されていないことがわかりました。最初のサポートの担当者が管理者に誤った情報を提供したことが判明しました。パッチを再配置し、機能しました。そして、ユーザーが半日働いていないという事実の責任を誰に譲渡できますか？プログラマーに。実のところ、そこにはないテスト部門にはそうではありません。まあ、誰も自分を責めることはないので、プログラマーがアナリストが望んだことを正確に行ったことをプログラムの新しいバージョンを送信する前に検証できないアナリストマネージャーも、それとは何の関係もありません。また、管理者とサポートの第一線は一般に外国の管轄下にあるため、極端に管理することはできません。残っているのはプログラマーだけです。最も興味深いのは何ですかパッチの「緊急」アップロードのために、独自のプログラムが実装され、バグ修正が割り当てられたときに自動的にプログラマーに手紙を送ることができました。管理者がこのプログラムにパッチパッチを置いたときに、プログラマとユーザーでさえ、パッチのアップロードに関する通知を自動的に送信することを妨げるものは不明です。一般に、ボタンをクリックするだけでパッチを配置することをお勧めします。たとえば、ボタンをクリックしてパッチを配置するとき。たとえば、ボタンをクリックしてパッチを配置するとき。たとえば、ティムシティ。パッチをレイアウトするプロセスを変更することで問題は解決し、リスクは軽減されますが、有罪なものを見つけることはできません。

マネージャーの行動のためのいくつかの簡略化されたアルゴリズムを検討してください。

アルゴリズム1。

そのような行動の戦術の不条理と不道徳にもかかわらず、場合によっては効果的であることが判明します。リーダーが状況に影響を与えられない場合（上級管理職が資金を割り当てていない、プロセスを管理する方法が理解されていないなど）、理論的に状況に影響を与える可能性のある人々にトラブルを配置することにより、リーダーは問題を排除する可能性を高めます。ある店舗では、商品の不足はすべて、運送業者やレジ係の給与から差し押さえられました。その後、店の従業員は自発的にビデオカメラに身を投げ、ビデオを見ながら見始めました。定期的にこの店を強盗した数人の泥棒の買い物客が手に捕まった後、不足は著しく減少しました。肯定的な結果が達成されたという事実にもかかわらず、そのような行動の戦術のリスクに注目する価値があります。売り手はカメラに手を入れて個人的な時間を犠牲にするか、道路を渡って店で新しい仕事を得ることができます。この機能により、この戦術はIT部門で非常に危険になります。これはお勧めしません。

アルゴリズム2。

このアルゴリズムをお勧めします。



リスク管理のより深い理解のために、Tom DeMarcoとTimothy Listerの著書「Waltzing with the Bears」を読むことをお勧めします。



誰かが役に立つかもしれない、ここにマネージャーのための本の別の選択があります。



入力ミス、スペルミスなどに関するすべてのコメントは、個人的なメッセージを送信してください。しかし、私はそれらを修正することを約束しません。なぜなら、私が記事を書くとき、私は報酬を受け取らず（エッセイを書く経験を除いて）、何も危険にさらさないからです（私のアカウントの評価を除く）。ここでは、おそらく、動機付けと自己識別のトピックにスムーズに移行する価値があります、しかし、残念ながら、この記事はここで終わります。ところで、私がスペルミスを修正する義務を負わなかったという事実は、私が間違いを間違いなく修正しないことを意味するものではありません。



ご清聴ありがとうございました！ :)