‍

阅读本文你将获得：1、研发团队绩效考核指标由哪些构成的；2、研发团队的自驱力问题如何解决

‍

前言：本文内容节录于思码逸 Merico CEO 任晶磊在 51CTO 与鲲鹏会 TGO 进行的“远程场景下技术团队效能管理与激励”主题分享。基于对该赛道的全面认知，他分享了研发团队管理和自驱力本文结合演讲内容对研团队管理总结了两点重要内容

‍

远程办公最大的挑战，其实在于人的低效。但值得注意的是，效率问题并不仅存在于远程办公中，只是在集中办公、监管强度更大的场景下被隐藏了。在组织建设中，被频繁提及的词语是研发绩效管理和自驱力。没有管理者不希望培养出一个具备强大自驱力，在弱监管下也能高效工作的团队；也没有员工不希望自己的自驱力获得充分信任，进而拥有足够空间自由发挥。那么如何做好研发绩效管理并培养良好的团队自驱力呢

‍

研发团队绩效考核指标构成

‍

从本质上来说，自驱其实是绩效管理问题。管理者关注的绩效指标应当足够合理、具备说服力、易于操作，并使公司目标、团队目标与个人目标保持一致。基于这样的指标，将结果快速反馈给管理者与员工个人，及时对齐目标，消除信息不对称不透明。当员工相信自己的点滴工作累积将主导绩效评价结果时，自驱力自然就提升了。

那么绩效指标如何设计，才能充分激发团队自驱力？

‍

作为一个技术人员占绝对多数的公司，我们从自己的管理经验出发，与大家分享软件开发团队的五阶绩效统计评价维度。为便于大家理解，我们将这五阶维度排布在从“活跃度”到“成果”的评价光谱上。

落实到具体实践中，这些评价指标未必需要全部用上，也未必每个都适用于某个团队的实际情况。所以还是需要管理者充分理解、判断本团队的现状，再进行指标的设计与组合。

『讨论统计』

讨论包括线上及线下讨论，换句话说，说话不积极，态度有问题。讨论参与度越高，绩效评价就越高。

这一维度上没有什么专门的工具，纯粹依赖管理者的“体感”。

‍

『Issue统计』

即在代码库提交的维度上进行评价，这里主要评价的是开发流程的顺畅与否。

关键指标包括积压变化（backlog change，未解决的 issue 数量量变化）、周期时间（cycle time，解决一个 issue 所需天数）、工作量量平衡（workload balance，完成 80% 工作量量的⼈人数占比）、吞吐量（throughput，每人每月解决的 issue 数量）、缺陷率（defect ratio，bug 占所有 issue 总数的⽐例）等。

在Issue活动维度上进行统计评价的工具不少，典型的一款产品叫Pinpoint，以上的指标就来自于他们的产品设计。当然，通过调用代码库的接口，团队也可以自开发工具来进行简单统计。

『代码统计』

即对代码库中的代码进行统计。可以看出相比上一维度而言，代码统计更接近开发者的产出。可见度不再只局限于commit代码、解决issue的动作，我们开始能够了解每个commit中开发者做了什么，做得如何。

‍

对产出的评价可以分为两大方面：工作量与质量。工作量方面的关键指标包括代码行数、修改代码的位置数量、修改的文件数量、工作中新产出代码和重构旧代码的比例。质量方面的指标是搅动（churn），即在一个较短的时间内多少比例的代码被反复删除重写，这可能暗示了代码的质量相对较低。我们和京东数科工程效能团队的朋友交流过，他们的评价体系中也有非常相似的概念。

‍

在这个维度上的统计工具，比较著名的是GitPrime，也就是被IT培训平台PluralSight收购整合后的Flow。

‍

『AST分析』

即基于抽象语法树（AbstractSyntax Tree）对代码库中的代码进行深度分析。在这个维度上，工作量指标是基于代码逻辑的复杂度和代码中其他代码对此代码的依赖性，因而工作量评价会更接近于此代码对项目整体的贡献度；而质量方面的评价也更加贴合工程质量视角，除静态扫描出的规则性质量问题外，还能给出项目内的测试覆盖度、代码复用度等指标上的评价。

由于技术难度较大，这个维度上的工具选项就很有限了。思码逸是目前市面上唯一提供这个分析深度的研发管理工具，当然这款产品的应用并不仅限于评价代码表现。

AST分析维度下的工作量评价与传统指标的对比

代码复用及优化建议

‍

『业务分析』

业务分析是最接近于传统意义上“绩效”的维度，也就是去评价技术团队到底为公司业务发展起到了怎样的助推作用。

很多非技术出身的管理者也许觉得，既然技术团队的终极目的也是服务于业务，拿最终成果来评价有何不可？那么不妨来看看球赛的赛后统计：除了比分外，赛后统计一般会给出相当详尽的全场数据。

所谓“最终结果”，在一场球赛里就是比分，它可能受到多方面因素的影响，而这些因素可能是在球队可控范围外的。一个过度简化抽象的最终结果并不足以完整客观地反映全场表现，更无法支持教练组进行战术战略的分析规划，提升球队的未来表现。

技术团队的贡献与业务发展，二者之间之间一定有相关性，但其间的链条远比球队表现到最终比分的链条要更长、更复杂。仅仅依赖业务分析这个评价维度，在销售、市场团队可能行得通，但应用在技术团队可能难以让人信服。

‍

研发团队的自驱力问题如何解决

‍

一句话概括：研发团队自驱力源于合理的研发绩效管理体系，而合理的研发绩效考核管理其实是数学问题。至于选择怎样的绩效考核指标、如何配比参数，就需要依靠研发管理者们的智慧了。想了解更多研发效能的文章，可以阅读《深度代码分析在研发效能度量中的落地场景》希望本文分享的五阶评价维度能给您带来一些启发。