[ケース]時間通りの反復かチームの半分か？

友だち、 最初のケースが15 分間注目されたので、続けます。



4年前、私たちはモスクワで当時の一連のセミナーから3回目のセミナーを開催しました。 プログラムを多様化するために、参加者のケースの解析に数時間を費やすことにしました。 約40人の参加者がいたため、ここですべてのケースを理解できないことは明らかです。 そのため、特別な民主主義が導入されました：事件の収集、投票、 slavapankratovに代表される権威ある委員会による結果の集計。



その結果、次の状況が最も興味深いケースのトップになりました。 ケースは本物であり、生徒の実際の経験から取ったものです。

ケース「チームの半分を解任」

同僚スラバパンクラトフからの免責事項。 ケースの設計に使用される実際の状況はトレーナーによって処理されます（非パーソナライズされ、正式な入門ノートで大きくなり、解決策がなければ不可能だった事実によって補強されます）、「プラスチックの味」を獲得する可能性があることに注意してください：人工および発明。 問題のある状況の分析自体は、常に一定の割合の現実のゆがみを伴います。また、現実世界の期間のモデルとしてのケースは、人為的で、とてつもないと思われるかもしれません。 この状況をトレーニングシミュレーターとして、また状況自体をスパーリングパートナーと見なすことをお勧めします。これは、パンチングバッグとは異なり、反撃することができますが、同時に訓練生をノックアウトすることは彼の仕事ではありません。



なぜこの紹介をしましたか。



トレーナーは、単に講義をしたり、記憶されたセミナーを改めて語るだけでなく、トレーニングを行っている場合、生徒の抵抗に直面します。 学生の実際の経験がコーチまたはグループによる批判的な評価の状況に陥るとすぐに、人は彼を擁護する傾向があります。 過去に何かを修正する方法はありませんが、あなたがずっと前に間違っていたことを認めることは、それがずっと前であっても、もはや重要ではないように思われますが、私たちは好きではありません。 言い換えれば、学習状況において、学生が自分自身を認識し、そのような状況で以前に最も論理的または効果的な方法で行動できなかったと判断した場合、防御が発生します。実際の生活についてのあなたのケースで？!!”または（トレーナーのお気に入り） "あなたはそれをモックするために特別に私に湾曲したケースを滑らせた なぜあなたのお気に入りは？ これは、生徒の頭の中での内部的な議論である、誘発された反射の良いマーカーです。 そして、反射は学習の最初のステップです。



したがって、このケースの決定を推論する過程で、同様の防御的反応または有罪なものを見回したいだけの場合（ケース自体、他の参加者のコメント、またはこの分析の著者の言葉で）、あなたはそれを維持するべきではありません：反射は消えました。 おそらく、経験の初期には正しく動作しないかもしれないという考えを促しました。 おめでとうございます。このケースに参加し、学習プロセスが開始されました。



行こう！

状況

プロジェクトチームがあります：プログラマ、テスター、アナリスト、プロジェクトマネージャーです。この場合はプレイすることをお勧めします。 つまり、状況に対する持続可能なソリューションのために、プロジェクトマネージャーの行動のモデルを設計する必要があります。



プロジェクトチームは、毎月の反復で顧客に提供される大規模なITシステムを開発しています。 つまり、各月の開始前に、チームは顧客に提供できる作業量を選択して評価します。 作業には、反復の要件の分析、システムコードの開発または改訂、システムの新しいバージョンのテスト、顧客のスタンドでの展開と構成が含まれます。 チームは、毎月1日か2日をかけて、1暦月以内に開発およびテストできる要件を分析および評価します。 顧客との作業は約1年間続いており、現時点では祝日と休暇シーズンを考慮して、製品の10バージョンが顧客に提供されています。



顧客はシステムの中間バージョンを受け入れて次のバージョンを待つだけでなく、提供されたソフトウェアを使用してビジネスプロセスの大部分を自動化します。 顧客のインフラストラクチャでは、システムに実際のデータが含まれています。 システムの新しいバージョンの配信、展開、または運用中にエラーまたは遅延が発生した場合、顧客の会社の大部分の作業は約300〜400ユーザーの労働時間を失います。



反復の量を評価するための十分に確立された手順にもかかわらず、プロジェクトチームは10回のうち4回の反復で製品の新しいバージョンの配信を中断しました（1〜4-5営業日）。 毎回失敗の理由は異なります。顧客のインフラストラクチャでのソフトウェアの展開と更新の問題。 修正と再配信につながる重大なエラー。 実装されている要件の構成の変更、および変更の実装条件の過小評価。 「問題のある」配送後、振り返ってシステム上の問題を特定することはできませんでした。 顧客のビジネスの期限を守れないことの結果も毎回異なります。問題は、配達日が遅れているという事実だけでなく、顧客の単純な分割にあります。



納期の最後の2回の中断は、2か月連続で1つずつ発生しました。 新しいバージョンを3日間起動できなかったため、顧客のユニットの400人の従業員全員が3日間ダウンタイムになりました。 最後通告の形で怒っている顧客は、会社の経営者にプロジェクトの秩序を回復するための対策を講じることを要求しました。



プロジェクトチームが勤務する会社のテクニカルディレクターは、ケースの主人公を呼び出し、次の管理上の決定を彼に通知しました。



プロジェクトが現在開始されている次の反復が期限によって中断された場合、会社の他の15のプロジェクトチーム（合計で1,000人以上の従業員がいる）の訓練と前例を設定するために、従業員の半数がチームから解雇されます。プロジェクトは、人々の構成と将来の配達のタイミングに従って再フォーマットされます。



決定は最終的なものとして表明されます。 テクニカルディレクターは、おそらく顧客の代表者との交渉で圧力を受けていたため、納期に間に合うようにこの決定を実施することを約束し、キャンセルすることはできません。



そのような管理上の決定が上司から伝えられたプロジェクトチームマネージャーの代わりになり、いくつかの質問に答えてください。

質問：

1.経営陣の決定について話すか、チームに伝えないか？



2.1スピーキング、チームまたはその個々のメンバーに何を正確に何の言葉で言いますか？



2.2チームに伝えない場合、今後の行動はどうなりますか？ 働きますか？ ではないでしょうか？ プロジェクトをどのようにさらに進めますか？ あなたの行動モデルの結果は何ですか？

追加データ

チームはスムーズに動作します。 チームには明らかな部外者やスターはいません。 以前の問題は体系的ではありませんでした。 先に、期限を守らないとプロジェクトの将来に影響を与える可能性があることを既にチームに発表しました。会社の業務では、従業員の不況とマネージャーとエンジニアの解雇がありました。 しかし、内訳は繰り返されました。 説明は常にあります。 状況は変わらず、顧客は彼が使用するサービスを所有する会社に圧力をかけることにしました。



休憩してください。 必要な限り冷静に考えてください。 あなたの決定を書き留め、あなたの決定を明確に記録してください：繰り返しの用語が失敗した場合に解雇についてチームに話すか、話さないか？ 結果についてチームに「ヒント」を与えることに決めた場合は、処方を書き留めて、チームがそれをどのように認識できるかを考えてください。 あなたはすでにこれらのコメントを表明しています。 今回はあなたの言葉の後に人々は異なる働きをしますか？



[ケースに関する独立した作業の一時停止-コメントでの決定を公開することは必須ではありませんが、ケースを完了し、すでに既に表示している場合は、最終的にこれを行うことができます。



ソリューションを提供する前に、ソリューションの安定性に影響するすべての要因を考慮に入れることができないトレーニングモデルのフレームワークにいることを思い出してください。 実際には、ソリューションははるかに単純であるか、まったく実行不可能であることが判明する場合があります。



通常、「真空中の球状のマネージャー」は、3人のマスターの使用人です。

1. ビジネス-顧客、会社、経営者の利益
2. チームの興味
3. 自身の権限（非公式および公式）および評判

これらはすべて密接に相互接続されています。 決定がビジネスにとってはうまくいくが、チームが死んで、それを実現する場合、マネージャーの評判はどうなりますか？ ビジネスの観点では、すべてがうまくいく可能性がありますが、チームの観点では...そして、私たちの市場は非常に小さく、5年間の仕事の後、すべての企業に友人がいます。



決定がチームにとっては良いが、ビジネスの利益が考慮されない場合、マネージャーの評判はどうなりますか？

実生活の例。 少し前に、私たちは年次プログラムの参加者と話をしました。参加者は、本当の見込み客の中で、彼のチームとともに別の会社に移ることを考えました。 状況に関係なく、これは非常に不安定なステップです。 他の会社の所有者はチームを獲得するためにこれを行うことができますが、彼らは会社からチームを撤回するマネージャーと引き続き働きたいですか？ 大きな問題は...

ケースに戻りましょう。 ソリューションを設計するとき、ソリューションの安定性に影響を与え、状況の制御を失う可能性のある最も明らかな要因を考慮に入れようとします。 つまり、不安定なソリューションであり、チームマネージャーが状況に影響を与えることができず、コントロールを失い、マネージャーが許可したくないフェーズに移行するソリューションです。



簡単に言うと、運転手は、曲がる前に車を運転したことがあり、カーブが氷で覆われていることを確認し、車を曲がり角から抜け出すために何をすべきかを決定します。 不安定な解決策は、マシンを溝に導くことです。 ドライバーが制御されたスキッドに車を入れて、コーナーから車を美しく取り出した場合、ソリューションは機能していると見なされますが、限られたスペースに適用できます-ドライバーはプロであり、同様の状況で行動する準備ができており、繰り返し行いました。 決定の変形としての「ラッキー」は、事故と見なされます。



ケースに関して言えば、顧客に飛ぶという決定と、脅迫または脅迫によって決定をキャンセルしてテクニカルディレクターに影響を与えるように説得することは、リスクのあるものとして受け入れられます。 「そして、私たちは彼と素晴らしい関係を築いており、一緒に大騒ぎしています」-トレーニングシミュレーターの条件ではなく、ケースの条件を変更して、現実に解決する修正。



同時に、私たちは、解決策の選択肢や仮定によって、ケースの現実を誤って変更する可能性があります。 あなたと私たちの両方のルール。 私たちとあなたの両方は、決定がケースの初期条件に変更を加えると言う権利を持っています。



準備はいい？



私たちの意見では、トレーニングやオンラインプログラムの学生から最も頻繁に聞こえる非常に不安定なソリューションを提供します。 これらの答えを分析すると同時に、「持続不可能なソリューション」と呼ぶものの例を示します。



決定木の最初の分岐点を見てみましょう。

オプション番号1。 チームは結果について知らされていません。

議論は異なります：パニックにならないために、誰も自分で落ちないように（差し迫った脅威についてすぐにわかります）、チームに分裂がないようにします（誰が解雇されますか？）、誰も仕事をして代わりに別の仕事を探すなどしないようにします



システム理論の観点から、マネージャーは「私たちは話せない」という決定のリスクを負い、チームに情報と希望（他の言葉は見つからない）を残し、「すべてが何らかの形で解決する」と期待します。



この場合のソリューションを設計するときに、ほとんどの場合考慮されないのは何ですか？



多くの場合、解雇の脅威に関する情報がイテレーションの途中でチームに知られるようになるとは考えられていません。 同時に、実際に、私たちがまだ検討中のモデルである現実の世界では、情報は公式のものに加えて、最も予想外の方法で会社を回ります：「あなたは誰でも手に入れるでしょう...しかし彼らはすぐにあなたをカットします、あなたはあなた自身の仕事を探します」（オプションとして、人々は以前に一緒に働いたり勉強したりしました）、「あなたはすぐに削減されると聞きました。おそらく私たちのプロジェクトに来ますか？ 「同じ会社の管理者間でリソースをめぐる内部競争のケース」という欠員が発生しました。プロジェクトAのこれらは、そのような遅れで完全に死にました。 彼らがもう一度それを浸そうとしたら半分を解雇します！」



私たちは春雨の皿である会社で働いています。そこでは、人員配置に関係なく人と人とのつながりが存在し、口頭でのコミュニケーション（別名ゴシップ）は実際には管理できません）。



マネージャーが解雇の可能性についてチームに伝えず、情報がチームに漏れた場合、マネージャーは何をしますか？ 知らなかったと言う？ パニックをまかないために彼が隠れたと言う？ 人々は不確実性の状態で生きることはできません。 そして、マネージャーの認識不足または（さらに悪いことに）チームからの一般的な運命に関する情報を故意に隠したという認識は、チームマネージャーの信頼を破る可能性が非常に高いです。 そのような状況でマネージャーがプロジェクトを完了し、さらに作業することは非常に困難です。



これはケースの条件の変更ではありません。私たちは間違いなく見つけると言っているのではありません。 「チームに伝えない」という決定の安定性をテストします。 持続可能性は、「もしどうすればいいのか」という質問に答えることができるかどうかによって決まり、同様のリスクが発生した場合でもソリューションの実装を継続できます。

オプション番号2。 チームに次のように伝えます。「できなければ、半分は分散されます。」

このオプションのリスクは何ですか？ 「インターン」シリーズでは、ビコフ博士が4人のインターンに次のように語ったときに素晴らしいシリーズがありました。 私はまだ誰を決めていません。 ええ、ここ！ 私はそれを袋に入れます、それはすべてのほとんどを傷つけるでしょう！」



次に何が起こりますか？ さらに、人々は必ず、罰する右手が触れない人々のグループに参加しようとします。 動作しないゲームは動作するようになります：セットアップ、他の同僚と情報を共有しないという意識的な決定など。



そのような条件下で、反復は時間通りに完了しますか？ ほとんどない。 人々はそれについて考えていません。 時間通りに何かを渡す方法。 しかし、敗者の半分になっていないことについて。 エネルギーはそこに向けられていません。

オプション番号3。 彼はそこにいますか？

待って、あなたが言う。 話せません あなたも話せません どうして？ ソリューションはどこにありますか？..



40人のマネージャーとの1時間の議論の結果、次のオプションに到達しました。



ステップ番号1。 チームとの総会で、状況を説明します。 そして、反復に合格しなかった場合にそれを通知します。 その後、全員が解雇されます。 そして私。 そもそもマネージャーとして。



コメント：「チームの半分」ではなく、すべて。 チームで「ゲーム」を生まないため。 チームの半分が解雇されるようだと誰かが聞いた場合、マネージャーは常に反対することができます。私のデータによると、少なくとも私は間違いなく去ります。



同時に、解雇の脅威はさまざまな方法でさまざまな人々に影響を与える可能性があります。 誰かがすぐに仕事を探し始めることができるので、反復の途中で人が去るリスクが高まります。 したがって、次のものが必要です。



ステップ番号2。 総会ですぐに、文字通り次のように言ってください。「この情報は異なって認識されることを理解しています。 あなたがイテレーションの終了前に自分で去ることを決めた場合-次の2-3日でこれについて私に通知する大きな要求。 私たちの会議の後、これについてあなたがどう思うかを理解するために、私はあなたのそれぞれと一対一で会いたいと思います。」



疑いのある人に自信を植え付けるために必要なステップ番号3 。 総会の終わりに、次のように言います。「友人、締め切りに間に合わないリスクを最小限に抑えるために、5日前に目標を立てることをお勧めします。 念のため。 さらに、私たちは毎日集まって、私たちが間に合っているかどうかにかかわらず、私たちがどのように進んでいるかの全体像を見るでしょう。



ステップ番号4。 チームメンバーごとに1対1で会いましょう。 そして、誰かが去ろうとしている場合は、数日後にそれを全員に報告し、もう一度集まり、離れずに対処する方法を決定します。



チームがリリースの提供に成功した場合、そうでない場合、人生が表示されます。 しかし、3つのコンポーネントの観点から：

• 事業内容
• チーム
• 権威と信頼

このソリューションは、すべてのオプションの中で最も持続可能です。 あなたは言うことができます：待って、それで、マネージャーは、あなたがうそをつくことができる必要がありますか？ 永遠の嘘？ たぶん。 少なくともマネージャーは、プロジェクトが予定通りに納品されなかった場合に何が起こるかを正確に知りません。 私見では、色を濃くして安全にプレイする方が良い場合があります。特に、半分が解雇されるという明確な確実性がなかったと言う機会が常にあるためです。



それでは、肩が2番目のケースを離れました。 肯定的かつ建設的な意見をお聞かせください。



また、クローズドケースクラブ「System People」の立ち上げと並行して、困難な状況をHabréで公開し続けます。