作為PM，寫PRD文檔就相當于對于一個程序員來說要會編碼，對于UI設計師來說會用PS進行設計，這是一項我們繞不開的技能。
也經常聽到有人說，寫文檔有用嗎？我們的程序員是不會看這些東西的，他們都是直接上原型圖，PM寫的PRD文檔洋洋灑灑那么多字，最后沒人看，還寫它干嘛？
那我們PM為什么還要寫PRD文檔呢？
事實上不管你寫不寫PRD文檔，當產品最終出現問題時，這個鍋一定是你來背！你是產品負責人，產品出問題，不找你找誰？
所以PRD文檔真的不重要嗎？答案是否定的。PRD文檔當然重要，開需求評審會的時候，評審內容有PRD文檔吧！當然一些小型的初創團隊都是PM直接說了算！自然不用什么評審會。但產品出問題了，總得找問題做備案吧！當PM離職的時候總得做交接工作吧！沒有交接，那下一任PM還得重頭慢慢梳理產品功能流程？
這個時候PRD文檔的作用就體現出來了。
1. 產品出問題時，可以快速定位問題，做備案
2. 開需求評審會議時，整體過PRD文檔，程序員可能不看你的文檔，但是開會時，大家都會整體的過一遍你寫的PRD文檔，對產品的整個流程有個清晰的認知
3. PM離職時，交接必備物
那么如何撰寫PRD文檔呢？
現階段，市面上談論最多的也就是三種寫法。第一，word ＋ 原型圖，這也是絕大多數PM所推崇的做法；第二，原型圖標注，直接在原型圖上標注自己的注解，其實就是把word＋原型圖合二為一了；第三，上次看到的有人直接用Excel寫文檔，需求變更、產品輸出等都十分的方便。
今天這里，主要還是談論用的人數最多的形式，因為我們寫文檔也主要是要把PRD文檔所涵蓋的內容表達清楚，邏輯理清楚。至于形式，大家在掌握了寫法后，大可以都試一圈，然后找到最適合自己的，沿用下去就好。
首先，PRD文檔大體涵蓋以下幾個部分。
第一，文檔頭。包含文檔名稱、作者或撰寫人、文檔編寫日期、版本紀錄。這是方便后期產品如果出現問題時，可以直接找到相關負責人，以及在后期迭代中，直接更新版本，加減功能即可。
第二，就是目錄。我們的目錄包含以下5大塊。
1. 產品背景、目標 、用戶角色
2. 產品需求（功能介紹，增加的、刪除的、改變的......）
3. ?產品流程圖（整個產品從頭東尾運行的流程圖，此處可能會有流程圖、泳道圖等）
4. ?產品附件（這里包括測試用例、Axure高保真原型圖地址等）
5. ?其它需求（非功能性，比如運營、測試等）
接下來，針對以上的某幾個重要的部分詳述。
1. 產品背景、目標
這里背景主要是引出為什么我們要做這款產品？
目標則是，我們推出這款產品是希望它最終達到什么目的。達成這個目的的階段性目標是什么，該怎么去實現？跟競品相比，我們希望它有什么獨特性能讓它脫引而出？
2. 產品需求
落實到產品具體的地方，產品有哪些需求？增加了哪些需求？調整了什么？取消了什么？需不需要其他資源的配合？有什么影響？，把幾個地方說清楚。
當涉及到有些特別重大的功能時，可以用圖文的形式，有側重點的進行梳理。
3. 產品流程圖
這是整個產品的框架，因此描述清楚是非常有必要的。我們需要講清楚產品的每個邏輯點，每個地方應該怎么走？應該做什么樣的判斷？如果進行到這個操作會返回給用戶什么內容？用戶觸發之后得到什么內容？失敗了會返回什么，成功了會返回什么？......
如圖所示，這就是我們把一款產品從頭到尾的流程畫出來的效果。從登陸界面，到執行完所有產品功能其中所有的邏輯。程序員不會看我們PM的整個“冗雜”的文檔，他們只會看這些圖例以及我們的原型圖，因此把邏輯理清楚，對于我們PM來說，是無比重要的（因為針對這些邏輯的東西，程序員是會有很多發言權的）。
4. 其它需求
俗話說，PM是產品的生父，運營是產品的養父，這就是產品與運營之間的關系。
這里可能會涉及到與運營對接等需求，因此在撰寫PRD文檔時，我們需要實時的與運營進行溝通，他們作為一線人員，直接對市場負責，我們產品人員，可以直接從他們那獲得用戶的需求等
這樣，大體PRD文檔所涵蓋的內容就都有了。最重要的一點，我們PM撰寫PRD文檔時，希望迭代一就盡可能完美，后期產品迭代時，我們只需要單一的修改功能即可。需求不要經常性變更，相信我，程序員是十分反感這點的。
