年终总结 | 怎样复盘项目/团队表现？

之前我们聊了如何在年终节点辨别高效能人才，以及如何投资高效能人才，以带动团队整体的效能提升。在这篇文章里，我们把视线抬高，聊一聊项目及团队级的复盘。

在开始前，先讨论一个问题：如何理解复盘？

我们认为，复盘并不只是单向汇报、向上管理，而是集结了反思聚合、重点讨论、经验交流、规划拆解的多步骤过程。每个级别的研发管理者，都需要在不同组织粒度上承担主导复盘、输出思考、整合经验的责任。

以下内容介绍了项目/团队复盘的几个方向，希望能给正在为年终总结挠头的你提供参考。

纵向对比，了解效能趋势

首先，可以对比分析项目/团队本年度与过去几个年度的效率及质量数据，观察整体及平均值同比变化，对比预期目标是否实现。进一步可以按照部门、团队、项目下钻，定位差异主要产生的主体。

 

其次，可以按照阶段进行分解，观察整体及平均效能在本年度的趋势。

一方面，趋势图能够反映效能表现的波动性。以效率为例，趋势图能直观展示不同阶段效率分层的现象，结合更细粒度的箱线图，可以进一步辨别波动存在的根因，从而解决导致忙闲不均的系统性问题。

另一方面，如果本年度推行了具体的效能改进措施，趋势图能够帮助团队复盘这些措施的效果如何，促进团队间的交流学习。

 

如同张乐老师的文章所说，研发效能的提升需要实验思维，不断检视、反思、检讨所采用的实践，哪些实践的确有效，哪些实践效果不大，哪些实践方向正确但因执行不到位所以效果才不及预期，进而找到最适合团队的效能实践。

有限横向对比，建立基线

全局复盘的场景下，难免有冲动把所有的团队/项目全拉出来做比较 —— 听起来简单公正，但需要小心避开陷阱，才能使横向对比发挥应有作用。

首先，研发管理者需要意识到团队/项目的阶段、业务特性、规模、人力结构等特征存在差异，一刀切的横向对比可能并不公平，反而影响研发团队士气。建议做横向对比前，先匹配团队/项目特征，并检验数据上是否可比，避免横向对比过度泛化。

在横向对比行业效能指标，特征信息相对较少的情况下，也需要尽量匹配业务特性、规模、语言等特征，保障行业参考值的有效性。

 

其次，横向对比的主要目的应是建立工程能力基线，为后续改进提供参考。由于这个基线一般是平均值，一线管理者可以更进一步拆分不同岗位、职级能力基线值，并作为下一年度项目预估的参考。

结合工时数据分析

如果研发团队有记录工时相关数据，这类指标也可以提供有趣的信息。但在纳入分析前，建议明确分析工时的目的：如果将工时作为考核指标之一，那么有可能给开发者传递不恰当的信息，变相鼓励他们多坐办公室，而非高效地完成工作。

开发者的时间可以理解为研发团队的资源投入。综合分析资源投入（工时）与产出情况（效率），可以帮助研发管理者盘点人力负载与缺口，辅助规划下一年度的人才选用育留。

一方面，可以从部门、团队、项目等不同视角进行下钻分析，并结合特征评估是否合理；另一方面，可以按照岗位、职级等特征做聚类分析，观察是否存在集聚现象。

  

一线管理者则可以更细粒度地分析工时及产出的分布情况：开发者有多少时间是投入在会议中？加班情况是否严重？团队成员是否在超负荷工作？写代码的时间中，有多少是服务于新功能开发或性能优化，有多少是在救火解 bug？产出分布与工时分布是否匹配？是否有开发者参与过多项目，因而在切换上投入大量时间的情况？开发者的产出分布是否均衡合理？（上一篇内容也提到，少数开发者贡献了大部分产出，这一现象是常见的，但仍应控制在合理范围内。）

如果数据反映研发团队正在众多 bug 之间疲于奔命，那么年终正是复盘案例、交流经验并制定改进规划的好时机。

基于项目特性，有侧重地关注质量

在任何时候，研发团队选取北极星指标后，都需要设计护栏指标，避免某些有害的“数据增长”带来错误信号，质量便常常是重要的护栏指标。

但需要注意，度量与改进都有成本，难以面面俱到。因此，建议基于项目阶段与业务特性，有侧重地选取质量指标。例如：

• 当项目处于高活跃度的增长期，建议关注重点问题率及代码复用度，以便及时解决关键风险，并预防增长期的风险蔓延
• 当项目业务逻辑复杂时，建议关注测试覆盖度与模块性，合理拆分解耦模块将有助于复杂项目的维护
• 当项目进入维护或重构阶段，建议以遗留代码的圈复杂度指标作为质量提升的切入点，同时也通过模块性指标评估架构合理性
• 人员流动性较大，或需要被其他团队使用的项目，则需要额外留意代码的注释覆盖度

以上的质量指标侧重编码阶段的软件工程质量。结合软件研发的其他阶段，例如测试缺陷与发版后事故指标，选取重点关注项目，进行质量问题的回溯与相关性分析，能带来更加丰富的洞察。

明确各个项目的质升需求，针对性地进行复盘，并基于数据制定下一年度提升计划。这能帮助研发团队集中力量解决关键问题，达到质效协同提升，而不是被过度敏感的质量监测牵扯过多精力。