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