この記事では、私の意見では、機能の重要なギャップについて説明し、それを実装するための可能な方法を提案します。
プロジェクト計画を立てるのに役立つ明確なツールはありません。
どのシステムでも、タスクの実行を計画し、実行者、日付などを指定できます。 原則として、これはシステムにタスクを入力できることを意味します。 何らかの理由でのみ、そのようなシステムのユーザーは千里眼であり、どのタスクを実装する予定かを事前に知っていると想定されます。
あいまいなアイデアからリスト、さらには100,500項目のタスクツリーに移行する方法がわかりやすい提案はありません。 このアプローチのいくつかの要素は、 アプリケーションライフサイクル管理クラスのシステムで観察されますが、そのようなすべてのシステムでは、スケジューリングの側面が大幅に低下します。
私は、従業員の雇用とタスク間の依存関係を考慮して、タイムラインに重ねて、単一の情報スペースで一連の前例、コンポーネント、要件、タスク、およびパフォーマーを管理できるツールを夢見ています。 単純なリストやタスクの階層でさえも、全体像を把握するには十分ではありません。 実際、タスクの構造化はさまざまな観点から見ることができます。 タスクの重要性と自明性は、それらを見る角度によって異なります。 たとえば、使用シナリオの観点から見ると、スクリプトのテストを忘れることはほとんどありません。また、コンポーネントの観点からは、コンポーネントの相互作用のためのプロトコルを設計するタスクが自然に現れます。 そして今、すべての観点からプロジェクトを見て、何も忘れていないことを確認した後、かなりまともな計画を得ました。
変化する計画に取り組むのは不便
計画が定期的に変更されると、変更は通常、過去の値を上書きします。 MS Projectでは、計画のバージョン（いわゆる基本計画）を保存し、それを現在の計画と比較できます。 これは、タスクの構造があまり変わらない場合に少し役立ちます。 実際には、1つのタスクから複数のタスクへの分解が頻繁に発生し、タスク間の関係の追加と削除、用語の再評価が行われます。 多くの場合、少し「再生」する必要があります。 計画に変更を加えて、これがプロジェクトの締め切りまたはコストにどのように影響するかを確認します。アーティストをプロジェクトに追加し、エグゼキュータ間でタスクを再配布し、タスクを追加または削除します。 このような変更が多数ある場合、基本計画との単純な比較だけでは、変更の本質を理解するには不十分です。
計画変更ジャーナルが本当に恋しいです。それは何が、いつ、どのように変更されたかを示しています。 また、この変更またはその変更が行われた理由を説明するコメントを作成したいと思います。 特定のタスクの評価が時間の経過とともにどのように変化したかを確認して、タスクの原因不明の新しい出現率を評価すると便利な場合があります。 後で計画に戻って相互に比較できるように、計画のいくつかの異なる状態を修正することが可能であるはずです。 計画はプロジェクトマネージャーのためのツールです。 私たちは変化する世界に住んでいるので、現実のモデルである計画を定期的に変更できることが重要です。 各時点で、プロジェクト計画は2つの部分で構成されています。
- 何だった-タスクのタイミング、人件費などの実際のデータ
- 何になったのか-現時点でのイベントのさらなる発展が見られます。
時間が経つにつれて、これらの要件を満たすために計画を変更する必要があります。 同時に、以前の計画が何であったかを見る機会があるはずです。
すべての人が異なるという事実を考慮していません
ほとんどすべてのシステムで、パフォーマーは簡単に交換可能なものとして認識されています。 現実には、人々は生産性、専門性、さらに多くの要因の点で非常に異なっています。 このような違いのモデリングは、コンピューターゲームで積極的に使用されており、プロジェクト管理システムでは、人々の違いは単に無視されます。
従業員の専門性と生産性に関する基本情報でさえも、計画の準備に大いに役立つ可能性があります。
問題領域の診断にはほとんど注意が払われていない
プロジェクト管理システムはRPに大量の情報をダンプし、RPを自分でいじって、数字とグラフの深fromから必要な情報を抽出します。 期待できる最大値は、プロジェクト全体のパフォーマンスや燃焼チャートなどの要約指標です。 しかし、悪魔が細部にあることは知られています。 プロジェクトが*現在*時間通りに完了しているのに、実行速度の*ダイナミクス*が負であることを確認することの用途は何ですか？ 実際、これは、近い将来、プロジェクトが予定より遅れ始めることを意味し、この問題を防ぐための行動は、すべてが既に起こったときではなく、今実行することができます。
優れたプロジェクト管理システムは、プロジェクト全体の特性と個々の部分の両方を特徴付けるいくつかの重要な指標を分析する必要があると確信しています（たとえば、これは個々の従業員のパフォーマンス、個々のコンポーネントの実装速度など）。 さらに、分析は静的であるだけでなく、変化のダイナミクスも考慮に入れる必要があります（計画の変更については上記を参照）。
これにより、マネージャーは事後だけでなく、問題が発生する前にプロジェクトの問題に対応できるようになり、影響の度合いが大幅に軽減されます。
システムはクラウドに行く
現代のファッショントレンドに従ったプロジェクト管理システムはすべてクラウドに移行します。 雲はいいです、そうです。 しかし、従来のソリューションへの追加としてのみ。 ネットワークにアクセスしなくても、プロジェクト計画を取り、余暇にそれを利用できることが非常に重要です。 変更を行った後、クラウドで計画を公開でき、誰でも利用できるようになる場合に非常に便利です。 しかし、データ*がクラウドでのみ使用可能*の場合は非常に不便です。つまり、インターネットにアクセスできない場合、データにアクセスできません。
データのローカルコピーの消失は重大な理由によるものであることを理解しています。 複数の人が同時に計画の同じ部分に変更を加えた場合、それらをクラウドで結合すると問題が発生する可能性があります。 ただし、問題が複雑であるという事実は、それが解決できないという意味ではありません。
クラウドベースのプロジェクト管理システムでは、たとえばEvernoteのように、プロジェクトデータをローカルで操作し、その後同期することができるように思えます。
おわりに
誰かが私がプロジェクトマネージャーのためにすべてを行うシステムを望んでいるという印象を受けるかもしれません。そうすれば、彼の立場は単純に廃止されます。 これは完全に間違っています。 プロジェクトマネージャーの活動に伴う日常的な操作を自動化し、不必要な詳細から脳を解放し、より重要なことに集中できるシステムが必要です。 無限のタスクリストとパフォーマンステーブルにより、リーダーは主要なものを強調することができず、非常に非生産的な時間を費やすことになります。 プロジェクト管理自動化システムは、エンティティを使用した基本操作の実装を単純化するだけでなく、マネージャが同時に操作するエンティティの数を減らす必要があります。 これは、基本エンティティを高レベルの抽象エンティティに結合することで実行する必要があります。
このような定性的な飛躍は、プロジェクトを表すための理論的なモデルが存在する場合にのみ可能であるようです。これには、異なるレベルの抽象化とすべての必要な指標が含まれます。 このモデルでは、1つまたは別の管理方法論を明示的に使用する必要はありません。 システムは、このモデル内のプロジェクトでアクションを自動化します。 間違いなく、プロジェクトマネージャーはモデルを明確に理解する必要があります。さもないと、プロジェクトマネージャーはシステムを効果的に使用できず、逆に無限に複雑で理解しにくいように見えます。
また、プロジェクト管理システムで何が恋しいですか？
どの機能を追加しますか？