哈囉，朋友

最近因為公開了 UXD 產品設計課的關係，收到許多人的問題，其中關於「PRD」的討論比例很高，包括了：

「如何建立更系統化的交付文件？」

「如何撰寫開發也看得懂的PRD文件？」

「因合作PM不會寫PRD也不會出spec，想了解最基本的PRD模板元素應該要列到多細才堪用？」

「如何寫出清楚明瞭讓工程與外部人士都了解的規格書？」

​

因此今天想跟你聊聊我怎麼看待「產品需求文件 PRD」。

我想將這個議題分解成以下項目來討論：

• PRD 文件的目的
• PRD 文件的用途
• PRD 文件的內容

​

▋PRD 文件的目的 ▋

我認為 PRD 文件的本質目的是「定義方向」，清楚的說明為什麼有這樣的需求發生，我們期望產生什麼效益，如此一來後續的解決方案就是為了證明我們是否有滿足需求？

譬如說公司一開始想要的目的是犒賞員工，對應的策略是舉辦員工旅遊，並讓參與者感受到奢華的服務，因此解決方案是訂高級的飯店。

但因為高級飯店的團體住宿之中有大型會議廳的包套服務，某個主管覺得可以順便舉辦一些團建活動來讓員工參與，順便做教育訓練。

雖然資源是有效的利用了，但原本「犒賞員工」的目的可能也被破壞了，畢竟被公司抓去高級飯店做團建活動與教育訓練怎麼樣也不會讓員工覺得是被「犒賞」，頂多是「感覺舒適的進修」。

這世上有非常多為了手段而拋棄目的的決策，撿了芝麻掉西瓜的事情屢屢發生。

描述品質優秀的「需求」往往要有一些抽象的空間存在，這樣才能既指名方向，又不限制非要用什麼手段來實現不可，好讓實現需求的團隊能夠因時因地制宜，根據現實狀況來提供解決方案。

但人腦非常的不靠譜，特別是對於抽象目標的理解容易扭曲成更簡單具體的東西，例如你本來犒賞員工的策略是提供奢華感的享受，但最後大家只記得七星級飯店，因為我們的腦袋喜歡明確具體的事物。

因此，透過寫下 PRD 文件來幫助我們找出一種說法，既可以描述抽象的目的，還為了防止我們的記憶混亂，避免因為與不同的利害關係人討論，就迷失了原本的方向。

​

▋PRD 文件的用途 ▋

許多人會問「該如何寫出讓工程師或需求方都了解的文件？」

這個問題背後隱藏的語意，很像是希望將文件丟過去讓對方自己閱讀，就能避免溝通似的。

坦白說，做不到，因為人跟人的合作過程就是會有認知落差，而文件是沒辦法彌補認知落差的，必須要根據你溝通的對象，來調整溝通的顆粒度以及溝通的進度才行。

因此 PRD 文件第一個最好的讀者其實是撰寫文件的你自己，這份經過思考寫下來的文件，讓你可以在溝通重要需求的場合之中攤開來當做參考資料，降低你的認知負擔，不用每一件事情都重新載入腦袋之中，把你有限的認知資源用在面對當下的溝通議題。

從事軟體產業的朋友多半是聰明人，許多聰明人都喜歡仰賴自己的記憶來憑空討論事情，這其實是一件非常浪費認知資源的行為。

相對的，如果你寫下來的 PRD 連自己事後都不想要打開來看，在各種討論需求的場合之中沒辦法幫助你理解現況，那麼要怎麼奢望別人會想閱讀你所撰寫的 PRD 文件呢？

再強調一次，PRD 文件第一個最好的讀者其實是撰寫文件的你自己，好好的利用它吧。

​

▋PRD 文件的內容 ▋

接下來討論「PRD 到底要寫到什麼程度？」（啊，終於寫到本文標題了）

我會分為「設計目的」、「目標情境」、「實踐規則」與「描述解決方案」這幾個區塊來作為 PRD 的內容。

​

「設計目的」最容易理解，也最不容易寫得好，如同上面提到的，優秀的「需求描述」必須帶有一點抽象空間，既指名方向又不定義具體的解決方案。

​

「目標情境」的部份，我的起手式是定義參與系統運作的角色是什麼樣的權責？這些參與流程的使用者各自擔當什麼任務？

這部份依賴任務步驟的分析，將抽象的目標轉換成一個一個小目標，並且定義每個小目標的任務步驟。

​

「實踐規則」包括了具體的任務案例，描述解決方案應該要在指定的情境中滿足的條件，這可以作為最基礎的驗收標準，這種 Usecase 通常是硬指標，不涉及好用不好用的體驗流程，例如說使用者可以使用信用卡作為支付方式就是硬指標，結果只有能或不能，但刷卡流程設計的很糟糕就是另外一個議題。

通常沒有軟體產品開發經驗的需求方最痛苦的就在這段，因為他們拿捏不准需求被實現時的品質，可能對於工程師而言已經滿足需求（你看，能刷卡啦？），但是對需求方來說操作流程的體驗極其複雜難懂。

如果軟體產品會涉及實體環境的工作流程，那麼還需要梳理數位環境與實體環境的服務流程，確保業務邏輯是具備可行性的。

​

最後是「描述解決方案」，這邊會定義為了滿足使用者案例所需要的功能或資訊內容，例如有個 UseCase 指定了使用者可以註冊成為會員，那解決方案之中要描述成為會員的流程圖以及操作過程會需要用到的資訊來源。

​

我一般會把功能性的部分獨立畫成 Functon flow 流程圖，描述解決方案的運作邏輯。

​

另外把解決方案之中會需要的資訊內容進行結構化的分析，整理成資訊架構規劃的內容，例如定義這個系統中有一種內容叫做「課程」，課程會需要有對應的影音內容，以及上架銷售的條件設定。

我會在需求訪談的過程一起進行資訊架構的規劃，就是一面討論「課程的使用情境與業務邏輯」，一面畫出 iA 的示意圖，讓抽象的資訊架構能夠視覺化的搭配案例情境來討論。

​

▋結論 ▋

總結一下，我對產品需求文件 PRD 的看法：

• PRD 文件的目的是「定義方向」，描述抽象的目的，避免我們隨著時間而記憶混亂。
• PRD 文件的用途是，降低你的認知負擔，你應該是最重要的讀者。
• PRD 文件的內容可以分為「設計目的」、「目標情境」、「實踐規則」與「描述解決方案」這幾類內容。

以上是我對 PRD 文件的觀點，分享給你，希望能對你有所幫助。 也歡迎你回信提問嘿！

by Soking