バックグラウンド
同社のビジネスの急速な発展とビジネスラインの急速な拡大に伴い、プロジェクトは数が多いだけでなく、ますます複雑になり、多くのプロジェクトはチーム間およびドメイン間のコラボレーションを伴います。この前提の下で、技術層は、リソースの競合を回避し、リソース情報とプロジェクト情報を同期させ、プロジェクトが計画どおりにタイムリーに完了および提供されるようにするために、定期的にビジネス型プロジェクトの開始および宣伝準備会議を開催します。
スタートアップに関するよくある質問
ほとんどの新興企業は、急速な成長の過程で、プロジェクト リソースの割り当て、情報の調整、プロジェクト管理などの問題に直面します。特定の問題点は次のように分類できます。
1) プロジェクトがクロスドメインを含み、情報が整合していない。一部のプロジェクトにはクロスドメインが含まれますが、ドメイン間のコミュニケーションが少なく、すべての関係者が優先度、計画時間、製品ソリューション、技術ソリューションなどのプロジェクト情報について一貫性のない理解を持っています。これらの状況はプロジェクトの進行に役立ちません。
2) 要件やプロジェクトが確認できない、優先課題。統一されたビジネスプロジェクトの承認会議とプロセスがないため、各ドメインはそれがプロジェクトであり、独自のドメインでニーズがあることを確認します. ただし、各ドメインのさまざまな条件により、プロジェクトの識別基準もかなり異なります. Aドメインではプロジェクトに応じて実施され、Bドメインでは反復的な要件に従うため、優先順位の統一が難しく、プロジェクトのスケジュールを立てることができません
3) プロジェクトのリソースが保証されず、プロジェクトの計画に影響を与える。プロジェクト情報や重点課題のズレにより、プロジェクトリソースの確保が困難
4) 各ブロックのリーダーが明確でなく、プロジェクトの推進が難しい。統一されたプロジェクトの確立とプロセスがなく、各ドメインのプロジェクト標準が相互運用可能でないため、プロジェクトを使用するためのビジネス、製品、および技術の担当者を決定することは困難です。そのため、問題が発生した場合、率先して対処することができないか、最も傷ついた人が対処することがよくあります。
ソリューション
上記の問題を解決するために、技術部門が中心となり、定期的に独自のプロジェクト準備プレゼンテーションを開催し、プレゼンテーションプロセスを策定し、地域全体での運用を促進します。
自主企画プレゼン準備会：技術部の主導により、事業・製品が独自に懸案案件情報を記入し、週2回の集中企画成立プレゼン会に参加。プロジェクトの背景、メリット、計画などの情報を標準化・集中的に紹介することで、プロジェクトに沿った承認・推進が可能かどうかを確認することを目的としています。
次に、プロジェクトの承認基準と会議プロセスに関する情報を詳しく紹介します。
1) 事業認定基準
ドメインごとに条件が異なるため、統一的なプロジェクト承認基準を確認することは不可能であり、各ドメインが独自の開発状況と特性に応じてプロジェクト承認のベースラインと基準を決定し、ビジネスの反復とビジネスのバランスを実現します。計画。確認後、各ドメインでのプロジェクト承認基準を関係者全員が理解できるように、社内の全ドメインに公開します。
たとえば、ドメインAのプロジェクト承認基準:
状況 1: 事業者から提出された要求またはプロジェクトは、次のいずれか 2 つの条件を満たし、独立したプロジェクトを宣言できます。
-
新しいビジネスモデルまたは新機能
-
クロスビジネスラインの数 ≥ 2
-
推定投資リソース ≥ 150 マン日
状況2：トレーディング版のスケジュールに入る必要があり、以下の条件のいずれか2つを満たす場合、独立したプロジェクトに応募できます
-
クロスバージョン数量 ≥ 3
-
クロスビジネスラインの数 ≥ 2
-
推定投資リソース ≥ 150 マン日
「クロスビジネスライン」の説明
-
例: A ドメイン、B ドメイン、C ドメイン、つまり「クロスライン オブ ビジネス」
-
Aドメインのaライン、Aドメインのbライン、Aドメインのcラインは「同一の事業ライン」（ドメインAの事業ライン）
B ドメイン プロジェクトの基準:
-
スキームの完全性に対する高い要件 (つまり、反復におけるクロスバージョン分割には適していません)
-
研究開発の作業量は 100 人日を超えると推定され、関係者は 3 つ以上のビジネス ドメインに関与しています。
全体として、各ドメインのプロジェクト承認基準は、主に、ワークロードが大きいかどうか、クロスドメインであるかどうか、0-1 機能であるかどうか、および明確で高収率であるかどうかの 4 つの側面について設定されています。
2) 担当者の確認
プロジェクトの主要な 3 者（ビジネス、製品、技術）の担当者は、プロジェクトの開始時にレイヤーごとに確認する必要があります。確認後、業務担当者が製品側に連絡し、製品ドッキング責任確認を行います。プロジェクトの承認後、技術事業者は、プロジェクトの技術面の関連事項を促進するために、対応する技術的責任を手配する必要があります。
三者責任者の主な業務：
ビジネスサイドの担当者 ：クロスドメインなど、ビジネスレイヤーでのプロジェクト情報のすり合わせをしっかり行う必要があり、ビジネスレイヤーの情報を処理し、ゴールに合わせることを率先して行う必要がありますプロジェクトの整合性。
商品側の担当者： 商品層のプロジェクトの商品企画をすり合わせてインプットする必要がある商品企画に問題があれば率先して推進する必要があるプロセスをフォローアップして、製品計画が時間どおりに高品質で提供されていることを確認します。
技術面の担当者 ：プロジェクトが計画どおりに遂行され、高い品質が要求されることを保証するために、プロジェクトの観点から技術面の課題の推進と整合確認を行う必要があります。
全体として、計画されたリズムに沿ってプロジェクトを進め、質の高いプロジェクトを遂行するためには、各担当者がプロジェクトの観点からそれぞれの境界を突破する必要があります。
3) プロジェクト スピーカーは、以前の情報を調整します。
プロジェクトの講演者は、ビジネス、製品、技術のいずれかです。プロジェクトの発表者は、プロジェクトの承認前に情報を収集、調整、および確認する必要があります。プロジェクトの背景、目的、MRD、その他の関連情報などのプロジェクト情報。
4) プロジェクトの説教者は、独立したプロジェクトの準備プレゼンテーション フォームに入力し、フォームの情報に従って登録します。
自主企画セミナーの募集要項に沿って情報収集・登録必須項目：プロジェクト名、プロジェクトの背景と目的、プロジェクトの価値、事業領域、スポンサー、スピーカー、MRD、製品：
5) 独立したプロジェクト準備会議を組織する
- 会議のサイクルについては、会議は 2 週間ごとに開催されます。これは、登録時に事前に通知し、すべての関係者に電子メールで送信する必要があります。
-
会議の主催者 (PMO) は、プロジェクトのサイクル タイム要件と、独立したプロジェクト準備プレゼンテーション フォームの登録情報に従って、会議を開催します。
-
参加者、CTO、プロジェクト スピーカー、関連するビジネス ドメインのテクニカル ディレクター、その他の任意の担当者はイニシエーター、製品、ビジネス
-
プロジェクト通知グループを作成します。これは、すべてのスピーカーをグループに引き込み、プロジェクト関連のプロセスと注意が必要な事項を同期させるためのものです
-
会議を発表者と対応するビジネス ドメインのテクノロジ リーダーに転送する
-
プロジェクト登録情報に不備がないか確認し、登録情報に必要な項目を確認し、当該事業ドメインの技術担当者にMRDを送付し、問題がないか確認してください。会議の効率を上げるためには、各MRDの内容に応じてプレゼンテーション時間を見積もる必要があり、プレゼンテーション時間を3～5分以内に抑える必要があります。
-
会期中、各課題の登録順と発表予定時間に従い、順次発表を行います。
6) 自主企画準備会議の結果を同時に発表
説明会終了後、主催者は各企画の発表状況や成果を登録し、メールやフェイシュウグループで全員を通す必要があります。
要約する
案件決裁プロセスを標準化し、案件決裁会議を画一的に実施することで、情報のズレや最適化、フォローアップ不能などの問題を効果的に回避し、案件納期の効率化と品質のさらなる向上を図ることができます。
プロジェクト承認基準の確立により、承認が必要なドメインと承認不要のドメインがすべて明確になります。
プロジェクト承認プロセスの統一により、各ドメインは、以前のプロジェクトの一貫性のない内容による曖昧さではなく、プロジェクトの開始方法とプロジェクト承認に必要な情報をより明確に知ることができます。
全員責任者制度により、各責任者の責任分担を明確にし、プロジェクトの課題を進め、プロセスをたどることができます。
上記の計画を実施することにより、プロジェクトの高品質でタイムリーな配信をより確実に行うことができます。