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