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

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

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

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

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

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

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

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

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

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

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

1、文檔的命名和編號，如V1.0,V1.1；

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

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

4、引言，對該產(chǎn)品的一個整體概述、產(chǎn)品的目標、產(chǎn)品的藍圖規(guī)劃，我們的產(chǎn)品要做成一個什么樣子；

5、需求概述，主要描述我們的產(chǎn)品滿足用戶什么樣的需求，我們的用戶有什么樣的特征，我們產(chǎn)品對運行環(huán)境的要求，設計和實現(xiàn)的上的要求規(guī)范、項目計劃和我們開發(fā)過程中可能會遇到的風險；

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

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

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

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

10、測試需求，對測試人員的能力要求、內側人員的要求，測試規(guī)范的制定，以及測試出問題以后怎么解決，怎么確認，不至于在測試過程中出現(xiàn)不必要的問題；

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

12、運營計劃，當我們產(chǎn)品上線后怎么來引流，引流的途徑有哪些，以什么樣的方式來引流，引流進來以后怎么將我們的用戶促活、維系、轉換、付費、持續(xù)付費，以及做多大規(guī)模的活動運營等；

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

今晚的內容就分享到這里祝大家工作愉快，原文首發(fā)于我的個人微信公眾號產(chǎn)品精益講堂，歡迎交流謝謝！