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

剛踏入的職業工作者、或是已經身經百戰的職業工作者，常常遇到萬年的問題「到底文件要寫得多細才算好」、「有什麼文件是身為『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，可能是一場會議記錄達到共識，立刻執行。同等，每間公司的模式不同，只是用不同形式或名詞展現。

這篇文章 軟體業 PM 日常會接觸的文件｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上個禮拜我們說到了《 你的公司有提供「對外」的產品文件給使用者參考嗎？ 》。這個禮拜我們來 …

上個禮拜我們說到了《 你的公司有提供「對外」的產品文件給使用者參考嗎？ 》。這個禮拜我們來談談：同樣是寫文件，由 Technical Writer 寫與 PM 寫有什麼不同 ?​

PM 的工作包山包海，要跟業務單位/客戶對需求、花時間整理規格、跟設計師/工程師/QA/營運團隊溝通。​

PM 職責範圍確實也包含寫產品的規格與規劃，例如：​

• 使用者故事(User Story)： 即 As a (使用者), I want (做什麼事情), so that (得到什麼成果)，讓產品團隊理解每個功能為誰而做、要做什麼、做完成果。
• User Story Acceptance Criteria Test Cases：寫完 User Story 後，必須要進一步描述這個功能的細節，透過「Given (在什麼情況下)，When(當使用者做了什麼)，Then(會發生什麼事情)」才能讓工程師與 QA (測試工程師) 執行。
• Product Roadmap：告訴 C 字輩的老闆接下來的產品發展，這一季要做什麼、為什麼要做、要打哪些用戶、如何衡量成效、成效好與不好的相對應措施是什麼。

可以看到，PM 的寫作文件通常是「對內」，告訴團隊接下來要做些什麼、不做些什麼；但 Technical Writer 通常是「對外 (外部使用者)」，告訴使用者產品從哪裡開始用、要完成對應的事情該怎麼做、技術細節要到哪裡去查…等。​

PM 和 Technical Writer 的技能樹不同，前者更多在溝通、後者更多在引導。​

這裡想問問大家：你目前有在公司內部有幫忙寫文件嗎？如果有的話，你寫作哪些呢 ; 如果沒有的話，你會想學習寫文件嗎？​

想聽聽大家的想法唷！

這篇文章 關於產品文件，PM 跟 Technical Writer 寫的有什麼差別 ? | 專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

Hi 大家好，我是朱騏​ ​ ▋簡單自我介紹​ 我過往的工作經驗都是在 SaaS 軟體產業，曾經擔任 PM 將 …

Hi 大家好，我是朱騏​

​

▋簡單自我介紹​

我過往的工作經驗都是在 SaaS 軟體產業，曾經擔任 PM 將近 6 年的時間、在新職位 — Technical Writer 工作也已經快 9 個月的時間，這篇文章想跟大家討論關於「寫產品文件」這件事情。​

歡迎來看看我的自我介紹更認識我​

https://www.technice.com.tw/profession/​

▋公司的「產品文件」很重要！​

公司的產品文件可以簡單分為「對外」以及「對內」，這篇文章先來講「對外」的文件。​

​

什麼是「對外」的產品文件呢？簡單說，就是替公司的產品寫一份「攻略本」。攻略本是電玩產業的詞，能幫助新手玩家快速學會操作方法、了解遊戲目標，接著就可以比較開心的在遊戲的世界中玩耍。​

​

在職位分工比較細的軟體公司中，會特別將「對外」的產品文件交給Technical Writer (技術寫手) 來做，他們寫作的內容就稱為「技術寫作( Technical Writing )」。這種文件有以下的功用 :​

• 能夠引導消費者更好地使用公司產品
• 可以視為公司品牌、產品使用體驗的一環
• 能影響消費者對於公司產品的整體觀感。(想想看，如果你今天使用一款複雜的電器產品，但沒有說明書應該會很崩潰吧！)​

​

這就像「攻略本」會先告訴新手玩家基本的操作方法，讓玩家在別在超大的遊戲世界中不知所措的亂跑、被怪打死而感到挫折（可能一開始連「基礎戰鬥知識」都沒有就跑出新手村）。好的技術文件，應該能夠把公司產品複雜的功能與規格，在適當的時間點、用適當的方式告訴使用者。​

​

想問問大家，你目前待的公司、或你知道哪些公司有提供「對外產品文件」給使用者參考呢？

這篇文章 你的公司有提供「對外」的產品文件給使用者參考嗎？ | 專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。