產品迭代縮影:PRD的撰寫與迭代

24 評論 29270 瀏覽 287 收藏 16 分鐘

文檔能力是產品經理必備的基本能力。

文檔能力是產品經理必備的基本能力,產品經理通過文檔的方式把需求轉化為功能傳遞給項目的相關人員,使相關人員更好的理解功能需求。所以文檔的好壞直接影響到團隊成員對需求的理解程度。

剛入行的產品新人都會優先學習產品需求文檔(下面會用PRD代替)的撰寫和原型的繪制,自己當時也是一樣。當時看了很多產品需求文檔的案例,各種類型、格式的產品文檔都研究過。然后在主流的幾個文檔格式中選擇Axure原型來撰寫PRD,因為Axure做的原型需求文檔,與讀者之間有互動,體驗更加良好而不至于那么單調。

產品需求文檔初成型

剛開始時,在網上的一些模板并結合實際項目來撰寫PRD的,并且PRD和原型圖是完全分開的,也就是說第一次撰寫的PRD只包含一些基本的和公共的信息,比如文檔的修訂歷史、產品說明、版本介紹以及核心的流程圖(如下圖)。其他的細節信息則是通過在原型圖上進行簡要的標注。

后來經歷過幾次的項目開發和迭代之后,發現PRD與原型圖分開管理的方式制作起來十分繁瑣,并且一些小版本的更新會直接在原型圖上更新而忘了更新PRD。而且開發人員、設計師基本上只看原型圖不看PRD,遇到需求問題就直接問PM,這樣就失去了產品需求文檔的意義了。

后來就決定把原型圖與PRD進行統一,上面分散管理的問題也得到解決。并更換為更流行的側邊導航欄、更好的視覺設計,使讀者的閱讀體驗更好。此時的產品需求文檔已經慢慢開始成型。

這個版本可以說是PRD的Beta版,雖然是Beta版本,但是基本功能能滿足我們的需求。

文檔的迭代優化

以Beta版的PRD持續一段時間,經歷了一些項目的沉淀,在項目的使用過程中發現幾個有趣的現象:

  • 開發人員基本上只關注功能的實現,焦點在交互原型圖上
  • 設計師基本上只關注頁面和效果,焦點在原型圖上
  • 測試人員則是側重于功能細節與各種情況的處理方案

可以理解,如果把PRD作為一個產品來看,上面的涉及的人員都是PRD的核心用戶,只不過3種角色的工作性質不同,所以需求不同而已。顯而易見,Beta版的PRD只是把產品相關信息和原型圖進行簡單的結合,并不能滿足上面的需求,所以開發過程中就出現了幾個嚴重的問題:

  • 對原型圖、功能的描述不夠周全,開發經常找PM確認需求上的點
  • 原型圖上沒有添加頁面跳轉信息,導致設計師設計起來有些吃力
  • 沒有把核心功能的流程圖的流程粒度細化到每個操作,增加PRD讀者的理解成本
  • 一些分支流程、特殊情況沒有在文檔中說明清楚,導致測試人員經常找PM確認流程細節,嚴重降低PM工作效率以及增加了團隊的溝通成本。

沒錯,自己挖的坑,跪著也要填完。明確問題所在后,就需要針對性解決。在此之前,需要針對目標用戶進行“用戶調研”,確認一下開發人員、設計師和測試人員這些“核心用戶”的意見和看法。收集他們的意見之后,去「起點學院」購買了一些課程并學習具體的文檔規范,然后閱讀一些與PRD相關的文章,進行分析總結,然后迭代出新版的產品需求文檔。(首頁如下圖)

新版本PRD在實踐中運用之后,之前出現的問題得到了很好的解決,最明顯的是團隊成員找PM確認需求的次數大大降低了,并且開發效率也得到了提高。當然,PM也減少了在溝通上成本。

下面我會通過以下7個方面來對新版PRD進行詳細說明。(文章末尾附有PRD模板Axure文件的下載地址。)

  • 文檔命名
  • 文檔結構
  • 產品概述
  • 全局說明
  • 流程圖
  • 功能需求
  • 非功能需求

文檔命名

文件的命名,只要能告訴別人這個文檔的所包含的必要信息就可以了。對PRD而言,需要讓別人知道這個文檔是什么產品的產品需求文檔,處于什么階段,比如PRD_產品名稱_V1.0.0。不過為了更好的進行統一管理,這里使用采用了下面的方式來對文件名進行命名。

文檔命名規則:【PRD】+ 產品名稱 + 產品版本號

例如:【PRD】微信 V6.6.1

文檔結構

PRD的內部結構,如下圖所示。

主要包含產品概述、全局說明、流程圖、功能需求與非功能需求這5大模塊,每個模塊下方有對應的子模塊,下面進行詳細的介紹。

產品概述

產品概述模塊是用于展示產品介紹、開發規劃以及文檔修訂歷史等基本內容。主要有4個部分:

  • 修訂歷史
  • 開發周期
  • 產品版本說明
  • 產品介紹

首先來看看修訂歷史。

修訂歷史

修訂歷史是展示PRD的修改記錄,里面記錄著產品經理對PRD的修訂的方式以及修訂的內容。一般會放在文檔的第一頁,方便團隊成員第一時間了解到需求是否有改動。而修訂歷史一般會采用表格的形式展示,包含文檔的版本號、修訂日期、修訂方式、修訂人以及修訂內容。

開發周期

開發周期包含兩個模塊,分別是開發周期以及開發計劃。

從上圖可以看出,在開發周期表格中,顯示項目的計劃開發時間。不同的平臺開發難度不同,所以這里也會加以區分。下方的則是開發計劃,在敏捷開發中,都會以一個時間區間作為迭代的里程碑,小步快跑,一步步完成迭代上線。比如說一個移動App,開發的第一階段首先要進行框架的搭建、啟動頁、登錄注冊等基本功能的開發,然后再按照計劃、優先級開發后續的功能。

產品版本說明

版本說明只是展示產品對應版本所包含的核心功能。需要注意的是,這個版本是以上線版本為基準,需要與上面開發周期所說的版本需要區分開來。

產品介紹

顯示產品的相關介紹,常見的字段有產品名稱、logo、slogen、產品簡介、產品定位、目標人群、使用場景以及產品目標等。有個別產品可能還需要顯示其他的信息,具體以實際情況為準。

全局說明

全局說明則是對產品中公共部分的控件、文案、網路請求狀態顯示等進行統一的說明。全局說明這部分會因產品不同而變動較大,所以也需要根據實際情況而定。

流程圖

流程圖在這個PRD中是比較重要的模塊,其中的邏輯性較強,最能反應出產品經理的邏輯思維能力與流程圖的繪制能力。

在文檔中,流程圖中包含信息結果圖、功能結果圖、業務流程圖以及任務流程圖(也就是功能流程圖)。

其中信息結構圖和功能結構圖可以使用Xmind、MindManager、百度腦圖等工具進行繪制;而業務流程圖、任務流程圖則可以使用Visio、OmniGraffle、ProcessOn等工具進行繪制,然后導入到PRD。如果業務涉及到多端、多用戶角色的產品,可以使用泳道圖。流程圖的具體的繪制大家可以參考woshipm社區下的《實例解析業務流程圖與產品流程圖

功能需求

功能需求模塊是整個PRD中最重要的部分,這個模塊是對功能的詳細說明。先看看功能需求下的三個子模塊:

功能列表

該頁面展示了整個產品的所有功能,一般采用列表的形式展示,通常包含字段有模塊、功能名稱、功能描述以及優先級。在這里額外添加了一項階段安排,通過顏色的刺激程度來區分功能的開發階段。

產品線路圖

產品線路圖與上述所說的功能結構圖十分類似,只不過功能結構圖是以功能為單位,而線路圖則是以頁面為單位。產品線路圖展示了產品的所有頁面以及對應連接關系。我們可以通過點擊線路圖中的矩形節點,跳轉到對應的功能詳情。

功能詳情

這個是我們的開發人員、設計師、測試人員使用最多的一個模塊,沒有之一。該模塊展示的是功能頁面的詳細信息,主要有功能頁面的描述、流程說明以及異常情況處理。

以啟動頁為例說明一下。主要包含4個部分,分別是原型圖、頁面簡介、界面描述和用戶用例。其中界面描述是對原型圖中的元素進行詳細的解釋。用戶用例則是對用戶的使用流程、備選流程以及異常流程情況的說明。不過并不是每個頁面都會有用戶用例這個部分,一些簡單的展示界面、沒有用戶行為的頁面,就可以不做用戶用例。

通過功能詳情的一些細節描述和用戶用例的思考,可以大大減少產品經理對功能思考的遺漏點。

非功能需求

不同產品有不同的非功能性需求,一般有以下幾類非功能性需求。

  • 性能需求
  • 統計需求
  • 營銷需求
  • 法務需求
  • 質量需求
  • 安全需求
  • 運營需求
  • 財務需求

上面的列舉的非功能需求就不一一說明了,每個產品都不一樣,需要根據具體產品、具體情況而定。

總結

其實PRD的撰寫與迭代,可以看做是一個產品的設計與迭代的過程。所以我們在PRD迭代更新的過程中,要明確團隊的實際需求,找出痛點、分析問題、得出解決方案、然后實施并驗證方案的正確性。

以上產品需求文檔是經過兩次迭代之后,然后結合團隊的流程總結出來的,雖然并不完美,但是很好的滿足當前團隊的需求,基本上符合當前敏捷開發團隊的使用,后續也會不斷改進優化。每個團隊也會因情況不同而需求不一樣,所以也僅供參考。

不過需要明確一點的是,PRD只是一個幫助PM傳遞想法和需求的工具,一個輔助手段,并不是目的,所以核心還是在需求上?;蛟S到了團隊的后期,團隊成員能力都很強、都很默契,基本上可以通過口頭溝通完成信息傳遞時,那么產品需求文檔也就不那么重要了。(嗯,比較理想…)

產品需求文檔模板_Axure文件地址:(https://pan.baidu.com/s/1eT9RUZg)密碼: mhns

 

本文由 @?Kimson 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自PEXELS,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 模版不見了,還可以怎么領取呀

    來自浙江 回復
  2. 您好,看了你的文章和原型,深有體會,現在我也在做需求文檔原型化,在閱讀您的文章時遇到一個疑問,就是在產品的不同迭代中,我是一個產品版本一個原型,還是將產品版本的多個版本集中在一個原型呢?求指教

    來自四川 回復
  3. 這段問題的描述剛好就是我最近踩的坑,深有體會

    來自北京 回復
  4. 挺好的,很清晰,給了一個很好的思路

    來自廣東 回復
  5. 版本迭代的原型,是一個版本一個axure文檔嗎

    來自廣東 回復
  6. 謝謝大佬分享

    來自廣東 回復
  7. 滿滿的干貨,謝謝分享。受教了

    來自浙江 回復
  8. 用Axure的什么版本比較好呢

    回復
  9. 滿滿的干活,非常實用的模板!

    來自廣東 回復
  10. 老鐵,文件下載下來,打開文件已損壞。

    來自四川 回復
  11. 剛半路接手了一個項目,正愁怎么把文檔補上呢,感謝老鐵,學習了!

    來自廣東 回復
  12. 您好,地址失效了,能麻煩再分享一下嘛 謝謝

    來自四川 回復
  13. 請教下,產品線路圖是用什么工具畫的?

    來自河北 回復
    1. 用Axure畫的啊

      來自廣東 回復
  14. 謝謝,寫得不錯,很值得學習和借鑒。必須打賞

    來自廣東 回復
  15. 寫的很不錯,目前正在發愁怎么寫。鏈接好像失效了

    來自浙江 回復
    1. 不會呀 前兩天還可以下

      來自廣東 回復
  16. 寫的很好很充實,最近我在嘗試和你完全相反的方向,PRD的去原型化,希望完全利用流程圖、字段描述和邏輯描述將需求說清楚,發現這種方式對自己思考需求很有幫助,但是在評審和開發階段,還是效率低些,一方面開發測試面對整篇的文字不會多認真去看,另一方面,在交互文檔上同樣還要標注清楚。之后也會嘗試PRD的原型化

    來自廣東 回復
    1. 非常贊同你的看法。

      來自上海 回復
  17. 是用什么軟件做的???word?還是?寫的很好,學習了。

    來自北京 回復
    1. axure

      來自廣東 回復
    2. axure寫那么多文字,而且還有列表。是不是有點麻煩了。

      來自北京 回復
  18. 寫的不錯,謝謝分享

    來自北京 回復
  19. 可以啊

    來自廣東 回復