プロジェクト構造の3.5レベル

最近、マネージャーとチームがプロジェクトの管理と管理に必要なツールを説明する簡単なモデルを自分で発見しました。



すべてのプロジェクトは、情報フローとチームの構築と形式化の必要性に応じて、3つのレベルに分割できます。 なぜこれがモデルの基礎なのですか? 私の意見では、プロジェクト構造は、「管理スタイル」やその他の非公式の人間の問題に最初に従うものだからです。









レベル0:制御されたカオス


ゼロレベルのプロジェクト全体は、人々の個人的な資質にかかっています。 最も重要なことは、コミュニケーションの流れ、人々の間のつながりの数であり、責任と組織の構造の描写ではありません。 チームが1つのオフィス、チャット、またはメール会議(分散チームの場合)の境界を越えない場合、理想的なツールはホワイトボードです。 時間と空間の両方で配信されます。これは現在最も頻繁に行われています。



混oticとしたレベルのプロジェクト管理を実装する最も有名なツールは、もちろんGoogleグループです :)。



カオスはどのプロジェクトにも存在するはずなので、私は「カオス」を別のレベルの構造にとらえませんでした。 したがって、プロジェクトは活発でモバイルのままです。 人間のコミュニケーションの混乱は生命の源であり、他のレベルの構造性で「カバー」することはできません。



レベル1:アジャイル


柔軟な(高速な)レベルの構造性により、多くの人がよく知っていると思います。 37 SignalsのBasecampのおかげで、ソフトウェア開発者だけでなく、ビジネスの他の分野でも柔軟なプロジェクト管理方法論が明らかになりました。



このレベルで使用されるツールを使用すると、意思決定を失うことなく、作業成果物のストレージを最小限に抑えることができます。 重点は、実行者が理解できる原子的な「問題」にタスクを分割することです。 このレベルの最小限のツールセットにより、「マイルストーンによる管理」を実装できます。 多くの場合、アジャイルツールのリストには、ファイル共有とバージョン管理されたファイルストレージもあります。



第2レベル:管理


タスクの実行時間が重要な情報である多くのプロジェクトがあります。 そして、この情報は多くのマネージャーにとって非常に重要なので、このスタイルのプロジェクト管理を別のレベルで区別します。



ガントチャートと「タスクに費やした時間」がここにあります。 目標は、できるだけ詳細かつ現実的な計画を立てることです。 プロジェクトのコンテキストをより予測可能にし、プロジェクトで必要な操作を開発すればするほど、ガントチャートの機能が向上します。 当然のことながら、タスク間の関係を規定し、あいまいなタスクや絶えず変化する要件に直面してすべてを計画しようとするのはおかしいです。 しかし、他のプロジェクトもあります。たとえば、「小区域の建設」では、各掘削機が日ごとに塗装されます。



管理レベルのツールを使用してチームが達成する追加の目標もあります。 プロジェクト図は、クライアントに彼らの哀しみと非常に制御性を示す方法です。 ネクタイと洗練された靴がクールな会議でどのようにあるべきか、プロジェクトにガントチャートがあるはずです:)



制御されたタイプのプロジェクトで動作するよく知られたシステムは、MS Project(alas、これが唯一の機能)、 LiquidPlannerIBNZohoComindworkです。 そしてもちろん、 @TaskDaptivのようなプロジェクト管理の大御所



第3レベル:定義済み


私自身が到達した最後のレベルは、ビジネスプロセスの設定です。 このレベルでは、プロジェクトは個々のプロセスを識別し、各プロセスに対して独自のツールが構成されます。 そのようなプロセスの例は、顧客からのインシデントと問題です。 支払いと金融取引; 重要なドキュメントの承認。



各プロセスについて説明します。 カスタムプロセスをサポートするツールは既に少数です。 これが良い例です-SalesForce (ただし、CRMの分野ではなく、プロジェクト管理)、 JiraIBNComindwork



おわりに


作者に敬意を払い、誰に対しても敬意を払ってください。テキストを書くのはそれほど簡単ではなく、自分の製品に何度か言及するからです。

ご意見をお寄せいただき、ありがとうございます!



All Articles