寫在前面的話：
產(chǎn)品經(jīng)理在一家互聯(lián)網(wǎng)公司往往掌管著所有的需求，需要溝通的對(duì)象也包括了設(shè)計(jì)、開發(fā)、測(cè)試、運(yùn)營等角色。所以，一名產(chǎn)品經(jīng)理需要處理和面對(duì)的信息量常常是巨大的，也因此往往會(huì)面臨到溝通低效、產(chǎn)品開發(fā)進(jìn)度和質(zhì)量不可控等等問題。
這時(shí)候，最好的解決方案，其實(shí)是一份清晰高效的產(chǎn)品文檔。可惜，大部分產(chǎn)品經(jīng)理對(duì)于“文檔”的價(jià)值和意義認(rèn)知都是不夠的。
在本文中，作者Gaurav Oberoi分享了他對(duì)于產(chǎn)品文檔的看法以及撰寫產(chǎn)品文檔的常用流程。此外，本文還含有一份真正完整的產(chǎn)品文檔示例，以及詳細(xì)的產(chǎn)品文檔寫作指南(包括格式+思路)，希望對(duì)你有所幫助。
以下是正文
很多人聽到「產(chǎn)品文檔」這四個(gè)字就像吞了蒼蠅一樣，人們通常會(huì)認(rèn)為這意味著又要花幾周寫一個(gè)根本沒人看的文檔。如果一個(gè)團(tuán)隊(duì)總被產(chǎn)品文檔這種事情拖累，怎么可能「敏捷」得起來，怎么可能高效地產(chǎn)出代碼?
我在過去十幾年創(chuàng)造了多個(gè)數(shù)百萬人使用的軟件產(chǎn)品之后，越發(fā)認(rèn)為這種觀點(diǎn)是完全錯(cuò)誤的。根據(jù)我的經(jīng)驗(yàn)：
高效的產(chǎn)品文檔是創(chuàng)造偉大產(chǎn)品的過程中所不可或缺的重要組成部分。撰寫產(chǎn)品文檔可以強(qiáng)制所有人從項(xiàng)目初始就理性思考，頻繁溝通，明確權(quán)責(zé)——所有的這些都會(huì)帶來更好的軟件質(zhì)量，更低的進(jìn)度風(fēng)險(xiǎn)，以及更少的時(shí)間浪費(fèi)。
在這篇文章中，我會(huì)通過一個(gè)案例來分享一些普適的建議，這些建議會(huì)對(duì)產(chǎn)品經(jīng)理，尤其是大中型(超過二百人的)公司中的產(chǎn)品經(jīng)理們非常有幫助。
首先，讓我們來看個(gè)例子
假設(shè)你需要解決這么一個(gè)問題：
一家從事在線旅游預(yù)訂服務(wù) (就像 Hotels 或者 Airbnb 但是規(guī)模更小一些)的公司。目前這家公司的支付轉(zhuǎn)化率偏低，所以這個(gè)季度大家打算嘗試通過在支付環(huán)節(jié)加入在線客服的方案來提升轉(zhuǎn)化。
你的計(jì)劃是：
通過在支付環(huán)節(jié)增加在線客服來嘗試提高支付轉(zhuǎn)化率。
支付轉(zhuǎn)化率目前僅有 18%，而業(yè)內(nèi)平均轉(zhuǎn)化率有 30%。我們打算測(cè)試下在支付時(shí)展示在線客服聊天窗口是否可以提高這個(gè)轉(zhuǎn)化率。用戶運(yùn)營團(tuán)隊(duì)已經(jīng)同意了提供1人月的客服人力支持。
在你沒有產(chǎn)品文檔時(shí)，你會(huì)這樣做：
比方說，你覺得行動(dòng)起來總是最重要的，因此直接開始動(dòng)手：
1. 在迭代計(jì)劃會(huì)上，你和團(tuán)隊(duì)討論了這個(gè)需求;
2. 然后你挑選了一個(gè)靠譜的第三方客服供應(yīng)商(例如 SnapEngage );
3. 提交一個(gè)工單來讓工程師添加一些 Javascript 代碼;
4. 和支持團(tuán)隊(duì)開個(gè)會(huì)，確定他們都準(zhǔn)備好了。
搞定了!這么簡(jiǎn)單的事情怎么能要我們寫產(chǎn)品文檔呢?
那么現(xiàn)在問題來了：
如果你是在一個(gè)小型創(chuàng)業(yè)團(tuán)隊(duì)，你也確實(shí)可能并不需要一份產(chǎn)品文檔——因?yàn)楫a(chǎn)品改動(dòng)相對(duì)小，涉及到的人也相對(duì)更少。
但如果你是在一個(gè)更大的組織之中，或者產(chǎn)品更加成熟/復(fù)雜，就會(huì)陸續(xù)出現(xiàn)下列這些問題，并且相比寫文檔，這些問題會(huì)需要更多時(shí)間來處理。例如：
工程師把工單標(biāo)記完成了，但是一驗(yàn)收測(cè)試，就發(fā)現(xiàn)這個(gè)功能完全沒有考慮移動(dòng)端的適配。(唉呀!你忘了提醒大家手機(jī)端的使用才是核心場(chǎng)景。)
用戶運(yùn)營經(jīng)理打算開展一個(gè)漫長的評(píng)審流程，以確定最合適的聊天服務(wù)商。(啊……需要定一個(gè)會(huì)議，向大家解釋下這次上線只是一個(gè)灰度測(cè)試。)
發(fā)布一小時(shí)后，客服報(bào)告說他們收到了西班牙語的在線聊天請(qǐng)求。(啥?要追加一個(gè)緊急發(fā)布，把這個(gè)測(cè)試限定在英語用戶中。)
一個(gè)設(shè)計(jì)師花了幾天，為聊天窗口滑入屏幕的交互繪制了一個(gè)完美的動(dòng)畫。(用戶體驗(yàn)過度優(yōu)化，你是否對(duì)整個(gè)團(tuán)隊(duì)統(tǒng)一了“這次只是一個(gè)測(cè)試”的預(yù)期?)
一周的測(cè)試完成之后，數(shù)據(jù)分析師發(fā)現(xiàn)無法產(chǎn)出你要的報(bào)告，因?yàn)橄嚓P(guān)的必要指標(biāo)并沒有埋點(diǎn)。(史詩級(jí)的失敗。從頭再來吧。)
如果這是一個(gè)相對(duì)簡(jiǎn)單的項(xiàng)目，即使沒有產(chǎn)品文檔可能也不至于陷入這樣的災(zāi)難之中。但是在簡(jiǎn)單的項(xiàng)目中你仍然有可能會(huì)因?yàn)闆]有文檔浪費(fèi)許多時(shí)間和機(jī)會(huì)成本。
而如果你寫了一篇文檔：
為了便于說明，我準(zhǔn)備了兩個(gè)示例文檔：一篇思路筆記，和一篇完整的產(chǎn)品文檔——這樣可以完整介紹產(chǎn)品文檔的撰寫流程。
請(qǐng)?jiān)诶^續(xù)閱讀下文之前，花幾分鐘讀一下這兩篇示例文檔吧。
1. 思路筆記示例
這是一個(gè)根據(jù)你已知的信息和想要解答的問題所梳理成的列表。這會(huì)是你需要做的第一件事情，大約需要一個(gè)小時(shí)來完成這個(gè)文檔。這個(gè)文檔會(huì)成為你和團(tuán)隊(duì)中其他人的一個(gè)溝通基礎(chǔ)。
↓↓↓以下是思路筆記示例部分↓↓↓
1. 問題
轉(zhuǎn)化率糟透了，只有18%，應(yīng)該可以被提升至30%(需要詳細(xì)數(shù)據(jù)支持)。
還能嘗試什么方法來提高轉(zhuǎn)化率，是否還值得繼續(xù)投入呢?需要先看一下以往的用戶反饋總結(jié)和用戶調(diào)研結(jié)果。
2. 目標(biāo)
證明在線客服是有用的。如果測(cè)試結(jié)果不理想也別抓狂，失之我命。
最好能在十二月初確定結(jié)論，這樣就可以申請(qǐng) Q1 的人力支持。
3. 聊天服務(wù)提供商
從最有名的幾個(gè)中挑一個(gè)出來：Olark，SnapEngage 等等
這些服務(wù)的界面長得怎么樣，可以以及必須自定義多少界面元素?
需要可以讓客服團(tuán)隊(duì)不改一行代碼，就能夠設(shè)置他們的在線時(shí)間及虛擬形象。
集成服務(wù)的成本是怎樣的?僅僅加一段 JavaScript 代碼就可以，還是……?
我們可以從服務(wù)提供商獲得多少數(shù)據(jù)報(bào)告?如果是我們自己做數(shù)據(jù)分析的話需要做什么準(zhǔn)備?
可以在聊天服務(wù)中加入一些自定義的變量來幫助我們分析數(shù)據(jù)么?例如 用戶 ID?
是否可以先不管現(xiàn)有 Zendesk 中現(xiàn)有工單的遷移?
4. 如何衡量成功
需要衡量：一個(gè)聊天客服的成本，一個(gè)客服可以完成多少次在線聊天，以及這些聊天可以帶來多少新的轉(zhuǎn)化。
如果項(xiàng)目結(jié)束后拿不到這些數(shù)據(jù)，這個(gè)測(cè)試就白做了。
一定要從客服主管和財(cái)務(wù)人員那里盡早獲得反饋。
5. 推進(jìn)測(cè)試
需要對(duì)多少流量進(jìn)行測(cè)試?應(yīng)該通過這幾個(gè)指標(biāo)計(jì)算得出：點(diǎn)擊聊天的用戶數(shù)，單個(gè)聊天的平均耗時(shí)，同時(shí)進(jìn)行的聊天并發(fā)數(shù)，平均等待時(shí)長等等
這個(gè)數(shù)據(jù)倒是可以算出來，但是考慮到現(xiàn)在只有一堆假設(shè)沒有任何數(shù)據(jù)，并不值得真正去算。
所以我們拍腦袋先定 20% 的流量用于測(cè)試，然后根據(jù)實(shí)際情況進(jìn)行調(diào)整吧。
這個(gè)測(cè)試需要多少天呢?是否需要考慮季節(jié)性的流量波動(dòng)?
6. 需要什么樣的數(shù)據(jù)報(bào)告?
我想了解測(cè)試組和對(duì)照組的轉(zhuǎn)化率，營收，以及訂單總量。
以及此次測(cè)試實(shí)際影響到的人數(shù)(開啟聊天的人數(shù))。
7. 還有什么?
是否考慮國際化的問題?我覺得現(xiàn)在還是先不考慮比較好。
移動(dòng)設(shè)備?你懂的，現(xiàn)在30%的交易量都來自于移動(dòng)端.
網(wǎng)頁加載時(shí)間?務(wù)必保證聊天窗口不要拖慢整個(gè)網(wǎng)頁的加載速度!
↑↑↑以上是思路筆記示例部分↑↑↑
2. 產(chǎn)品文檔示例
只有和團(tuán)隊(duì)一起評(píng)審了你的假設(shè)和創(chuàng)意之后(無論是在專門召集的會(huì)議上，喝咖啡時(shí)，或者桌上足球的休息時(shí)間)，你才應(yīng)該真正開始寫產(chǎn)品文檔。如果已經(jīng)完成了溝通和評(píng)審，整個(gè)文檔應(yīng)該花費(fèi)你 1-3 個(gè)小時(shí)的時(shí)間。
↓↓↓以下是產(chǎn)品文檔示例部分↓↓↓
灰色引用部分是注釋。
第一次閱讀此文檔時(shí)建議先忽略注釋部分通讀此文，然后再回到文初重新閱讀所有內(nèi)容。
文中提到的所有超鏈接并沒有鏈接到任何地方。這篇文章中的外鏈就只是表明有一些待辦事項(xiàng)和相關(guān)文檔。
在支付時(shí)增加在線客服
由 Gaurav Oberoi 撰寫
最后更新日期：2016年9月28日
這個(gè)項(xiàng)目的目標(biāo)是通過在支付頁面增加在線對(duì)話客服來提高支付轉(zhuǎn)化率。這是一個(gè)為期 30 天的測(cè)試，測(cè)試完成后我們可能會(huì)上線或者關(guān)掉這個(gè)功能(薛定諤的客服?蛤蛤)。
用不超過兩行文字描述此項(xiàng)目。我所說的“行”是指你的客戶端的默認(rèn)閱讀寬度(例如 Google Docs、維基、文本文件等)。堅(jiān)持字?jǐn)?shù)限制是可讀性的關(guān)鍵所在。
I. 概覽
A. 問題
1. 支付轉(zhuǎn)化率過低：只有 18% 的點(diǎn)擊了「預(yù)訂」按鈕的用戶完成了支付。競(jìng)品預(yù)訂網(wǎng)站可以達(dá)到約 30% 的轉(zhuǎn)化率(數(shù)據(jù)來源)。我們正在失去收入!
2. 沒有明確的流失原因：之前的工單和用戶調(diào)查給出了一系列非常多可能的原因(易用性、支付費(fèi)用、支付耗時(shí)方面的問題)，也沒有明確的分類。
3. 增加幫助文檔的內(nèi)容并沒有起到作用：上個(gè)季度，我們對(duì)幫助文檔和預(yù)定信息的內(nèi)容及界面設(shè)計(jì)做了 A/B 測(cè)試。這只帶來了 1.5% 的轉(zhuǎn)化率輕微提升。
我強(qiáng)烈建議使用列表來增強(qiáng)文檔的可讀性。
使用粗體文字快捷指出每行文字的要點(diǎn)，并且限制列表在兩三行以內(nèi)。
我更喜歡有序列表，因?yàn)檫@樣在口頭溝通時(shí)很容易指示清楚。
B. 目標(biāo)
1. 測(cè)試客服聊天是否可以明顯地提高轉(zhuǎn)化率：每天新增超過 90 個(gè)訂單就能打平在線客服的運(yùn)營成本，現(xiàn)在還不清楚是否能做到這一點(diǎn)。這是一次測(cè)試!
2. 降低測(cè)試成本：避免所有的過度優(yōu)化，如果測(cè)試成功，在 Q1 我們就可以優(yōu)化在線聊天的體驗(yàn)了。
3. 在 12 月 1 日前確定最終的結(jié)果：在開始做 Q1 計(jì)劃前，我們還有 8 周時(shí)間。
確保文檔可以提出一個(gè)明確的目標(biāo)，這個(gè)目標(biāo)應(yīng)當(dāng)是非常容易判斷“達(dá)成目標(biāo)了么?”的。
在文檔中做出明確的承諾。
C. 不應(yīng)考慮的問題
1. 重要的界面修改：只增加一個(gè)可見的聊天按鈕，不做任何其他的設(shè)計(jì)改動(dòng)。
2. 確定聊天服務(wù)供應(yīng)商：目前而言先使用 SnapEngage，如果測(cè)試成功了，再考慮長期的服務(wù)供應(yīng)商。
3. 國際化和非英語用戶：為了簡(jiǎn)化處理，此次測(cè)試僅針對(duì)美國地區(qū)及其他英語用戶。
這部分用來排除種種不利的假設(shè)，樹立正確的項(xiàng)目預(yù)期。
D. 團(tuán)隊(duì)成員和角色劃分
1. Heather(用戶運(yùn)營經(jīng)理)：批準(zhǔn)客服資源需求。
2. Randy(用戶運(yùn)營專員)：負(fù)責(zé)處理用戶反饋，每周整理反饋總結(jié)。
3. Colin(工程師)：開發(fā)和測(cè)試。也要負(fù)責(zé)配置SnapEngage，并且給我們展示一下設(shè)置方法。
4. Kalpana(財(cái)務(wù))：在測(cè)試階段以及后續(xù)時(shí)間負(fù)責(zé)評(píng)審我的盈利預(yù)算。
5. Joha(設(shè)計(jì)師)：花一點(diǎn)時(shí)間看一下我們?cè)谠O(shè)計(jì)上的改動(dòng)，沒有大塊的設(shè)計(jì)需求。
6. Vikram(數(shù)據(jù)分析師)：確保我們能按時(shí)拿到此次測(cè)試的數(shù)據(jù)報(bào)告。
幫助大家明確項(xiàng)目成員及對(duì)每一個(gè)人的期望。
僅包括將會(huì)執(zhí)行這件事情的人，和對(duì)這件事情有通過/否決權(quán)力的人。
II. 背景
這里應(yīng)當(dāng)包含了解當(dāng)前問題以及解決方案所需要的所有背景信息。
添加任何你認(rèn)為應(yīng)該出現(xiàn)在這里的內(nèi)容，例如：用例、用戶模型、數(shù)據(jù)指標(biāo)、競(jìng)品解決方案、調(diào)研結(jié)果等等。
A. 用例
1. 用戶需求：
在 2 分鐘內(nèi)獲得幫助：不確定是否可以實(shí)現(xiàn)，但是我們先沖著這個(gè)目標(biāo)去努力吧。
適配移動(dòng)端及桌面端：有 28% 的支付是在手機(jī)上完成的，所以移動(dòng)端適配很重要。
2. 用戶運(yùn)營團(tuán)隊(duì)需求：
有反饋隊(duì)列的客服后臺(tái)：在桌面/web 端就可以，不需要支持移動(dòng)端
增刪客服人員：可自助完成，而不需要開發(fā)人員支持
設(shè)置在線時(shí)間：可以控制網(wǎng)站上的在線聊天按鈕是否可見。
查看用戶信息：需要傳遞用戶 ID 的參數(shù)給后臺(tái)，方便客服人員查找當(dāng)前用戶信息。
給會(huì)話打標(biāo)簽：在聊天結(jié)束后，可以在注釋字段中記錄一些非結(jié)構(gòu)化的文本信息。
B. 假設(shè)
1. 每天增加90個(gè)付費(fèi)訂單，可以打平一個(gè)客服人員的運(yùn)營成本：根據(jù)每個(gè)客服人員的成本以及一個(gè)支付用戶的 LTV(生命周期價(jià)值)。詳見表格。
2. 一個(gè)客服人力可以支持 20% 的支付流量：基于對(duì)等待時(shí)間、聊天時(shí)長、并發(fā)聊天數(shù)量的一系列假設(shè)。我們沒有數(shù)據(jù)能支持做出靠譜的假設(shè)，所以拍腦袋定一個(gè)數(shù)據(jù)，并且需要我們的系統(tǒng)支持快速增加/降低測(cè)試流量。
3. 支付轉(zhuǎn)化率應(yīng)該從18%增加到20%：總轉(zhuǎn)換率不需要增加特別多就已經(jīng)意味著測(cè)試成功了。在這里查看我們的分析報(bào)告。
III. 解決計(jì)劃
用你能做到的最自然的方式描述你的計(jì)劃。
需要做到清晰、條理清楚、合理分段。
根據(jù)不同項(xiàng)目的特點(diǎn)，你也可以加入：線框圖，用戶流程圖，表單輸入/驗(yàn)證邏輯，數(shù)據(jù)模型……等執(zhí)行該計(jì)劃所需要的所有細(xì)節(jié)。
A. 在線客服提供商
我選擇了SnapEngage，符合我們的既定用例并且價(jià)格便宜($60/月)。注：如果測(cè)試成功，我們會(huì)再選擇適當(dāng)?shù)墓?yīng)商。我已經(jīng)注冊(cè)了一個(gè)付費(fèi)賬戶，帳號(hào)密碼在我們的密碼管理工具中。
B. 用戶體驗(yàn)
通過 SnapEngage 的文檔來弄清楚他們這個(gè)聊天窗口的彈出邏輯。有以下幾點(diǎn)：
1. 按鈕：設(shè)置為“立即聊天”的文案，并且放在詳情頁中“預(yù)訂”主按鈕的旁邊;
2. 交互：點(diǎn)擊時(shí)展示客服姓名，以及“您需要什么幫助?”的文案;
3. 所有的支付頁面：它應(yīng)該在所有的三個(gè)付款步驟頁面上都展示;
4. 不自動(dòng)彈出：我們可以以后再試這個(gè)效果，現(xiàn)在先低調(diào)上線測(cè)試。
C. 會(huì)話參數(shù)
1. 這是什么：當(dāng)我們嵌入服務(wù)供應(yīng)商的 Javascript 時(shí)，我們可以傳入特定的參數(shù)。這些參數(shù)客服可以看得到，并且也會(huì)記錄在日志和數(shù)據(jù)報(bào)告里。
2. 傳輸這些參數(shù)：用戶 ID，用戶郵箱，瀏覽器信息，預(yù)訂 ID，預(yù)訂訂單價(jià)格。
D. 測(cè)試流量開關(guān)
只會(huì)有部分支付流量看到在線客服功能。下面是我們需要做的工作：
1. 只展示給 X%的用戶：我們必須能夠在不重新部署的情況下就可以修改 X 的值，但是可以每次修改時(shí)都由用戶運(yùn)營團(tuán)隊(duì)向工程師提交一個(gè)工單來人工修改(例如，將這個(gè)值存儲(chǔ)在我們的數(shù)據(jù)庫/Redis 中)。
2. 對(duì)展示過的用戶始終可見：只要用戶看到過一次這個(gè)聊天窗口，在測(cè)試期間此用戶就應(yīng)該始終可以看到這個(gè)功能?？梢酝ㄟ^ cookie 來存儲(chǔ)這個(gè)狀態(tài)，也可以用這批用戶的用戶 ID 來記錄(例如：如果用戶 ID 對(duì) 100 取模小于 X，就可以看到此功能)。
3. 流量遞增方案：第一天，我們只開放 5% 的流量用于測(cè)試，如果用戶運(yùn)營團(tuán)隊(duì)反饋正常，則在第二天開放至 10% 的流量，第三天開放至 20%。
E. 數(shù)據(jù)指標(biāo)和報(bào)告
1. 日志記錄：在現(xiàn)有的指標(biāo)當(dāng)中增加：”live_checkout=true/false”。
2. 新的數(shù)據(jù)報(bào)告：
對(duì)比有在線客服的用戶(測(cè)試組)和沒有在線客服的用戶(對(duì)照組)的支付轉(zhuǎn)化率。
在線客服所帶來的總訂單數(shù)和收入。
測(cè)試用戶中有多少人點(diǎn)擊了在線聊天窗口。
3. SnapEngage 的數(shù)據(jù)報(bào)告：可以告訴我們平均會(huì)話耗時(shí)，以及并發(fā)會(huì)話數(shù)等數(shù)據(jù)
上面我舉的例子可能晦澀難懂，但是我們團(tuán)隊(duì)中的工程師和數(shù)據(jù)分析師則會(huì)很容易理解——因?yàn)樗麄冋沁@部分文檔的受眾。
記?。簩懴滤行枰四X執(zhí)行的必要事項(xiàng)。
F. 未來計(jì)劃
1. 如果我們發(fā)現(xiàn)在線聊天的使用率很低：我們需要嘗試一些優(yōu)化方案，例如：a. 自動(dòng)彈出聊天窗口，b. 修改聊天按鈕樣式，c. 在聊天按鈕旁邊增加客服人員照片。
2. 如果測(cè)試驗(yàn)證成功：我們會(huì)爭(zhēng)取更多的客服人力，并且在 Q1 進(jìn)行大規(guī)模迭代改進(jìn)，包括選擇合適的供應(yīng)商，更深入的數(shù)據(jù)分析，以及正式的客服話術(shù)培訓(xùn)。
指明項(xiàng)目的未來發(fā)展方向永遠(yuǎn)都是好事，因?yàn)檫@樣可以引導(dǎo)人們更長遠(yuǎn)地去思考。
IV. 任務(wù)和排期表
考慮到在「未來計(jì)劃」中提到的問題，這個(gè)排期表可能會(huì)有一到兩周的延期。只要我們能夠在 12 月 1 日得到測(cè)試結(jié)果，我們就在 Q1 人力資源規(guī)劃時(shí)爭(zhēng)取到更多的人力。
1. 10 月 4 日：文檔評(píng)審。
2. 10 月 8 日：和客服團(tuán)隊(duì)一起在開發(fā)環(huán)境中測(cè)試如何設(shè)置客服人員以及客服時(shí)間。
3. 10 月 11 日：上線。我們會(huì)在接下來的數(shù)天中逐步增加測(cè)試流量。
4. 10 月 17 日：在上線1周后同步信息。在此時(shí)我們可能會(huì)有一些額外的工作要做。
5. 11 月 12 日：最后一次溝通，評(píng)審當(dāng)下狀態(tài)以決定繼續(xù)推進(jìn)還是結(jié)束此項(xiàng)目。
6. 12 月 1 日：這是完成此項(xiàng)目并且得到測(cè)試結(jié)果的最終截止日。
開始的時(shí)候排期表可以只有一個(gè)大致的估期，通過更多的分析來逐步精確時(shí)間點(diǎn)(例如需要技術(shù)文檔)。
但是盡早嘗試拆解和確定時(shí)間點(diǎn)，大致框定每項(xiàng)工作的范圍和規(guī)模仍然是非常重要的。
工期估算應(yīng)當(dāng)來自于執(zhí)行方(開發(fā)，設(shè)計(jì)等)。
↑↑↑以上是產(chǎn)品文檔示例部分↑↑↑
啊哈!有了文檔之后是不是就感覺踏實(shí)多了?寫文檔看起來是額外的工作成本，但是其實(shí)并不是，高效的文檔可以幫助你和你的團(tuán)隊(duì)節(jié)約時(shí)間投入，并且在交付上線時(shí)會(huì)更有信心。
等等——你已經(jīng)讀完示例文檔了么?請(qǐng)務(wù)必先讀完它，再繼續(xù)閱讀下面的文章。
產(chǎn)品文檔寫作指南
我通過示例文檔詮釋了這篇文章中所講述的思考，在繼續(xù)閱讀下文之前，請(qǐng)務(wù)必確認(rèn)你已經(jīng)閱讀了上面的文檔示范。
為什么要寫產(chǎn)品文檔?
一言以蔽之：為了以更高的質(zhì)量、更快的速度和更佳的預(yù)判來交付正確的產(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)品，以及「為什么」要這么做。用來說明清楚一個(gè)產(chǎn)品的表達(dá)方式很多，但最核心的，一定要說清楚這五件事情：
1. 問題
描繪你此次打算解決的問題。更重要的是，解釋為什么要去解決這個(gè)問題。描述要盡可能地具體，并且提供相關(guān)的數(shù)據(jù)指標(biāo)。
2. 可衡量的目標(biāo)
明確承諾交付和成果，明確哪些事情超出了此項(xiàng)目的范疇。每一個(gè)目標(biāo)，都應(yīng)該可以明確衡量「是否達(dá)到目標(biāo)」。
3. 需求背景
提供你的觀眾理解當(dāng)前問題以及接受你的提議所需的所有背景信息。包括但不限于假設(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)品文檔寫作流程：
接下來我會(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è)步驟的目的是過一遍文檔中的細(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é)等待著梳理清楚。于是接下來需要將所有這些細(xì)節(jié)都整理出來，并且逐一梳理斟酌。
在完成第一版文檔之后，需要繼續(xù)大篇幅編輯修改，通常最終的文檔可以在你的第一版草稿的基礎(chǔ)上壓縮 30%-50% 的長度，簡(jiǎn)潔和清晰的文檔就意味著更加容易閱讀。
大部分文檔都可以在半天到一天的時(shí)間里完成，不過實(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ì)這件事情有通過/否決權(quán)力的人。
5. 評(píng)審文檔(1小時(shí))
在開始會(huì)議之前，詢問是否有參會(huì)者沒有詳細(xì)閱讀你的文檔。通常都會(huì)有一兩個(gè)人中槍，在這種情況下可以說：“沒問題，我們先用 10 分鐘一起來看一下文檔。已經(jīng)讀過文檔的人可以利用這個(gè)時(shí)間先放松休息一下。”
這次會(huì)議上你需要獲得利益相關(guān)方的同意，并且獲得執(zhí)行方(工程師、支持團(tuán)隊(duì)等)的知曉、認(rèn)可以及人力支持。
你可能需要開多次評(píng)審會(huì)議，并且根據(jù)評(píng)審會(huì)議上溝通的信息不斷修改文檔。
6. 通過評(píng)審后，及時(shí)同步信息和建立工單(1-2小時(shí))
會(huì)后同步信息的電子郵件需要包含更新后的產(chǎn)品文檔鏈接，和此項(xiàng)目相關(guān)的工單鏈接(例如在頁面上添加 JavaScript 代碼，完成數(shù)據(jù)分析報(bào)告，測(cè)試 Staging 環(huán)境，和支持團(tuán)隊(duì)預(yù)演流程，等等)。
一般接下來將會(huì)有一位工程師完成技術(shù)文檔，不過并不總是這樣(文中的示例項(xiàng)目就不需要這一步)。
產(chǎn)品文檔進(jìn)階技巧：
1. 盡量簡(jiǎn)短
沒有比這更重要的文檔寫作建議了。簡(jiǎn)潔意味著清晰的思路和溝通，也意味著你的文檔更加易于閱讀和理解——這一點(diǎn)至關(guān)重要。
2. 使用平白的語言和簡(jiǎn)單的格式
使用簡(jiǎn)短而不是花哨的語句，使用列表和加粗強(qiáng)調(diào)可以使文章更一目了然，以放松有趣的方式寫作而不是一板一眼，如果你有得體的幽默感就再好不過了。
3. 為開發(fā)團(tuán)隊(duì)預(yù)留時(shí)間
通過評(píng)審并且達(dá)成一致通過的文檔才是完善的文檔。如果你希望在未來的某一個(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)真考慮過項(xiàng)目進(jìn)入開發(fā)的所有必要條件，你就可以提前發(fā)現(xiàn)這些問題(例如，是否在移動(dòng)設(shè)備中可以使用在線聊天功能?)。
5. 確保每一個(gè)人都跟上了你的節(jié)奏
當(dāng)我組織產(chǎn)品評(píng)審時(shí)，會(huì)議室里的大部分人都已經(jīng)大致了解我要講的內(nèi)容——因?yàn)槲乙呀?jīng)提前在討論會(huì)和日常聊天中溝通過這個(gè)事情了。既然大家都已經(jīng)清楚了「做什么」和「為什么要做」的問題，文檔評(píng)審會(huì)上我們只要關(guān)注實(shí)施細(xì)節(jié)就好了。
6. 在圖表中下功夫
流程圖、線框圖等圖表可以通過易于理解的方式提供很大的信息量，同時(shí)也需要消耗非常多的時(shí)間來制作這些圖表。
7. 在思考和寫文檔上花 0.5-3 天時(shí)間
具體時(shí)間根據(jù)項(xiàng)目大小而定。花費(fèi)在寫文檔上的時(shí)間越長，所帶來的邊際收益就會(huì)遞減。特別需要指出的是，沒有人能夠讀的下去超過 5-6 頁的文檔。
8. 指明方向，明晰愿景
你不僅僅是在定義一個(gè)功能，也是在解釋「為什么我們要做這件事情」以及「我們的目標(biāo)是什么」，在文檔中指出這個(gè)項(xiàng)目將會(huì)對(duì)更高層面的規(guī)劃造成什么影響，以及接下來會(huì)發(fā)生什么。
9. 確保你的觀眾閱讀了文檔
如果你的文檔又臭又長，或者從來不分享給對(duì)應(yīng)的人，那你還不如不寫文檔。務(wù)必確保你的文檔被對(duì)應(yīng)的人閱讀了，我上面關(guān)于評(píng)審開始時(shí)留時(shí)間給大家讀文檔的建議值得大家參考。
10. 獲取真誠的反饋
你的文檔是否是在贅述人盡皆知的事情?或者是文檔缺乏足夠的細(xì)節(jié)?是否在后續(xù)實(shí)施中發(fā)現(xiàn)了太多的邊緣情況?又或者，是否在制定計(jì)劃和文檔評(píng)審上耗費(fèi)了太多的時(shí)間?你應(yīng)該和你的團(tuán)隊(duì)時(shí)刻保持溝通。
產(chǎn)品文檔與敏捷開發(fā)矛盾嗎?
我知道會(huì)有爭(zhēng)議，但是產(chǎn)品文檔和敏捷開發(fā)的原則沒有絲毫沖突，并且在類似于 Scrum 這樣的敏捷方法上得到了充分發(fā)揮。
畢竟，用戶故事許多時(shí)候需要詳盡的描述，文檔可以增加溝通中的清晰度和可傳播性，為什么非要刻板地認(rèn)為僅僅使用口頭溝通和使用白板才算是敏捷開發(fā)呢?
“產(chǎn)品文檔會(huì)導(dǎo)致發(fā)布變慢，過度規(guī)劃，通常會(huì)浪費(fèi)時(shí)間?！边@樣的想法完全是無稽之談。
我工作過的多個(gè)世界級(jí)團(tuán)隊(duì)遵循著一些敏捷原則(例如兩周一個(gè)迭代周期)，每天(甚至更頻繁地)發(fā)布代碼，并且以發(fā)布產(chǎn)品(而不是文檔或者會(huì)議)作為衡量成功的標(biāo)準(zhǔn)——這些團(tuán)隊(duì)也都仍然認(rèn)為文檔是他們打造成功軟件的一個(gè)關(guān)鍵部分。
產(chǎn)品文檔與技術(shù)文檔有何區(qū)別?
產(chǎn)品文檔通常關(guān)注做什么 ，而技術(shù)文檔更多關(guān)注在如何做 。這兩種文檔為研發(fā)流程中的不同環(huán)節(jié)帶來同樣的清晰視角，并且都使得工程師(和他們的用戶)身心愉悅。
