很多人听到「产品文档」这四个字就像吞了苍蝇一样，人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累，怎么可能「敏捷」得起来，怎么可能高效地产出代码？

我在过去十几年创造了多个数百万人使用的软件产品之后，越发认为这种观点是完全错误的。根据我的经验：

在这篇文章中，我会通过一个案例来分享一些普适的建议，这些建议会对大中型（超过二百人的）公司中的产品经理们非常有帮助。

首先，举个例子

假设你在这里工作：

一家从事在线旅游预订服务（就像 Hotels 或者 Airbnb 但是规模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个季度大家打算尝试通过在支付环节加入在线客服的方案来提升转化。

你的工单/用户故事/路线图是：

通过在支付环节增加在线客服来尝试提高支付转化率。支付转化率目前仅有 18％，而业内平均转化率有 30％。我们打算测试下在支付时展示在线客服聊天窗口是否可以提高这个转化率。用户运营团队已经同意了提供 1 人月的客服人力支持。

在你没有产品文档时，你会这样做：

比方说，你觉得行动起来总是最重要的，因此直接开始动手：

在迭代计划会上，你和团队讨论了这个需求。然后你挑选了一个靠谱的第三方客服供应商（例如SnapEngage）。提交一个工单来让工程师添加一些 Javascript 代码。和支持团队开个会，确定他们都准备好了

搞定了！这么简单的事情怎么能要我们写产品文档呢？如果你是在一个小型创业团队，你也确实并不需要——因为产品改动相对小，涉及到的人也相对更少。

但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会陆续出现下列这些问题，并且相比写文档，这些问题会需要更多时间来处理。

例如：

工程师把工单标记完成了，但是一验收测试，就发现这个功能完全没有考虑移动端的适配「唉呀！你忘了提醒大家手机端的使用才是核心场景」。用户运营经理打算开展一个漫长的评审流程，以确定最合适的聊天服务商「啊……需要定一个会议，向大家解释下这次上线只是一个灰度测试」。发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。「啥？要追加一个紧急发布，把这个测试限定在英语用户中」。一个设计师花了几天，为聊天窗口滑入屏幕的交互绘制了一个完美的动画「用户体验过度优化，你是否对整个团队统一了「这次只是一个测试」的预期？」。一周的测试完成之后，数据分析师发现无法产出你要的报告，因为相关的必要指标并没有埋点「史诗级的失败。从头再来吧」。

如果这是一个相对简单的项目，即使没有产品文档可能也不至于陷入这样的灾难之中。但是在简单的项目中你仍然有可能会因为没有文档浪费许多时间和机会成本。

如果你写了一篇文档

为了便于说明，我准备了两个示例文档：一篇思路笔记，和一篇完整的产品文档示例——这样可以完整介绍产品文档的撰写流程。

请在继续阅读文章之前，花几分钟读一下这两篇示例文档吧。

（1）阅读示例思路笔记（阅读时间 2 分钟）

这是一个根据你已知的信息和想要解答的问题所梳理成的列表。

这会是你需要做的第一件事情，大约需要一个小时来完成这个文档。这个文档会成为你和团队中其他人的一个沟通基础。

（2）阅读示例文档（阅读时间 6 分钟）

只有和团队一起评审了你的假设和创意之后（无论是在专门召集的会议上，喝咖啡时，或者桌上足球的休息时间），你才应该真正开始写产品文档。

如果已经完成了沟通和评审，整个文档应该花费你 1-3 个小时的时间。

啊哈！有了文档之后是不是就感觉踏实多了？写文档看起来是额外的工作成本，但是其实并不是，高效的文档可以帮助你和你的团队节约时间投入，并且在交付上线时会更有信心。

等等！——你已经读完示例文档了么？请务必先读完它再继续阅读下面的文章。

Ben Horowitz

文档撰写指南

我通过示例文档诠释了这篇文章中所讲述的思考，在继续阅读全文之前，请务必确认你已经阅读了示例文档。

为什么要写产品文档？

为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。

是的，就是这样。那么，产品文档将如何帮助你做到这一切呢？Ben Horowitz 分享了上图中这个看法，我的示例文档也是一个很好的例证。明确一下要点：

产品文档中应当包含哪些内容？

产品文档应该明确沟通要做一个「什么」产品，以及「为什么」要这么做。用来说明清楚一个产品的表达方式很多，但最核心的，一定要说清楚这五件事情：

问题：描绘你此次打算解决的问题。更重要的是，解释为什么要去解决这个问题。描述要尽可能地具体，并且提供相关的数据指标。可衡量的目标：明确承诺交付和成果旅游会展策划书格式范文，明确哪些事情超出了此项目的范畴。每一个目标，都应该可以明确衡量「是否达到目标」。需求背景：提供你的观众理解当前问题以及接受你的提议所需的所有背景信息。包括但不限于假设、用例、数据指标等信息。解决方案详情：你的提议应该有充足的细节，易于团队成员消化理解及执行——可以把这部分内容想象成对人脑进行编程和执行。时间轴：列出你的团队共同认可的截止日期和其他重要时间点。这部分内容开始的时候可能会比较模糊，但是在最后一次文档评审之前应当完全敲定。

你可以使用我的示例文档做你的文档模板，按照你的想法增/删/改任何章节。只要你能够清晰并且条理清楚地表述上面提到的这五点信息，文档形式并不重要。

如何写产品文档？

接下来我会介绍我撰写和评审文档的常规流程。根据项目大小，利益相关方的数量不同等情况，流程细节可能会有所变化，但是大体的流程是确定的。

（1）快速完成一个草稿（1-2 个小时）

关闭电子邮件和聊天工具。泡杯茶，坐在椅子上开始思考，然后逐一把你所了解的信息列成清单（见上文中的思路笔记示例）。

（2）安排几个 30 分钟的一对一会议（1-4 个小时）

这个步骤的目的是过一遍文档中的细节，优化你的方案，并且获得更多人的支持。尽可能控制这些会议的规模，人越少越好（理想状态下都应该是一对一会议）。

在本文的示例中，我会和客服部门的负责人，一个财务人员和一个工程师分别安排一次会议。

（3）撰写和编辑文档（0.5-3 天）

此时，你应该对能做，并且应该做什么有了一个明确的想法，但是大脑中塞满了大量的细节等待着梳理清楚。于是接下来需要将所有这些细节都整理出来旅游会展策划书格式范文，并且逐一梳理斟酌。

在完成第一版文档之后，需要继续大篇幅编辑修改，通常最终的文档可以在你的第一版草稿的基础上压缩 30%-50% 的长度，简洁和清晰的文档就意味着更加容易阅读。

大部分文档都可以在半天到一天的时间里完成，不过实际上也会有一些文档需要两三天才能写完。

（4）群发文档并且安排一个 1 小时的评审会议（15 分钟）

将文档群发给项目的所有利益相关方，并且抄送给其他可能对文档感兴趣的团队（例如你所在的产品团队，整个支持团队等）。

跟进这些关键人员是否接受了会议邀请：将会执行这件事情的人，和所有对这件事情有通过/否决权力的人。

（5）评审文档（1小时）

在开始会议之前，询问是否有参会者没有详细阅读你的文档。通常都会有一两个人中枪，在这种情况下可以说：「没问题，我们先用 10 分钟一起来看一下文档。已经读过文档的人可以利用这个时间先放松休息一下」。

这次会议上你需要获得利益相关方的同意，并且获得执行方（工程师、支持团队等）的知晓、认可以及人力支持。

你可能需要开多次评审会议，并且根据评审会议上沟通的信息不断修改文档。

（6）通过评审后，及时同步信息和建立工单（1-2 小时）

会后同步信息的电子邮件需要包含更新后的产品文档链接，和此项目相关的工单链接（例如「在页面上添加 JavaScript 代码」，「完成数据分析报告」，「测

来源【写作训练营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！