共计 7138 个字符，预计需要花费 18 分钟才能阅读完成。
“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 期中的《洞悉客户的“待办工作”》一文，作者统计了尼尔森每年公布的《冲破翻新报告》中的数据。尼尔森是全球排名第一的市场钻研公司。
卡友地带是路歌旗下面向卡车司机公益产品，提供内容、社群和司机间互助服务，领有极高的用户粘性、美誉度和用户忠诚度。
Teambition 是阿里云旗下的一款合作类产品，它帮忙组织以数字化的形式高效合作和达成指标，产品开发、交付及翻新是 Teambition 反对的一个重要场景。我自己在负责阿里巴巴研发效力团队方法学小组的同时，还负责 Teambition 客户胜利首席征询参谋，为 Teambition 内部客户提供咨询服务，路歌网络是 Teambition 产品以及咨询服务的客户。
《精益产品开发准则、办法与施行》，何勉，清华大学出版社，2017-08-01
https://www.teambition.com/ar…
【对于云效】
云效，云原生时代一站式 BizDevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。
立刻体验
