鵝廠產(chǎn)品經(jīng)理手把手教你6步寫出5星需求文檔

需求文檔（PRD）是產(chǎn)品經(jīng)理與項目成員之間的溝通媒介，移動互聯(lián)網(wǎng)時代，產(chǎn)品上線迭代節(jié)奏非?？欤环葸壿嬊逦乙c分明的需求文檔可以讓成員之間的溝通更為高效；同時，產(chǎn)品需求文檔的撰寫，也能很大程度上看出產(chǎn)品經(jīng)理的專業(yè)素養(yǎng)和水平。那么，最為經(jīng)濟化高性價比的需求文檔，應該如何撰寫呢？

首先，我們需要知道需求文檔的存在價值是什么？

1、確保需求思考的全面性

產(chǎn)品經(jīng)理在需求落地過程中，如果沒有真正落實到對全流程細節(jié)的仔細斟酌，很容易出現(xiàn)細節(jié)遺漏或需求不合理，所導致的結果就是功能設計不完善，溝通模糊化，甚至導致需求的頻繁變更，多做無用功。不僅影響產(chǎn)品的上線規(guī)劃，還容易引起成員公憤。PRD的撰寫可在一定程度上確保產(chǎn)品經(jīng)理思考的全面性。

2、資料傳承

一款產(chǎn)品在其生命周期中，有可能經(jīng)由數(shù)個產(chǎn)品經(jīng)理之手，中間的優(yōu)化迭代改版，如果沒能及時記錄下來，往往到達下一個接盤者手上的時候，又得重新開始摸索一遍，極大降低了效率。因此，需求文檔的撰寫和變更記錄，能實現(xiàn)資料的有效傳承，方便后人迅速上手跟進。

3、存證

我們都知道，需求文檔不可能一成不變，在需求評審、實際開發(fā)過程中，往往有大大小小的調整，需求變更后及時更新記錄，而非停留于口頭的需求邏輯敲定，方便后續(xù)搜索求證，避免遺忘。

6步寫出高性價比PRD

實際撰寫PRD時，采用的載體形式很多，如word、excel、在線協(xié)同工具、交互原型圖+標注等，但無論哪種形式的PRD，最終的目標都是最高效且最準確地將需求傳遞給開發(fā)。因此，一般不建議長篇大論贅述太多，這樣容易提高大家的閱讀和理解成本，我們只需保證準確表達出“開發(fā)同學需要知道的邏輯/內(nèi)容”即可。

一般而言，一份經(jīng)濟化的PRD僅需包含以下6個部分：變更歷史、需求簡介、框架結構&功能模塊(核心)、消息觸達相關、數(shù)據(jù)埋點相關、異常流。

具體應用時可再根據(jù)實際項目進行調整刪改。

1、變更歷史

可分為3個部分：更新時間、更新內(nèi)容（版本號、更新內(nèi)容描述、標注）、撰寫更新內(nèi)容的人。目的是記錄每一次需求的更新/迭代，方便項目成員了解方案細節(jié)，快速跟上節(jié)奏。該部分有兩個小技巧：

• a、版本號V x.x，對于大改動/大版本變動，用變更小數(shù)點前1位表示，如V1.0，V2.0；小更新用小數(shù)點后1位表示，如V1.1，V1.2
• b、正文更新部分標注上特殊標識，如加粗、標紅、底色高亮等，并在變更內(nèi)容中說明，便于團隊成員最快速找到更新點

2、需求簡介

主要包括需求背景和功能列表概覽（標注優(yōu)先級）。

需求背景是信息同步的一部分，團隊開發(fā)成員往往前期沒參與到市場調研、匯報等環(huán)節(jié)，該部分可幫助團隊成員了解項目背景、目標，并達成項目價值、上線時間等預期共識。

功能列表概覽則是為了讓開發(fā)同學對整體需求有一個完整的把握，適用于需求開發(fā)周期評估、需求完成checklist等場景。

3、結構框架&功能模塊

該部分是需求文檔的核心部分，囊括了產(chǎn)品方案的全局和細節(jié)邏輯，主要是向開發(fā)同學清晰且準確說明需求實現(xiàn)期望，盡可能覆蓋各類場景，盡可能使用案例/圖例輔助說明，盡可能使用邏輯性語言表述。該模塊可統(tǒng)分為全局結構和功能模塊兩大部分：

• a、全局結構

包括產(chǎn)品核心主路徑、各分支路徑的邏輯流程圖，闡述產(chǎn)品全局的路徑跳轉、閉環(huán)邏輯，方便全局性理解需求。如下全局邏輯流程圖：

• b、功能模塊

該模塊主要針對各分支路徑進行詳細的需求描述，落到產(chǎn)品層面，則是追求 “場景窮舉說透、邏輯到位可行”。以日期為例，方案中涉及的日期是工作日、節(jié)假日、自然日、交易日、還是非交易日，需要做到準確用詞無歧義。

為了盡可能簡單而清晰地表達，對于每個功能模塊，都可以嘗試從4個方面結合進行敘述：

• 1）應用場景：落實到產(chǎn)品上線時會遇到的各種場景，分別列舉。
• 2）頁面元素組成：對應于上述的某個場景，該頁面包括了哪些元素，頁面布局如何。
• 3）觸發(fā)條件及響應效果：相當于輸入條件和輸出結果，在什么樣的時間節(jié)點、觸發(fā)了什么樣的條件、會產(chǎn)生什么樣的反饋/響應結果。
• 4）舉例示意：通過實際例子，或附上具體的交互圖輔助說明，提升上述內(nèi)容描述的可理解性。

如對于某電商平臺而言，應用場景上大致有：

新用戶注冊、老用戶登錄、推薦流、搜索、下單流程（添加到購物車/直接購買）、訂單提交流程、結算流程、物流跟蹤、售后服務等具體場景。

具體到購買某款商品的單一場景上，頁面布局元素包括：商品圖片示意模塊、商品信息概覽（名稱、價格、月銷量、產(chǎn)地等）、商品參數(shù)介紹頁、用戶評價、店鋪介紹、更多推薦。還有吸底的加入購物車、立即購買、收藏、客服按鈕。

下鉆到該場景下的“加入購物車”這一動作而言，其觸發(fā)響應邏輯如下：

觸發(fā)條件：用戶點擊“加入購物車”按鈕；

響應結果：后臺將商品添加至用戶購買清單中，前端彈出告知彈層，告知用戶“商品已成功添加至購物車”。

4、消息觸達相關

消息觸達，可作為產(chǎn)品功能服務、推廣拉新、活躍/留存提升、流失召回的有效方式，主要渠道可包括公眾號、短信、app push、產(chǎn)品站內(nèi)彈層等。該部分在作為PRD的一部分時，為了避免邏輯遺漏，可套用6個元素做呈現(xiàn)：觸達形式、消息ID、觸達場景、消息模板示意、文案示意、跳轉路徑。

以電商平臺購買某款商品后用戶簽收的場景為例：

觸達形式：app push

消息ID：123456

應用場景：某款商品（xxx）物流已送達且用戶完成簽收

消息模板：已簽收，您在$store$購買的寶貝已于$date$順利送達，確認收貨可獲積分哦>> （$$內(nèi)為變量）

文案示意：已簽收，您在xx小店購買的寶貝已于4月15日順利送達，確認收貨可獲積分哦>>

跳轉路徑：點擊跳轉到該款商品的訂單詳情頁

5、數(shù)據(jù)埋點相關

產(chǎn)品上線后，產(chǎn)品經(jīng)理需要及時跟蹤上線效果并做優(yōu)化迭代，因此配合產(chǎn)品上線節(jié)點，數(shù)據(jù)的埋點也要同步ready。產(chǎn)品經(jīng)理需自身先明確該業(yè)務/功能的目標是什么，需用何種數(shù)據(jù)指標來描述衡量；體現(xiàn)在PRD中，則主要包括埋點位置、埋點ID、觸發(fā)場景。

如統(tǒng)計互金平臺某款理財產(chǎn)品的點擊率和申購轉化率，埋點位置會體現(xiàn)在產(chǎn)品曝光頁面、買入按鈕、買入成功頁面；

ID包括點擊流ID（統(tǒng)計UV、PV）和渠道號（統(tǒng)計申購人數(shù)、金額等信息）；

觸發(fā)場景則是理財產(chǎn)品曝光、用戶點擊申購、申購成功時分別統(tǒng)計數(shù)據(jù)并上報。

6、異常流

PRD的撰寫，不僅要覆蓋產(chǎn)品功能的正常邏輯和場景，還需全面考慮到產(chǎn)品上線可能出現(xiàn)的異常情況和相應的應對方案。提前預見可能有的坑，才能避免產(chǎn)品上線后真的踩坑……

舉個栗子，當前很多產(chǎn)品設計時會走情感化路線，如允許用戶自定義名稱、自定義圖片上傳。在此過程中，用戶輸入了非法字符（如emoji表情）時，是提示用戶修改，還是允許正常顯示？當用戶輸入的詞匯包含敏感詞，是不允許提交，還是直接做過濾屏蔽處理？

更多異常流情況如弱網(wǎng)環(huán)境、訪問超時、刷新/獲取信息失敗、信息缺省、權限獲取失敗等，都需要根據(jù)具體的產(chǎn)品case體現(xiàn)在PRD中。實際撰寫時可按“異常流描述+處理方案“的搭配方式呈現(xiàn)。

附上PRD撰寫6大模塊checklist，方便大家后續(xù)參考：

需求管理三大原則

除了PRD，產(chǎn)品經(jīng)理在項目實操過程中還會遇到需求管理的相關問題。如同項目多個需求，甚至不同項目多線程進行的情況，難免會產(chǎn)生需求沖突。在需求管理上，怎么讓“高效有序”代替“慌亂焦慮”，本質上，即是需求的優(yōu)先級如何權衡？用什么原則標準權衡？回答這樣兩個問題，可以從以下三個方面考慮：戰(zhàn)略定位、用戶影響范圍、實現(xiàn)成本。

1、戰(zhàn)略定位

經(jīng)濟基礎決定上層建筑，戰(zhàn)略定位決定發(fā)力方向。每一階段的需求方向形成跟該階段整個團隊的戰(zhàn)略目標息息相關。作為產(chǎn)品經(jīng)理，要明確部門階段性發(fā)展的目標，并將其落地到自身的業(yè)務需求中來，如今年部門的目標是創(chuàng)收，則需求大方向、資源等都會相應地往商業(yè)化產(chǎn)品傾斜。無論是怎樣的產(chǎn)品需求，都應該向戰(zhàn)略方向靠攏，并由此來權衡項目優(yōu)先級。

一般來說，對于某些戰(zhàn)略型的跨部門合作項目，同樣需要把需求優(yōu)先級提升。一方面，既然合作達成，說明該需求項目對雙方而言都是符合目標預期的；另一方面，當前項目上線的進程和效果，是后續(xù)長期合作共贏的前提和基礎。

2、用戶影響范圍

衡量需求優(yōu)先級，離不開重要性和緊急性的判斷。

重要性，可從以下三個原則綜合來看：

a、主干邏輯優(yōu)先

如電商類型產(chǎn)品，用戶從挑選商品，到下單，到支付，即是其主干流程，該流程的任何問題，都會影響到業(yè)務的整體，需要優(yōu)先考慮。

b、業(yè)務目標優(yōu)先

產(chǎn)品需求，需要對業(yè)務效果負責，需求上線后數(shù)據(jù)效果反應不好，是每個人都不愿意看到的。因此，需優(yōu)先處理“可產(chǎn)生最佳效果，對業(yè)務目標有最大化貢獻”的需求，即核心driver，在有限的資源基礎上，優(yōu)先滿足對業(yè)務目標的最大化貢獻。其次，才是其它“可產(chǎn)生效果，提升效用次之”的需求。

c、用戶體驗優(yōu)先

理想狀態(tài)下，要求產(chǎn)品能滿足所有用戶的需求，體驗絕佳。但因用戶千人千面（即使定位某一特定用戶群體）、客觀資源條件等問題，實際情況往往需要對產(chǎn)品功能有所取舍，此時我們應該優(yōu)先保證絕大部分用戶的體驗，大致原則是：對核心/大部分用戶有影響的＞對較小部分用戶有影響的＞一般產(chǎn)品使用體驗問題＞錦上添花需求

而從問題解決版本的緊急性來看的話，可以有以下原則：線上bug＞當前有一定不良影響的需求＞短時間內(nèi)可控，解決后會有較為明顯的積極影響的需求

3、實現(xiàn)性價比

大部分需求產(chǎn)生時，更多的從用戶角度/業(yè)務角度出發(fā)，尋求效果的最大化，不會被實現(xiàn)成本、實現(xiàn)難度束縛住思維。但是，當需求逐漸成型，實現(xiàn)的性價比，就要同步考慮了。衡量其可實現(xiàn)性、實現(xiàn)成本損耗、資源現(xiàn)狀及其性價比；基于現(xiàn)有資源的基礎上，再決定產(chǎn)品需求的最終方案（照常or調整），以達到性價比最高，并擇優(yōu)優(yōu)先實現(xiàn)。例如：方案A和B都是可為業(yè)務用戶盤子帶來快速增長的核心渠道，但方案B的實現(xiàn)周期需要2周，方案A最快1周即可上線，則權衡性價比之下，優(yōu)先級會A＞B。

掌握PRD快速且高效的撰寫能力，產(chǎn)品經(jīng)理可根據(jù)所在業(yè)務歸納沉淀下相應checklist或模板，形成該過程的SOP；同時在多需求纏繞的時候，形成自身一套優(yōu)先級和性價比權衡標準，可有效提升自身效率，在多需求中更游刃有余。

也許，產(chǎn)品經(jīng)理就是雕刻家，在有形的章法和無形的力度弧度把控中游走，深鐫淺刻，終將雕刻出屬于自己的大衛(wèi)像。

文：曾銳林@騰訊大學（tencent_university）

首席增長官推薦：

《工具型產(chǎn)品運營如何能促進用戶增長？》
《增長黑客如何基于心理賬戶、效應及決策，運用在股票App的產(chǎn)品設計中》
《做內(nèi)容怎么能不懂用戶增長，增長黑客了解一下？》

更多精彩，關注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術和數(shù)據(jù)來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實現(xiàn)低成本甚至零成本帶來的有效增長…