這世界走的再快，也與你無關，一步一步成長，也挺好。

受公司學院的邀請，師父出山為廣大同事做了一次含金量超高的分享。打從上周接到邀請，師父就開始緊張兮兮的準備這次分享，滿腦子都是如何做分享（偷偷告訴你們，他都沒心思工作了）。因為，這事情關乎他的面子，我想這世上可能沒有什么比他的面子更重要的了。

他一直說“我滿腦子的東西，怎么講！” 最開始他打算把整個產品設計流程全部講一遍，然后一個人在那里神經兮兮嗶嗶了一天。

我實在看不下去了，于是給他講了一下我平時聽得一些分享的情況。

我說：“大家都是已經入門的產品了，其實早在我還沒做產品工作的時候就已經對流程滾瓜爛熟了，但是知道流程并沒有什么卵用。我們需要的不是大的框架和虛的概念，不如你就抓住流程里面非常細小的點來講實際工作中的應用”。

好在師父在懵逼的情況下聽取了我的意見。于是就有了下面的分享內容，這里我將放出我師父的演講稿，這比聽分享和看分享后整理的文檔更有參考意義（我在師父分享完之后是整理了一份分享文檔給學院的）。

主題：如何寫好一份prd（我將草稿只字不改，雖然有點亂，但是這樣完全代表他思考邏輯的稿子可以看出他的思維邏輯多縝密，還有絲絲尷尬和搞笑）

1.

大家好，我是家庭網絡產品線產品中心的產品經理**，在部門主要負責路由APP的產品工作，很高興在這里和大家做這個分享會，由于我之前從事的行業比較多，根據之前一些產品經驗，結合自身的特長，總結了一套自己產品設計的方法，用來跟大家分享，由于時間關系，我這里著重分享下我寫需求文檔的一些經驗，希望能拋磚引玉，互相交流學習。也希望大家能在今后的過程中能總結出自己的一套更好的產品需求文檔的編寫方法。

我認為，一款產品的上線，產品經理需要負責其四個階段：概念階段，設計階段，實施階段和運營階段。

概念階段里我們需要提供產品的商業模式（即BRD）的內容以及產品的市場分析（即MRD），公司立項一般會需要提供這兩個文檔，特別是商業模式特別重要，斐訊0元購就是一個非常好的商業模式，往往一個好的商業模式基本決定了一個互聯網產品的成敗。而市場分析會對市場環境，競品和商業對手，市場容量等等進行評估。

當商業和市場條件都滿足以后，我們需要確定我們的業務流程，這里的業務流程是個廣義的業務流程，意思是我們的核心交互是什么。比如商城的業務流程就是：查看商品-加入購物車-提交訂單-支付-發貨-收貨-售后；而我們路由APP的核心業務流程就是：路由設置-路由管理-路由控制。一個大型的APP往往會有多條線的業務流程。

接下來我們就要開始做競品分析了，一般會選擇相關行業里的排名靠前的，或者是比較有自己特色的產品，比如路由器APP，我們就經常會拿小米，360，TP-LIANK，網件等等來做競品分析，競品分析的維度有：產品定位，功能列表，價格，市場銷量，目標用戶，版本迭代等等。

然后我們就開始做需求分析了，也就是我們會在很多書本上看到的那些：用戶畫像，用戶場景，需求來源等等，我這里稍微提一下我自己做需求來源的幾個點：

• 關注行業趨勢和動向
• 根據友盟數據或者是市場數據提煉需求
• 用戶痛點和癢點挖掘
• 用戶反饋
• 競品參考
• 自身優化。

由于時間關系，以上概念階段的要素我就不詳細展開講了，這里只是順帶提一下，讓大家有個了解。

2.

我今天要講的主要是產品的設計階段，從文檔上來說就是PRD-產品需求文檔。很多人認為PRD就是用WORD寫寫我們需要做什么就好，其實一份完整的PRD不僅僅需要寫一份文檔來說明你要做什么，而是包括多份文檔內容，也就是廣義上的PRD。我從文檔上和流程上把它分成四部分：邏輯流程，思維導圖，原型圖，以及狹義的PRD輸出文檔。

3.

首先我們要理清楚產品大的邏輯流程，一般是用VISIO來做這方面的工作，就和畫人像一樣我們需要先確定其三庭五眼，這樣我們的邏輯才不會走偏。

還是回到我們路由APP上來例舉，由于路由產品的特殊性，我們一般需要用多方交互的泳道圖來表現我們的產品邏輯，一個路由功能一般會牽涉到APP端，后臺，設備端的多方交互。

這里舉個簡單的功能來作為例子，比如遠程控制路由器上的指示燈，APP端做出打開的操作，操作命令發送到云服務器，云服務器收到指令后找到對應設備的MAC地址，然后發送到對應路由器上打開路由器指示燈，這就是一個簡單的多方交互。我們需要用VISIO畫出這個邏輯，讓別人知道這個功能大概是什么樣子。

除了多方交互邏輯，我們有時候也會用來設計業務邏輯，業務邏輯里有時候也會有多方出現的情況，比如B2C的產品就會牽涉到B端用戶和C端用戶的邏輯流，各端用戶也會對應到其分別的前端和后臺。邏輯流程的種類非常多，我這里就不一一例舉了，分析一個鍛煉自己熟悉邏輯流程的好辦法，每天在應用市場下載一些推薦的APP下來，自己試著用VISIO畫出它們的邏輯流程，同時也可以學習它們的功能設計方法，這樣會讓自己的產品設計能力進步的非?？?。

4.

邏輯流程整理清楚以后，我們就可以根據大模塊開始做思維導圖，我一般會用XMIND來做這個，很多人會用思維導圖來做業務邏輯，我一般喜歡用思維導圖來做產品結構和邏輯判斷。

一般來說做完這個，整個產品有些什么頁面基本就都知道了。比如我的提綱，就是在寫我要講的東西的結構，不過APP的思維導圖里會多一些邏輯判斷在里面，舉個例子，賬號登錄，密碼輸入正確怎么樣，不正確會怎么樣，各會顯示或者是到那個頁面，就是邏輯判斷。如果大家有興趣，會下可以找我具體看思維導圖該怎么畫。

5.

接下來就要畫產品經理最熟悉的原型圖了，我一般用AXURE來畫原型圖，經過上面的邏輯流程和產品結構以及邏輯判斷的整理，實際上到原型圖這一步，我們只需要把邏輯頁面化而已。

實現我們要弄清楚整個產品的框架與層級，打個比方，一般的產品框架有：登錄注冊，首頁，個人中心，設置等等，而層級關系則是登錄頁面下有：用戶名輸入，密碼輸入，已經相對應的判斷頁面等等。類似于這種，大家可以舉一反三，這樣一層層的去做，你就發現整個APP的框架就會搭建起來了。

然后我們需要設計好頁面，頁面上有什么元素，如何展現。這個我想大家都會畫，不過畫的好看不好看，清晰不清晰就另當別論了。這個大家要是有興趣，平時我們可以私下探討。

不過我個人認為原型圖的頁面一定要簡潔清晰，不要加過多的設計元素在里面，除非你是要搶UI的飯碗。很多小伙伴都喜歡把原型圖畫的特復雜。接下來就是做交互跳轉了，說到這里，肯定有很多小伙伴覺得，這不是UE的事情嗎？其實UE負責的更多的是交互的用戶體驗，而里面的交互邏輯一般都需要產品來確認。而且，交互跳轉做的好，你給別人講你的設計的時候也會更輕松，思路也更清晰。

一般來說，做到這里原型圖基本上已經完成了，不過我個人更喜歡在原型圖上繼續做標注，第一，是為了讓UE或者程序員更清楚你的功能設計，其實也為你后面寫需求文檔做了標注提示。這里我一般會做兩種標注，一種是邏輯說明，大的頁面之間的關系或者跳轉我會做邏輯說明的標注；一種是功能規則標注，一般標注在功能點或者是字段上面，對具體的功能點做說明。

6.

接下來就是狹義上的產品需求文檔的編寫了，實際上整個產品邏輯在這個階段你應該已經一清二楚了。剩下的就是怎么把它表達出來，讓別人知道，這個其實還蠻難的，導致了很多程序員都不愛看PRD。這里我還是呼吁一下各位程序員大哥，還是給產品一個機會，多看看PRD,謝謝。話題偏了，還是讓我們回到需求文檔上來吧！

7.

產品文檔一般的格式我這里就不贅述了，我這里講講幾個重要的點吧：首先是需求說明，很多產品會忽略這個東西，我這里的需求說明是要說清楚，我們為什么要做這個需求點。舉個例子，之前路由APP是支持郵箱用戶的，后來因為業務需要，需要取消郵箱用用戶登錄，所以我這樣來寫這個需求說明：

8.

考慮到以后要上線的，比如打賞，藍汛游戲加速等牽涉到提現和充值的和金錢掛鉤功能，必須有手機驗證才能確保安全。其次，現在斐訊所有平臺只能用手機注冊，不會再產生郵箱用戶，如果繼續支持郵箱用戶則后期開發需要為這些用戶做多余的適配工作，所以需要禁用郵箱用戶，強制用戶綁定手機。

9.

這樣大家就清楚知道你為什么要做這個需求了，這個對剛剛走上產品崗位的產品經理還是特別重要的，你如何說服你的領導，或者是其他人，讓他們覺得你做這個需求是有意義的。有時候我們也需要對某個功能寫上需求預期，也就是說我這個需求需要達成什么樣的數據指標，這樣就可以對照后面的數據分析做個對比了。

10.

接下來要寫的就是功能描述了，新入職場的產品經理往往會把這塊寫的特別重，基本上會占到整個PRD的八成內容，其實我要說的是，你可以把這塊敘述得更清晰明確，只用說明你這個需求有哪些功能模塊，模塊之間功能流程是什么樣，用戶是如何操作的。

這里很多人會有另外的寫法，喜歡把規則插進去寫，我個人不是很喜歡這樣做，功能說明就直接描述功能是什么，會讓別人更清晰的了解整個功能操作，而規則可以寫在下面另外的模塊里，我一般叫他約束性描述，或者功能規則。這一塊在產品文檔里特別重要，一般的產品所說的有“坑”，問題就是出在這里。

11.

那我們如何來避免這種“坑”的情況發生呢？

我從兩個方面來講這個，第一個就是產品規則里需要有哪些要素，第二個就是如何自檢自己的文檔里有沒有紕漏；

首先產品規則里需要有：約束性描述-即這個東西只能怎么樣，功能規則-這個功能該執行什么邏輯，這兩個東西，基本上都會有，下面的有些東西可能只會有些特定的需求才會有，不過也是特別重要的。

比如數據來源，我這里的顯示的東西調用的是那張表或者是哪個接口；

儲存方式，我這個規則是緩存在本地還是保存到服務器上；

異常情況，如果發現異?；蛘咤e誤，這個邏輯該怎么走；

極值，如果在這里出現了999條記錄我該如何處理；

操作提示，用戶使用這個功能不知道是啥，我改怎么提示用戶或者是用戶做了什么操作，我該告訴用戶什么；

防呆規則，這里的輸入框是不是只能輸入數字或者輸入多少個數字；顯示內容及其格式，某塊地方是顯示的什么東西，或者是可能顯示什么，顯示的是圖片還是視頻還是文字或者支持的是什么格式。

前后臺邏輯關系，前端操作會對后臺產生什么影響，后臺的設置會讓前端顯示什么；

前置條件和后置條件,發生這個用例的前提條件，或者滿足什么條件才能觸發這個用例，發生這個用例之后的結果，會產生什么影響等等。

當然，你的產品規則可能遠遠不止以上那些，只要是你覺得有必要特別說明的東西，都可以算作你的產品邏輯，同樣的要求就是，一定要完整，明確并且清晰，不要留“坑”。

12.

那當我寫完產品規則以后，我該如何自檢自己的PRD呢？我這里也總結了一些我的經驗用來自檢。主要分三個角度：1產品角度，2運營角度，3，風險評估；

13.

從產品角度，我們需要注意以下的要素：

• 流程是否形成有效的閉環（什么叫閉環，就是功能走著走著不能走不通了）；
• 文案是否易懂，是否存在歧義（你的提示或者描述是否表達清晰，無文法錯誤，你的slogan是否有情懷，吸引人）；
• 版本兼容問題（如固件/第三方插件/第三方接口/APP各版本之前是否有沖突，功能之間或者交互之間做了好兼容）；
• 與其他系統(后臺系統/服務器)的調用是否能相互兼容跑通（這里一般是牽涉多方平臺的處理方案）；
• 新功能是否存在其他關聯功能點沖突（做一個新功能的時候一定要考慮到和其他有關聯功能的相互影響）；
• 業務高峰的系統降級處理邏輯（如果你做的是以為重度業務APP，一定要考慮很多用戶同時涌入的風險以及處理方案，比如某米的商品搶購）；
• 后續新功能或關聯產品如果下線的影響點（當你要下架某個功能的時候，要考慮到下架以后的風險和對其他功能會產生什么影響，要寫功能下架預案）；

14.

從運營角度，我們需要注意以下的要素：

• 是否存在數據報表、埋點需求；
• 是否存在客服查詢需求；新功能的客戶宣傳策略；
• 是否存在運營需求；數據指標和預期驗證；
• 運營需求和產品功能是否相互影響；

15.

從風險評估角度，我們需要注意以下的要素：

• 是否會因為功能設計而導致平臺審核不通過（特別是蘋果）；
• 是否引發諸如騷擾、欺詐等安全隱患；
• 是否存在用戶資料泄露，財產，數據泄露安全隱患；
• 是否存在負面輿情風險；
• 是否存在法律及合規風險；
• 發布審核風險；版本撤回及異常評估（回滾策略）；

所以我們經常會設計一些條例或者是用戶須知來防范這些風險。

如果時間充足，接下來我會將產品的實施階段和運營階段產品需要做些什么。

嘖嘖嘖，半個小時的分享時間，寫了這么多還怕說不夠。最搞笑的是，他最后說了句大家有需要的可以隨時可以來找他。我跟他說考慮清楚要不要這么說，他說就客套一下啦，沒人會當真的。于是第二天有人來找他，有人加他微信。

嚴肅點說，這次分享真的是干貨滿滿，只有非常認真仔細的閱讀，理解和實踐，才能轉化成自己的能力。跟了師父快半年了，學了這么久的我仍在反復練習，你是否也應該放下所謂的“***天成為優秀的產品經理”，而是踏踏實實的練習呢。

這世界走的再快，也與你無關，一步一步成長，也挺好。

作者：Jelly妮

來源：https://www.jianshu.com/p/e61f7eb59b94

本文由 @Jelly妮 授權發布于人人都是產品經理。未經作者許可，禁止轉載。

題圖來自unsplash，基于CC0協議