产品文档撰写指南：被你忽视的这些流程思维导图

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

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

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

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

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

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

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

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

Ben Horowitz

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

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

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

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

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

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

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

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

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

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

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

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

会后同步信息的电子邮件需要包含更新后的产品文档链接，和此项目相关的工单链接（例如「在页面上添加 JavaScript 代码」，「完成数据分析报告」，「测试 Staging 环境」，「和支持团队预演流程」，等等）。

一般接下来将会有一位工程师完成技术文档，不过并不总是这样（文中的示例项目就不需要这一步）。

没有比这更重要的文档写作建议了。简洁意味着清晰的思路和沟通，也意味着你的文档更加易于阅读和理解——这一点至关重要。

使用简短而不是花哨的语句，使用列表和加粗强调可以使文章更一目了然，以放松有趣的方式写作而不是一板一眼，如果你有得体的幽默感就再好不过了。

通过评审并且达成一致通过的文档才是完善的文档。如果你希望在未来的某一个迭代 Sprint 中开发此项目，就应该提前两到三周开始这个产品文档写作流程。

在项目得以进入开发之时，常常会发现大量未预料到的边缘情况——但这种情形其实可以避免。如果你认真考虑过项目进入开发的所有必要条件，你就可以提前发现这些问题（例如，是否在移动设备中可以使用在线聊天功能？）

当我组织产品评审时，会议室里的大部分人都已经大致了解我要讲的内容——因为我已经提前在讨论会和日常聊天中沟通过这个事情了。既然大家都已经清楚了「做什么」和「为什么要做」的问题，文档评审会上我们只要关注实施细节就好了。

流程图、线框图等图表可以通过易于理解的方式提供很大的信息量，同时也需要消耗非常多的时间来制作这些图表。

具体时间根据项目大小而定。花费在写文档上的时间越长，所带来的边际收益就会递减。特别需要指出的是，没有人能够读的下去超过 5-6 页的文档。

你不仅仅是在定义一个功能，也是在解释「为什么我们要做这件事情」以及「我们的目标是什么」，在文档中指出这个项目将会对更高层面的规划造成什么影响，以及接下来会发生什么。

如果你的文档又臭又长，或者从来不分享给对应的人，那你还不如不写文档。务必确保你的文档被对应的人阅读了，我上面关于评审开始时留时间给大家读文档的建议值得大家参考。

你的文档是否是在赘述人尽皆知的事情？或者是文档缺乏足够的细节？是否在后续实施中发现了太多的边缘情况？又或者，是否在制定计划和文档评审上耗费了太多的时间？你应该和你的团队时刻保持沟通。

我知道会有争议，但是产品文档和敏捷宣言的原则没有丝毫冲突，并且在类似于 Scrum 这样的敏捷方法上得到了充分发挥。

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

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

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

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