基金公司最佳实践：如何用价值流分析，洞察研发效能瓶颈？

近日，ONES 受邀参加 QECon 2023 全球软件质量&效能大会（北京站）。在会上，ONES 高级研发总监&首席解决方案架构师陈亮宇，发表了主题为《聚焦价值流分析，寻找研发效能的「北极星」》的演讲，分享 ONES 在 DevOps 实践中的洞见及思考。

陈亮宇在研发管理方向深耕 10 余年，在敏捷管理、DevOps 领域实践经验丰富，成功帮助数百家中大型企业实现高效管理，提升研发效能。本次演讲，他结合 ONES 某知名基金公司的最佳实践，详解如何通过价值流分析洞察研发效能瓶颈，以及如何有效提升研发效能。

阅读本文，你将了解：

• 研发效能提升路径的六大步骤

• 如何通过价值流分析提升研发效能

• 研发中常见的瓶颈阶段及内在动因

01 提升研发效能的关键六步

在聊研发效能之前，想和大家分享一个 AI 小故事：

作为研发出身的我，在 ChatGPT 刚火的那阵子，打算用 AI 写一个运维脚本，很好奇它究竟是如何帮助企业提升研发效能的。我先去了解了 ChatGPT 的前世今生，通过阅读大量的资料和论文理解它的同类和原理，最后再真正上手试用它。

当我做足了功课后，便信心满满地使用 ChatGPT，代码在我的提示词下，很快就产生了。但我发现，这段代码实现的内容与我的需求相差甚远，我开始重新修订提示词，但这时候，我又发现了下一个问题：每次生成的内容有限，我需要不断拆分需求，分批次地生成代码。最终，我发现生成的代码质量并不过关，我又开始和 ChatGPT 沟通如何写好一个单元测试。就这样不断地摸索，终于在一周后完成了这个脚本。

这次经历总的来说达到了我的目的，即通过 AI 完成了一个脚本。但通过一系列的效能分析（写这种脚本的需求产生的频次如何？我原本写这个脚本需要多久？过往写的质量如何？），这次的尝试无疑是失败的。

在黑夜里，想要确定方向，最简单的方法就是寻找北极星，研发效能的「北极星」是什么？就是顺畅、高质量地持续交付有效价值的闭环。在 ONES 服务众多客户落地研发效能实践的过程中，总结出以下六大步骤：

• 评估企业研发管理现状

• 引入管理工具，将研发过程全面落地在工具上

• 价值流分析，明确企业的效能瓶颈

• 设计效能提升的实施步骤和计划

• 建立指标库，并设立提升目标

• 持续改进

02 最佳实践：知名基金公司的效能提升案例

企业往往擅长解决问题，却不擅长发现问题。也就是说，上述提升效能路径的前三步，是企业普遍缺少的步骤。接下来，我将通过一个案例，帮助大家更好地理解如何通过价值流分析洞察效能瓶颈。

该案例来自一家国内知名基金公司的信息科技部门，公司战略规划中明确要求信息科技要围绕核心的投资、营销、运营等领域，构建公司的数字化护城河，提升研发效能。受 DevOps 文化影响，在接触 ONES 之前，该公司全力发展 CI/CD 基础设施建设，效能提升却陷入了困境；公司便很快意识到，DevOps 的概念不仅仅是 CI/CD，而是涉及整个研发管理的全链条。最后，ONES 通过「产品+咨询+服务」三者结合的方式，为其提供了全流程研发管理解决方案。

步骤一：评估企业研发管理现状。ONES 通过规范化、线上化、数字化、智能化四个维度为该公司进行评估：

• 规范化：研发模式是否覆盖所有研发场景，评估研发管理各环节的规范程度；

• 线上化：企业是否运用一站式研发管理平台，承载从需求到交付全流程的流通；

• 数字化：企业是否有成熟的度量模型数据，来持续优化团队能力和交付效率；

• 智能化：企业是否有智能化的决策模型，为研发管理过程提供决策推荐。

步骤二：引入管理工具，将研发过程全面落地在工具上。ONES 咨询顾问通过访谈、回顾会等方式梳理客户的研发管理全流程，并将该公司的研发管理过程从需求调研到业务验收的完整流程全面固化在 ONES 中。

步骤三：价值流分析，明确企业的效能瓶颈。下图是 ONES 最初为其绘制的价值流映射图：业务部向产品部提出自己原始的需求，需求便流入需求池中；当需求的目标、范围确认清楚后，产品经理完成需求的原型图设计及文档分析，并交给 UED 完成 UI 设计。与此同时，产品经理拉齐 UED、研发、测试部门主管一起澄清需求；之后，研发部门将需求拆分为各个研发任务，进入研发阶段。

然而，当我们画完价值流映射图后，发现了三个异常环节，分别处于业务验收阶段、研发阶段以及发布上线阶段。

第一个异常环节处于业务验收阶段。在最后的验收环节，该公司的 C/A 率低至 50%，也就是说，交付的需求有一半都无法通过验收。ONES 通过访谈关键部门，得出以下结论：

首先，需求实现的效果与预期不一致。需求从业务部门提出到研发阶段，中间产生了层层的信息差，无论是需求方案、UI 设计，还是技术方案，业务侧全程未参与，造成了研发资源的大量浪费。

其次，业务侧快速上线的期待与研发排期的冲突。受到研发排期的影响，需要快速响应的需求最终都错过了交付时间。

最后，是跨部门沟通不畅的原因。有时，需求已经暂停了，却未及时告知研发部门，直到验收阶段才被知晓。

第二个异常环节处于研发阶段。如果一个项目的研发周期为 20 天，但真正的增值时间只有 12 天，导致这一现象只有一个动因：跨部门协作不畅。以下图这张计划表为例，每个业务需求被拆解成各个部门的研发需求，客户端的需求基本上依赖中台的研发完成。也就是说，如果研发没有排期，需求的完成就会被拖长，导致大量需求等待。跨部门协作是研发效能中较为常见的问题，解决方案有很多，比如成立虚拟的业务小组、部门统一目标、规划优先级等等。

第三个异常环节处于发布上线阶段。因为 CI/CD 平台的日益完善，该公司的发布阶段只需半小时，但是发布上线的前置时间长达 1 天，流动效率仅为 1%。ONES 对其关键角色进行了访谈，发现了这 1% 的原因：

其一：发布需层层审批，存在各种各样的等待情况；

其二：无论需求的大小，所有需求都需审批；

其三：发布的时间经常不确定，无法前置安排审批时间。

围绕上述 3 个异常阶段，ONES 为客户制定了一系列的提升计划。在执行了一个季度后，该公司的价值流数据发生了很大的变化：整体的流动效率从原本的 69% 提升到 82%，C/A 率也从 87% 提升到了 93%（图中标红数字表示提升的数据）。

03 思考和总结

今天的演讲接近尾声，和大家分享以下几点心得：

• 研发效能和任何变革一样，有低垂的果实，也有边际效应。例如，验收阶段因为信息通知的不及时导致浪费，通过很小改动就能获得提升；同时它也有边际效应，CI/CD 的基础建设固然能提升研发效能，但当工程效能已经不是研发效能的瓶颈时，我们需要慎重考虑是否继续投入。

• 返工是最大的浪费，尤其是交付不符合预期的价值。返工代表的是质量问题，但质量问题不仅仅体现在测试环节，我们将测试左移，从价值流最前端开始关注，此时所产生的浪费是最小的。越到价值流末端的返工、浪费行为就越应该被抵制。

• 不同企业研发效能的目标和路径都不尽相同。专家经验最终也只是参考，需要贴合企业的实际情况来制定效能提升的目标。

• 价值流分析能够有效帮助企业找到研发效能瓶颈，从而将复杂的研发效能提升工程化繁为简。

• 规范化和线上化是价值流分析的重要条件，能够极大地承载价值流数据的获取时间。