10个月,15亿,阿里云如何赋能企业打造交付和创新竞争力?

简介: 中国有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亿”, 即便放眼全球这也是一个奇迹。

01.jpg

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

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

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

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

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

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

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

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

02.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 团队赋能实践

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

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

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

04.jpg

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

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

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

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

05.jpg

图4:基于 Teambition,可视化端到端产品和业务价值流(放大图)

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

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

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

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

接下来我们要做的是加速团队交付。

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

06.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

07.jpg

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

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

08.jpg

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

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

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

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

09.jpg

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

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

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

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

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

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

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

10.jpg

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

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

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

11.jpg

图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期中的《洞悉客户的“待办任务”》一文,作者统计了尼尔森每年发布的《突破创新报告》中的数据。尼尔森是全球排名第一的市场研究公司。

  1. 卡友地带是路歌旗下面向卡车司机公益产品,提供内容、社群和司机间互助服务,拥有极高的用户粘性、美誉度和用户忠诚度。
  2. Teambition 是阿里云旗下的一款协作类产品,它帮助组织以数字化的方式高效协作和达成目标,产品开发、交付及创新是 Teambition 支持的一个重要场景。我本人在负责阿里巴巴研发效能团队方法学小组的同时,还担任 Teambition 客户成功首席咨询顾问,为 Teambition 外部客户提供咨询服务,路歌网络是Teambition产品以及咨询服务的客户。
  3. 《精益产品开发原则、方法与实施》,何勉,清华大学出版社,2017-08-01
    7.https://www.teambition.com/article/agile
目录
相关文章
|
7月前
|
存储 缓存 数据挖掘
Flink + Doris 实时湖仓解决方案
本文整理自SelectDB技术副总裁陈明雨在Flink Forward Asia 2024的分享,聚焦Apache Doris与湖仓一体解决方案。内容涵盖三部分:一是介绍Apache Doris,一款高性能实时分析数据库,支持多场景应用;二是基于Doris、Flink和Paimon的湖仓解决方案,解决批流融合与数据一致性挑战;三是Doris社区生态及云原生发展,包括存算分离架构与600多位贡献者的活跃社区。文章深入探讨了Doris在性能、易用性及场景支持上的优势,并展示了其在多维分析、日志分析和湖仓分析中的实际应用案例。
519 17
Flink + Doris 实时湖仓解决方案
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
4845 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
11月前
|
敏捷开发 供应链 数据可视化
如何利用精益生产管理工具提升项目执行力?推荐7款必备工具
本文介绍了七款精益生产管理工具,包括板栗看板、LeanKit、Targetprocess、Miro、Smartsheet、Airtable 和 LiquidPlanner,详细阐述了各工具的功能亮点及其在不同行业的应用,旨在帮助企业提高效率、减少浪费、优化流程,实现项目管理的持续改进。
如何利用精益生产管理工具提升项目执行力?推荐7款必备工具
|
缓存 数据可视化 机器人
07 ROS的TF坐标管理工具
本文详细介绍了ROS(机器人操作系统)中TF(Transform)坐标管理工具的使用方法,包括如何监听和广播坐标变换消息,使用相关命令行工具查看TF关系,以及如何通过编写节点代码来创建TF广播器和监听器,并展示了如何在launch文件中配置TF相关的节点。
516 0
|
12月前
|
供应链 监控 数据可视化
精益生产是什么,如何将精益生产应用于项目管理?
本文介绍了精益生产的基本概念、历史发展及其在项目管理中的应用,强调了精益生产通过消除浪费、提高效率和质量来降低成本、增强企业竞争力的作用。文章还特别介绍了板栗看板作为精益生产工具在项目管理中的具体应用,包括项目进度管理、任务分配、问题跟踪及团队协作等方面,展示了其可视化、实时性和灵活性的特点。
精益生产是什么,如何将精益生产应用于项目管理?
|
数据采集 人工智能 自然语言处理
AI战略丨赋能更好的教育, 大模型应用再提效
采用成熟厂商的解决方案,不仅仅是因为过硬的技术,还有对客户业务的理解,以及顺畅的沟通和服务能力。
|
12月前
|
JSON 数据可视化 小程序
uview/小程序可视化表单代码生成器文档
uview/小程序可视化表单代码生成器文档
150 0
|
Unix Python
python 的标准库模块glob使用教程,主要为glob.glob()使用与glob.iglob()使用
python 的标准库模块glob使用教程,主要为glob.glob()使用与glob.iglob()使用
458 0
|
数据采集 监控 BI
C#实验室检验LIS信息系统源码 微生物检验、质控维护
LIS系统的主要目标是为检验室开展检验工作提供更加有效的系统支持。该系统将尽量减少以人工操作的方式来实现信息转移,减少在接收检验项目、报告结果和保存记录等工作中可能会出现的人为误差,为检验结果查询提供更有效的方法,节省了管理信息所需的琐碎时间和精力。为实验室技术人员提供智能化的运行模式,使处理诸如按照规程审核检验结果、取消检验项目、分析、处理存在重大疑问的检验结果、执行特殊的命令和处理质量控制等问题更轻松自如,这将使检验人员更快地获得准确清晰的检验结果。为临床医护人员提供在线设施,使他们可以及时准确地获得相关实验室信息。确保检验结果的可靠性和准确性,利用实验室管理信息系统的仪器监控和质量控制,
158 0