阿里妹导读：中国有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%以上”；
金字塔的中间层次是操作和操作流程——为了实现目标，系统需要支持哪些用户操作，这些操作的流程是什么样的。该实例中包含发卡和开卡两个操作，并针对相对复杂的开卡操作画出了详细的流程；
金字塔的底层是业务规则，流程中的各个操作步骤对应的业务规则是什么样的——什么条件下，用户做什么操作，会得到什么样的结果。其中，既包含正常路径——如付款成功后的提示和跳转；也包含异常路径——如连接支付宝失败时的处理。