產品經理要發現需求，而不是複製已有的需求。功能需求文檔能夠幫助產品經理深入理解需求，理解“為什麼要做、為什麼這麼做”。
本文乃作者應一位朋友要求，將項目分析的經驗總結並撰寫成文。
我所在的公司將產品文檔區分為FRD (Functional Requirement Docs, 即功能需求文檔) 和PRD (Product Requirement Docs, 即產品需求文檔)。二者各司其職缺一不可，甚至在項目推動進程中，功能需求文檔的重要性要高過於PRD。同事經常說，當你輸出了一份好的功能需求文檔，PRD就只是簡單的體力活而已。
一、為什麼要做功能需求文檔
功能需求文檔是人寫的，給人看的。在我的認知里，功能需求文檔有如下兩點價值：
- 對寫的人：通透認知
- 對看的人：統一認知
產品經理在撰寫一份合格的功能需求文檔時，需充分調研場景、挖掘需求、分析利弊，梳理邏輯以達到邏輯自洽，一步步推演得出最終的設計方案結論。在這個過程中，產品經理能夠以書面的形式整理並反覆推演自己的邏輯，幫助自身深入理解需求，理解“為什麼要做、為什麼這麼做”。
而項目組裡的同事，原先對產品需求、方案解決的問題是幾乎一無所知的。產品經理要在一個短短的評審中將“為什麼要做、為什麼這麼做”說透，則需要功能需求文檔的支持。一份功能需求文檔就像一份項目Kick Off的ppt，幫助視覺、開發等同學快速把對方案的認知拉到與產品接近的水平。
因此功能需求文檔是一面鏡子，幫產品經理自清；也是一劑催化劑，幫項目成員迅速catch up。
二、寫功能需求文檔前的思路準備
1. 需求場景分析
開門見山的，往往是最重要的，也是最考驗的。
我慣用的分析流程是需求來源、場景還原、痛點追溯。
（1）需求來源是對於需求的數據具象
如今產品經理收到需求的途徑有很多，業務同學的反饋、用戶的滿意度調研、用戶的使用數據、競品的調研報告、產品對於世界動向的感知等等。每個聲音途徑的權重是不同的，各家產品經理需要表述清楚本期項目的需求具體來自哪個途徑，並將需求聲音的強度進行數據化表達。
比如我們公司用jira管理業務同學的反饋，則在明確需求來源時，就可以搜集提過該需求的jira數量，以此初步定量需求聲音的強度。
（2）場景還原是對於需求的背景故事補全
需求表達的是“用戶想要的方案”，而且用戶往往會在其中摻雜某些“自以為是”的產品方案設計。因此產品需要做的是抓著用戶需求的藤蔓一路向上，到達的第一級便是場景還原。
還原出明確的場景，有助於產品對需求躍然出生動的體感，而非停留在乾澀的文字轉述。
場景包含三要素：誰、什麼條件下、做什麼。
其中的核心是「什麼條件下」，吃透條件有助於判斷該需求的頻次。
（3）痛點追溯是對於場景的刨根問底
還原場景後一定要記得多做一步——再多問2個問題：用戶為什麼要做這件事？在做這件事時遇到了什麼問題？如果不刨根問底，就容易掉進“場景陷阱”，以為已抽象到最底層了。
比如我們本月遇到用戶提出打卡作業需要一次性佈置多份內容不同的主題，經分析後我們發現用戶的場景是“在未復學前安排老師做線上的打卡集訓營”。有的產品經理此時已覺得分析到位，需求瞭然於胸，於是找了幾個做打卡集訓營的競品研究研究，就準備輸出產品方案了。這樣就容易淪落到無腦的抄襲照搬中。
正確的方式是深入到用戶中，挖掘場景背後的目的。用戶要做打卡集訓營是想通過內容進行引流獲客，因為疫情期間無法線下引流，線上投放又對轉化率和現金流要求較高。因此我們除了滿足打卡的基礎工具支持外，還需要搭配營銷解決方案，甚至與平臺內的其他投放渠道進行聯動，幫助用戶獲取更多曝光。甚至如果能找到一種更好的線上獲客方式，我們完全可以不提供打卡工具，也能夠滿足用戶。
需求場景分析就是抽絲剝繭、尋根溯源的過程，把需求還原成場景、把場景還原成痛點。在這個過程中，對要解決的問題、要達到的目標會愈加清晰。
2. 競品方案分析
明確需要解決的問題後，建議找幾款已然能夠較好解決該問題的產品，深入分析後作為參照。新手產品在接觸一款新的產品時往往會束手無策，尤其遇到複雜的產品時，容易迷失在眼花繚亂的頁面中。此時要註意競品的分析方法，並且找到能與我們問題對標的具體功能，只取一瓢飲即可。
（1）競品功能定位
明確競品的功能定位：給誰用的？做什麼用的？做成什麼樣？
比如在研究競品的打卡功能時，發現競品將打卡類型區分為“打卡課程”、“作業課程”、“解鎖課程”、“專欄課程”4種，此時則應該通過區分競品提供的功能差異，明確這4種類型分別對標什麼使用場景，不同的場景中用戶關註的信息分別是什麼、管理動作是什麼。
舉個“打卡課程”和“作業課程”的例子。
競品提供的功能中，打卡課程和作業課程的核心區別有3：
- 在創建方式上，打卡課程創建時有開始與結束時間；而作業課程沒有；
- 在子任務生成方式上，打卡課程在創建完畢後，系統會根據設置的時間範圍創建出對應的子任務列表；而作業課程創建後無子任務列表，仍需用戶自行在課程內創建；
- 在數據統計上，打卡課程側重打卡完成進度和時間進度的比較；作業課程側重子任務數以及作業提交的份數。
從這些功能差異點上，還原出各自對標的場景：
打卡課程滿足的場景，是用戶需要佈置一個有始有終的打卡任務。如英語教育機構內常見的每日打卡活動，從固定日期開始，到固定日期結束，每日打卡學習的內容均不相同。機構管理者關註的重點，是學員是否每日按要求完成打卡任務。
作業課程滿足的場景，是用戶以一個課程或一個班級為單位去統一管理作業。如培優輔導機構內老師經常會在課後給學員們佈置提高題，機構就可以在建班時為這個班級創建一個作業課程，這個作業課程自身無必要設置開始與結束時間，因為班級的周期可以非常長也可以很靈活。老師需要佈置作業時，在課程內添加作業子任務即可。機構管理者關註的重點，是總共佈置了多少次作業，學員又提交了多少。
（2）競品概念模型
經驗豐富的產品可以通過測試，反推出競品的概念模型：有幾個實體？實體和實體間的關係是什麼？
同樣以上文中的競品舉例，分析後不難發現，競品存在“課程”和“子任務”兩個系統。子任務是依據課程的規則生成的。老師創建課程後，系統依據規則生成對應的子任務，將課程分發給學員後才可生成學員的課程。學生提交作業的過程，就是提交與子任務關聯的答案。
由於概念模型不是本文重點，圖中僅繪製了流程中涉及的核心實體，實體的具體屬性及其他關聯實體，這裡不作展開。
（3）競品功能使用流程
測試競品的功能主流程、異常流程，有助於我們在異常流程的設計中做參照。
3. 核心方案抽象
心中有了遠方 (需求場景分析) ，手裡也有了地圖 (競品方案分析) ，剩下的就是設計路線了 (核心方案) 。許多產品經理在設計核心方案時容易照搬競品的方案，這裡建議採用“否定分析法”，確保功能是充分且必要的。
比如競品設計了打卡具備獨立的打卡介紹頁，支持富文本編輯。新手產品也許會想：“嗯這個功能不錯，我要抄過來”，但卻忘了多思考一步——打卡子任務也有內容，打卡介紹頁也有內容，為什麼兩邊內容要分開做？不給用戶提供打卡介紹行不行？
要回答這個問題，則需要思考清楚打卡介紹和打卡子任務的不同定位——打卡介紹，正常的用法是用於介紹一份打卡作業，相當於書的封面，吸引別人把讀；而打卡子任務則相當於書的內頁，是正文內容。
因此需要打卡介紹的場景，更多是要用圖文介紹的方式吸引潛在客戶參與，對於現有客戶的客情維護則不需要打卡介紹。而我們的客戶由於行業及規模屬性，幾乎沒有面向潛在客戶打卡的場景。
這樣分析下來，就能得出與深入思考前相反的結論：打卡介紹對我們而言是一個不必要的功能，不做。
三、功能需求文檔的表達方式
即便思路清晰萬事俱備，語言表達也是文檔中不容小覷的重要一環。好的表達方式能夠給FRD加分，差的表達則容易矇蔽FRD中思維的閃光。每個人有自己慣用的語言組織方式，這裡僅列舉幾個能給文檔加分的表達小技巧。
1. 舉例代替描述
需要註意在描述場景時，儘量講具體、完整的用戶故事，新手產品要避免抽象模糊的需求描述。用戶故事最好有實例支撐，如用戶調研時獲得的某個經典素材，甚至是與用戶溝通時的聊天截圖。
比如“調研發現A機構在疫情期間無法線下開課的情況下，選擇採用微信群內打卡接龍的方式，與學員保持高頻溝通，圈住學員。A機構採用的打卡頻次為每日一練，每日內容為機構老師精心選擇（配上內容案例），會在當晚12點前準備好第二天學員打卡的內容”，這樣的表述，就會好過“調研發現，機構有每日打卡的需求”。
2. 圖表代替描述
盡可能避免大段文字，長文對於開發同學來說看著會較為費勁。撰寫文檔時可以考慮用ppt繪製結構性的內容；用表格表達多維對比；用processon繪製用戶使用流程。
3. 一次說清一件事
請記住：不同流程不要混在一個流程圖裡，不同系統不要混在一個概念模型package里。
新手產品往往容易犯把所有信息塞在同一張圖裡的錯誤。比如流程圖時把多角色多流程放一起，不僅繪製流程圖時指向線很多，難以表述，而且讀者的理解成本也很高。建議如遇這種情況，分開繪製，一個流程畫一張圖，一次說清一件事。
4. 階段性結論
較大項目在功能需求分析時抽絲剝繭層層深入，篇幅較長，建議階段性給一個結論，且實際的可往下執行的結論。如場景分析part，結論是“哪些場景已覆蓋、哪些未覆蓋，本期重點覆蓋哪些”；競品分析part，結論是“競品哪些點值得學習，哪些雖然涉及精巧但不符合我們受眾人群，哪些不值得借鑒”；項目方案part，結論是“本期有哪些重點方案要做，為什麼做，解決什麼問題”。
像這樣的階段性總結，可以幫助你把思路一個個串起來，也能讓聽的人順著你的思路走，不走神不跑偏。
結語
關鍵點總結
- 需求場景分析需做好需求具象、場景還原、痛點追溯，勢必“多追溯一層”
- 競品方案分析需從功能上深挖，明確對標場景，還原競品概念模型，勢必“多挖掘一層”
- 核心方案抽象需否定分析
- 通過舉例、繪圖、聚焦表述、階段性總結的方式，使文檔可讀性更強
此文斷斷續續3周才成稿，寫完回讀過去寫的部分，並不是很滿意，仿佛蒙著一層霧，不夠精煉不夠直擊。產品需練、文筆需練，路恆漫漫，一點小小思考，供各位參考。
本文由 @撕裂時間的少年 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。