axure實戰教程-tft每日頭條

PRD對産品開發的重要性無需多費筆墨，但PM們經常遇到一個尴尬，“寫多了大家未必都會看；寫少了又怕别人不懂。”實際上，PRD的問題不在于如何寫而在于讓團隊能夠理解業務，以及開發過程中如何被傳遞與執行。

axure實戰教程（活用Axure撰寫輕便的需求文檔）1

關于PRD的幾個建議

1、PRD有且隻有一個目的，描述清楚要做什麼，怎麼做，并保證團隊的及時同步；

2、對一份PRD來說，沒有什麼比可讀性還重要的事情了。可能的情況下，盡量不要輸出WORD版本的PRD，WORD版本的PRD文檔會随着内容的增長可讀性直線下滑，原因在于WORD更善于線性描述；

3、不要列“需求格子”，任何一個功能方案不要再用傳統的軟件工程師法來描述“前置條件”、“狀态機”、“輸入”、“輸出”這種格式來框定需求，它會使得産品的功能僅僅是功能，這是給産品帶來風險的一個引子；

4、讓你的PRD隻有一份是個不錯的嘗試，文檔多了，除了增加管理成本之外，就是讓人不知道從哪裡去找想要的東西；

5、程序猿并不是害怕産品經理變更需求，而是害怕産品經理自己沒有想清楚，給出的産品方案難以自圓其說，反複修改而又達不到想要的結果；

6、讓團隊的每個人都參與進來，發揮程序猿的主觀能動性，認真聽取來自技術、設計、測試端的那些“莫名其妙”的建議，善用并适當采納這些建議，你會發現很多事情會簡單很多；

7、放松一點，保持頭腦清醒，激活你的團隊，讓成員給你反饋。

以上，供你參考。

PRD内容架構

現在出發，我們的目的是讓你的PRD相對輕便，别人願意看，自己也不太“痛苦糾結”。

文檔導航：讓你的團隊成員知道怎麼看，盡可能一份文檔描述清楚而又完整；
版本摘要：讓你的團隊成員明白為什麼做；
變更日志：讓你的團隊成員知道你“又做了什麼手腳”；
産品原則：通用性的規範，讓所有人都知道應該遵從什麼标準，什麼要求，做成什麼樣；
功能結構：通俗一點的說法就是，“用圖來描述”你現在想從哪裡動刀子了，是要改動“個人資料”模塊還是訂單頁面；
關鍵流程：别什麼都畫一個圖，把核心的流程描述清楚即可；邏輯完整，你甯可缺少一些場景的邏輯，而不是連一個場景都講不清楚；
故事闆與原型：用場景化的語言描述某個功能是什麼，配合适當的例子，讓團隊成員真正理解這個場景下的用戶行為。

文檔導航

給PRD加一個導航系統，是為了清晰的引導團隊成員看快速找到他所關注的内容。

axure實戰教程（活用Axure撰寫輕便的需求文檔）2

為什麼要有導航？

1、從這個導航結構，所有人都能一眼就明白這個版本的概貌，能清晰的知道要做什麼，也知道你又改了什麼，更重要的是，這個結構的第一步描述了整個版本為什麼要做的原因——需求的出處，以及産品的價值。

2、如果有條件的情況下，可以弄一個小型的服務器，整個團隊其實隻需要通過浏覽器直接範圍這個地址即可。【一定要創造條件，避免産品原型，或RP文件，或壓縮包通過郵件、QQ、微信漫天飛的現象。】

産品經理有責任确保整個團隊隻有一個需求的輸入口——需求的及時同步，産品經理也需要确保流轉到下一個任何環節都是經過确認的版本。

版本摘要

axure實戰教程（活用Axure撰寫輕便的需求文檔）3

版本定義與目的

在定義一個版本，編寫一份PRD的時候，整個團隊首先需要了解的是，這個版本為什麼要做，做了有什麼用。嘗試描述這些問題有很大的幫助：

為什麼要這個版本，是運營驅動還是産品驅動？
這個版本主要做了什麼，能為用戶帶來什麼？
做完這個版本，對産品的競争力能帶來什麼提升？

裡程碑計劃

很多公司，産品經理和項目經理是完全兩個不同的角色，通過彼此的協調配合共同來推進一個項目【叠代】。但在一些創業公司，或者相對小型一些的企業，産品經理&項目經理統稱為PM，有PM來統籌資源，推進進度，當然也包括産品需求。對這一類的産品經理而已，必須把控整個項目的進度。

在這種工作環境下，需要保證整個團隊（從上到下）對進度節點的一緻認可和知悉，并盡可能的嚴格按照計劃來執行。否則，極容易出現場面失控，一口又一口結結實實的鍋，會讓PM們吃不完兜着走。

具體到項目進度的編制、執行和控制，是另外一個話題，暫且略過。

其他

摘要都可以起到一個極好的歸納作用，引領整個團隊正确的理解項目。視不同的情況，不同的産品（業務）類型，版本的摘要有完全不同的内容，如果是乙方的項目，則還可以把項目架構，溝通機制都作為一個摘要來傳遞。

一個建議是，盡可能的把文檔歸攏，而不是完全依賴郵件滿天飛。

變更日志

最善變的，不是你的女朋友，而是“需求”。

axure實戰教程（活用Axure撰寫輕便的需求文檔）4

所有應對和管理需求變更的“奇淫技巧”，首先要的是能夠從心理上有所準備，能夠擺正心态正确面對需求的變更，然後才是通過恰當的手段管理需求變更——不要想着去控制變更，一字之差之間有很大的不同。

需求變更帶來的困境

額外的開銷
項目的延期
團隊士氣低落
質量失控

應對需求變更的建議

（1）通過角色扮演來挖掘需求

這個鍋，産品經理得徹底背起來。需求的頻繁變動，往往最根本的原因就是需求與用戶的真實場景相背離，産品經理直接套用了用（ling）戶（dao）們（men）的“解決方案”演變為功能需求，導緻在整個功能的設計階段，流程梳理環節越走越遠而往往不能夠自知，鑒于此，産品經理一定要學會如何扮演角色，倒推場景下的用戶行為。隻有在這個階段，把自己演變為“小白”才可能真正發現和理解用戶——秀一場cosplay吧。

（2）借助團隊的力量驗證需求

不要維護自己的方案，你的方案第一次拿出給到設計師、程序猿的時候，就是為了讓他們來給你找出問題，在第一次需求評審的時候，盡可能的傾聽來自團隊的聲音，你應該把第一次需求評審會議改為“需求表演會”。産品經理應該要理解，隻要在越早期的時候，被研發質疑，然後再通過需求驗證，才能讓團隊感受到這些團隊的力量，你應該讓你的團隊協助你，而不是讓他們按照你的方案來執行。

（3）保持需求的唯一出口

這是一個重大的災難。需求多端發起，特别是甲乙方的項目，涉及的幹系人過多，以及跨部門協作的時候，每個人都在發表聲音，從而導緻局面徹底失控。這就是為什麼建議在一份PRD的開頭明确一個協同規則的根本原因，把它作為項目的頭等大事，寫在最首要的位置，時刻同步給到每一個人。産品經理應該盡可能的建立一種“隻有PM确認的工作才付諸行動”的氛圍。

（4）保持持續性更新

需求變更的另外一個重要原因就是，需求沒有及時同步，任何一個小的變更，一定要随時同步到整個團隊，它除了影響研發之外，還包括設計、測試團隊，以及後續的運營團隊。

所有的關于需求變更技法，都是在補救你此前捅過的婁子和埋下的雷。不要奢望能躲避需求變更，而是要引導和管理在合适的範圍内。

不要害怕變更，畢竟唯一不變的，就是變化。

産品原則

産品經理應該盡早制定一份産品的基本原則，什麼能做，什麼不做。當然，這裡可以完整的描述從體驗角度需要遵從的基本規範。

axure實戰教程（活用Axure撰寫輕便的需求文檔）5

這裡沒有太多的建議和參考，你的産品原則，既可以是戰略性的，也可以是産品功能性的，可以大到決定産品方向，可以小到顔色字體。

制定産品規範（原則）的目的，是為了保障産品的體驗一緻性。更重要的是，保護你的産品不出現意外。産品經理應該盡可能的從多維度制定規則，但不要過于複雜。越是方向上的東西越是要簡單。例如微信，如果傾向于發信者的立場，在後續的版本過程中更多的維護發信者的體驗；如果是傾向于收信者的立場，則一定在保障發信者的體驗。

任何産品都很難照顧到産品的所有角色，必須明确産品的側重點是什麼。

功能架構

想象一棟樓，你能看到有地基、柱子、橫梁、牆面、屋頂，這個樓之所以不會輕易垮塌，就是因為這些部件構建了一種穩固的結構——物理架構。你一定很快就能想象得到，房子要能适合居住，就得有進排水（系統），得有電力供應（系統）等等，這就從邏輯層來構建一棟樓的結構。

從這樣一個粗糙的描述裡面，你應該能夠理解，所謂架構，就是把各個部件進行歸納彙總，提煉抽象，并通過适當的鍊接方式打造成一個穩定的形狀，滿足人們的實際需要。在你面對一個産品/一個需求的時候，應該能在腦海裡勾畫出模型，什麼東西是4個桌腿，什麼東西是一個桌面，4條腿和一個桌面如何共同構建和支撐這個業務的穩定運行。

axure實戰教程（活用Axure撰寫輕便的需求文檔）6

通常情況下，一份PRD中，隻需從物理結構層詳盡的描述“功能結構”即可。實際情況是，有的情況下，你并不需要畫一個結構圖，因為産品的結構可能已經千年不變了，這個版本也可能僅僅是修複一些問題，甚至隻是把方形的用戶頭像改成圓形——因為你的老闆覺得好看。

産品架構不僅是能支撐當下的業務，也要能具備适度的擴展性和容錯性。

關鍵流程

越是複雜的系統，越是推薦把流程圖做一個目錄，不但是引導閱讀者，而是檢查遺漏的方法。同時，産品經理在繪制流程圖的時候，盡可能的遵從通用的規範，并養成養好的習慣。好的流程圖，可以快速讓整個團隊熟悉理解業務，并優化業務。

axure實戰教程（活用Axure撰寫輕便的需求文檔）7

梳理業務流程的步驟，估計沒有多少經驗的産品經理們都能想象得到，先要去調研，然後畫成圖，在這個過程裡面會有确認，完善的工作。調研的過程是為了解決who，what，why，how，以及where的問題：誰，在什麼情況下，做了什麼事情，這個事情需要什麼前置條件，又輸出了什麼，這個事情在哪裡完成的？

但這極可能陷入形式主義性質的錯誤，這種調研僅僅是在知道“用戶現在怎麼做？”最後極可能得出一個流水式的糊塗賬。産品經理需要的是探索更深層次的問題，為什麼要這麼做，為什麼不這麼做？

流程的基本意思是指水流的路程，也就是工作進行中的次序或順序的布置和安排，由兩個及以上的業務步驟，完成一個完整的業務行為的過程。對一項業務來說，從它的輸入到最終的結果，理論上來說就是一張流程圖就可以畫完整，但為什麼不這麼做呢？

沒有多少人可以一口氣看完一張橫跨多個業務角色、多個業務部門的流程圖後，能有一個全局的概念。這種形式的流程圖，會讓人陷入一種不可收拾的泥潭中。産品經理不僅僅是要知道每個環節的流程，更要理解整個業務的體系，并協助團隊成員從全局來理解業務邏輯。你需要把業務的核心剝離得出來，抽象出多個可以支撐業務的關鍵支點。隻有先搭建了一個好的戲台，人物角色才能夠全面鋪開。在你的腦海中想象一串葡萄的樣子，你的業務流程圖也應該是這樣，一條主線若個支線無數節點。

每一項業務通常都能找到它的關鍵支撐點，比如O2O項目，我們可以抽象歸類出“受理、派單、接單、回單、回訪”5個業務動作，通過這5個基本的業務動作，能夠讓整套系統流轉不同的業務單據，能夠支撐多個的業務角色，而不是簡單粗暴的讓流程跟着單據走，不能演變出新增/删減一份單據都需要重新定義、修改流程的局面。

實際上，你應該發現，對産品經理而言，是先有業務，再做框架，然後是功能，最後是過程。一定要避免直接操刀把一個産品拆分成多少個模塊，模塊多少頁面，頁面内是什麼按鈕。

故事闆與原型

所謂的用戶故事，就是描述用戶想要實現的功能，最簡單的說法，就是“誰想要幹嘛”。

産品經理們的PRD文檔會出現”寫了沒有人看“的尴尬，一個重要原因就是用戶需求的描述方式。你寫了很多也足夠細緻，但讀文檔的人卻始終沒有辦法進入角色。過于技術化的描述讓人昏昏欲睡沒有思考的欲望，根本在于閱讀者不能通過角色置換想象一個用戶在幹嘛，要幹嘛，以及為什麼。

随着業務複雜性的提升，”需求清單“會變成像裹腳布一樣讓人不願意忍受。

根據用戶的業務場景寫成故事闆，而不是列出一張”需求清單“。這麼做的目的是為了保證團隊能夠理解、認同為什麼要這個功能，以及用戶是怎麼做的，并引發團隊的思考。

産品經理描述的功能需求（故事闆），應該盡量用團隊可以理解的業務語言來描述，而不是描述諸如字段，存儲的技術語言。作為産品經理，必須把重心放在用戶所能理解的問題上。你解決的是用戶的問題，而不是程序猿們的問題。比如頁面響應速度這個問題，産品經理可以描述為“啟動頁3秒後自動跳轉到首頁”，而忽略“響應速度”本身是個什麼概念——原因在于你的用戶并不能理解你的響應速度，而你應該像你的用戶一樣思考問題。

故事闆并不是為了追求完整性，而在于它能夠被理解和有價值。所以，不太建議過于在意”故事闆怎麼描述“這個問題，這可能不是最重要的是問題。關鍵是場景覆蓋的程度，覆蓋越廣，适應性會更強，程度越深，可能用戶的體驗相對會更好一些。産品經理需要在不同的版本裡面權衡在什麼版本做什麼功能，二八法則可能是你很好的一個工具。

想辦法讓你的團隊在你的文檔裡面”看見“用戶的具體行為動作，在每個人的腦海中構建出一副生動的畫面，你的PRD才會有活力。