國外的產(chǎn)品經(jīng)理怎么寫需求文檔

很多人聽到「產(chǎn)品文檔」這四個字就像吞了蒼蠅一樣，人們通常會認為這意味著又要花幾周寫一個根本沒人看的文檔。如果一個團隊總被產(chǎn)品文檔這種事情拖累，怎么可能「敏捷」得起來，怎么可能高效地產(chǎn)出代碼？

我在過去十幾年創(chuàng)造了多個數(shù)百萬人使用的軟件產(chǎn)品之后，越發(fā)認為這種觀點是完全錯誤的。根據(jù)我的經(jīng)驗：

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

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

首先，舉個例子,假設你在這里工作：

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

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

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

在你沒有產(chǎn)品文檔時，你會這樣做：

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

1. 在迭代計劃會上，你和團隊討論了這個需求。

2. 然后你挑選了一個靠譜的第三方客服供應商。

3. 提交一個工單來讓工程師添加一些 Javascript 代碼。

4. 和支持團隊開個會，確定他們都準備好了

搞定了！這么簡單的事情怎么能要我們寫產(chǎn)品文檔呢？如果你是在一個小型創(chuàng)業(yè)團隊，你也確實并不需要——因為產(chǎn)品改動相對小，涉及到的人也相對更少。

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

• 工程師把工單標記完成了，但是一驗收測試，就發(fā)現(xiàn)這個功能完全沒有考慮移動端的適配。

• 「唉呀！你忘了提醒大家手機端的使用才是核心場景。」

• 用戶運營經(jīng)理打算開展一個漫長的評審流程，以確定最合適的聊天服務商。

• 「啊……需要定一個會議，向大家解釋下這次上線只是一個灰度測?！?/span>

• 發(fā)布一小時后，客服報告說他們收到了西班牙語的在線聊天請求。

• 「啥？要追加一個緊急發(fā)布，把這個測試限定在英語用戶中。」

• 一個設計師花了幾天，為聊天窗口滑入屏幕的交互繪制了一個完美的動畫。

• 「用戶體驗過度優(yōu)化，你是否對整個團隊統(tǒng)一了「這次只是一個測試」的預期？」

• 一周的測試完成之后，數(shù)據(jù)分析師發(fā)現(xiàn)無法產(chǎn)出你要的報告，因為相關的必要指標并沒有埋點。

• 「史詩級的失敗。從頭再來吧?！?/span>

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

如果你寫了一篇文檔：

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

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

• 閱讀 示例思路筆記 （閱讀時間 2 分鐘）
  這是一個根據(jù)你已知的信息和想要解答的問題所梳理成的列表。
  這會是你需要做的第一件事情，大約需要一個小時來完成這個文檔。這個文檔會成為你和團隊中其他人的一個溝通基礎。

• 閱讀 示例產(chǎn)品文檔 （閱讀時間 6 分鐘）
  只有和團隊一起評審了你的假設和創(chuàng)意之后（無論是在專門召集的會議上，喝咖啡時，或者桌上足球的休息時間），你才應該真正開始寫產(chǎn)品文檔。如果已經(jīng)完成了溝通和評審，整個文檔應該花費你 1-3 個小時的時間。

2.文檔撰寫指南

我通過示例文檔詮釋了這篇文章中所講述的思考，在繼續(xù)閱讀全文之前，請務必確認你已經(jīng)閱讀了 示例產(chǎn)品文檔

為了以更高的質(zhì)量、更快的速度和更佳的預判來交付正確的產(chǎn)品。

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

1. 從一開始就理性思考
   在團隊開始付出更高成本去設計軟件架構、實施代碼開發(fā)、完善界面設計、測試軟件質(zhì)量之前，寫文檔可以迫使你提前思考每一個細節(jié)。這將會提高你決策的質(zhì)量，降低意外事件發(fā)生的概率。

2. 高效溝通
   你常常需要和不同的利益相關方（支持團隊，工程團隊，設計團隊，財務團隊，管理層等等）溝通你的方案。產(chǎn)品文檔可以幫助你事半功倍地完成溝通，避免口頭溝通中產(chǎn)生的歧義，團隊中的所有人可以更好地理解你的意圖，并且更有的放矢地做出答復。

3. 明確權責
   明確項目目標的評價標準，公開承諾獎懲激勵機制：利益相關方可以知曉如果最后一刻變更需求會意味著什么，工程師們也會在預估工期時再三斟酌。

產(chǎn)品文檔中應當包含哪些內(nèi)容？

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

1. 問題
   描繪你此次打算解決的問題。更重要的是，解釋為什么要去解決這個問題。描述要盡可能地具體，并且提供相關的數(shù)據(jù)指標。

2. 可衡量的目標
   明確承諾交付和成果，明確哪些事情超出了此項目的范疇。每一個目標，都應該可以明確衡量「是否達到目標」。

3. 需求背景
   提供你的觀眾理解當前問題以及接受你的提議所需的所有背景信息。包括但不限于假設、用例、數(shù)據(jù)指標等信息。

4. 解決方案詳情
   你的提議應該有充足的細節(jié)，易于團隊成員消化理解及執(zhí)行——可以把這部分內(nèi)容想象成對人腦進行編程和執(zhí)行。

5. 時間軸
   列出你的團隊共同認可的截止日期和其他重要時間點。這部分內(nèi)容開始的時候可能會比較模糊，但是在最后一次文檔評審之前應當完全敲定。

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

如何寫產(chǎn)品文檔？

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

1. 快速完成一個草稿（1-2 個小時）
   關閉電子郵件和聊天工具。泡杯茶，坐在椅子上開始思考，然后逐一把你所了解的信息列成清單（見上文中的 示例思路筆記 ）。

2. 安排幾個 30 分鐘的一對一會議 （1-4 個小時）
   這個步驟的目的是過一遍文檔中的細節(jié)，優(yōu)化你的方案，并且獲得更多人的支持。盡可能控制這些會議的規(guī)模，人越少越好（理想狀態(tài)下都應該是一對一會議）。
   在本文的示例中，我會和客服部門的負責人，一個財務人員和一個工程師分別安排一次會議。

3. 撰寫和編輯文檔 （0.5-3 天）
   此時，你應該對能做，并且應該做什么有了一個明確的想法，但是大腦中塞滿了大量的細節(jié)等待著梳理清楚。于是接下來需要將所有這些細節(jié)都整理出來，并且逐一梳理斟酌。
   在完成第一版文檔之后，需要繼續(xù)大篇幅編輯修改，通常最終的文檔可以在你的第一版草稿的基礎上壓縮 30%-50% 的長度，簡潔和清晰的文檔就意味著更加容易閱讀。
   大部分文檔都可以在半天到一天的時間里完成，不過實際上也會有一些文檔需要兩三天才能寫完。

4. 群發(fā)文檔并且安排一個 1 小時的評審會議（15 分鐘）
   將文檔群發(fā)給項目的所有利益相關方，并且抄送給其他可能對文檔感興趣的團隊（例如你所在的產(chǎn)品團隊，整個支持團隊等）。
   跟進這些關鍵人員是否接受了會議邀請：將會執(zhí)行這件事情的人，和所有對這件事情有通過/否決權力的人。

5. 評審文檔（1小時）
   在開始會議之前，詢問是否有參會者沒有詳細閱讀你的文檔。通常都會有一兩個人中槍，在這種情況下可以說：「沒問題，我們先用 10 分鐘一起來看一下文檔。已經(jīng)讀過文檔的人可以利用這個時間先放松休息一下」。
   這次會議上你需要獲得利益相關方的同意，并且獲得執(zhí)行方（工程師、支持團隊等）的知曉、認可以及人力支持。
   你可能需要開多次評審會議，并且根據(jù)評審會議上溝通的信息不斷修改文檔。

6. 通過評審后，及時同步信息和建立工單 （1-2 小時）
   會后同步信息的電子郵件需要包含更新后的產(chǎn)品文檔鏈接，和此項目相關的工單鏈接（例如「在頁面上添加 JavaScript 代碼」，「完成數(shù)據(jù)分析報告」，「測試 Staging 環(huán)境」，「和支持團隊預演流程」，等等）。

一般接下來將會有一位工程師完成技術文檔，不過并不總是這樣（文中的示例項目就不需要這一步）。

寫出高效產(chǎn)品文檔的進階技巧

1. 盡量簡短
   沒有比這更重要的文檔寫作建議了。簡潔意味著清晰的思路和溝通，也意味著你的文檔更加易于閱讀和理解——這一點至關重要。

2. 使用平白的語言和簡單的格式
   使用簡短而不是花哨的語句，使用列表和加粗強調(diào)可以使文章更一目了然，以放松有趣的方式寫作而不是一板一眼，如果你有得體的幽默感就再好不過了。

3. 為開發(fā)團隊預留時間
   通過評審并且達成一致通過的文檔才是完善的文檔。如果你希望在未來的某一個迭代 Sprint 中開發(fā)此項目，就應該提前兩到三周開始這個產(chǎn)品文檔寫作流程。

4. 像工程師一樣思考
   在項目得以進入開發(fā)之時，常常會發(fā)現(xiàn)大量未預料到的邊緣情況——但這種情形其實可以避免。如果你認真考慮過項目進入開發(fā)的所有必要條件，你就可以提前發(fā)現(xiàn)這些問題（例如，是否在移動設備中可以使用在線聊天功能？）。

5. 確保每一個人都跟上了你的節(jié)奏
   當我組織產(chǎn)品評審時，會議室里的大部分人都已經(jīng)大致了解我要講的內(nèi)容——因為我已經(jīng)提前在討論會和日常聊天中溝通過這個事情了。既然大家都已經(jīng)清楚了「做什么」和「為什么要做」的問題，文檔評審會上我們只要關注實施細節(jié)就好了。

6. 在圖表中下功夫
   流程、線框圖等圖表可以通過易于理解的方式提供很大的信息量，同時也需要消耗非常多的時間來制作這些圖表。

7. 在思考和寫文檔上花 0.5-3 天時間
   具體時間根據(jù)項目大小而定。花費在寫文檔上的時間越長，所帶來的邊際收益就會遞減。特別需要指出的是，沒有人能夠讀的下去超過 5-6 頁的文檔。

8. 指明方向，明晰愿景
   你不僅僅是在定義一個功能，也是在解釋「為什么我們要做這件事情」以及「我們的目標是什么」，在文檔中指出這個項目將會對更高層面的規(guī)劃造成什么影響，以及接下來會發(fā)生什么。

9. 確保你的觀眾閱讀了文檔
   如果你的文檔又臭又長，或者從來不分享給對應的人，那你還不如不寫文檔。務必確保你的文檔被對應的人閱讀了，我上面關于評審開始時留時間給大家讀文檔的建議值得大家參考。

10. 獲取真誠的反饋
    你的文檔是否是在贅述人盡皆知的事情？或者是文檔缺乏足夠的細節(jié)？是否在后續(xù)實施中發(fā)現(xiàn)了太多的邊緣情況？又或者，是否在制定計劃和文檔評審上耗費了太多的時間？你應該和你的團隊時刻保持溝通。

感謝 Vikram Oberoi 。

?

END

?

?

?