产品经理避免沟通低效和开发风险的终极大招……

2018-06-17 10:47

  本文作者Gaurav Oberoi 是 SurveyMonkey 的前联合创始人,曾于 Amazon、Xmarks 就职,在硅谷有十余年工作经验,负责过多款数百万以上用户量的产品。

  全文由刘涵宇翻译,为FellowPlus 产品负责人,个人关注产品设计、效率工具和投融资行业,微信号“不安静的书桌”,欢迎关注交流。

  产品经理在一家互联网公司往往掌管着所有的需求,需要沟通的对象也包括了设计、开发、测试、运营等角色。所以,一名产品经理需要处理和面对的信息量常常是巨大的,也因此往往会面临到沟通低效、产品开发进度和质量不可控等等问题。

  这时候,最好的解决方案,其实是一份清晰高效的产品文档。可惜,大部分产品经理对于“文档”的价值和意义认知都是不够的。

  在本文中,作者Gaurav Oberoi分享了他对于产品文档的看法以及撰写产品文档的常用流程。此外,本文还含有一份真正完整的产品文档示例,以及详细的产品文档写作指南(包括格式+思),希望对你有所帮助。

  很多人听到「产品文档」这四个字就像吞了苍蝇一样,人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累,怎么可能「敏捷」得起来,怎么可能高效地产出代码?

  我在过去十几年创造了多个数百万人使用的软件产品之后,越发认为这种观点是完全错误的。根据我的经验:

  高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成部分。撰写产品文档可以强制所有人从项目初始就思考,频繁沟通,明确权责——所有的这些都会带来更好的软件质量,更低的进度风险,以及更少的时间浪费。

  在这篇文章中,我会通过一个案例来分享一些普适的,这些会对产品经理,尤其是大中型(超过二百人的)公司中的产品经理们非常有帮助。

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

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

  2. 然后你挑选了一个靠谱的第三方客服供应商(例如 SnapEngage );

  如果你是在一个小型创业团队,你也确实可能并不需要一份产品文档——因为产品改动相对小,涉及到的人也相对更少。

  但如果你是在一个更大的组织之中,或者产品更加成熟/复杂,就会陆续出现下列这些问题,并且相比写文档,这些问题会需要更多时间来处理。例如:

  工程师把工单标记完成了,但是一验收测试,就发现这个功能完全没有考虑移动端的适配。(唉呀!你忘了提醒大家手机端的使用才是核心场景。)

  用户运营经理打算开展一个漫长的评审流程,以确定最合适的聊天服务商。(啊……需要定一个会议,向大家解释下这次上线只是一个灰度测试。)

  发布一小时后,客服报告说他们收到了西班牙语的在线聊天请求。(啥?要追加一个紧急发布,把这个测试限定在英语用户中。)

  一个设计师花了几天,为聊天窗口滑入屏幕的交互绘制了一个完美的动画。(用户体验过度优化,你是否对整个团队统一了“这次只是一个测试”的预期?)

  一周的测试完成之后,数据分析师发现无法产出你要的报告,因为相关的必要指标并没有埋点。(史诗级的失败。从头再来吧。)

  如果这是一个相对简单的项目,即使没有产品文档可能也不至于陷入这样的灾难之中。但是在简单的项目中你仍然有可能会因为没有文档浪费许多时间和机会成本。

  为了便于说明,我准备了两个示例文档:一篇思笔记,和一篇完整的产品文档——这样可以完整介绍产品文档的撰写流程。

  这是一个根据你已知的信息和想要解答的问题所梳理成的列表。这会是你需要做的第一件事情,大约需要一个小时来完成这个文档。这个文档会成为你和团队中其他人的一个沟通基础。

  还能尝试什么方法来提高率,是否还值得继续投入呢?需要先看一下以往的用户反馈总结和用户调研结果。

  我们可以从服务提供商获得多少数据报告?如果是我们自己做数据分析的话需要做什么准备?

  可以在聊天服务中加入一些自定义的变量来帮助我们分析数据么?例如 用户 ID?

  需要衡量:一个聊天客服的成本,一个客服可以完成多少次在线聊天,以及这些聊天可以带来多少新的。

  需要对多少流量进行测试?应该通过这几个指标计算得出:点击聊天的用户数,单个聊天的平均耗时,同时进行的聊天并发数,平均等待时长等等

  这个数据倒是可以算出来,但是考虑到现在只有一堆假设没有任何数据,并不值得真正去算。

  所以我们拍脑袋先定 20% 的流量用于测试,然后根据实际情况进行调整吧。

  只有和团队一起评审了你的假设和创意之后(无论是在专门召集的会议上,喝咖啡时,或者桌上足球的休息时间),你才应该真正开始写产品文档。如果已经完成了沟通和评审,整个文档应该花费你 1-3 个小时的时间。

  第一次阅读此文档时先忽略注释部分此文,然后再回到文初重新阅读所有内容。

  文中提到的所有超链接并没有链接到任何地方。这篇文章中的外链就只是表明有一些待办事项和相关文档。

  这个项目的目标是通过在支付页面增加在线对话客服来提高支付率。这是一个为期 30 天的测试,测试完成后我们可能会上线或者关掉这个功能(薛定谔的客服?蛤蛤)。

  用不超过两行文字描述此项目。我所说的“行”是指你的客户端的默认阅读宽度(例如 Google Docs、维基、文本文件等)。字数是可读性的关键所在。

  1.支付率过低:只有 18% 的点击了「预订」按钮的用户完成了支付。竞品预订网站可以达到约 30% 的率(数据来源)。我们正在失去收入!

  2.没有明确的流失原因:之前的工单和用户调查给出了一系列非常多可能的原因(易用性、支付费用、支付耗时方面的问题),也没有明确的分类。

  3.增加帮助文档的内容并没有起到作用:上个季度,我们对帮助文档和预定信息的内容及界面设计做了A/B 测试。这只带来了 1.5% 的率轻微提升。

  1. 测试客服聊天是否可以明显地提高率:每天新增超过 90 个订单就能打平在线客服的运营成本,现在还不清楚是否能做到这一点。这是一次测试!

  2. 降低测试成本:避免所有的过度优化,如果测试成功,在 Q1 我们就可以优化在线聊天的体验了。

  3. 在 12 月 1 日前确定最终的结果:在开始做 Q1 计划前,我们还有 8 周时间。

  确保文档可以提出一个明确的目标,这个目标应当常容易判断“达成目标了么?”的。

  1. 重要的界面修改:只增加一个可见的聊天按钮,不做任何其他的设计改动。

  2. 确定聊天服务供应商:目前而言先使用 SnapEngage,如果测试成功了,再考虑长期的服务供应商。

  3. 国际化和非英语用户:为了简化处理,此次测试仅针对美国地区及其他英语用户。

  3. Colin(工程师):开发和测试。也要负责配置SnapEngage,并且给我们展示一下设置方法。

  4. Kalpana(财务):在测试阶段以及后续时间负责评审我的盈利预算。

  5. Joha(设计师):花一点时间看一下我们在设计上的改动,没有大块的设计需求。

  6. Vikram(数据分析师):确保我们能按时拿到此次测试的数据报告。

  添加任何你认为应该出现在这里的内容,例如:用例、用户模型、数据指标、竞品解决方案、调研结果等等。

  在 2 分钟内获得帮助:不确定是否可以实现,但是我们先冲着这个目标去努力吧。

  适配移动端及桌面端:有 28% 的支付是在手机上完成的,所以移动端适配很重要。

  查看用户信息:需要传递用户 ID 的参数给后台,方便客服人员查找当前用户信息。

  给会话打标签:在聊天结束后,可以在注释字段中记录一些非结构化的文本信息。

  1. 每天增加90个付费订单,可以打平一个客服人员的运营成本:根据每个客服人员的成本以及一个支付用户的 LTV(生命周期价值)。详见表格。

  2. 一个客服人力可以支持 20% 的支付流量:基于对等待时间、聊天时长、并发聊量的一系列假设。我们没有数据能支持做出靠谱的假设,所以拍脑袋定一个数据,并且需要我们的系统支持快速增加/降低测试流量。

  3. 支付率应该从18%增加到20%:总转换率不需要增加特别多就已经意味着测试成功了。在这里查看我们的分析报告。

  根据不同项目的特点,你也可以加入:线框图,用户流程图,表单输入/验证逻辑,数据模型……等执行该计划所需要的所有细节。

  我选择了SnapEngage,符合我们的既定用例并且价格便宜($60/月)。注:如果测试成功,我们会再选择适当的供应商。我已经注册了一个付费账户,帐号密码在我们的密码管理工具中。

  通过SnapEngage 的文档来弄清楚他们这个聊天窗口的弹出逻辑。有以下几点:

  1. 按钮:设置为“立即聊天”的文案,并且放在详情页中“预订”主按钮的旁边;

  对比有在线客服的用户(测试组)和没有在线客服的用户(对照组)的支付率。

  我举的例子可能晦涩难懂,但是我们团队中的工程师和数据分析师则会很容易理解——因为他们正是这部分文档的受众。

  指明项目的未来发展方向永远都是好事,因为这样可以引导人们更长远地去思考。

  考虑到在「未来计划」中提到的问题,这个排期表可能会有一到两周的延期。只要我们能够在 12 月 1 日得到测试结果,我们就在 Q1 人力资源规划时争取到更多的人力。

  2.10 月 8 日:和客服团队一起在开发中测试如何设置客服人员以及客服时间。

  4.10 月 17 日:在上线周后同步信息。在此时我们可能会有一些额外的工作要做。

  5.11 月 12 日:最后一次沟通,评审当下状态以决定继续推进还是结束此项目。

  开始的时候排期表可以只有一个大致的估期,通过更多的分析来逐步精确时间点(例如需要技术文档)。

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

  是的,就是这样。那么,产品文档将如何帮助你做到这一切呢?Ben Horowitz 分享了上图中这个看法,我的示例文档也是一个很好的。明确一下要点:

  在团队开始付出更高成本去设计软件架构、实施代码开发、完善界面设计、测试软件质量之前,写文档可以你提前思考每一个细节。这将会提高你决策的质量,降低意外事件发生的概率。

  你常常需要和不同的利益相关方(支持团队,工程团队,设计团队,财务团队,管理层等等)沟通你的方案。产品文档可以帮助你事半功倍地完成沟通,避免口头沟通中产生的歧义,团队中的所有人可以更好地理解你的意图,并且更有的放矢地做出答复。

  明确项目目标的评价标准,公开承诺惩激励机制:利益相关方可以知晓如果最后一刻变更需求会意味着什么,工程师们也会在预估工期时再三斟酌。

  描绘你此次打算解决的问题。更重要的是,解释为什么要去解决这个问题。描述要尽可能地具体,并且提供相关的数据指标。

  明确承诺交付和,明确哪些事情超出了此项目的范畴。每一个目标,都应该可以明确衡量「是否达到目标」。

  提供你的观众理解当前问题以及接受你的提议所需的所有背景信息。包括但不限于假设、用例、数据指标等信息。

  你的提议应该有充足的细节,易于团队消化理解及执行——可以把这部分内容想象成对人脑进行编程和执行。

  列出你的团队共同认可的截止日期和其他重要时间点。这部分内容开始的时候可能会比较模糊,但是在最后一次文档评审之前应当完全敲定。

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

  这个步骤的目的是过一遍文档中的细节,优化你的方案,并且获得更多人的支持。尽可能控制这些会议的规模,人越少越好(理想状态下都应该是一对一会议)。例如,在本文的示例中,我会和客服部门的负责人,一个财务人员和一个工程师分别安排一次会议。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  (而不是文档或者会议)作为衡量成功的标准——这些团队也都仍然认为文档是他们打造成功软件的一个关键部分。产品文档与技术文档有何区别?

  12月22日,由前腾讯新闻中心主编,青山资本副总裁,“在行”上全网评分最高的市场营销类行家李倩老师主讲的课程——“

  7周重塑你的品牌框架和营销操盘”即将开课,了解课程详情和报名,请长按下面的海报扫码。返回搜狐,查看更多责任编辑: