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

一、背景講述

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

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

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

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

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

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

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

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

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

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

所有訴求問題，可總結(jié)為兩點：

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

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

有些也是我初轉(zhuǎn)產(chǎn)品時，曾擔(dān)心過的問題?？吹酱颂幍淖x者，不知是否有過類似擔(dān)憂？

三、PRD的用戶視角分析

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

1. what：PRD是什么？

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

2. why：為什么要寫PRD？

這里引用他處定義，解釋說明。

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

具個人經(jīng)驗，歸納為兩點：

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

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

3. when：PRD在什么階段寫？

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

后果是，在PRD梳理過程中，影響決策。導(dǎo)致后期部分功能需求搖擺不定，因為缺少此類信息輸入，細化PRD后，才發(fā)現(xiàn)底層邏輯需求錯誤，導(dǎo)致大范圍返工。

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

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

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

MRD：Market Requirement Document

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

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

where：PRD在哪兒寫？

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

4. who：分辨PRD用戶是誰

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

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

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

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

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

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

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

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

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

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

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

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

2）外部相關(guān)方與C端不同在于，B端和G端的外部相關(guān)方，對產(chǎn)品有絕對性影響?？蓜澐譃楦?、中、基層甲方領(lǐng)導(dǎo)。

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

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

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

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

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

1. 避坑一：無版本記錄、修訂記錄

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

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

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

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

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

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

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

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

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

常見的需求來源有：

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

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

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

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

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

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

5. 避坑五：信息不清晰 布局不簡潔

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

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

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

2) 文字排版簡潔

描述簡潔精煉。避免大段文字，多分行。

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

考慮信息主次?？紤]信息的次序感，通過字體類型（粗細）和字號區(qū)分出信息層級和描述重點。

3) 色彩簡潔

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

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

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

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

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

六、總結(jié)&思考

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

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

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

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

問題：評審沒有“裁判”。

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

問題：評審沒有“教練”。

方案：制定標準：原型中，寫標準示例，建立知識庫優(yōu)秀案例

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

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

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