《产品经理避免沟通低效和开发风险的终极大招》由会员分享，可在线阅读，更多相关《产品经理避免沟通低效和开发风险的终极大招（35页珍藏版）》请在金锄头文库上搜索。
1、产品经理避免沟通低效和开发风险的终极大招产品经理在一家互联网公司往往掌管着所有的需求，需要沟通的对象也包括了设计、开发、测试、运营等角色。所以，一名产品经理需要处理和面对的信息量常常是巨大的，也因此往往会面临到沟通低效、产品开发进度和质量不可控等等问题。这时候，最好的解决方案，其实是一份清晰高效的产品文档。可惜，大部分产品经理对于“文档”的价值和意义认知都是不够的。在本文中，作者Gaurav Oberoi分享了他对于产品文档的看法以及撰写产品文档的常用流程。此外，本文还含有一份真正完整的产品文档示例，以及详细的产品文档写作指南（包括格式+思路），希望对你有所帮助。以下是正文很多人听到产品文档这
2、四个字就像吞了苍蝇一样，人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累，怎么可能敏捷得起来，怎么可能高效地产出代码？我在过去十几年创造了多个数百万人使用的软件产品之后，越发认为这种观点是完全错误的。根据我的经验：高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成部分。撰写产品文档可以强制所有人从项目初始就理性思考，频繁沟通，明确权责所有的这些都会带来更好的软件质量，更低的进度风险，以及更少的时间浪费。在这篇文章中，我会通过一个案例来分享一些普适的建议，这些建议会对产品经理，尤其是大中型（超过二百人的）公司中的产品经理们非常有帮助。首先，让我们
3、来看个例子假设你需要解决这么一个问题：一家从事在线旅游预订服务 （就像 Hotels 或者 Airbnb 但是规模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个季度大家打算尝试通过在支付环节加入在线客服的方案来提升转化。你的计划是：通过在支付环节增加在线客服来尝试提高支付转化率。支付转化率目前仅有 18，而业内平均转化率有 30。我们打算测试下在支付时展示在线客服聊天窗口是否可以提高这个转化率。用户运营团队已经同意了提供1人月的客服人力支持。在你没有产品文档时，你会这样做：比方说，你觉得行动起来总是最重要的，因此直接开始动手：1. 在迭代计划会上，你和团队讨论了这个需求；2. 然后你
4、挑选了一个靠谱的第三方客服供应商（例如 SnapEngage ）；3. 提交一个工单来让工程师添加一些 Javascript 代码；4. 和支持团队开个会，确定他们都准备好了。搞定了！这么简单的事情怎么能要我们写产品文档呢？那么现在问题来了：如果你是在一个小型创业团队，你也确实可能并不需要一份产品文档因为产品改动相对小，涉及到的人也相对更少。但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会陆续出现下列这些问题，并且相比写文档，这些问题会需要更多时间来处理。例如：工程师把工单标记完成了，但是一验收测试，就发现这个功能完全没有考虑移动端的适配。（唉呀！你忘了提醒大家手机端的使用才是核心
5、场景。）用户运营经理打算开展一个漫长的评审流程，以确定最合适的聊天服务商。（啊需要定一个会议，向大家解释下这次上线只是一个灰度测试。）发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。（啥？要追加一个紧急发布，把这个测试限定在英语用户中。）一个设计师花了几天，为聊天窗口滑入屏幕的交互绘制了一个完美的动画。（用户体验过度优化，你是否对整个团队统一了“这次只是一个测试”的预期？）一周的测试完成之后，数据分析师发现无法产出你要的报告，因为相关的必要指标并没有埋点。（史诗级的失败。从头再来吧。）如果这是一个相对简单的项目，即使没有产品文档可能也不至于陷入这样的灾难之中。但是在简单的项目中你仍然
6、有可能会因为没有文档浪费许多时间和机会成本。而如果你写了一篇文档：为了便于说明，我准备了两个示例文档：一篇思路笔记，和一篇完整的产品文档这样可以完整介绍产品文档的撰写流程。请在继续阅读下文之前，花几分钟读一下这两篇示例文档吧。1. 思路笔记示例这是一个根据你已知的信息和想要解答的问题所梳理成的列表。这会是你需要做的第一件事情，大约需要一个小时来完成这个文档。这个文档会成为你和团队中其他人的一个沟通基础。以下是思路笔记示例部分1. 问题转化率糟透了，只有18%，应该可以被提升至30%（需要详细数据支持）。还能尝试什么方法来提高转化率，是否还值得继续投入呢？需要先看一下以往的用户反馈总结和用户调研
7、结果。2. 目标证明在线客服是有用的。如果测试结果不理想也别抓狂，失之我命。最好能在十二月初确定结论，这样就可以申请 Q1 的人力支持。3. 聊天服务提供商从最有名的几个中挑一个出来：Olark，SnapEngage 等等这些服务的界面长得怎么样，可以以及必须自定义多少界面元素？需要可以让客服团队不改一行代码，就能够设置他们的在线时间及虚拟形象。集成服务的成本是怎样的？仅仅加一段 JavaScript 代码就可以，还是？我们可以从服务提供商获得多少数据报告？如果是我们自己做数据分析的话需要做什么准备？可以在聊天服务中加入一些自定义的变量来帮助我们分析数据么？例如 用户 ID?是否可以先不管现有
8、 Zendesk 中现有工单的迁移？4. 如何衡量成功需要衡量：一个聊天客服的成本，一个客服可以完成多少次在线聊天，以及这些聊天可以带来多少新的转化。如果项目结束后拿不到这些数据，这个测试就白做了。一定要从客服主管和财务人员那里尽早获得反馈。5. 推进测试需要对多少流量进行测试？应该通过这几个指标计算得出：点击聊天的用户数，单个聊天的平均耗时，同时进行的聊天并发数，平均等待时长等等这个数据倒是可以算出来，但是考虑到现在只有一堆假设没有任何数据，并不值得真正去算。所以我们拍脑袋先定 20% 的流量用于测试，然后根据实际情况进行调整吧。这个测试需要多少天呢？是否需要考虑季节性的流量波动？6. 需要
9、什么样的数据报告？我想了解测试组和对照组的转化率，营收，以及订单总量。以及此次测试实际影响到的人数（开启聊天的人数）。7. 还有什么?是否考虑国际化的问题？我觉得现在还是先不考虑比较好。移动设备？你懂的，现在30%的交易量都来自于移动端.网页加载时间？务必保证聊天窗口不要拖慢整个网页的加载速度！2. 产品文档示例 （阅读时间 6 分钟）只有和团队一起评审了你的假设和创意之后（无论是在专门召集的会议上，喝咖啡时，或者桌上足球的休息时间），你才应该真正开始写产品文档。如果已经完成了沟通和评审，整个文档应该花费你 1-3 个小时的时间。以下是产品文档示例部分在支付时增加在线客服由 Gaurav Ob
10、eroi 撰写最后更新日期：2016年9月28日这个项目的目标是通过在支付页面增加在线对话客服来提高支付转化率。这是一个为期 30 天的测试，测试完成后我们可能会上线或者关掉这个功能（薛定谔的客服？蛤蛤）。用不超过两行文字描述此项目。我所说的“行”是指你的客户端的默认阅读宽度（例如 Google Docs、维基、文本文件等）。坚持字数限制是可读性的关键所在。I. 概览A. 问题1. 支付转化率过低：只有 18% 的点击了预订按钮的用户完成了支付。竞品预订网站可以达到约 30% 的转化率（数据来源）。我们正在失去收入！2. 没有明确的流失原因：之前的工单和用户调查给出了一系列非常多可能的原因（易
11、用性、支付费用、支付耗时方面的问题），也没有明确的分类。3. 增加帮助文档的内容并没有起到作用：上个季度，我们对帮助文档和预定信息的内容及界面设计做了 A/B 测试。这只带来了 1.5% 的转化率轻微提升。我强烈建议使用列表来增强文档的可读性。使用粗体文字快捷指出每行文字的要点，并且限制列表在两三行以内。我更喜欢有序列表，因为这样在口头沟通时很容易指示清楚。B. 目标1. 测试客服聊天是否可以明显地提高转化率：每天新增超过 90 个订单就能打平在线客服的运营成本，现在还不清楚是否能做到这一点。这是一次测试！2. 降低测试成本：避免所有的过度优化，如果测试成功，在 Q1 我们就可以优化在线聊天的
12、体验了。3. 在 12 月 1 日前确定最终的结果：在开始做 Q1 计划前，我们还有 8 周时间。确保文档可以提出一个明确的目标，这个目标应当是非常容易判断“达成目标了么？”的。在文档中做出明确的承诺。C. 不应考虑的问题1. 重要的界面修改：只增加一个可见的聊天按钮，不做任何其他的设计改动。2. 确定聊天服务供应商：目前而言先使用 SnapEngage，如果测试成功了，再考虑长期的服务供应商。3. 国际化和非英语用户：为了简化处理，此次测试仅针对美国地区及其他英语用户。这部分用来排除种种不利的假设，树立正确的项目预期。D. 团队成员和角色划分1. Heather（用户运营经理）：批准客服资源
13、需求。2. Randy（用户运营专员）：负责处理用户反馈，每周整理反馈总结。3. Colin（工程师）：开发和测试。也要负责配置SnapEngage，并且给我们展示一下设置方法。4. Kalpana（财务）：在测试阶段以及后续时间负责评审我的盈利预算。5. Joha（设计师）：花一点时间看一下我们在设计上的改动，没有大块的设计需求。6. Vikram（数据分析师）：确保我们能按时拿到此次测试的数据报告。帮助大家明确项目成员及对每一个人的期望。仅包括将会执行这件事情的人，和对这件事情有通过/否决权力的人。II. 背景这里应当包含了解当前问题以及解决方案所需要的所有背景信息。添加任何你认为应该出现
14、在这里的内容，例如：用例、用户模型、数据指标、竞品解决方案、调研结果等等。A. 用例1. 用户需求：在 2 分钟内获得帮助：不确定是否可以实现，但是我们先冲着这个目标去努力吧。适配移动端及桌面端：有 28% 的支付是在手机上完成的，所以移动端适配很重要。2. 用户运营团队需求：有反馈队列的客服后台：在桌面/web 端就可以，不需要支持移动端增删客服人员：可自助完成，而不需要开发人员支持设置在线时间：可以控制网站上的在线聊天按钮是否可见。查看用户信息：需要传递用户 ID 的参数给后台，方便客服人员查找当前用户信息。给会话打标签：在聊天结束后，可以在注释字段中记录一些非结构化的文本信息。B. 假设
15、1. 每天增加90个付费订单，可以打平一个客服人员的运营成本：根据每个客服人员的成本以及一个支付用户的 LTV（生命周期价值）。详见表格。2. 一个客服人力可以支持 20% 的支付流量：基于对等待时间、聊天时长、并发聊天数量的一系列假设。我们没有数据能支持做出靠谱的假设，所以拍脑袋定一个数据，并且需要我们的系统支持快速增加/降低测试流量。3. 支付转化率应该从18%增加到20：总转换率不需要增加特别多就已经意味着测试成功了。在这里查看我们的分析报告。III. 解决计划用你能做到的最自然的方式描述你的计划。需要做到清晰、条理清楚、合理分段。根据不同项目的特点，你也可以加入：线框图，用户流程图，表单输入/验证逻
