本文檔只討論一件事情，如何才能寫好PRD文檔

PRD文檔是產品每天工作中必須撰寫的文檔，能夠寫出好文檔成為一個PM的基本技能要求。然而，寫好PRD并不容易。
不但很多剛入門的產品經理很難寫出專業(yè)且質量高的PRD，如果你讓從業(yè)多年的資深產品經理親手撰寫，也難免會出現(xiàn)小到功能疏漏定義不全，大到邏輯與已有功能相矛盾的情況。

你是否遇到過以下情況？

狀況1: 同一功能經過多次迭代，現(xiàn)狀如何只能查代碼，為什么這樣設計沒人說得清只能推翻重新思考

幾乎所有公司的PRD文檔很難用井井有條來形容

王同學是從業(yè)多年經驗豐富的產品經理，接受某條產品線后，某次迭代需求需要調整一個相關的老的功能模塊。然而這個模塊的具體邏輯沒有人說的清楚，使用關鍵詞查找歷史文檔找到10多篇，信息支離破碎，無從整理。好不容易讓研發(fā)大大耗費2-3天查代碼把邏輯搞清楚了，卻不知道當時為什么這么設計，產品設計陷入僵局。前任產品也很委屈，我寫的很清楚呀，只是你找不到。文檔當時總監(jiān)也Review了，沒毛病。

• 原因分析：歷史文檔版本管理混亂，查找麻煩。

• 解決方案：產品經理需要按照功能模塊來持續(xù)修改文檔。至于多文檔中同一個功能模塊更新繁瑣，維護成本增高的問題。

你是否遇到過以下情況？

狀況2：產品經理寫的PRD總是漏掉細節(jié)

細節(jié)太多，告訴大家要多上心多注意真的有用嗎？

總監(jiān)和團隊Leader一遍遍指出遺漏點，但好像這些點永遠也改不完。最終研發(fā)做出來一堆問題，回顧甩鍋大會上，產品只能認栽，承諾下次寫的更細致一些。但是，當事產品經理也很委屈，我就差親手寫代碼了，到底還要怎么詳細呢？

• 原因分析：缺乏系統(tǒng)的撰寫框架，瑣碎的點過多，復雜的系統(tǒng)設計中難免漏掉重要細節(jié)。

• 解決方案：每次撰寫一個組件、一個頁面、一個功能，都需要定義好框架和結構。下次再引用的時候就可以站在巨人的肩膀上，有效提醒撰寫者避免遺漏?？蚣苋绾螛嫿ǎ?/p>

你是否遇到過以下情況？

狀況3：同組內同樣的功能大家反復思考，反復造輪子。

產品做完的思考如何能夠模塊化的被復用到其他人的設計中？

明明是同一個產品，各個功能模塊內部各自為政，差異越來越大。當事產品表示，別人做了什么，怎么設計的，我哪知道，總不能天天把所有人寫的PRD都讀一遍吧。

• 原因分析：相似的功能沒有抽象出來，也就更不用說能否檢索的問題了。

• 解決方案：做過的組件要抽象出來單獨放在一個組件庫，整個團隊都可以共享這個庫中的資源。當然，如果有一天產品經理離職了，這些資產被抽象出來，理應可以被其他產品繼續(xù)復用。

你是否遇到過以下情況？

狀況4：原來投影技巧也需要培訓，很多產品真的控制不好文檔和原型的互動

一會議室的人都在等產品，更糟的是，產品所有笨拙的操作都會被投影出來

產品經理召集了一大票研發(fā)、測試同學坐在會議室里面講解需求（評審），但一會兒看文檔，一會兒看原型，原型窗口大小又很難控制，沒幾分鐘就把研發(fā)測試都將暈了。文檔的邏輯和原型對應不上，原型比例一會兒太大，一會兒太小，大量時間被浪費。

• 原因分析：原型中的各個部分應該與PRD中的對應描述相對應，預設好對應關系，會上才能從容自如。

• 解決方案：焦點移動到文檔的指定的位置后，原型部分會按照預設自動調整位置和縮放。