この場合、プロジェクト管理でよく知られているガントダイアグラムはうまく機能しません。 典型的な例は、CISの拡張機能の開発です。
以下では、最小限の管理コストで多数の並列タスクを制御するためにプロジェクトで使用した方法を説明します。
1.作業計画
約5年前に、プロジェクトマネージャーへのスケジューリングに関する推奨事項という記事を書きました 。 原則は時の経過とともにテストされてきましたが、私はまだそれらを順守しています。
ただし、一部の種類のタスクでは、一貫した詳細なスケジュールを作成することはほとんど不可能です。 多数のタスクが並行して行われ、それぞれの期間と複雑さを推定できるのは、大きなエラーを伴う場合のみです。
古典的な例は開発です。 各開発は、少なくとも設計、コーディング、テストなどのいくつかの段階を経ます。 原則として、タスクが前のステージに移動する場合、いくつかの反復が必要です。 開発はコーディングからテストに移行し、開発者は別のタスクを引き受けました。 開発はコーディングに戻り、開発者は前のタスクを完了するか、エラーの修正を早急に行います。 状況と優先度に応じて、タスクプールでのチーム作業の順序が異なる場合があります。 プロセスは無秩序で制御不能に見えます。 プロジェクトマネージャーが慣れている、すべてを制御することに慣れている、きちんとしたガントチャートの形式でこれを提示することは、可能な限り非常に面倒で、あまり有用ではありません。
になる方法 作業の進行を制御する方法は？ 理解する方法-間に合うかどうか ボトルネックはどこですか。 十分なリソースがありますか？ 誰がうまく機能し、誰がそうではないのか 最後に、経営陣に報告する方法は？
以下は、私にとって最適であると思われるオプションの1つであり、ある条件では-唯一のオプションです。
2.作業管理システムの使用
各参加者がタスクを受信し、他の参加者に転送して完了をマークできるタスク管理システムを使用しないと、通常のプロセスを構築することは不可能です。
私の実践では、さまざまなツールを使用し、このトピックに関するレビュー記事を公開しました（Habr： Project manager toolsの記事を参照）。 ここでは、追加機能のプラグインを最小限に抑えながら、標準機能を使用して開発管理用にセットアップしたJIRAの使用経験について詳しく説明します。
JIRAは、アトラシアンのタスク管理（リクエスト）管理システムです。 ライセンスのコストは、ユーザー数に応じて、10ユーザーあたり10ドルから始まります。 自分でインストールするか、クラウドでアプリケーションを使用するかを選択できます。 すべてのオプションの価格については、 こちらをご覧ください 。
JIRAは、やや古風なインターフェイス（これは非常に立派な時代のシステムであり、すでに非常に長い開発方法を経ています）、信頼性、可能なすべてを構成するための柔軟なシステム（ワークフロー、画面の種類、アクセス、通知システム）、有料および無料の膨大な数のプラグイン、そして、深い発展の可能性。
改訂の必要はありませんでした。ワークフローを設定し、絶えず改善しました（作業プロセスはタスクのステータスとそれらの間の遷移の設定と順序です）。また、作業を制御する参加者とダッシュボードへのアクセスです。
アプリケーションを使用する機能と可能性をなんらかの形で詳細に説明するタスクを自分で設定するわけではありませんが、さらなるプレゼンテーションのために、いくつかのポイントを説明することが重要です。
3.タスク管理ワークフロー
このワークフローは、この例では設計、コーディングテストなど、タスクのライフサイクルを反映しています。 実際、プロセスははるかに複雑です。 プロジェクトの組織の特徴、参加者の募集、管理要件に応じて、ステージの数は非常に大きく異なります。
たとえば、プロジェクトの1つには、開発タスクを追跡するための次のワークフローがありました。
調整、作業の分配、システムのすべてのインスタンスでのテストの多くの段階...しかし、これにより、システムのすべてのステップを確認し、責任を追跡し、タスクが誰とどの段階にあるかを正確に知ることができました。
4.タスクの複雑さ
タスクの複雑さは、設計と構造の2つのコンポーネントに分けられました。 設計とは、ドキュメントを準備し、開発をテストするアナリストの仕事です。 構築は、アナリストに渡す前に、技術設計、コーディング、独自のテストを開発するための開発者の作業です。
詳細を掘り下げることなく、タスクの複雑さを事前に評価することは、特に数千のタスクがある場合、この場合のように、非常に困難です。 しかし、総作業量、必要なリソース量を理解し、タイミングを決定するために評価する必要があります。
おおよその評価のために、計算機が使用されます。計算機は、タスクの種類と複雑さに応じて、計画された複雑さに起因します。
タスクの複雑さは、オブジェクトとその作業量に応じて決まります。 たとえば、Oracle eBSでフォームを開発するための複雑さの基準は次のとおりです。
- 非常にシンプル-8列以下の単一ブロックフォーム。 特別な機能ロジックは必要ありません。
- シンプル-20列以下の1つのマルチブロック（2〜3ブロック）形式。 シンプルな機能ロジック（シンプルな編集、クロス編集（クロス編集）、シンプルな計算、合計および小計）が必要です。
- など
タスクのタイプは、タスクの内容、テクノロジー、アプリケーション、またはその一部の詳細を反映しています。
例：
-新規または変更可能なフォーム。
-新規または改訂されたレポート。
-新規または変更可能なデータベースプログラム。
-SQL *ローダースクリプト。
-シグナル（アラート）。
-パーソナライズ。
-など
計算機は、開発の複雑さとタイプに基づいて、計画された複雑さを計算します。
また、推定誤差は統計的にはかなりの数になる可能性がありますが、これらの誤差は平準化され、作業計画の目的で労働量の一般的な考え方を使用できます。
5.タスクパフォーマンスの監視
では、タスクのステータスとその複雑さを把握して、作業の進捗をどのように評価できますか？
従来のオプションでは、特定の期間に必要なタスクの数を計画し、定期的にタスクの完了を追跡します。 問題は、一部のタスクに時間がかかり、複数の計画期間に及ぶことです。 また、多くのタスクが完了する期間もあれば、少なすぎるタスクもあります。 これは、特にプロジェクトの開始時と終了時の状況の理解を提供しません。
タスクの個々の段階の完了を計画することができます。 上記の例では、それぞれが計画不可能な21のステージを使用しました。 主なものを選択します-設計の完了、コーディングの完了、タスク全体の完了。 各タスクの日付を計画し、偏差を制御します。 実現可能だと思われます。 ただし、多数のタスクを同時に処理している間は、数百の逸脱を見つけて正しい結論を導き出すことはかなり困難です。 偏差ごとに、説明、客観的な理由があります。 何かが遅く、何かもっと速く行われます。
プロジェクトの1つで、日付管理方法を使用しようとしました。 予定日は出演者によって設定されました。 事実は、対応するステータスからの移行時にシステムに自動的に記録されました。
この図は、機能設計（FD）の準備ができた日付による偏差のヒストグラムを示しています。 正の値はリードを示し、負の値はチャートの遅れを示します。 最大数のPDが3.8日から1.7日の遅れでエグゼキュータによって引き渡されることがわかります。 同時に、極端な値は、スケジュールの43日遅れから67日遅れです。
この状況では、ほとんどの場合、パフォーマーが設定した期限に違反していることがわかります。 この体系的なエラーは、それについて熟考する価値があります。 ただし、チームのやる気があり、全員が誠意を持って仕事をしている場合、これは人々が実際の用語を示すことができないことを意味するだけであり、出演者は仕事中に生じる複雑な要因を考慮しません。
計画に余分な時間が費やされますが、実際には誰も締め切りを守る責任がありません。 違反に対する制裁を導入すると、日付に大きなマージンが設定され、パフォーマンスの状況がさらに悪化します。
何かをコントロールしたい場合、コントロールの結果をどう処理するか、収集したデータに基づいてどのような決定を下すことができるかを考えてください。
6.アーンドボリューム法
高度な不確実性を伴う多数のタスクが失敗する運命にあるため、詳細レベルで一元管理する試み。
これらのタスクをグループに分割し、詳細な計画をグループに委任できます。 数人、数十のタスクをチェーンに配置し、変更に迅速に対応し、優先順位の変更に関する決定を下すことができます。 しかし、プロジェクトレベルでは、他の方法が必要です。
使用されているボリュームの方法が助けになります。 理論に入ることなく、開発の計画事実管理のためにこの方法がどのように実装されるかを説明します。
タスクのライフサイクルを既に決定し、各タスクの計画された複雑さを決定しています。 次に、各段階のタスクの完了率を割り当てます。 私たちの場合、 労働投入量が設計とコーディングに分割されたため、それぞれの値に割合が割り当てられます。
関心の割り当ては専門家によって行われ、タスクがどれだけ完了したと考えられるか、この段階でどれだけ多くの労働力が残っているかを評価します。
このようなテーブルがコンパイルされた後、各タスクについて、計画からすでに何日がマスターされているかを判断し、各タスクの進捗を測定することができます。
たとえば、タスクには、設計に10時間、開発に20時間の予定労働投入量があります。 そして、テスト段階では、アナリストの作業に関しては80％（テストの完了に必要な作業の20％）、開発者の作業に関しては50％完了していると考えています。 設計が8時間、開発に10時間かかったことを認める準備ができています。 合計で、30人日のうち18がすでに完了しています。
同時に、実際には他の時間が費やされる可能性があることを考慮していません。 述べられた目的のためにそれは重要ではありません。
7.プロジェクト報告
各タスクについて計画された複雑さとマスターボリュームを備えたテーブルがあることで、物事がどのように進んでいるかを簡単に理解できます。
より詳細なレベルで分析し、必要なすべてのセクションでサマリーテーブルを作成できるように、タスクをプロジェクトの指示、コンポーネント、およびマイルストーンに分割することができます。
プロジェクトの全体像は、リーダーシップレベルでのプレゼンテーションに便利になります。
JIRAアップロードの概要表
事実上のプロジェクトの管理
この方法は必ずしも理解できるとは限りません。 神話上のマンデーは、開発の断片ほど明確ではありません。 そして、彼はグループおよび個々のパフォーマーレベルでの詳細な計画をキャンセルしません。 ただし、これは現在の状況を評価し、作業の完了を予測する最も客観的な方法です。