-
レビュー システムは、インターネット製品管理の重要な手段であり、戦略計画、製品設計、技術導入、製品運用、製品マーケティングなどの製品管理のあらゆる側面で実行されます。効率的なレビューシステムは、企業の製品管理能力を測る重要な尺度であると言えます。レビュー システムの価値のいくつかを簡単に挙げてみましょう。
レビュー システムは、関係者が製品構築の目標について一貫した理解を得るのに役立ちます。
レビューシステムを通じて、製品企画計画、製品需要計画、技術計画、運営計画、マーケティング計画などの品質をチェックし、製品の品質を向上させることができます。
レビュー制度により、商品企画や構築プロセスにおけるポイントやリスクポイントを確認し、プロジェクト実施のリスクを低減します。
評価制度は参加者の能力を効果的に向上させることができます。
システム製品のアーキテクチャとアーキテクチャ設計の精神が一貫して実装されていることを確認するため、レビュー制度を通じて計画をチェックします。
製品レビューは非常に重要ですが、どの企業のレビューシステムも効率的ではないようです。レビュー会議は形式的なものになったり、主要陣営間のPKに発展したりしています。レビュー システムに関しては、さまざまなソフトウェア エンジニアリングの書籍や方法論で取り上げられていますが、ここでの焦点はレビュー システム (製品レビューなど) の一般原則について説明することではありません。ベースの製品をレビューシステムで確認する方法。
1. 建設段階プロジェクト VS. 運営段階プロジェクト
決済プラットフォームやオープンプラットフォームなど、プロダクトプラットフォームの概念を採用したインターネットプロダクト（プロダクトプラットフォーム）の場合、構築期のプロダクトのプロジェクト管理は、運用期のプロダクトのプロジェクト管理とは異なる課題に直面します。
これらの製品プラットフォームを強調する理由は、多くのインターネット製品の主なロジックは Web サイトのフロントエンドであるため、これらの Web サイトのレビューは比較的簡単で、プロトタイプ主導のアプローチのみが必要となるためです。しかし、これらのプラットフォーム製品では、単純な Web サイトのページ開発作業だけではなく、通常、これらのシステムの最も複雑なロジックはバックエンドのビジネス ルールとビジネス ロジックにあり、これらはプロトタイプでは明確に説明できません。
1) 建設期間中のプロジェクトの特徴
プロジェクトサイクルが1か月以上など比較的長い
プロジェクトのリソースが比較的豊富で、別個のプロジェクト チームとして運営可能
プロジェクト管理では、従来のプロジェクト管理方法またはアジャイルなプロジェクト管理方法を使用できます。
比較的完全な製品ドキュメント、完全なプロトタイプ、完全なプロジェクト計画、プロジェクト確立セミナー/需要セミナーなど、市場調査/競合製品分析など、プロジェクト前の準備作業は比較的十分です。
プロジェクトは比較的独立しており、他のプロジェクトによる制約が少ない
2) 事業期間中の事業の特徴
サイクルは短く、ほとんどの場合は 2 週間未満です
リソースは限られており、プロジェクト チームのメンバーは他の製品を同時に保守しなければならない場合があります。
会社のビジネスが拡大するにつれて、製品や技術的なアーキテクチャに精通した人材は常に不足しています。これらの人材は通常、いくつかの重要な新しいプロジェクトを担当しており、新人が職場のシステムに慣れるのを手助けする必要があります。
プロジェクト管理では、一般に、スクラムや XP などのアジャイル プロジェクト管理手法、または縮小されたアジャイル開発が採用されます。
プロジェクトの準備が不十分であり、十分な準備をしてから実行することは不可能です。
プロジェクトは既存の製品に基づいて最適化および再構築する必要があり、既存のシステムに影響を与えることはできません。運用可能な製品の場合、製品アーキテクチャとシステム アーキテクチャは、少しずつ変更するうちに制御を失い、変形します。これらの要因を制御するメカニズムが必要です。
ここでは、運用期間中の製品レビューと技術レビューの方法に焦点を当てます。
2. 運用期間中の商品レビューの原則
どんなに緊急なプロジェクトであっても、製品レビューと技術レビューは必ず行わなければなりません
レビューは機敏でなければなりません
レビューの形式は関係ありません。レビューしてください。 =会議、レビューの形式は、公式レビューまたは非公式レビューのいずれかになります。レビューの核心は、システムに精通し、計画をチェックできる人材が必要であるということです。
レビューの目的は、最適な解決策を見つけることではなく、既存のリソースの制約内で最も合理的な解決策を見つけることです。
完璧なレビュー制度は存在しません。重要なのは、実際にレビュー制度を継続的に最適化し、自社の状況に応じたレビュー制度と事後対策を確立することです。
3. 運用期間中の商品レビューの方法
運用期間中の製品レビューには、参考となるベストプラクティスプランはなく、各企業の現実的なビジネス環境が異なり、ビジネスモデルごとにレビュー方法も異なります。運用期間中の製品の効率的なレビューは、管理の標準化、俊敏性、ビジネスの現実性の要件のバランスを取る必要があるバランスの芸術であると言えます。しかし、全体として、運用期間中の製品レビュー方法の核心は同じであり、チームの協力に基づく継続的な改善です。
運用期間中のレビュー体制は、運用期間中の製品開発プロセスによってサポートされる必要があります。製品レビューシステムの継続的な最適化を確実にするために、他のプロセスリンクからレビューシステムの問題を収集して明らかにするために、運用期間中の製品開発の簡素化されたプロセス（建設期間中の製品開発プロセスと比較して）を策定する必要があります。たとえば、品質テスト、運用、販売、マーケティング、その他のリンクからのフィードバックを通じて、レビュー システムが失敗したプロジェクトが発見され、ケース ライブラリに組み込まれ、研究開発プロセスとレビュー システムが継続的に最適化されます。
レビューが必要な厳格な基準を確立し、それを定量化可能なチェックリスト形式に洗練します (単に最初の基準)
たとえば、開発時間が 1 週間を超えるか 1 週間未満であっても、主要なビジネス モジュールが含まれる場合は、それらをレビューする必要があります。審査の要否をインターフェース担当者で判断するのではなく、工期と影響を一律に評価する手法を採用しているのは、人的要因が多すぎて審査制度が形骸化するのを避けるためである。
1週間以内で主要なビジネスモデルの変更を伴わない場合は担当者が独自に判断します。
レビューには利害関係者の参加が必要であり、製品担当者や技術担当者だけが評価するだけでは不十分です。たとえば、製品ソリューションには技術担当者、運用担当者、財務担当者などが必要です。技術ソリューションには製品担当者、アーキテクト、ビジネス専門家などが必要です。レビューに参加している関係者は、計画をロールバックしてやり直す権利を有します。もちろん、これにはチームのコラボレーションという別の大きなテーマが関係します。チームが信頼関係を確立できなければ、システムがどれほど完璧であっても、それは PK になります。
レビュー担当者は包括的なレビューを行う必要はありませんが、レビューの効率を確保するために、要件の主要なポイント、主要なビジネス ルール、およびリスク ポイントに関する計画のみをレビューします。レビュー結果は、関連するプロセスフォームに記録する必要があります。
レビュー事例ライブラリを確立し、レビュー事例ライブラリを定期的（月次）にレビューし、レビューシステムを継続的に最適化します。レビュー事例の要約は、人物ではなくその問題に焦点を当てるべきであり、レビュー担当者に結果に対する全責任を負わせないようにする必要があります。
システムの実行は、システムが最初にどの程度完璧に定義されているかには依存しません。重要なのは、システムを継続的に最適化できるかどうかです。継続的最適化/継続的改善/継続的改善は、さまざまな管理方法のよく知られた効果的な核心秘訣の 1 つですが、特にそれらの管理ファッションのバズワードと比較すると、継続的改善について言及するのはあまりにも独創的で退屈です。 . それは非常に高いので、私たちは皆、私たちが直面しているさまざまな問題を解決するための「特効薬」を望んでいます。
記事の出典：以前のように僧侶になって仏陀になる 転載の際は出典リンクを明記してください。