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

需求文檔PRD是產(chǎn)品經(jīng)理最基本的工作。優(yōu)秀的產(chǎn)品經(jīng)理一定能寫出優(yōu)秀的PRD，不能寫高質(zhì)量PRD的產(chǎn)品經(jīng)理大概率不是優(yōu)秀的產(chǎn)品經(jīng)理。

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

本文的前提是需求已經(jīng)規(guī)劃好，你拿到自己的需求開始做產(chǎn)品規(guī)劃。

一、PRD的目標用戶

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

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

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

二、寫PRD前的準備

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

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

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

例子：

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

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

于是你查看公司的用戶畫像，發(fā)現(xiàn)主要用戶分成如下幾類：

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

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

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

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

三、功能拆分

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

1. 拆分原則

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

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

1. Independent（獨立原則）

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

2. Negotiable(可協(xié)商原則）

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

3. Valuable（有價值原則）

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

4. Estimable（可估算原則）

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

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

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

6. Testable（可驗證原則）

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

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

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

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

2. 分析方法

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

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

3. 優(yōu)先級確認

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

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

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

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

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

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

亮點功能是可遇而不可求的，并且一個亮點功能會隨著競爭對手的跟進，逐漸轉(zhuǎn)變?yōu)楹诵墓δ芑虼我δ堋Ｒ虼宋覀兡茏龅木褪莾?yōu)先把握核心功能，逐步補充次要功能，準備應(yīng)對其他功能。

四、案例實戰(zhàn)

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

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

然后將題目按照需求類型和優(yōu)先級分類：

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

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

到這里就做好撰寫PRD的準備了。下面繼續(xù)講撰寫PRD的具體技巧，如何能夠?qū)懗鲆环葑约汉蛨F隊都能夠讀懂的PRD。

1. 通用建議

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

1.1 提供流程圖

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

1.2 使用專業(yè)、共識詞匯

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

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

1.3 提供概念詞典

當你文檔中出現(xiàn)一些不常見、復(fù)雜、有歧義的詞匯時，建議列出你的概念并進行嚴謹?shù)慕忉?。放到“需求描?業(yè)務(wù)規(guī)則”中最佳，方便閱讀者在了解需求時對照查看。

1.4 使用在線文檔

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

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

2. PRD的結(jié)構(gòu)

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

①版本說明

②需求背景

③業(yè)務(wù)流程

④需求列表

⑤需求描述

• Story
• 流程圖
• 界面描述
• 業(yè)務(wù)規(guī)則

2.1 版本說明

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

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

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

2.2 需求背景

目的是向設(shè)計師和開發(fā)團隊解釋清楚為什么要做本次需求。團隊不了解用戶需求，也能做設(shè)計和開發(fā)，但是基本做不出來優(yōu)秀的產(chǎn)品。

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

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

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

What：做什么功能。

• 用戶需求：我們要做一個什么樣的功能滿足用戶。例如：做一個商品搜索欄。
• 業(yè)務(wù)需求：我們要做一個什么樣的功能滿足業(yè)務(wù)。例如：做一個優(yōu)先推薦利潤高產(chǎn)品的搜索欄。

Where：使用場景是什么。

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

Who：誰的需求。

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

Why：為什么要做。

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

How：怎么做。

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

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

2.3 業(yè)務(wù)流程

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

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

2.4 需求列表

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

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

2.5 需求描述

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

Story：

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

流程圖：

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

界面描述：

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

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

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

在評審前，記得把手繪原型圖替換為帶標注的UX。雖然你更新起來會比較麻煩，但是對開發(fā)團隊來說，閱讀十分方便。下圖是我?guī)啄昵白龅囊粋€后臺系統(tǒng)的交互及標注，供參考。

業(yè)務(wù)規(guī)則：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

親，請不要吝惜手中的票票，給筆者繼續(xù)做產(chǎn)品經(jīng)驗分享的動力。

為我投票

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

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

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

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