本篇文章9391字，读完约23分钟
这是一个基于你知道的信息和你想回答的问题的列表。这将是您需要做的第一件事，大约需要一个小时来完成此文档。本文档将作为您和团队中其他人之间沟通的基础。
本文是由我黑马授权并由gaurav oberio出版的三级教程(微信标识:sanjieke)。
前面写着这样的话:
在互联网公司中，产品经理通常负责所有的需求，沟通的对象也包括设计、开发、测试和操作的角色。因此，产品经理需要处理和面对的信息量往往是巨大的，这往往会导致沟通效率低下、产品开发进度和质量无法控制等问题。
此时，最好的解决方案实际上是一个清晰高效的产品文档。不幸的是，大多数产品经理并不知道文档的价值和意义。
在这篇文章中，作者gaurav oberoi分享了他对产品文档和编写产品文档的一般过程的看法。此外，本文还包含一个真正完整的产品文档示例和一个详细的产品文档编写指南(包括格式+想法)，希望对您有所帮助。
以下是正文
许多人听到“产品文档”这个词，就好像他们吞下了一只苍蝇。人们通常认为这意味着写一份没人会看的文件需要几周时间。如果一个团队总是被产品文档拖垮，它怎么可能是“敏捷”的，怎么可能高效地产生代码？
在过去的十年里，创造了数百万人使用的几种软件产品之后，我越来越觉得这种观点是完全错误的。根据我的经验:
高效的产品文档是创造优秀产品过程中不可或缺的重要部分。编写产品文档可以迫使每个人从项目开始就理性思考、频繁沟通并明确自己的权利和责任，所有这些都将带来更好的软件质量、更低的进度风险和更少的时间浪费。
在本文中，我将通过一个案例分享一些通用的建议，这对产品经理非常有帮助，尤其是大中型公司(员工超过200人)的产品经理。
首先，让我们看一个例子
假设你需要解决这样一个问题:
一家从事在线旅游预订服务的公司(就像酒店或airbnb一样，但规模较小)。目前，该公司的支付转换率较低，所以本季度，大家都打算尝试通过在支付环节增加在线客服来提高转换率。
你的计划是:
通过在支付过程中增加在线客户服务来提高支付的转化率。
目前，支付转换率仅为18%，而行业平均转换率为30%。我们打算测试在付款期间显示在线客户服务聊天窗口是否可以提高这一转化率。用户运营团队同意提供一个人工月的客户服务人力支持。
当您没有产品文档时，您会这样做:
例如，你认为行动总是最重要的，所以就开始吧:
1.在迭代计划会议上，你和团队讨论了这个需求；
2.然后选择一个可靠的第三方客户服务提供商(如snap engage)；；
3.提交一份工作订单，让工程师添加一些javascript代码；
4.与支持团队开会，确保他们准备好了。
完成！我们怎么能为这么简单的事情编写产品文档呢？
所以现在的问题是:
如果你在一个小的创业团队，你可能不需要产品文档，因为产品变更相对较小，涉及的人也较少。
但是，如果你在一个更大的组织中，或者产品更成熟/复杂，下面的问题将会一个接一个地出现，这些问题比写文档需要更多的时间来处理。例如:
工程师标记了工作指令，但是在验收测试时，发现该功能根本没有考虑移动终端的适应性。(唉！你忘了提醒每个人手机的使用是核心场景。(
用户运营经理打算进行一个漫长的审查过程，以确定最合适的聊天服务提供商。(啊，我们需要安排一个会议，向大家解释这次发布只是一次灰度测试。(
发布一小时后，客服报告称他们收到了一个西班牙语的在线聊天请求。(什么？要添加紧急发布，请将此测试限于英语用户。(
一位设计师花了几天时间为聊天窗口滑入屏幕的互动绘制了一个完美的动画。(用户体验过度优化。你是否统一了这只是对整个团队的一个测试的期望？(
经过一周的测试，数据分析师发现你想要的报告无法产生，因为相关的必要指标没有被埋没。(巨大的失败。让我们重新开始。(
如果这是一个相对简单的项目，即使没有产品文档，它也不会陷入这样的灾难。然而，在简单的项目中，您可能仍然会浪费大量的时间和机会成本，因为没有文档。
如果你写了一份文件:
为了便于解释，我准备了两个样本文档:一个思维笔记和一个完整的产品文档，可以完整地介绍产品文档的编写过程。
在继续之前，请花几分钟时间阅读这两个示例文档。
1.思维笔记示例
这是一个基于你知道的信息和你想回答的问题的列表。这将是您需要做的第一件事，大约需要一个小时来完成此文档。本文档将作为您和团队中其他人之间沟通的基础。
以下是思维笔记的示例部分
1.问题
转换率很可怕，只有18%，而且应该提高到30%(需要详细的数据支持)。
还有什么其他方法可以提高转换率，值得继续投资吗？有必要先看看之前的用户反馈总结和用户调查结果。
2.目标
证明在线客户服务是有用的。如果测试结果不令人满意，不要生气，丢掉我的生命。
最好在12月初做出结论，以便您可以申请第一季度的人力支持。
3.聊天服务提供商
选择一个最著名的:olark，snapengage等等
这些服务的接口是什么，有多少接口元素可以并且必须被定制？
有必要使客户服务团队能够在不更改一行代码的情况下设置他们的在线时间和虚拟映像。
集成服务的成本是多少？只是添加一个javascript代码，或者？
我们能从服务提供商那里得到多少数据报告？如果我们自己做数据分析，我们应该做什么准备？
你能给聊天服务添加一些自定义变量来帮助我们分析数据吗？例如，用户id？
有可能忽略现有zendesk中现有工作的迁移吗？
4.如何衡量成功
需要衡量:聊天客户服务的成本，一个客户服务可以完成多少在线聊天，这些聊天可以带来多少新的转变。
如果你不能在项目结束后得到这些数据，测试将会是徒劳的。
务必尽快从客户服务主管和财务人员那里获得反馈。
5.高级测试
需要测试多少流量？应该从这些指标来计算:点击聊天的用户数量、单次聊天的平均时间消耗、同时聊天的数量、平均等待时间等等
这些数据是可以计算的，但是考虑到只有一堆假设而没有任何数据，它不值得真正计算。
让我们拍拍脑袋，设定20%的流量进行测试，然后根据实际情况进行调整。
这个测试需要多少天？你需要考虑季节性交通波动吗？
6.需要什么样的数据报告？
我想知道测试组和对照组的转换率、收入和总订单。
实际上受这个测试影响的人数(开始聊天的人数)。
7.还有什么？
你考虑国际化吗？我认为现在最好不要去想它。
移动设备？你知道，现在30%的交易来自移动终端。
网页加载时间？确保聊天窗口不会降低整个网页的加载速度！
以上是思想笔记的示例部分
2.产品文档示例
只有在和团队一起回顾了你的假设和想法之后(无论是在一个特别的会议上，在喝咖啡的时候，还是在桌上足球休息的时候)，你才应该真正开始写产品文档。如果沟通和审查已经完成，整个文件应该需要1-3个小时。
以下是产品文档的示例部分
灰色参考是注释。
第一次阅读本文档时，建议忽略注释，完整阅读文本，然后在文本开头再次阅读所有内容。
本文中提到的所有超链接都不会链接到任何地方。本文中的外链仅表示有一些待办事项和相关文档。
付款时增加在线客户服务
作者:gaurav oberoi
最后更新日期:2016年9月28日
本项目的目标是通过在支付页面增加在线对话客户服务来提高支付转换率。这是一个30天的测试。测试完成后，我们可以上网或者关闭这个功能(薛定谔的客服？蛤蜊)。
用不超过两行的篇幅描述这个项目。我所说的行是指你的客户的默认阅读宽度(比如谷歌文档、维基百科、文本文件等)。)。坚持字数限制是可读性的关键。
一.概述
A.问题
1.付款的转换率太低:只有18%点击“预订”按钮的用户完成了付款。竞争产品预订网站的转换率可达30%左右(数据来源)。我们正在失去收入！
2.损失没有明确的原因:之前的工作订单和用户调查给出了一系列可能的原因(可用性、支付成本、耗时的支付)，并且没有明确的分类。
3.增加帮助文档的内容不起作用:上个季度，我们对帮助文档和预定信息的内容和界面设计进行了测试。这只会导致转化率略微提高1.5%。
我强烈建议使用列表来增强文档的可读性。
使用粗体文本快速指出每行文本的要点，并将列表限制为两行或三行。
我更喜欢有序列表，因为在口头交流中很容易清楚地表明。
B.目标
1.测试客服聊天是否能显著提高转换率:每天增加90多个订单就能平抑在线客服的运营成本，但这能否做到还不清楚。这是一个测试！
2.降低测试成本:避免过度优化。如果测试成功，我们可以在第一季度优化在线聊天体验。
3.在12月1日之前确定最终结果:在开始第一季度计划之前，我们还有8周时间。
确保文件能提出明确的目标。这个目标应该很容易判断和实现吗？当然。
在文件中做出明确的承诺。
C.不应考虑的问题
1.重要的界面修改:只添加一个可见的聊天按钮，不做其他设计更改。
2.确定聊天服务提供商:目前，首先使用snapengage，如果测试成功，考虑长期服务提供商。
3.国际化和非英语用户:为了简化处理，此测试仅适用于美国和其他英语用户。
这一部分用于消除各种不利的假设，建立正确的项目预期。
D.团队成员和角色划分
1.heather(用户运营经理):批准客户服务资源需求。
2.兰迪(用户操作专家):负责处理用户反馈，每周整理反馈总结。
科林(工程师):开发和测试。还要负责配置snapengage，并向我们展示如何设置它。
4.卡尔帕纳(财务):负责在测试阶段和随后的时间里审查我的利润预算。
5.约翰(设计师):花点时间看看我们的设计变化。没有大的设计需求。
维克拉姆(数据分析师):确保我们能及时得到这次测试的数据报告。
帮助人们定义项目成员和他们对每个人的期望。
只有执行此事的人和有权通过/否决此事的人包括在内。
Ii .背景
它应该包含理解当前问题和解决方案所需的所有背景信息。
添加您认为应该出现在这里的任何内容，例如用例、用户模型、数据指示器、竞争解决方案、研究结果等等。
A.用例
1.用户要求:
两分钟内获得帮助:我不确定能否实现，但让我们先朝着这个目标努力。
调整移动终端和桌面终端:28%的支付是在手机上进行的，因此移动终端调整非常重要。
2.用户操作团队要求:
具有反馈队列的客户服务背景:在桌面/网络端，不需要支持移动端
添加和删除客户服务人员:它可以通过自助完成，无需开发人员的支持
设置在线时间:您可以控制网站上的在线聊天按钮是否可见。
查看用户信息:需要将用户id参数传递给后台，以便客服人员查找当前用户信息。
标签对话:聊天后，您可以在评论栏中记录一些非结构化的文本信息。
B.假设
1.每天增加90个付费订单可以平衡客户服务人员的运营成本:根据每个客户服务人员的成本和付费用户的ltv(生命周期价值)。详情见表。
2.客户服务人员可以支持20%的支付流程:基于一系列关于等待时间、聊天持续时间和同时聊天次数的假设。我们没有数据来支持做出可靠的假设，所以我们需要我们的系统来支持测试流的快速增加/减少。
3.付款转换率应该从18%提高到20%:总转换率不需要增加太多，这意味着测试成功。请查看我们的分析报告。
Iii .结算计划
尽可能用最自然的方式描述你的计划。
需要清晰、连贯和合理的分割。
根据不同项目的特点，还可以添加:线框、用户流程图、表单输入/验证逻辑、数据模型等。执行计划所需的所有细节。
A.在线客户服务提供商
我选择了snapengage，它符合我们既定的使用案例，而且价格便宜(60美元/月)。注:如果测试成功，我们将再次选择合适的供应商。我已经注册了一个支付账户，账户密码在我们的密码管理工具中。
B.用户体验
通过snapengage的文档找出他们聊天窗口的弹出逻辑。有以下几点:
1.按钮:将其设置为即时聊天的副本，并将其放在详细信息页面的预订主按钮旁边；
2.互动:点击时显示客户服务名称，你需要什么帮助？文案；
3.所有付款页面:应显示在所有三个付款步骤页面上；
4.不要自动弹出:我们可以在将来再次尝试这种效果。现在，让我们低调上网。
C.会话参数
1.这是什么:当我们嵌入服务提供者的javascript时，我们可以传递特定的参数。客户服务人员可以看到这些参数，并记录在日志和数据报告中。
2.传输这些参数:用户id、用户邮箱、浏览器信息、预订id和预订订单价格。
D.测试流量开关
只有一些支付流量会看到在线客户服务功能。我们需要做的是:
1.仅向x%用户显示:我们必须能够在不重新部署的情况下修改x的值，但是用户操作团队可以在每次手动修改时向工程师提交工作单(例如，将该值存储在我们的数据库/redis中)。
2.对于显示的用户总是可见的:只要用户已经看到这个聊天窗口一次，用户应该总是能够在测试期间看到这个功能。该状态可以通过cookie存储，也可以由这些用户的用户id记录(例如，如果用户id的模数小于100)，则可以看到该功能)。
3.流量增加方案:第一天，我们只开放5%的流量进行测试。如果用户运营团队的反馈正常，第二天将开放10%的流量，第三天开放20%。
E.数据指标和报告
1.日志记录:将live_checkout=true/false添加到现有指示器。
2.新数据报告:
比较有在线客户服务的用户(测试组)和没有在线客户服务的用户(对照组)的支付转化率。
在线客户服务的总订单和收入。
测试有多少用户点击了在线聊天窗口。
3.snapengage的数据报告:它可以告诉我们平均会话时间和并发会话的数量
上面的例子可能晦涩难懂，但是我们团队中的工程师和数据分析师很容易理解，因为他们是这部分文档的读者。
记住:写下人脑需要完成的所有必要的事情。
F.未来计划
1.如果我们发现在线聊天的使用率很低，我们需要尝试一些优化方案，比如:a .自动弹出聊天窗口，b .修改聊天按钮的样式，c .在聊天按钮旁边添加客服人员的照片。
2.如果测试成功:我们将争取更多的客服人员，并在第一季度进行大规模的迭代改进，包括选择合适的供应商、更深入的数据分析和正式的客服语音培训。
指出项目的未来方向总是一件好事，因为它可以引导人们思考更长的时间。
Iv .任务和日程
考虑到“未来计划”中提到的问题，这一时间表可能会推迟一至两周。只要我们能在12月1日得到测试结果，我们将在第一季度人力资源规划中争取更多的人力。
1.10月4日:文件审查。
2.10月8日:与客户服务团队一起测试如何在开发环境中设置客户服务人员和客户服务时间。
3.10月11日:上网。我们将在接下来的几天里逐步增加测试流量。
4.10月17日:上线一周后同步信息。此时我们可能有一些额外的工作要做。
5.11月12日:最后一次沟通，回顾当前状态以决定是继续还是结束项目。
12月1日，6:这是完成这个项目和获得测试结果的最后期限。
开始时，调度表只能有一个粗略的估计周期，通过更多的分析(例如，需要技术文件)，时间点可以逐渐精确。
然而，尽可能快地拆除和确定时间点，并大致确定每项工作的范围和规模，仍然是非常重要的。
项目评估的时限应来自执行者(开发、设计等)。)。
以上是产品文档的示例部分
啊哈！有了文件后，你觉得自己更脚踏实地了吗？写文档看起来像是额外的工作成本，但事实并非如此。高效的文档可以帮助您和您的团队节省时间和投资，并且在交付上线时更加自信。
等等，你看完样本文件了吗？请先阅读，然后继续阅读下面的文章。
产品文档编写指南
我通过示例文档解释了本文的思路。在继续阅读以下内容之前，请确保您已经阅读了上述文档演示。
为什么要写产品文档？
总之:为了交付质量更高、速度更快、预判更好的正确产品。
是的，就是这样。那么，产品文档将如何帮助您完成这一切呢？本·霍洛维茨在上面的图片中分享了这个观点，我的样本文档也是一个很好的例子。明确要点:
1.从一开始就理性思考
在团队开始为设计软件架构、实现代码开发、改进接口设计和测试软件质量付出更高的成本之前，编写文档可以迫使你提前考虑每一个细节。这将提高你的决策质量，降低事故发生的概率。
2.高效沟通
您经常需要与不同的利益相关者(支持团队、工程团队、设计团队、财务团队、管理层等)交流您的计划。)。产品文档可以帮助你用一半的努力完成沟通，避免口头沟通中的歧义，并且团队中的所有人都可以更好地理解你的意图并给出更有针对性的回应。
3.明确的权力和责任
明确项目目标的评估标准，并公开承诺奖惩激励机制:如果需求在最后一刻发生变化，利益相关者可以知道这意味着什么，工程师在估算工期时会三思而行。
产品文档应该包含什么？
产品文档应该清楚地传达要做什么和为什么要做。有许多方法可以清楚地解释一个产品，但核心是要清楚地解释这五件事:
1.问题
描述一下你这次打算解决的问题。更重要的是，解释我们为什么要解决这个问题。描述应尽可能具体，并提供相关的数据指标。
2.可衡量的目标
对交付和结果的明确承诺，以及超出本项目范围的明确内容。每个目标都应该能够清楚地衡量目标是否已经实现。
3.需求背景
向你的听众提供他们理解当前问题和接受你的建议所需的所有背景信息。包括但不限于假设、用例、数据指标和其他信息。
4.解决方案详细信息
你的提议应该有足够的细节，便于团队成员消化、理解和执行。你可以把这部分想象成人类大脑的编程和执行。
5.时间表
列出截止日期和你的团队同意的其他重要时间点。这一部分在开始时可能是模糊的，但应该在最后一次文件审查之前完成。
您可以使用我的示例文档作为您的文档模板，并根据您的想法添加/删除/更改任何章节。只要你能清楚而有条理地表达这五点信息，文档形式就不重要。
产品文件编写流程:
接下来，我将介绍我撰写和审阅文档的一般过程。根据项目的规模和利益相关者的数量，过程的细节可能会有所变化，但是一般的过程是确定的。
1.快速完成草稿(1-2小时)
关闭电子邮件和聊天工具。泡一杯茶，坐在椅子上开始思考，然后把你知道的信息一个一个列出来，就是上面思考笔记的例子。
2.安排几次30分钟的一对一会议(1-4小时)
这一步的目的是浏览文档中的细节，优化您的计划并获得更多人的支持。尽可能控制这些会议的规模，人数越少越好(理想情况下，应该是一对一的会议)。例如，在本例中，我将安排与客户服务部的负责人、一名财务人员和一名工程师会面。
3.编写和编辑文档(0.5-3天)
在这一点上，你应该对你能做什么和应该做什么有一个清晰的想法，但是你的脑子里充满了等待被解决的细节。因此，所有这些细节都需要一一梳理和考虑。
完成文档的第一版后，您需要继续在一个大空间中编辑和修改它。通常，最终文件可以在你的第一版草稿的基础上压缩30%-50%。一份简洁明了的文件意味着它更容易阅读。
大多数文件可以在半天到一天内完成，但事实上，有些文件需要两三天才能完成。
4.分组发送文件，安排一个1小时的回顾会议(15分钟)
将文档发送给项目的所有涉众，并将副本发送给可能对文档感兴趣的其他团队(如您的产品团队、整个支持团队等)。)。
跟进这些关键人员是否接受了会议邀请:将执行此事的人员，以及所有有权通过/拒绝此事的人员。
5.审阅文档(1小时)
在开始会议之前，询问是否有与会者没有详细阅读您的文档。通常，一两个人会被枪杀。在这种情况下，我们可以说:没问题。让我们花10分钟一起看一下文件。那些看过文件的人可以利用这个时间先在“放松”休息一下。
在这个会议上，你需要利益相关者的同意，以及执行者(工程师、支持团队等)的知识、认可和人力支持。)。
您可能需要召开几次审查会议，并根据审查会议中传达的信息不断修改文件。
6.审核通过后，同步信息并及时建立工作单(1-2小时)
会后同步信息的电子邮件需要包括与此项目相关的更新产品文档链接和工作单链接(如在页面上添加javascript代码、完成数据分析报告、测试试运行环境、支持团队预览流程等)。)。
一般来说，工程师接下来会完成技术文档，但情况并非总是如此(对于本文中的示例项目，这一步不是必需的)。
产品文档的高级技能:
1.尽可能简短
没有更重要的文件写作建议。简单意味着清晰的思维和交流，也意味着你的文档更容易阅读和理解，这是非常重要的。
2.使用简单的语言和格式
用短句代替花哨的句子，用列表和粗体强调可以使文章一目了然，用轻松有趣的方式而不是正式的方式写作。如果你有适当的幽默感就好了。
3.为开发团队预留时间
完美的文件是通过审查并达成共识的文件。如果你想在未来的迭代冲刺中开发这个项目，你应该提前两到三周开始产品文档的编写过程。
4.像工程师一样思考
当一个项目进入开发阶段时，它经常会发现很多意想不到的边缘情况，但是这种情况是可以避免的。如果您仔细考虑项目进入开发的所有必要条件，您可以提前发现这些问题(例如，在线聊天可以在移动设备中使用吗？).
5.确保每个人都跟上你的节奏
当我组织产品回顾时，会议室里的大多数人都已经知道我要谈什么，因为我已经提前在讨论和日常聊天中传达了这件事。既然大家都知道“做什么”和“为什么要做”的问题，我们只需要在文件审查会议上注意执行细节。
6.在图表上努力工作
流程图、线框和其他图表可以以一种易于理解的方式提供大量信息，并且制作这些图表会耗费大量时间。
7.花0.5-3天时间思考和写文件
具体时间取决于项目的规模。写文件花的时间越长，它带来的边际效益就越小。特别是，没有人能阅读超过5-6页的文件。
8.指引方向，清晰视野
您不仅定义了一个功能，而且还解释了“我们为什么要做这件事”和“我们的目标是什么”，在文档中指出这个项目将对更高层次的规划产生什么影响以及接下来会发生什么。
9.确保你的观众已经阅读了文档
如果你的文档又臭又长，或者你从来没有和相应的人分享过它，你最好不要写它。确保您的文档已被相应的人阅读。我关于在审查开始时给每个人留出时间阅读文件的建议值得你参考。
10.获得真诚的反馈
你的文件是不是重复了大家都知道的东西？还是文件缺乏足够的细节？在随后的实施中是否发现了太多的边缘情况？或者，您是否在计划和文档审查上花费了太多时间？你应该随时和你的团队保持联系。
产品文档和敏捷开发之间有矛盾吗？
我知道会有争议，但是产品文档和敏捷开发的原则之间没有冲突，它已经在敏捷方法中被充分利用，比如scrum。
毕竟，用户故事通常需要详细描述，文档可以提高沟通的清晰度和传播性。为什么你必须严格地认为只有口头交流和白板才是敏捷开发？
产品文档会导致缓慢发布、过度规划，并且通常会浪费时间。这个想法完全是胡说八道。
我工作过的许多世界级团队都遵循一些敏捷原则(例如，每两周一个迭代周期)，每天发布代码(甚至更频繁)，并将发布产品(而不是文档或会议)作为衡量成功的标准。这些团队仍然认为文档是他们成功软件的关键部分。
产品文档和技术文档有什么区别？
产品文档通常关注做什么，而技术文档更关注如何做。这两个文档为R&D过程中的不同环节带来了相同的清晰视角，并且都让工程师(和他们的用户)身心愉悦。
