本文以一個積分模塊為例，試圖給出一個PRD的寫作模板供大家參考。並對一些產品人對於PRD的思維誤區談談自己理解。

一.三步完成PRD撰寫

步驟1.功能概述：主要回答這個功能是幹什麼的

舉一個當年自己剛工作時設計的積分模塊案例：

本模塊具體PRD模板如下：

一、功能概述

1.1 功能場景基於連鎖超市線下消費導流使用的網店積分系統，用戶在線下門店或線上消費後都可以獲得積分。積分的使用分為兩種：a.可在線上下單後抵扣配送費;b.抵扣線上消費現金。

通過此模塊增加用戶粘性，加強品牌影響，進而能刺激用戶到店消費。

1.2 模塊用戶連鎖超市線下與網店的消費者。步驟2.需求功能拆分與各模塊對應運作流程功能拆分主要是將該模塊拆分為一個個的功能點，並確定各個功能點之間的邏輯。具體PRD模板如下：二、功能需求2.1 功能概述

表：需求總表

註：優先順序值為1表示優先順序為最高。

關鍵業務流程

步驟2，3.各功能點流程闡述這裡需要闡述清楚的最重要分為兩點

• 說明這個功能點的前後條件分別是什麼？用戶在什麼時候會觸發這個功能？比如多次輸入錯誤某信息，還是多次點擊。
• 此外還要說明的一點是這個模塊的輸入輸出分別是什麼，也就是用戶需要在這裡給予什麼信息，而隨著這裡的流程處理完後會返回什麼信息給用戶。

這裡本質上就是在描述這個模型：

我們將需求統一抽象為輸入，在經過系統黑盒處理後，得出結果返回給用戶。而輸入，輸出可能會有限制條件，我們都需要考慮清楚。

具體PRD模板如下：2.2 功能詳情2.2.1 積分生成業務規則1. 線下門店與線上獲得的積分都歸屬到統一的積分賬戶進行管理。2. 積分兌換規則：以每筆訂單扣除所有優惠後（如：積分抵現）用戶最終支付的訂單金額數取整（不足1元的金額捨去）後為兌換基數，按照1元兌換1積分標準進行兌換。前置條件線下：以會員卡為用戶標識線上：用戶登陸，接收到訂單信息。

輸入

消費金額；消費時間；消費場景（線上/線下）。輸出本次消費獲得積分；積分有效截止期（預留欄位，後期可能要擴展新需求）；賬戶總積分。後置條件獲得積分後，返回本次獲得積分數量。業務流程圖

2.2.2 積分消費：運費券兌換

業務規則

1.100積分可兌換1張運費券。2.積分有效期與線下規則一樣，為永久有效（但需要預留可以設置有效期的擴展），運費券有效期為半個月，有效期周期計算公式為從領取的時間T開始計算，有效期等於T+30。前置條件用戶登陸；進入運費券兌換中心後置條件顯示兌換運費券結果（是否成功/失敗原因/兌換數量）。業務流程圖

2.2.3 積分消費：線上抵扣

業務規則1.用戶的積分兌換現金比例為：100積分抵扣5元。2..此處前端定義為訂單模塊，此處不定義獨立頁面只提供操作介面。（和訂單模塊的開發同學定的，他們將會傳的數據，有問題隨時反饋）

前置條件訂單提交且使用了積分，則進行積分扣取動作。後置條件

更新用戶積分中心數據

異常訂單未完成時，即未完成結算，所有積分將被退回至積分賬戶；訂單完成結算後用戶選擇取消訂單，則所有積分不退回。業務流程圖

寫到這可以說一份簡單的PRD骨架就完成了。大家可以根據自己的公司要求進行適當的增添。

接下來讓我們談一點別的。

二.關於寫PRD的一些誤區看法相信很多行業老手在工作了一段時間後都有這樣的想法，我的PRD寫的這麼累到最後開發還是不看，索性我就不寫了，或者簡單寫完了事。只去畫原型與開發溝通，不可否認開發不看PRD的事確實存在，我也遇到過。 記得當年剛參加工作，就是在設計完這個積分模塊，當時項目經理趾高氣揚的告訴我：「你就畫圖去就行了，還在文檔里定欄位，uuid與uid分得清不？」 當時我也是一臉無辜。 但是說回來，開發不看所以我們就真不寫了嗎？答案肯定是否定的。 在我工作這麼久後，我發現其實PRD真正的作用有如下幾個：

a.是否涉及線上參數的配置，初始值的配置是多少與效果如何檢驗

很多時候我們的初始化模塊設計時都有默認配置，比如上文案例中我們定1錢等於1積分,100積分等於1張運費券。 但是這樣的設置上線後經過市場的檢驗後，是否需要微調，機制是否需要迭代，這些都是未知數。而我們需要有一個能將我們所有設計版本進行記錄的統一地方，這裡記錄的是每次經過市場反饋後的修正值，並通過與之前的設計鮮明對比能最大程度上讓自己得到提升。 這裡就像我們高中學慣用的錯題本的感覺。 b.本模塊與其他模塊的相互依賴關係：其他模塊變動時對本模塊造成的影響如果你在一個大公司，你的產品設計不可避免的會與兄弟模塊進行交互。假設你沒有一個詳細的依賴說明，當兄弟模塊進行邏輯修改的時候，你需要花費多大精力才能反應過來會對自己模塊造成影響？而同時你又要如何去進行對應模塊修改？ c.團隊內部規範與降低溝通成本：避免救火隊式產品 日常工作中產品經理作為這個產品的直接負責人，少不了被各種組內召喚去解答各種問題，但是帶來的直接問題是每天留給自己的工作時間就很少了。如果這個時候我們擁有一份完整的文檔，很多時候問題都是可以內部化解的。 例如：A：新客戶的環境的初始化配置是什麼？我：在tower上的客戶管理模塊自己去看。 d.個人經驗財富的積累——產品日記這個也是最重要的一環，我想問大家一個問題，大家覺得產品人競爭門檻在哪？或者說你憑什麼覺得你能拿20-30K的薪資。 這裡不是說你幹了5到10年就行的，而是同樣設計一個積分系統，一個crm系統你能拿出的設計是你在過去10年間經過無數次迭代的結果，將這裡面的坑儘可能的都踩了一遍。 這才是企業願意給你高薪的原因：因為你的設計能讓整個團隊縮短數個月乃至一年的迭代開發周期。

如果想看從零到一的APP如何寫PRD，還可以看看我培訓的學員撰寫的PRD作業：

三爺：最易懂產品PRD撰寫案例分享（建議收藏）?

zhuanlan.zhihu.com

最後：

如果想看更多產品設計的核心教程或者在初級產品經理崗位徘徊了好久沒有出路的同學都可以直接點擊下方關注我的專欄！

推薦閱讀：

相关文章