1. 私たちは普段どのような種類のプロジェクトを行っていますか?
通常プロジェクトと大規模プロジェクトの2種類があります
1. 通常商品
技術チームの焦点は実行を適切に行うことであり、システムのデリバリーを確実にするためにプロセス制御にさらに注意を払う必要があります。
2. 大きなプロジェクト:
ビッグプロジェクトとは何か、その特徴は何ですか
大規模なプロジェクトには、多大な時間、大規模な人員、システムの大規模化、複雑さ、調整の難しさが伴い、メンバーの調整や事務の推進にも困難があり、それらを解決する能力が求められます。
共通プロジェクトとしては、No.1プロジェクト、システム再構築プロジェクト、新製品開発プロジェクト、
昨年の疫病の最中に、私たちはシステムのリファクタリングを完了しました。複数の封鎖に基づいて、リファクタリングシステムを正常に完成させ、立ち上げました。振り返ってみると、単純に見て、そう思うなら、別の大きなプロジェクトに挑戦しましょう。どうやって手に入れたの
2. 大きなプロジェクトの場合は、重要なポイントに焦点を当て、移動前に決定を下す
プロジェクトが重要であればあるほど、計画、設計、準備に多くのエネルギーを投資する必要があると思います。
いくつかのポイントを要約します。
ビジネス、テクノロジー、チームなどに関して、「WHY」「WHAT」「WHO」「HOW」を明確に問い、明確に考える
WHY（プロジェクトが完了する理由）。多くのリーダーは、プロジェクトの実行と遂行に慣れているため、またはたとえ意見が違っても何も変えることができないと感じているため、プロジェクトの背後にある「なぜ」を探ることに熱心ではありません。「WHY」が分からないと、問題を解決したいときに核となる論理的根拠が欠如し、真の需要を特定することが難しく、自分が欲しい機能と問題の判断が困難になります。解決したいことは同じです。
WHAT（どんなプロジェクトが作られるのか）。「WHY」はプロジェクトの動機や目的を決めること、「WHAT」はプロジェクトの具体的な形を決めることであり、簡単に言えば、どのような製品やシステムで目的を達成するかということです。例えば、年間の需要において、これらのリンクは当社の事業開発、特に新規事業の発展に重大な支障をきたします。このような「超」プロジェクトに参加するなら、少なくとも次の2点は押さえておくべきでしょう。
WHO (一緒にプロジェクトを行うために来る人)。多くの問題はシステムの問題だけでなく、人も重要な要素であるため、プロジェクトの中核となる人材を特定し、プロジェクトのすべての関係者をリストアップする必要があります。
HOW（プロジェクト開始後のやり方）。事業目標、成果期待、関係者を明確にした上で、プロジェクト実行プロセスに入りますが、従来のプロジェクト管理をベースに、この2点に注意する必要があります。
タスク (モジュール) を合理的に分割することは、プロジェクトの成功の半分です。大規模なプロジェクトでは、設計と計画のために最終的な効果をパッケージ化する必要があり、それは実行プロセス中に確実に分割され、達成されます。重要なのは、全員が最終的な構造について合意に達するのを待ってから、チーム、ビジネス ドメイン、特定のシナリオ タスクの規模に応じてタスクとモジュールを分割し、最後から始めて、どのように実行するかを決定する必要があるということです。最終的な望ましい結果から分割を開始します (最終的なアーキテクチャの形状は、製品とシステムの全体的なアーキテクチャに基づく必要があります)。
リスク認識を維持し、マーフィーの法則に畏敬の念を抱く: 大規模なプロジェクトは、推進プロセス中に緊急事態や確率論的な出来事が発生する傾向があります。プロジェクトのスケジュールに十分なバッファを確保するなど、適切な計画を立て、緊急事態の対処メカニズムを事前に決定する必要があります。問題など
十分な準備を行った上で、プロジェクト設立会議を開催し、WHY、WHAT、WHO、HOWの情報や考え方をプロジェクト関係者間で共有します。キックオフ ミーティングは、プロジェクトの雰囲気を決め、必要な情報を同期し、プロジェクトを進めるための障害を取り除きます。
第三に、難しい問題にどう対処するか、
大規模なプロジェクトは非常に複雑で、多くのやっかいな問題を抱えがちです。これらの問題に対処するための基本原則は、最終結果を重視し、可能な限りの支援とリソースをすべて使用し、原則に違反することなく適切なバランスと妥協を持って目標を達成することです。次に、あなたにインスピレーションを与えることを願って、人や物の二次元から私が踏んだ落とし穴のいくつかを共有します。
人材の在庫、能力のマッチング、製品要件、目標管理、タスクの分解、チームの雰囲気など、このプロセス中に新しい人を追加しないでください。そうしないと、仕事が大きくなるほど忙しくなり、大規模な作業には従事しません。訓練は時間、進捗、コストなどに大きな影響を与えるため、指示を与え、計画を与える
1. 質問 1: 少将が不足している場合はどうすればよいですか?
プロジェクトの人員不足が常態化しています。たとえば、部門内の一連の基幹システムを書き換える必要があるが、チームが繰り返し作業を続けて指定時間内に書き換えを完了することができません。全員が ALL IN を書き換えると、システムは商業的に受け入れられないため、反復は 2 ～ 3 か月間停止されます。サイクルが長くなり書き換えプロジェクトが半年に及ぶと、事故のリスクが高まるだけでなく、書き換えプロジェクトは長期間価値を生み出すことができず、チームの負担となります。 。
同様の状況に遭遇した場合は、社内で動き回って、プロジェクトの価値や利点を主体として利用し、上位組織の助けを借りて他のチームから人材を借りる必要があります。「借りる」「借りられる」という経験がある人は嫌がるでしょう。この方法だと、業務やシステムに詳しくない他チームの学生が参加するなど、新たな問題が多く発生します（費用がかかる）。状態への移行が非常に高い）、またはあなたとの間に報告関係がなく、仕事の手配とタスクの実行がスムーズではありません。
したがって、大規模なプロジェクトにおいて、プロジェクトメンバーを補充するために人材を頻繁に借り入れることはお勧めできませんし、人材の出向が頻繁に行われること自体が、権利と責任の不一致を反映しており、一連の問題を引き起こすことになります。組織横断的なプロジェクトチームの構成を組織内での共通認識とし、全員が必要に応じて柔軟にプロジェクトチームに参加できるよう柔軟な業績・評価・報告制度を設計するのが良い方法だろう。また、プロジェクトチームに所属する場合は、以下の点に注意してください。
プロジェクトが始まったら、チームのメンバーではなく、より大きな視点から適切な学生を探してください。
プロジェクトに参加する学生の一定期間内の報告関係や業績評価をプロジェクトチームにまとめ、プロジェクトリーダーは各人の権利と責任を実情に応じて再整理し、拘束関係と責任を決定します。パフォーマンスの割合。
プロジェクトの実施は終わりを意味するものではなく、すべての従業員のパフォーマンス結果がプロジェクト目標の達成と密接かつ長期的に関連している必要があります。
最後に、場合によっては「兵士不足」の問題を解決するだけでなく、「少将」になるかどうかを真剣に検討する必要もあります。現在の人材がプロジェクトのオーナーとしてふさわしいかどうかを十分に検討する必要があります。私の経験から言えば、プロジェクトの成否はプロジェクトオーナーがほぼ8割を決めます。オーナーの能力が足りなければ、助けやサポートを与えるか、別の人や上司を見つけるか。結局のところ、プロジェクトの成否が鍵となるので、オーナーの選択には妥協しないでください。
2. 質問 2: 押してはいけないのは人や物ですか?
あなたも同様の経験はありませんか: 一部の機能やモジュールは、誰もが実装していないことが多い、または急いで実装する必要があることがよくあります (たとえば、ダブル イレブンに新しく追加されたアクティビティ ゲームプレイにより、多くの関連チームが担当するシステムを実装できるようになります)。これにより、プロジェクトの進行が妨げられる可能性があります。
以前、私は会社の注文取引システムを長く担当していましたが、この分野に詳しい学生ならわかると思いますが、注文システムは寄せ集めであり、どんな企業でも注文フォームにフィールドを追加したいと考えます。当初、注文システムにデータを追加するかどうかでよく議論しました。デザインが汚いとシステムの安定性や保守性が損なわれるのではないかと心配したからです。
この 2 つの状況からわかるのは、人や組織には動かせないものがたくさんあるということ、対応を誤ると関係者間の対立が激化する、同様の問題に対処する必要があるということです。
対立現象における利益要求を理解する: さまざまな関係者間の意見の対立という現象の背後には、実際には利益相反が存在しており、お互いの懸念を理解する必要があります。例えば、発注システムの保守性や安定性を考慮して、あるシステム項目を発注に含めたくないのですが、その懸念を解決していただければ、納得していただきやすいと思います。
プロジェクトの結果に対する適切な妥協: 多くの場合、完璧なソリューションを作ることはできず、システムへの実装が不十分なまま要件を達成する必要がある場合もあります。プロジェクトは 100% 完璧ではありませんが、基本原則を理解して諦めないのが良い戦略であり、プロジェクトの進行と引き換えに制御可能な部分は妥協するのが良い戦略です。
プロジェクトのステータスと意思決定メカニズムを通じてプロジェクトを推進する: 大規模プロジェクトは多くの場合、企業の主要な戦略の成果です。通常の状況では、特定の企業が確立した戦略に反対する人はいないため、大規模プロジェクトの重要性を利用して、より多くの目標を達成するために努力することができます。システム内には多くのリソースとヘルプがあります。何らかの対立に直面した場合は、意思決定メカニズムを使用して、上位のメンバーとのコミュニケーションと意思決定を通じて解決策を得る方法を学びましょう。
3. 質問 3: プロジェクトの変更はありますか?
あなたにとって最も対処が難しいのは、突然の変更、つまり以前の計画の調整であり、新たな困難や問題が現れるでしょう。多くの場合、一般的な変更点が 2 つあります。
プロジェクトの進行中に、これまで特定されなかった、または考慮されていなかった不足点が特定され、計画を調整する必要が生じました。
上司からの要件の変更は、多くの場合、内容の追加です。
プロジェクトの変更や上司の CR への対応が難しい理由は、プロジェクト本来の計画リズムが崩れてしまうためであり、本来連動していたタイムスケジュール、人員スケジュール、タスクやモジュールのスケジュールを組み替え、結合し、矛盾を解決しなければならないからです。リスクはリンクを介してプロジェクト全体に伝達され、強力な連携効果が得られます。
私からあなたへの提案は、平常心を保つことです。ほとんどすべてのプロジェクトが同じような状況に遭遇します。否定的な感情があると、問題の解決がさらに難しくなるだけです。2 つのことをしっかりと行う必要があります。
外側から内側へ解決するには、優先順位の調整、新しいリソース、スケジュールの調整から始めますが、そうでない場合は、時間の圧縮、計画の調整、さらには残業を検討します。ROI とリスクを適切に比較検討し、問題 A を解決するためにより困難な問題 B を作成しないでください。
統合変更管理では、すべての変更を管理、レビュー、評価、記録し、最終的にプロジェクト メンバー全員にブロードキャストして、全員の情報に一貫性があり、エンドポイントの理解に誤りがないことを確認する必要があります。
さらに、私自身の経験を共有したいと思いますが、上司が頻繁に変わることに悩んでいる場合は、プロジェクトの進捗状況と解決されている問題をより直感的に経験できるように、報告を増やすようにしてください。決定論的なリスクはより大きな共感につながります。
4. まとめ
大規模プロジェクトはテクノロジー リーダーの試練の場であり、技術的な能力が試されるだけでなく、製品、ビジネス、コミュニケーション、ビジネスの進歩などの総合的な能力が試されます。主要なプロジェクトでひどい暴力を経験した学生は、他の問題に対処するときにより冷静になります。
そのため、実際の仕事で同様のプロジェクトに参加したり主導したりする機会があれば、ぜひ挑戦してみると問題解決能力が大幅に向上します。今日の講義では、次の 3 つの点を強調したいと思います。
大きなプロジェクトをマスターすることが試金石であり、分水嶺となるため、自分のキャリア計画に一定の要件がある学生は、磨きと練習の機会を逃してはなりません。
大規模なプロジェクトでは、人に関連する問題は完全に合理的かつ論理的ではない可能性があるため、技術的およびシステムの問題よりも人的問題の解決が難しいことがよくあります。この時点では、感情的なコミュニケーションとコミュニケーションの方が優れているかどうかを確認するとよいでしょう。
プロジェクトを予定通り立ち上げて失敗なくしても60点であることを常に念頭に置き、重要なのはビジネス上の効果であるため、開発プロセスを常に把握するだけでなく、開発にも全力を注ぐ必要があります。それはビジネスと製品の設計段階のまさに最初の段階です。
