產(chǎn)品經(jīng)理要發(fā)現(xiàn)需求，而不是復(fù)制已有的需求。功能需求文檔能夠幫助產(chǎn)品經(jīng)理深入理解需求，理解“為什么要做、為什么這么做”。

本文乃作者應(yīng)一位朋友要求，將項目分析的經(jīng)驗總結(jié)并撰寫成文。

我所在的公司將產(chǎn)品文檔區(qū)分為FRD (Functional Requirement Docs, 即功能需求文檔) 和PRD (Product Requirement Docs, 即產(chǎn)品需求文檔)。二者各司其職缺一不可，甚至在項目推動進(jìn)程中，功能需求文檔的重要性要高過于PRD。同事經(jīng)常說，當(dāng)你輸出了一份好的功能需求文檔，PRD就只是簡單的體力活而已。

一、為什么要做功能需求文檔

功能需求文檔是人寫的，給人看的。在我的認(rèn)知里，功能需求文檔有如下兩點價值：

• 對寫的人：通透認(rèn)知
• 對看的人：統(tǒng)一認(rèn)知

產(chǎn)品經(jīng)理在撰寫一份合格的功能需求文檔時，需充分調(diào)研場景、挖掘需求、分析利弊，梳理邏輯以達(dá)到邏輯自洽，一步步推演得出最終的設(shè)計方案結(jié)論。在這個過程中，產(chǎn)品經(jīng)理能夠以書面的形式整理并反復(fù)推演自己的邏輯，幫助自身深入理解需求，理解“為什么要做、為什么這么做”。

而項目組里的同事，原先對產(chǎn)品需求、方案解決的問題是幾乎一無所知的。產(chǎn)品經(jīng)理要在一個短短的評審中將“為什么要做、為什么這么做”說透，則需要功能需求文檔的支持。一份功能需求文檔就像一份項目Kick Off的ppt，幫助視覺、開發(fā)等同學(xué)快速把對方案的認(rèn)知拉到與產(chǎn)品接近的水平。

因此功能需求文檔是一面鏡子，幫產(chǎn)品經(jīng)理自清；也是一劑催化劑，幫項目成員迅速catch up。

二、寫功能需求文檔前的思路準(zhǔn)備

1. 需求場景分析

開門見山的，往往是最重要的，也是最考驗的。

我慣用的分析流程是需求來源、場景還原、痛點追溯。

（1）需求來源是對于需求的數(shù)據(jù)具象

如今產(chǎn)品經(jīng)理收到需求的途徑有很多，業(yè)務(wù)同學(xué)的反饋、用戶的滿意度調(diào)研、用戶的使用數(shù)據(jù)、競品的調(diào)研報告、產(chǎn)品對于世界動向的感知等等。每個聲音途徑的權(quán)重是不同的，各家產(chǎn)品經(jīng)理需要表述清楚本期項目的需求具體來自哪個途徑，并將需求聲音的強(qiáng)度進(jìn)行數(shù)據(jù)化表達(dá)。

比如我們公司用jira管理業(yè)務(wù)同學(xué)的反饋，則在明確需求來源時，就可以搜集提過該需求的jira數(shù)量，以此初步定量需求聲音的強(qiáng)度。

（2）場景還原是對于需求的背景故事補(bǔ)全

需求表達(dá)的是“用戶想要的方案”，而且用戶往往會在其中摻雜某些“自以為是”的產(chǎn)品方案設(shè)計。因此產(chǎn)品需要做的是抓著用戶需求的藤蔓一路向上，到達(dá)的第一級便是場景還原。

還原出明確的場景，有助于產(chǎn)品對需求躍然出生動的體感，而非停留在干澀的文字轉(zhuǎn)述。

場景包含三要素：誰、什么條件下、做什么。

其中的核心是「什么條件下」，吃透條件有助于判斷該需求的頻次。

（3）痛點追溯是對于場景的刨根問底

還原場景后一定要記得多做一步——再多問2個問題：用戶為什么要做這件事？在做這件事時遇到了什么問題？如果不刨根問底，就容易掉進(jìn)“場景陷阱”，以為已抽象到最底層了。

比如我們本月遇到用戶提出打卡作業(yè)需要一次性布置多份內(nèi)容不同的主題，經(jīng)分析后我們發(fā)現(xiàn)用戶的場景是“在未復(fù)學(xué)前安排老師做線上的打卡集訓(xùn)營”。有的產(chǎn)品經(jīng)理此時已覺得分析到位，需求了然于胸，于是找了幾個做打卡集訓(xùn)營的競品研究研究，就準(zhǔn)備輸出產(chǎn)品方案了。這樣就容易淪落到無腦的抄襲照搬中。

正確的方式是深入到用戶中，挖掘場景背后的目的。用戶要做打卡集訓(xùn)營是想通過內(nèi)容進(jìn)行引流獲客，因為疫情期間無法線下引流，線上投放又對轉(zhuǎn)化率和現(xiàn)金流要求較高。因此我們除了滿足打卡的基礎(chǔ)工具支持外，還需要搭配營銷解決方案，甚至與平臺內(nèi)的其他投放渠道進(jìn)行聯(lián)動，幫助用戶獲取更多曝光。甚至如果能找到一種更好的線上獲客方式，我們完全可以不提供打卡工具，也能夠滿足用戶。

需求場景分析就是抽絲剝繭、尋根溯源的過程，把需求還原成場景、把場景還原成痛點。在這個過程中，對要解決的問題、要達(dá)到的目標(biāo)會愈加清晰。

2. 競品方案分析

明確需要解決的問題后，建議找?guī)卓钜讶荒軌蜉^好解決該問題的產(chǎn)品，深入分析后作為參照。新手產(chǎn)品在接觸一款新的產(chǎn)品時往往會束手無策，尤其遇到復(fù)雜的產(chǎn)品時，容易迷失在眼花繚亂的頁面中。此時要注意競品的分析方法，并且找到能與我們問題對標(biāo)的具體功能，只取一瓢飲即可。

（1）競品功能定位

明確競品的功能定位：給誰用的？做什么用的？做成什么樣？

比如在研究競品的打卡功能時，發(fā)現(xiàn)競品將打卡類型區(qū)分為“打卡課程”、“作業(yè)課程”、“解鎖課程”、“專欄課程”4種，此時則應(yīng)該通過區(qū)分競品提供的功能差異，明確這4種類型分別對標(biāo)什么使用場景，不同的場景中用戶關(guān)注的信息分別是什么、管理動作是什么。

舉個“打卡課程”和“作業(yè)課程”的例子。

競品提供的功能中，打卡課程和作業(yè)課程的核心區(qū)別有3：

1. 在創(chuàng)建方式上，打卡課程創(chuàng)建時有開始與結(jié)束時間；而作業(yè)課程沒有；
2. 在子任務(wù)生成方式上，打卡課程在創(chuàng)建完畢后，系統(tǒng)會根據(jù)設(shè)置的時間范圍創(chuàng)建出對應(yīng)的子任務(wù)列表；而作業(yè)課程創(chuàng)建后無子任務(wù)列表，仍需用戶自行在課程內(nèi)創(chuàng)建；
3. 在數(shù)據(jù)統(tǒng)計上，打卡課程側(cè)重打卡完成進(jìn)度和時間進(jìn)度的比較；作業(yè)課程側(cè)重子任務(wù)數(shù)以及作業(yè)提交的份數(shù)。

從這些功能差異點上，還原出各自對標(biāo)的場景：

打卡課程滿足的場景，是用戶需要布置一個有始有終的打卡任務(wù)。如英語教育機(jī)構(gòu)內(nèi)常見的每日打卡活動，從固定日期開始，到固定日期結(jié)束，每日打卡學(xué)習(xí)的內(nèi)容均不相同。機(jī)構(gòu)管理者關(guān)注的重點，是學(xué)員是否每日按要求完成打卡任務(wù)。

作業(yè)課程滿足的場景，是用戶以一個課程或一個班級為單位去統(tǒng)一管理作業(yè)。如培優(yōu)輔導(dǎo)機(jī)構(gòu)內(nèi)老師經(jīng)常會在課后給學(xué)員們布置提高題，機(jī)構(gòu)就可以在建班時為這個班級創(chuàng)建一個作業(yè)課程，這個作業(yè)課程自身無必要設(shè)置開始與結(jié)束時間，因為班級的周期可以非常長也可以很靈活。老師需要布置作業(yè)時，在課程內(nèi)添加作業(yè)子任務(wù)即可。機(jī)構(gòu)管理者關(guān)注的重點，是總共布置了多少次作業(yè)，學(xué)員又提交了多少。

（2）競品概念模型

經(jīng)驗豐富的產(chǎn)品可以通過測試，反推出競品的概念模型：有幾個實體？實體和實體間的關(guān)系是什么？

同樣以上文中的競品舉例，分析后不難發(fā)現(xiàn)，競品存在“課程”和“子任務(wù)”兩個系統(tǒng)。子任務(wù)是依據(jù)課程的規(guī)則生成的。老師創(chuàng)建課程后，系統(tǒng)依據(jù)規(guī)則生成對應(yīng)的子任務(wù)，將課程分發(fā)給學(xué)員后才可生成學(xué)員的課程。學(xué)生提交作業(yè)的過程，就是提交與子任務(wù)關(guān)聯(lián)的答案。

由于概念模型不是本文重點，圖中僅繪制了流程中涉及的核心實體，實體的具體屬性及其他關(guān)聯(lián)實體，這里不作展開。

（3）競品功能使用流程

測試競品的功能主流程、異常流程，有助于我們在異常流程的設(shè)計中做參照。

3. 核心方案抽象

心中有了遠(yuǎn)方 (需求場景分析) ，手里也有了地圖 (競品方案分析) ，剩下的就是設(shè)計路線了 (核心方案) 。許多產(chǎn)品經(jīng)理在設(shè)計核心方案時容易照搬競品的方案，這里建議采用“否定分析法”，確保功能是充分且必要的。

比如競品設(shè)計了打卡具備獨立的打卡介紹頁，支持富文本編輯。新手產(chǎn)品也許會想：“嗯這個功能不錯，我要抄過來”，但卻忘了多思考一步——打卡子任務(wù)也有內(nèi)容，打卡介紹頁也有內(nèi)容，為什么兩邊內(nèi)容要分開做？不給用戶提供打卡介紹行不行？

要回答這個問題，則需要思考清楚打卡介紹和打卡子任務(wù)的不同定位——打卡介紹，正常的用法是用于介紹一份打卡作業(yè)，相當(dāng)于書的封面，吸引別人把讀；而打卡子任務(wù)則相當(dāng)于書的內(nèi)頁，是正文內(nèi)容。

因此需要打卡介紹的場景，更多是要用圖文介紹的方式吸引潛在客戶參與，對于現(xiàn)有客戶的客情維護(hù)則不需要打卡介紹。而我們的客戶由于行業(yè)及規(guī)模屬性，幾乎沒有面向潛在客戶打卡的場景。

這樣分析下來，就能得出與深入思考前相反的結(jié)論：打卡介紹對我們而言是一個不必要的功能，不做。

三、功能需求文檔的表達(dá)方式

即便思路清晰萬事俱備，語言表達(dá)也是文檔中不容小覷的重要一環(huán)。好的表達(dá)方式能夠給FRD加分，差的表達(dá)則容易蒙蔽FRD中思維的閃光。每個人有自己慣用的語言組織方式，這里僅列舉幾個能給文檔加分的表達(dá)小技巧。

1. 舉例代替描述

需要注意在描述場景時，盡量講具體、完整的用戶故事，新手產(chǎn)品要避免抽象模糊的需求描述。用戶故事最好有實例支撐，如用戶調(diào)研時獲得的某個經(jīng)典素材，甚至是與用戶溝通時的聊天截圖。

比如“調(diào)研發(fā)現(xiàn)A機(jī)構(gòu)在疫情期間無法線下開課的情況下，選擇采用微信群內(nèi)打卡接龍的方式，與學(xué)員保持高頻溝通，圈住學(xué)員。A機(jī)構(gòu)采用的打卡頻次為每日一練，每日內(nèi)容為機(jī)構(gòu)老師精心選擇（配上內(nèi)容案例），會在當(dāng)晚12點前準(zhǔn)備好第二天學(xué)員打卡的內(nèi)容”，這樣的表述，就會好過“調(diào)研發(fā)現(xiàn)，機(jī)構(gòu)有每日打卡的需求”。

2. 圖表代替描述

盡可能避免大段文字，長文對于開發(fā)同學(xué)來說看著會較為費勁。撰寫文檔時可以考慮用ppt繪制結(jié)構(gòu)性的內(nèi)容；用表格表達(dá)多維對比；用processon繪制用戶使用流程。

3. 一次說清一件事

請記?。翰煌鞒滩灰煸谝粋€流程圖里，不同系統(tǒng)不要混在一個概念模型package里。

新手產(chǎn)品往往容易犯把所有信息塞在同一張圖里的錯誤。比如流程圖時把多角色多流程放一起，不僅繪制流程圖時指向線很多，難以表述，而且讀者的理解成本也很高。建議如遇這種情況，分開繪制，一個流程畫一張圖，一次說清一件事。

4. 階段性結(jié)論

較大項目在功能需求分析時抽絲剝繭層層深入，篇幅較長，建議階段性給一個結(jié)論，且實際的可往下執(zhí)行的結(jié)論。如場景分析part，結(jié)論是“哪些場景已覆蓋、哪些未覆蓋，本期重點覆蓋哪些”；競品分析part，結(jié)論是“競品哪些點值得學(xué)習(xí)，哪些雖然涉及精巧但不符合我們受眾人群，哪些不值得借鑒”；項目方案part，結(jié)論是“本期有哪些重點方案要做，為什么做，解決什么問題”。

像這樣的階段性總結(jié)，可以幫助你把思路一個個串起來，也能讓聽的人順著你的思路走，不走神不跑偏。

結(jié)語

關(guān)鍵點總結(jié)

1. 需求場景分析需做好需求具象、場景還原、痛點追溯，勢必“多追溯一層”
2. 競品方案分析需從功能上深挖，明確對標(biāo)場景，還原競品概念模型，勢必“多挖掘一層”
3. 核心方案抽象需否定分析
4. 通過舉例、繪圖、聚焦表述、階段性總結(jié)的方式，使文檔可讀性更強(qiáng)

此文斷斷續(xù)續(xù)3周才成稿，寫完回讀過去寫的部分，并不是很滿意，仿佛蒙著一層霧，不夠精煉不夠直擊。產(chǎn)品需練、文筆需練，路恒漫漫，一點小小思考，供各位參考。

本文由 @撕裂時間的少年 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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