制御レベルの数

どういうわけか、FBでは、友人の間で、組織の効果的な運営を確保するために、管理レベルがいくつあるべきかという議論がありました。 私は、約20年前にロシア連邦大統領評議会のセミナーで発表されたアーノルド（ターミネーターではなく数学）の報告を思い出しました。 報告書はかなり予想外の結論を下した。

「n> 3のモデルで記述された多段階制御は不安定です。 2段階制御は周期的な変動につながりますが、3つ以上のステップ制御で発生する変動の壊滅的な増加を引き起こしません。 真の安定性は、1 段階の管理によってのみ保証されます。管理者は、当局からの励ましよりも、事件の利益に関心があります。」

組織に何千人もの従業員がいる場合、これはどのように可能ですか？



そして、それはすべてプロジェクト管理についてです。



「路面電車の運転手が新しい方法を探し始めたら、トラブルを待ってください。」 外部条件がよく知られていて安定している場合、生産作業がよく研究され、繰り返しテストされ、実行者の機能が定義され、一定である場合、これらの条件では狭い専門化とコンベヤーが効率の基礎となります。 障害がなければ、組織は均衡状態にありながら（不安定ではあるが）任意に長く、管理の階層に耐えることができます。 古代エジプトからソビエト時代までの複数レベルの官僚制度を思い出します。



しかし、外部条件が動的に変化している場合、組織が独自の結果を得たい場合、要件が絶えず変化している新製品を開発する場合、知的生産努力、創造性、および新しい機会の探索が必要な場合、初めて生産技術を適用し、これらの条件でプロジェクト管理組織が使用されます。 そして、そのようなシステムの制御モデルについて語ったのはアーノルドでした。



「しかし、待ってください」と読者は言います。「プロジェクトアクティビティには、目標、戦略、プログラム、ポートフォリオ、プロジェクト、サブプロジェクト、ワークパッケージという独自のマルチレベル階層があります。 そして、各レベルには独自のマネージャーがいます。 さて、「...ワンステップ管理、管理者は当局からの励ましよりも事件の利益により関心がある」とはどこにあるのでしょうか？



プロジェクト管理の基礎は、作業の階層構造です。 重大な間違いはプロセス分析です：分析、設計、コーディング、テスト、文書化。



正しい構造は結果指向でなければなりません。 したがって、各作業パッケージは、独自の結果を達成することを目的としたミニプロジェクトと見なされ、個別に管理される必要があります。 そして、このマネージャーが「当局からの励ましよりも事件の利益に関心がある」ためには、4つの条件を満たすだけで十分です。



1.期待される結果が設定されます。 「何」、そして最も重要なのは「なぜ」（ただし「どのように」ではない）を行うべきである。

かつて同僚のアレクサンダー・オルロフはこう言った





2.「ゲーム」のルールが定義されています。 APIによって提供されるコーディング標準であるシステムアーキテクチャに関連する最小限の制限は、絶対に必要ではありません。 ルールと基準が増えると、労働生産性が低下することを忘れないでください。



3.割り当てられたリソースとその労働時間、ハードウェアとソフトウェアなど。



4.結果を評価するための測定可能な基準を確立しました。何が良いのか、何が悪いのか。



そしてそれだけです。 上司ではなくビジネスの利益のために頭が働く、安定した1段階の管理を取得します。



そのようなもの。