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