2.5　实施注意事项

为了更好地执行价值探索，在整个过程中有以下6点值得注意。

1．多角色参与探索

探索环涉及业务领域的很多方面，包括问题的发现与定义、目标与衡量的制订等多种产物，而不仅仅是产出一个功能需求列表。因此，建议与业务领域问题及产品解决方案相关的各类角色都能够参与其中。而且，参与其中的每个人均应该对上述内容有所贡献。

“即时提现”案例就是由团队多个角色共同贡献，使方案从“大而全的一次到位式”转变到“分步快速试验式”。当开发工程师了解产品经理的原始想法以后，从不同的视角分解问题，并一起集思广益，得出了这种投入回报率最高的最简方案，以较少的资源投入（只需一人做技术实现，其他开发人员还在开发其他功能），最快地得到了问题的答案。从第一步的“装饰窗”，到最后一步的“定向探索”，前后也只用了大约6周，就得到了最终的结论。

正像敏捷大师、Scrum方法的倡导者Mike Cohn所说：“你的整个产品Backlog（需求列表）不必全部来自Product Owner（产品总负责人或产品经理）。当团队其他人对它也做出贡献时，是团队参与感进入良好状态的一种信号，此时团队更可能成功地做出敏捷转型。”

2．存在往复过程

探索过程中存在很多的不确定性，因此4个环节中也必然存在一定的反复与循环。这是正常现象，尤其是当业务领域比较复杂、涉及环节比较多，业务流程中所涉及的角色也比较多时，更容易发生。很可能在讨论某个问题的可行解决方案时，会发现另一个隐藏的重要业务问题。

另外，探索过程强调“度量与量化”。在讨论过程中经常会出现对衡量指示器及量化结果理解不一致的现象，很可能会对原来达成一致的指标项产生异议。这是值得高兴的事情，因为我们发现了在日常沟通中不易被发现的理解偏差。对于这些偏差的处理，参与探索者既可以先把它记录下来，后续再进行探索，也可以将当前讨论的结果记录下来，并针对这一新问题开启探索之旅，甚至将探索者分成两组，分别探讨，再进行同步。无论遇到哪种异议，采取哪种行动，参与探索的人都应该对行动达成共识。

3．风险不是等价的

我们会从每个业务问题中分析出很多风险或假设，假如我们为每个假设都设计出多种试验方案，并且坚持实施所有试验方案，很可能会消耗太多的成本，并错过市场时机。因此，我们仅需对那些被评估为风险较大的假设进行验证方案设计，并尽量以较低成本进行验证。而对于那些低风险项，团队要在设计解决方案时，提出一些衡量指标器，并在方案执行后，一同收集相关的数据结果。

4．上帝视角

由于在某个领域工作时间较长，有些人认为自己非常了解用户，常常“闭门造车”，并美其名曰“注重用户体验”。然而，当产品上线后却发现，用户对产品功能有很大的意见。

2017年，某互联网公司的人工智能部门收集了大量不同类型的数据，需要进行标注。由于需要标注的数据类型较多，不同数据类型的标注方法不同，因此对标注者的技能要求也有所不同。该公司原来招募标注人员的工作是通过线下考试的方式，即以文件的方式通过邮件将材料发送给应聘者，应聘者完成后，再邮件回复。这一工作由数据运营人员和数据顾问负责，他们制订了标注人员招聘的整个线下流程和规则。

但是，由于标注需求量越来越大，而标注人员的流动性也较大，因此，标注人数的缺口持续扩大，使用线下考试方式已经不能满足对标注人数的需求。经过讨论，公司决定组织一个产品开发团队，开发一个标注人员在线考试系统，代替原有的线下手工考试方式，提高标注人员招聘环节的效率。产品开发团队的产品经理通过向数据运营人员和数据顾问了解业务领域知识和业务需求，分析并撰写了在线考试系统的需求说明书。产品经理认为，数据标注人员招聘工作已经通过线下操作方式进行了一段时间，数据顾问对该系统的软件需求足够明确，从数据顾问那里了解的业务需求应该足够充分，因此直接设计了一整套的用户交互界面，该系统包括题库、设计试卷、举办考试、收集试卷、评分等功能，涉及出题人、出卷人、答卷人和管理员4个角色。

当该系统的第一个版本开发完成后，产品经理找来了数据运营人员和数据顾问进行系统验收。验收通过以后，就马上开始灰度测试。灰度测试第一天，就收到了答卷人的大量反馈（吐槽），系统的很多功能都不是很方便。

从在线考试系统这个想法的产生，到第一次灰度上线，时间跨度近5个月。在复盘时，这个项目团队一致认为有两个严重的失误，它们是：

（1）团队成员自认为已经掌握了答卷人的所有需求，因此直到所有的产品开发工作都完成，产品流程的设计者也没有找该系统真正的使用者进行验证。

（2）团队认为完全有能力开发一个满意的在线考试系统，因此根本没有考虑先设计一个最小可发布版本（MVP），而是直接设计了一个“大而全”的版本，开发时间较长。

之后，团队还讨论了假如重新做这个项目，团队会如何做？经过热烈讨论，团队找到了很多可行方法来提前验证功能需求。例如：

（1）“纸上原型交互”方法，就是将系统交互原型打印到纸上，邀请用户试验，观察用户的行为，并与用户沟通，从而得到用户反馈，当然现在有很多电子工具支持这种需求；

（2）“MVP”法，即快速推出“面向标注人”的简化考试版本，仅实现其中一种类型标注的在线考试功能，而题库以及出题人相关的功能均暂时先由内部人员用手工方式进行准备。

5．唯数字论

当我们建立起数据指标体系，搭建好我们的试验机制，并且能够收集到大量指标数据以后，有一点需要格外注意，那就是：所有收集到的数据只能告诉你当前的状态是什么，并不能直接告诉你背后的原因是什么，也无法完全预测未来，尤其当业务市场发生改变，而数据又无法展示时。

短视频移动应用“快手”的前身是一款移动端GIF图片生成工具（名为“GIF快手”），当时用户规模也到了一定数量（GIF快手鼎盛时拥有几千万用户，日活跃用户上百万，但同时也有工具型产品的弱点：留存率偏低）。2013年，它转型做短视频应用，最低点时日活跃用户跌落至万级，然而，现在日活跃用户近亿。试想如果只看数据，坚持做GIF图片生成，是否还能有现在这么庞大的用户群呢？

因此，拿到指标数据之后，我们仍旧需要仔细思考，分析各项数据背后的原因，思考未来的发展趋势，甚至提出一些我们没有完全把握的问题或方向，再次开启探索环。

6．蛇行效应

还有一种情况，比较常见。团队针对问题制订了一系列的试验方案A，并开始执行验证。但在还没有执行完成或得到结果之前，团队又有了新的想法和方案B，并且对新的想法兴奋不已，马上开始执行方案B。没有多久，可能又想到了一个新的方向，如此循环，如图2-18所示。

这经常发生在中小企业因资金到位而人员快速膨胀的时候。既可能是因为试验方案需要较长的时间，也可能是因为管理者关注的问题点转变得过快。我们无法排除原来打算解决的业务问题已经失效的可能性，但这种情况对于团队的管理有极大的挑战。

图2-18　蛇行效应