做產品經常會寫prd，但是如果沒有一套完整的寫作思路和框架，寫出的prd質量就不會太好，導致遺漏重要資訊，在專案過程中被開發、前端、測試吐槽。趁這個週末有空，來梳理下一下寫prd的邏輯。
prd為product requirement document的簡稱，其中文翻譯為：產品需求文件。該文件是產品專案由「概念化」階段進入到「圖紙化」階段的最主要的乙個文件。當然，這個定義針對的是乙個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標使用者、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等，本文主要討論的是戰術部分。
prd的主要使用物件有：開發、測試、專案經理、互動設計師、運營及其他業務人員。開發可以根據prd獲知整個產品的邏輯；測試可以根據prd建用例；專案經理可以根據prd拆分工作包，並分配開發人員；互動設計師可以通過prd來設計互動細節。prd是專案啟動之前，必須要通過評審確定的最重要文件。
產品經理的prd，就像建築設計師的設計圖紙，是整個設計和思考的結晶，同時，也是思考過程呈現。《使用者體驗要素》作者在書中有一句很經典的話：「文件不能解決問題，但是定義可以」，這也是prd的另乙個重要的作用：定義產品需求，在團隊內達成共識。
寫prd，其實就是乙個產品的業務需求分析過程，最近在看一本書，叫《火球uml大戰需求分析》，裡面提到了需求分析過程，作者的這個需求分析思路是基於傳統軟體/系統，但是我覺得這種思路是相通的，可以應用於所有產品。我根據這個思路，做了部分改良，形成了以下的邏輯：
整理產品結構
分析核心業務流程
分析及整理用例
分析及整理非功能性需求
整理需求文件並評審
就像修建一座商場，在設計的時候，需要考慮整個商場的結構，商場包含美食區、服裝區、百貨區、休閒娛樂區等，然後每個區域又可以按商家或型別細分。產品也是這個道理，產品是由功能和內容組成，這些功能和內容，按照某種緯度，組成頻道/模組，最終形成產品的整體結構。由於產品的結構一般比較大，這裡僅以產品結構中的個人中心這個模組為例：
產品結構一般通過mindmanger梳理。需要注意的是，產品結構≠頁面結構，產品結構是邏輯上的，頁面結構是物理上的，至於具體的結構和方法，可以參看《使用者體驗要素》一書。
每個產品，都會有幾個核心的業務，分析並梳理出幾個核心業務流程，可以幫助產品經理了解產品邏輯。筆者做的是b端產品，核心業務流程一般都會涉及到多個角色，而c端產品，核心流程的使用者則比較單一。涉及到多個角色的業務流程，可以使用泳道圖，單個角色可以使用普通的活**。另外，在分析業務流程的時候，還可以配合使用狀態圖和順序圖，具體使用什麼工具，視情況而定，重點是梳理清楚邏輯。
這個步驟是更具體，也很重要的的一步，前面2個步驟確定了範圍和流程，這一步針對流程上的某個節點來具體描述。以會員中心→內容管理這個模組為例，這個模組下面包含的用例有：
新增文章
修改文章
刪除文章
檢視文章列表
檢視文章詳情
現在，就可以按照上面這個列表，來一一的描述用例。乙個完整的用例應該包含以下主要內容：
其實，關於需求怎麼描述，沒有完全正確的方式，只有最合適的方式，具體因人而異。《啟示錄》一書作者就建議描述產品需求只需要高保真原型+注釋就可以，完全不需要文件，以下是書中的一些觀點：
產品說明（需求）文件的主體應該是高保真原型，由它體現產品的功能需求、資訊架構、使用者體驗、互動設計、視覺設計。高保證原型最大的優勢是可以用於測試。詳細內容可以參看這本書的第十八章，「重新定義產品說明文件」一節。與其花幾個星期撰寫冗長的word文件，既沒人讀，也無法測試，還不如和設計師一起建立原型。
不管是用例描述還是功能描述，規則都是最重要的一部分，這裡主要講一下如何描述能完整無誤的闡述需求並讓閱讀者看懂。規則的描述，主要是從3方面思考。
資料規則。主要指頁面從資料庫調取資料並展現的規則，比如檢視文章列表這個用例，需要描述文章列表頁面展示哪些字段、每個欄位的型別及長度、列表的排序規則重新整理頻率等。
互動規則。介面上存在互動的元素，一一枚舉並說明，比如鏈結、按鈕、滑動、下拉的具體互動規則及異常處理。另外，整個場景由於網路問題、系統問題導致的異常也需要說明。
非功能需求涉及比較廣，比如產品的效能需求，訪問速度達到多少、最大能支援多少人同時訪問；比如設計需求，產品要設計成小清新風格還是成熟穩重的風格等；還比如統計需求，產品要統計哪些字段，形成哪些報表等。這個可以根據具體的需求來描述。
當完成以上4個步驟以後，整個產品的邏輯已經很清楚了，再將產出物彙總，就可以整理出需求文件。文件出來後，需要和專案相關的負責人一起評審，評審確認通過，就可以進入產品的實施階段。實施一般是由專案經理負責，但是很多公司沒有配備該崗位，這就要求產品經理擁有專案管理的能力，來推動產品順利實施並上線。
目前市面上各種需求文件，五花八門，千萬不要試圖找到乙個100%完美的文件模版，prd文件，只有最合適的，沒有最好的，每個人所在的公司背景都不一樣，大公司要求文件規範，細節到位，小公司可能只需要記錄關鍵資訊，剩餘的靠口頭溝通，甚至都不需要文件。還有些人，直接通過axure描述產品需求。
prd文件，最重要的還是以上的整個思考和整理的過程，當以上步驟梳理清楚後，文件只是水到渠成的產出。我的原則是，只要內容清楚，文件格式沒那麼重要。
產品經理需要做產品的戰術執行和戰略計畫工作，我認為這兩個工作是個遞進的關係，當你能把產品的戰術執行到位，真正的把一款產品從0到1做出來的時候，再去思考產品的創新、規劃……產品才容易落地，否則，永遠是紙上談兵。這也是為什麼很多產品助理剛開始到公司都只接一些功能模組的設計實施工作，而不是一來就做戰略方面的工作。
產品需求文件到底該怎麼寫？
博主作為一名產品小白，也被產品需求文件折騰的死去活來，網上也難找乙個完美的模板。那麼，作為產品需求文件，到底該怎麼寫，才能讓設計讓開發都能清晰的了解呢？產品需求文件，主要目的是說明需要開發的產品功能 ui 互動 效能 運營等要求。產品需求文件質量的好壞，在很大程度上不僅直接影響著研發部門是否可以明確...
PRD產品需求文件概要
prd概念 prm就是product requirements document的簡稱，也就是產品需求模型。一般來說乙個產品會伴隨有市場需求文件 market requirements document 產品需求文件 prd 有些公司會把mrd和prd兩個文件合併為prm文件。prd文件需要包含的內...
產品需求文件 PRD（上）
深刻理解三大文件的寫作目的與應用場景 理解並掌握prd文件的用途與作用 理解並掌握prd文件 寫作思路 寫作方法 寫作格式 prd文件向上是對mrd內容的繼承與發展，向下則是要把mrd文件裡面的各種理論要求 技術化，向研發部門與設計部門說明產品的功能和效能要求。prd文件是產品文件中最底層最細緻的文...