逸Talk | 高效工作全靠领导盯？开发团队的自驱力密码
关于『逸Talk』
『逸Talk』是思码逸Merico新设立的内容专栏，目标是与从业者或泛兴趣的读者分享软件工程效能、软件工程质量、技术团队管理等主题相关的优质内容。
在注意力弥足珍贵的时代，『逸Talk』专栏希望持续传递高质量的洞见与干货。让您投入的每一分钟阅读时间都能产出价值——这将是我们对这个专栏的愿景，也将是我们自我约束、严控内容质量的紧箍咒。
以下，Enjoy~
经历了一个超长待机的假期后，各地企业已在这两周陆续开工。除了少数地区的企业已让员工回归办公室外，大部分人依然坚守家中响应“在家隔离”的号召。然而一开工大家才发现，比起春节在家禁闭两星期，关着禁闭还要上班果然是更辛苦的事情。
协同软件选定了，网络调试稳定了，IM软件终于不卡顿了，人脸打卡蓬头垢面地打上了，早会也穿着睡裤开完了。然而家里的诱惑实在太多，这边摸摸猫那边躺一会，一不小心又是无所事事的一天……
远程办公最大的挑战，其实在于人的低效。但值得注意的是，效率问题并不仅存在于远程办公中，只是在集中办公、监管强度更大的场景下被隐藏了。而这次全国范围内的远程办公实验，使低效问题集中暴露出来。
在组织建设中，被频繁提及的一个词语是自驱力。没有管理者不希望培养出一个具备强大自驱力，在弱监管下也能高效工作的团队；也没有员工不希望自己的自驱力获得充分信任，进而拥有足够空间自由发挥。
那么如何培养团队的自驱力呢？
从本质上来说，自驱其实是绩效管理问题。管理者关注的绩效指标应当足够合理、具备说服力、易于操作，并使公司目标、团队目标与个人目标保持一致。基于这样的指标，将结果快速反馈给管理者与员工个人，及时对齐目标，消除信息不对称不透明。当员工相信自己的点滴工作累积将主导绩效评价结果时，自驱力自然就提升了。
那么绩效指标如何设计，才能充分激发团队自驱力？
作为一个技术人员占绝对多数的公司，我们从自己的管理经验出发，与大家分享软件开发团队的五阶绩效统计评价维度。为便于大家理解，我们将这五阶维度排布在从“活跃度”到“成果”的评价光谱上。
落实到具体实践中，这些评价指标未必需要全部用上，也未必每个都适用于某个团队的实际情况。所以还是需要管理者充分理解、判断本团队的现状，再进行指标的设计与组合。
『讨论统计』
讨论包括线上及线下讨论，换句话说，说话不积极，态度有问题。讨论参与度越高，绩效评价就越高。
这一维度上没有什么专门的工具，纯粹依赖管理者的“体感”。
『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）对代码库中的代码进行深度分析。在这个维度上，工作量指标是基于代码逻辑的复杂度和代码中其他代码对此代码的依赖性，因而工作量评价会更接近于此代码对项目整体的贡献度；而质量方面的评价也更加贴合工程质量视角，除静态扫描出的规则性质量问题外，还能给出项目内的测试覆盖度、代码复用度等指标上的评价。
由于技术难度较大，这个维度上的工具选项就很有限了。思码逸是目前市面上唯一提供这个分析深度的研发管理工具，当然这款产品的应用并不仅限于评价代码表现。
所谓“最终结果”，在一场球赛里就是比分，它可能受到多方面因素的影响，而这些因素可能是在球队可控范围外的。一个过度简化抽象的最终结果并不足以完整客观地反映全场表现，更无法支持教练组进行战术战略的分析规划，提升球队的未来表现。
技术团队的贡献与业务发展，二者之间之间一定有相关性，但其间的链条远比球队表现到最终比分的链条要更长、更复杂。仅仅依赖业务分析这个评价维度，在销售、市场团队可能行得通，但应用在技术团队可能难以让人信服。