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

作為一名產品經理，撰寫PRD文檔是基本功之一，但依舊有很多同學寫不好高質量的PRD。那么該如何寫出高質量的PRD，應對后續工作呢？作者結合自己的實戰，與你分享了一些技巧，希望對你有所幫助。

需求文檔PRD是產品經理最基本的工作。優秀的產品經理一定能寫出優秀的PRD，不能寫高質量PRD的產品經理大概率不是優秀的產品經理。

今天筆者同大家一起聊聊寫PRD那些事兒。

本文的前提是需求已經規劃好，你拿到自己的需求開始做產品規劃。

一、PRD的目標用戶

寫好一份的PRD其實并不容易，首先PRD的讀者就需求就很難統一。

• 老板：有些老板會看產品的PRD，如果你的老板是產品經理，那么很好，他能夠給你提出專業的改進意見。如果缺乏產品經驗，那么就看老板的個人偏好了。有注重產品價值的，有注重功能合理性的，有注重成本的，有注重UI是否好看的。
• 業務：業務的水平參差不齊，有點非常懂業務，但是不一定懂技術。有的就只是一個傳聲筒，不會思考，很難給出你建設性的建議，甚至起到反作用。
• 設計師：UX/UI設計師需要根據你的PRD進行產品設計。那么需要你將業務需求完整的傳達給他們，才能夠產出一份高質量的設計。
• 開發：需要結合你的PRD和UX/UI完成產品開發，而開發又可以分為前端開發和后端開發，需求也是存在差異的。后端開發更關注業務邏輯，前端開發更關注交互邏輯。

對于優先級，我個人的建議是：開發>設計師>業務，老板視情況而定。業務結合UI溝通效率更高，跟設計師則可以在線下持續共同需求。但是產品經理對開發過程的參與度很低，同時開發過程也是人力、時間成本投入最高的，一旦因為PRD描述不清導致開發事故，糾錯成本就會很高。

二、寫PRD前的準備

產品經理尤其是經驗較少的產品經理，要避免拿到需求就開始“高效”輸出PRD的誤區。否則很可能寫出自己覺得非常完美，但是被老板和業務劈頭蓋臉狂噴的PRD。

俗話說“磨刀不誤砍柴工”，要避免寫出自嗨的PRD，需要先了解用戶需求。

• 用戶是誰：你本次需求面向的用戶是誰？有什么特征？
• 使用場景：該類用戶在什么場景下會使用你的功能？該場景有什么特征？
• 使用目的：該類用戶在為什么在某種場景下要使用你的功能？想到達到什么目的？
• 如果不夠了解需求的背景和用戶需求，如何高效的進行了解，也是一門學問：
• 翻閱公司的關聯文檔，比如有沒有用戶畫像、用戶訪談或相近需求的產品文檔，站在前人勞動成果之上去寫PRD，能起到事半功倍的效果。
• 請教自己的老板或有經驗的同事、朋友，但是務必在請教之前，自己先進行思考，總結自己的困惑，有針對性的提問。不要浪費對方時間。
• 自己到網絡上檢索相關的資料，自行學習。這個相對來說效率會比較低，但是比較通用。畢竟不能總依賴同事，公司也不一定有資料積累。自己掌握高效獲取信息的方法，才是根本之道。
• 如果功能非常重要，能申請到UED資源去做用戶調研就更好了。這是個非常好的成長機會，不僅能夠讓你更了解用戶，還能豐富你的產品能力和閱歷。
• 再舉個具體的例子。

例子：

背景：你在一家電商公司工作，現在公司想要做一個商品推薦的功能，并且將工作分配給了你。

你拿到需求之后，開始思考，這個推薦功能是面向所有用戶的嗎？顯然不是，對于那種有明確購買目標的用戶似乎不適用。

于是你查看公司的用戶畫像，發現主要用戶分成如下幾類：

• 小美：女大學生，喜歡在平臺上瀏覽商品，經常會購買一些物美價廉的小商品。
• 小英：女白領，收入較高，喜歡在平臺上購買大品牌的商品。
• 小計：家庭主婦，喜歡在平臺購買折扣的母嬰、日用品。
• 小直：IT男，收入較高，消費頻次低，消費目標明確。搜索、對比商品完成交易。

這時你發現，小美、小英、小計都能作為商品推薦的目標用戶。于是你跑去找Leader，問他是要為這三類用戶都做推薦嗎？你的Leader摸著腦袋不好意思的笑了，說“這次是想為一些小商家做商品推薦，幫他們提高客流量，工作太忙，忘記跟你交代了”。

于是你知道小美是你最主要的目標用戶，需要針對年輕女性的偏好做推薦，使用的場景集中在非工作時間。需求的方向終于確定了。你在腹誹Leader的時候，也為自己的機智點贊。

如果你再多想一步，還會注意到公司目前的戰略方向是吸引小商家，那么不止是推薦商品功能可以做，店鋪推薦、小商家流量折扣等功能都可以做。

三、功能拆分

了解了用戶需求之后，就可以開始產品功能設計。產品設計的第一步就是做功能拆分，功能拆分好之后，才好對每個功能展開描述，撰寫PRD。我習慣按照敏捷開發的思路進行。

1. 拆分原則

功能拆分應當基于INVEST和MVP的原則，以使拆分的功能更合理。

INVEST用于拆功能，將復雜、龐大的功能（Epic、Feature）拆分為簡單、微小（Story）的功能。不了解Epic等含義的，可以自行了解敏捷開發的方法，在此不能面面俱到。

1. Independent（獨立原則）

指的是用戶故事（Story）需要彼此獨立，低耦合。應當做到功能在業務流程、功能界面、數據、用戶目標等層面的低耦合。這樣做的好處是有利于靈活的選擇Story規劃、設計、開發和驗收。比如“登陸賬號”和“登陸密碼”不是獨立的，“手機登陸“和“郵箱登陸”是獨立的。

2. Negotiable(可協商原則）

指的是用戶故事應當是可協商、可討論的，不能是定死的。不要把用戶故事寫成合同，事無巨細，不可更改。應當在不斷的討論、細化中成型。

3. Valuable（有價值原則）

指用戶故事對于用戶來說是重要的，有價值的。這個不用贅述，是產品功能最基本的要求。同時價值也決定了用戶故事的優先級。

4. Estimable（可估算原則）

指開發團隊能夠根據用戶故事估算所需的工作量。包含兩層意思，用戶故事是可實現，且方便開發團隊預估開發工作量。比如“根據用戶心情改變手機主題”在現有技術條件是不可實現的，“根據天氣、節日改變手機主題”是可以實現的且可估算的。

5. Small&Similar Size（規模小且適中原則）

功能越小，排期預估越準，但是過小也會導致管理難度增大。并且多個用戶故事之間的開發工作量差異不宜過大。所以要根據團隊的情況，切分出大小合適的功能，以能夠在一個迭代內完成幾個用戶故事。比如登陸功能可以分成手機號、郵箱、第三方等登陸方式，可以將每種登陸方式單獨拆出來，根據優先級和資源情況安排迭代。

6. Testable（可驗證原則）

指用戶故事必須是可以被驗證的。我認為可以分成三個層面理解。

1. 功能設計階段，能夠去驗證用戶故事的價值、合理性。
2. 開發實現階段，能夠有清晰的驗收標準，確認開發結果滿足設計需求。
3. 發布跟進階段，能夠收集到明確的市場反饋和效果判斷標準，以判斷是否達到設計預期，方便后續的迭代優化。

MVP(Minimum Viable Product)最小可行產品是極其重要的原則。無論公司大小，團隊資源多少，按照MVP都能夠保證項目團隊一直在做最重要的事情。

比如騰訊在開發微信的時候，也需要考慮投入產出比（ROI），先把只有基本聊天功能的微信推向市場，在用戶的使用過程中不斷驗證、迭代，逐步完成了今天龐大的微信生態。如果微信一開始就試圖打造一個生態，相信對于張小龍也是不可能完成的任務。

2. 分析方法

分析方法有很多，我個人最推崇流程分析法，并且一直在使用。比如我在《產品“無”之道》中提到的例子，新手產品經理可以先只考慮業務流程，按照業務流程去做頁面和功能的拆解。

分析業務流程時，強烈建議使用泳道流程圖，幫助自己將業務流程分析清楚。

3. 優先級確認

將功能拆分完之后，還需要根據用戶故事的優先級，確認開發順序。重要的優先開發，相對不重要的后開發，一旦發生風險，可以去掉最不重要的用戶故事。

一般按照重要緊急程度劃分優先級，可以從如下幾個角度考慮：

• 長期vs短期
• 深層vs表層
• 簡潔vs復雜
• 普世vs特殊
• 緊急vs不緊急

一般來說，前者重于后者。但是也有特殊情況，比如最重要客戶的特殊需求，也當優先處理。

基于上述的判斷標準，我個人會將功能劃分為四大類：

1. 核心功能（痛點）：缺少就不能滿足業務和用戶的需求。比如電商的付款、社交軟件的文字聊天。
2. 次要功能（癢點）：沒有也能用，但是有用戶用的更舒服。比如電商的購物車、論壇的點贊。
3. 亮點功能（爽點）：在行業內顛覆式創新的功能，別的競爭對手都沒有，一旦上線能讓用戶非常爽。比如微信的搖一搖，360的免費。
4. 其他功能：跟業務關系不大，但是不得不做的。比如法律合規、政策要求等。

亮點功能是可遇而不可求的，并且一個亮點功能會隨著競爭對手的跟進，逐漸轉變為核心功能或次要功能。因此我們能做的就是優先把握核心功能，逐步補充次要功能，準備應對其他功能。

四、案例實戰

以上圖的在線寫作業為例。建議新手產品經理一定要先做加法，盡量羅列相關的功能。我就不按照標準的用戶故事格式寫了，感興趣的讀者可以自行練習。

• 查看作業題：學生要能看到作業題。
• 作答題目：學生要能作答。
• 類似例題：如果學生遇到不會的題目，還能查看例題。
• 自動保存：萬一發生突發斷開情況，可以讀取自動保存信息。
• 作業草稿：寫到一半要去做別的事情可以先離開。
• 錯別字糾錯功能：自動識別回答里的錯別字，提示學生。
• 提交作業：寫完作業之后提交。
• 空白題目提示：提交作業時有沒做的題目進行提示。

然后將題目按照需求類型和優先級分類：

• 核心功能：查看作業題（P0）、作答題目（P0）、提交作業（P0）
• 次要功能：自動保存（P1）、作業草稿（P1）、空白題目提示（P2）
• 放棄功能：類似例題（需要有后臺功能支持，且工作量巨大）、錯別字糾錯功能（容易讓學生養成依賴）

選擇P0、P1的用戶故事開發，畫出流程圖如下：

到這里就做好撰寫PRD的準備了。下面繼續講撰寫PRD的具體技巧，如何能夠寫出一份自己和團隊都能夠讀懂的PRD。

1. 通用建議

寫PRD有一些通用的tips，可以讓你的PRD更易于閱讀。

1.1 提供流程圖

除了上傳自己在準備階段梳理的整體業務流程圖，如果某些Story的功能仍然比較復雜，那么也應當梳理出流程圖，幫助閱讀者對story有個全面的理解。

1.2 使用專業、共識詞匯

專業詞匯可以分為IT行業通用詞匯和行業詞匯，需要你在工作和團隊溝通中不斷積累。比如：

• IT行業通用：
• 行業：流量、焦點小組、UGC、PGC、OGC、KOL等。
• 設計：banner、按鈕、滑塊、輸入框、單/多選等。
• 前端開發：JS、CSS、HTML、WEB端、移動端、URL等。
• 后端開發：API、數據庫、SQL、解耦合、并發、同步/異步等。
• 測試：冒煙測試、黑/白盒測試、bug、回歸測試等。
• 數據分析：PV、UV、visits、點擊、轉化率、漏斗、用戶畫像等。
• 行業詞匯：因不同行業而異。比如電商、社交、在線教育等都有各自的專業詞匯。
• 共識詞匯：指的是團隊合作中大家常用的溝通用語。很多大廠的共識詞匯甚至可能演變成行業通用詞匯，即“互聯網黑話”，比如賦能、拉通，組合拳、閉環、顆粒度等。個人不太喜歡這些詞匯，有點過于濫用了。

1.3 提供概念詞典

當你文檔中出現一些不常見、復雜、有歧義的詞匯時，建議列出你的概念并進行嚴謹的解釋。放到“需求描述-業務規則”中最佳，方便閱讀者在了解需求時對照查看。

1.4 使用在線文檔

PRD最好寫到在線文檔中，與使用word等離線文檔相比好處非常明顯，更新之后開發、測試可以直接閱讀最新的文檔，不需要產品先發送文檔，開發、測試再下載更新。

現在在線文檔的種類非常多，并且功能越來越強大、體驗也越來越好，并且很多提供了歷史版本的功能，方便對比查看。

2. PRD的結構

日常迭代的PRD，內容我一般寫的比較簡單。包括：

①版本說明

②需求背景

③業務流程

④需求列表

⑤需求描述

• Story
• 流程圖
• 界面描述
• 業務規則

2.1 版本說明

版本說明用于記錄PRD的更新歷史，方便開發、測試了解PRD都更新了哪些內容。

• 版本號：記錄更新的次數，1.0，2.0…即可。加一位小數是為了讓開發團隊看起來更親切，哈哈。
• 日期：PRD更新的日期，讓開發團隊了解需求是什么時候更新的。
• 負責人：更新PRD的人，產生疑問時方便跟進。
• 版本內容：描述本次更新了哪些內容，包括那個Story的哪個具體功能、新的需求的概括。

對于非常重要的更新，建議使用不同顏色字體，以引起開發團隊的注意。注意，開發過程中的變更一定要經過開發團隊的確認，產品不能擅自更改。

2.2 需求背景

目的是向設計師和開發團隊解釋清楚為什么要做本次需求。團隊不了解用戶需求，也能做設計和開發，但是基本做不出來優秀的產品。

設計師大多是有表達欲望的，尤其在更有發揮空間的色彩和圖案層面。如果設計師不了解需求背景和用戶，就只能根據自己的想象去做設計，做出的交互方式以及內容展示的重點很難滿足業務和用戶需求。比如你想突出產品特點，設計師做成了突出產品外觀。

一個優秀的開發是需要能從業務和用戶的角度思考的。拿到同樣的需求，不同能力的開發交付的產品是不一樣的。這種差別，不止體現在代碼的可用性、兼容性、魯棒性等技術層面，還會直接影響用戶體驗。比如了解用戶的算法工程師，能夠完成更符合用戶需求的產品推薦；前端工程師能夠開發出反饋更恰當、更及時、更絲滑的效果，讓用戶用起來更舒服。

需求背景描述應該使用5W1H的方法，即What、Where、When、Who、Why、How。根據需求的復雜程度從用戶需求（必選）、業務需求（推薦）等方面描述。

What：做什么功能。

• 用戶需求：我們要做一個什么樣的功能滿足用戶。例如：做一個商品搜索欄。
• 業務需求：我們要做一個什么樣的功能滿足業務。例如：做一個優先推薦利潤高產品的搜索欄。

Where：使用場景是什么。

• 用戶需求：用戶在什么場景下使用。例如：在用戶有明確購買目的場景下使用。
• 業務需求：業務對該功能的依賴場景是什么。例如：幫助商品初次觸達用戶的場景下需要。
• When：一般什么時候使用。
• 用戶需求：用戶什么時間使用較多。例如：用戶剛進入APP時最容易使用搜索欄。
• 業務需求：什么時候去實現業務需求。例如：用戶使用搜索欄搜索時。

Who：誰的需求。

• 用戶需求：哪些用戶會使用該功能。例如：所有用戶都會使用搜索欄。
• 業務需求：哪些業務對功能有依賴。例如：所有商品對搜索欄都有依賴，小品牌依賴度更高。

Why：為什么要做。

• 用戶需求：用戶為什么要使用該功能。例如：為了更快的找到想買的東西或品牌。
• 業務需求：業務為什么需要該功能。例如：除了能高效匹配用戶和商品，還能通過結果排序盈利。

How：怎么做。

• 用戶需求：如何做該功能以滿足用戶需求。例如：在首頁增加搜索欄。
• 業務需求：如何做該功能以滿足業務需求。例如：搜索欄能夠搜索到全部商品并按照業務規則排序展示。

在剛開始時，建議按照上述的格式自己列出來，再寫成方便閱讀的連貫文字。等到輕車熟路之后，就可以直接動筆，邊寫邊梳理了。

2.3 業務流程

推薦以泳道流程圖的形式展示，案例請看《如何寫出一份優秀的PRD-準備篇》。想畫好流程圖其實也不難，掌握以下幾個要點即可。

• 橫向列出功能相關的角色，例如用戶、后臺、運營等。
• 縱向列出功能相關的業務環節，例如挑選商品、下單購買、訂單處理等。
• 按照業務（數據）流程推進，將對應的行為、處理寫到對應角色下。
• 判斷使用分支結構，務必使用多層二分法覆蓋所有情況。
• 巧用循環結構，減低流程圖復雜度。比如某個分支流程需要返回之前的流程，那么就可以使用循環結構。
• 所有的分支必須閉環，及指向結束。

2.4 需求列表

按照需求的優先級，從高到低依次列出本次需要開發的功能。方便開發測試優先完成高優先級的需求，一旦發生延期風險，可以放棄開發后面的低優先級需求。

• 需求名稱：為需求起個簡潔的名稱，方便溝通。例如搜索欄。
• 模塊/子模塊/頁面：方便開發團隊理解該功能在那個頁面實現。
• Story：描述該需求的用戶故事。要用“作為一個用戶（As a user），我希望（I want）什么功能，以（so that）滿足什么商業價值“的標準格式描述，以講清楚該需求的目標用戶、功能和價值。
• 需求來源：講清楚需求的來源，方便后續跟進。
• 優先級：需求的優先級，優先級的評估同樣可以參考準備篇。

2.5 需求描述

下面就到了PRD的重頭戲：需求描述（或功能描述）。一個功能設計是否合理，能否被設計和開發團隊讀懂，設計、開發出滿足用戶需求和業務需求的產品，都要依賴需求描述的合理性。

Story：

再次重申Story，避免閱讀者返回需求列表查看。

流程圖：

對于復雜的功能，建議詳細的畫出流程圖。簡單功能可以省略。

界面描述：

在與設計團隊對接時，推薦使用手繪原型圖。因為懶得畫了，就想到網上找一些。很多手繪原型圖畫的都很好看、很精細，但是我覺得不是很合適。

如果有專業的交互設計師，這反而是對他設計的一種限制，以你的不專業影響了他的專業。如果需要你自己做交互設計，那么也沒必要在手繪上畫這么多時間，直接用工具做反而更好。

我個人認為畫到如下程度就可以了。

在評審前，記得把手繪原型圖替換為帶標注的UX。雖然你更新起來會比較麻煩，但是對開發團隊來說，閱讀十分方便。下圖是我幾年前做的一個后臺系統的交互及標注，供參考。

業務規則：

業務規則是PRD中最核心，也是最難描述的部分。功能的流程、頁面的導航、界面設計、組件功能、提示文字、異常情況等都需要在業務規則中描述清楚。個人的一些描述習慣如下。

• 從主要流程到分支流程。比如訂單處理，應該優先描述正常的訂單流轉流程，再描述特殊訂單的處理流程。
• 從主要頁面到次要頁面。一個流程中可能涉及多個頁面，那么應該按照主線將主要頁面描述清楚，再描述次要頁面。比如訂單列表、訂單處理頁為主要頁面，訂單流轉等為次要頁面。
• 從一般頁面狀態到特殊頁面狀態。一個頁面可能會分成多種狀態，比如一般頁面、空頁面、報錯頁面等，那么應當優先描述清楚一般頁面，再講清楚特殊頁面及其出現條件。
• 從上到下描述頁面功能。這樣描述會比較符合前端開發的習慣，從上小到下逐個完成頁面布局和功能的開發。比如從頁頭、標題、搜索欄、主要功能區、到底部導航欄等。
• 描述清楚每個功能區。首先描述清楚每個功能區的作用是什么，然后是使用什么控件，接著交代清楚默認狀態、功能邏輯、功能限制等，最后補充報錯情況。

比如描述一個用戶留言框：

• 讓用戶輸入留言保存并展示；
• 默認為空，顯示提示文案”請輸入留言“；
• ≤100字，過長無效；
• 提交時校驗是否為空，若為空則報錯”留言不能為空“；否則校驗是否有敏感詞，若存在則報錯”存在敏感詞，請修正后再試“；否則提交并保存用戶留言。
• 從以上描述可以看到雖然一個輸入框很簡單，但其實要包括前端的展示、報錯，以及后端的提交和儲存。只不過這個控件很常用，可以約定俗成的簡單描述。比如有標準的交互規范，可以描述為”用戶留言默認為空，≤100字，需要空內容和敏感詞校驗“。

對于具體的文字描述，同樣有一些原則，整理如下：

• 要符合MECE原則，即 Mutually Exclusive Collectively Exhaustive，“相互獨立，完全窮盡”。我們在描述需求的時候，一定要考慮所有的情況，并給出應對方案。為了避免遺漏，最好借助坐標軸、集合關系圖、腦圖等方法。

描述邏輯清晰。因為受個人思維習慣的影響，所以想講清楚什么是邏輯清晰比較困難。大概就是符合大多數人的認知規律，能夠按照時間先后、因果、主次、關聯、整體與部分等關系，合理的將產品功能描述清楚。因此更多的需要把功夫花在平時對自己的訓練上，多讀一些科學、哲學相關的書籍。

用語簡潔。這個很好理解，沒有人喜歡又臭又長的需求文檔，要用盡量精簡的語句，將產品功能描述清楚。比如：

• 描述不必事無巨細，抓住重點描述。比如”當用戶滑動并看到按鈕時，可能用手點擊按鈕“，改為”當用戶點擊按鈕時“。
• 盡量用短句，減少長句。比如”當用戶點擊輸入框彈出鍵盤輸入文字并顯示“，改為”1.點擊輸入框，2.彈出鍵盤，3.顯示輸入文字“。
• 避免抽象詞匯，選用具體詞匯。比如”輸入文字不能太多“，改為”輸入文字≤100字“。
• 不必有客套話，直接描述。比如”請開發大大注意不能提交空內容，謝謝“，改為”檢驗是否為空“。
• 不必用華麗的辭藻修飾，要用精確的修飾。比如”頁面切換時要如牛奶一般絲滑“，改為”頁面切換要平滑“。
• 減少語義重復的語句。比如”按鈕要大、明顯、容易點擊“，改為”按鈕要方便點擊“。

使用專業詞語。文章開篇已經交代過。使用專業詞匯除了方便閱讀，同時也能極大精簡語句。比如”內容過多時，輸入框旁邊要出現滑塊，拖動滑塊可以改變顯示文章“，改為”輸入框內容過長顯示滾動條“。

避免歧義。在寫功能描述時，一定不要只考慮自己頭腦中的概念，要考慮自己的措辭是否會造成誤解。

• 盡量使用數字、公式、圖表。比如”輸入不能多于100字“，那么輸入100個字是否允許呢？最好描述為”輸入≤100字“。
• 避免主體及對象模糊。比如”前端負責提示，后端負責提交數據。其還要負責埋點?！扒昂蠖硕伎梢詫崿F埋點，因此要注意指定清楚。
• 可以使用縮寫，但是不能產生二異性。比如”后臺“可能指程序后臺，也可能指運營后臺等。如果可能讓人誤解，就必須描述清楚。
• 其它的行文技巧。比如注意多音字、多義詞、定語范圍等。

最后是要有一個清晰的排版。每個人都有自己的排版技巧。在此就不跟大家介紹了。

關于如何書寫PRD的分享就到這里，希望對你有幫助。

親，請不要吝惜手中的票票，給筆者繼續做產品經驗分享的動力。

為我投票

我在參加人人都是產品經理2022年度作者評選，希望喜歡我的文章的朋友都能來支持我一下~

點擊下方鏈接進入我的個人參選頁面，點擊紅心即可為我投票。

每人每天最多可投35票，投票即可獲得抽獎機會，抽取書籍、人人都是產品經理紀念周邊和起點課堂會員等好禮哦！

投票傳送門：https://996.pm/YyDmr