稍微有點經驗的產品經理，基本上都會寫好一份PRD，那到底要具備哪些特點，才能讓開發、測試一致稱贊你的PRD？

如果你去采訪幾個周圍稍微有點經驗的產品經理：“你認為你寫的PRD是一份好PRD嗎？”

答案可能會高度統一：“Yes,it is！”

在產品經理崗位上耕耘這些年，我的PRD收到了來自開發GG和測試MM的不計其數的建（pi）議（dou），終于收獲了長足的進步，最近一年寫的PRD在開發、測試團隊中獲得了一致的認可。所以如果你要問我這個問題，我的答案也會是：“Yes,it is！”

但如果再追問一下：“你認為什么樣的PRD是一份好的PRD呢？“

這個時候答案就會千奇百怪了，“思路清晰，排版整齊……”每個人可能都巴拉巴拉列舉一大堆的特征。

在我看來，在一個真正的產品經理眼里，世間萬物，只要是人造出來的，都是產品。產品上市之前，PRD就是產品經理交付的第一個產品。對這個產品經理交付的第一個“產品”，至少應該具備以下4個特點，才能算是一個好的產品（PRD），即：價值明確、考慮全面、可讀性強、修訂留痕。

一、價值要明確

能幫助用戶解決問題，則產品是有價值的；而有價值，是一個產品誕生的原點。產品是為了解決用戶問題的，PRD是為了打造幫用戶解決問題的這個產品而編制的。

那么，你的產品最終要解決的是用戶在什么場景下的什么問題？要實現的定性目標是什么？定量目標是什么？

在你的PRD當中把這些內容寫清楚，一方面，可以讓自己更加清晰地理解和審視項目價值；另一方面，也讓開發、測試同學知道自己要做的工作是有價值的。

這有什么意義？ 這么說吧：

• 有工資拿，我做到朝九晚五；
• 有價值感，我自愿朝九晚九。

讓團隊知道他們做的工作是有價值的，并且讓他們知道能實現什么樣的價值，是凝結一個團隊克服重重困難，滾滾向前的最為重要的力量。因此，一份好的PRD，一定會有關于它的項目價值的清晰描述。

二、考慮要全面

衡量一個產品經理PRD功力的最為關鍵的指標，就是看他是否考慮得足夠全面。我將產品經理考慮全面的功力分成三個段位：

第一級：模塊內全面

在這個段位上，產品經理能考慮到在正常情況下，所設計模塊當中可能的應用場景，每個場景下有哪些分支流程和處理邏輯。

比如：在下單流程中，能考慮到針對接口返回成功、失敗的各種場景的處理邏輯；同時，也能考慮到在正常場景或流程之外，有哪些異常場景，并設計對應的處理方式。比如：下單流程中，接口響應超時場景怎么處理。

第二級：模塊外全面

這個段位上的產品經理，不僅能考慮到所設計模塊的各種正常、異常場景，還能考慮到這個模塊的調整會影響到的其他系統模塊，并在PRD當中給出相應的應對策略。

比如：當你在門票的下單流程中調整了游玩人信息的處理邏輯，你能否考慮到對酒店品類的下單流程的影響。

第三極：擴展性全面

到了這個段位上的產品經理，不僅能對當下的模塊內容的場景考慮全面，還能考慮到未來三到五個迭代版本之后可能的產品形態。

他在自己的設計方案中預留產品擴展空間的同時，也在前期PRD當中對可能的擴展需求進行標注，以提醒開發人員在代碼層、數據結構層預留充分的擴展空間。

比如：你負責了一個旅游平臺訂單重構的項目。在第一個版本中，你只對門票的下單流程進行了重構，但你在前期的方案設計階段，除了對現階段門票訂單的重構方案進行全面的設計，還能考慮到未來1年之中，對酒店、線路品類進行重構時的主要場景需求，并在產品方案中預留出擴展空間以供未來擴展。

三、可讀性要強

這一點應該很好理解，PRD全稱Product Requirement Document，即產品需求文檔。因此，它的本質還是一份文檔，對于開發、測試團隊成員來說，還是一份需要仔細研讀的文檔。對于需要研讀的團隊成員而言，一份可讀性強的PRD可以節省大量的時間，有效提高開發和測試的工作效率。

那么，啥叫可讀性強？

我認為可讀性強的PRD包括三個特點：

1. 一個文檔覆蓋完整需求

這是對于文檔可讀性的最基本的要求，剛做產品那會兒，沉迷于各種所謂的PRD模板和繪圖工具，大致就是用Xmind畫腦圖、用Axure畫原型，用visio畫流程圖，然后再用word寫PRD。

盡管也會在PRD中把重要的界面原型截圖放進去，但有時候，Word無法很好地呈現一些交互效果，或者比較大的visio圖在word里面看不清的時候，開發、測試團隊就需要html原型文件、word、visio幾個文檔一起看，并進行來回切換。有時候也會出現開發人員嫌來回切換麻煩，干脆直接就簡單看看原型圖，之后就按照自己的想法開始coding了。

很顯然，從閱讀體驗來看，用word來寫的PRD很難一個文檔覆蓋完整需求，也不是一份可讀性很強的PRD文檔。

那么，有沒有什么方式是可以實現一個PRD文檔覆蓋所有需求的呢？

在這里推薦一個比較好的寫PRD的方式——直接在Axure原型中撰寫PRD，這也是目前我所在公司撰寫PRD的方式。自從在Axure中寫PRD之后，原型、流程圖、需求說明都被寫在了一個原型文檔當中，開發、測試再也不用幾個文檔來回切換著看了。

另外，除了便于團隊成員在一個文檔中查看完整需求之外，對于產品經理而言也有諸多便利。比如：多文檔無需來回騰挪，調整時只需維護一個文檔即可，無需擔心漏了某個文檔，可以按照頁面撰寫，伸縮性強等等。因此，如果你還在用word寫PRD，建議你趕緊拋棄word，擁抱Axure吧。

2. 文檔有清晰的框架結構

一兩頁就能寫完的小需求PRD，框架結構對可讀性的影響自是不大，但是對于超過10頁的PRD文檔來說，框架結構對于可讀性的影響就比較大了。

經過我多年實戰經驗，化繁為簡，一個好的文檔框架大致是如下一個結構：

• 封面：需求名稱、版本、更新日期、作者等；
• 修訂記錄：修訂時間、修訂人、修訂位置、修訂內容、修訂原因、審核人等；
• 文檔說明：需求背景、解決方案、項目目標、產品范圍等；
• 總體流程/架構：產品架構、主流程、主要功能模塊簡述等；
• 模塊一：模塊名稱、用戶場景、產品用例等；
• 模塊二：模塊名稱、用戶場景、產品用例等；
• 迭代版本1：版本名稱、時間等；
• 迭代版本2：版本名稱、時間等；
• 附錄：會議紀要、遺留問題等。

3. 排版清爽、條理清晰、圖文并茂

好比是人不能只有骨骼沒有血肉，PRD光有一個清晰的框架結構還遠遠不夠，因為開發、測試團隊看得最多還是具體的細化的功能需求，而這些細碎具體的需求內容實際上也是最應該考慮可讀性的地方。

如何提高內容的可讀性？盡可能讓你的需求描述具有清晰的條理和清爽的布局。

幾個提高內容可讀性的小技巧分享給大家：

• 需求描述和原型一一對應，且不宜相隔太遠；
• 圖文并茂，盡量避免整版整版的文字；
• 能用圖描述的，就不要用干巴巴的文字；
• 的確需要大段文字描述的內容，分拆成一個一個的小點描述。

總而言之就是一個原則：讓用戶看起來不那么累。

四、修訂要留痕

需求變更對于產品經理而言是難以避免的，在項目進入開發階段之后，對PRD所做的所有變更一定要留下痕跡，這些修訂痕跡包括兩種：修訂記錄及修訂標注。

1. 修訂記錄

通常情況下，一份合格的PRD里面一般都會標配一個如下圖所示的修訂記錄，這是一份PRD最基本的修訂痕跡。

據我觀察：即便是在我目前這樣一家相對成熟的互聯網公司當中，依然存在大量的修訂記錄形同虛設的情況。要改什么內容，產品經理直接跟開發測試說一下就改掉了。

為什么會這樣？

有的時候可能是因為忙，忘記了；有的可能是因為懶，懶得改；而最主要的原因還是在于產品經理缺少修訂留痕的意識，認為這種細碎的工作沒必要。

實際上這個修訂痕跡是非常重要的，他直接反映了PRD文檔的變遷史，也讓開發、測試團隊對PRD的變化做到同步更新，避免團隊做無用功，避免不必要的扯皮。

由于沒有修訂記錄，跟開發和測試扯皮自然難以避免，即便沒有扯皮，產品最終上線之后的實際情況與PRD有諸多不符，也會逐漸就演變成了給后人挖的一個接一個的坑。有良心的產品經理，不給后人挖坑。

2. 修訂標注

當然，有了修訂記錄痕跡，如果你能秉持著心中的用戶思維，產品思維來對待，你會認為這是不夠的，為什么？

因為開發測試要從你洋洋灑灑十幾頁的PRD當中，找出你改動的那兩段文字依然是一件很困難的事情。

怎么解決開（yong）發（hu）的這個痛點？

對于一名產品經理而言，要解決這個問題實在太容易了，把修訂內容標注出來不就可以了嘛。如果你是用Word寫PRD，解決這個問題簡直soeasy，直接在“修訂”模式下編輯文檔就可以了；如果你是用Axure寫PRD，也不難，只需要把你改動的位置用其他顏色標記一下就可以了。

在這里分享幾個火山的PRD中的一些修訂痕跡：

Word修訂模式標注留痕：

Axure橙色字體留痕：

流程圖橙色填充留痕：

這樣的PRD痕跡可以給開發、測試小伙伴帶來巨大的便利，做起來很容易，也花不了太多時間，當然，要做到前文描述的所有要求其實也都不難，關鍵取決于你是否有這個意識這樣去做而已。

從根本上來說，其實是取決于你是否把你寫的PRD看做是你的一個產品，是否把你的開發、測試搭檔看做是你的用戶。

三、總結

PRD沒有標準，所以什么樣的PRD是一份好的PRD，這實際上是一個仁者見仁智者見智的問題。本文闡述的好PRD的4個特點也僅代表一家之言。

那么，這個問題誰最有發言權？它的讀（yong）者（hu）。

PRD文檔的讀者是誰？UED、開發、測試、業務需求方以及未來要接手你工作的其他產品經理，都會成為它的用戶。

產品好不好，產品經理說了不算，用戶說了才算。所以，回到文章開頭的問題，如果你也認為自己的PRD寫得很好，不妨再找幾個搭檔的開發、測試同學問一下，看看結果會是怎樣……

#專欄作家#

PM火山，微信公眾號：PM火山，人人都是產品經理專欄作家。后臺型產品從0到1負責人?？恐鴮W習、實踐、總結，再學習、再實踐、再總結來讓自己不斷成長的產品人。

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

題圖來自Unsplash，基于CC0協議