編輯導讀：需求文檔，是伴隨產(chǎn)品經(jīng)理整個職業(yè)生涯的東西。而寫需求文檔，就是最能體現(xiàn)產(chǎn)品基本功的地方了。要如何寫好需求文檔呢？本文將從三個方面展開分析，希望對你有幫助。

某大廠的CEO曾經(jīng)說過“練好基本功，能贏99%的事”，而寫需求文檔，就是最能體現(xiàn)產(chǎn)品基本功的地方了。有不少產(chǎn)品/運營童鞋抱怨研發(fā)不配合、態(tài)度不好、喜歡挑茬，如果你平時在工作中遇到過這些問題，學姐強烈建議把這篇看完，先琢磨下自己的需求文檔是否合格。

另外，雖然需求文檔在匯報、晉升答辯的時候幾乎用不到，但學姐可是聽說，不少互聯(lián)網(wǎng)大廠的高管會去翻閱需求文檔，來了解產(chǎn)品細節(jié)、考察一線童鞋們的基本功是否扎實，這時候如果文檔寫得不到位，可就尷尬了~

大廠產(chǎn)品專家手把手教你系列（一）：三步寫出好簡歷

大廠產(chǎn)品專家手把手教你系列（二）：行業(yè)調研和規(guī)劃

一、寫之前，先分類

在寫需求文檔之前，我們先要對本次寫的文檔進行正確地分類，畢竟一個做半年的需求和一個做半天的需求，在文檔上肯定會體現(xiàn)出差異。這就和我們在需求分析階段會先做用戶分層是一個道理（用戶分層學姐強調過很多遍啦，不了解的童鞋趕緊戳這篇），需求一般可以分為以下三類：

1. 大項目

有超過3個功能點才能實現(xiàn)的需求，就是一個相對完整的項目了，一般需要研發(fā)2個月以上。

舉個例子，學姐之前曾經(jīng)做過一個在訂單上加收1塊錢服務費的功能，雖然聽上去只是一丟丟（一句話需求啟動～），但卻會涉及到對整個交易流程的改造，C端會涉及到交易列表、商品詳情頁、訂單列表、訂單詳情、退款詳情等，B端會涉及到商戶通知、交易列表、對賬單等；除了業(yè)務方的研發(fā)，還會需要到優(yōu)惠中心、訂單中心、結算中心等各大中臺一起參與研發(fā)。而且每個功能點都沒有辦法拆分上線。

這類文檔的模版是最完整的，學姐會在第二章具體介紹。

2. 功能點

指可以單獨上線的功能點。

比如微信公眾號最近新增了“草稿箱”功能，寫到一半的文章可以保存，雖說從公眾號作者的角度來說這是一個比較大的改版，因為涉及到公眾號后臺最核心的功能——寫文章。但實現(xiàn)起來，只是加了這三個功能點：

• 寫文章時可以保存草稿或查看草稿
• 公眾號后臺的首頁新增“最近的草稿”模塊
• 公眾號后臺首頁左側工具欄新增“草稿箱”，點擊可以查看所有的草稿

其中后兩者完全可以等功能1上線了之后單獨上線。像這類需求就可以按照“功能點”去寫需求文檔，三個功能點合起來寫或者分開寫完全看產(chǎn)品對進度的要求。

3. 小優(yōu)化

這類需求可能是一些較小的用戶體驗提升、big fix、視覺優(yōu)化等，比如某個頁面上改一個按鈕之類。很多童鞋在寫這類文檔的時候往往是“一句話需求”，但其實這類文檔也會有側重點，要做到“麻雀雖小，五臟俱全”。

二、三段式寫PRD

搞清楚需求的3種分類后，我們就可以使用不同的模版了，學姐會根據(jù)三段式去詳細介紹PRD的每一部分：背景->內容->計劃（小優(yōu)化不需要）。

1. 需求背景

這是一個常見的扣分點，背景不寫或者寫得不好，這不就相當于追女生的時候上來就問她體重多少嘛（大家可以求一下研發(fā)小哥哥/姐姐的心理陰影面積）。這部分是每類需求都要寫的，絕不能省略哦。需求背景分為以下兩部分：

1）為什么要做（WHY）

首先我們要講清楚為什么要做這個需求，這里學姐提供1個經(jīng)典句式，那就是欲揚先抑。我們可以先說目前的問題，比如先列舉用戶痛點，再配一些數(shù)據(jù)，最后提出我們解決問題的方案，就能把故事說得比較順了，舉兩個簡單的例子大家感受下：

• 某某行業(yè)目前魚龍混雜，信息不公開透明，消費者的權利得不到保護，據(jù)行業(yè)報告顯示投訴率達百分之多少，因此，我們要搭建一個真實可靠的消費者評價體系
• 結算頁面是用戶完成交易的必經(jīng)頁面，目前其轉化率不到50%，競品/行業(yè)內標準是60%，因此需要優(yōu)化

這樣寫的好處是會讓其他部門的同事感同身受，畢竟其他人并不像你一樣這么了解這個行業(yè)的用戶和產(chǎn)品，這樣可以產(chǎn)生共情。

2）想要達到什么目標（WHAT）

預估做項目能達到的核心指標，最好把預估的過程也寫出來。一方面，“直接談錢”可以提升其他同事的成就感，讓他們更愿意積極參與；另一方面也是鍛煉自己作為產(chǎn)品/運營對數(shù)據(jù)的敏感性，像學姐因為估得多了，基本上每次的數(shù)量級都是非常準的，越來越接近真實數(shù)據(jù)。

比如，公司現(xiàn)階段的核心指標是交易額，我們想在訂單完成頁新增推薦模塊，其他業(yè)務線做這類推薦模塊的訪購率一般是2%，我們交叉推薦的行業(yè)客單價一般在100元左右，那么我們只需要把訂單詳情頁日均UV*2%*100元*就能算出每天新增的交易額了。如果預估的時候沒有什么可以參考的數(shù)據(jù)，你又是剛入職或者剛接觸這個業(yè)務，也可以找身邊一些資深的同事討論下，問問他們覺得是多少，然后取個中間值。

2. 需求內容

寫完背景之后可以進入正文了，也是三段式（我就套娃）：需求概覽->需求詳述->數(shù)據(jù)打點。

1）需求概覽

這部分其實就是闡明這個需求的scope，先給大家一個比較直觀的印象，不同類型的需求會有各自的寫法。

對于大項目，一定要把功能列表寫出來，因為項目的功能點往往很多，直接講功能點的話容易把別人繞暈，先要給大家一個whole picture。用表格形式，寫出每個功能點對應的頁面、平臺等，如果涉及到跨部門，最好把對應的（研發(fā)）接口人也寫上（也可以需求評審之后補充）↓

對于功能點，可以先簡單描述下每個功能點。如果是幾個功能點合并在一個文檔寫，那么可以把優(yōu)先級也標注清楚↓

對于小優(yōu)化，需求本身并不復雜，可能幾十行代碼就解決了。正因為這樣，研發(fā)在做的時候可能比較隨意，忽略一些小細節(jié)，比如到底是在哪個端、哪幾個頁面上，這時候我們就要盡可能直觀一點。如果需求很簡單的話，甚至可以在這個表格里就把需求詳述也一起寫了～

2）需求詳述

需求詳述這部分，不同的項目、功能點差異是比較大的（小優(yōu)化比較簡單，就不展開了），如果要說能用同一個模版去套，那就有點不負責任了。所以學姐抽象出了比較常見的2種維度對功能進行細分，不同類型需求對應不同的寫法，還會教大家作圖的步驟～

a）新增VS優(yōu)化

新增就是從0到1搭建功能，優(yōu)化就是從1到100。

對于新增，我們要把“新概念”定義清楚。比如新增加了一些頁面/狀態(tài)，它們定義是什么。比如草稿這個功能，就會新增“草稿箱”，這個頁面展示出了公眾號作者所有的草稿，定義清楚之后，寫文檔的時候統(tǒng)一措辭，這樣能確保大家都在一個面上溝通。再比如，不存在草稿詳情頁，只是在原來文章詳情頁新增了一個中間狀態(tài)，叫“草稿態(tài)”，點擊保存草稿后、發(fā)布文章之前，都是這個狀態(tài)。這樣對齊之后大家和研發(fā)的溝通就會比較順暢了，不容易產(chǎn)生誤解。

對于優(yōu)化，我們要強調的就是優(yōu)化后和優(yōu)化前的差異。比如做一個頁面優(yōu)化，我們可以直接放上對比圖，把調整的部分圈出來貼在需求文檔上，標清楚數(shù)字，然后再用文字描述對應的優(yōu)化，這樣研發(fā)就不用對著新的稿子“找茬”了。

b）側重前端頁面 VS 側重后端邏輯

很多人喜歡分B端和C端，對應不同的寫法。學姐倒覺得，寫文檔的時候不如看這個需求是側重“前端頁面”還是側重“后端邏輯”，因為這才是開發(fā)的邏輯，To B或To C其實是產(chǎn)品做需求分析的邏輯。

比如，剛剛提到的“新增1元服務費”就是一個端到端的需求（B端C端都有），邏輯上并不復雜，但由于涉及到交易流程，頁面會比較多，所以是比較重前端頁面。像這類需求，我們可以在盡可能用設計稿說話，圖文穿插，在描述需求的時候盡量多貼一些圖，比如在流程圖上也能貼一些頁面，甚至直接用交互稿/視覺稿去評審。

另外一個例子是打車業(yè)務，在乘客端的訂單詳情頁進行展示優(yōu)化，雖然聽上去這是頁面調整，但訂單頁狀態(tài)非常多，有接單前、接單后出發(fā)前、出發(fā)后未到達目的地、到達目的地、乘客上車后、乘客到達目的地未付款、已付款等等十來個狀態(tài)，每個狀態(tài)展示的頁面都差不多，只是展示的元素（比如按鈕）會略有不同，這反而是一個非常強調邏輯的需求。這時候如果只貼設計稿，就很難說明問題，還是需要用靈活應用各種圖表。

那么問題來了，除了表格和流程圖之外，怎么作出合適的圖來表達產(chǎn)品邏輯呢？

去網(wǎng)上搜一下，會發(fā)現(xiàn)有各種圖，比如泳道圖、時序圖、狀態(tài)機、架構圖、拓撲圖等等……說實話，學姐覺得，作圖只要能清晰地表達出邏輯，沒有人會在意你畫的是不是夠標準（指互聯(lián)網(wǎng)行業(yè)，非軟件）。學姐在大廠這么多年，做過各種業(yè)務，身經(jīng)百戰(zhàn)，從來沒被研發(fā)挑戰(zhàn)過作圖的問題，甚至也沒有在大廠里面聽到過別人提“UML”這個詞（當然如果你愿意認真學UML也是極好的）。

其實，作圖的原則都是類似的，學姐抽象出了作圖5個步驟，看完之后童鞋們應該會覺得作圖so easy。

3. 清晰作圖5步走

1）畫元素

圖中的元素大家應該都知道吧？就是不同形狀的框+文字，比如腦圖里面的每個主題，比如流程圖（圖1）里面的開始、結束、步驟、選擇等，比如時序（圖2）里面的對象和激活期↓

*截圖來自ProsessOn

如果想要畫得標準一些的話，也可以進一步學習下不同形狀框框的含義。

2）放位置

元素所屬的角色可以直接標在框內，但如果這個對象、角色里面還有很多細分邏輯，就要用元素的位置去表達。比如在剛剛的時序圖里，同一縱列的代表同一對象，在泳道圖（圖1）里也是同理，同一列代表角色，在系統(tǒng)架構圖里（圖2），每個橫行的代表同一層級的系統(tǒng)功能↓

*截圖來自ProcessOn

3）連連看

放好位置我們就可以開始連連看了，也就是建立元素之間的關系。常見的有3種，從屬關系、先后順序和數(shù)據(jù)傳輸，前者用一條線連接，后兩者都是帶箭頭的線。比如流程圖、時序圖的單箭頭表示先后順序；架構圖中的雙箭頭表示數(shù)據(jù)傳輸↓

*截圖來自ProcessOn

OKR中的連線表示從屬關系，從大O（目標）拆解到小o，從小o在拆解到KR（路徑）↓

*截圖來自ProcessOn

4）找包含

有了前三步其實就能搞定大部分的圖了，不過我們還要看下元素之間的是否包含。我們經(jīng)?？吹郊軜媹D里面經(jīng)常會出現(xiàn)一些大框套小框的樣式（又套娃），就是因為有包含關系。舉個簡單的例子，美團的騎手評價及申訴流程（簡化版）就很清晰，可以看到平臺第一次過濾的時候主要包含了4種情況，第二次過濾的時候又會包含3種情況，這樣作圖我相信騎手也能看得很明白↓

*摘自美團公眾號

如果前者部分包含了后者的話，我們只要把這兩個元素稍微疊起來一些就行了，比如經(jīng)典的PMF方法論，不過這類圖在需求詳述里用得比較少，一般是在需求背景這部分↓

5）添輔助

為了讓大家看的更清晰，作完圖之后我們可以適當?shù)奶砑右恍┹o助，比如底色、輔助線等，幫助大家看圖更輕松。比如下面的架構圖和泳道圖看起來就會比黑白的要清晰↓

截圖來自ProcessOn

4. 數(shù)據(jù)打點

到這里文檔的大部分內容都寫完了，數(shù)據(jù)打點又是文檔里面比較容易忽略的部分，經(jīng)常會出現(xiàn)數(shù)據(jù)打點的文檔后續(xù)再補這種情況，這很容易導致上線之后才發(fā)現(xiàn)漏打點。

學姐建議，可以先把最核心的打點都寫上，等需求評審完、需求細節(jié)都確定之后，再把詳細的打點都寫上，這樣既不會太花時間，又不會因為某些打點沒有評估而新增工作量（不清楚怎么打點的可以看學姐的這篇文章）。

5. 項目計劃

如果本次的需求是一個大項目或者重要的功能點，項目計劃是必寫的。雖然寫文檔的時候，研發(fā)的工作量還沒有評估出來，但很多重要的項目是有時間節(jié)點的，與其等到大家評估出來之后你再提意見，還不如一開始就把你心中的節(jié)奏直接展示出來給大家看，讓研發(fā)去反推項目的啟動時間和資源。

當然，如果不是有時間節(jié)點的高優(yōu)先級項目，你也可以只是把表格空著，等評審完了再去填寫。

三、評之后，要更新

三段式寫完了，但是并不意味著結束，在需求評審完后，我們還需要陸續(xù)在文檔上更新以下這些內容↓

1. 風險點

這部分也是必更新的，大部分需求的風險點除了有資源、合規(guī)、預算等，還有一個容易忽視的就是不同部門研發(fā)之間的依賴關系，比如研發(fā)b需要研發(fā)c的一個接口，研發(fā)a又需要研發(fā)b提供的接口，即使c準時給出了接口，a和b也研發(fā)完成了，也用假數(shù)據(jù)測試過了，但很可能因為c的bug導致a和b都無法聯(lián)調成功，整個項目就容易delay。

所以，如果研發(fā)在評審的時候，提出了一些依賴關系，那我們一定要在文檔里用醒目的黃底標清楚，可以標注在PRD的第三部分——項目計劃這部分。

2. 項目計劃

備注了風險點之后，項目計劃也可以更新了。另外，建議童鞋們在比較重大的項目上，可以把開會的日期、參會人員和會議紀要也記錄進去。

3. 根據(jù)各方反饋進行的調整

這應該是產(chǎn)品童鞋的家常便飯了，評審之后多多少少會有一些可行性或者研發(fā)資源的問題，會調整一些細節(jié)，學姐建議大家在原文檔的基礎上劃線修改，保留原始需求，把修改的原因也作記錄，這樣也便于在以后有資源的時候重新優(yōu)化。

4. 數(shù)據(jù)結果

一個需求文檔，最完美的ending就是最終的數(shù)據(jù)結果了。學姐接觸下來，大部分優(yōu)秀的研發(fā)對這數(shù)據(jù)結果都很感興趣的。

我們可以等有數(shù)據(jù)了之后更新在需求文檔的第一段第二部分（需求背景-想要達到什么目標），看看和自己預估的是否有差異？如果低于預期的話問題在哪兒？是否能從中推導出后續(xù)的2.0版本？如果2.0版本的需求文檔中，能附上1.0版本的鏈接，文檔開頭還有數(shù)據(jù)更新和分析，那相信2.0版本的需求評審也就能順理成章了。

#專欄作家#

海貝學姐，公眾號：海貝學姐，人人都是產(chǎn)品經(jīng)理專欄作家。十年大廠產(chǎn)品經(jīng)驗，精通產(chǎn)品方法論和產(chǎn)品知識。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于 CC0 協(xié)議