產品經理工作術：我如何搞定「文件」這件事？

上一篇文章，我們探討了寫文件對產品經理的重要性，並於文章末尾預告本篇文章：我將分享我自己的工作方法。

你將在本文收穫一套系統化的產品經理工作法，由我自己整理、實踐並迭代無數版本，希望對你有啟發。

讓我們開始吧！

定義文件、PRD與Spec

為了讓後面討論更順利，一開始我們有三個名詞需要定義，分別是

• 文件
• PRD：Product Requirement Document的縮寫，中文可翻為產品需求文件。以下內容以英文縮寫PRD稱呼
• Spec：Specification的縮寫，中文可翻為規格、規格書。以下內容以英文縮寫Spec稱呼

這三個名詞的定義分別是

• 文件：記載書面內容的溝通載體
• PRD：說明專案範圍的文件
• Spec：說明功能如何運作的文件

為了讓大家更好理解，以下用文氏圖表達這三者涵蓋的範圍。

• 文件：最廣泛，屬於最外層的集合，涵蓋範圍最大。
• PRD：涵蓋範圍次之，它說明了本次專案的範圍，不只是產品經理的規畫文件，也可能包含設計師的設計稿、後端工程師的API文件、公關的新聞稿等等……。
• Spec：為最小的集合，它說明了功能如何運作，以什麼邏輯計算，介面長什麼樣子。

給三個重要的名詞下定義之後，我們開始進入正題。

進行的順序是從抽象到具體，讓大家掌握大方向之後再走進細節。

怎麼做出好的文件？

首先是最廣義的文件。

對於文件來說，我整理出四點寫作原則，分別是

1. 把話寫清楚
2. 用語要肯定
3. 不干涉執行細節
4. 不做也要寫出來

每一項原則的背後，都是血淚教訓，以下說明細節。

首先是第一項「把話寫清楚」。

這項原則要求我們在寫文件時，若不能只用文字就說明清楚的，就換別的方式表達，比如說表格，表格通常是一個用於說明複雜邏輯的好工具（比如說用於埋點邏輯）。

接著是第二項「用語要肯定」，勿用「若出現未知情況，則可能要以A情況的邏輯處理」，出現可能、也許、應該要這類用語會讓工程師不知如何處理。

若遇上自己確實不清楚細節的情況，那恭喜你提前找到問題，是件好事！

因為比起進開發後經過一回又一回的返工，現在把它搞清楚是最有效率的，要做的事情是趕快釐清細節，再寫出用語肯定的文件。

第三項是「不干涉執行細節」，即在把話寫清楚的前提下，把意思表達給協作方（設計師、工程師）後，就不要去干涉別人的執行細節。

一來是把發揮空間留給別人，二來則是把自己的時間留在更重要的地方。

最後一項「不做也要寫出來」的意思是，如果文件上有寫等於要做，那沒寫呢？是產品經理沒想到，還是想到了決定不處理？

為了避免有這種「薛丁格的邏輯」，同時處於要做和不要做的疊加態，讓人摸不著頭續，不如就在自己明確想清楚不做後寫清楚：此處經過某考量，決定不予處理。

那你可能會說，沒想到怎麼辦？MECE法則「相互獨立，完全窮盡」可以幫你解決沒想到的情況。

總結起來，這四點文件寫作原則如下。

1. 把話寫清楚：文字寫不清楚，就用表格
2. 用語要肯定：肯定表達會發生什麼、長什麼樣子
3. 不干涉執行細節：把話寫清楚，然後管你好你自己的手
4. 不做也要寫出來：想過要做的要寫，想過不做也要寫

怎麼做出好的PRD？

講完了最廣義的文件寫作原則，我們接著說要怎麼處理PRD。

PRD是為了「說明專案範圍」而生，這個定義就表示PRD的

• 對象：產品開發團隊的成員
• 目標：讓團隊成員理解專案範圍內的大小事

PRD是寫給產品開發團隊的成員看的，而產品經理通常是團隊內「對專案了解最廣」的那個人，因此產品經理在撰寫時應該要記得提醒自己：

自己認為理所當然的資訊，看的人是否也知道？不知道的話就需要加以說明。

寫PRD的目標是讓團隊成員理解專案範圍內的大小事，而不同公司的大小事也不盡相同，所以我在此只能提供一個通用版本，應該可以涵蓋八成的情況，剩下兩成情況還需要你自行調整。

怎麼做出好的Spec？

接下來是產品經理工作的重頭戲：寫Spec。

Spec就像是產品的說明書，將我們的想法化為圖紙，任何人一看就知到這個功能怎麼運作。

就像說明書不會預設用戶有哪些背景知識，Spec也是，Spec是寫給不特定人看的，因此如非必要，不要使用專有名詞。

一份稱職的Spec需要做到「兩個可視化」，分別是

• 邏輯可視化：使用文書軟體（Google Docs、Word），目的是描述運作邏輯
• 介面可視化：使用原型工具（Axure、Figma），目的是描述介面、介面與介面之間的關係

舉個例子會比較清楚，以售票平台KKTIX為例，當使用者從T1桃園雲豹的球賽活動頁面要點擊「下一步」進入購票頁面時，此時會有兩種狀態：

• 所有票種剩餘數量總和 > 0，正常顯示購票頁面
• 所有票種剩餘數量總和 = 0，顯示空值畫面「目前沒有任何可以購買的票券」

邏輯可視化就是要用文字將上述邏輯寫出來，介面可視化就是要把上述介面、介面與介面之間畫出來。

知而後行，實踐出真知

看到這裡，相信你對產品經理如何處理文件應該有更深的認識。

然而，「知」不應該是終點，「行」才是。

要把這套方法變成你自己的，我建議把這套工作法多練習實作，練習的對象你從App商店中可以找到成千上萬，選一個你喜歡的開始反向拆解練習，相信你在短時間之內就會看到自己明顯的進步。

祝實踐愉快。