相信很多同學都很好奇，在一個產(chǎn)品的設計中產(chǎn)品經(jīng)理到底需要輸出多少文檔，并且這些文檔又有什么作用呢？

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

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

需求管理列表示例

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

在需求收集階段完成之后，產(chǎn)品經(jīng)理需要快速的把需求功能化，這一階段需要把需求抽象、挖掘需求的本質(zhì)，很多時候不同的需求可以整合到一個功能中進行實現(xiàn)。例如：

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

類似這樣的描述在需求收集階段是經(jīng)常出現(xiàn)的，產(chǎn)品經(jīng)理需要挖掘其背后的本質(zhì)，進行需求抽象，形成實際的功能，于是我們需求產(chǎn)生一份功能列表和功能結(jié)構(gòu)圖（信息結(jié)構(gòu)圖）

功能列表示例

功能結(jié)構(gòu)圖示例

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

功能流程圖示例

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

原型頁面結(jié)構(gòu)示例

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

界面跳轉(zhuǎn)流程圖示例

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

測試反饋一覽表示例

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

產(chǎn)品上線自查清單示例

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

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

文中若有不妥的內(nèi)容，歡迎大家指正！

本文由 @keeliu（微信號cainiaoPM） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。