身為一位產品經理，其中一個工作就是接收各地飛來的奇耙 “要求”，我都笑稱自己是許願池，神燈裡的精靈。而精靈最頭痛的事情，不是實現願望，而是了解願望。因為一但理解誤差，就會像電影神鬼願望一樣，錯把變成有錢人的願望，實現成販毒致富的毒梟，或是許願變成籃球明星，結果那話兒卻小的可憐。

其實開發團隊才是真正把願望落地實現的精靈，而每個提出要求的stakeholders就是拿著神燈的許願者。PM身為稱職的神燈(?)，就是要把這些奇耙的 “要求” ，具體化成開發團隊能夠理解的 “需求”，並且確認需求最終帶來的結果和公司的走向一致，這就是PRD的目的及價值。

什麼是PRD

Product Requirement Document ，產品需求說明書，顧名思義就是制定需求的文件。有一點需要注意，和開發團隊討論需求時，最忌諱只談論要做什麼（What），而忽略了為什麼要做（Why）。後者代表需求的終點，也就是需求帶來的價值，而前者只是實踐價值的過程而已。有了終點，團隊就知道該往什麼方向努力，有時優秀的團隊甚至會以技術立場提出比PM更有效率的需求，這就是讓團隊有共同目標的優點。

所以PRD除了詳細紀錄功能描述之外，更重要的是把stakeholders的目標，需求帶來的價值以及要完成的目的都記錄下來，讓團隊每一個人都明白最後的終點以及需求上線後預期看到的成果。上線之後，如果結果不如PRD預期，那就再根據現況進行迭代，一步一步邁向目標。

PRD包含什麼

1. 文件版本紀錄和基本資訊

紀錄每個版本的修改，作為日後追蹤使用

2. 專案目的(Purpose)，專案範圍(Scope)以，及專案目標(Goal)

專案目的：闡述這個專案的來龍去脈，包括這些功能的定義是如何產生的，是經過AB測試或是用戶調查，為什麼要做這些功能，這些功能是為了解決用戶什麼樣的問題等等，簡單來說，專案目的就是這個專案會提供用戶什麼樣的價值。要注意，專案目的必須與公司的目標一致，如果公司使用OKR指標，就可以把O放進專案目的中。

專案範圍：專案目的只有一個，但是達成的方法很多種，專案範圍必須明確制定，幫助團隊聚焦在最重要的功能上。

專案目標：設定追蹤指標，確認專案完成後必須達到什麼條件，這裡必須明確的列出指標名稱，指標計算方式，以及達標的定義。

3. 功能列表

主要有四大欄位，其餘欄位可以依據不同專案增減
User Story：以user story的方式描述需求，強調功能的目的
Functions：將user story從功能面的角度拆解，讓開發團隊更明白需求細節
Success Matrix：將功能和指標關聯在一起，目的還是只有一個，讓團隊聚焦在預計達成的目標以及需求會提供的價值
Acceptance Criteria：使用Given…When…Then…描述各種情境，讓開發以及QA團隊明白功能最終呈現方式

4. FlowChart和Wireframe
如果功能列表是單點的需求描述，那麼FlowChart就是這些點連起來的流程邏輯圖。這份流程圖描述使用者在系統上操作時，功能之間的前後關係。Wireframe通常是PM和設計師溝通需求後，產生的一份簡圖，用來和開發以及需求單位一同確認UX設計。有些PM會自己製作簡單的wireframe，做為和設計師溝通的工具。

總結

PRD的存在，是為了解釋需求帶來的價值，為何要做這些需求，以及需求本身的詳細描述。文件內容沒有一定的規格，只要能夠達成上述的目的，任何寫法都可以。如果你沒寫過PRD，本篇範例可以作為一個起點，讓你練習如何寫一份完整的需求說明書。