写在前面的话：

　　产品经理在一家互联网公司往往掌管着所有的需求，需要沟通的对象也包括了设计、开发、测试、运营等角色。所以，一名产品经理需要处理和面对的信息量常常是巨大的，也因此往往会面临到沟通低效、产品开发进度和质量不可控等等问题。

　　这时候，最好的解决方案，其实是一份清晰高效的产品文档。可惜，大部分产品经理对于“文档”的价值和意义认知都是不够的。

　　在本文中，作者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 这样的敏捷方法上得到了充分发挥。

　　毕竟，用户故事许多时候需要详尽的描述，文档可以增加沟通中的清晰度和可传播性，为什么非要刻板地认为仅仅使用口头沟通和使用白板才算是敏捷开发呢?

　　“产品文档会导致发布变慢，过度规划，通常会浪费时间。”这样的想法完全是无稽之谈。

　　我工作过的多个世界级团队遵循着一些敏捷原则(例如两周一个迭代周期)，每天(甚至更频繁地)发布代码，并且以发布产品(而不是文档或者会议)作为衡量成功的标准——这些团队也都仍然认为文档是他们打造成功软件的一个关键部分。

　　产品文档与技术文档有何区别?

　　产品文档通常关注做什么 ，而技术文档更多关注在如何做 。这两种文档为研发流程中的不同环节带来同样的清晰视角，并且都使得工程师(和他们的用户)身心愉悦。