PRD（Product Requirements Document）產品需求規格書是什麼？它是做一道菜所需要的食譜 …

開出一份合格的 PRD 是產品經理的基本功、硬實力（不過我認為這當中也牽涉到軟實力的養成）之一。

廚師出菜都有食譜了，開發一個產品 PM 怎能沒有 PRD 呢？所以在產品開發及現有產品優化、迭代，我們都需要寫好一份 PRD。

​

目錄

• 一份完整的PRD有哪些內容？
• 沒有PRD會有哪些問題？
• PRD也可以很簡短、精細
• 認清團隊及公司的方向

​

一份完整的PRD有哪些內容？

PRD 的用意是促進團隊成員彼此的溝通，雖然它有一個極度完整的內容， 但只要能對團隊有利、能快速理解真實需求及方向那就不一定要有這份 PRD，一張 A4紙、一頁PPT都可以完成，但必須要包含以下這幾個內容。

1. Objective / Goal

   • 產品需求背景
   • PRD 內容名詞解釋
   • User Story
   • User interaction（UI / UX）

2. Product Structure and flow

   • Functional map
   • User Flow（Flow chart）
   • UI Flow
   • Business Logic

3. Timeline and constraints

   • Date（Start, End, and Pull in the date）
   • Budget
   • Timeline
   • Resources
   • Dependencis

4. Document status

   • 版本
   • 修改紀錄

5. More info / Other

   • i18n 語言文字字串
   • Database structure
   • Database table relationship

​

沒有PRD會有哪些問題？

PRD 就是做一道菜的食譜，如果今天一個完全沒有烹飪經驗的人，你跟他說要做 Jellied Eels(鱔魚凍)，你覺得他會知道怎麼做嗎？做出來的菜色，Hell’s Kitchen(地獄廚房) 的 Gordon 會滿意嗎？

曾經在外上課時，業師提及 PRD 這東西只適用在 Waterfall(瀑布式開發)，而敏捷(Agile) 不需要，當時我是不信，一直都不信，今天不管是何種 Methodology，基本的 PRD、SPEC 一定要有！

依我的經驗，有些公司沒有 PRD、完整產品規格這種 Sense，基本上大概是：

• 細節從頭到尾永遠透過口頭溝通
• 你想得到灑在雲端各處的各種檔案
• RD 們通靈東補西補來完成開發

不管是經營者、執行者，你會想待在這樣的團隊嗎？

​

－沒有 Clean Code 只有 Dirty Code

RD 的 Code 髒掉跟 PRD 哪有關係？嘖關係可大了！

需求不斷變更的情況，RD 的 Code 都不知道髒到哪種程度了，然後 branch 一直往外開， 但今天只要開發人員異動，後續接手的人豈不是很倒霉？

同時需求不明確造成開發週期變更，最倒霉的絕對是 RD，他們開始要加班、延誤上線，反正 RD 就是要把東西做出來， 但最重要的是他會開始不喜歡自己、貶低自己在團隊中的價值。

​

－公司沒有高度的策略戰術

如果一間公司沒有 PRD 的素養，那相信在企業經營策略、行銷戰術也沒有完整、具體規劃，大概就是走一步算一步，因為 PRD 和 MRD, BRD 有高度相關性（本篇不探討）。

最終產品做爛，大家再來推責、互相甩鍋，一但有這樣的文化產生、後續的合作也不會多好，傷害已經造成了，就算後續補再好、再精細的 PRD 都沒辦法挽救團隊的向心力。

​

－產品無法良好的優化、迭代

沒有 PRD 也行啦！產品最後很勉強地上線，公司上下開始面臨客服問題的鳥事。

之後要進行產品的優化迭代，怎麼著手？怎麼改？完全是憑感覺，然後再東漏西漏，這邊補一下那邊補一下，PM 和 RD 寶貴的時間就永遠浪費在這。

​

PRD也可以很簡短、精細

相信不管身為 PM 還是 RD，一定會覺得：

難道 PRD 前期規劃一定要花這麼長的時間、這麼齊全的內容才能開始開發嗎？

其實 PRD 也可以很簡短、精細，一共有這四個部分：

1. 產品目標
2. 產品功能
3. 測試及上線
4. 總體資源（時間、預算、人力）

​

－定義產品目標

其包含：

• 產品現況
• 目標
• 背景
• 假設

一開始就把產品目標定義好非常重要，如果 PM 不知道這個產品的最終目標是什麼，勢必進入開發時樓一定越蓋越歪，甚至無法完成。

定義產品目標一定要特別留意，它必須夠具體、夠人性化且易懂，藉此驗證我們非常清楚這個產品的用途，不會有天馬行空的假設出現。

透過以下問題歸納總結並梳理我們的想法：

• 這個產品是給誰使用的呢？使用者要怎麼使用它？這個產品是 2B 還是 2C呢？若只屬其中一種，未來如何延伸呢？( B2B2C)
• 為什麼我們要做這個產品？產品有合適的市場嗎？公司對這項產品的期待是什麼？
• 我們一定要自己動手做？有沒有現成的架構、方式去開發出這項產品？
• 產品開發期間如何做好測試？需要達成哪些指標才能把產品上市？

還有很多細項可以探討，不過最重要的是避免產品目標和解決方案的混淆，把目標定義出來可以讓我們知道終點、目的地，但不是一個到達終點的地圖！

​

－產品功能

當知道產品的目標後，就必須把產品功能給詳細描繪出來，其包含：

• User Story
• User interaction（UI / UX）
• Functional map
• User Flow（Flow chart）

此時幾乎已經進入準開發階段，因為團隊會開始去想如何達成產品的目標？

所以必須時時聯想使用者如何使用這個產品？

• 從使用者角度這個產品的核心重點功能是什麼？
• 使用者如何和這個產品互動？
• 開發者本身的 Domain 和客戶理解的日常用語是一致的嗎？

而具體描述產品的功能，有經驗的 PM 一定會透過 User Story 來描繪具體的情境，進而把需求、產品互動流程、使用者給串再一起。

​

－產品測試及上線

軟體產品在上線前我們一定會透過 CI/CD 做自動化流程：

• Build code
• Unit Test
• 從 UIT, SAT, 更新到 PROD 環境

而在功能完整開發出來之前，一定會經過上述一系列的流程，至於什麼時候產品可以上線？取決於以下幾點：

• Functionality（功能）：Prod(正式版) 產品需要包含哪些東西？基本的功能有哪些？
• Usability（可用性）：核心重點功能它應該要夠簡單、不煩瑣，快速解決使用者的需求及問題，也就是講求高水準的可用性
• Reliability（可靠性）：有沒有經過壓力測試？UI 有沒有一致且是否遵照 DS(Design System)？哪些 Bug 是真的可以勉強接受使用者也不會抱怨的？
• Performance（效能）：產品每個獨立功能所運作的時間是多久？例如忘記密碼填寫 Email 後多久會收到信？
• Supportability（可支持性）：團隊有沒有足夠人力來因應產品上線的功能優化？團隊 AM(Account Managr) 是否會取得用戶得回饋並反映給團隊？

​

－總體資源（時間、預算、人力）

在總體資源當中的時間是最讓人容易混淆的部分？這個時間是 Scrum Sprint 的時間還是產品上市的時間？

我自己的經驗是，團隊就算最後把產品做完，但有可能 AM、老闆或是客戶一句話就讓這產品遲遲不上線， 所以只要大概知道使用者及公司所期望的產品上線時間是什麼時候，而 PM 應帶領團隊回頭來看 PRD，完成所有的功能需要多少時間？可能是幾個 Cycle 的 Sprint 等等。

預算及人力的部分，為了打造這個產品，PM 手上的預算有多少？我必須動用多少人、天及資金才能完成產品如期上線？而就目前來說團隊還缺少哪些資源？

​

認清團隊及公司的方向

我曾經任職一間公司是完全沒有 PRD、Spec 這東西的， 公司也沒有做好交接事項，很多問題都還要公司同仁去私訊離職的員工。 但今天如果有 PRD 以及相關的 Spec，就能避免這些無謂的舉動，更不會有上述沒有PRD會有哪些問題？提到的這幾個問題。

而如果一位新進的 PM 遇到的這樣的狀況，一定要立即讓主管甚至是老闆知道， 因為接下來做的產品絕對會有很多問題，你以為只是在既有產品上疊加功能，但你不知道這些功能可能會影響到現有平台的用戶。

如果是待在這樣的團隊必須要有心理準備，或許這就是長年以來的文化， 先不要把它視為一種不好的習慣，反而要去思考、挖掘最根本的原因是什麼。

有可能公司高層根本不懂技術、不懂產品開發的細節，只專注在是否獲利如何切入產品的市場。 而歷年的 PM 可能偷懶、RD 覺得有沒有都沒差，經年累月下來就變成了公司的一個習慣，剛加入一個團隊一定要知道這些細節。