國外的產品經理是如何寫需求文檔的？

12-17

在國外產品的開發過程跟國內一樣么？國外的產品經理是如何寫產品需求文檔的呢？

Gaurav Oberoi 是 SurveyMonkey 的（前）聯合創始人，曾於 Amazon、Xmarks 先後從事工程師、產品經理等職位，在西雅圖和矽谷有十餘年的工作經驗。

翻譯了這一篇他對於產品文檔的看法，以及他撰寫產品文檔的常用流程，希望可以回答題主的疑問。

如何寫產品文檔

很多人聽到「產品文檔」這四個字就像吞了蒼蠅一樣，人們通常會認為這意味著又要花幾周寫一個根本沒人看的文檔。如果一個團隊總被產品文檔這種事情拖累，怎麼可能「敏捷」得起來，怎麼可能高效地產出代碼？
我在過去十幾年創造了多個數百萬人使用的軟體產品之後，越發認為這種觀點是完全錯誤的。根據我的經驗：

高效的產品文檔是創造偉大產品的過程中所不可或缺的重要組成部分。撰寫產品文檔可以強制所有人從項目初始就理性思考，頻繁溝通，明確權責——所有的這些都會帶來更好的軟體質量，更低的進度風險，以及更少的時間浪費。

在這篇文章中，我會通過一個案例來分享一些普適的建議，這些建議會對大中型（超過二百人的）公司中的產品經理們非常有幫助。

首先，舉個例子。
假設你在這裡工作：

一家從事在線旅遊預訂服務 （就像 Hotels 或者 Airbnb 但是規模更小一些）的公司。目前這家公司的支付轉化率偏低，所以這個季度大家打算嘗試通過在支付環節加入在線客服的方案來提升轉化。

你的工單/用戶故事/路線圖是：

通過在支付環節增加在線客服來嘗試提高支付轉化率。
支付轉化率目前僅有 18％，而業內平均轉化率有 30％。我們打算測試下在支付時展示在線客服聊天窗口是否可以提高這個轉化率。用戶運營團隊已經同意了提供 1 人月的客服人力支持。

在你沒有產品文檔時，你會這樣做：

比方說，你覺得行動起來總是最重要的，因此直接開始動手：

在迭代計劃會上，你和團隊討論了這個需求。
然後你挑選了一個靠譜的第三方客服供應商（例如 SnapEngage ）。
提交一個工單來讓工程師添加一些 Javascript 代碼。
和支持團隊開個會，確定他們都準備好了

搞定了！這麼簡單的事情怎麼能要我們寫產品文檔呢？如果你是在一個小型創業團隊，你也確實並不需要——因為產品改動相對小，涉及到的人也相對更少。

但如果你是在一個更大的組織之中，或者產品更加成熟/複雜，就會陸續出現下列這些問題，並且相比寫文檔，這些問題會需要更多時間來處理。例如：

工程師把工單標記完成了，但是一驗收測試，就發現這個功能完全沒有考慮移動端的適配。
- 「唉呀！你忘了提醒大家手機端的使用才是核心場景。」
用戶運營經理打算開展一個漫長的評審流程，以確定最合適的聊天服務商。
- 「啊……需要定一個會議，向大家解釋下這次上線只是一個灰度測試。」
發布一小時後，客服報告說他們收到了西班牙語的在線聊天請求。
- 「啥？要追加一個緊急發布，把這個測試限定在英語用戶中。」
一個設計師花了幾天，為聊天窗口滑入屏幕的交互繪製了一個完美的動畫。
- 「用戶體驗過度優化，你是否對整個團隊統一了「這次只是一個測試」的預期？」
一周的測試完成之後，數據分析師發現無法產出你要的報告，因為相關的必要指標並沒有埋點。
- 「史詩級的失敗。從頭再來吧。」

如果這是一個相對簡單的項目，即使沒有產品文檔可能也不至於陷入這樣的災難之中。但是在簡單的項目中你仍然有可能會因為沒有文檔浪費許多時間和機會成本。

如果你寫了一篇文檔：

為了便於說明，我準備了兩個示例文檔：一篇思路筆記，和一篇完整的產品文檔示例——這樣可以完整介紹產品文檔的撰寫流程。

請在繼續閱讀文章之前，花幾分鐘讀一下這兩篇示例文檔吧。

閱讀示例思路筆記（閱讀時間 2 分鐘）
這是一個根據你已知的信息和想要解答的問題所梳理成的列表。
這會是你需要做的第一件事情，大約需要一個小時來完成這個文檔。這個文檔會成為你和團隊中其他人的一個溝通基礎。
閱讀示例產品文檔（閱讀時間 6 分鐘）
只有和團隊一起評審了你的假設和創意之後（無論是在專門召集的會議上，喝咖啡時，或者桌上足球的休息時間），你才應該真正開始寫產品文檔。
如果已經完成了溝通和評審，整個文檔應該花費你 1-3 個小時的時間。
啊哈！有了文檔之後是不是就感覺踏實多了？寫文檔看起來是額外的工作成本，但是其實並不是，高效的文檔可以幫助你和你的團隊節約時間投入，並且在交付上線時會更有信心。

等等！——你已經讀完示例文檔了么？請務必先讀完它再繼續閱讀下面的文章。

文檔撰寫指南

我通過示例文檔詮釋了這篇文章中所講述的思考，在繼續閱讀全文之前，請務必確認你已經閱讀了示例產品文檔

為什麼要寫產品文檔？

為了以更高的質量、更快的速度和更佳的預判來交付正確的產品。

是的，就是這樣。那麼，產品文檔將如何幫助你做到這一切呢？Ben Horowitz 分享了上圖中這個看法，我的示例文檔也是一個很好的例證。明確一下要點：

從一開始就理性思考
在團隊開始付出更高成本去設計軟體架構、實施代碼開發、完善界面設計、測試軟體質量之前，寫文檔可以迫使你提前思考每一個細節。這將會提高你決策的質量，降低意外事件發生的概率。
高效溝通
你常常需要和不同的利益相關方（支持團隊，工程團隊，設計團隊，財務團隊，管理層等等）溝通你的方案。產品文檔可以幫助你事半功倍地完成溝通，避免口頭溝通中產生的歧義，團隊中的所有人可以更好地理解你的意圖，並且更有的放矢地做出答覆。
明確權責
明確項目目標的評價標準，公開承諾獎懲激勵機制：利益相關方可以知曉如果最後一刻變更需求會意味著什麼，工程師們也會在預估工期時再三斟酌。

產品文檔中應當包含哪些內容？

產品文檔應該明確溝通要做一個「什麼」產品，以及「為什麼」要這麼做。用來說明清楚一個產品的表達方式很多，但最核心的，一定要說清楚這五件事情：

問題
描繪你此次打算解決的問題。更重要的是，解釋為什麼要去解決這個問題。描述要儘可能地具體，並且提供相關的數據指標。
可衡量的目標
明確承諾交付和成果，明確哪些事情超出了此項目的範疇。每一個目標，都應該可以明確衡量「是否達到目標」。
需求背景
提供你的觀眾理解當前問題以及接受你的提議所需的所有背景信息。包括但不限於假設、用例、數據指標等信息。
解決方案詳情
你的提議應該有充足的細節，易於團隊成員消化理解及執行——可以把這部分內容想像成對人腦進行編程和執行。
時間軸
列出你的團隊共同認可的截止日期和其他重要時間點。這部分內容開始的時候可能會比較模糊，但是在最後一次文檔評審之前應當完全敲定。

你可以使用我的示例文檔做你的文檔模板，按照你的想法增/刪/改任何章節。只要你能夠清晰並且條理清楚地表述上面提到的這五點信息，文檔形式並不重要。

如何寫產品文檔？

接下來我會介紹我撰寫和評審文檔的常規流程。根據項目大小，利益相關方的數量不同等情況，流程細節可能會有所變化，但是大體的流程是確定的。

快速完成一個草稿（1-2 個小時）
關閉電子郵件和聊天工具。泡杯茶，坐在椅子上開始思考，然後逐一把你所了解的信息列成清單（見上文中的示例思路筆記）。
安排幾個 30 分鐘的一對一會議（1-4 個小時）
這個步驟的目的是過一遍文檔中的細節，優化你的方案，並且獲得更多人的支持。儘可能控制這些會議的規模，人越少越好（理想狀態下都應該是一對一會議）。
在本文的示例中，我會和客服部門的負責人，一個財務人員和一個工程師分別安排一次會議。
撰寫和編輯文檔（0.5-3 天）
此時，你應該對能做，並且應該做什麼有了一個明確的想法，但是大腦中塞滿了大量的細節等待著梳理清楚。於是接下來需要將所有這些細節都整理出來，並且逐一梳理斟酌。
在完成第一版文檔之後，需要繼續大篇幅編輯修改，通常最終的文檔可以在你的第一版草稿的基礎上壓縮 30%-50% 的長度，簡潔和清晰的文檔就意味著更加容易閱讀。
大部分文檔都可以在半天到一天的時間裡完成，不過實際上也會有一些文檔需要兩三天才能寫完。
群發文檔並且安排一個 1 小時的評審會議（15 分鐘）
將文檔群發給項目的所有利益相關方，並且抄送給其他可能對文檔感興趣的團隊（例如你所在的產品團隊，整個支持團隊等）。
跟進這些關鍵人員是否接受了會議邀請：將會執行這件事情的人，和所有對這件事情有通過/否決權力的人。
評審文檔（1小時）
在開始會議之前，詢問是否有參會者沒有詳細閱讀你的文檔。通常都會有一兩個人中槍，在這種情況下可以說：「沒問題，我們先用 10 分鐘一起來看一下文檔。已經讀過文檔的人可以利用這個時間先放鬆休息一下」。
這次會議上你需要獲得利益相關方的同意，並且獲得執行方（工程師、支持團隊等）的知曉、認可以及人力支持。
你可能需要開多次評審會議，並且根據評審會議上溝通的信息不斷修改文檔。
通過評審後，及時同步信息和建立工單（1-2 小時）
會後同步信息的電子郵件需要包含更新後的產品文檔鏈接，和此項目相關的工單鏈接（例如「在頁面上添加 JavaScript 代碼」，「完成數據分析報告」，「測試 Staging 環境」，「和支持團隊預演流程」，等等）。
一般接下來將會有一位工程師完成技術文檔，不過並不總是這樣（文中的示例項目就不需要這一步）。

寫出高效產品文檔的進階技巧

盡量簡短
沒有比這更重要的文檔寫作建議了。簡潔意味著清晰的思路和溝通，也意味著你的文檔更加易於閱讀和理解——這一點至關重要。
使用平白的語言和簡單的格式
使用簡短而不是花哨的語句，使用列表和加粗強調可以使文章更一目了然，以放鬆有趣的方式寫作而不是一板一眼，如果你有得體的幽默感就再好不過了。
為開發團隊預留時間
通過評審並且達成一致通過的文檔才是完善的文檔。如果你希望在未來的某一個迭代 Sprint 中開發此項目，就應該提前兩到三周開始這個產品文檔寫作流程。
像工程師一樣思考
在項目得以進入開發之時，常常會發現大量未預料到的邊緣情況——但這種情形其實可以避免。如果你認真考慮過項目進入開發的所有必要條件，你就可以提前發現這些問題（例如，是否在移動設備中可以使用在線聊天功能？）。
確保每一個人都跟上了你的節奏
當我組織產品評審時，會議室里的大部分人都已經大致了解我要講的內容——因為我已經提前在討論會和日常聊天中溝通過這個事情了。既然大家都已經清楚了「做什麼」和「為什麼要做」的問題，文檔評審會上我們只要關注實施細節就好了。
在圖表中下功夫
流程圖、線框圖等圖表可以通過易於理解的方式提供很大的信息量，同時也需要消耗非常多的時間來製作這些圖表。
在思考和寫文檔上花 0.5-3 天時間
具體時間根據項目大小而定。花費在寫文檔上的時間越長，所帶來的邊際收益就會遞減。特別需要指出的是，沒有人能夠讀的下去超過 5-6 頁的文檔。
指明方向，明晰願景
你不僅僅是在定義一個功能，也是在解釋「為什麼我們要做這件事情」以及「我們的目標是什麼」，在文檔中指出這個項目將會對更高層面的規劃造成什麼影響，以及接下來會發生什麼。
確保你的觀眾閱讀了文檔
如果你的文檔又臭又長，或者從來不分享給對應的人，那你還不如不寫文檔。務必確保你的文檔被對應的人閱讀了，我上面關於評審開始時留時間給大家讀文檔的建議值得大家參考。
獲取真誠的反饋
你的文檔是否是在贅述人盡皆知的事情？或者是文檔缺乏足夠的細節？是否在後續實施中發現了太多的邊緣情況？又或者，是否在制定計劃和文檔評審上耗費了太多的時間？你應該和你的團隊時刻保持溝通。

說好的敏捷開發（Agile/Scrum）呢？
我知道會有爭議，但是產品文檔和敏捷宣言的原則沒有絲毫衝突，並且在類似於 Scrum 這樣的敏捷方法上得到了充分發揮——畢竟，用戶故事（Story）許多時候需要詳盡的描述，文檔可以增加溝通中的清晰度和可傳播性，為什麼非要刻板地認為僅僅使用口頭溝通和使用白板才算是敏捷開發呢？
「產品文檔會導致發布變慢，過度規劃，通常會浪費時間」的想法完全是無稽之談。我工作過的多個世界級團隊遵循著一些敏捷原則（例如兩周一個迭代周期），每天（甚至更頻繁地）發布代碼，並且以發布產品（而不是文檔或者會議）作為衡量成功的標準——也都仍然認為文檔是他們打造成功軟體的一個關鍵部分。

你對技術文檔怎麼看？
我是一個技術文檔的支持者。產品文檔通常關注「做什麼」，而技術文檔更多關注在「如何做」。這兩種文檔為研發流程中的不同環節帶來同樣的清晰視角，並且都使得工程師（和他們的用戶）身心愉悅。
未來如果大家有興趣的話我可能會寫一篇關於技術文檔的文章。

總結
感謝你讀到這裡。如果你認為這篇文章有用，請分享給其他人——特別是你的產品/工程團隊。
如果你想看更多的產品經理內容（例如：規劃產品路線圖），或者想了解其他人如何使用產品文檔，請用兩分鐘填寫這個小調查（英文）。我會在未來的文章中分享調查結果中有意思的信息。

以上，祝寫文檔愉快！

備註：

感謝周思博（Joel Spolsky）（微軟早期 PM，曾參與創辦 Stack Overflow，Trello，FogBugz 等產品，《軟體隨想錄》作者）的「文檔是對人腦的編程」的比喻。早在2000年，他寫了4 篇關於文檔的系列文章（英文），這對我的 PM 道路產生了巨大的影響，強烈推薦。
在頂部的引文中，貝索斯所說的筆記是指為高層管理會議使用的，介紹新業務/產品創意的備忘錄。這實際上不算是產品文檔，但是兩者並不是完全不一樣。貝索斯在會議開始的時候會組織所有人默讀文件——這激發了我在文檔評審時做同樣的事情。來源
感謝 iDoneThis 博客這篇關於寫作的價值的文章（英文）。這是貝索斯和 Horowitz 的引言的來源。

感謝 Vikram Oberoi 。

閱讀更多原創文章及譯文，可以關注我的知乎專欄：不安靜的書桌·知乎專欄
原文鏈接：https://goberoi.com/on-writing-product-specs-5ca697b992fd

原創翻譯，轉載請註明出處

--------------------------
更新部分：
感謝大家關注。今天翻牆找了兩個國外產品文檔模板。其實和國內的差不多，第一個跟我之前看到的中國電信內部PRD差不多，第二個也是很普通的~
第一個是電商類網站的BRD，下載鏈接http://pan.baidu.com/s/1qW0pRoo
第二個是移動APP的需求文檔，下載鏈接http://pan.baidu.com/s/1qWJSGrE
--------------------------
在Quora上搜索了PRD template（產品需求文檔模板）、spec sample（產品說明書樣本）等等關鍵字，看了10+個問題，普遍的答案都是：我們沒有固定的格式和模板呀。根據我所看的Quora問題總結，現在普遍的趨勢都是使用原型代替文字居多的文檔。
我的答案將有兩部分組成：1.選兩個quora問答摘錄漢化一下；2.貼出Marty Cagan（《啟示錄》作者）的產品說明文檔範例。

先選一個代表性的問答摘錄一下，寫主要的，有一部分略去沒有翻譯（PS：本人英語渣，主要是意譯，歡迎重新提供翻譯或指正）：

問題：What Format Are Product Managers Using to Create and Deliver Product Requirements?（產品經理在指定產品需求時有什麼固定的格式？）
Cliff Gilley（15年產品管理經驗）的回答：
我使用的工具和開發流程都是比較隨意的，根據不同情況而定，只要讓開發者容易明白就行了。我一般使用：

有注釋的線框圖，包含頁面跳轉的指向；

產品需求文檔，討厭的東西額

嚴密具體的用戶故事

簡單的用例

現在寫那些所謂的「需求"已經不明智了，特別當你在一個牛逼的開發團隊里時。你只要闡明你想解決的問題、說明用戶如何使用，然後定期檢查開發者的工作再提議反饋就行了。

下面這個問答，可以看出有些歪國人是用workflow（工作流工具）發布需求的。

問題：What"s an Effective Workflow for Writing a Spec or Product Requirements Document (PRD)?（有什麼有效的工作流工具可以用來寫產品需求說明書？）
Nick Barr（Canvas產品經理）的回答：
需求文檔至少要有3個部分：

用例。包含詳細的功能列表。

線框圖或原型。

成功的指標：怎樣確定項目做成功了？有什麼指標，如何度量？（應該是類似里程碑什麼的）

根據團隊不同，PRD可能還需要包含這些：簡介/目標，競爭分析，功能特性列表。
好啦，產品結構骨架都想好了，然後文檔發布在Confluence里，如圖：
（陳西西特此注釋：我百度了一下，Confluence是一種工作流工具，詳細介紹移步：Confluence - Team Collaboration Software）

PRD里，先寫用例或者先線框圖都沒關係，順序可以打亂。
關於生成線框圖的具體方法：1.隨便搞個白板和設計師一起畫出UI的草稿；2.用Balsamiq（一種手繪風格的原型工具）和photoshop生成原型，或者只用HTML把UI連接起來(wire it up)就好；3.把線框圖加到PRD里，創建一個三列的表格：頁面標題、線框圖、交互描述，如圖：

用例怎麼寫：記住這些寫出來都是直接交給團隊開發的，不要出錯，要寫的清楚明白透徹，要用完整的句子描述功能，或者列出功能特性的清單。直接在Confluence里寫，如圖：

（圖中翻譯有誤，User Stories應翻譯為「用戶故事」，而非「用例」）

好了，最後把開發狀態改為「待審查」，然後email團隊成員，讓他們審查和對PRD提議。

好。碼字到此，我已經快眼瞎了，你先給我點個贊。
接下來我將介紹Marty Cagan的產品說明文檔法則。
（Marty Cagan，矽谷產品集團（SVPG: Sillicon Valley Product Group）合伙人，曾經是網景公司平台及工具部門副總裁、ebay產品管理和設計高級副總裁。著有：《啟示錄：打造用戶喜愛的產品》）

Marty Cagan認為產品文檔沒有固定格式，但理想的產品說明文檔應該滿足以下要求：
1. 產品說明文檔應該完整地描述用戶體驗——不只是用戶需求，還包括交互設計和視覺設計。希望大家已經明白用戶需求和用戶體驗是密不可分的。
2. 產品說明文檔必須準確地描述軟體的行為。文字和圖片的表達能力實在有限，不足以完成這項任務。
3. 產品說明文檔的受眾較廣——開發人員、測試人員、客服人員、市場營銷人員、運維人員、銷售人員、管理層等等。因此，產品說明文檔必須以某種直觀的方式把產品信息和產品行為告訴所有人。
4. 產品說明文檔應該可以修改。雖然進入開發階段後，應該盡量避免修改產品說明文檔，但總有意想不到的問題出現，需要修改產品說明文檔以適應新情況。
5. 撰寫產品說明文檔的過程中會出現許多衍生物，比如，按優先順序排列的需求列表、線框圖、實體模型，但應該有一個主體來代表產品，避免混淆不清，版本錯亂。
（摘自Cagan的《啟示錄》一書，擴展閱讀：Marty Cagan：重新定義產品說明文檔）

Cagan建議「嘗試高保真原型，與其花幾個星期撰寫冗長的Word文檔，既沒人讀，也無法測試，還不如和設計師一起創建產品原型「。
另外，他在http://SVPG.com網站上給出了產品說明文檔的範例：Examples

我一般都是先畫線框，然後交互、注釋
一般對接部門只看這些，文檔基本是不看的

國外的軟體開發模式一般分為重方法論以及敏捷方法論兩種模式。
重方法論比較注重產品的完整性與前期設計，因為文檔一般比較詳盡和全面。適合做邏輯比較複雜，規模比較大的系統。
敏捷方法論注重產品的快速迭代，未來重構，為現在而設計。因此文檔一般和交互說明寫在一起，文檔較輕。適合業務邏輯比較簡單，規模相對較小的產品。敏捷方法論的產品現在甚至有一種無文檔的趨勢，都是靠交互說明去體現並且補充相應的規則。
個人認為文檔在時間條件允許的情況下還是應該相對完善，也是版本多次迭代以後自己回頭反思的一個重要依據。

有沒有問國內需求文檔怎麼寫的問題…

個人覺得，只要說明白問題就行…還不如直接寫測試用例…

產品經理是中國特有的吧,,,國外沒有產品經理這一個職位

外國的PRD寫得好系列