上一篇文章，我們探討了寫文件對產品經理的重要性，並於文章末尾預告本篇文章：我將分享我自己的工作方法。
你將在本文收穫一套系統化的產品經理工作法，由我自己整理、實踐並迭代無數版本，希望對你有啟發。
定義文件、PRD與Spec
為了讓後面討論更順利，一開始我們有三個名詞需要定義，分別是
- 文件
- PRD：Product Requirement Document的縮寫，中文可翻為產品需求文件。以下內容以英文縮寫PRD稱呼
- Spec：Specification的縮寫，中文可翻為規格、規格書。以下內容以英文縮寫Spec稱呼
這三個名詞的定義分別是
- 文件：記載書面內容的溝通載體
- PRD：說明專案範圍的文件
- Spec：說明功能如何運作的文件
為了讓大家更好理解，以下用文氏圖表達這三者涵蓋的範圍。
- 文件：最廣泛，屬於最外層的集合，涵蓋範圍最大。
- PRD：涵蓋範圍次之，它說明了本次專案的範圍，不只是產品經理的規畫文件，也可能包含設計師的設計稿、後端工程師的API文件、公關的新聞稿等等……。
- Spec：為最小的集合，它說明了功能如何運作，以什麼邏輯計算，介面長什麼樣子。
給三個重要的名詞下定義之後，我們開始進入正題。
進行的順序是從抽象到具體，讓大家掌握大方向之後再走進細節。
怎麼做出好的文件？
首先是最廣義的文件。
對於文件來說，我整理出四點寫作原則，分別是
- 把話寫清楚
- 用語要肯定
- 不干涉執行細節
- 不做也要寫出來
每一項原則的背後，都是血淚教訓，以下說明細節。
首先是第一項「把話寫清楚」。
這項原則要求我們在寫文件時，若不能只用文字就說明清楚的，就換別的方式表達，比如說表格，表格通常是一個用於說明複雜邏輯的好工具（比如說用於埋點邏輯）。
接著是第二項「用語要肯定」，勿用「若出現未知情況，則可能要以A情況的邏輯處理」，出現可能、也許、應該要這類用語會讓工程師不知如何處理。
若遇上自己確實不清楚細節的情況，那恭喜你提前找到問題，是件好事！
因為比起進開發後經過一回又一回的返工，現在把它搞清楚是最有效率的，要做的事情是趕快釐清細節，再寫出用語肯定的文件。
第三項是「不干涉執行細節」，即在把話寫清楚的前提下，把意思表達給協作方（設計師、工程師）後，就不要去干涉別人的執行細節。
一來是把發揮空間留給別人，二來則是把自己的時間留在更重要的地方。
最後一項「不做也要寫出來」的意思是，如果文件上有寫等於要做，那沒寫呢？是產品經理沒想到，還是想到了決定不處理？
為了避免有這種「薛丁格的邏輯」，同時處於要做和不要做的疊加態，讓人摸不著頭續，不如就在自己明確想清楚不做後寫清楚：此處經過某考量，決定不予處理。
那你可能會說，沒想到怎麼辦？MECE法則「相互獨立，完全窮盡」可以幫你解決沒想到的情況。
總結起來，這四點文件寫作原則如下。
- 把話寫清楚：文字寫不清楚，就用表格
- 用語要肯定：肯定表達會發生什麼、長什麼樣子
- 不干涉執行細節：把話寫清楚，然後管你好你自己的手
- 不做也要寫出來：想過要做的要寫，想過不做也要寫
怎麼做出好的PRD？
講完了最廣義的文件寫作原則，我們接著說要怎麼處理PRD。
PRD是為了「說明專案範圍」而生，這個定義就表示PRD的
- 對象：產品開發團隊的成員
- 目標：讓團隊成員理解專案範圍內的大小事
PRD是寫給產品開發團隊的成員看的，而產品經理通常是團隊內「對專案了解最廣」的那個人，因此產品經理在撰寫時應該要記得提醒自己：
自己認為理所當然的資訊，看的人是否也知道？不知道的話就需要加以說明。
寫PRD的目標是讓團隊成員理解專案範圍內的大小事，而不同公司的大小事也不盡相同，所以我在此只能提供一個通用版本，應該可以涵蓋八成的情況，剩下兩成情況還需要你自行調整。
怎麼做出好的Spec？
接下來是產品經理工作的重頭戲：寫Spec。
Spec就像是產品的說明書，將我們的想法化為圖紙，任何人一看就知到這個功能怎麼運作。
就像說明書不會預設用戶有哪些背景知識，Spec也是，Spec是寫給不特定人看的，因此如非必要，不要使用專有名詞。
一份稱職的Spec需要做到「兩個可視化」，分別是
- 邏輯可視化：使用文書軟體（Google Docs、Word），目的是描述運作邏輯
- 介面可視化：使用原型工具（Axure、Figma），目的是描述介面、介面與介面之間的關係
舉個例子會比較清楚，以售票平台KKTIX為例，當使用者從T1桃園雲豹的球賽活動頁面要點擊「下一步」進入購票頁面時，此時會有兩種狀態：
- 所有票種剩餘數量總和 > 0，正常顯示購票頁面
- 所有票種剩餘數量總和 = 0，顯示空值畫面「目前沒有任何可以購買的票券」
邏輯可視化就是要用文字將上述邏輯寫出來，介面可視化就是要把上述介面、介面與介面之間畫出來。
知而後行，實踐出真知
看到這裡，相信你對產品經理如何處理文件應該有更深的認識。
然而，「知」不應該是終點，「行」才是。
要把這套方法變成你自己的，我建議把這套工作法多練習實作，練習的對象你從App商店中可以找到成千上萬，選一個你喜歡的開始反向拆解練習，相信你在短時間之內就會看到自己明顯的進步。
祝實踐愉快。
