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

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

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

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

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

好在師父在懵逼的情況下聽取了我的意見。于是就有了下面的分享內(nèi)容，這里我將放出我?guī)煾傅难葜v稿，這比聽分享和看分享后整理的文檔更有參考意義（我在師父分享完之后是整理了一份分享文檔給學(xué)院的）。

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

1.

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

我認(rèn)為，一款產(chǎn)品的上線，產(chǎn)品經(jīng)理需要負(fù)責(zé)其四個階段：概念階段，設(shè)計(jì)階段，實(shí)施階段和運(yùn)營階段。

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

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

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

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

• 關(guān)注行業(yè)趨勢和動向
• 根據(jù)友盟數(shù)據(jù)或者是市場數(shù)據(jù)提煉需求
• 用戶痛點(diǎn)和癢點(diǎn)挖掘
• 用戶反饋
• 競品參考
• 自身優(yōu)化。

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

2.

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

3.

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

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

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

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

4.

邏輯流程整理清楚以后，我們就可以根據(jù)大模塊開始做思維導(dǎo)圖，我一般會用XMIND來做這個，很多人會用思維導(dǎo)圖來做業(yè)務(wù)邏輯，我一般喜歡用思維導(dǎo)圖來做產(chǎn)品結(jié)構(gòu)和邏輯判斷。

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

5.

接下來就要畫產(chǎn)品經(jīng)理最熟悉的原型圖了，我一般用AXURE來畫原型圖，經(jīng)過上面的邏輯流程和產(chǎn)品結(jié)構(gòu)以及邏輯判斷的整理，實(shí)際上到原型圖這一步，我們只需要把邏輯頁面化而已。

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

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

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

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

6.

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

7.

產(chǎn)品文檔一般的格式我這里就不贅述了，我這里講講幾個重要的點(diǎn)吧：首先是需求說明，很多產(chǎn)品會忽略這個東西，我這里的需求說明是要說清楚，我們?yōu)槭裁匆鲞@個需求點(diǎn)。舉個例子，之前路由APP是支持郵箱用戶的，后來因?yàn)闃I(yè)務(wù)需要，需要取消郵箱用用戶登錄，所以我這樣來寫這個需求說明：

8.

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

9.

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

10.

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

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

11.

那我們?nèi)绾蝸肀苊膺@種“坑”的情況發(fā)生呢？

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

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

比如數(shù)據(jù)來源，我這里的顯示的東西調(diào)用的是那張表或者是哪個接口；

儲存方式，我這個規(guī)則是緩存在本地還是保存到服務(wù)器上；

異常情況，如果發(fā)現(xiàn)異?；蛘咤e誤，這個邏輯該怎么走；

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

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

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

前后臺邏輯關(guān)系，前端操作會對后臺產(chǎn)生什么影響，后臺的設(shè)置會讓前端顯示什么；

前置條件和后置條件,發(fā)生這個用例的前提條件，或者滿足什么條件才能觸發(fā)這個用例，發(fā)生這個用例之后的結(jié)果，會產(chǎn)生什么影響等等。

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

12.

那當(dāng)我寫完產(chǎn)品規(guī)則以后，我該如何自檢自己的PRD呢？我這里也總結(jié)了一些我的經(jīng)驗(yàn)用來自檢。主要分三個角度：1產(chǎn)品角度，2運(yùn)營角度，3，風(fēng)險評估；

13.

從產(chǎn)品角度，我們需要注意以下的要素：

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

14.

從運(yùn)營角度，我們需要注意以下的要素：

• 是否存在數(shù)據(jù)報表、埋點(diǎn)需求；
• 是否存在客服查詢需求；新功能的客戶宣傳策略；
• 是否存在運(yùn)營需求；數(shù)據(jù)指標(biāo)和預(yù)期驗(yàn)證；
• 運(yùn)營需求和產(chǎn)品功能是否相互影響；

15.

從風(fēng)險評估角度，我們需要注意以下的要素：

• 是否會因?yàn)楣δ茉O(shè)計(jì)而導(dǎo)致平臺審核不通過（特別是蘋果）；
• 是否引發(fā)諸如騷擾、欺詐等安全隱患；
• 是否存在用戶資料泄露，財產(chǎn)，數(shù)據(jù)泄露安全隱患；
• 是否存在負(fù)面輿情風(fēng)險；
• 是否存在法律及合規(guī)風(fēng)險；
• 發(fā)布審核風(fēng)險；版本撤回及異常評估（回滾策略）；

所以我們經(jīng)常會設(shè)計(jì)一些條例或者是用戶須知來防范這些風(fēng)險。

如果時間充足，接下來我會將產(chǎn)品的實(shí)施階段和運(yùn)營階段產(chǎn)品需要做些什么。

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

嚴(yán)肅點(diǎn)說，這次分享真的是干貨滿滿，只有非常認(rèn)真仔細(xì)的閱讀，理解和實(shí)踐，才能轉(zhuǎn)化成自己的能力。跟了師父快半年了，學(xué)了這么久的我仍在反復(fù)練習(xí)，你是否也應(yīng)該放下所謂的“***天成為優(yōu)秀的產(chǎn)品經(jīng)理”，而是踏踏實(shí)實(shí)的練習(xí)呢。

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

作者：Jelly妮

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

本文由 @Jelly妮 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于CC0協(xié)議