10 月 26 日,思码逸 DevData Talks 邀请到了哈啰出行研发效能团队负责人高明国。他多年来负责公司业产研协同平台建设、效能度量工具体系建设、测试效能工具建设、稳定性工具建设、质量流程规范管理等。他这次为我们带来的主题是《哈啰一站式业产研协同平台建设与实践》,分享如何通过一系列效能方案与最佳实践后,帮助公司解决降本增效的难题。
由于篇幅有限,本文仅整理总结了演讲亮点,如果大家希望了解更多细节,可在文末扫码获取PPT、观看视频回顾。以下为文字回顾:
1. 面临的困境
2. 建设方案
3. 落地实践
4. 展望未来
面临的困境
首先,如下图所示,是哈啰降本增效背景下组织面临的困境。左侧一类为管理困境,右侧一类为质量和效率困境。
管理困境主要分成三点:
-
企业管理团队困境
-
业务团队困境
-
项目管理困境
质量和效率困境主要分成三点:
-
产研协同的困境
-
交付团队的困境
-
效能度量的困境
建设方案
我们制定了高效交付体系化协同解决方案,主要经历了三个步骤,即标准化、线上化和数字化。
第一步,将流程标准化后,再通过我们线上系统的能力去承载这些流程,让这些流程商当中的关键节点变成我们平台上的一个能力,或者平台上的某一个关键节点,让整个研发过程的数据能够标准化且沉淀下来,最后则基于这个数据去做度量,做词语改进。
接着,我们能看到如下图的战略一致性,其实战略一致性主要就是为了让组织目标能够更加聚焦,资源投入能够更加地清晰。在业务层面和交互层面,实际上我们去落地组织层面规划战略的一些目标,即我们通过建设一个战略,能够让管理人从纵横业务和横向部门的交叉去分析,然后管理我们资源投入,去监控它到底有没有异常。因此,我们在这里做了四件事情:
-
业务分组
-
战略规划
-
目标关联
-
兵力监控
哈啰为什么会选择项目协同呢?这是因为项目里面很重要的两点特性,一个就是聚焦,一个就是价值。我们通过项目协同可以很清楚地知道这个项目实现了什么价值,能给业务带来什么价值,也能让我们做事更加聚焦。
在哈啰,我们将项目分成两大类型:
-
战役项目
-
非战役项目
两个战役项目包含立项专项的和需求集项目,以及日常支持。立项专项主要是一些比较大且比较重要的项目。需求集项目则是像一些迭代,例如系统已经建完了,但可能在后面进入到一些 bug 的修复或者小需求,我们就会将它放入需求集项目里面。而日常支持,比如针对用户使用过程中遇到的一些问题,我们也许会做一些QA或者技术支持,就会放入日常支持里面。
业产协同是通过一套产品化的方案,让整个业务和这个产品能够通过平台去进行衔接,让业务在平台上去提交你的MRD,然后产品去承接这个对应的MRD,再通过MIE和我们的这个变更去关联,将整个链路串起来。
落地实践
在精细化运营中,能看到我们从战略规划层面做了以下几点:
-
组织效能
-
项目协同
-
持续交付
-
工程能力
-
生产质量
组织效能方面,我们能通过数据评估资源投入和目标规划是否匹配,当前项目是否存在风险,关注支撑目标项目资源健康度,亦或是分析各项目是否进入价值回收阶段,以使我们能及时做出正确决策。
另外,由于我们整个项目过程全都线上化,所以我们会在项目过程中定义哪些是属于项目异常,然后通过巡检把它自动推到我们的个人工作台上面,以及在钉钉群里面也会生成告警,并且会通过经营驾驶舱管理我们整个项目的一个健康度。
此外,我们也会进行质量管控,我们会关注一些当前阶段核心的指标,然后通过质量数据的稳定提升,能够让当前流程和其团队能够更加适配,研测和协同能够更加紧密。
效率分析指的是在资源变化较大的情况下,使用个体度量更合适,比如:
-
研发测试交付时长比:体现测试成熟度、环境稳定性、测试工具的完善。
-
人均交付需求数:参与度越高说明测试团队需求吞吐能力越大。
-
需求参与度:短期内测试参与度越高,说明覆盖的需求更多,生产漏测风险更小。
针对紧急发布以及发布失败,我们也在做持续的治理。如下图所示能看到我们在21年的发布成功率在94%左右,直到23年已近97%左右。同时,也能观察到生产紧急发布和回滚发布数据在急剧下降,这说明我们紧急发布和回滚发布量逐渐变少。这是因为我们通过以下几点流程提升了发布效率:
-
落地发布计划
-
优化平台能力
-
拉通上下游依赖
-
收口部署权限
在我们面临的困境中,由于我们缺少相关的内容规范,因此整个APP发版经常会有延期的情况,所以我们制定了如下图APP发版的流程规范,通过定标准、设卡点,然后跟进过程且抓结果,最后做分析改进。
最终在生产质量上,我们会通过后事前监控、事中应急、事后复盘去做持续改进,例如:
-
基于工程变更的问题上报机制:对所有的生产,所有的变更进行统一管控。
-
生产问题的快速定位:能够在发现问题的时候进行5分钟的生产问题聚合,以便能做快速的回滚。
-
故障SLA检测:针对生产的故障做四个复盘,复盘完了以后会去做SLA故障检测,包括SLA目标达成的一个情况。
-
故障复盘持续改进:将所有的故障录入系统后,持续跟进系统生成的所有改进项,确保落地所有改进项。
总结
简要总结几点做度量的建议:
-
数据可信:如果你所生产的研发过程中产生的数据都是模糊的,或者都是不准确的,那将是没有办法去做度量的。
-
人才可用:比如公司说要通过AI或者大数据让我们去提效,而如果公司现在根本就不具备这样的人才做这件事情,那这样的方案必然是不可行的。
-
措施可行:制定的提效方案一定要是可落地的,不要制定一些假大空的东西。
展望未来
*由于篇幅有限,以上为节选内容,如希望回顾完整讲座,请扫描以下二维码观看回顾视频
The End
如果你觉得这篇内容对你挺有启发,请你轻轻点下小手指,帮我两个小忙呗:
1、点亮「在看」,让更多的人看到这篇满满干货的内容;
2、关注公众号「哈啰技术」,可第一时间收到最新技术推文。
如果喜欢就点个👍喔,有您的喜欢⛽,我们会更有动力输出有价值的技术分享滴。
本篇文章来源于微信公众号:哈啰技术
本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。