国外的产品经理怎么写需求文档

1、国外的产品经理怎么写需求文档很多人听到产品文档这四个字就像吞了苍蝇一样，人们通常会 认为这意味着又要花几周写一个根本没人看的文档。如果一个团队 总被产品文档这种事情拖累，怎么可能敏捷得起来，怎么可能 高效地产出代码？我在过去十几年创造了多个数百万人使用的软件产品之后，越发认 为这种观点是完全错误的。根据我的经验：高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成 局部。撰写产品文档可以强制所有人从工程初始就理性思考，频 繁沟通，明确权责一一所有的这些都会带来更好的软件质量，更 低的进度风险，以及更少的时间浪费。在这篇文章中，我会通过一个案例来提供一些普适的建议，这些建 议会对大中型（超过

2、二百人的）公司中的产品经理们非常有帮助。首先，举个例子,假设你在这里工作：一家从事在线旅游预订服务（就像Hotels或者Airbnb但是规 模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个 季度大家打算尝试通过在支付环节加入在线客服的方案来提升转 化。你的工单/用户故事/路线图是：通过在支付环节增加在线客服来尝试提高支付转化率。支付转化率 目前仅有18%,而业内平均转化率有30%。我们打算测试下在支 付时展示在线客服聊天窗口是否可以提高这个转化率。用户运营团 队已经同意了提供1人月的客服人力支持。在你没有产品文档时，你会这样做：比方说，你觉得行动起来总是最重要的，因此直接开始动手：.

3、在迭代计划会上，你和团队讨论了这个需求。.然后你挑选了一个靠谱的第三方客服供应商。.提交一个工单来让工程师添加一些Javascript代码。.和支持团队开个会，确定他们都准备好了搞定了！这么简单的事情怎么能要我们写产品文档呢？如果你是在 一个小型创业团队，你也确实并不需要因为产品改动相对小， 涉及到的人也相对更少。但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会 陆续出现以下这些问题，并且相比写文档，这些问题会需要更多时 间来处理。例如：工程师把工单标记完成了，但是一验收测试，就发现这个功能完全 没有考虑移动端的适配。唉呀！你忘了提醒大家手机端的使用才是核心场景。用户运营经理打算开

4、展一个漫长的评审流程，以确定最合适的聊天 服务商。啊需要定一个会议，向大家解释下这次上线只是一个灰度 测。J发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。啥？要追加一个紧急发布，把这个测试限定在英语用户中。一个设计师花了几天，为聊天窗口滑入屏幕的交互绘制了一个完美 的动画。用户体验过度优化，你是否对整个团队统一了这次只是一个测 试的预期？一周的测试完成之后，数据分析师发现无法产出你要的报告，因为 相关的必要指标并没有埋点。史诗级的失败。从头再来吧。如果这是一个相对简单的工程，即使没有产品文档可能也不至于陷 入这样的灾难之中。但是在简单的工程中你仍然有可能会因为没有 文档浪费许多时间

5、和机会本钱。如果你写了一篇文档：为了便于说明，我准备了两个例如文档：一篇思路笔记，和一篇完 整的产品文档例如这样可以完整介绍产品文档的撰写流程。请在继续阅读文章之前，花几分钟读一下这两篇例如文档吧。阅读例如思路笔记（阅读时间2分钟）这是一个根据你的信息和想要解答的问题所梳理成的列表。 这会是你需要做的第一件事情，大约需要一个小时来完成这个文 档。这个文档会成为你和团队中其他人的一个沟通基础。阅读例如产品文档（阅读时间6分钟）只有和团队一起评审了你的假设和创意之后（无论是在专门召集的 会议上，喝咖啡时，或者桌上足球的休息时间），你才应该真正开 始写产品文档。如果已经完成了沟通和评审，整个文档应该

6、花费你 1-3个小时的时间。2 .文档撰写指南我通过例如文档诠释了这篇文章中所讲述的思考，在继续阅读全文 之前，请务必确认你已经阅读了例如产品文档为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。那么，产品文档将如何帮助你做到这一切呢？ Ben Horowitz提供了 上图中这个看法，我的例如文档也是一个很好的例证。明确一下要 点：.从一开始就理性思考在团队开始付出更高本钱去设计软件架构、实施代码开发、完善界 面设计、测试软件质量之前，写文档可以迫使你提前思考每一个细 节。这将会提高你决策的质量，降低意外事件发生的概率。.高效沟通你常常需要和不同的利益相关方（支持团队，工程团队，设计团

7、队，财务团队，管理层等等）沟通你的方案。产品文档可以帮助你 事半功倍地完成沟通，防止口头沟通中产生的歧义，团队中的所有 人可以更好地理解你的意图，并且更有的放矢地做出答复。.明确权责明确工程目标的评价标准，公开承诺奖惩激励机制：利益相关方可 以知晓如果最后一刻变更需求会意味着什么，工程师们也会在预估 工期时再三斟酌。品文档中应当包含哪些内容？产品文档应该明确沟通要做一个什么产品，以及为什么要 这么做。用来说明清楚一个产品的表达方式很多，但最核心的，一 定要说清楚这五件事情：1.问题描绘你此次打算解决的问题。更重要的是，解释为什么要去解戾这 个问题。描述要尽可能地具体，并且提供相关的数据指标。2

8、,可衡量的目标明确承诺交付和成果，明确哪些事情超出了此工程的范畴。每一个 目标，都应该可以明确衡量是否到达目标。.需求背景提供你的观众理解当前问题以及接受你的提议所需的所有背景信息、。包括但不限于假设、用例、数据指标等信息。.解决方案详情你的提议应该有充足的细节，易于团队成员消化理解及执行可 以把这局部内容想象成对人脑进行编程和执行。.时间轴列出你的团队共同认可的截止日期和其他重要时间点。这局部内容 开始的时候可能会比拟模糊，但是在最后一次文档评审之前应当完 全敲定。你可以使用我的例如文档做你的文档模板，按照你的想法增/删/改任 何章节。只要你能够清晰并且条理清楚地表述上面提到的这五点信 息、

9、，文档形式并不重要。如何写产品文档？接下来我会介绍我撰写和评审文档的常规流程。根据工程大小，利 益相关方的数量不同等情况，流程细节可能会有所变化，但是大体 的流程是确定的。.快速完成一个草稿（1-2个小时）关闭电子邮件和聊天工具。泡杯茶，坐在椅子上开始思考，然后逐 一把你所了解的信息列成清单（见上文中的例如思路笔记）。.安排几个30分钟的一对一会议（1-4个小时）这个步骤的目的是过一遍文档中的细节，优化你的方案，并且获得 更多人的支持。尽可能控制这些会议的规模，人越少越好（理想状 态下都应该是一对一会议）。在本文的例如中，我会和客服部门的负责人，一个财务人员和一个 工程师分别安排一次会议。.撰

10、写和编辑文档（0.5-3天）此时，你应该对能做，并且应该做什么有了一个明确的想法，但是大脑中塞满了大量的细节等待着梳理清楚。于是接下来需要将所有 这些细节都整理出来，并且逐一梳理斟酌。在完成第一版文档之后，需要继续大篇幅编辑修改，通常最终的文 档可以在你的第一版草稿的基础上压缩30%-50%的长度，简洁和 清晰的文档就意味着更加容易阅读。大局部文档都可以在半天到一天的时间里完成，不过实际上也会有 一些文档需要两三天才能写完。.群发文档并且安排一个1小时的评审会议（15分钟）将文档群发给工程的所有利益相关方，并且抄送给其他可能对文档 感兴趣的团队（例如你所在的产品团队，整个支持团队等）。跟进这些

11、关键人员是否接受了会议邀请：将会执行这件事情的人， 和所有对这件事情有通过/否决权力的人。.评审文档（1小时）在开始会议之前，询问是否有参会者没有详细阅读你的文档。通常 都会有一两个人中枪，在这种情况下可以说：没问题，我们先用 10分钟一起来看一下文档。已经读过文档的人可以利用这个时间先 放松休息一下。这次会议上你需要获得利益相关方的同意，并且获得执行方（工程 师、支持团队等）的知晓、认可以及人力支持。你可能需要开屡次评审会议，并且根据评审会议上沟通的信息不断 修改文档。.通过评审后，及时同步信息和建立工单（1-2小时）会后同步信息的电子邮件需要包含更新后的产品文档链接，和此项 目相关的工单链

12、接（例如在页面上添加JavaScript代码，完 成数据分析报告，测试Staging环境，和支持团队预演流 程，等等）。一般接下来将会有一位工程师完成技术文档，不过并不总是这样 （文中的例如工程就不需要这一步）。写出高效产品文档的进阶技巧.尽量简短没有比这更重要的文档写作建议了。简洁意味着清晰的思路和沟 通，也意味着你的文档更加易于阅读和理解这一点至关重要。.使用平白的语言和简单的格式使用简短而不是花哨的语句，使用列表和加粗强调可以使文章更一 目了然，以放松有趣的方式写作而不是一板一眼，如果你有得体的 幽默感就再好不过了。.为开发团队预留时间通过评审并且达成一致通过的文档才是完善的文档。如果你

13、希望在 未来的某一个迭代Sprint中开发此工程，就应该提前两到三周开始 这个产品文档写作流程。.像工程师一样思考在工程得以进入开发之时，常常会发现大量未预料到的边缘情况一 但这种情形其实可以防止。如果你认真考虑过工程进入开发的所 有必要条件，你就可以提前发现这些问题（例如，是否在移动设备 中可以使用在线聊天功能？）。.确保每一个人都跟上了你的节奏当我组织产品评审时，会议室里的大局部人都已经大致了解我要讲 的内容因为我已经提前在讨论会和日常聊天中沟通过这个事情 了。既然大家都已经清楚了做什么和为什么要做的问题， 文档评审会上我们只要关注实施细节就好了。.在图表中下功夫流程、线框图等图表可以通过易于理解的方式提供很大的信息量， 同时也需要消耗非常多的时间来制作这些图表。.在思考和写文档上花0.5-3天时间具体时间根据工程大小而定。花费在写文档上的时间越长，所带来 的边际收益就会递减。特别需要指出的是，没有人能够读的下去超 过5-6页的文档。.指明方向，明晰愿景你不仅仅是在定义一个功能，也是在解释为什么我们要做这件事 情以及我们的目标是什公，在文档中指出这个工程将会对更 高层面的规