編輯導(dǎo)語(yǔ)：在寫(xiě)PRD需求時(shí)，我們總會(huì)遇到各種各樣的坑，如何避免或者少踩一些坑呢？作者分享了從用戶視角出發(fā)的自己經(jīng)歷過(guò)的奇葩問(wèn)題與解決思路，希望對(duì)你有所幫助。

一、背景講述

接到公司任務(wù)，做《避坑36計(jì)》分享PRD撰寫(xiě)思路。

之前做的G端需求調(diào)研避坑分享，讓我司百來(lái)號(hào)人，看到什么叫自殺式自黑總結(jié)，講述遇過(guò)的各種奇葩問(wèn)題和解決思路。這次決定換換這打臉不討好的方式。

畢竟公司產(chǎn)品被強(qiáng)制參加，改變策略不講個(gè)體遭遇，收集一波研發(fā)、設(shè)計(jì)的吐槽，再需求分析共同探討。這決定了本期主題《用戶視角的PRD撰寫(xiě)》。

決定記錄下來(lái)，一方面是提煉總結(jié)和自我提醒；另一方面，是和同行共同交流避坑經(jīng)驗(yàn)，交流互助，碰撞更好的解決方案。更好地滿足PRD產(chǎn)品的用戶需求。

注：總結(jié)來(lái)自創(chuàng)業(yè)屬性公司，可能和大廠所遇問(wèn)題不同，若有不同觀點(diǎn)，也歡迎交流。

二、 現(xiàn)有聲音收集

為收集現(xiàn)有痛點(diǎn)和需求，于是乎，先去問(wèn)了設(shè)計(jì)、研發(fā)們一個(gè)小問(wèn)題：你覺(jué)得產(chǎn)品的PRD怎么樣？

得到的問(wèn)題反饋，好氣又好笑，含蓄又直接，八分的玩笑中透露出十分的認(rèn)真，但每個(gè)反饋都值得被認(rèn)真對(duì)待。確實(shí)是群有想法、有輸出、能抗傷害的同事了。

雖然個(gè)人認(rèn)為，PRD不一定要實(shí)現(xiàn)全部交互跳轉(zhuǎn)，從全流程來(lái)看，在需求不明確的場(chǎng)景下，B端/G端產(chǎn)品存在較大的改動(dòng)風(fēng)險(xiǎn)。交互不難實(shí)現(xiàn)，但維護(hù)成本太大，并存在被看漏的可能性。

拆解該研發(fā)槽點(diǎn)的底層需求，實(shí)際是覺(jué)得現(xiàn)有方式表達(dá)并不清晰，沒(méi)能很好呈現(xiàn)頁(yè)面的跳轉(zhuǎn)關(guān)系，造成了團(tuán)隊(duì)溝通上的困難。而認(rèn)為要有交互，只是他作為用戶提出的解決方案。

所有訴求問(wèn)題，可總結(jié)為兩點(diǎn)：

1. 可讀性差
2. 內(nèi)容不詳

于是，我又去問(wèn)了其他產(chǎn)品：你寫(xiě)PRD擔(dān)心過(guò)什么？

有些也是我初轉(zhuǎn)產(chǎn)品時(shí)，曾擔(dān)心過(guò)的問(wèn)題。看到此處的讀者，不知是否有過(guò)類似擔(dān)憂？

三、PRD的用戶視角分析

用基礎(chǔ)分析工具5W1H，拆解下PRD的用戶需求。

1. what：PRD是什么？

首先，在定位上，PRD是產(chǎn)品經(jīng)理的溝通工具。涉及最多的兩種表現(xiàn)形式是Word+Axure，和Axure。兩者各有優(yōu)劣，其實(shí)不用局限于一種形式，可根據(jù)使用場(chǎng)景選擇合適的表現(xiàn)形式。

2. why：為什么要寫(xiě)PRD？

這里引用他處定義，解釋說(shuō)明。

產(chǎn)品原型的目的，是清楚表達(dá)產(chǎn)品設(shè)計(jì)理念和功能交互及執(zhí)行邏輯，提高產(chǎn)品、研發(fā)、UI及業(yè)務(wù)部門(mén)之間的溝通效率，避免信息不對(duì)稱和信息傳達(dá)的遺漏和缺失而導(dǎo)致的整個(gè)項(xiàng)目進(jìn)度延期問(wèn)題。

具個(gè)人經(jīng)驗(yàn)，歸納為兩點(diǎn)：

1. 減少溝通的認(rèn)知偏差
2. 保障質(zhì)量的前提下提升效率

說(shuō)人話就是：減少扯皮，避免返工；能懶則懶，減少加班。

3. when：PRD在什么階段寫(xiě)？

理論上，PRD作為產(chǎn)品需求文檔，是繼BRD、MRD后，從產(chǎn)品規(guī)劃到產(chǎn)品設(shè)計(jì)的階段性產(chǎn)出物。在中小型公司中，常缺失在規(guī)劃階段的商業(yè)論證和市場(chǎng)驗(yàn)證，需求來(lái)自領(lǐng)導(dǎo)對(duì)市場(chǎng)的敏感度，來(lái)決策做或不做，缺失的商業(yè)需求文檔、市場(chǎng)需求分析。

后果是，在PRD梳理過(guò)程中，影響決策。導(dǎo)致后期部分功能需求搖擺不定，因?yàn)槿鄙俅祟愋畔⑤斎?，?xì)化PRD后，才發(fā)現(xiàn)底層邏輯需求錯(cuò)誤，導(dǎo)致大范圍返工。

而在實(shí)踐中，經(jīng)常為了更快產(chǎn)出，會(huì)變成PRD通關(guān)全過(guò)程，缺少BRD、MRD的階段和產(chǎn)出。

BRD：Business Requirement Document，產(chǎn)品向上溝通立項(xiàng)的工具。

內(nèi)容：說(shuō)明產(chǎn)品賣給誰(shuí)、成本和收入情況、為什么能贏利等關(guān)鍵問(wèn)題。闡述為什么立項(xiàng)，為公司提供信息，從而決策該產(chǎn)品是否有投入資源的價(jià)值。

MRD：Market Requirement Document

定義：向上溝通要做什么、怎么做的工具。

內(nèi)容：說(shuō)明所處行業(yè)的市場(chǎng)情況、目標(biāo)用戶、競(jìng)品情況、自身策略等信息。闡述內(nèi)外環(huán)境影響，向公司說(shuō)明產(chǎn)品在市場(chǎng)中的定位和策略，核心是為該產(chǎn)品在同公司的眾多產(chǎn)品線中，爭(zhēng)取更多的研發(fā)、運(yùn)營(yíng)和市場(chǎng)資源傾斜。

where：PRD在哪兒寫(xiě)？

此處可劃分為兩大階段，四個(gè)類型。兩大階段為需求評(píng)審、交互評(píng)審；四個(gè)類型為項(xiàng)目的大版本需求設(shè)計(jì)、項(xiàng)目的小迭代需求、新產(chǎn)品從0-1孵化、新產(chǎn)品迭代需求。在不同環(huán)節(jié)，關(guān)注的內(nèi)容會(huì)有所不同。

4. who：分辨PRD用戶是誰(shuí)

在B端、G端產(chǎn)品中，PRD的用戶在產(chǎn)品工作中的上下游環(huán)節(jié)，可分為公司外部相關(guān)方、內(nèi)部成員。

1）內(nèi)部成員：內(nèi)部用戶和C端基本一樣。

a）需求評(píng)審階段：主要面向領(lǐng)導(dǎo)、研發(fā)負(fù)責(zé)人、產(chǎn)品負(fù)責(zé)人、項(xiàng)目經(jīng)理。希望獲取的信息如下：

• 需求價(jià)值
• 目標(biāo)
• 用戶故事（為誰(shuí)在什么場(chǎng)景下解決什么問(wèn)題）
• 方案可行性
• 成本（功能清單）
• 需求優(yōu)先級(jí)
• 競(jìng)爭(zhēng)力情況
• 產(chǎn)品架構(gòu)（和其他模塊的關(guān)系）

b）交互評(píng)審階段：主要面向前端、后端、設(shè)計(jì)、測(cè)試、項(xiàng)目經(jīng)理、協(xié)同產(chǎn)品。希望獲取的信息如下：

• 需求價(jià)值
• 目標(biāo)
• 用戶故事（為誰(shuí)在什么場(chǎng)景下解決什么問(wèn)題）
• 方案可行性
• 需求優(yōu)先級(jí)
• 產(chǎn)品架構(gòu)（和其他模塊的關(guān)系）
• 頁(yè)面交互
• 性能要求

作為PRD文檔，交互評(píng)審階段為核心業(yè)務(wù)場(chǎng)景。詳細(xì)拆解該階段各類用戶的核心關(guān)注點(diǎn)，如下：

后端：關(guān)注數(shù)據(jù)從哪來(lái)，數(shù)據(jù)有什么，哪些需要存，如何建表存，這些數(shù)據(jù)是否需要支持增、刪、改、查等功能，需要為產(chǎn)品提供哪些接口，評(píng)估方案可實(shí)施性。

前端：關(guān)注后端接口如何與前端界面結(jié)合，調(diào)取后端哪個(gè)接口，并用怎樣的方式為后端收集入?yún)?，在收集入?yún)r(shí)前端是否要做額外的限制，以及后端返回的出參如何轉(zhuǎn)化為前端的提示等，評(píng)估方案可實(shí)施性。

設(shè)計(jì)師：關(guān)注信息布局和交互的合理性、用戶體驗(yàn)、產(chǎn)品的界面調(diào)性。作為產(chǎn)品下游，他們往往是最關(guān)注PRD中原型內(nèi)容的人。

測(cè)試：關(guān)注產(chǎn)品的user story，因?yàn)镼A需要模擬不同的使用場(chǎng)景設(shè)計(jì)測(cè)試case，大部分情況下QA會(huì)用Xmind等腦圖設(shè)計(jì)工具來(lái)設(shè)計(jì)、覆蓋可能出現(xiàn)的case，并進(jìn)行遍歷測(cè)試。

協(xié)同產(chǎn)品：產(chǎn)品中有哪些通用概念，本次迭代與之前版本的功能迭代的關(guān)系，需求的緊急性和重要性。

2）外部相關(guān)方與C端不同在于，B端和G端的外部相關(guān)方，對(duì)產(chǎn)品有絕對(duì)性影響。可劃分為高、中、基層甲方領(lǐng)導(dǎo)。

• 甲方高層：很多不看，他們喜歡看PPT和上線系統(tǒng)，部分喜好摳“字眼”。
• 甲方中層：注重業(yè)務(wù)邏輯（解決了什么問(wèn)題）、功能價(jià)值（可達(dá)到的效果）、用戶場(chǎng)景（為誰(shuí)在什么場(chǎng)景下解決什么問(wèn)題）、使用體驗(yàn)，部分喜好摳字段、交互和視覺(jué)呈現(xiàn)。
• 甲方基層：注重功能使用場(chǎng)景（功能是否滿足業(yè)務(wù)需求）、使用體驗(yàn)、字段。

四、how：PRD的內(nèi)容要素

PRD涉及的信息要素有版本記錄、需求分析、需求設(shè)計(jì)、全局說(shuō)明、原型設(shè)計(jì)四大內(nèi)容。在不同階段場(chǎng)景下，涉及的內(nèi)容略有差別，具體內(nèi)容如下圖。

此處進(jìn)行總結(jié)羅列，不做內(nèi)容拆解，等有時(shí)間精力梳理時(shí)，再進(jìn)行總結(jié)分享。

五、PRD撰寫(xiě)的避坑總結(jié)

1. 避坑一：無(wú)版本記錄、修訂記錄

版本記錄、修訂記錄不可少。在PRD里直接記錄，每次修改時(shí)順手完成，成本遠(yuǎn)遠(yuǎn)小于事后追溯。

版本記錄：用于方便對(duì)應(yīng)不同版本。內(nèi)容包含系統(tǒng)名稱、文檔版本號(hào)、系統(tǒng)版本號(hào)、創(chuàng)建時(shí)間、產(chǎn)品經(jīng)理、UI設(shè)計(jì)師、前端、后臺(tái)人員信息。

修訂記錄：易于回溯和總結(jié)變更原因，保障下次的輸出。內(nèi)容包含修訂日期、文檔版本、所在頁(yè)面、變更內(nèi)容、修訂情況、修訂人員。

在這過(guò)程中，不但要補(bǔ)充內(nèi)容，也要思考需要修改的原因是什么。是需求挖掘沒(méi)有到位？沒(méi)有找到關(guān)鍵的業(yè)務(wù)干系人？業(yè)務(wù)流程存在疏漏？還是外部商務(wù)因素干擾引發(fā)的需求反復(fù)？

要綜合衡量每次修改的成本差異、實(shí)現(xiàn)效果。思考修改變動(dòng)是否能解決用戶核心問(wèn)題，此次修改是不是項(xiàng)目中最需要堅(jiān)持的核心功能流程，要注意把撕逼的機(jī)會(huì)留給守護(hù)核心功能流程上。

2. 避坑二：需求背景描述不全面

需求背景需全面，盡量還原業(yè)務(wù)場(chǎng)景。需求收集-分析的過(guò)程，是產(chǎn)品設(shè)計(jì)的輸入，讓產(chǎn)品經(jīng)理能摸清問(wèn)題的本源。溝通要在信息對(duì)等的前提下進(jìn)行，需求場(chǎng)景表達(dá)越合理，越能讓團(tuán)隊(duì)覺(jué)得自己所做事情是有價(jià)值的。

如果被質(zhì)疑時(shí)，你只能說(shuō)出“老板/領(lǐng)導(dǎo)要這么做”的話，說(shuō)明你在需求調(diào)研和需求分析階段偷了懶，沒(méi)有負(fù)起責(zé)任，這也容易因?yàn)閷?duì)需求理解不到位造成返工。

做功能只是手段、不是目的。不要只做傳話者，變成了自己討厭的人。

常見(jiàn)的需求來(lái)源有：

1. 業(yè)務(wù)需求/問(wèn)題
2. 現(xiàn)狀數(shù)據(jù)分析
3. 來(lái)自競(jìng)品（抄競(jìng)品）

3. 避坑三：需求評(píng)審階段，未梳理系統(tǒng)依賴

B/G端系統(tǒng)，常依賴于其他系統(tǒng)數(shù)據(jù)，在需求評(píng)審階段，就需梳理清楚所有所需數(shù)據(jù)來(lái)源、系統(tǒng)依賴。

一方面，是進(jìn)行初步的可行性評(píng)估，明確所需條件是否具備；另一方面，可提前協(xié)調(diào)相關(guān)資源，預(yù)留字段和接口。若交互設(shè)計(jì)階段，才進(jìn)行相關(guān)梳理和確認(rèn)，易造成決策返工，可能會(huì)發(fā)現(xiàn)前置條件并不滿足。

4. 避坑四：數(shù)據(jù)層分析缺失

交互評(píng)審中，數(shù)據(jù)分析梳理不可缺。B/G端系統(tǒng)設(shè)計(jì)中，數(shù)據(jù)是核心。其中數(shù)據(jù)清單列表、實(shí)體關(guān)系圖是每次需求都需梳理和更新的必要信息，數(shù)據(jù)流程圖可根據(jù)需求的復(fù)雜程度決定是否分析。

5. 避坑五：信息不清晰 布局不簡(jiǎn)潔

信息結(jié)構(gòu)盡量清晰，布局盡量簡(jiǎn)潔。無(wú)論頁(yè)面設(shè)計(jì)，還是PRD的排版布局，都要注意信息設(shè)計(jì)的合理性。并且內(nèi)容越清晰，越能降低評(píng)審人員的理解門(mén)檻，提前討論疑問(wèn)點(diǎn)，讓評(píng)審效率更高。形式的建議如下：

1) 圖文結(jié)構(gòu)化布局

頁(yè)面元素與注釋對(duì)應(yīng)清晰，最好在元素邊上就是注釋。

2) 文字排版簡(jiǎn)潔

描述簡(jiǎn)潔精煉。避免大段文字，多分行。

信息要放得下。放不下又全要，就換個(gè)交互形式。

考慮信息主次。考慮信息的次序感，通過(guò)字體類型（粗細(xì)）和字號(hào)區(qū)分出信息層級(jí)和描述重點(diǎn)。

3) 色彩簡(jiǎn)潔

避免豐富的顏色。用黑白灰+主題色+強(qiáng)調(diào)色。

6. 避坑六：忽略細(xì)節(jié)定義

注意細(xì)節(jié)定義。以下幾點(diǎn)，都是較為重要且易被忽略的。

• 定義數(shù)據(jù)
• 定義地圖交互
• 定義異常狀態(tài)反饋
• 定義排序規(guī)則
• 定義狀態(tài)機(jī)

最后，其實(shí)還需結(jié)果導(dǎo)向，不要拘泥于形式表達(dá)，最終是希望能和上下游高效協(xié)同。

六、總結(jié)&思考

前期設(shè)計(jì)環(huán)節(jié)考慮越充分，越能保障后續(xù)實(shí)現(xiàn)的質(zhì)量。所以還是有必要梳理PRD規(guī)范。當(dāng)生產(chǎn)中的每個(gè)環(huán)節(jié)都保證生產(chǎn)質(zhì)量，從整條生產(chǎn)鏈來(lái)看，會(huì)節(jié)省了不少“補(bǔ)鍋”成本，也就是“1-10-100”理論。

在設(shè)計(jì)階段，花1塊錢能解決的問(wèn)題；留在制造階段，要用至少10倍成本來(lái)糾錯(cuò)；如缺陷流出到顧客，則至少要花100倍成本來(lái)糾錯(cuò)。

但標(biāo)準(zhǔn)的制定和執(zhí)行需要過(guò)程，需有序推進(jìn)。這是關(guān)于產(chǎn)品質(zhì)量和效率的權(quán)衡，值不值得我們花時(shí)間讓它變得高質(zhì)量，要聚焦目標(biāo)和初心，是為了“60分”還是“100分”，優(yōu)先處理最重要的事情，聚焦處理核心的需求。

在公司分享的最后環(huán)節(jié)，產(chǎn)品副總裁讓大家挨個(gè)補(bǔ)充了所遇問(wèn)題和感想，并針對(duì)每個(gè)槽點(diǎn)/問(wèn)題，拆解了解決方案，讓總結(jié)和分享并沒(méi)有止步于會(huì)議。例如：

問(wèn)題：評(píng)審沒(méi)有“裁判”。

方案：定義關(guān)鍵要素的標(biāo)準(zhǔn)。增加打分標(biāo)準(zhǔn)。記錄評(píng)審修改過(guò)程，進(jìn)行評(píng)估，標(biāo)準(zhǔn)為評(píng)審次數(shù)、文檔修改次數(shù)的有效歸檔、修改情況，利于復(fù)盤(pán)提升產(chǎn)品設(shè)計(jì)能力。

問(wèn)題：評(píng)審沒(méi)有“教練”。

方案：制定標(biāo)準(zhǔn)：原型中，寫(xiě)標(biāo)準(zhǔn)示例，建立知識(shí)庫(kù)優(yōu)秀案例

這樣有自省能力和持續(xù)成長(zhǎng)的組織，相信未來(lái)會(huì)更好。我也會(huì)繼續(xù)努力，在此次總結(jié)后，梳理下出適合自身行業(yè)的PRD標(biāo)準(zhǔn)，持續(xù)優(yōu)化自身和團(tuán)隊(duì)的輸出質(zhì)量及效率。望共勉之。

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

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