阿里巴巴何勉：互联网产品如何创新落地？需要做到这5“让”
图片来源于2018年北京QCon活动
传统的瀑布开发方法无法满足产品创新的要求，于是迭代和敏捷开发渐成主流。通过迭代，我们期望去交付价值、去获取反馈。但，迭代仅仅局限于开发阶段，并不能给我们带来根本的变化。
因为产品创新的生命周期不仅仅是包含产品开发这个过程，更包括前面的业务规划和产品定义，以及之后的实施和验证，从而交付价值和得到市场的反馈，根据反馈去即时调整。是一个完整的创新循环。
所以我今天要说的是超越敏捷，其目的是：更快交付价值和获取反馈、交付有用的价值，赋能产品创新。当然，超越的是狭义的敏捷——开发阶段的敏捷。
今天要讲的，包含以下几个部分：
1）让光照亮关键所在；
2）让价值顺畅流动；
3）让团队聚焦关键目标；
4）让功能服务于关键目标；
5）让业务交付闭环加速。
这 5 个“让”是接下下来分享的内容。
从一个故事讲起，酒吧前一个醉汉在找来找去，很长时间了。警察上前问他：你在干吗？“我在找我的钥匙”。警察找了一下什么也没发现，问：钥匙是丢在这吗？醉汉说：不是。那他为什么在这找？醉汉的回答是，因为这有光啊。
钥匙英文是 Key，也可以译成关键。在光照亮的地方寻找答案，但那并不是关键所在。产品开发中类似的情况时有发生，产品开发的关键究竟在哪里?
在产品开发中，我们的根本问题从来不是停滞的资源，而是停滞的用户需求。然而，许多管理者特别偏爱去关注资源，看资源的忙闲，而停滞的需求却很少被关注和即时发现。
为了让研发过程提效，我们首先要让光照亮关键所在。只去看各个独立的阶段是不够的，我们要照亮的是整个端到端的过程，也就是从一个用户需求或创意被提出到被验证和交付以及获取有效反馈的整个过程。这个过程中涉及不同部门间的协作，我们需要照亮需求整个流动的过程中，流动是否顺畅，在哪里发生了停滞，瓶颈在哪里。
我们要可视化整个需求端到端的交付过程。可视化的核心不是人、资源和任务，而是价值的端到端交付过程。我们要让团队看到协作交付需求的过程，看到价值 (需求) 端到端的流动，需求在哪里发生了等待与积压，瓶颈在哪里。这才是关键所在，是我们协作和改进的出发点和依据。
我们看到了需求交付的过程，这个过程从我们决定做一个需求开始，也就从众多的机会中做出选择开始。需求从选择到设计，再到评审，接下来是开发中，验收和交付。
让我们单独看开发过程，我们看到了横向的泳道，泳道的第一列蓝色纸条是需求，后面的黄色纸条是需求下属的任务，分别属于前端、后端，测试和依赖，多个模块（或关联部门）协作完成需求的开发。
蓝色纸条是需求，它什么时候可以从开发中进入待测试列呢？当其下属的所有任务都完成后，需求才可以进入待测试列。这时原先用的任务可以被清空，泳道就空下来了，可以接纳新需求。
如果都泳道都被占满了，我们应该怎么做呢？我们应该做的不是开始更多的需求，而是尽快去完成那些已经开始的需求，让需求流动起来。正如前面所说，问题在于停滞的需求，需求如果停滞就会在这排队，提示该环节中可能存在问题。
所以我们关注的重点是：需求端到端的流动是不是足够顺畅、足够快，有没有产生积压。这是一个端到端的价值交付过程，让光照亮这个过程，就是为了让需求顺畅流动，让价值更顺利的交付。
我们会统计两个时间周期：开发周期和客户周期时间。开发周期是从待开发开始到待发布结束。客户周期时间则从“已选择”开始到发布结束。我们希望缩短这两个周期，以加速交付和反馈。
上图中的泳道数量是有限的，它也意味着并行需求的数目是有限制的，限制的好处有两点。
第一：并行少，更快地完成进行中的需求，需求从开始到完成的时长自然缩短；
第二：如果产生了问题，我们必须尽快解决，让需求能顺畅流动。
这也促进了团队更加紧密的协作，首先是平行团队的协作，比如前后端团队紧密协作，向需求对齐，快速交付需求；其次是前后环节的协作，比如开发完成后即时进行测试，打破测试移交的批量和瓶颈。这就是所谓前后拉通，左右对齐。
我们还要特别强调的是内建质量：每个阶段流动的规则要清晰，有明确的入口或出口标准。比如，需求进入待开发前的标准是：开发测试和业务要共同澄清需求的业务目标、用户使用流程及测试验收标准。在移交测试之前，我们必须进行充分的自测等等。内建质量强调的是过程质量，一方面是最终交付质量的保障，另一方面通过过程质量的提高促进交付过程更加顺畅，提高交付的效率。
接下来要做的事情是要让团队聚焦于关键目标。
度量非常重要。德鲁克说：如果不能度量它，你就无法改进它。同时度量也充满困难。
1997 年英国首相布莱尔上台的时候，大家都抱怨医疗系统的服务太差，尤其是反应太慢。布莱尔的内阁，制定了一项考核标准（也就是 KPI）：所有预约，必须在 48 小时内得到诊疗。这项 KPI 的考核结果不错。2005 年，在英国大选电视辩论上，布莱尔开始炫耀自己的政绩。
在场的有人举手说：“对不起，首相先生，可是我电话从来也打不进去”。布莱尔觉得这可能只是个别现象，于是，主持人问在场的其他人是否遇到过这个情况？几乎所有人都举手了。背后的原因我们大概能能够猜到的，既然预约 48 小时必须接诊，而现有的资源满足不了要求。那最简单的办法就是避免接受预约。布莱尔后来说，给复杂的世界确立一个简单的目标，有时只会适得其反。这个事情告诉我们，没有度量是不行的，但对于度量我们一定要小心。产品开发同样如此，如果在产品早期过度关注诸如 DAU（活跃用户数），GMV（交易额）之类的虚荣指标往往会把产品带到错误的方向。
好的度量首先来自于对业务的理解。这幅图显示了某个二手交易平台的业务模型，图中，每个框是一个用户的行为结点，比如说用户通过搜索，得到列表，并进入了详情页，加入购物车等等。而图中，每一条线是行为之间的转换。
基于这幅业务大图，我们很容易找到产品的指标，比如说：卖家要发布就要看他平均的发布数量。对于搜索，可以考察搜索匹配率或者搜索下单率等等。但是问题又来了，我们会发现潜在需要关注的指标太多了，我们应该从哪里开始呢？
让我们做一个抽象，它适合大部分互联网产品。商业模式由产品和市场两个相互关联的部分构成，产品部分包括：产品的目标定位, 目标用户是谁？解决他们什么问题？以何种方案去解决？市场部分包括：如何触达用户？如何定价？采取怎样的运营模式？等等。
这是一个概念上的商业模式，把用户带到这个商业模式里面，我们看到是从一个潜在的客户，到一个使用产品的客户，再到一个满意并愿意留下来的客户，从满意的客户身上能获得我们的收益，并且最好能带来更多的客户。
实现增长是互联网产品业务成功的核心。Eric Ries 总结了产品增长的三个引擎：付费引擎、病毒引擎和粘性引擎。
付费引擎：付费获取用户。但你必须有钱获取用户，一般的经验告诉我们：客户终身价值最好要大于 3 倍的获客成本；
病毒引擎：让用户告诉用户，并带来更多的用户，这个过程的核心是：发生的越快越好，带来的用户越多越好；
粘性引擎：要让用户留下来，其核心是：用户流失的速度得小于新增的速度。
这三个引擎里，哪一个更重要？当然是都很重要。但是，不同阶段其偏重是不一样的。问题是从哪一个引擎开始？尽管付费引擎、病毒引擎有它的作用，但是如果没有黏性，付费引擎、病毒引擎是开动不起来的，所以在新产品（或新特性）打造时，一定是从黏性开始的。
增长黑客的核心是要把一个好产品卖出去，第一步要让产品满足市场的需求，保证产品和市场匹配。在不同的阶段关注不同的指标，但一定是从黏性开始的，关注与粘性相关的指标。找准产品的核心指标很关键，但节奏和路径更重要。
有了一个正确的目标之后，接下来就要让功能服务于真正关键的目标。
基于这些指标，我们要做的就是进一步分解，把它转化为产品功能。在这一步，影响地图是一个可能会用到的工具。先简单介绍一下。我们有一个目标，要把它变成一个个的功能，要确保功能服务于目标，影响地图就是要实现从功能到目标之间的映射。
业务目标和功能之间的映射是有距离的，影响地图要在两者之间建立桥梁。这两个桥墩叫角色和影响。从目标出发，通过影响谁可以实现这个目标，是什么样的影响，为此需要什么样的产品功能。
举一个例子，如我们的目标是：6 个月之内不增加客服人数的情况下，支持两倍的用户数。这是一个量化的指标。影响谁才能实现这个目标呢？我们想到的有客服，经常有问题的初级用户，还有可能帮助我们回答问题的高级用户。以客服为例，需要怎样的影响呢？比如更快速的定位和跟踪问题。为此产品要提供用户服务记录和根据呼入电话定位用户的功能。
影响地图背后的假设是：产品通过功能 (what)，影响 (how) 特定用户角色（how）的行为，从而实现业务目标（why）。影响地图帮助团队更有效的拓展思路挖掘和组织需求。
基于影响地图，接下来我们要做的是选择其中最有效的功能，合理规划，迭代的实现目标。关于规划，我想问大家一个问题。我们的目标是实现整张地图吗？
显然不是。在需求的挖掘阶段，我们可以集思广益、充分发散，但做规划，我们则要有效收敛。我们的目标是在地图上找到从功能到目标的最短路径。以最少的功能，最快的实现目标或验证假设。影响地图让我们可以更聚焦。
第一：聚焦有限的目标，过滤与目标无关的需求，防止范围蔓延；
第二：在资源有限的情况下，强制做出优先级的判断，选择对实现目标影响最大的需求。
我们做了选择的需求，并完成交付。这就代表成功了吗？显然不是，我们的目的是实现目标，而不是交付功能。成功与否最终还是要看目标的达成情况，而功能只是手段。功能与目标之间还差着两道假设。
第一：我们假设这些功能会产生设想的影响，让用户产生我们期望中的行为；
第二：假设对用户行为的影响能帮我实现目标。这两类假设，在被事实验证之前，只能是假设。
影响地图的一个重要的优点是，它保留并直观呈现上面两类假设。这样，当功能交付后，我们可以也应该去检视影响和目标的达成情况。我们希望引导团队更多关注业务成果，为业务负责，而不仅仅只是交付功能。
所以，功能交付后，我们要基于影响地图去检视影响和目标的达成情况，并作出及时的调整，这样才能形成闭环。之前我们对目标的量化为这一闭环的有效性提供了好的基础，我们应该在交付功能后去收集和有效分析数据，形成数据化的闭环。通过这一套机制，我们希望培养：关注业务结果，数据驱动的实验文化和增长文化。
这一部分也是一个总结。今天我们从什么是产品交付的关键说起，首先告诉大家要关注端到端的价值流动，可视化并促进价值顺畅流动。以此为基础，我们要保证交付的是真正的价值，因此我们要关注真正的业务目标，并保证产品的功能为业务目标服务, 这一过程中，我们需要快速反馈和调整，最终形成一个业务和创新的闭环。我们要做的是如何让这个闭环更加有效，并加速这个闭环。
传统开发方式很多时候是竖井式，每一个部门看上去都很忙，但是从用户的角度去看，需求却有大量的等待，未能形成有效的闭环，或者反馈的周期太长，无法满足互联网创新的要求。我们要做的是：首先要保证闭环的有效和畅通，并在此基础上关注价值和促进价值的流动，加速有效的创新循环，赋能业务创新，为业务的成功奠定坚实的基础。