寫 PRD 是為了找對問題並解決問題


Posted by Christy on 2021-10-14

本篇為 PRD到底该怎么写?更全面的文档范例来了 閱讀筆記

PRD 的功能與使用者

PRD 是產品項目由「概念化」階段進入到「圖紙化」階段的最重要的一個文檔。

PRD的主要使用對象有:研發、測試、交互設計師及其他業務人員。

《用戶體驗要素》作者在書中有一句很經典的話:「文檔不能解決問題,但定義可以」,PRD就是要定義需求。

寫 PRD 以前,先思考下面七個問題:

1. 解決什麼問題?

RTPA設計框架,是一種逆向思維假設分析,我們要使用這樣一種思考技巧:假設初始需求都是錯誤的,即問題並不存在,你需要重新發現問題。

不要需求方一提需求,就開始著手設計,多問幾個為什麼並著手調查,以瞭解真正的問題。

2. 怎麼衡量?

怎麼知道問題已經解決了?

3. 需要多少資源?

時間、人力的評估

4. 會不會太複雜?

會影響哪些層面或現有產品功能

5. 有風險嗎?

主要是相關政策,是否合法等等

6. 有創新嗎?

調查競爭對手怎麼做

7. 用戶怎麼說?

親身體驗場景與用戶需求

寫PRD的基本步驟

搭框架:先定義所有使用者角色,針對每個角色提供相應功能

定流程:把每個角色與功能串連,讓閱讀者可以瞭解產品全貌

扣細節:主要從輸入、處理、輸出三方面考慮

PRD 的內容

  1. 修訂記錄:檔案更新時間、作者、修訂內容,以便追朔

  2. 全局說明:名詞解釋、錯誤處理、數據規則列表

  3. 項目背景:產品的現狀、方案、目標

  4. 項目範圍:把功能圖列出來

  5. 業務流程:使用上的功能流程吧,像是登入前後之類的

  6. 功能需求:這裡佔的比例最大,主要是用 User Story 的方式描述

    完整的 User Story 包含:

    a. 描述(非必須):功能簡介

    b. 前置條件:角色、權限,例如使用者登入前

    c. 後置條件:例如使用者登入後

    d. 界面交互:定義介面

    e. 業務流程:前後端處理

    f. 異常和分支流程:這裡做登入的錯誤處理

    g. 數據字典(非必須):data base 的定義

  7. 非功能需求:監控流量、性能等等

小結:找對問題比解決方案更重要










Related Posts

Leetcode 刷題 pattern - Next Greater Element

Leetcode 刷題 pattern - Next Greater Element

Angular 入門教學 - 系列文目錄

Angular 入門教學 - 系列文目錄

各種在瀏覽器上發送 request 的方法

各種在瀏覽器上發送 request 的方法


Comments