如何撰寫產品需求與規格文件？給產品經理的問題、心法與實作小撇步！
在開始分享 PM 相關的心得文章之後，常常會被問到這些問題：
- 如何撰寫產品文件？有沒有格式可以參考？
- 如何寫 User Story？要寫多細？誰寫？（參考文章）
- 如何畫流程圖、Journey Map、Wireframe？什麼時候畫？
還有一些延伸的團隊合作問題：
- 工程師不看文件，東西不按照規格做，怎麼辦？
- 文件發出去都沒有回應或回饋，怎麼辦？
- 文件好像都只有我在看，好氣餒！
這些問題的答案其實就是 — — 「看情況」！雖然沒有一個完美的格式和流程可以解決所有問題，但我會試著在這篇文章整理我寫文件、溝通文件的心得與思考方式，以及反思為何有時文件會被視為無效、被人詬病的原因。
什麼是產品需求文件？
我在【PM夥伴攻略】如何跟工程師合作？中曾經寫到 PRD（Product Requirements Document 產品需求文件）這個文件類型，有時也叫做產品規格書（Product/Feature Spec），更小型的功能修改則可能只是一張票（Ticket）。PRD 內容通常包含：
【目標＆問題】
- 產品目標、預期產出
- 問題、指標、假設
- 使用者分群＆使用情境
【解決方案】
- 使用者故事（User Story — As a … user, I want to …, so that …）
- 使用流程與設計（User Flow / Wireframe / Mockup，PM、設計師負責）
- 產品規格細節、系統邏輯、極端使用情境（PM、工程師、QA 負責）
【其他注意事項】
- 功能範疇（Phase 1, Phase 2 …）、功能相依性（Dependencies）
- 功能上線策略規劃、市場溝通策略
- 未來擴充可能、後續規劃（上線後的下一步是什麼？）
- 其他參考資料：使用者研究、競品研究、會議記錄
每天寫這些文件都快堆得比人還高，為何 PM 苦口婆心用心良苦歸心似箭地產出詳細而精美的文件，有時卻會被詬病，甚至最讓人困擾的，工程師不看文件、不照著規格開發？
在觀賞以下部分之前，歡迎簡單瀏覽【PM夥伴攻略】番外篇：工程師雷區幹話大全 了解我與工程師們的愛恨情仇。
問題：為什麼！為什麼工程師就是不能好好用心仔細地看看產品需求文件？
因為從他的角度，這份產品需求文件無法達成有效的溝通。
讓我試著從工程師的角度來思考一下他們遇到的問題：
- 文件太長，根本不知道重點在哪裡。 這一段是寫給我看的嗎？怎麼感覺是寫給老闆或 PM 主管看的？雜七雜八到底要我看哪部分？
- 文件內的需求、規格細節寫的不清楚。 這文件真的寫完了嗎？還是又要我通靈？發文不附圖，此風不可長。
- 文件總是都一直改、或沒更新。 實在無法信任我看到的任何一個版本。敏捷起來，連我自己都會怕。
結論就是：「PM 大大，你可不可以當面跟我解釋、幫我畫個重點，讓我現場問問題、討論一下，不要叫我寒窗苦讀萬言書！」
這些問題導致工程師覺得看了文件也沒用、懶得看，不如直接抓 PM 本人講個清楚，或是先照自己的想法做，等到測試時看 QA 或需求單位最後提什麼問題再來修。這之中的來來回回不但造成時間與精神成本的浪費，也顯示出文件本身並沒有有效達成他的目標。
其實不只是在與工程師用文件溝通時會遇到這些問題，產品規劃涉及很多不同的單位，例如商業端（客服、業務、老闆）、設計師、工程師、QA、其他 PM 以及主管，我也遇過丟出文件後卻沒人回應、沒人提意見、沒人看的狀況，可能的原因就是我寫的內容沒有正中要點，或是我根本選錯溝通方法。與其用文件，很多時候當面溝通完再用文字記錄下來會是更有效率的做法。（只用口頭開需求也是會被電爆的，請自重！）
解法：先確認目的與對象，再來有目的的撰寫
寫產品文件就跟做產品一樣（跟這世上的萬事萬物都一樣），要先確認使用的對象是誰、我想要達成的目的是什麼，瞭解他們到底想要/需要看什麼後，再來設計這份文件的內容，有目的的寫文件以確保觀看者可以得到他想要的資訊，來達到實際而有效的溝通。
【目的】 ・我為什麼要寫這份文件？ ・我希望它達成的目標與結果是什麼？ ・這是一份主要文件、還是參考文件？ ・若是主要文件，哪些參考可以直接附上，避免重工？
【對象】 ・誰會看這份文件？ ・他將如何使用這份文件？ ・他預期在這份文件得到哪些資訊？ ・他習慣的文件格式是什麼樣子？
回到上面那份落落長的 PRD 來看，對於工程師來說，瞭解目標、使用者研究、使用情境也許重要，但這些都是次要資訊，僅需要在專案一開始時確認沒有問題就行；而最重要的其實是產品要如何修改、功能細節的規劃，這些跟工程直接相關的實作細節。
舉一個各司其職、效率極大化的例子，在產品需求文件中 PM（你、團隊、主管）想了解價值（outcome）、QA 想直接看到產出（output）長怎樣、工程師則需要知道實際要做哪些改動（changes），一份文件的確可以滿足所有人「想看到相對應資訊」的需求，但單單一份統一的文件可能無法達成「有效率的傳遞資訊」的目標。
流程：在對的時間，用對的方式溝通對的內容
而儘管是跟同一個對象，可能會因為不同目的在不同的時間點溝通，這時溝通方式、文件的內容也會不太一樣。以這個流程舉例：
- 確認產品目標、商業問題 / PM 主管、商業端團隊
- 討論目標、問題、指標、假設 / PM 團隊、設計師、資料團隊、工程團隊
- 討論使用情境、發想不同解法、確認解法 / PM 團隊、設計師
- 設計使用流程、功能介面、研究與測試 / PM、設計師
- 確認使用流程、功能介面、規格細節 / PM、設計師、工程師
- 回去修改，再來確認修改過後的 PRD / PM、設計師、工程師、QA
- 討論開發實作（切 Phase、切 Story、資源時程） / PM、工程師
- 與商業端確認改動與上線規劃 / PM 主管、商業端團隊
- 將以上所有討論內容的最終結論寫下，PRD 最終版本定案！
口頭溝通還是很重要
以上每個階段，主要都還是仰賴口頭溝通（當面、視訊），再以不同階段、不同完整度的 PRD 作為輔助文件。產品開發是團隊合作，同一份 PRD 會隨著團隊的討論而慢慢變完整，就算 PRD 最終版本已經定案（希望是真的 final 版本），在正式開發前、中、後，還是需要大量的口頭溝通！
PRD 作為最完整的文件之一，最主要還是 PM 自己要看的，當要 brief 給工程師或其他成員時、當忘記某個討論過的細節時、當要分享給其他團隊作為參考時，它就會是個很棒的資料來源。
階段性溝通完成後，持續調整文件類型與內容
當要開始實作時，在一開始用完整的 PRD 跟團隊成員 brief 完產品需求與確認規格後，可以直接將拆分的 Stories 開到專案管理工具裡面，每張 Ticket 只寫上那個任務需要完成的工程實作細節、產品畫面，並將 PRD 反作為參考資料，讓工程師在開發的時候可以專心在實作上。
原先的 PRD 可能隨著你們釋出一些 Stories 、得到一些回饋後需要修改、變換方向，或甚至是建立一份新的 PRD 開新的需求，那也代表又進入一個新的階段，文件類型和內容又需要重新調整了。
實作小撇步
1. 溝通前先說明目的並畫重點
傳遞文件與溝通時，明確告訴對方目的、預期結果，並幫對方擷取出重點。不要期待他會把整篇 PRD 完整看完，很多人看到落落長的文件會想說晚點再看，然後就沒有然後了。因地制宜、設身處地為對方著想，主動讓他知道哪邊是最重要的部分，其他則是次要的參考資料。
更清楚一點，文件中待確認的部分也可以用紅色標記大大的 TBD（To Be Discussed）讓對方一眼看出要討論的部分！
2. 視覺化、圖像化
圖像永遠比文字表達得更清楚，討論時可以溝通細節，實作時確保所有人認知一致，附上流程圖、Wireframe、Mockup 是基礎中的基礎，就算只是手畫的都好！
3. 條列目錄
最核心的問題是「我如何寫一份架構邏輯完整的文件？」但是這部分會因人而異，PM 與工程師思考的順序、邏輯、對每個段落的重要性看法不同，因此為了讓事情更明朗，至少在比較大篇幅的文件中放個簡單的目錄吧！也別忘了用錨點超連結，讓使用者可以一鍵到達他想看的部分。
大部分線上協作文件的軟體都內建有這個功能（Google Doc, Confluence, Dropbox Paper），只要確保自己有設定對、使用者也會使用就行了！
4. 從看文件的使用者身上蒐集回饋
其實上述使用目錄的建議，就是我在跟工程師討論為何他覺得我寫的文件很難看懂後，我們想出的其中一個修正方法。
舉例來說，我寫 PRD 的邏輯是按照我的思考順序寫下來，並把所有參考資料放在文件開頭；但他在閱讀 PRD 時認為應該要把最重要的、他需要知道的資訊放在最開頭，隨著重要程度遞減，將參考資料放在文件最尾端。
修改寫 PRD 的順序對我來說並不理想，況且這份文件也會給其他人看，每個人肯定會有不同的看法，因此我們討論了一些在不需要修改文件順序與架構的情況下可以改善的解法：
- 條列目錄 + 錨點超連結
- 用不同顏色的標題來區分不同目的的區塊（例如：商業相關、使用者相關、工程實作）
- 傳遞文件給特定對象時，在文件中收合（隱藏）某些區塊，使用者想看再自己延展打開（以 Dropbox Paper 為例）
每個團隊、每個工程師喜歡的工作方法不同，這也是為何我會在文章一開始提到，文件怎麼寫、格式怎麼設定、要寫多細，這些都是「看情況」。有些公司就是一個步驟一個步驟嚴謹的走下來，不會有太密集的討論，有些公司則是隨時都在找不同的人開會討論、做新的決策，他們會需要的文件和溝通方式就絕對不同，因此從一起工作的夥伴身上得到回饋是最快的修正方式！
文件只是一個溝通的工具
說到底文件就只是一個溝通的工具——跟自己溝通、跟正在一起工作的團隊溝通、跟未來不認識的交接同事溝通。
文件能作為良好溝通工具的原因，在於它具有穩定性與可傳遞性，在穿越時間（歷經多個月的專案）與空間（跨國團隊）的情況下，能夠讓所有人得到一致的訊息，如同英文所說的 ”on the same page”。
放到近代的話，線上文件工具不但可以讓多人同時協作，也可以看到歷史變更紀錄，方便團隊回去考察在過去時間點做的決策與變更，讓整個溝通的過程能夠輕易的攤在觀看者面前，同時確保公司與團隊能夠有組織性的維護共同知識，持續做經驗的累積與傳承。
除此之外，我私心認為寫文件也是一個與自己溝通的工具，在下筆的過程中更透徹地思考整個專案，大至目標、小至細節，反覆雕琢進而讓問題的形狀更清晰。
所以說何時該寫產品文件？要寫多細？
既然是溝通的工具，就應該只在「使用文件溝通是最有效率」的情況下使用它。重點不在於文件，而在於它是否能讓溝通更順暢，別讓文件的產出與維護成本超出了它所能帶來的價值。
儘管這篇文章主要在分享 PRD 的實作，但廣義來說，我認為所有為了溝通「產品」相關資訊而存在的文件，都算是產品文件。包含了：
- 產品路線圖（Product Roadmap）
- 產品需求文件（PRD）、產品規格（Product/Feature Spec）
- GitHub / JIRA / Trello Ticket
- 產品使用說明
- 產品會議記錄
在修修改改了好多不同版本的 PRD 格式後，我發現其實也不用拘泥於格式（網路上可以查到的格式真是千奇百樣），不用每次都像填表單般把每個欄位空隙填滿，只要能夠達成有效溝通的，都會是一份好文件！
畢竟如果一張 JIRA Ticket 就可以講完的事情，就用不著在 Confluence 寫一篇落落長的需求文件。
PRD 是你的產出，但不是你的產品，產品上線後產生的影響力才是 PM 真正重要的工作，因此善用產品文件來說服利害關係者、跟實作者溝通細節，進而推動產品影響力才是真正重要的事！
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多團隊合作的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～