作為產品經理在設計產品過程中你需要使用哪些文檔?

20 評論 94498 瀏覽 646 收藏 10 分鐘

相信很多同學都很好奇,在一個產品的設計中產品經理到底需要輸出多少文檔,并且這些文檔又有什么作用呢?

相信產品原型、PRD這兩個文檔名稱肯定是大家聽的最多的,但是在一個產品的設計中光有這兩個就夠了么,顯然答案是否定的,下面我就把我在產品的設計中會用到的文檔類型及其作用做一個詳細說明。

首先,在一個產品需求收集階段,我們需要進行大量的用戶訪談或者是調查,在這個階段我們需要準備一封叫做“需求管理列表”的文檔(也有人叫做“需求池”),這份文檔也是我們后續工作的指導性文檔,很多其他的文檔都是從這份文檔衍生出來。下面是我們自己的需求管理列表的截圖:

Q1

需求管理列表示例

這份表格中的內容大多比較好理解,特別需要注意的是優先級和需求來源,這兩項屬性是后續決定該需求是否實現的重要依據,來源一般可以分為公司內部和外部用戶,具體在往細分可以根據自己所在團隊的實際情況決定。

在需求收集階段完成之后,產品經理需要快速的把需求功能化,這一階段需要把需求抽象、挖掘需求的本質,很多時候不同的需求可以整合到一個功能中進行實現。例如:

  • 需求1、我要能夠及時的和朋友聊天;
  • 需求2、我想要把自己拍的好看的圖片傳給我的朋友;
  • 需求3、要是能夠和朋友進行語音或者是視頻聊天就好了。

類似這樣的描述在需求收集階段是經常出現的,產品經理需要挖掘其背后的本質,進行需求抽象,形成實際的功能,于是我們需求產生一份功能列表和功能結構圖(信息結構圖)

Q2

功能列表示例

Q3

功能結構圖示例

在需求功能化的階段,對每一個子功能都需要整理出對應那個的功能流程圖,流程圖是產品經理梳理自己的產品邏輯、驗證產品效用的重要步驟,在制作流程圖的過程中會窮盡功能的各種狀態和操作,并在腦海中不斷的推演功能的使用場景。在這一階段一定要定義好具體功能的狀態,通過狀態去控制不同的操作,而操作又可以改變狀態,在這一階段如果能夠對狀態和操作進行十分明確的定義,那么在開發進行具體實現時邏輯也會清晰,因為在具體的功能實現中流程往往包含正向和逆向,而通過狀態和操的相互影響是解決這兩種流程的較優解決方案(至少我現在沒有找到更好的解決方案)。

Q4

功能流程圖示例

往往在你完成了這兩份文檔的時候,一般你也開始進行原型設計了,會產生線框圖、低保真原型、高保真原型等等一系列的原型文檔。在很多的產品經理社區一直在討論原型和prd能不能整合為一個文檔,個人認為在原型中加入必要的功能說明和交互說明是很有必要的,但是PRD也是不可缺少的文檔,所有文檔的存在都有其價值所在,不明白其價值而討論起存在的合理性都是耍流氓。原型多是在項目進行中使用,其特點:直觀、有交互邏輯、能給項目成員真實的體驗,在完成的過程中產品經理更多的是處于交互體驗的角度去考慮問題;而PRD更多的是保證產品迭代的延續性,其特點:內容全面、定性定量,在團隊成員更換、產品周期較長時發揮其作用,在完成過程中產品經理更多的是規范規則和定義。兩個文檔的意義,決定了他存在的價值。

Q5

原型頁面結構示例

在以上三分文檔(功能列表、功能結構圖、產品原型)準備妥當之后,我們就可以愉快的去組織第一次評審會議了,如果要求高的同學,也可以準備對應的演示PPT,主要是對整個產品的介紹,有部分公司可能需要準備MRD文檔,進行立項說明,爭取更多的公司內部的資源,而像我現在所在的公司屬于創業型公司,產品經理提出的絕大部分功能都是為了解決實際問題的,一般不會存在爭奪資源的情況。而在不斷的評審確認的過程中,一般會輸出更多的魚其他人員對接的文檔,與UI溝通的界面跳轉流程圖、與測試溝通的用例等等。

Q6

界面跳轉流程圖示例

而在評審和確認階段,需要把最開始的需求管理列表和產品功能列表完善,把項目開發計劃于技術人員進行確認,并逐漸完善&優化原型文檔、PRD,把產品標準和規則、功能定義及說明、產品風險等事項進行充分考慮。而評審通過后,視覺進行UI設計(原型、界面跳轉流程圖)、開發進行技術實現(原型、PRD)、測試進行功能檢測(功能列表 、PRD、原型)主要的參考依據都是以上文檔,至于PRD的模板優秀的太多了,我也就不再進行累贅了。而最后作為一個產品自然少不了自己也體驗并測試產品,還會輸出測試反饋文檔,提出功能優化意見。

Q7

測試反饋一覽表示例

往往在完成了一個產品后我們都需要對其進行部署、上線,而每一次的上線我總是提心吊膽著,感覺每一次的上線都是在走鋼絲,錯了一步都會造成巨大的影響,功能是否全部測試到位、程序的代碼是否完整的提交了、新老版本直接更新會不會出現意想不到的情況等等,這些問題一致困擾著我,而在經歷了若干次的提心吊膽之后,我把上線中可能會遇到的問題整理成了一份上線前的自查清單,每次在上線前都會發送給項目中的各個成員要其對清單中的具體內容進行確認,以保證產品上線的質量,至此一個完整的項目便算完結,而后續的數據統計分析等環節,有時候更多可能是運營需要保證的工作。

Q8

產品上線自查清單示例

以上就是我在整個項目的實施過程中需要用到的文檔,產品經理需要對接的角色太多,而不同角色的特定或是專業知識也是不一樣的,不可能通過一份文檔對接所有的干系人,所以會衍生出各種各樣的的文檔,而這些文檔也是必須在實際的項目中遇到問題之后才能體現其價值,而我也是出于希望你能夠去實際體驗、領悟的目的,故不提供以上文檔模板的下載鏈接。

其實文檔不在于類型有多少,內容有多豐富,只在于需要使用你文檔的人或是關鍵點能夠發揮文檔的價值即可,一切的文檔都是為了保證項目的正常進行,保質保量的完美實現。

文中若有不妥的內容,歡迎大家指正!

 

本文由 @keeliu(微信號cainiaoPM) 原創發布于人人都是產品經理?,未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 作為一個產品經理,你應該把以上的內容,畫一張圖出來,方便我學習

    來自上海 回復
  2. 學習了,感謝分享

    回復
  3. 讀完之后感覺學到了很多,感謝作者

    來自北京 回復
  4. ???

    來自上海 回復
  5. 先看看再說

    來自上海 回復
  6. 學習力,感覺講的很細。對于小白很受用。

    來自北京 回復
  7. 請問你的頁面跳轉流程圖是怎么做的

    來自福建 回復
  8. 每步都做到感覺精力不夠啊。

    來自江蘇 回復
  9. 涵蓋了很多項目經理的工作,另外你還負責產品測試么

    來自北京 回復
    1. 測試自然是要做的,產品經理不去測試的話,那么最后的產品肯定完成度不高

      來自廣東 回復
    2. 非常贊同,自己的產品上線前必須自己測試一遍

      來自廣東 回復
  10. 收起來,好好學習,謝謝分享!

    來自天津 回復
  11. 這個我必須說下,你把項目經理的一些活都干了,需求池、bug匯總、產品上線自查清單示例
    尤其是最后這個,特么,你還讓不讓項目經理活了,呵呵
    我們產品經理要是像你這樣,我就嗨皮死了

    來自河南 回復
    1. 公司現在沒有項目經理,只能自己把這部分工作做了

      來自廣東 回復
  12. 真棒!學習了,制表去o((≡^♀^≡))o

    回復
  13. 贊一個

    來自湖北 回復
  14. 挺好

    來自遼寧 回復
  15. ??

    來自北京 回復
  16. 內容不錯,就是感覺少了幾步,如果是按照《用戶體驗要素》來的話也許會更好

    來自陜西 回復
  17. 好干貨,學習了!

    回復