Gaurav Oberoi 是 SurveyMonkey 的联合创始人（现已离任），曾于 Amazon、Xmarks 先后从事工程师、产品经理等职位，在西雅图和硅谷有十余年的工作经验。在这篇文章中他分享了他对于产品文档的看法以及撰写产品文档的常用流程。
产品文档撰写指南
很多人听到「产品文档」这四个字就像吞了苍蝇一样，人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累，怎么可能「敏捷」得起来，怎么可能高效地产出代码？
我在过去十几年创造了多个数百万人使用的软件产品之后，越发认为这种观点是完全错误的。根据我的经验：
高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成部分。
撰写产品文档可以强制所有人从项目初始就理性思考，频繁沟通，明确权责——所有的这些都会带来更好的软件质量，更低的进度风险，以及更少的时间浪费。
在这篇文章中，我会通过一个案例来分享一些普适的建议，这些建议会对大中型（超过二百人的）公司中的产品经理们非常有帮助。
首先，举个例子
假设你在这里工作：
一家从事在线旅游预订服务 （就像 Hotels 或者 Airbnb 但是规模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个季度大家打算尝试通过在支付环节加入在线客服 的方案来提升转化。
你的工单/用户故事/路线图是：
通过在支付环节增加在线客服来尝试提高支付转化率。
在你没有产品文档时，你会这样做：
比方说，你觉得行动起来总是最重要的，因此直接开始动手：
在迭代计划会上，你和团队讨论了这个需求。
然后你挑选了一个靠谱的第三方客服供应商（例如 SnapEngage ）。
提交一个工单来让工程师添加一些 Javascript 代码。
和支持团队开个会，确定他们都准备好了
搞定了！这么简单的事情怎么能要我们写产品文档呢？如果你是在一个小型创业团队，你也确实并不需要——因为产品改动相对小，涉及到的人也相对更少。
但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会陆续出现下列这些问题，并且相比写文档，这些问题会需要更多时间来处理。例如：
工程师把工单标记完成了，但是一验收测试，就发现这个功能完全没有考虑移动端的适配。
「唉呀！你忘了提醒大家手机端的使用才是核心场景。」
用户运营经理打算开展一个漫长的评审流程，以确定最合适的聊天服务商。
「啊……需要定一个会议，向大家解释下这次上线只是一个灰度测试。」
发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。
「啥？要追加一个紧急发布，把这个测试限定在英语用户中。」
一个设计师花了几天，为聊天窗口滑入屏幕的交互绘制了一个完美的动画。
「用户体验过度优化，你是否对整个团队统一了「这次只是一个测试」的预期？」
一周的测试完成之后，数据分析师发现无法产出你要的报告，因为相关的必要指标并没有埋点。
如果这是一个相对简单的项目，即使没有产品文档可能也不至于陷入这样的灾难之中。但是在简单的项目中你仍然有可能会因为没有文档浪费许多时间和机会成本。
如果你写了一篇文档：
为了便于说明，我准备了两个示例文档：一篇思路笔记，和一篇完整的产品文档示例——这样可以完整介绍产品文档的撰写流程。
请在继续阅读文章之前，花几分钟读一下这两篇示例文档吧。
阅读示例思路笔记。 （阅读时间 2 分钟） 阅读示例文档。 （阅读时间 6 分钟）
等等！——你已经读完示例文档了么？请务必先读完它再继续阅读下面的文章。
文档撰写指南
我通过示例文档诠释了这篇文章中所讲述的思考，在继续阅读全文之前，请务必确认你已经阅读了示例文档 。
为什么要写产品文档？
为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。
是的，就是这样。那么，产品文档将如何帮助你做到这一切呢？Ben Horowitz 分享了上图中这个看法，我的示例文档也是一个很好的例证。明确一下要点：
从一开始就理性思考 高效沟通 明确权责
产品文档中应当包含哪些内容？
产品文档应该明确沟通要做一个「什么」产品，以及「为什么」要这么做。用来说明清楚一个产品的表达方式很多，但最核心的，一定要说清楚这五件事情：
问题 可衡量的目标 需求背景 解决方案详情 时间轴
你可以使用我的示例文档做你的文档模板，按照你的想法增/删/改任何章节。只要你能够清晰并且条理清楚地表述上面提到的这五点信息，文档形式并不重要。
如何写产品文档？
接下来我会介绍我撰写和评审文档的常规流程。根据项目大小，利益相关方的数量不同等情况，流程细节可能会有所变化，但是大体的流程是确定的。
快速完成一个草稿（1-2 个小时） 思路笔记示例 ）。安排几个 30 分钟的一对一会议 （1-4 个小时） 撰写和编辑文档 （0.5-3 天） 群发文档并且安排一个 1 小时的评审会议（15 分钟） 评审文档（1小时） 通过评审后，及时同步信息和建立工单 （1-2 小时）
写出高效产品文档的进阶技巧
尽量简短 使用平白的语言和简单的格式 为开发团队预留时间 像工程师一样思考 确保每一个人都跟上了你的节奏 在图表中下功夫 在思考和写文档上花 0.5-3 天时间 指明方向，明晰愿景 确保你的观众阅读了文档 获取真诚的反馈
说好的敏捷开发（Agile/Scrum）呢？
我知道会有争议，但是产品文档和敏捷宣言的原则 没有丝毫冲突，并且在类似于 Scrum 这样的敏捷方法上得到了充分发挥。
毕竟，用户故事（Story）许多时候需要详尽的描述，文档可以增加沟通中的清晰度和可传播性，为什么非要刻板地认为仅仅使用口头沟通和使用白板才算是敏捷开发呢？
「产品文档会导致发布变慢，过度规划，通常会浪费时间」的想法完全是无稽之谈。
我工作过的多个世界级团队遵循着一些敏捷原则（例如两周一个迭代周期），每天（甚至更频繁地）发布代码，并且以发布产品（而不是文档或者会议）作为衡量成功的标准——这些团队也都仍然认为文档是他们打造成功软件的一个关键部分。
你对技术文档怎么看？
我是一个技术文档的支持者。产品文档通常关注 做什么 ，而技术文档更多关注在如何做 。这两种文档为研发流程中的不同环节带来同样的清晰视角，并且都使得工程师（和他们的用户）身心愉悦。
未来如果大家有兴趣的话我可能会写一篇关于技术文档的文章。
总结
感谢你读到这里。如果你认为这篇文章有用，请分享给其他人——特别是你的产品/工程团队。
如果你想看更多的产品经理内容（例如：规划产品路线图），或者想了解其他人如何使用产品文档， 请用两分钟填写这个小调查（英文） 。我会在未来的文章中分享调查结果中有意思的信息。
以上，祝写文档愉快！
备注：
1. 感谢周思博 （Joel Spolsky） （微软早期 PM，曾参与创办 Stack Overflow，Trello，FogBugz 等产品，《软件随想录》作者）的「文档是对人脑的编程」的比喻。早在2000年，他写了4 篇关于文档的系列文章（英文） ，这对我的 PM 道路产生了巨大的影响，强烈推荐。
2. 在顶部的引文中，贝索斯所说的笔记是指为高层管理会议使用的，介绍新业务/产品创意的备忘录。这实际上不算是产品文档，但是两者并不是完全不一样。贝索斯在会议开始的时候会组织所有人默读文件——这激发了我在文档评审时做同样的事情。来源
3. 感谢 iDoneThis 博客这篇关于写作的价值的文章（英文） 。这是贝索斯和 Horowitz 的引言的来源。
感谢 Vikram Oberoi 。
原文链接：https://goberoi.com/on-writing-product-specs-5ca697b992fd
原创翻译，转载请注明出处
