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

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

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

需求管理列表示例

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

在需求收集階段完成之后，產(chǎn)品經(jīng)理需要快速的把需求功能化，這一階段需要把需求抽象、挖掘需求的本質(zhì)，很多時(shí)候不同的需求可以整合到一個(gè)功能中進(jìn)行實(shí)現(xiàn)。例如：需求1、我要能夠及時(shí)的和朋友聊天；需求2、w我想要把自己拍的好看的圖片傳給我的朋友；需求3、要是能夠和朋友進(jìn)行語音或者是視頻聊天就好了。類似這樣的描述在需求收集階段是經(jīng)常出現(xiàn)的，產(chǎn)品經(jīng)理需要挖掘其背后的本質(zhì)，進(jìn)行需求抽象，形成實(shí)際的功能，于是我們需求產(chǎn)生一份功能列表和功能結(jié)構(gòu)圖（信息結(jié)構(gòu)圖）

功能列表示例

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

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

功能流程圖示例

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

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

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

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

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

測試反饋一覽表示例

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

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

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

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

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

本文由 @keeliu（微信號(hào)cainiaoPM）發(fā)布