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

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

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

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

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

首先，舉個(gè)例子,假設(shè)你在這里工作：

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

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

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

在你沒(méi)有產(chǎn)品文檔時(shí)，你會(huì)這樣做：

比方說(shuō)，你覺(jué)得行動(dòng)起來(lái)總是最重要的，因此直接開始動(dòng)手：

1. 在迭代計(jì)劃會(huì)上，你和團(tuán)隊(duì)討論了這個(gè)需求。

2. 然后你挑選了一個(gè)靠譜的第三方客服供應(yīng)商。

3. 提交一個(gè)工單來(lái)讓工程師添加一些 Javascript 代碼。

4. 和支持團(tuán)隊(duì)開個(gè)會(huì)，確定他們都準(zhǔn)備好了

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

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

• 工程師把工單標(biāo)記完成了，但是一驗(yàn)收測(cè)試，就發(fā)現(xiàn)這個(gè)功能完全沒(méi)有考慮移動(dòng)端的適配。

• 「唉呀！你忘了提醒大家手機(jī)端的使用才是核心場(chǎng)景。」

• 用戶運(yùn)營(yíng)經(jīng)理打算開展一個(gè)漫長(zhǎng)的評(píng)審流程，以確定最合適的聊天服務(wù)商。

• 「啊……需要定一個(gè)會(huì)議，向大家解釋下這次上線只是一個(gè)灰度測(cè)。」

• 發(fā)布一小時(shí)后，客服報(bào)告說(shuō)他們收到了西班牙語(yǔ)的在線聊天請(qǐng)求。

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

• 一個(gè)設(shè)計(jì)師花了幾天，為聊天窗口滑入屏幕的交互繪制了一個(gè)完美的動(dòng)畫。

• 「用戶體驗(yàn)過(guò)度優(yōu)化，你是否對(duì)整個(gè)團(tuán)隊(duì)統(tǒng)一了「這次只是一個(gè)測(cè)試」的預(yù)期？」

• 一周的測(cè)試完成之后，數(shù)據(jù)分析師發(fā)現(xiàn)無(wú)法產(chǎn)出你要的報(bào)告，因?yàn)橄嚓P(guān)的必要指標(biāo)并沒(méi)有埋點(diǎn)。

• 「史詩(shī)級(jí)的失敗。從頭再來(lái)吧。」

如果這是一個(gè)相對(duì)簡(jiǎn)單的項(xiàng)目，即使沒(méi)有產(chǎn)品文檔可能也不至于陷入這樣的災(zāi)難之中。但是在簡(jiǎn)單的項(xiàng)目中你仍然有可能會(huì)因?yàn)闆](méi)有文檔浪費(fèi)許多時(shí)間和機(jī)會(huì)成本。

如果你寫了一篇文檔：

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

請(qǐng)?jiān)诶^續(xù)閱讀文章之前，花幾分鐘讀一下這兩篇示例文檔吧。

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

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

2.文檔撰寫指南

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

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

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

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

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

3. 明確權(quán)責(zé)
   明確項(xiàng)目目標(biāo)的評(píng)價(jià)標(biāo)準(zhǔn)，公開承諾獎(jiǎng)懲激勵(lì)機(jī)制：利益相關(guān)方可以知曉如果最后一刻變更需求會(huì)意味著什么，工程師們也會(huì)在預(yù)估工期時(shí)再三斟酌。

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

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

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

2. 可衡量的目標(biāo)
   明確承諾交付和成果，明確哪些事情超出了此項(xiàng)目的范疇。每一個(gè)目標(biāo)，都應(yīng)該可以明確衡量「是否達(dá)到目標(biāo)」。

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

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

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

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

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

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

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

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

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

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

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

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

一般接下來(lái)將會(huì)有一位工程師完成技術(shù)文檔，不過(guò)并不總是這樣（文中的示例項(xiàng)目就不需要這一步）。

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

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

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

3. 為開發(fā)團(tuán)隊(duì)預(yù)留時(shí)間
   通過(guò)評(píng)審并且達(dá)成一致通過(guò)的文檔才是完善的文檔。如果你希望在未來(lái)的某一個(gè)迭代 Sprint 中開發(fā)此項(xiàng)目，就應(yīng)該提前兩到三周開始這個(gè)產(chǎn)品文檔寫作流程。

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

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

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

7. 在思考和寫文檔上花 0.5-3 天時(shí)間
   具體時(shí)間根據(jù)項(xiàng)目大小而定。花費(fèi)在寫文檔上的時(shí)間越長(zhǎng)，所帶來(lái)的邊際收益就會(huì)遞減。特別需要指出的是，沒(méi)有人能夠讀的下去超過(guò) 5-6 頁(yè)的文檔。

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

9. 確保你的觀眾閱讀了文檔
   如果你的文檔又臭又長(zhǎng)，或者從來(lái)不分享給對(duì)應(yīng)的人，那你還不如不寫文檔。務(wù)必確保你的文檔被對(duì)應(yīng)的人閱讀了，我上面關(guān)于評(píng)審開始時(shí)留時(shí)間給大家讀文檔的建議值得大家參考。

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

感謝 Vikram Oberoi 。

?

END

?

?

?