PRD文檔究竟該怎麼寫，你寫的有可能是錯的

在分享今晚的內容之前，我先跟大家討論一個問題，產品經理為什麼要寫需求文檔，當然這個問題在我上周面試一位剛入職的產品經理的時候也曾問道，所以作為產品經理我們自己必須要清楚什麼是需求文檔，為什麼要寫它。

繼續我們的話題，產品經理為什麼要寫需求文檔，首先我們將這個問題拆分一下，為什麼寫，寫需求文檔是方便讓我們的項目經理、程序、設計師、測試工程師、運營、市場，包括我們的老闆等相關人員知道我們的產品要做成什麼樣子，產品需求文檔是對商業需求文檔和市場需求文檔通過產品的角度，用產品經理的專業知識進行更專業化、具體化的描述，將概念化的文檔轉化為圖形化的一個重要文檔，同時寫需求文檔的一個重要目的是讓我們的產品設計更加合理，減少疏漏提高項目的開發周期，開發效率。

以上內容是對為什麼要寫需求文檔這樣一個目的、概念進行了一個概述，下面我們再來分析，需求文檔究竟該怎麼寫。

我身邊的產品經理曾抱怨，自己寫了一百多頁的需求文檔，我們程序根本不按照我寫的需求來實現，最終上線的產品，很多流程都走不通，用我自己的話來講，我這位產品經理朋友可能遇上了富有想像力的程序。這也是我接下來跟大家討論的第二個話題，我們的程序究竟想要一份什麼樣的需求文檔。這裡為什麼要強調程序，因為產品的最終形態是有程序來實現，所以我們的需求文檔一定要讓程序看懂。

這裡我將程序分為了3個等級，分別是高明的程序、富有想像力的程序和坑爹的程序。

高明的程序已經具備了產品思維，當你給他一個需求的時候，他會協助你一起分析需求，理清楚這個功能要達到一個怎麼樣的程度，讓什麼樣的用戶來使用更方便、易用、實用、好用。遇上這樣的程序，產品經理都不需要寫需求文檔，你可能只是畫畫流程圖、原型圖，最終上線的產品跟產品經理想像的幾乎無差異而且還會超出產品設計時的期望。

富有想像力的程序他們偏向於圖形化的東西，他們在看需求的時候擅長看信息結構圖、業務架構圖、原型圖，對於長篇文字他們懶得看，所以遇上這種類型的程序，我們盡量多畫圖，對於一個比較長的需求，我們儘可能用一兩句話講清楚，細節部分多用圖形來描述。

坑爹的程序，為什麼是坑爹的程序呢，因為你給他需求稍不留神去盯任務，去跟著測試，他就會實現出來一個用起來相當吃力的功能，比如保存完不刷新頁面，返回要連續點兩次，跳轉會到達錯誤的頁面等等，遇上這樣的程序只能怪產品運氣差，跟這樣的程序協作，在過程當中一定要流程化，包括對產品功能的敘述不但用圖畫出來，還要用詳細的文字來敘述清楚，如果稍不留神忽略了一個細節，他們會首先想辦法把邏輯串通，只有在串不通的情況下，他們才會找產品，所以遇上這樣的程序是比較危險的，今天做什麼明天做什麼我們一定要盯緊，對於當天完成的任務當天要確認，所以我認為遇上這樣的程序是比較坑爹的。

以上我是對程序進行了等級劃分，那麼我們的需求文檔究竟有沒有必要寫，如果寫究竟應該要怎麼寫，那我們要做到的第一步就是去了解我們的程序是高明的程序、富有想像力的程序還是坑爹的程序。

寫需求文檔，我常用到的工具是Axure,因為Axure本就有強大的文檔編輯能力，而且還可以生成網頁，所以我的做法是將Axure裡面的文檔生成網頁，上傳到只有內網可以訪問的伺服器上，我將模塊分為了產品、競品、測試、工作動態和需求提交五個模塊，點擊產品下拉菜單，選擇相應模塊，進入需求詳情，就能看到該功能的需求描述、用例圖、流程圖、交互原型等，所以協作起來十分方便。工作動態主要記錄團隊內人員當天要做的事情，需求提交我在表單大師創建了表單，內部人員可以在上面提需求。

下面我們就來說說需求文檔的內容，究竟該怎麼寫需求文檔。產品經理為什麼要寫需求文檔，首先我們將這個問題拆分一下，為什麼寫，寫需求文檔是方便讓我們的項目經理、程序、設計師、測試工程師、運營、市場，包括我們的老闆等相關人員知道我們的產品要做成什麼樣子，產品需求文檔是對商業需求文檔和市場需求文檔通過產品的角度，用產品經理的專業知識進行更專業化、具體化的描述，將概念化的文檔轉化為圖形化的一個重要文檔，同時寫需求文檔的一個重要目的是讓我們的產品設計更加合理，減少疏漏提高項目的開發周期，開發效率。

2、文檔的版本歷史，文檔的版本歷史需要寫清楚文檔的版本號、修改原因、修改日期、修改人、修改原因和確認人；

3、目錄，方便我們的閱讀人員快速找到自己所要看的內容；

4、引言，對該產品的一個整體概述、產品的目標、產品的藍圖規劃，我們的產品要做成一個什麼樣子；

5、需求概述，主要描述我們的產品滿足用戶什麼樣的需求，我們的用戶有什麼樣的特徵，我們產品對運行環境的要求，設計和實現的上的要求規範、項目計劃和我們開發過程中可能會遇到的風險；

6、功能需求，主要描述我們產品當中不同功能的不同用途，業務規則，比如我們的這個功能要做到什麼程度，什麼樣的用戶來使用，在什麼樣的場景下，解決用戶什麼樣的問題，功能需求還包括用戶用例圖、流程圖、界面功能圖和交互原型圖；

7、可選方案，為我們產品準備兩個或兩個以上的備選方案，不至於產品的發展陷入困境而不知如何處理，備選方案可以從團隊的人、財、物、事、以及對自然災害、政策原因等多方面來考慮；

8、效益成本分析，比如我們要做這個產品估計要多長時間來完成，需要多少人、需要多少資金，最終要達到怎樣的指標才算合格，包括做一個小功能的預估分析；

9、整合需求，比如我們需要跟合作夥伴合作開發某個功能，或者是內容的置換、用戶的置換等通過合作來產生更高的商業收益；

10、測試需求，對測試人員的能力要求、內側人員的要求，測試規範的制定，以及測試出問題以後怎麼解決，怎麼確認，不至於在測試過程中出現不必要的問題；

11、非功能性需求，包括對產品的運行速度、用戶安全、用戶隱私、產品的可靠性、易用性、維護性、可移植性、擴展性、可替換性等需求，對產品的營銷需求、運營需求、財務需求、法務需求、使用幫助、問題反饋等需求；

12、運營計劃，當我們產品上線後怎麼來引流，引流的途徑有哪些，以什麼樣的方式來引流，引流進來以後怎麼將我們的用戶促活、維繫、轉換、付費、持續付費，以及做多大規模的活動運營等；

13、版本規劃，版本規劃主要描述我們當前版本計劃做什麼內容，需要多少人來做，做的過程中怎麼來協作，協作流程是怎樣的，以及我們下個版本計劃要做什麼。

今晚的內容就分享到這裡祝大家工作愉快，原文首發於我的個人微信公眾號產品精益講堂，個人微信yichenbz,個人網站需求分析研習社，QQ交流群：489899046，歡迎交流謝謝！