案例背景

快速扩张期，软件架构和人员协作复杂度上升

戴尔科技集团主要为企业客户提供数据存储、资讯安全、虚拟化、云计算等用于存储、管理、保护和分析大量数据的 IT 产品和服务。

戴尔科技集团旗下的 VxRail 团队正处于规模快速扩张阶段，也面临着扩张期研发组织的典型效能挑战。在这一阶段，业务持续增长，对研发交付能力提出更高的要求；但事实上，研发效能的趋势却往往与期望背道而驰——软件系统和组织结构变得复杂，沟通协作成本上升，管理可见性下降。

VxRail 团队希望通过建设研发效能度量，保持效能现状看得透，瓶颈风险说得清，在团队扩张的同时，保持研发效率的超线性增长。

基础设施建设：一套度量数据，服务于不同角色及场景需求

研发效能需要组织上下不同角色共同参与。只有符合角色需求、指向明确结论的效能数据呈现，才能给使用方带来有价值的信息，争取到更多内部成员支持。

戴尔科技集团 VxRail 团队自建了研发效能平台，并在平台封装了其业务交付逻辑与流程，将思码逸及其他来源的效能度量数据统一汇集到平台层。同一套效能数据，在不同角色、不同应用场景下会呈现为不同指标和数据视图，以满足场景化的需求。

思码逸解决方案

以编码环节的量化指标为基础，客观认知研发效率现状

要改进研发效率，团队需要首先客观认知研发效率的现状如何，哪个环节存在风险。然而，随着团队规模扩大至超过过往的管理半径，依靠体感评估“效率”不再奏效，也往往会受到团队成员的质疑。

思码逸帮助 VxRail 团队引入了编码环节的工作量指标——代码当量，作为其研发效能平台的首批指标之一，为研发效率的评估提供数据抓手。

首先，代码当量指标可以挤掉代码中的水分，避免代码移动、增删等行为带来工作量的大幅波动，更加科学合理。

其次，代码当量直接从代码中解析出工作量信息，能够在保障清晰可信的同时，以较低成本快速开启效能度量。在效能建设早期，这一指标可作为切入点，帮助团队客观认知研发交付现状，建立起效率目标共识。

最后，代码当量指标健壮性较强，不易受噪音影响。因此可作为校准其他指标的抓手，与上游的需求环节、下游的评审、测试、交付环节交叉分析，帮助研发团队逐步建立起全流程的效能度量。

合理分配研发资源，让人力成本变成切实的效率改进

当现有产能无法支撑日益增长的业务需求时，用招聘补齐人力缺口是最简单直接的解决方案，但简单直接不等于有效。

为了使资源投入转化为切实的效率改进，VxRail 团队借助思码逸制定了“三步走”方案：

1. 盘点人效和交付效率，理解研发资源现状

借助产出导向的结果性指标（代码当量与需求交付数），研发管理者可以了解整体产能现状，并根据产品线团队、地区、职级、在职时长等属性进行分组分析。

同时，管理者可以从产品线/项目的维度，看效率是否符合预期：新项目关注速度，启动速度应更快，摸索期应更短；老项目关注维护成本可控，不应有太多效率波动。通过横向对比不同阶段、不同规模的项目效率，了解研发团队的工作重心，合理规划产品线及调配人力。

同时评估人效和交付效率，能够帮助管理者直观了解研发产出的供需是否匹配，哪个环节最急需补充人力，对症下药。

2. 控制风险，避免盲目加人

前面提到，团队新增成员可能会使人员结构更加臃肿，协作更加复杂，使研发效率不升反降。

因此，研发团队在继续加人之前，可以先评估规模扩张对效率的影响：管理者可以通过同环比，观察效率如何变化，进而决策是继续扩张团队，还是改善实践修炼内功。一线管理者也可以每周了解项目/团队研发效率，设立合理区间，及时识别忙闲不均、超负荷工作等异常点。

例如，某团队存在大量任务互相耦合，这些任务过去由少数老员工负责，新加入的成员暂时帮不上手，而老员工边培训新员工边完成任务，已经不堪重负——这时候最关键的就不是继续增加人手，而是解耦任务，让新成员发挥应有的作用。及时识别这类效率下降的原因，排除规模扩张带来的风险，能够帮助团队取得更理想的回报。

3. 帮助新员工成长，让团队更快看到投资回报

新员工从陌生到如鱼得水，生产力达到峰值的平均周期长达 8 个月；在此期间，其他同事也需要投入时间解答新员工问题，或与新员工磨合，加起来是一笔巨大的成本支出。因此，如何加速新员工的融入成长，对于扩张期企业非常重要。

一方面，VxRail 团队借助思码逸分析新员工生产力曲线，筛选抽象出优秀人才画像，从源头入手帮助 HR 找到最适合的候选人。

另一方面，VxRail 团队通过量化新员工成长速度，积极探索培训的最佳实践。当发现哪个部门或团队的新员工的成长特别快时，研发团队可以组织跨部门的分享交流，并沉淀为新员工路线图、mentor 机制等共享知识。

深入分析加速每个版本，避免细微浪费积少成多

IT 行业性质决定了 VxRail 团队的产研特征：产品规模庞大且复杂，定制化程度较高；交付以版本为单位，多个版本并行开发，同时有多个小团队分别负责不同版本；交付周期较长，一个版本对应多个迭代。

随着团队规模超出管理半径，研发管理者不再能像靠主观感觉来评估各版本的研发效率，卡点和瓶颈也难以识别。如果没能赶在规模快速增长前制定好效率度量机制、风险识别和控制的措施，而是放任风险从单点扩散到全局，后期调整起来可能会更加麻烦。

VxRail 团队使用思码逸，从历史数据中统计版本研发过程中的工作量递增趋势，并根据不同项目阶段（孵化期、开发期、维护期）、版本类型（Major、Minor、Patch）等属性，分别建立了效率趋势基准线。

基准线可以帮助研发团队及时识别异常点。例如，基线反映 Major 版本一般在 Feature Complete 前完成大部分编码工作，即代码当量与故事点数都应趋近收敛。但 A 版本已经到达 Feature Complete 时间点，代码当量与故事点数都在持续新增，提交动作也频繁，则提示规划环节未充分评估风险、研发环节未充分前置风险，导致代码冻结未能真正达成。在迭代回顾中，团队需要充分讨论分析这些异常点，在后续迭代中实时改进。

此外，VxRail 团队还使用思码逸统计了历史数据中各类型版本的流分布。流分布指工作量在不同类型事务上的分布，可以是 Feature、Fix、Hotfix 等交付数量或代码工作量。流分布反映了版本的工作重心。一线研发管理者与产品经理可以参照流分布基线，合理规划版本任务，避免重心偏移。

流分布可作为告警指标，帮助研发团队审视当前工作方向是否符合预期，是否会造成业务影响。当流分布出现较大偏差时，可能是前期规划没有考虑完整，有大量计划外事务进入；也可能是线上质量出现严重问题，团队忙于救火而无暇顾及原本的规划。

在引入思码逸度量研发效能的同时，VxRail 团队也在试点研发团队的敏捷转型。对于每个版本交付情况的深入和精细把握，能够帮助 VxRail 团队提前设计风险预案，实现敏捷实践的平稳着陆。