文章開頭：本文是杜松發表在產品壹佰的文章（http://www.chanpin100.com/article/104999）轉載文章僅供大家習，不作任何商業用途。
想辦法讓你的團隊，在你的PRD文檔里面「看見」用戶的具體行為動作。
PRD對產品開發的重要性無需多費筆墨，但PM們經常遇到一個尷尬，“寫多了大家未必都會看；寫少了又怕別人不懂。”
實際上，PRD的問題不在于如何寫，而在于讓團隊能夠理解業務，以及開發過程中如何被傳遞與執行。
一、關于PRD的幾個建議
PRD有且只有一個目的：描述清楚要做什么，怎么做，并保證團隊的及時同步。
對一份PRD來說，沒有什么比可讀性還重要的事情了。
1、可能的情況下，盡量不要輸出WORD版本的PRD，WORD版本的PRD文檔會隨著內容的增長可讀性直線下滑，原因在于WORD更善于線性描述；
2、不要列“需求格子”，任何一個功能方案不要再用傳統的軟件工程師法來描述“前置條件”“狀態機”“輸入”“輸出”這種格式來框定需求，它會使得產品的功能僅僅是功能，這是給產品帶來風險的一個引子；
3、讓你的PRD只有一份是個不錯的嘗試，文檔多了，除了增加管理成本之外，就是讓人不知道從哪里去找想要的東西；
4、程序猿并不是害怕產品經理變更需求，而是害怕產品經理自己沒有想清楚，給出的產品方案難以自圓其說，反復修改而又達不到想要的結果；
5、讓團隊的每個人都參與進來，發揮程序猿的主觀能動性，認真聽取來自技術、設計、測試端的那些“莫名其妙”的建議，善用并適當采納這些建議，你會發現很多事情會簡單很多；
6、放松一點，保持頭腦清醒，激活你的團隊，讓成員給你反饋。
以上，供你參考。
二、PRD內容架構
現在出發，我們的目的是讓你的PRD相對輕便，別人愿意看，自己也不太“痛苦糾結”。
文檔導航：讓你的團隊成員知道怎么看，盡可能一份文檔描述清楚而又完整；
版本摘要：讓你的團隊成員明白為什么做；
變更日志：讓你的團隊成員知道你“又做了什么手腳”；
產品原則：通用性的規范，讓所有人都知道應該遵從什么標準，什么要求，做成什么樣；
功能結構：通俗一點的說法就是，“用圖來描述”你現在想從哪里動刀子了，是要改動“個人資料”模塊還是訂單頁面；
關鍵流程：別什么都畫一個圖，把核心的流程描述清楚即可；邏輯完整，你寧可缺少一些場景的邏輯，而不是連一個場景都講不清楚；
故事板與原型：用場景化的語言描述某個功能是什么，配合適當的例子，讓團隊成員真正理解這個場景下的用戶行為。
1、文檔導航
給PRD加一個導航系統，是為了清晰的引導團隊成員看快速找到他所關注的內容。
為什么要有導航？
1）從這個導航結構，所有人都能一眼就明白這個版本的概貌，能清晰的知道要做什么，也知道你又改了什么。更重要的是，這個結構的第一步描述了整個版本為什么要做的原因——需求的出處，以及產品的價值。
2）如果有條件的情況下，可以弄一個小型的服務器，整個團隊其實只需要通過瀏覽器直接范圍這個地址即可（一定要創造條件，避免產品原型，或RP文件，或壓縮包通過郵件、QQ、微信漫天飛的現象）。
產品經理有責任確保整個團隊只有一個需求的輸入口——需求的及時同步。 產品經理也需要確保流轉到下一個任何環節都是經過確認的版本。
2、版本摘要
1）版本定義與目的
在定義一個版本，編寫一份PRD的時候，整個團隊首先需要了解的是，這個版本為什么要做，做了有什么用。嘗試描述這些問題有很大的幫助：
為什么要這個版本，是運營驅動還是產品驅動？
這個版本主要做了什么，能為用戶帶來什么？
做完這個版本，對產品的競爭力能帶來什么提升？
2）里程碑計劃
很多公司，產品經理和項目經理是完全兩個不同的角色，通過彼此的協調配合共同來推進一個項目迭代。但在一些創業公司，或者相對小型一些的企業，產品經理&項目經理統稱為PM，有PM來統籌資源，推進進度，當然也包括產品需求。對這一類的產品經理而已，必須把控整個項目的進度。
在這種工作環境下，需要保證整個團隊（從上到下）對進度節點的一致認可和知悉，并盡可能的嚴格按照計劃來執行。否則，極容易出現場面失控，一口又一口結結實實的鍋，會讓PM們吃不完兜著走。
具體到項目進度的編制、執行和控制，是另外一個話題，暫且略過。
3）其他
摘要都可以起到一個極好的歸納作用，引領整個團隊正確的理解項目。視不同的情況，不同的產品（業務）類型，版本的摘要有完全不同的內容，如果是乙方的項目，則還可以把項目架構，溝通機制都作為一個摘要來傳遞。
一個建議是，盡可能的把文檔歸攏，而不是完全依賴郵件滿天飛。
3、變更日志
最善變的，不是你的女朋友，而是“需求”。
所有應對和管理需求變更的“奇淫技巧”，首先要的是能夠從心理上有所準備，能夠擺正心態正確面對需求的變更，然后才是通過恰當的手段管理需求變更——不要想著去控制變更，一字之差之間有很大的不同。
1）需求變更帶來的困境
額外的開銷
項目的延期
團隊士氣低落
質量失控
2）應對需求變更的建議
A. 通過角色扮演來挖掘需求
這個鍋，產品經理得徹底背起來。需求的頻繁變動，往往最根本的原因就是需求與用戶的真實場景相背離，產品經理直接套用了用（ling）戶（dao）們（men）的“解決方案”演變為功能需求，導致在整個功能的設計階段，流程梳理環節越走越遠而往往不能夠自知，鑒于此，產品經理一定要學會如何扮演角色，倒推場景下的用戶行為。只有在這個階段，把自己演變為“小白”才可能真正發現和理解用戶——秀一場cosplay吧。
B. 借助團隊的力量驗證需求
不要維護自己的方案，你的方案第一次拿出給到設計師、程序猿的時候，就是為了讓他們來給你找出問題，在第一次需求評審的時候，盡可能的傾聽來自團隊的聲音，你應該把第一次需求評審會議改為“需求表演會”。產品經理應該要理解，只要在越早期的時候，被研發質疑，然后再通過需求驗證，才能讓團隊感受到這些團隊的力量，你應該讓你的團隊協助你，而不是讓他們按照你的方案來執行。
C. 保持需求的唯一出口
這是一個重大的災難。需求多端發起，特別是甲乙方的項目，涉及的干系人過多，以及跨部門協作的時候，每個人都在發表聲音，從而導致局面徹底失控。這就是為什么建議在一份PRD的開頭明確一個協同規則的根本原因，把它作為項目的頭等大事，寫在最首要的位置，時刻同步給到每一個人。產品經理應該盡可能的建立一種“只有PM確認的工作才付諸行動”的氛圍。
D. 保持持續性更新
需求變更的另外一個重要原因就是，需求沒有及時同步，任何一個小的變更，一定要隨時同步到整個團隊，它除了影響研發之外，還包括設計、測試團隊，以及后續的運營團隊。
所有的關于需求變更技法，都是在補救你此前捅過的婁子和埋下的雷。不要奢望能躲避需求變更，而是要引導和管理在合適的范圍內。不要害怕變更，畢竟唯一不變的，就是變化。
3、產品原則
產品經理應該盡早制定一份產品的基本原則，什么能做，什么不做。當然，這里可以完整的描述從體驗角度需要遵從的基本規范。
這里沒有太多的建議和參考，你的產品原則，既可以是戰略性的，也可以是產品功能性的，可以大到決定產品方向，可以小到顏色字體。
制定產品規范（原則）的目的，是為了保障產品的體驗一致性。更重要的是，保護你的產品不出現意外。產品經理應該盡可能的從多維度制定規則，但不要過于復雜。越是方向上的東西越是要簡單。例如微信，如果傾向于發信者的立場，在后續的版本過程中更多的維護發信者的體驗；如果是傾向于收信者的立場，則一定在保障發信者的體驗。
任何產品都很難照顧到產品的所有角色，必須明確產品的側重點是什么。
4、功能架構
想象一棟樓，你能看到有地基、柱子、橫梁、墻面、屋頂，這個樓之所以不會輕易垮塌，就是因為這些部件構建了一種穩固的結構——物理架構。你一定很快就能想象得到，房子要能適合居住，就得有進排水（系統），得有電力供應（系統）等等，這就從邏輯層來構建一棟樓的結構。
從這樣一個粗糙的描述里面，你應該能夠理解，所謂架構，就是把各個部件進行歸納匯總，提煉抽象，并通過適當的鏈接方式打造成一個穩定的形狀，滿足人們的實際需要。在你面對一個產品/一個需求的時候，應該能在腦海里勾畫出模型，什么東西是4個桌腿，什么東西是一個桌面，4條腿和一個桌面如何共同構建和支撐這個業務的穩定運行。
通常情況下，一份PRD中，只需從物理結構層詳盡的描述“功能結構”即可。實際情況是，有的情況下，你并不需要畫一個結構圖，因為產品的結構可能已經千年不變了，這個版本也可能僅僅是修復一些問題，甚至只是把方形的用戶頭像改成圓形——因為你的老板覺得好看。
產品架構不僅是能支撐當下的業務，也要能具備適度的擴展性和容錯性。
5、關鍵流程
越是復雜的系統，越是推薦把流程圖做一個目錄，不但是引導閱讀者，而是檢查遺漏的方法。同時，產品經理在繪制流程圖的時候，盡可能的遵從通用的規范，并養成養好的習慣。好的流程圖，可以快速讓整個團隊熟悉理解業務，并優化業務。
梳理業務流程的步驟，估計沒有多少經驗的產品經理們都能想象得到，先要去調研，然后畫成圖，在這個過程里面會有確認，完善的工作。調研的過程是為了解決who，what，why，how，以及where的問題：誰，在什么情況下，做了什么事情，這個事情需要什么前置條件，又輸出了什么，這個事情在哪里完成的？
但這極可能陷入形式主義性質的錯誤，這種調研僅僅是在知道“用戶現在怎么做？”最后極可能得出一個流水式的糊涂賬。產品經理需要的是探索更深層次的問題，為什么要這么做，為什么不這么做？
流程的基本意思是指水流的路程，也就是工作進行中的次序或順序的布置和安排，由兩個及以上的業務步驟，完成一個完整的業務行為的過程。對一項業務來說，從它的輸入到最終的結果，理論上來說就是一張流程圖就可以畫完整，但為什么不這么做呢？
沒有多少人可以一口氣看完一張橫跨多個業務角色、多個業務部門的流程圖后，能有一個全局的概念。這種形式的流程圖，會讓人陷入一種不可收拾的泥潭中。產品經理不僅僅是要知道每個環節的流程，更要理解整個業務的體系，并協助團隊成員從全局來理解業務邏輯。你需要把業務的核心剝離得出來，抽象出多個可以支撐業務的關鍵支點。只有先搭建了一個好的戲臺，人物角色才能夠全面鋪開。在你的腦海中想象一串葡萄的樣子，你的業務流程圖也應該是這樣，一條主線若個支線無數節點。
每一項業務通常都能找到它的關鍵支撐點，比如O2O項目，我們可以抽象歸類出“受理、派單、接單、回單、回訪”5個業務動作，通過這5個基本的業務動作，能夠讓整套系統流轉不同的業務單據，能夠支撐多個的業務角色，而不是簡單粗暴的讓流程跟著單據走，不能演變出新增/刪減一份單據都需要重新定義、修改流程的局面。
實際上，你應該發現，對產品經理而言，是先有業務，再做框架，然后是功能，最后是過程。一定要避免直接操刀把一個產品拆分成多少個模塊，模塊多少頁面，頁面內是什么按鈕。
6、故事板與原型
所謂的用戶故事，就是描述用戶想要實現的功能，最簡單的說法，就是“誰想要干嘛”。
產品經理們的PRD文檔會出現“寫了沒有人看”的尷尬，一個重要原因就是用戶需求的描述方式。你寫了很多也足夠細致，但讀文檔的人卻始終沒有辦法進入角色。過于技術化的描述讓人昏昏欲睡沒有思考的欲望，根本在于閱讀者不能通過角色置換想象一個用戶在干嘛，要干嘛，以及為什么。
隨著業務復雜性的提升，“需求清單”會變成像裹腳布一樣讓人不愿意忍受。
根據用戶的業務場景寫成故事板，而不是列出一張“需求清單”。這么做的目的是為了保證團隊能夠理解、認同為什么要這個功能，以及用戶是怎么做的，并引發團隊的思考。
產品經理描述的功能需求（故事板），應該盡量用團隊可以理解的業務語言來描述，而不是描述諸如字段，存儲的技術語言。作為產品經理，必須把重心放在用戶所能理解的問題上。你解決的是用戶的問題，而不是程序猿們的問題。比如頁面響應速度這個問題，產品經理可以描述為“啟動頁3秒后自動跳轉到首頁”，而忽略“響應速度”本身是個什么概念——原因在于你的用戶并不能理解你的響應速度，而你應該像你的用戶一樣思考問題。
故事板并不是為了追求完整性，而在于它能夠被理解和有價值。所以，不太建議過于在意“故事板怎么描述”這個問題，這可能不是最重要的是問題。關鍵是場景覆蓋的程度，覆蓋越廣，適應性會更強，程度越深，可能用戶的體驗相對會更好一些。產品經理需要在不同的版本里面權衡在什么版本做什么功能，二八法則可能是你很好的一個工具。
想辦法讓你的團隊在你的文檔里面“看見”用戶的具體行為動作，在每個人的腦海中構建出一副生動的畫面，你的PRD才會有活力。
三、關于Axure
如果你考慮嘗試僅用Axure撰寫你的PRD，這幾條意見可能對你有用：
1、使用最新的Axure版本，Axure 8.1是最好的選擇；
2、使用內聯框架，可以讓你把整個原型串聯起來；
3、盡量多用母版，不僅提升了效率，母版還能夠協助你合理的解耦；
4、組合是個好東西，特別是Axure 8以后給了組合更多的屬性，你可以像用部件一樣使用組合；
5、動態面板要學會，它能充分展示一些交互過程，也要慎重，過多的面板降低了原型本身的協作，在早期的版本中，動態面板還會明顯降低原型的流暢度；
6、掌握柵格系統；
7、Axure是個極好的工具，掌握它是應該的，把它耍得很酷，看你的工作量和時間；
8、保持清醒，不要炫技。
文章結尾：再次申明所有轉載文章僅供學習，感謝杜松老師的分享，如果喜歡我的文章點關注??吧！比心呦！
