講到PRD，有兩種不同的意見：有的人認為PRD十分關(guān)鍵，能夠體現(xiàn)出產(chǎn)品方案、設(shè)計思路；而有的人則認為PRD無用，價值小。對此筆者認為：我們應該結(jié)合公司、業(yè)務、產(chǎn)品等去自定義PRD，發(fā)揮它的最大價值。
一、寫作緣由
PRD、原型可以說是產(chǎn)品經(jīng)理工作中最常見、最高頻的交付物了。但是最近與許多同事的交流中卻發(fā)現(xiàn)，很多產(chǎn)品人員、開發(fā)人員都對需求文檔抱有一種輕視、鄙夷的態(tài)度，產(chǎn)品經(jīng)理對于需求文檔敷衍了事，開發(fā)更是看都不看。加之一些不知從何處來的言論鼓吹，“一個好的產(chǎn)品經(jīng)理絕對不等同于寫文檔、畫原型”“寫文檔就是搬磚”，PRD更加成為了一個尷尬的存在。
然而事實并非如此。
對于產(chǎn)品經(jīng)理個人而言，需求文檔是產(chǎn)品方案、設(shè)計思路、實現(xiàn)思路的綜合體現(xiàn)和結(jié)果輸出，不管是使用可交互原型、手繪原型還是文字描述，產(chǎn)品經(jīng)理總是需要這樣一個載體來表達自己的思維結(jié)晶。
對于團隊配合而言，隨著分工越來越細化以及員工流動性的增加，需求文檔轉(zhuǎn)而擔負起了聯(lián)絡(luò)產(chǎn)品、開發(fā)、測試以及新老員工的溝通工具。
對于公司或者業(yè)務這個抽象實體而言，需求文檔是其業(yè)務發(fā)展、變革的沉淀……
上面講到需求文檔存在的價值，不過我們也應該看到，圍繞著目標或者第一性，需求文檔可能只是交付產(chǎn)品或用戶價值的工具，我們確實應當結(jié)合公司、業(yè)務、產(chǎn)品的具體情況去自定義“需求文檔”，而不是直接生搬硬套。
下文所述，是基于我個人不到一年的產(chǎn)品工作以及PRD寫作經(jīng)驗。我相信隨著經(jīng)驗的不斷積累，還會不斷生發(fā)出新的認知來，屆時通過比較，我也能感知到自己的成長，在這里也歡迎大家與我共同探討。
二、重新定義需求文檔
1. 面向人群與寫作目標
需求文檔的使用人群主要包括產(chǎn)品經(jīng)理、開發(fā)、測試。對于產(chǎn)品產(chǎn)品經(jīng)理而言，使用并撰寫需求文檔應當可以幫助：
- 細化產(chǎn)品方案
- 輸出文字版的產(chǎn)品實現(xiàn)方案
- 幫助整理思路、發(fā)現(xiàn)不足、促進溝通
- 用于對內(nèi)對外的溝通展示
對于開發(fā)和測試而言，需求文檔應當可以幫助其了解業(yè)務、功能、成功標準，從而更好的進行開發(fā)和測試。
因而寫作PRD的過程，可以視為一個梳理產(chǎn)品思路、細化產(chǎn)品方案、細化技術(shù)方案的迭代的過程，而最終的PRD可以作為產(chǎn)品的藍圖、實施方案以及溝通工具。
2. 寫作思維
下面總結(jié)了在PRD寫作中我認為比較重要的幾種思維模型：
（1）目標思維
首先最頂層的思維應當是“目標思維”，通過思考這些問題找到寫作目標：這份文檔給誰看？他們想看哪些信息？他們會以何種方式看？我應該以什么樣的形式、內(nèi)容來寫才能更好的幫助讀者？
我寫作的常見目標可能是這樣的：
- 通過需求文檔梳理整個產(chǎn)品設(shè)計思路，并簡要的傳達給項目成員。
- 通過需求文檔，將產(chǎn)品方案細化為文字版的解決方案，這個文字版方案應當涵蓋所有開發(fā)細節(jié)，以便開發(fā)可以快速展開工作而無需多次找我溝通確認。
- 需求文檔應該有良好的組織結(jié)構(gòu)，便于以后加入新的文檔。
- 跟隨敏捷與迭代的原則，需求文檔也應是敏捷并且不斷迭代的。
- 需求文檔應當及時記錄和告知變更。
（2）基本的邏輯思維
產(chǎn)品文檔的各個組成模塊，應當具備合理的邏輯關(guān)系，而不是雜亂地鋪在文檔里。
例如，可以首先描寫和論證用戶需求；然后簡要敘述為了解決需求，選擇了怎樣的產(chǎn)品方案或業(yè)務模型；隨后列出為了實現(xiàn)業(yè)務模型需要鋪設(shè)的產(chǎn)品功能點；進一步的，通過功能流程圖，將功能點進一步細化為一個個頁面路徑和頁面元素；最后還要有對于頁面元素的詳細描述。
可以看到，這樣的需求文檔是邏輯清晰、有說服力的，出現(xiàn)問題也很容易定位到具體環(huán)節(jié)。
（3）微言大義
對語言文字有所敬畏，語言文字作為溝通工具，是非常容易造成歧義的，要想準確地將自己的思路想法傳達給別人是一件非常難的事情。需求文檔在文字表達上應該力求簡潔、清晰、無歧義，多試著以讀者的角度去審視自己的文字表達，相信你會發(fā)現(xiàn)很多問題。
（4）產(chǎn)品思維
我個人將PRD的寫作過程看作對產(chǎn)品思路的梳理和記錄。這個產(chǎn)品思路或許并沒有唯一正確答案，我個人的思路可以概括為：
（1）自上而下，基本遵循目標-概要性產(chǎn)品解決方案–詳細解決方案（對于常見的2C互聯(lián)網(wǎng)產(chǎn)品，這個詳細解決方案可能包括從功能結(jié)構(gòu)到頁面視覺的一系列工作）
（2）由內(nèi)而外，主要用于對現(xiàn)有功能的優(yōu)化，基本遵循可用-易用-好用的迭代原則。
因而實際工作中，我的寫作思路一般也遵循上述原則，對于新功能通常按照目標-概要方案-詳細方案去寫；對于功能優(yōu)化，結(jié)合現(xiàn)有使用場景和痛點，去提出優(yōu)化方案。
（5）技術(shù)思維
產(chǎn)品思維比較偏重于分析決策和提出面向用戶或商業(yè)的解決方案，而技術(shù)主要考慮如何去實現(xiàn)這個解決方案，以及這個解決方案對既有技術(shù)框架的影響有多大。
實際上，一個好的解決方案絕不僅僅只考慮用戶或商業(yè)，技術(shù)實現(xiàn)也是必須考量的要素。技術(shù)將解決方案落實并決定項目的資源和成本，技術(shù)方案的好壞也會直接決定用戶的使用體驗，甚至有些時候技術(shù)實現(xiàn)可以驅(qū)動商業(yè)和用戶需求的變革。
產(chǎn)品經(jīng)理缺失技術(shù)思維，就會很容易將自己沒完成的任務無意識的甩鍋給開發(fā)，實際工作中開發(fā)經(jīng)常跑來找產(chǎn)品溝通需求細節(jié)也是源于此。
以一個簡單的例子來說明：
技術(shù)層面，用戶在登錄注冊后，可以本地緩存賬號信息，從而下次訪問應用時無需手動進行登錄操作。如果產(chǎn)品經(jīng)理不懂這個緩存技術(shù)，在PRD中就會缺失相應描述，開發(fā)人員無法明確是否要做這樣一個自動登錄的功能，就只能拍腦袋決定了。
再舉一個登錄注冊相關(guān)的例子：
網(wǎng)站登錄注冊需要考慮是否限制用戶多賬號登錄的問題，網(wǎng)站運行在瀏覽器上，瀏覽器在緩存用戶信息的時候是按域存儲的；如果網(wǎng)站允許多賬號登錄，在不加以設(shè)計的情況下，這些同時登錄的賬號會出現(xiàn)數(shù)據(jù)混亂的情況。因而必須在產(chǎn)品設(shè)計之初就從需求上定義是否需要多賬號登錄，進而才能由開發(fā)給出一個完善的多賬號數(shù)據(jù)存儲或請求方案。
現(xiàn)實工作中，產(chǎn)品經(jīng)理可能無法達到技術(shù)人員的水平，解決之道可以是自己多學習、和技術(shù)多去溝通產(chǎn)品方案；還可以通過制定設(shè)計&開發(fā)規(guī)范，讓產(chǎn)品、設(shè)計、技術(shù)可以協(xié)同工作(類似于ant design，定義了一套常用的設(shè)計開發(fā)規(guī)范，產(chǎn)品設(shè)計和開發(fā)都可以基于共同規(guī)范去開展，而不用重復造輪子)。
在我最初的認知中，產(chǎn)品經(jīng)理應該盡量去定義一套足夠詳盡的解決方案，而開發(fā)人員、設(shè)計人員只需根據(jù)PRD去進行自己的工作。
在對設(shè)計、開發(fā)有了一定的了解后，我認為，單靠產(chǎn)品經(jīng)理一人之力去輸出詳盡的解決方案是不太可能的（除非產(chǎn)品經(jīng)理既懂得產(chǎn)品設(shè)計、又懂得技術(shù)、還懂得交互設(shè)計和視覺設(shè)計等）。一個真正優(yōu)秀的產(chǎn)品方案應該由產(chǎn)品人員、開發(fā)人員、設(shè)計人員、測試人員通力合作，這些人員不是上下游關(guān)系、規(guī)劃與執(zhí)行關(guān)系，而是一種能力互補的關(guān)系，這些人員的才能共同造就一個優(yōu)秀的產(chǎn)品。
另一方面，在不斷的配合中，產(chǎn)品、設(shè)計、開發(fā)應該嘗試去將常用功能封裝成一個設(shè)計&開發(fā)框架，在以后的工作中可以直接沿用或改動現(xiàn)有框架，提高工作與溝通效率。
三、PRD結(jié)構(gòu)
下面簡要介紹我個人常常使用的PRD的基本結(jié)構(gòu)：
1. 需求
也是產(chǎn)品方案要達到的目標，需求可能是用戶需求（即以用戶價值為導向），也可能是業(yè)務需求（即以商業(yè)價值為導向），后面的產(chǎn)品方案細節(jié)，最終都是為了達到這一目標。
在PRD中闡述項目的目標，有助于激發(fā)團隊成員的動機，從而在目標上達成一致。
2. 設(shè)計模型
面向需求或目標，提出解決方案或設(shè)計模型，可以以泳道圖、流程圖等可視化的方式或者文字表達的方式描述主要的業(yè)務邏輯、產(chǎn)品架構(gòu)。
3. 功能列表
根據(jù)設(shè)計模型，將用戶需求、業(yè)務需求轉(zhuǎn)換為大大小小的產(chǎn)品功能模塊或非功能性要求，闡述這些模塊間的業(yè)務關(guān)聯(lián)、數(shù)據(jù)關(guān)聯(lián)，對于功能進行優(yōu)先級分析和版本規(guī)劃。
4. 功能流程
針對每一個功能模塊，圍繞著功能目標，設(shè)計功能流程。如圍繞著用戶賬號登錄這一目標，設(shè)計登錄注冊的流程。這里要注意：
根據(jù)功能模塊的特性，使用不同種類的流程圖，比如泳道圖、時序圖、狀態(tài)圖。
突出主流程、弱化分支流程、以文字表達異常流程，將三者區(qū)隔開來。
（產(chǎn)品設(shè)計應當優(yōu)先考慮引導用戶走向主流程，次之考慮對于用戶的分支行為作出一定約束，最后還要考慮整個環(huán)境系統(tǒng)可能出現(xiàn)的異常。對于用戶、設(shè)計人員、開發(fā)人員而言，這三者的作用和優(yōu)先級都是不同的）。
5. 頁面設(shè)計與頁面元素
頁面設(shè)計是對功能流程的進一步細化，許多的頁面元素串聯(lián)起來，引導用戶走完整個功能流程并達成目標。根據(jù)功能流程圖，考慮以最少的頁面和最清晰有效的頁面布局實現(xiàn)功能。
6. 頁面詳細說明
對于頁面之間的邏輯和每一個頁面元素進行必要的說明。
頁面元素包括信息和控件等，在說明信息時，需要對信息的展示效果、信息來源、信息的計算規(guī)則、信息的刷新規(guī)則等進行說明；對于控件，以輸入性控件為例，對控件類型、控件樣式、控件交互、輸入限制、輸入校驗等屬性進行說明。
個人覺得，頁面詳細說明是開發(fā)和測試最終要參考的部分，也是產(chǎn)品經(jīng)理最容易有遺漏的地方，因為這里會涉及很多細節(jié)；對于這里的寫作也是爭議最多的，是否要寫得足夠詳盡？我只能說，對此要具體情況具體分析，如果團隊已經(jīng)有了成熟的配合模式和規(guī)范，這里自然可以簡化；但是我想每個產(chǎn)品經(jīng)理都應該具備寫一份詳盡文檔的能力。
那么怎樣才能避免遺漏細節(jié)呢？
我個人覺得，還是要有技術(shù)思維。換位思考如果你是開發(fā)，你需要知道哪些必要因素才能開工。
對此，個人認為最快的學習途徑不是看別人怎么寫需求文檔，而是讀一些技術(shù)的書，真正明白當一個開發(fā)在寫代碼時是在做什么。
以網(wǎng)頁表單為例，前端需要通過html和CSS來定義表單的結(jié)構(gòu)和樣式，通過javascript執(zhí)行一些輸入限制和校驗，通過AJAX和服務端通信，發(fā)送POST請求將用戶輸入的一些字段信息上報；服務端需要編寫程序?qū)φ埱筮M行處理并在處理完成后發(fā)送響應給前端。
因而從前端的角度出發(fā)，PRD里應當包含頁面控件樣式的描述、控件交互的描述、輸入限制的描述、數(shù)據(jù)上報的描述等；從后端的角度出發(fā)，PRD里應該包含有數(shù)據(jù)上報的描述。
7. 全局說明
一些各個頁面都有的功能點、交互模式、設(shè)計樣式，或者一些通用的異?？刂疲梢苑旁谌终f明里。
四、總結(jié)
在PM的日常工作中，對于PRD有了一些認知上的升級，在這里進行了初步總結(jié)。主要講述了：
（1）PRD寫作的目的和價值
（2）PRD寫作中應該具備的思維模式
（3）PRD的常見結(jié)構(gòu)
此文雖以PRD為主要話題，但實質(zhì)上重在對產(chǎn)品經(jīng)理邏輯與理性思維的體察。誠如很多大佬說的，產(chǎn)品經(jīng)理需要有一秒內(nèi)變?yōu)榘装V的能力；但個人認為，除了直覺與感性，良好的邏輯思維與理性亦是產(chǎn)品人必不可少的。
本文由 @lemon 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導、進階學習的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）
