軟體業 PM 日常會接觸的文件｜專家論點【Mr.T】

剛踏入的職業工作者、或是已經身經百戰的職業工作者，常常遇到萬年的問題「到底文件要寫得多細才算好」、「有什麼文件是身為『PM』才該寫的」，每每聽到這問題，通常只有一個答案「沒有標準答案」，看似不負責任，卻也是真實世界遇到的問題，讓我們來拆解一番。

常見的文件類型

當然有更多更多的內容，不一網打盡全部寫完也不科普裡面包含哪些細節，當我們知道以下常見的文件，作為專業工作者，江湖在走，Google 搜尋技能要有。作為專案經理、產品經理的日常經常性會接觸到的文件。包含以下幾種：

1. User Story 使用者故事

嚴格來說這不算是文件，算是文件組成的一小部分。大概是最具爭議性，有些公司期望寫的跟 Spec 一樣細節，包含邏輯流程圖、頁面轉換流程、資料庫欄位，又有些公司只要定義簡單的一句話包含明確的 AC 驗收規範 (Acceptance Criteria)。
如果我們用通用術語在敏捷的定義來看，就是你寫到什麼範圍能達標達成開發團隊的共識即可，而這個達標往往存在於主管、用戶、PM 的心中。這邊筆者建議有幾件事情不能少，就是這「功能的目的是什麼」、「使用者可以達成什麼任務」、「必要的驗收條件（Accetance Criteria）是什麼」，至於其他就是隨著團隊的共識有細微的不同。

2. Flowchart & UI Flow 使用者體驗流程圖

現實生活極巨爭議性之二，來自於與設計師的職責難以居分，就是按下特定的按鈕之一步步畫面，怎麼操作才是對使用者好，誰是負責訪談與探索、誰是負責分析用戶體驗，雖然 PM 非常需要介入了解，實際上要有專業的設計師共同協作，並指派主要負責人才是關鍵。
第二個爭議每個人對於「UI」定義不同，是高擬真度的 Prototype UI Flow 還是要擬真度的 Mockup UI Flow，要看團隊中協作對於現有開發階段的認知，以及合作共識的默契場握度。

此文件的目的通常為了達到兩個目的，工程師可以知道頁面之間的流程是什麼、設計師可以知道用戶是透過什麼方式完成個別任務。而這邊有可小陷阱，可不是要寫的「使用者說明書」般的細節，重點依然要擺在「大家如何看得懂好開發」。

3. Technical Spec 技術規格文件

通常是工程師不想寫或是企業對於職責分配不清楚、沒有足夠的人力，就會要求 PM 來寫，包含 Database 資料庫欄位、後端 API 介面對應於使用者畫面、與相關邏輯對應。正常做法是由非 PM 工作者，例如前後端工程師、或是架構師描述清楚。有些時候 PM 的介入在於職掌定義為「Technical Project Manager」，這類職務要寫如同「API Spec」，這類的職務通常是有深度技術背景的人來撰寫。即使非技術類的 PM，通常藉由看懂文件，可以加強跟第三方合作廠商合作的準確度。

沒有技術背景的朋友不用擔心，只要不是寫程式，如果是看得懂、能溝通，可以透過基本的本職學能的學習，在 Coursera、工程師間溝通的邊做邊學，都是可以漸漸掌握。

4. PRD 產品規格文件

白話就是產品為何而做、是什麼，至於產品怎麼做就是工程師要協助定義，通常為何資訊溝通方便，有時會被補充進入 PRD，因此文件通常會由 PM、設計師、工程師共同協作。文件包含的內容更是形形色色，不僅僅是包含我們上述講的 1-3 點，更有包含產品支援平台、驗收文件、使用情境相關說明。

5. MRD 行銷規格文件

產品行銷可理解為市面上用戶或客戶如何在第一時間點了解你的產品，因此絕對不是規格的細節，而是描述你想要服務的客戶類型，學術點就是 Go-to-market 策略、STP 策略，通常是行銷人員撰寫，而 PM 撰寫有個好處，就是你越了解市場，越是知道「產品為何而做」。

6. BRD 事業規格文件

有別於 PRD 是製作產品、MRD 是行銷產品、BRD 就是如何賣產品，包含產品組合的如何定價，產品路線圖的未來幾年產品消長計畫、產品的盈利虧損哪裡來的預測等等，通常是業務人員撰寫。

小結

筆者有個非常深度的領悟，理想中有這些文件很美好，而現實因為時程因素不允許我們如此即時產出完美無缺的文件，重點不是為了要等規格全部寫完才進行開發，光是爭議文件內容的筆戰就無法完成，重點應該擺在如何在彼此擁有的共識下推出產品，得到「市場回饋」後再修正，時間就是金錢。

其次是看起來要有「形式上」的文件，很多時候組織會被束縛必須要有遵循網路上的範本再度執行，而隨著組織的共識，可能是簡單的一頁 A4，可能是一場會議記錄達到共識，立刻執行。同等，每間公司的模式不同，只是用不同形式或名詞展現。

瀏覽 5,827 次