我是怎么用数学方法，统计分析远程研发团队效能的？
在组织建设中，被频繁提及的一个词语是自驱力。没有管理者不希望培养出一个具备强大自驱力，在弱监管下也能高效工作的团队；也没有员工不希望自己的自驱力获得充分信任，进而拥有足够空间自由发挥。
那么如何培养团队的自驱力呢？以下内容整理自 2 月 10 日晚 Merico 思码逸的 CEO 任晶磊在《鲲鹏说》直播节目中的分享（部分内容有删减），供 TGO 鲲鹏会的读者们阅读，从而学会用数据指标观测及衡量团队效能，找到效能提升的症结点与破局点。
获取完整版分享 PPT，请关注本公众号回复“远程办公”查收下载链接。
大家好，我是任晶磊，Merico 思码逸 CEO，也是 TGO 鲲鹏会北京分会会员。今天我要给大家分享的内容是《远程技术团队的绩效管理与激励》，主要包含三个方面：
远程的最大挑战：我认为远程协作的最大挑战不在于工具、沟通层面的，很多事情不 work 的前提是我们没有找对关键；
开发团队数据分析的指标与方法：远程协作的落脚点如果最终还是在人和团队，那么团队的绩效管理就非常重要，因此势必涉及到一些量化方法；
信息不对称、自我驱动与及时反馈：当我们有了对团队绩效的分析结果之后，怎样给予开发团队及时的反馈？怎样帮助管理者消除信息不对称？只有上述这些闭环完全形成，才能最终驱动整个开发团队效能的提升。
Merico 思码逸其实一直在实践远程和分布式的工作方式，而且我们是一个真正意义上的分布式团队。目前，我们有 20 多个成员，遍布在 5 个不同的国家，15 座城市，从 2018 年下半年创业开始到目前为止，我们一直都实践着这样的模式。但这样的模式并不会影响到我们团队的研发效率。
下面一张图其实展示了我们远程团队的效能情况，也是开发效率的一项关键数据，叫做“开发当量”。它统计了项目代码的复杂度，是一个积累的量，当你不断地修改复杂度，也随之会形成单调递增。
左边这幅图绘制了我们 vdev 项目（Merico 思码逸核心项目）2019 年全年增长的情况，可以看到，这个曲线是一个很漂亮的直线上升的趋势，而且中间有不断上扬的趋势。那么从绝对值来看的话，从 100k 以下的开发当量一直增加到将近 800k 的开发当量，整个的效率还是较高的。
除此之外，这个数据提供给大家的目的，也是帮助那些未来考虑采用远程或者分布式方式协作的技术 Leader，当面临到“怎么证明团队在远程之后效率是否降低“这样一个问题时，可以通过当量曲线的数据情况来提供一个佐证。
其实，远程团队最大的痛点不是来源于工具、沟通的低效，80% 的痛点是来源于每个人在工作上的投入度。所以后面分享中大部分的内容会聚焦到“人”的层面上进行分享。但回归到现实场景下，其实很多 Team Leader 无法具体衡量程序员每一天的产出。
我看过很多文章中分享对远程工作效果衡量的解决方案中，自律或者自我驱动这类词会经常被提及。但其实你要了解，看团队自我驱动的时候，其实应该认识到这是一个管理的问题。或者说，从本质上来看，自驱其实是绩效管理问题。
管理者关注的绩效指标应当足够合理、具备说服力、易于操作，并使公司目标、团队目标与个人目标保持一致。基于这样的指标，将结果快速反馈给管理者与员工个人，及时对齐目标，消除信息不对称不透明。当员工相信自己的点滴工作累积将主导绩效评价结果时，自驱力自然就提升了。
那么绩效指标如何设计，才能充分激发团队自驱力？
作为一个技术人员占绝对多数的公司，我们从自己的管理经验出发，与大家分享软件开发团队的五阶绩效统计评价维度。为便于大家理解，我们将这五阶维度排布在从“活跃度”（Activity）到“成果”（Achievement）的评价光谱上。
落实到具体实践中，这些评价指标未必需要全部用上，也未必每个都适用于某个团队的实际情况。所以还是需要管理者充分理解、判断本团队的现状，再进行指标的设计与组合。
从“活跃度”到“成果”的不同递进阶段来看，主要可以从以下五种不同的统计分析指标上来衡量：
第一个维度是对讨论的统计，讨论包括线上及线下讨论。换句话说，说话不积极，态度有问题。讨论参与度越高，绩效评价就越高。这一维度上没有什么专门的工具，纯粹依赖管理者的“体感”。
在研发团队中，Issue 是可以反映一个研发团队状态和开发活跃性的指标之一，Issue 统计即代表对代码库提交的维度上进行的评价，这里主要评价的是开发流程的顺畅与否。关键指标包括：
积压变化（Backlog change，未解决的 Issue 数量量变化）；
周期时间（cycle time，解决一个 Issue 所需天数）；
工作量量平衡（workload balance，完成 80% 工作量量的⼈人数占比）；
吞吐量（throughput，每人每月解决的 Issue 数量）；
缺陷率（defect ratio，bug 占所有 Issue 总数的⽐例）等。
在 Issue 活动维度上进行统计评价的工具不少，典型的一款产品叫 Pinpoint，上面这些指标就来自于他们的产品设计。当然，通过调用代码库的接口，团队也可以自开发工具来进行简单统计。
即对代码库中的代码进行统计。可以看出相比上一维度而言，代码统计更接近开发者的产出。可见度不再只局限于 commit 代码、解决 issue 的动作，我们开始能够了解每个 commit 中开发者做了什么，做得如何。
对产出的评价可以分为两大方面：工作量与质量。
工作量方面的关键指标包括代码行数、修改代码的位置数量、修改的文件数量、工作中新产出代码和重构旧代码的比例。
质量方面有一个非常重要的指标，被称作搅动（churn），即在一个较短的时间内多少比例的代码被反复删除重写，这可能暗示了代码的质量相对较低。大家可以关注一下这个指标。我们和京东数科工程效能团队的朋友交流过，他们的评价体系中也有非常相似的概念，实践之后会发现一个团队 code churn 的值高，那么这个团队在 deliver 和开发情况也相应的较差一些。
在这个维度上的统计工具，比较著名的是 GitPrime，也就是被 IT 培训平台 PluralSight 收购整合后的 Flow。
那往第四个维度继续往下看的话，就需要引入一些统计的方法来分析，而不再是仅仅通过脚本就能发现。
一开始的时候我就提到了我们团队在使用“开发当量”衡量效能，“开发当量”即基于抽象语法树（AbstractSyntax Tree）对代码库中的代码进行深度分析。
在这个维度上，工作量指标是基于代码逻辑的复杂度和代码中其他代码对此代码的依赖性，因而工作量评价会更接近于此代码对项目整体的贡献度；而质量方面的评价也更加贴合工程质量视角，除静态扫描出的规则性质量问题外，还能给出项目内的测试覆盖度、代码复用度等指标上的评价。
此外，“开发当量”可以比较有效地屏蔽代码行级别的简单指标而带来的效能评测失真的问题。
由于技术难度较大，这个维度上的工具选项非常有限，思码逸也是目前市面上唯一提供这个分析深度的研发管理工具。
业务分析是最接近于传统意义上“绩效”的维度，也就是去评价技术团队到底为公司业务发展起到了怎样的助推作用。
很多非技术出身的管理者也许觉得，既然技术团队的终极目的也是服务于业务，拿最终成果来评价有何不可？那么不妨来看看球赛的赛后统计：除了比分外，赛后统计一般会给出相当详尽的全场数据。
所谓“最终结果”，在一场球赛里就是比分，它可能受到多方面因素的影响，而这些因素可能是在球队可控范围外的。一个过度简化抽象的最终结果并不足以完整客观地反映全场表现，更无法支持教练组进行战术战略的分析规划，提升球队的未来表现。
技术团队的贡献与业务发展，二者之间之间一定有相关性，但其间的链条远比球队表现到最终比分的链条要更长、更复杂。仅仅依赖业务分析这个评价维度，在销售、市场团队可能行得通，但应用在技术团队可能难以让人信服。
综合以上五个维度总结来说，其实就是自驱力源于合理的绩效管理，而合理的绩效管理其实是数学问题。
我们整个系统里会有各种数据视图。这里想展示一点的是，上面所说的这些分析的结果，要实现闭环的话，是需要最终要反馈到开发者手中的，才能达到更好的激励、驱动效果。
所以，我们有管理者日报和管理者周报这样一个做法。
下面展示的管理者周报，也是我们团队实际的周报情况。从周报中，你可以看到某一位同学他每天开发量的变化，同时也可以把柱状图里虚的、灰颜色的筛选出来，然后你也能看到自己工作量跟团队工作量的对比情况，我们通过这种反馈方式可以很好地增强对团队的激励，也形成了工作的闭环。
注：本文大部分内容转载自 思码逸 Merico 公众号的《逸 Talk | 高效工作全靠领导盯？开发团队的自驱力密码》整理，感谢 TGO 鲲鹏会会员企业 思码逸 Merico 对 TGO 的支持！
疫情当前，一批批中小企业相继在危难中倒下或开始艰难的自救。那么在开始重新调整企业技术战略规划前，需要掌握哪些核心原则，避免“坑”的出现呢？
明晚（2 月 14 日）20:00 鲲鹏说，迎来「疫情特辑」的最后一弹。最后一弹也将由互联网架构技术专家，“架构师之路”公众号作者、58 同城技术委员会主席、58 到家技术委员会主席、到家集团技术 VP、快狗打车 CTO 沈剑（艾玛，嘉宾太重磅，Title 太多，光环太足）将在线直播《疫情当前，互联网公司如何做好技术战略规划》。用他的经验积累和实践方法论，教你企业技术战略制定的核心与要诀！