編輯導語：産品經理的日常工作是繁雜的，要與各種原型圖和需求說明書打交道，還要了解用戶需求，對接開發。因此，掌握一個好的工作方法尤為重要。本文作者建議在原型圖的基礎上寫産品需求文檔，從而提高團隊的整體工作效率。

當下互聯網産品疊代的速度越來越快，大家都在追求小而美MPV的産品開發方式，以應對市場的快速發展和變化。

傳統的産品經理既要用Axure畫原型圖，又要用word輸出産品開發需求說明書（PRD），費時費力，到最後開發、測試的小夥伴不一定喜歡看，因為既要看原型圖又要開PRD文檔還有各種其他産品文檔，顯得很麻煩。

結合這個痛點，我建議推崇在原型圖的基礎上寫産品需求文檔，這樣不僅為産品經理節省了時間，開發、測試也不用看那麼多的文檔，整體提高了團隊工作效率。

首先打開原型式産品需求文檔，整個文檔界面頂部分成了黑色的一級導航和紅色的二級導航區域構成。

如下圖，黑色一級導航可以選擇不同的目錄大綱，每個一級導航關聯多個二級導航菜單，每一個二級導航菜單下面就是我們産品需求文檔的具體内容了。

原型式需求文檔的一級導航分為：産品介紹、思維導圖、原型圖、非功能性需求，四個模塊，每個模塊下面關聯了多個子菜單模塊，現在開始詳解二級導航的菜單。

一、産品介紹

1. 産品說明

主要作用是幫助大家更清晰的了解需求背景和目的，為什麼要做？怎麼做？大家可以通過閱讀此文檔清晰了解産品需求的整條線，如下圖所示。

2. 功能清單

主要作用是告訴大家當前版本涉及到哪些需求點、功能點，每個需求點的大概需求描述是如何實現的，設計邏輯是怎樣的。

3. 修訂曆史

主要作用是記錄需求對外評審後，每次修改了需求中的哪些頁面的什麼地方，哪個字段、哪個邏輯等等，并在頁面中記錄修改前的邏輯是怎樣的，修改後是怎麼的。

修訂曆史記錄列表支持跳轉至修改詳情頁面，以方便大家知道和快速查看。後期我将單獨寫一篇原型式需求文檔寫作規範再詳細介紹。

4. 版本介紹

主要是定義當前的版本号、版本上線時更新發布的内容，以及上線更新的方式、應用商店截圖是否更新，進行說明。

二、思維導圖

該模塊主要是幫助大家了解産品的整體系統設計架構、功能、信息結構，通過圖表的形式梳理産品邏輯、流程。

該模塊不僅限于這4個内容，一切利于大家理解産品的圖表都可以呈現在此模塊中，例如：時序圖、泳道圖、用例圖、關系圖、狀态圖、行為數據圖、操作流程圖、财務資金明細表等等。

1. 功能結構圖

是以功能模塊為類别，介紹模塊下其各功能組成的圖表，功能模塊則可能是完成某一個任務的一組程序，功能點可能是一個程序中的某個處理過程。

方便大家對功能結構形成一個直觀的認識，防止在産品需求轉化為功能需求的過程中出現功能模塊和功能點缺失的現象。

2. 信息結構圖

是脫離産品的實際頁面，将産品的數據抽象出來，組合分類的圖表。促使大家在查看産品複雜的信息内容時是否會出現遺漏、混亂、重複的情況，且可以作為開發工程師建立數據庫的參考依據。

3. 業務流程圖

是業務需求在不同的階段各個功能模塊之間信息流向交互的過程，以圖表的形式呈現。它的作用是幫助大家全面了解業務處理的過程，分析業務的合理性，幫助開發拟出可以實現計算機的處理部分。

4. 功能流程圖

是具體的某個功能點系統對該功能的處理流程，該流程更多的時候可能會放在當前功能點需求文檔一起呈現，更利于大家閱讀理解的連貫性。

5. 時序圖

是反應了對象之間交互的順序，是前端與服務端消息傳遞、數據交互建模的依據，它能夠很好幫助開發理解産品功能如何實現，如何設計開發文檔。

三、原型圖

1. 業務規則

是通過一定的約束條件限制、控制、影響業務的行為。通過此内容大家可以清晰的看到整個産品中存在多少業務規則和限制條件。

2. 全局說明

用于說明整個産品線中碰到的全局性問題，說明某些頻繁出現在各種位置的同類信息。作用是方便大家對産品需求中有共性的需求點集中閱讀，也方便需求維護管理。

3. 原型圖頁面清單

是當前版本待設計、開發的所有頁面清單，大家可以通過此内容直觀的看到具體的開發任務，大家也是通過此内容查看每個功能、頁面具體的産品設計需求文檔。

4. 産品規範

分為交互規範、視覺設計規範以及其他說明，這裡其實跟全局說明有些類似，為了方便大家更好的理解和區分全局性問題與規範的差異，所以我們拆成了兩部分進行描述。

四、非功能性需求

非功能性需求是産品為滿足用戶使用、運營需要而必須具備的功能需求以外的需求。

它不僅限于以上4個内容，可能還包括安全性需求、易用性、可擴展性、可維護性需求、網絡需求、數據需求、接口需求、統計需求、服務端與客戶端交互需求等其他需求，此模塊我們隻要求以上4個内容作為基礎要求。

1. 數據埋點

是作為數據采集的一種方式，是為日後進行數據分析所具備的基礎。

2. 兼容性需求

是當前版本内容與曆史版本内容同在系統中工作不能産生bug，需兼容新舊功能的正常運行及曆史數據。

3. 性能需求

是從系統的數據性能、系統的并發性、響應特性以及結構特性來對系統的性能提出的需求。

4. 測試需求

是整理測試焦點（邏輯、數據、流程），明确測試焦點優先級，為測試小夥伴提供測試用例所需的功能信息。

最後想說一點，一份再好的《原型式産品需求文檔》也需要産品、開發、測試整個團隊的不斷磨合和适用，我将自己的産品經驗分享出來希望可以幫到大家，謝謝！

本文由 @燦爛千陽 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部