01 前言

寫PRD是產(chǎn)品經(jīng)理的基本功，但很多時候，我們無法得到系統(tǒng)的指導，全靠野蠻生長，簡稱野生產(chǎn)品經(jīng)理。我們的PRD可能會面臨很多問題，在開發(fā)過程中由于需求描述不明確，不斷地進行修改最后導致延期。文檔被領導挑出毛病，打擊自信心，在同事中信譽度降低等等。

減少無效的溝通，提高工作效率，是一篇清楚的PRD帶來的好處。

02 什么是PRD？

（1）PRD是什么

PRD是Product Requirement Document的簡稱，我們叫它產(chǎn)品需求文檔，它的誕生意味著產(chǎn)品從概念化到圖紙化的進化。

（2） PRD的對象有哪些？

以開發(fā)團隊為主的研發(fā)、測試、視覺設計師、交互設計師等相關業(yè)務人員。

（3）PRD有什么作用？

• 研發(fā)根據(jù)PRD進行開發(fā)邏輯，并進行代碼編寫
• 測試根據(jù)PRD編寫測試用例，進行后期的測試
• 視覺與交互設計師根據(jù)PRD設計
• 作為記錄邏輯的文檔，以便時間長了忘記邏輯可以翻看以前的文檔
• 確保項目組所有成員對此次迭代內(nèi)容達成共識的記錄
  
  

03 寫之前需要注意的問題

（1）這個需求在解決什么問題
很多情況是一個需求提過來，產(chǎn)品經(jīng)理立馬著手開始設計，甚至有時候需求方會附帶自己的設計方案，有的產(chǎn)品經(jīng)理也沒有經(jīng)過思考直接就執(zhí)行了（早些時候我也這么干過，別人指哪打哪）
事實上一個需求最重要的是發(fā)現(xiàn)問題，發(fā)現(xiàn)問題比立馬出解決方案更加重要。因為沒有探究問題是什么，可能一開始設計的方向就是錯的了。

我們需要考慮以下內(nèi)容：

• 這個需求解決了誰的問題？這個誰可能是用戶，可能是其他需求方如老板、運營、市場
• 問題的本質是什么？是不是如需求方所說？

這里有一種設計技巧可以使用，叫做RTPA設計框架，他的核心就是重新發(fā)現(xiàn)問題。我們可以使用以下的步驟：

設計思路

可以看到，最后才是設計，在設計之前我們重點要搞清楚的是問題所在。

（2）需要多少資源
為實現(xiàn)這個需求，需要多少資源，多少人力，多少時間來完成，需要做一個大致的評估。

（3）是最簡單的解決方案嗎？
當前的設計是最簡單的解決方案嗎？實現(xiàn)起來難度怎么樣？值不值得去做？

（4）有風險嗎？
主要考慮做出來后能不能投入使用，會不會違反法規(guī)，或者違反第三方的規(guī)則導致不能使用?；蛘吖δ軙绊憚e的方面，如線上bug引起的崩潰，或者導致什么數(shù)據(jù)下降。

（5）設計是否創(chuàng)新
有沒有調研過競品對于這個功能是怎樣設計的，對于這個問題是怎么處理的，有沒有行業(yè)內(nèi)比較先進的做法。

總之，我們在設計之前需要考慮以上的問題，想清楚了再進行設計，可以少走彎路。

04 編寫步驟

做完了設計之前的工作，就可以開始設計了。編寫中有三個大的方向：
（1）搭框架
這一步主要定產(chǎn)品的大致框架，包括產(chǎn)品架構、信息架構、功能結構。
首先通過角色將系統(tǒng)劃分開，系統(tǒng)中又包含子系統(tǒng)，再將系統(tǒng)中的功能按照模塊劃分成功能模塊，再列出每個模塊下的功能就成了。

• 產(chǎn)品框架

  
  
  智慧城市產(chǎn)品架構圖

• 信息架構

  
  
  外賣平臺信息架構圖

（2）業(yè)務流程
分為主業(yè)務流程和子業(yè)務流程。每個業(yè)務中包含業(yè)務流程圖、狀態(tài)流轉圖、時序圖。
業(yè)務流程圖：

評價流程圖

狀態(tài)流轉圖：

狀態(tài)流轉圖

登錄時序圖：

時序圖

（3）文檔細節(jié)
在對功能的描述中，【輸入】【處理】【輸出】是最關鍵的步驟，用戶在前置條件下進行輸入操作后，系統(tǒng)會進行怎樣的處理，最后輸出什么樣的結果。文檔主要在描述這些內(nèi)容，以及一些有輔助作用的數(shù)據(jù)表，交互細節(jié)等。

05 文檔組成部分

1. 修訂記錄

記錄每次文檔的修改信息，主要有，修改的功能、具體內(nèi)容、修改的時間、誰修改的等信息，以便在以后查找起來方便。在Axure之類的平臺中做文檔還可以對每次修改添加一個超鏈接，快速定位到迭代。

2. 項目背景

從現(xiàn)狀、方案、目標3方面描述。

• 現(xiàn)狀：描述當前需求方遇到的問題，最好能跟價值模型關聯(lián)；
• 方案：針對這個問題，所提供的解決方案概述；
• 目標：期望獲得多少價值指標提升；
  通過項目背景的描述，可以讓項目參與者感受到自己的工作價值。

3. 項目范圍

列出項目架構圖和功能結構圖。

4. 全局說明

主要包含需要對全局統(tǒng)一處理的一些描述，如名詞解釋、異常流程處理、其他默認規(guī)則。

• 名詞解釋
  將一些不常見的，比較晦澀的名詞列出并解釋，以便大家的理解，與共識。

• 異常流程處理
  斷網(wǎng)處理、無法預知的異常報錯、服務器錯誤處理

• 其他默認處理
  加載方式、列表顯示數(shù)據(jù)量、缺省顯示

5. 業(yè)務流程

列出核心業(yè)務流程與子系統(tǒng)業(yè)務流程，一般功能性的業(yè)務流程都在功能描述里寫。

6. 項目風險

了解有關的法律法規(guī)，有與第三方合作的需要了解別人的規(guī)則，提前避免風險。
或者功能會影響別的方面，如線上bug引起的崩潰，或者導致什么數(shù)據(jù)下降。

7. 需求優(yōu)先級&干系人

主要記錄相關的需求是誰提的，以便有不清楚的地方可以快速定位到相關人員。

8. 功能需求

這塊是細節(jié)最多的地方，每個功能說明都包含：設計背景（非必須）、功能描述（非必須）、用戶場景（非必須）、輸入/前置條件、后置條件、界面交互、業(yè)務流程、分支流程、異常處理、數(shù)據(jù)字典（非必須）

• 設計背景
  非必須的元素，我習慣在交代功能之前，描述一下這個功能是怎么來的，是誰提出的，為什么要做，這樣執(zhí)行者看了不會覺得這個功能沒有必要，反而還會幫忙思考怎樣實現(xiàn)更加簡單。

• 功能描述
  對這個功能是用來做什么的，進行一個描述

• 用戶場景
  用戶在什么樣的情況下進入這個操作

• 輸入/前置條件
  要操作這個功能，需要有什么條件，如什么角色，什么權限，處于什么狀態(tài)，需要輸入什么

• 后置條件
  進行了操作會輸出什么，數(shù)據(jù)會有什么變化，頁面會有什么跳轉

• 界面
  每個界面可以拆解出很多元素，如視頻、音頻、圖片、按鈕、文字等等。
  表單的每個元素要描述是否可為空、是否有初始內(nèi)容、是否默認選中、是 否有字數(shù)限制等，還有對應的錯誤提示；
  文本：最大顯示長度，超過怎么處理；
  鏈接：指定點擊后跳轉到哪個頁面；
  圖片：顯示的比例，缺省和加載失敗的顯示；
  數(shù)據(jù)：寫死還是通過后臺配置；
  最好使用圖片和文字解釋結合的方式，確保原型上要表達的和文字記錄的符合。

• 業(yè)務流程
  業(yè)務流程圖、子業(yè)務流程圖（根據(jù)合適的顆粒度拆分）與別的狀態(tài)圖之類的展示，也需要流程圖和文字解釋結合。

• 異常
  列出能夠預知的異常情況，并有對應的處理方案。如網(wǎng)絡錯誤、提交失敗、服務器錯誤等等。

• 數(shù)據(jù)字典
  這步也是非必須的，列出來也只是給研發(fā)一個參考，我們自己也要大概清楚這個功能有哪些字段。

9. 非功能需求

• 埋點需求
  我們需要采集的數(shù)據(jù)在這個功能里需要在哪里埋點。需要提供一個埋點需求表給研發(fā)。包括埋點的元素，觸發(fā)的條件、采集的維度等。

• 監(jiān)控需求
  監(jiān)控某些接口，或前端元素，在發(fā)生異常時進行預警通知，能讓我們提前知道異常并有所準備。

• 性能需求
  需要支持多少并發(fā)，如果是第三方服務的話需要多少額度。

• 兼容性需求
  需要兼容哪些設備，哪些瀏覽器版本之類的。
  
  
  

06 示例

這里的示例針對上面的第8點功能需求進行舉例說明。

（1）功能描述
提供給商戶進行賬號登錄。

（2）前置條件
輸入正確的賬號和密碼進行登錄操作

（3）后置條件
登錄成功后，根據(jù)用戶登錄的賬號與對應的角色進入到相應的首頁。
如果選擇了記住密碼，需要保持登錄30天，每一次登錄都刷新這個token記錄。

（4）界面

登錄管理后臺

界面元素說明

（5）業(yè)務流程

登錄業(yè)務流程

業(yè)務流程步驟說明

（6）異常流程

（7）數(shù)據(jù)字典

登錄數(shù)據(jù)字典

07 PRD模板

鏈接如下，自取哦~
鏈接: 鏈接: https://pan.baidu.com/s/1eXxbwwrZSAqEhnj4nBZIcA
提取碼: rkxv