中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

一、背景講述

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

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

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

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

注：總結來自創業屬性公司，可能和大廠所遇問題不同，若有不同觀點，也歡迎交流。

二、 現有聲音收集

為收集現有痛點和需求，于是乎，先去問了設計、研發們一個小問題：你覺得產品的PRD怎么樣？

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

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

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

所有訴求問題，可總結為兩點：

1. 可讀性差
2. 內容不詳

于是，我又去問了其他產品：你寫PRD擔心過什么？

有些也是我初轉產品時，曾擔心過的問題。看到此處的讀者，不知是否有過類似擔憂？

三、PRD的用戶視角分析

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

1. what：PRD是什么？

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

2. why：為什么要寫PRD？

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

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

具個人經驗，歸納為兩點：

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

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

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

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

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

而在實踐中，經常為了更快產出，會變成PRD通關全過程，缺少BRD、MRD的階段和產出。

BRD：Business Requirement Document，產品向上溝通立項的工具。

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

MRD：Market Requirement Document

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

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

where：PRD在哪兒寫？

此處可劃分為兩大階段，四個類型。兩大階段為需求評審、交互評審；四個類型為項目的大版本需求設計、項目的小迭代需求、新產品從0-1孵化、新產品迭代需求。在不同環節，關注的內容會有所不同。

4. who：分辨PRD用戶是誰

在B端、G端產品中，PRD的用戶在產品工作中的上下游環節，可分為公司外部相關方、內部成員。

1）內部成員：內部用戶和C端基本一樣。

a）需求評審階段：主要面向領導、研發負責人、產品負責人、項目經理。希望獲取的信息如下：

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

b）交互評審階段：主要面向前端、后端、設計、測試、項目經理、協同產品。希望獲取的信息如下：

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

作為PRD文檔，交互評審階段為核心業務場景。詳細拆解該階段各類用戶的核心關注點，如下：

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

前端：關注后端接口如何與前端界面結合，調取后端哪個接口，并用怎樣的方式為后端收集入參，在收集入參時前端是否要做額外的限制，以及后端返回的出參如何轉化為前端的提示等，評估方案可實施性。

設計師：關注信息布局和交互的合理性、用戶體驗、產品的界面調性。作為產品下游，他們往往是最關注PRD中原型內容的人。

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

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

2）外部相關方與C端不同在于，B端和G端的外部相關方，對產品有絕對性影響?？蓜澐譃楦?、中、基層甲方領導。

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

四、how：PRD的內容要素

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

此處進行總結羅列，不做內容拆解，等有時間精力梳理時，再進行總結分享。

五、PRD撰寫的避坑總結

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

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

版本記錄：用于方便對應不同版本。內容包含系統名稱、文檔版本號、系統版本號、創建時間、產品經理、UI設計師、前端、后臺人員信息。

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

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

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

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

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

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

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

常見的需求來源有：

1. 業務需求/問題
2. 現狀數據分析
3. 來自競品（抄競品）

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

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

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

4. 避坑四：數據層分析缺失

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

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

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

1) 圖文結構化布局

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

2) 文字排版簡潔

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

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

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

3) 色彩簡潔

避免豐富的顏色。用黑白灰+主題色+強調色。

6. 避坑六：忽略細節定義

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

• 定義數據
• 定義地圖交互
• 定義異常狀態反饋
• 定義排序規則
• 定義狀態機

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

六、總結&思考

前期設計環節考慮越充分，越能保障后續實現的質量。所以還是有必要梳理PRD規范。當生產中的每個環節都保證生產質量，從整條生產鏈來看，會節省了不少“補鍋”成本，也就是“1-10-100”理論。

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

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

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

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

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

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

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

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

本文由 @wenda 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。