阿里妹导读：中国有3000万卡车司机，他们每天开车12-16个小时，发生事故导致身亡的概率是普通人群的5倍。路歌旗下的“卡友地带”是中国最大的卡车司机交友互助平台，有超过150万的卡车司机在上面活跃。

“卡友地带”却在运行两年后，遭遇到产品交付和创新的双重困境，阿里资深技术专家何勉了解这件事情后，与卡友地带团队同甘共苦，帮助团队提高效能。今天，我们请到何勉为我们讲述背后的故事，你将看到我们应用了哪些核心实践，如何帮助团队数量级地提高交付响应能力，赋能业务创新。

“10个月、15亿营收”，这是路歌网络在新业务卡加优选[1]上取得的成绩。支持这一业务开发的是由6名技术和1名产品组成的全新团队，他们与业务人员紧密协作，从规划新业务、组建团队，到累计完成15亿销售额，只用了10个月[2]。
根据尼尔森[3]每年发布的突破创新报告，统计2012年到2016年全球上市的2万多种创新产品，其中只有92个在第一年内销售达到5000万美元（约3.5亿人民币）且次年还能持续。产品从0到1，“10个月，15亿”， 即便放眼全球这也是一个奇迹。

图1：路歌在卡加优选实现了巨大的业务成功

然而，在开展此次业务前，他们正遭遇产品交付和创新的双重瓶颈。每一到两个月发布一次正式版本，速度、准时性、质量都受到强烈挑战；更糟糕的是，交付内容满足不了用户和业务的需要，产品研发和业务团队之间相互质疑成为常态，商业化也一再受挫。社会意义巨大的公益产品“卡友地带”[4]随时可能被迫关闭，团队前景一片黯淡。

从那时起，我先后以个人和阿里云咨询顾问的身份，帮助路歌设计和实施精益产品交付和创新体系，并以 Teambition [5] 为工具承载了这一体系。“卡加优选”是它结出的第一个果实。

本篇将讲述“精益交付”的具体实践和落地过程。产品交付和业务创新都遇到瓶颈时，应该从哪里破局？在路歌，我们的选择是：从提升交付能力开始。因为没有高效交付的支持，再好的业务创新也难以落地。提升交付能力也是改善业务和技术团队协作的突破口。

1. 交付能力改进从改变认知开始

团队当然知道提升交付能力的重要性，为此也做过很多努力，但效果总不理想或者不可持续。这一次不同的是：我们决定从改变认知开始，先建立共同的认知，再落地配套的实践。我们将介绍其中的两个核心认知的改变。

1.1 认知1：打破效率竖井，从追求资源效率到优化流动效率

产品交付是一个系统工程，需要前后职能的协作，如：业务、产品、开发、运维等协作；同时也需要平行部门的协作，如：前端、后端、中台等的协同。传统产品开发方法，更多关注各个职能和部门的独立改进。

图2：效率竖井是交付效能低改进困难的深层次原因

上图反映了路歌当时的产品交付状况。每个部门看上去都很繁忙，认为自己的效率很高。它们各自从自己的角度优化。然而，过度的局部优化反而会损害整体效率。

图中下方的折线反映一个典型需求的交付时间历程。绿色短线表示需求正在被处理，红色长线表示需求在等待中。结果，实际工作不到两天，交付周期却超过1个月。

这就引出看待效率的两种不同视角。从组织的视角看，各个部门关注自己的 “资源效率”——如资源的使用率、本环节的产出等。从用户和业务的视角，我们更应该关心的是价值的 “流动效率”—— 需求的流动过程是否顺畅，需求从输入到交付的过程是否足够快。

在上述情况中，各个部门看上去都很繁忙，资源效率很高；但用户或业务感知到的却是另一回事，需求响应却十分迟缓，流动效率很低。我们称这一悖论为“效率竖井”。

效率竖井：由过度强调和优化局部的资源效率导致，表现为：各个环节和部门繁忙而“高效”，业务响应速度却很低。

 “效率竖井”延长了交付周期，损害业务响应能力。更重要的是，它掩盖系统性的问题，阻碍交付效能的改进。现实中，损害交付效能的往往都是系统性问题，如：公共环境的维护、跨职能的协同、集成和发布的效率、接口的对齐、质量改进等。系统性的问题需要系统性的解决方案，不能靠局部视角和信息来解决。事实上，最顽固的问题都不在局部。

“效率竖井”是组织效能低和改进困难的共同原因。打破效率竖井，是交付效能改进的关键。要想打破效率竖井，我们就必须转换思路——从追求“资源效率”，转化以“流动效率”核心，提升团队持续交付价值的能力。

聚焦流动效率，帮助组织即时暴露阻碍顺畅流动的问题，如：组织的协同、流程制度、持续交付工程能力、技术和应用架构等，这些往往都涉及系统性和深层次的原因。也只有解决深层次的问题，才能真正提升交付效能。

1.2  认知2：单位时间有效尝试的次数是业务创新的“黄金指标”

路歌是一家产业互联网公司，主业是干线物流服务。产业的特征决定其产品比纯互联网应用复杂；互联网和产业结合的全新模式，决定其不确定性比传统产业高很多。

面对复杂和不确定的环境，产品研发团队要具备怎样的能力，才能支持业务创新呢？我们认为：“单位时间内可以进行的有效业务尝试的次数”，这是衡量产品交付对业务创新支持的黄金指标。

“有效尝试”指通过交付产品得到（Earn）价值或从中学习（Learn）——如：学习用户的真实诉求，学习现实中可行的业务逻辑。我们称其为Earn or Learn——得到或学到。这才是有效尝试的标准，要让尝试有效，就必须事先定义需求要达成的目标，明确需求设计背后的假设。产品交付后，则要分析这些目标与假设，即时调整产品设计或商业模式。

创新能力的黄金指标：“单位时间内可以进行有效业务尝试的次数”，这是衡量产品交付对创新支持程度的黄金指标，而得到或学到是定义“有效”的标准。

从“单位时间内的有效尝试的次数”这一指标看，路歌过去的产品交付是有问题的。首先，能尝试的次数太少。一到两个月的版本周期，一年可以尝试的次数不超过10次，对于开创全新商业模式，这是不够的。

相比尝试的次数，有效性问题更大。路歌过去的产品开发模式，更多聚焦功能交付，确定一个商业模式后，就不断的添加功能。中间会有调整，但缺乏主动和刻意的学习，成功极大依赖于初始商业模式和产品的设计。

面对高度不确定的业务，再好的创新想法也必须通过不断迭代才能成功落地。忽略这一点，是卡加优选商业化受挫的重要原因。增加“单位时间有效尝试次数”才能提升找到成功之路的机会，这是产品技术团队支持业务创新的必由之路。

2.  团队赋能实践

建立共同的认知很重要。但，停留在口头的认知，不会改变任何东西。关键是如何把它们落地为具体的实践。通过系统的赋能实践和工具，团队将认知转化为了行动。接下来将介绍其中最核心的3个赋能实践。

2.1  赋能实践1 —— 可视化并管理端到端的价值流动过程

“以流动效率为核心，提升团队的持续交付能力”。为了做到这一点，首先要让团队看到需求的流动过程。

图3：基于 Teambition，可视化端到端产品和业务价值流

我们做的第一步是可视化价值交付过程，上图是基于 Teambition 工具的可视结果，我们称之为价值流看板。它与常见的任务看板不同，任务看板更多从资源视角出发，关注每个人在做什么，优化的目标主要是“资源效率”。而价值流看板关注的是端到端的价值流动，优化的目标是“流动效率”。

端到端的价值流可视化必须做到：

• 价值驱动——每一个流动单元（看板上的卡片）都是体现完整用户价值的业务需求；
• 前后拉通——可视化的目标是 “端到端”的价值流，前一个端指：从用户问题（或业务设想）的提出开始；后一个端指：到用户问题被解决结束。始于用户、终于用户。

图4：基于 Teambition，可视化端到端产品和业务价值流（放大图）

上图是放大后的 Teambition 截图，它拉通和可视化了端到端的价值流，让团队看到价值流动的整个过程，以及其中的等待、阻碍和积压。有了这一基础，团队可以关注整个流动过程的全局，即时处理过程中的问题。通过全局和系统的优化，来缩短交付周期和提高价值流动效率。

价值驱动，前后拉通：为改进流动效率，团队首先要可视化端到端的价值过程。其核心是要做到价值驱动——可视化用户价值的流动，前后拉通——可视化从用户问题提出，到解决用户问题的端到端过程。价值驱动，前后拉通，是系统改进的基础。

团队的业务规划、过程管理和业务反馈等，都是基于价值流开展的。关于具体的操作细节，本文不再展开。感兴趣的同学可以阅读我2017年出版的图书《精益产品开发：原则、方法和实施》[6]。也推荐你点击文末“阅读原文”，看我们精心制作的《研发效能提升和敏捷实施36计》系列视频[7]。

2.2  赋能实践2 ——控制并行，加速业务需求交付

接下来我们要做的是加速团队交付。路歌有多条产品线，每个产品线对应3到5个交付团队。交付团队都是全功能的，一般在10人以内，有自己的开发、测试和产品负责人，可以完成端到端的需求交付，包括需求分析、开发、测试和交付。

图5：从产品线看板到交付看板的分层管理

上图是我们设计的基于 Teambition 的分层看板机制，它由产品和交付两个层次构成。

1）产品层：管理产品线所有的需求。每条产品线（如卡加车服产品线）使用一个端到端的价值流看板，包含产品线的全部业务需求，反映它们端到端的交付过程。产品层的目标是：端到端的流动效率，并形成价值反馈闭环。

2）交付层：管理团队的交付过程。每个团队（如卡加优选交付团队、卡加优车交付团队等）维护一个交付看板，接受产品层分配来的需求。交付层的目标是：快速交付业务需求，并保证过程质量。

这两个层次是如何关联的呢？产品层的需求进入“等待开发”列后，会被手工分配到开发团队。我们用了 Teambition 的卡片复制功能，将产品的需求复制一份到对应的开发团队，并自动建立与产品层原始需求的关联。

需求进入开发团队后，开发、测试和业务会共同澄清需求，定义验收标准。然后，由团队将需求拆分为具体的任务，开始开发。需求开发完成后，产品看板上对应的需求也会变更状态。

交付层的目标是快速交付业务需求，并保证过程质量。为了做到这一点。我们规定，团队同时最多只能并行3个业务需求。实际运行下来，更多时候团队只会并行1到2个需求——一个需求在验收和上线准备中，另一个需求启动或开发中。这样做有什么好处呢？

首先，团队聚焦到有限的事务上，减少了工作切换、相互等待和积压，需求交付的速度明显加快。背后的道理是不言而喻的，并行两个需求，和并行10个需求，其交付周期是完全不同的。实际中，我们做到的结果是，需求交付周期（从分配到团队到上线）普遍小于1周。

其次，更有意义的是，在这一模式下，过去隐藏的问题被暴露出来了，如外部依赖问题、团队协作问题、缺陷处理不及时的问题、集成和交付问题都显现出来。过去团队可以忽略这些问题，选择并行去做其它事，但这些问题对效率的影响却是真切的。限制并行，让团队对必须面对和解决这些问题。如果问题一再出现，就必须系统地解决根源问题，也只有解决这些系统性的问题，交付效能才能持续提升。

最后，交付的质量得到了根本提升。得益于“实例化需求” （下一节介绍）实践的推广，在开始开发前，测试、开发和业务，共同定义需求验收标准，建立一致的理解。而有限的并行，让团队必须处理完一个需求，完成测试并修复所有缺陷后，才开始下一个需求。这样就避免了缺陷的累积，让系统始终处于一个质量良好的状态。过去一直困扰团队的交付的质量问题，几乎是在不经意间就得到了解决，这对团队和管理者都是一个“意外”的惊喜。可以说：实例化需求再加上即时发现并处理缺陷，是质量提升的“金手指”。

控制并行，加速交付：控制团队并行开发的需求数量，可以缩短交付周期，即时的暴露系统问题，并提高交付质量。

 产品层和交付层看板的共同特点是：它们都以价值流动为核心。两者相互配合，改进端到端的价值流动效率。

2.3   赋能实践3 —— 以终为始，通过实例化需求改善协作和质量

前面引入的两个实践更多是关于协作流程的。光有流程不够，团队还需要更具体的操作实践赋能，比如需求和质量保障实践等。在这类实践中，“实例化需求”是最具撬动作用的。

实例化需求的英文是Specification by Example，简称 SBE，直译过来就是用实例说明需求，它发生在需求进入开发之前。这时，业务（含产品）、开发和测试人员共同参与，以实例的形式澄清需求的验收标准，并达成一致的理解。

图6：团队通过实例化需求实践共同澄清需求，做到以终为始

上图中的三角描述了“实例化需求”的核心概念，首先，业务、开发和测试在一起，用例子来分析和澄清需求；其次，这些例子将来会转化为测试用例；最后，需求开发完成后，再通过测试来验证需求。如此形成闭环，这个三角就是实例化需求的过程。

图7：实例化需求的金字塔结构

实例化需求的本质是“以终为始”：“以终为始”是实例化需求的本质。它指的是在开发开始之前，团队就最终做成什么样达成一致的理解，并成为产品开发的依据和测试验收的标准。

实例化需求的概念不复杂。它成功的关键是，需求澄清的效率和效果，“卡加优选”团队都做到了。上图是团队实例化需求的例子，我们用金字塔的结构来组织需求澄清的过程：

• 金字塔的顶端是需求的目标，也就是解决什么用户或业务问题。例如图中的目标是：“通过发卡和开卡流程的设计，让司机实名开卡率达到40%以上”；
• 金字塔的中间层次是操作和操作流程——为了实现目标，系统需要支持哪些用户操作，这些操作的流程是什么样的。该实例中包含发卡和开卡两个操作，并针对相对复杂的开卡操作画出了详细的流程；
• 金字塔的底层是业务规则，流程中的各个操作步骤对应的业务规则是什么样的——什么条件下，用户做什么操作，会得到什么样的结果。其中，既包含正常路径——如付款成功后的提示和跳转；也包含异常路径——如连接支付宝失败时的处理。

图8：实例化需求重构了团队的协作模式和开发流程

实例化需求，不仅改变了需求分析过程，还真正改变了团队协作方式。上图描述了实例化需求对产品开发过程的影响。

• 需求进入开发团队的队列（等待开发）后，业务、开发和测试立即通过实例化需求活动澄清需求，用结构化的方式生成需求的验收标准。
• 实现过程中，开发实现这些需求的同时，团队将这些实例自动化，功能实现和自动化测试开发同步完成。
• 实现完成后，团队用加工好的自动化或手工测试来验收这些需求。

以上形成的循环被称为“验收测试驱动开发（Acceptancetest Driven Development）”，它重构了开发过程。不但提高了需求输入和产品交付的质量，还大幅提升了各个角色的参与度和协作意识，交付效率也随之改善。

以上介绍了3个核心赋能实践，它们是最基础和最具撬动作用的。得益于这些实践的带动，团队还不断改进及引入其它实践，包括：持续交付实践，持续改进方法以及自动化测试策略等，这里不再展开，同样请参考其他文档[6] [7]。

3.  交付能力的精进——精益交付能力赋能业务创新

认知的改变，流程和协作实践的赋能，加上有效的实施，团队交付能力随之精进。

图9：基于 Teambition 开放平台定制开发的度量系统——团队血槽系统

上图是路歌基于 Teambition 开放平台定制开发的度量平台，其中每一行是一个业务需求。团队称这一度量平台为血槽系统，它虽然简单，却系统反映了团队交付的速率、质量和有效性。

我们看到，业务需求交付周期中位数小于一周，上线后都分析反馈了业务结果，形成假设-验证-调整闭环，做到“得到或是学到（Earn or Learn）”。

图10：卡加优选，10个月内的迭代和发布次数

还是以卡加优选团队为例，10个月内我们进行了52次迭代，48次发布，比过去有5至10倍的提升。更关键的，每一次迭代都有明确的业务目标，形成业务改进反馈闭环。可以说，每一次迭代都是一次商业进化。团队对迭代的本质有了新的认知：

迭代的本质是商业进化：迭代的本质不是时间盒，更不是功能的堆砌，而应该是商业进化——交付明确的商业目标，并形成反馈，持续的进化。这样的迭代能力，是产品技术对业务创新的最大支持。

迭代周期缩短，每个迭代都是一次商业进化，结果是“单位时间有效的尝试次数”这一业务创新的黄金指标，得到了数量级的提升，业务创新成功的希望被再度点燃。

4. 总结

路歌公司CTO兼“卡友地带”创始人叶圣在回顾卡加优选的成功时说：

“15亿营收固然值得自豪。但，远比营收重要的是：我们建成了跨越企业边界的营销服务体系，奠定了未来商业形态的基石；远比前两者都重要的是：过程中建立了强有力的精益交付和精益创新的实践体系，成为公司未来业务拓展和增长的原动力。”

从改变认知，到实践赋能、工具落地，团队实现了交付能力的精进。10个月、52次迭代的极致交付能力，加上精益创新方法，让10个月、15亿营收成为现实。

参考资料：

1. 路歌网络是一家互联网物流企业，卡加车服是路歌旗下，面向干线卡车司机提供商业化服务品牌。卡加优选作为卡加车服的子品牌，为卡车司机提供高性价比的包括油料、ETC、耗材、生活物资等在内的商品 。
2. 之所以是10个月，是因为公司财年在2月底结束。从18年4月组件团队，到19年2月底财年结束，统计财年的结果，前后正好10个月。
3. 数据引用自《哈弗商业评论》2016.09期中的《洞悉客户的“待办任务”》一文，作者统计了尼尔森每年发布的《突破创新报告》中的数据。尼尔森是全球排名第一的市场研究公司。
4. 卡友地带是路歌旗下面向卡车司机公益产品，提供内容、社群和司机间互助服务，拥有极高的用户粘性、美誉度和用户忠诚度。
5.  Teambition 是阿里云旗下的一款协作类产品，它帮助组织以数字化的方式高效协作和达成目标，产品开发、交付及创新是 Teambition 支持的一个重要场景。我本人在负责阿里巴巴研发效能团队方法学小组的同时，还担任 Teambition 客户成功首席咨询顾问，为 Teambition 外部客户提供咨询服务，路歌网络是Teambition产品以及咨询服务的客户。
6. 《精益产品开发原则、方法与实施》，何勉，清华大学出版社，2017-08-01
7. https://www.teambition.com/article/agile

原文发布时间：2019-12-13
作者：何勉
本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。