直播回顾 | 哈啰一站式业产研协同平台的建设与实践

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 或者大数据让我们去提效，而如果公司现在根本就不具备这样的人才做这件事情，那这样的方案必然是不可行的。

• 措施可行：制定的提效方案一定要是可落地的，不要制定一些假大空的东西。

展望未来

我们其实在降本增效做了差不多两年左右，虽然这平台能力是我们建造及推进，但在一些分析上面还不足够，所以我们会在往后从点到线，去拓展更多更大的一个范围，也会更多地和业务去做协同。此外，我们会做更多的数据挖掘，尽可能地发现我们在研发过程中各个环节遇到的一些不管是流程问题还是效率问题，然后去做持续的改进，帮助整个团队不断地提效。

*由于篇幅有限，以上为节选内容，如希望回顾完整讲座，请扫描文末二维码观看回顾视频