製品運用要件ドキュメント（新しい製品開発者であれば、実際に適格な製品要件ドキュメントを作成できます）

新製品開発者は、実際に適格な製品要件文書を作成することができます

Come to Everyoneはプロダクトマネージャー[Starting Point Academy]で、BATの実践的なプロダクトディレクターが製品と運用について段階的に教えてくれます。

製品要件のドキュメント化は、製品担当者にとって非常に重要な基本スキルです。これは、R&D、テスト、UED、ビジネスを調整するための非常に重要なツールです。しかし、多くの新しい PM やインターネット分野の PM が作成したドキュメントは、主に次の点に反映されており、満足のいくものではないことがよくあります。

• 論理性に欠け、冗長で洗練されていない言語。
• 口語的な言葉が多すぎると、全体がプロフェッショナルに見えなくなります。
• データ構造やフィールドの論理関係を明確に表現することは不可能です。
• 開発思考の欠如;

その理由は次のとおりです。

• 新入社員は文書作成やプロセス設計に関する厳格なトレーニングを受けていません。
• ほとんどの PM は R&D のバックグラウンドを持っておらず、フロントエンドとバックエンドのビジネス ロジックとデータ構造を明確に理解していません。
• 詳細な分業、急速なバージョンの反復、機能ポイントの理解不足。

完全な製品要件ドキュメントは、PM が担当する機能を効果的に管理するのに役立つだけでなく、ビジネス ロジックを明確にし、分解された機能ポイントのテスト、研究開発、設計、および運用を調整します。

モジュール化された機能ポイント（Daoyeが過去に作成した機能）

ただし、企業によって製品要件ドキュメントのテンプレートは異なります。ただし、テンプレート形式が何であっても、ドキュメントの本質は「機能を効果的に明確に表現し、その後の業務の引き継ぎとバージョン反復の参照をサポートし、上位レベルと下位レベルに価値を伝達する」ことです。さらに、プラットフォーム ビジネスの発展に伴い、アーカイブおよび保存されたビジネス ドキュメントは、さまざまな時期の PM、R&D、テスト、プロジェクト マネージャー、設計者などがビジネスについてどのように考えているかをまとめた、非常に貴重な知識ベースとなります。文書調査自体も、企業が戦略を詳細にどのように実行しているかを反映しています。

しかし、「業務内容、機能内容、その他の要件」は、製品要件書を構成する非常に重要なモジュールです。この章では、一般版の観点からこれらのモジュールを紹介します。

あらゆるビジネスや要求には、関連するビジネス部門または製品マネージャー自身であるビジネス提案者がいます。

ビジネスソースの本質は、このビジネスを通じて実際的な問題を解決し、特定のコンバージョン率や特定の目標を達成することです。事業内容を明確に表現できます。複雑である必要はありませんが、一般的には次の内容が含まれます。

• 事業背景
• 製品機能の概要
• 製品見込み分析
• 製品機能全体プロセス
• 製品ロジック関係
• オブジェクト指向
• 応用
• 用語集
• 参照ドキュメント

上記のレベルは、一般バージョンの観点から、製品の価値をR＆Dとビジネス関係者に伝え、両者間の効果的な接続を実現します。

なぜビジネス、機能、概要についてマクロで非現実的な説明をする必要があるのでしょうか?これは面倒だし時間の無駄ではないでしょうか？

機能が追加または削除されるたびに、それは狭い意味では大したことではないということを理解する必要があります。しかし、マクロの観点から見ると、機能的な研究開発には企業の運営コストがかかります。適切に処理されない場合、運用コストが無駄になり、ユーザー エクスペリエンスや開発ルール全体に影響が及ぶこともあります。

製品のビジネス価値を伝えずに、製品担当者がR&D担当者を無理やり開発フェーズに追い込むのは間違っています。もし私が研究開発部門にいたら、この PM を殴り殺すだろう。すると、ビジネス記述の本質が明確になり、ビジネス価値がチームメンバーに伝わります。

一方、多くの企業では社内のプロジェクトプロセスが不完全であり、R&D 担当者全員が優秀な人材であるとは限りません。多くの場合、プロダクト マネージャーはプロジェクト マネージャーの責任を引き受け、プロジェクトの開発と立ち上げを推進する必要があります。この場合、ビジネス価値の説明が明確でなく、機能の開発およびリリース中に問題が発生した場合、開発者が非難されることになります。

ちなみに、これらについてはすべてお話しするわけではなく、仕事の中でゆっくりと蓄積していきます。

以下に、事業内容の説明を構成する要素について説明します。

ビジネス背景の説明:

ここでは、ビジネス提案者について説明し、ビジネス提案者がこの要件を提案した理由を詳しく説明する必要があります。なぜ？一方で、R&D 担当者に、なぜこの製品または機能を設計したのかを伝える必要があります。この需要には、その源からデザインに至るまで理由があります。一方、関係する事業部門を巻き込めば、少なくとも一人で戦うことにはなりません。

製品機能の説明:

現在の機能、設計された製品または機能の機能モジュールの概要を提供し、それらの製品機能を追加、改善、最適化します。

製品見込み説明:

この製品または機能は、それらのコンバージョン率指標またはそれらの目標を達成することを期待しています。

製品の全体的なプロセス:

Visio、Axure (Axure で描画されたフローチャートは非常に醜いです)。

一般的に、単純な要件の場合は、主要なビジネス フローと論理的な関係フローを表現すれば十分です。しかし、複雑なビジネスの場合は、製品や機能に関係する主要なプロセスを描き出す必要があります。このプロセスの目的は、主にフロントエンドとバックエンド間の論理的な関係とデータ構造を明確に表現することです。一方で、開発者がビジネスとデータフローを理解するのに便利であり、他方では、製品担当者が独自のニーズのビジネスロジックを整理するのにも便利です。それはその後のR&Dとのコミュニケーションに役立ちます。

プロセスの具体的な数は、ビジネスの複雑さによって異なります。一般的には、コアプロセスのみを描画する必要があります。

• フロントデスク: 主にやり取りとデータフロー。
• バックステージ: 主にビジネスロジックの判断とデータフロー。

フロントエンドプロセスとバックエンドプロセスを組み合わせることで、フロントエンドモジュールとバックエンドモジュールがどのように結合されているか、データがどのように保存、抽出、処理、分析されるかを明確に把握できます。

機能フレームワーク:

Mindjet Minmanager と Xmind で描画されたフレームワーク図は非常に醜いです。

フレームワーク図の重要性は、ビジネスを閲覧または理解する人々が、機能の機能ポイント間の論理的な関係を完全に理解できるようにすることです。同時に、優れたフレームワーク図があれば、PM は全体の基礎に立ち、担当する製品の全体計画を立て、プラットフォームビジネスを支えるフロントエンドとバックエンドの機能を把握することができます。

• 製品アーキテクチャ:フロントエンドとバックエンドのさまざまなシステムと管理モジュール間の論理的な関係。通常、これはビジネスに非常に精通したビジネス アーキテクトと上級製品ディレクターによって構築されます。各インターフェースをどのように接続し、結合するかが関係します。
• 機能アーキテクチャ:担当する製品または機能のフロントエンド機能とバックエンド機能間の論理的な関係。簡単に言えば、製品または機能のフロントエンドとバックエンドです。より広い意味では、システムに含まれる機能ポイント間の結合です。
• 機能フレームワーク:機能ポイントに含まれる論理的な関係。
• 機能構造:機能ポイントに含まれる論理的な関係。

「アーキテクチャ、フレームワーク、構造」の違いは、ビジネスの規模によって異なります。しかし、何であれ、そのパフォーマンスの原則は同じです。分解された機能点がどのようにつながっているかという機能構造関係を明確かつ簡潔に表現すれば十分です。

アーキテクチャに関しては、「機能分解とユーザー指向」を盛り込めば十分です。さらに深く掘り下げていくと、「アプリケーションオブジェクト、BI分析（BI要件も書き出す）、システム統合…」と分けることができます。その後、BIデータに基づいて製品バージョンを反復して最適化することができます。

オブジェクト指向

製品または機能が主に対象とするユーザーのタイプを表現します。ユーザーが誰で、どのような権限を持っているかを明確に表現するだけで、個々の機能設計にも大いに役立ちます。

応用

この機能はどのアプリケーション端末またはバージョンで起動する必要があり、その後の業務引き継ぎを容易にするために明確に記述する必要があります。

用語集

この文書に含まれる奇妙な単語のいくつかを説明することは非常に重要です。一部の PM は、非常に単純なコンテンツを非常に印象的なものとしてパッケージ化し、理解しにくいものに見せようとします。実際、彼らは単純なことをしているだけなのですが、読む人にとっては苦痛です。PRD を読むと、「これはいったい何を表現したいのだろう?」と思うでしょう。

参照ドキュメント

この機能に関して参照される文書は、後続のビジネスおよび研究開発関係者によるレビューを容易にするためにここに添付されています。

機能の説明は明確に記述できますか?そうであれば、開発者が欠陥を見つけることを心配する必要はありません。機能ポイントを完全に説明するにはどうすればよいですか? 3 つのポイントに焦点を当てます。「機能は誰ですか? 機能はどこから来ますか? 機能はどこに行くのですか?」

同時に、機能要件は主にコア機能とその他の機能に分けられます。コア機能であっても、その他の機能であっても、次の要素で構成できます。

• 関数名
• ユーザー指向
• ユースケース図 (Axure、モック (モバイルデバイスでのアジャイル開発に適しています))
• 前提条件
• 事後条件
• 機能説明
• 詳細な説明

具体的な機能説明内容は、業務の複雑さ（機能ポイント）に応じてフィルタリングされて説明されます。全部書いても、全部書かなくても構いません。ただし、どの方法を使用する場合でも、ドキュメントを閲覧する参加者にビジネス価値を完全かつ明確に整理して伝えることが目標であることを忘れないでください。

機能名（私は誰ですか）

システム内でのこの機能の名前。

ユーザー指向

この機能の対象ユーザー。 (フォアグラウンドでは関数の参加者は少数ですが、バックグラウンドおよびエンタープライズ レベルのアプリケーションでは関数の参加者は多数になります)

ユースケース図

プレゼンテーション層の機能を表現する論理図。従来のユースケース図、または簡略化されたプロトタイプ図やフローチャートになります。

前提条件（出身地）

この機能を使用する前提と論理関係。会社が大きくなると、各開発者は自分が担当する業務についてのみ記述するようになるので、開発者間のつながりを円滑にするために、各モジュールのソースを明確に表現する必要があります。

事後条件（そこに行くよ）

この機能を使用することによるビジネス機能およびデータ機能への影響と結果。

機能説明

この機能が達成する必要のあるビジネス価値または目的を説明します。

詳細な説明

「どうやって来て、どうやって行くのか」という機能を明確に表現します。コンピュータロジックに変換するということは、ページのレイアウトや操作ロジックを詳しく説明するということです。一般的に言えば:

• フロントエンド:主にフィールドとインタラクション ロジックで構成されます。
• バックステージ:主に判断ロジック、リストフォーム、クエリ条件、インタラクションロジックで構成されます。

その他の機能の目的は、機能の説明がこの製品機能の中核業務を対象としているのに対し、その他の機能は他の機能の変更を引き起こしたり、変更を必要とする業務を対象としていることです。関数の説明により、開発者はコア部分を明確に理解でき、他の関数により、開発者はコア以外の部分を明確に理解できます。

その他の機能は主に以下の内容で構成されています

その他のインターフェース

他のシステムによって生成された「フィールドとビジネスプロセス」について説明します。この製品またはビジネスは、フロントエンドとバックエンドの非メインプロセスモジュールに影響を与えます。

システムリスク評価

現在設計されている機能の欠陥と注意点は何ですか、そして将来の機能拡張でこれらの問題をどのように解決しますか?

その他の要件

コアではない機能ポイントについて詳細な説明を提供します。たとえば、フィルタリングする必要があるキーワードや、列フィールドの追加などです。

上記の内容を通じて、担当する製品や機能、業務内容、機能説明、その他機能を一般版の形で明確に表現することができます。これは製品要件ドキュメントの重要な部分であり、製品要件をより包括的かつ効果的に説明します。

同時に、PM の論理的思考力を訓練し、文章表現力とビジネス理解力を向上させ、需要管理全体において PM をより専門的にすることができます。担当する機能の論理的な関係とデータ フローの出入りを適切に制御できます。

形式に関係なく、私は 1 つの観点を主張します。それは、優れたテンプレートとはチームに適したものであるということです。現在、多くの企業が MVP の反復を実行する際に Axure + コンテンツ記述を使用しています。しかし、この形式では論理的な関係を明確に表現することが難しく、思考の抜け穴が多くなってしまいます。文書をアーカイブする場合、キーワードで検索することも困難です。しかし、これは確かに MVP の反復に適しており、問題が発生した場合にも簡単に修正できます。この方法は、完全なプロジェクト プロセスを備えたエンタープライズ プラットフォームに適しています。

アジャイル開発の概要としては、フローチャート + 機能フレームワーク (機能ポイント) + Axure (プロトタイプ図) という流れで、コアビジネスフローから始めて、徐々に反復しながら機能を完成させていくという流れに慣れています。このプロセスによりドキュメントも完成します。

ただし、要件定義書の作成やバージョン管理を EXCEL で行う企業もあります（これも良いです）。

しかし、初心者としては、複雑なものも書けるし、簡単なものも書けるということを覚えておく必要があります。しかし、もちろん、最初に簡単なことだけを書いていたら、一生簡単なことしかできません。

真実は単純です。単純なことは難しいが、複雑なことは簡単だ。複雑なトレーニングと要件を経た後でのみ、何度も簡素化することができます。

著者: Daoye、WeChat: ftl_keen。

この記事はもともと @倒爷 によって Everyone is a Product Manager に掲載されました。無断転載は禁止です。