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

當下互聯網產品迭代的速度越來越快，大家都在追求小而美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協議。