入力タスクとプロジェクト情報
物流会社は新しい倉庫を開く予定です。 このプロジェクトの実施により、主要顧客がプレゼンスの地理に課した条件を満たし、近隣地域での商品の配送と保管のための会社の物流コストを削減できます。 今は6月の初めです。 プロジェクトは9月中旬までに完了する必要があります。 2週間でプロジェクトの内容を説明し、スケジュールを作成し、予算とプロジェクトに必要なすべてのリソースを決定する必要があります。 すべてのドキュメントは、プロジェクト参加者と、マネージャーによるリソースの合意が必要です。
計画の準備。 プロジェクトチームの定義
すべてのプロジェクトパラメータを計画するために必要です。 もちろん、主な参加者はプロジェクトマネージャーと顧客です。 多くの場合、これらの人々は抽象的で複雑な方法で考えることができる高給のトップマネージャー（いわゆる「将軍」）ですが、詳細を詳しく述べることはあまり好きではありません。 私は通常、「一般」を開始会議に招待しませんが、私は彼らの代理人（いわゆる「補助者」）を回避します。
また、私は常に自問します。将来のプロジェクトの情報源は誰ですか？ これは難しいです。 さまざまな時点でプロジェクトに情報を提供できる人のリストは、かなり大きく、ぼやけている場合があります。 したがって、プロジェクトの内容を説明するのに十分な情報を提供してくれる従業員のみを特定します。 後で、プロジェクト計画を作成するときに、リソースとその情報の必要性をより完全に判断できるようになります。
倉庫を開くプロジェクトにおいて、倉庫の機能の重要な問題は、新しい地域で選択され雇用される必要のある人員です。 このプロセスにかかる時間と満たす必要のある条件は、人事部門によって決定されます。 それで、彼のリーダーを書きます。 また、プロジェクトは、近隣地域から車両を移動する必要があります。 輸送部門の長は、輸送の単位、条件、移動方法によって決定する必要があります。 これは、計画参加者のリストに追加することを意味します。 などなど。 私が持っています
次のリストを得ました：
- プロジェクトマネージャー（新しい倉庫に対する顧客の要件を持ち、過去に同様の作業を実行した）
- 人事部長（従業員の選択と雇用、オフィスのセキュリティ）
- 弁護士（免許、印章、憲章の修正の発行）
- 輸送部門の責任者（車両の輸送と通関）。
招待しないことを決めた人：
- 投資家（彼らは多くの仕事を持っていませんが、彼らはプロジェクトの「特定の」タスクを持っていません）
- ITの従業員（投資家に似ています。サーバー-アプリケーションが必要な場合、オフィス機器が必要な場合-スタッフ配置計画）の要件を知っています。
- 顧客。 なんで？ まず、彼は「一般」です（上記参照）。 第二に、彼は計画を始めることができるように彼の期待を十分に公式化しました。 第三に、そのようなカテゴリは、会議にドラッグするよりも、質問して回答を個別に受け取る方が便利です。 彼に生じた質問はすべて別のシートに書きます。
プロジェクト計画。 パート1.コンテンツの定義
プロジェクトのコンテンツを定義するのは簡単なことではありません。 将来のプロジェクトのすべてのパラメーターの文書化には、骨の折れる細心の注意が必要です。 尋問の形を取るために、相手との会話の準備をしなさい。 私は簡単な理由で自動化の手段を使用しません-ブレーンストーミングセッション中に作業を遅らせます。 そして、私にはほとんど時間がありません。 私は紙とペンのみを使用しています。
グループアセンブリ。 グループに自分の存在の目的を説明します-将来のプロジェクトの計画を支援するためです。 私は対談者のような経験はないので、彼らの助けが必要だと説明します。 作業の階層構造の構築を開始します（ISR、SDR、WBS）。 もちろん、私のメンバーはこれらのことを認識していませんが、これは必要ではありません。 私は質問をします：
- 私たちのプロジェクトの結果は何ですか？
- プロジェクトが完了したと言える条件は何ですか？
- プロジェクトの完了後、顧客はどのような主要な結果を見たいですか？
- 3〜5の最も重要なプロジェクトの結果は何ですか？
- プロジェクトの完了後、どのオブジェクト（ドキュメント、機器、従業員）が顧客に転送されますか？
など
明らかに、多くの質問は同じタイプのものであり、同じことについて尋ねます。 これは正常です。 おそらくこれは、優れた調査員が証人を尋問する方法です。 私は結果を大きく理解しやすいオブジェクトにまとめています。 プロジェクトが将来どのように実施されるかを理解し、これを参加者に伝えることができることが重要です。 シートに大きなブロックを描画し、2番目と3番目のレベルの分解で絶えずそれらを補完しますが、構造に特に煩わされることはありません。
すべての参加者が私の考えに従うように、私はチャートに表示するキーワードを常に大声で言います。 私は新しいアイデアを奨励し、最も重要なこと-ダイアグラム上の新しいオブジェクト。 取り消しは簡単です。 しかし、私の実践のプロジェクトは、フレームワークの詳細が不十分なために「落ちています」。 分解の上位レベルでの合計は次のとおりです。
- 建物
- スタッフ
- 支店の法的登録
- 倉庫設備
- オフィス機器
- 自動化
- 輸送
- 業務プロセス
- 倉庫およびオフィスのセキュリティ
- 予算の変更
お客様に質問を書くことを忘れないでください。 葉を捨てたので、メモリから：
- 新しい倉庫の建物には次のプロパティが必要であると考えています（リストに記載）。 そうだね
- 現在の1C構成のみが自動化として使用されます。
- プロジェクト内の他の倉庫から商品を移動していますか？
- プロジェクトの枠組みの中で主要なサプライヤーと契約を結びますか？
等
専門用語では、これらはプロジェクトの「仮定」です。 計画時に真と認めた要因。 これらの条件のいずれかが変更された場合、プロジェクトは予定どおりに完了しません。
グループにWBSを紹介します。「これはプロジェクトの内容です。 ブロック間の関係を確立し、リソースを割り当て、タスクの期間を決定する必要があります。 次に、各作品の締め切りを確認します。 15分の休憩に行くことができます。」
休憩中、私とプロジェクトマネージャーは、すべてのタスクを、構造が図と一致する（わずかに調整された）タスクの形式でMS Projectに直ちに送信します。 同時に、すべての定式化をチェックします。タスクはプロセスではなくタスクのように聞こえるはずです。 結果は、プロジェクトマネージャーと請負業者が理解する必要があります。
プロジェクト計画。 パート2.タスクの後継者と前任者の特定
プロジェクトチーム（実際はこれです）が再び組み立てられます。 プロジェクターの電源を入れて、最後の15分間で何が起こったかを説明します。 そして、グループに対する簡単な質問：
- コードx.xのタスク。 完了するまで実行できないタスクは何ですか？
- コードxxのタスクはどのタスクについて情報を提供しますか？
- コードx.xのタスクはどのタスクに対応します。 「入力」は何ですか？
等
専門用語では、これはタスクの「フォロワー」の確立と呼ばれます。 これは非常に面白くない仕事です。 しかし、何もすることはありません。
同様に、タスクの「先行」を定義します。 この仕事の方法論はあなたの将来の健康への鍵です。 タスク間の接続の種類を巧みに使用して、参加者の声明を正しく解釈します。「はい、いつでもできます！」 または「プロジェクト全体と並行して行われています！」 ところで、プロジェクトの完了に影響しないタスクをキャッチできます。 私たちはそれらを意図的に消します。
関係の定義と並行して、実行責任者を割り当てます。 「スイッチマン」や「ルーター」ではなく、実際のパフォーマーを見ることが重要です。 また、「開発者」のような「仮想」従業員を提供するのも好きではありません。 プロジェクトの各タスクには、姓、名、ミドルネーム、および自宅の住所が必要です！
少し技術的なニュアンス。 ネットワーク図には、常に「プロジェクトの開始」（前任者はいない）と「プロジェクト完了」（フォロワーがない）の2つのマイルストーンがあります。 このようなネットワークスケジュールの編成により、プロジェクトの開始日をいつでも変更して、すべての作業の完了を予測できます。 プロジェクトの正式な承認の2週間前に「プロジェクトの開始」を延期しています。 これは、官僚的な遅れから私を守ります。
その他。 リスクなどの流行語があります。 通常、私はそのような言葉で人々をだますことはありません-スタッフはすべての言葉を書き留めて、タスクと期限をすぐに与えるマネージャーの光景をすでに心配しています。 「ブレーキ」が確実に発生するタスクにリザーブを導入することで、状況を少し和らげます。 たとえば、情報を送信するときや交渉するとき。 タスクの近くにある予備の視覚的な表示は、参加者を安心させます。 もちろん、従業員が準備金の期限を確認するのは間違っています。 しかし、第一に、彼らは埋蔵量の最終的な分布に気付かないでしょう、そして第二に、誰もがタスクの構成とその実施のタイミングにのみ興味があります。 そして、この場合のチームの信頼は私にとってより重要です。
プロジェクト計画。 パート3.スケジュールの最適化
スケジュールの最初のバージョンは2か月に収まりませんでした。 つまり、プロジェクトを予定通りに完了したい場合は、4月に開始する必要がありました。 最後の比phorは、特にチームに適しています。 彼らは笑っています。 タスクの移動を開始します。
- スタッフを探すのに2ヶ月-たくさん！ すべての従業員を順番に検索する必要はありません。 プロジェクトに大きなリスクを伴わずに「並列」に動作します。
- プロジェクトの2つのマイルストーンを区別します。倉庫は顧客サービスの準備ができて（「必須」作業）、プロジェクトは完了しました（「オプション」作業は後で行うことができます）。 顧客に倉庫を開くことがより重要であり、結果の一部は1か月後に取得されることをお客様に説明することができます。
- 不要な関係などを削除します。
もちろん、常に最適化できるとは限りません。 しかし、我々はそれをやった。 支部の計画的な開設の1週間前に、すべての「必須の作業」が完了します（もちろん準備金を考慮に入れて）。 わかった わかった。
顧客は私のプロジェクトからそれほど離れていなかったため、蓄積された質問に答えるように招待しました。 しかし、これはできませんでしたが、通信で通信します。 ラッキー。 もちろん、私たちの個人的な存在から多くの利益を得ることはできませんでしたが、チームは重要な何かを完了する感覚を持ちました。
プロジェクト計画。 完了
プロジェクトオフィス（つまり、私）によって定義された正式な手順があります。 私は憲章（私はたくさんの情報を持っています）を開発し、資源管理者に郵送し、確認を収集し、作品の名前、その順序、時には構造を微調整します。 基本的なことを考慮したため、多くの変更はありませんが、部門は依然として責任を「ヘッジ」したいと考えています。
プロジェクトの開発に関するすべての作業に1週間かかりました。 合計10時間の会議が3回ありました。 プロジェクトの承認は明日行われます。 彼らは、「新しい入門書」があると言っています。 しかし、これはすでに「変更管理」です。 それについては後で詳しく説明します。
PSそれは知人によって書かれ、彼の名前はアレクサンダー・コルツォフです。 誰もが後悔していない場合-彼らは彼と招待を共有することができます。
彼のブログへのリンク