作者分享了4個撰寫PRD的關鍵思路， 希望這些思路， 可以讓你在撰寫PRD時有所受用。
我看了一下互聯網上面的文章， 流覽量高的文章，
那麼我這篇更偏“道”一些， 想講一講做產品兩年多以來， 對PRD撰寫的一些思考：
一、撰寫PRD應該是一個的動態獲取資訊的過程
心理學上， 有一個效應叫做：錨定效應。
大概是講， 人會傾向於依賴容易獲得的資訊， 快速得出結論。
比如， 我們常常說的“第一印象”；或者《思考， 快與慢》中作者提到的大腦中無意識的“系統1”依賴情感、記憶和經驗迅速作出判斷；或者《約伯斯傳》中提到喬幫主常用的判斷工具“直覺”。
這是原始進化動物生存的本能——站在劍齒虎面前思考的猿猴早被滅絕了。 這種決策路徑效率高， 省心省力。
但是在未儘量獲取足夠資訊的情況下（或經驗欠缺的情況下），
做完決策後， 還有會有一種沉沒成本效應的心理作祟。 決策者即使後來認識到錯誤， 往往也難以說服自己改變船頭的方向（腦補一下跟開發哥哥說要改需求的痛苦情景）。
（摘自《神秘的程式師》by西喬）
因此在開始撰寫產品PRD之前， 需儘量獲取更多的資訊， 使用使用者調研、資料分析等手段。 最土又最有效的辦法就是多問幾位前輩的意見， 兼聽則明。 但是， 如果在執行過程中， 如果真的發現方向偏了， 也要有勇氣踩刹車， 勇於承擔錯誤。
二、物件導向設計產品
其實我大學學的是物流管理， 半毛錢程式設計都不懂， 但是曾經讀過Java的介紹留下印象：Java是一門物件導向的程式設計語言。 什麼是物件導向？結合兩年多的產品經驗， 以我粗淺的理解， 主要有幾個特點：抽象、封裝、可複用。
世間的萬事萬物都是可以被抽象的。
比方說， 你要做一頓飯。
封裝是個啥意思呢？
簡單說， 就是老死不相往來。 炊具、調料、食材三者互不關心各自有什麼內容。 你把生菜換成芥藍， 我還是可以把它做成一道菜。
那麼可複用呢？
我每天都可以拿這三個物件做飯。 老王來了， 他也可以拿這三個物件做飯， 不用自己帶一套過來。
（如果理解錯了， 求程式師勿噴。 ）
我認為設計產品時， 也需要物件導向設計。
舉個簡單的例子。 以往唯品會app的忘記密碼功能， iPhone、Android、iPad、WAP都需要開發一套原生介面， 維護成本高， 後來改成了統一的H5流程， 那麼原生app再也不用關心H5忘記密碼的流程到底是怎樣的， 忘記密碼的反覆運算也不依賴app的發版。
第二個例子。以往唯品會個人中心功能表資料在中間層（服務層）配置維護，且不支援分流。但是公司內部有一個開關分流系統，可以創建開關，並靈活配置各種複雜規則。
那麼，按物件導向的思維設計：
對於前端。前端去請求功能表資料時，需要獲取的僅僅是：哪些功能表有資料？中間層返回了資料，前端就展示出來。不返回資料的，不展示；對於中間層。如果某個功能表需要分流，那麼可以在這個功能表上配置一個開關編碼，按這個開關編碼，帶上前端請求時帶的一些參數（使用者資訊），去請求開關分流系統。那麼中間層也不必理會開關的配置複雜規則，僅僅需要知道一個結果：開或者關。開，就向前端返回某功能表的資料；關，則不返回。對於開關分流系統。仍然是幹自己的事情，管理開關的創建及規則配置。三者之間的邊界清清楚楚，而且對於運營來講，極其靈活。
再扯遠一些，很多交互設計定義的元件（報錯元件、彈窗元件等），其實也是物件導向思想的一種應用。
物件導向設計產品的好處也是顯而易見的，最直接的便是節約開發、維護成本。另外，也能説明產品經理提高抽象思考能力，關注問題的本質。
三、面向PRD用戶角色進行設計
PRD其實本身也是一件產品。它的用戶是：開發、測試、設計師、專案經理。好的PRD也應當符合交互基本原則：don’t make me think。
在撰寫PRD的時候，需要仔細的考慮面向使用者角色的需求：
開發。涉及多開發團隊時，不同的團隊希望清楚的知道自己的開發範圍邊界是什麼？當然，最重要的，需要怎樣開發？和以往相比，改動了哪些東西？測試需要知道，使用者場景有哪些，便於撰寫豐富的用例，模擬真實的操作場景。設計師，需要瞭解哪些介面需要重新設計。專案經理需要知道專案的基本人員組成、預期上線時間、資源、風險等狀況。在撰寫文檔時，最好能針對不同角色，劃分不同的模組進行闡述，向不同的人展示不同的重點內容。同樣也是面對物件的思維。
四、結構化、圖化
PRD應儘量使用目錄、表格、流程圖、交互圖等結構化的表現方式。程式猿哥哥都喜歡。
曾經有一些產品經理寫了一堆的文字山，然後就沒有然後了。
總結一下撰寫PRD應該是一個的動態獲取資訊的過程物件導向設計產品面向PRD使用者角色進行設計結構化、圖化。
此外，撰寫PRD是一件需要不斷實踐，不斷總結的事情。但願上面的這些思路，可以讓你的PRD變得更牛逼一些。共勉。
本文由 @Joao_Zhang 原創發佈于人人都是產品經理。未經許可，禁止轉載。
第二個例子。以往唯品會個人中心功能表資料在中間層（服務層）配置維護，且不支援分流。但是公司內部有一個開關分流系統，可以創建開關，並靈活配置各種複雜規則。
那麼，按物件導向的思維設計：
對於前端。前端去請求功能表資料時，需要獲取的僅僅是：哪些功能表有資料？中間層返回了資料，前端就展示出來。不返回資料的，不展示；對於中間層。如果某個功能表需要分流，那麼可以在這個功能表上配置一個開關編碼，按這個開關編碼，帶上前端請求時帶的一些參數（使用者資訊），去請求開關分流系統。那麼中間層也不必理會開關的配置複雜規則，僅僅需要知道一個結果：開或者關。開，就向前端返回某功能表的資料；關，則不返回。對於開關分流系統。仍然是幹自己的事情，管理開關的創建及規則配置。三者之間的邊界清清楚楚，而且對於運營來講，極其靈活。
再扯遠一些，很多交互設計定義的元件（報錯元件、彈窗元件等），其實也是物件導向思想的一種應用。
物件導向設計產品的好處也是顯而易見的，最直接的便是節約開發、維護成本。另外，也能説明產品經理提高抽象思考能力，關注問題的本質。
三、面向PRD用戶角色進行設計
PRD其實本身也是一件產品。它的用戶是：開發、測試、設計師、專案經理。好的PRD也應當符合交互基本原則：don’t make me think。
在撰寫PRD的時候，需要仔細的考慮面向使用者角色的需求：
開發。涉及多開發團隊時，不同的團隊希望清楚的知道自己的開發範圍邊界是什麼？當然，最重要的，需要怎樣開發？和以往相比，改動了哪些東西？測試需要知道，使用者場景有哪些，便於撰寫豐富的用例，模擬真實的操作場景。設計師，需要瞭解哪些介面需要重新設計。專案經理需要知道專案的基本人員組成、預期上線時間、資源、風險等狀況。在撰寫文檔時，最好能針對不同角色，劃分不同的模組進行闡述，向不同的人展示不同的重點內容。同樣也是面對物件的思維。
四、結構化、圖化
PRD應儘量使用目錄、表格、流程圖、交互圖等結構化的表現方式。程式猿哥哥都喜歡。
曾經有一些產品經理寫了一堆的文字山，然後就沒有然後了。
總結一下撰寫PRD應該是一個的動態獲取資訊的過程物件導向設計產品面向PRD使用者角色進行設計結構化、圖化。
此外，撰寫PRD是一件需要不斷實踐，不斷總結的事情。但願上面的這些思路，可以讓你的PRD變得更牛逼一些。共勉。
本文由 @Joao_Zhang 原創發佈于人人都是產品經理。未經許可，禁止轉載。