如何为研发团队打造专属的效能提升路径

近日，ONES 受邀参加 2023 QECon 全球软件质量&效能大会（深圳站）。在会上，ONES 研发效能改进咨询顾问陈仪，发表了主题为《如何为研发团队打造专属的效能提升路径》的演讲。

陈仪有着丰富的咨询经验，曾带领团队深度、完整地参与过全球化的敏捷转型，并帮助客户完成敏捷转型的实践及效能提升。本次演讲，他主要从咨询视角出发，分享自己总结的一套帮助团队提升效能的方法论，同时也会提炼研发效能实践中的常见误区。

想获取完整演讲 PPT 及演讲视频，扫码联系 ONES 产品顾问，回复「QECon 大会」即可领取。

‍效能提升的上限与下限

研发效能是近十年软件研发领域的热门话题。很多软件研发企业或部门，在这个领域投入了大量的人力资源，并设立专职的岗位。

那么，为什么研发效能会得到企业的高度关注呢？

根据持续改进的理念，团队需要被允许停下手头的一些工作，定期回顾团队里存在的问题，思考如何改进。可以说，持续改进是为了让团队变得更好、更有竞争力，防止现存问题拖累团队。研发效能提升也是如此，其目标是让团队更好更快地交付客户想要的产品。

在我看来，提升研发效能是持续改进思想的一种具体表现形式，研发效能的范围也应该是广泛且全面的，不应该将研发效能的理解只限定在某一个或某几个特殊领域。

研发团队所面临的常见问题，主要分为四类：

研发侧的响应能力跟不上业务创新；
研发协作效率低；
系统稳定性难以保障；
缺乏统一的一体化平台。

这些问题凸显了提升研发效能的紧迫性和必要性。经过这些思考，我们再定义一下什么是研发效能。我比较认可的一个观点是：研发效能是顺畅、高质量、持续地交付有效价值的闭环。这个定义里一共包含了五个要点，这里重点解读其中两个要点：

顺畅，代表整个研发团队工作流顺畅，没有浪费，或者说尽量少的浪费、尽量少的等待、尽量少地出现瓶颈。所以，在研发效能实践中，不光要考虑工程侧的实践，还要考虑研发过程侧的实践，比如工作流的优化、研发管理流程的规范。
有效价值，代表交付物是不是客户真正想要的。有时候团队非常努力，但客户并不满意最终的交付物。所以在做效能度量时，需要包含客户价值这个维度。

通过定义，我们可以认为，研发效能是广泛且全面的。然而，我们往往追求研发效能工程侧的实践，比如 DevOps 平台建设、DevOps 工具的使用，而忽略了研发管理过程侧的实践。但后者正是整个研发项目的基础，所以我想提出一个观点：研发协作管理的成熟度，决定了效能提升的下限，同时直接影响了效能提升的上限。

如果把研发效能比作成正在建设的摩天大厦，那么不断提升大厦的层数，从 10 层、20 层到 50 层、100 层，意味着研发效能水平的不断攀升。研发协作管理就是大厦的地基，没有稳定地基的保证，整个研发效能大厦就没办法一直向上建设。

效能提升的必要路径

在我看来，每一个企业、组织、团队都是独一无二的，因此在探索研发效能提升路径时，也要根据团队特性来定制策略。如果将一套普适性的工具推广到所有团队，实际效果一般会低于团队预期，因为普适性的工具与方法，往往不会解决团队的某些具体问题，反而可能带来新的问题。

我把方法论一共归纳为六点，也叫「打造团队专属研发效能提升路径六个实践」：

评估团队现状。只有了解了团队现状，才能量身制定下一步计划；
从痛点、问题出发。优先解决最要紧的痛点和问题，会最大化短期收益；
优化工作流程规范。简化流程、简化浪费，从底层优化效能管理的根基；
逐步工具线上化。从提升局部垂直能力出发，逐步实现全局优化和拉通；
建立度量指标库。度量指标库并不是一次性就能完整建立，因此我们可以从先解决最紧急的问题，之后再不断维护指标库，保证指标库的持续更新，为效能全面度量做基本准备；
持续验证度量收益，打造效能管理闭环，迭代式探寻自身组织最需要的度量指标及工。

通过这六个实践，可以打造一套比较适合自身组织的效能提升路径。接下来我们通过一个客户实例，详细看看每一个实践的具体应用。

研发效能咨询客户案例

这是一家世界 500 强国有独资企业，业务领域涵盖金融、地产、供应链、创新等。它的组织架构为：集团下有科技公司及各个行业板块子公司，比如金融行业、地产行业、供应链行业，部分子公司下设有自己的 IT 部门。我们此次对接的是集团下的科技子公司。

第一步，从规范化、线上化、数字化和智能化四个维度，评估客户团队的现状。具体评估时，每一个大的维度下面也会细分出很多子方向，每一个子方向也会有很多具体的条目。通过和团队一起对每个具体条目的打分（0～5分），最终以雷达图的形式展现全面评估结果，可视化地评估团队在每个维度的现状。

规范化评估，主要针对团队的交付模式规范化的程度；
线上化评估，主要针对研发管理过程侧、工程侧的工具平台化程度；
数字化评估，主要针对效能指标管理体系的成熟度；
智能化评估，主要针对数据驱动战略决策的能力。

通过评估，我们认为案例中客户团队的现状是，在规范化、线上化和数字化上都有初步进展，但是在智能化上相对薄弱。

第二步，我们基于客户现状开始梳理痛点。

比较常见的梳理方式是跟不同关键角色进行访谈，组织群体性工作坊、敏捷回顾会等，尽可能让研发团队高度参与。一方面可以更全面地收集痛点和问题，另一方面团队从问题梳理上就高度参与，之后在推行任何改进措施时，会有更高的主观能动性。

通过痛点收集，我们将客户遇到的问题归纳为三类：

业务数字化转型，急需 IT 项目管理的提升；
团队、不同角色间的协同效率较低；
缺乏统一的研发协作平台。

梳理完之后，我们会形成一个痛点的待办事项，从多个维度去区分问题的紧急性，从而打造下一步的实施策略。

第三步，用价值流图分析（VSM）优化研发流程。通过可视化团队中的工作流程，让团队有更好的视角对目前的工作流进行审视，识别其中的浪费，从而优化整体工作流。

在该客户案例中，我们通过优化组织级的管理规范、项目管理规范，以及一些专门痛点，比如需求管理、测试管理、运维管理等，进行重点优化。当我们把团队的基础性问题解决掉，再去构建效能平台时，就会有一个很好的根基。

第四步，从全局为客户规划效能提升蓝图，按阶段逐步实施。

基于痛点梳理及流程优化，我们为客户团队整体规划了以优化流程规范、整合平台工具、提升持续集成测试能力等为主要方向的效能提升体系蓝图。整个方案实施分为两个阶段：

在第一阶段，从优化现有团队研发规范开始，结合客户现有工具的使用情况，按照最小 MVP 的原则，打造了以 ONES 研发管理平台为中心的初始版研发效能平台，打通企业内部的工具链，实现从业务需求提出到需求实现、发布上线的端到端的集成。此外，在持续集成阶段，我们也将静态代码扫描和安全代码审计作为质量保障的手段。

第二阶段，在持续集成和持续交付能力上，除了静态代码扫描外，我们也集成了更多的质量保障体系，包括接口自动化测试、安全静态扫描、安全动态扫描等一系列功能侧的实践，逐渐提升整个效能体系的质量保证。同时，继续深化效能研发一体化平台，让工具更加集成，为效能度量体系做准备。将优秀实践推广到其他子公司，形成集团级知识财富。

第五步，建立效能指标库。我们通过定义指标体系，包括了指标定义、计算公式、指标意义、数据源以及面向角色等因素的考量，从不同角度来定义指标、维护指标。比如从管理层、项目管理层、业务视角，我们更关注资源投入、项目质量、项目成本，更关注项目周期、交付周期等指标。但是从运维角度来看，他可能更关心故障响应的时效、故障处理的时效等指标。

与此同时，在验证效能指标时，也要先验证紧迫性较高的指标，解决紧迫性较高的痛点。

最后一步，打造效能指标的管理闭环。

通过 MVP 的模式，我们以敏捷迭代的方式，在每个迭代中选取少量指标，结合痛点，优先选取紧迫性较高的痛点，然后以相关指标作为前几个迭代的实施对象，定期分析，形成改进行动项，最终形成闭环。

在每一个迭代中，我们都会按照分析问题、选取目标、选取指标、获取数据、分析反馈、改进落地的顺序去实施。

有了改进指标后，接下来是打造效能指标的管理闭环。

最终极的目标，就是结合我们构建的研发效能一体化平台，实现效能管理的闭环，打造出一个数据驱动的效能度量可视化平台。

通过这样一个平台，我们可以自动化地产出各种视角的效能指标以及结果分析，对整个企业未来的规划产生积极的影响作用。

最后总结一下，通过打造效能提升路径的六个实践，我们为客户打造了一个效能提升蓝图。其中实现路径可以归纳为三个环节：

搭建组织级的流程规范，引入敏捷及工程的相关实践，完成效能提升的基础性准备工作。
以 ONES 研发管理平台为中心，打通上下游的发布平台，形成一体化平台；同时支持稳敏双态的项目管理，也就是敏捷和瀑布双模式的项目管理能力。
利用数据驱动效能改进闭环，打造出一个比较成熟的效能管理平台。

通过这三个环节，我们帮助客户在不到一年的时间里就打造出了效能平台的雏形，帮助客户的研发管理规范得到了进一步提升，同时也提升了研发管理体系的成熟度。未来，我们也会继续帮助客户进行研发管理工程侧的工具平台及度量体系建设。

研发效能实践中的常见误区

第一个误区是期望「快餐式」的「拿来主义」。

很多客户期望通过直接引进其他厂商在效能提升上的优秀实践，在短时间内复制出类似的效能收益。这样做，往往会忽视了解和优化自身研发管理规范的重要性，也低估了新工具在团队内部推行的阻力及学习成本。

一般来讲，将普适性的工具引用到团队中，最后往往只是接入了工具，并没有真正使用起来。所以通过合理的方法完善研发管理流程规范，逐步通过一些试验性实践，摸索出最适合自身组织的效能提升路径才是正解。

第二个误区是迷信单点局部工具能力。

单点局部的工具，在研发初期往往很有收益，因为它可以帮助我们解决很多具体问题，尤其是那些优先级较高的问题。但是随着研发效能进程的不断深入，单点工具的收益会随着时间逐渐递减，因此企业需要从更高的视角出发，对研发效能的一体化平台进行整体规划。

第三个误区是伪工程实践，为了做而做。

很多团队里充斥着伪工程实践，为了做度量而做度量，为了做公司的实践而去做实践，然而团队可能没有真正了解这些实践应用的真实意义。一个原因是团队的思维还没有跟上效能工具和实践的升级，导致很多工程实践在团队中的应用是被动的，而不是主动的。

另一个原因是，某些团队的效能指标直接与绩效指标挂钩，导致成员为了提高绩效而做一些假数据。

很多团队缺的不是工程实践的数量，而是工程实践执行的深度和态度。所以我也建议，在梳理痛点的时候，最好是由团队整体来参与。从一开始就培养团队的参与感，避免伪实践情况的发生。

第四个误区是试图提升研发效能的绝对值。

提升研发效能的绝对值，在现实发展的趋势下，这是一个不合理的现象。因为随着企业规模的壮大，研发团队的规模也在不断扩张，由此带来的团队内部沟通成本、协作复杂度，也会成倍增长。加上软件架构的复杂度也在不断攀升，最终研发效能的效果很难保证一直是上升趋势的，它在某一个阶段肯定会有所下降，或者产生波动。在这种情况下，我们能做的，就是尽可能地减缓研发效能恶化的速率。