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

　　1. 从一开始就理性思考

　　在团队开始付出更高成本去设计软件架构、实施代码开发、完善界面设计、测试软件质量之前，写文档可以迫使你提前思考每一个细节。这将会提高你决策的质量，降低意外事件发生的概率。

　　2. 高效沟通

　　你常常需要和不同的利益相关方（支持团队，工程团队，设计团队，财务团队，管理层等等）沟通你的方案。产品文档可以帮助你事半功倍地完成沟通，避免口头沟通中产生的歧义，atv，团队中的所有人可以更好地理解你的意图，并且更有的放矢地做出答复。

　　3. 明确权责

　　明确项目目标的评价标准，公开承诺奖惩激励机制：利益相关方可以知晓如果最后一刻变更需求会意味着什么，工程师们也会在预估工期时再三斟酌。

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

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

　　1. 问题

　　描绘你此次打算解决的问题。更重要的是，解释为什么要去解决这个问题。描述要尽可能地具体，并且提供相关的数据指标。

　　2. 可衡量的目标

　　明确承诺交付和成果，明确哪些事情超出了此项目的范畴。每一个目标，都应该可以明确衡量「是否达到目标」。

　　3. 需求背景

　　提供你的观众理解当前问题以及接受你的提议所需的所有背景信息。包括但不限于假设、用例、数据指标等信息。

　　4. 解决方案详情

　　你的提议应该有充足的细节，易于团队成员消化理解及执行——可以把这部分内容想象成对人脑进行编程和执行。

　　5. 时间轴

　　列出你的团队共同认可的截止日期和其他重要时间点。这部分内容开始的时候可能会比较模糊，但是在最后一次文档评审之前应当完全敲定。

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

　　产品文档写作流程：

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

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

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

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

　　这个步骤的目的是过一遍文档中的细节，优化你的方案，并且获得更多人的支持。尽可能控制这些会议的规模，人越少越好（理想状态下都应该是一对一会议）。例如，在本文的示例中，我会和客服部门的负责人，一个财务人员和一个工程师分别安排一次会议。

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

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

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

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

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