遅かれ早かれ、私たちは皆、私たちのビジネスをより良くする方法の問題を抱えていました。 私たちは計画を立てようとしましたが、ほとんどいつもそれを失望させました。 私たちは急にタスクを引き受けようとしましたが、望んでいたものが得られませんでした。 遅かれ早かれ、ある種の黄金の手段に至り、私たちのタスクは「必要に応じて」「ほぼ時間通りに」なりました。
問題は、遅かれ早かれ、気付かないうちに混合管理モデルになったことです。 混合管理モデルとは何ですか？ まず、何が混在しているかを理解する必要があります。 そして、2つのモデルが混在しています-計画的および状況的。 「状況モデルとは何か」という質問に答えるには、計画モデルの方向にそれから離れて、それに関するすべてのポイントを要約する必要があります。 計画モデルは次のとおりです。
- 解決する必要があるタスクのリストの存在。
- 彼らの決定の期限の可用性。
- 力と手段の存在。
- タスクの優先順位と優先順位、依存関係。
- 推定誤差と時間とリソースの可用性を理解する。
計画されたモデルによると、クリティカルパスを簡単に構築し、非常に現実的にそれに従うことができます。
計画されたモデルにはすべての利点がありますが、一つのことを除いて-実際の生活とあなたの周りの世界は計画に従ってではなく、状況によって、イベントによって生きています。 実際、事前に予測できなかったいくつかのイベントは、計画に割り込んで作業を中断し、より緊急で優先度の高いタスクを解決します。 多くの場合、経験の浅い管理や時間とお金の不足により、予期しない問題、タスク、およびインシデントのために、スケジュールされたアクティビティのスケジュールが半分または3倍になります。 建設現場（近隣のコテージなど）やサービス中の車の修理（必要な予備部品がない回数）を外部から観察するだけで十分です。
警察署の仕組みを知っていますか？ コールセンター、捜査官、地区警察、パトロールサービスがあるインテリアの通常の部門。 このような部門は、混合管理モデルに従って機能します。 通常は、全員が計画通りに働き、計画された管理モデルが完全に実装されます。地区警察官は機能不全のアルコール依存症を訪れ、時には調査員を助けます。 捜査官はビジネスを行い、検察官と裁判所に照会します。 PPSnikiは、電話とパトロール業務のために彼らに委ねられたエリアを回ります。 コールセンターはジョークを毒し、電話に応答します。
しかし、ある瞬間、「状況」に関する情報がコールセンターに届きます。 状況はすぐに対応する必要があり、PPSの服装がその場所に残されます。 衣装は状況を評価し、非常線、調査員、および合併症を引き起こします。 事件の現場で、調査員が働き始め、調査が組織され、状況が明らかにされます。 境内の目撃者のインタビュー。
私たちの多くはそのような状況を見たことはありませんが、私たちのすべては、コレクターへの襲撃、人質取り、および即時の解決を必要とする他の状況を聞いたことがあります。
状況モデルは、計画されたモデルよりもはるかに単純です。
- 主な目標：状況を解決し、計画されたモデルに戻ること
- すべての可能な（そして合理的な）力と手段は、最大の決定速度のために使用されます。
- 計画されたものはスローされ、計画されたすべてのアクティビティはバックグラウンドで取り出されます。
このモデルは、日常の問題を解決するようには設計されていませんが、そのために問題を迅速に解決します。 それから、状況はほとんど計画を混乱させませんでしたが、「万が一のために予約」から少しの時間しかかかりません。
マネージャーが状況モデルで作業することを学んだとき、「類似性」に従って状況を分離し始めました。 スキームと指示は、標準的な状況を解決するために開発されました。 彼らは非標準的な状況を解決するために特別な人々を訓練しました。 後に、指導者は計画された仕事と状況に従事する人々を分割しました-そのため、権力は立法と行政の2つの支部に分割されました。 内部では、各支部も2つに分かれており、そのような支部は最下部の警察署まで行きました。 学部および学科以外の人がいる場合-状況に応じて常に働き、標準的な問題を解決することができます。 調査員がいる場合、90％の時間は計画どおりに働いています。 SOBRは各部門には必要ありませんが、標準外の新しい状況での作業方法を知っているこれらの人々は常にそこにいます。
私たちはITを構築しており、計画されているモデル（スクラム、かんばん、および「これを行う必要があります...」という原則に基づいて動作する他のモデル）を本当に気に入っています。 私たちは皆、生きているシステムのバグが好きではありません。経営陣からの緊急のマーケティングタスクがいつ来るかは好きではありません。 これは、これらの緊急の、本質的に状況が計画された測定プロセスに食い込み、それを混乱させ、部門と私たちの個人のパフォーマンスを低下させるためです。 これは、チームがリークを迅速に封じ込めるIT-SOBRを持っていないため、人々を2つのグループ（計画的および状況的）に分割しなかったためです。
私のプロジェクトでは、すべてを3つのカテゴリに分けました。
- 計画中
- 状況的
- 「私たち以外の誰も」
私は最後のカテゴリーの問題を自分で解決します-アーキテクチャ、コード、サーバーを知っていて、酔っ払って夜でも流れを止めることができます。
状況的なタスクは、フロントエンドとシステム管理者という2人のチームによって解決されます。 この組み合わせには理由があります。突然の多くのタスク-マーケティング、または「何かが壊れた」。 別のバックエンド開発者を雇わないために、NodeJsでマーケティングバックエンド全体を記述し、フロントエンド開発者によって簡単に管理されています（良い開発者がいます）。 マーケティングリリースは、アプリケーションの計画されたリリースとは別であり、いつでも実行できます。
計画されたタスクは、開発者チームによってかんばんによって解決されます。
最終的には、結果と満足した人々がいます（誰もが自分のモードと仕事のスタイルが好きです）。
PSこれは管理モデルについての入門記事でした。一連の記事をこれに捧げ、それぞれについて新しく有用なものを詳細に伝えたいと思います。
PPSそして、ここでは、計画または状況に応じて時間を管理するように設計されたノートスペースサービスを開発しています。