關於寫 PRD 的小小心得
文／YH Chen
工作這些年來漸漸發現，其實很多問題都是溝通與流程上的問題。本篇標題雖然是講關於 PRD 的心得，但在進入正題之前，我想先來聊聊這些年來曾經讓我最苦惱的問題：
問題一：RD在開發時來問我詳細的規則，可是我也很菜啊！
如果是在經營自己產品的開發團隊，雖然也會新增產品功能或是開發新的產品，但還是會有大部分的需求會落在優化既有的功能，在這個情況下，原始功能的邏輯和規則是什麼就會是進行設計和 RD 在開發時很重要的資訊。
而在才剛接手負責某一產品的情況下，一定會有相當多的功能與架構都不是自己親手設計的，甚至交接拿到的文件如果是以 Wireframe Flow 或 Mockup之類的圖檔為主的話，要找特定細節的邏輯除了重新操作或測試可能也沒有其他方法了…
如果每次優化都是重新操作重新測試，嗯，你們知道的…
問題二：架上版本的功能和我拿到的文件對不起來啊！
這個問題跟上一題也有點關聯，除了文件上找不到相關的細節邏輯以外，我也有接手過年久失修的文件，架上版本的產品已經在不知道什麼時候改版過多次了，但這些文件其實並沒有跟著改版所以造成版本對不起來，而且也不知道所有差異的地方到底在哪裡…
在前期的工作中，通常這兩種都會是需要額外花大量時間重新整理、溝通的狀況，增加不少負擔，心真的會很累…
接下來進入正題吧！
PRD ( Product Requirement Document )，中文可以叫做產品需求規格書，是在產品開發流程中相當常見的用於紀錄、團隊內跨職能溝通的工具。
我加入點點簽 DottedSign 團隊之後才開始學習寫 PRD ，在此之前我一直以為 PRD 應該是大型專案團隊中 PM 角色負責的範疇，點點簽團隊開發節奏比較快，寫 PRD ？很難吧？很耗時吧？
後來在累積越來越多的經驗之後，我才知道 PRD 只是協助團隊溝通的工具，目的是「具體的」將開發需求、細節描述清楚，並且有一份「集中管理」的文件，將團隊溝通的內容統一記錄在一個地方，並且隨時更新，不會四散或隨著版本變更而遺失。
在我的認知中， PRD 是一種工具，而這個工具也確實讓我逐步解決了我在前面所提到的，那些年曾經遇過的問題。
關於 PRD 的基本架構、如何撰寫等相關教學文章已經有相當多大神分享了（首推最好懂最完整的一篇是Tom Liu 的【SOP不藏私】系列＃EP1「連猴子也會的PRD指南」），所以今天這篇我不會花太多篇幅介紹如何寫一份標準又完整的 PRD（自知之明 XD），而是改成分享一些我累積下來的想法。
在這邊我會分成開始撰寫之前的思考和開始撰寫的時候的一些方法。
1. 在開始撰寫之前
1–1. 先定義好這份 PRD 的規模
一份 PRD 並不一定等於一個產品，有時候會是一個專案，有時候會是一支功能，而這跟開發的形式甚至節奏都有關連。
以我限有的經驗來說，我負責的是點點簽的 SaaS 主產品，而 PD（Product Designer）在點點簽裡面擔任的是 Feature Owner 的角色，所以通常我們的 PRD 會是以功能作為顆粒來撰寫。
但有時候一支功能的複雜度比較高，這時候我定義規模時的思考方式會跟我在B2B產品設計心得之二：莫忘初衷中提到的「堆積木」相同，最完整的功能會是由多個小積木組成的，而這些小積木又分別可以拆開到其他地方組合，一塊小積木通常就會是我一份 PRD 的範圍。
舉個實際範例來說，我最初從前線 BD 接受到的情境需求可能會是：「客戶想要可以自動封存已經完成的文件的功能，讓他們組織內簽署完成的文件可以歸檔」。
在上面這個情境中，「封存」會是主要需求，但是客戶又想要「自動」的封存，所以我的切分方式會是：一塊「手動封存」的積木，加上一塊「自動化管理」的積木來由系統代替使用者進行動作。
未來如果還有其他功能也需要自動化，那自動化的小積木就可以再裝到其他地方去，例如自動刪除、自動建立文件、自動中止等等。
相較於上面切成兩塊小積木的方式，如果我直接切成一大塊包含手動和自動封存的積木，未來的彈性擴充相對就會比較小了。
當然定義規模沒有一定的規則，也沒有好壞評估的標準。但通常我在最初定義規模時就會找產品經理（PM）討論，確認好這次開發的範圍以外，也可以得到不同視角的建議（例如 PM 最在意的：風險和時程）。
1–2. 這份 PRD 的觀眾是誰
通常在產品團隊中，設計師不會只跟 PM 和 RD 溝通，前線的 BD 和 MKT 也會是我們一直對話的對象。
在我們目前的團隊，設計師透過前線（包含 BD、MKT）們了解客戶的需求，來把需求轉換成功能，再由設計師將功能的價值、使用情境帶回給前線作為與客戶對話和行銷的子彈。
在這些對話中所需的資訊就是必須被記錄的東西，所以我們就不再滿足只把 PRD 用來作為設計交付給 RD 開發的文件，而是讓整個團隊中的不同角色都可以在PRD中得到自己所需要的資訊。
RD 可以透過文件瞭解：功能的使用情境、開發範圍、開發細節等。
MKT 和 BD 可以透過文件了解：功能的使用情境、功能價值、用來對外溝通的特定專有名詞等。
那當然團隊內的其他角色也會有各自需要的資訊：Data Analyst 可能會需要確認追蹤的指標、客服團隊可能需要了解功能和限制來擬定當客戶詢問時的應對方式等。
所以在撰寫之前，我會先根據這次的範圍會影響到團隊內的哪些角色，確認或詢問他們的需求，並且確保這些資訊他們可以在文件中得到。
2. 開始撰寫文件
就像前面所述，我個人的經驗在切分文件的範圍大多是以「功能」為主，而主要的觀眾有：RD、PM、BD 和 MKT。
所以下面分享的內容其實放到不同產品或團隊一定會有很大的不同，但是大家還是可以先以上述的情況作為主要視角。
2–1. 個人常用的架構
我自己常用的架構其實很簡單，主要是三大部分：版本紀錄、功能價值與使用情境 和 功能開發細節。
2–1–1. 版本紀錄顧名思義就是紀錄版本
PRD 的目的是「集中管理」，因此不會因功能交付或是上線後就冰存不再變更，而是功能的每一次的版本迭代都要回過頭來記錄在文件上。
還記得前面我遇過的困擾「架上版本和文件對不起來」嗎？版本紀錄的部分就是希望盡可能減少這樣的情況發生。
2–1–2. 功能價值與使用情境的觀眾是整個團隊
通常我會把這支功能的價值和主要的使用情境寫在文件的第一章節，這個章節是整個團隊不分部門都需要閱讀的部分。
再更細分一點的話，第一章節我會至少記錄以下的內容：
功能價值：這支功能主要的價值是什麼？哪些人使用？
影響範圍：如果是付費功能，那是哪個版本以上才有？如果是跨平台功能，那哪些平台會有？
相關功能：有時候一支新功能會與過去的功能相關，那我會用連結的方式放上來。
使用情境：條列式的列上 Happy Case，詳述「誰」「在哪裡」「做什麼」還有「做了以後獲得什麼」。使用情境通常是整份文件最需要被不同角色了解的部分，RD 從這裡了解實際的開發範圍、BD 和 MKT 從這裡獲得推廣的子彈、QA 從這裡延伸測試腳本。
2–1–3. 功能開發細節的內容回歸設計師的專業
第二章節開始就是設計師可以發揮的部分了。舉凡功能心智圖 ( Function Map )、資訊架構 ( IA )、Flow Chart、Wireframe & Flow、Prototype、產品指標、UI 切圖等，都是第二章節以後可以寫的東西。
我也有看過其他的人會放上產品指標（Metrics）、字串表（Strings Table）、會議記錄、工作時間表等，基本上沒有什麼制式的規則，目的就是盡可能地詳述所有開發時需要的細節和資訊。
2–2. 建立一些規則，和觀眾培養閱讀時的小默契
我曾經在歐萊禮出版的「軟體架構原理-工程方法」一書的序章中看到作者整理了全書使用慣例，介紹書中不同的排版代表的涵意（例：斜體字代表新術語、URLs、電子郵件、檔名、延伸檔名）來與讀者建立閱讀時的默契。
PRD 也是一樣，為了讓溝通更順暢，我通常會建立一套自己在寫 PRD 時的小規則，並且也把這套規則同步給負責撰寫的其他團隊夥伴。
以下舉幾個範例：
我內文中的按鈕會用上下單引號表達，引號內則是按鈕的文案：「按鈕（Button）」。
如果是本次開發範圍內需要 MKT 成員協助確認的文案則會加上灰色底色來表達。
以上都不是既定的格式，也不是公開的規範，只是我們團隊內溝通的小默契，這些小默契培養起來後，在撰寫或是閱讀文件的速度都會更順暢。
2–3. 如果文件是四散的，那就善用偉大的超連結
開發的過程中，我會盡量確保 PRD 是整個團隊都可以獲得最詳盡資訊的地方，但是因為不同職能的成員各自運作，難免會有四散的文件，不太可能強制大家都要把內容塞到 PRD 裡面。
例如工程可能會有自己的技術文件、行銷也會有管理自己多語文案的表單，而這些我會擷取與本次開發範圍相關的部分，用連結的方式收納到 PRD 中，也就是讓 PRD 成為獲取所有資訊的入口。
3. 總結一下
最後，我想偷懶一下直接用 Marty Cagan 大神的「How to write a good PRD」內提及的撰寫步驟來做總結：
步驟一：做足功課
如果你是撰寫者，確保你提出的內容能夠說服你的團隊；如果你是閱讀者則可以思考一下，這份文件的內容有說服你嗎？如果沒有就一起討論一下吧。
步驟二：定義好產品目標
你必須有一個明確、可被了解的需求，並且詳細的寫下你的產品如何滿足這種需求。
步驟三：定義你的用戶
確定好你的用戶需求、背景、目的是什麼？
步驟四：定義好你的產品原則
你需要一些標準來作為體驗決策時的準則，這可能會跟產品的核心價值有關。
步驟五：測試你的產品
如果在開發前有進行可行性測試、可用性測試、產品概念測試等（當然文中是說要做），可以將測試的過程與結果放進文件中。
步驟六：定義與質疑你的假設
定義一些問題來質疑最初提出的需求與解決方案。
步驟七：寫下來
PRD 要讓整個團隊都知道放在哪裡、怎麼閱讀，並且 PRD 需要採用可以隨時更新的形式。
步驟八：確定優先級
如同前面提到的堆積木概念，每一顆小積木都會有優先排序，無論是不同支功能或是同一支功能內的細節項目。
步驟九：測試完整性
RD有足夠的資訊來開發嗎？ QA 有足夠的資訊來寫 Test Case 嗎？設計師有足夠的資訊來進行流程圖嗎？不同平台如果有功能上的落差，暫代的體驗規則是什麼？
步驟十：管理你的產品
PRD 是動態的，負責人應該追蹤並且更新所有的功能。
以上是這段時間寫了一些 PRD 後的小小心得，雖然我還是很害怕 RD 來問我規則啦 QAQ！
瀏覽 2,803 次
