离 2022 年结束还有不到二十天，是时候从百忙之中腾出手来，整理一年一度的年终总结了。年终总结不仅是让领导了解过去一年的辛勤工作，也是为自己和并肩奋斗伙伴们做个系统性的梳理。
如果你刚好是一名研发 Leader，那么恭喜，你写年终总结的难度要比其他同事更上一层楼。你不仅需要清晰地概括团队过去一年的工作，还需要让非研发背景的领导同事们都看得懂，进而为下一年度工作争取支持。
如果还不知道如何下笔，先来看看最近当红的 ChatGPT 怎么说：
ChatGPT 虽然还无法代笔年终总结，但它的建议依然有一定参考价值——研发 Leader 在复盘年度工作时，可以从两方面动笔：
- 从业务交付的视角，回顾主要工作，让业务方乃至偏后台的财务、人事部门听得懂
- 从研发团队/项目自身的视角，复盘现状并定位关键问题，进而提出下一年度的改进思路
这篇文章也将从以上两方面，介绍研发 Leader 如何基于数据写出精彩又有干货的年终总结。
本文数据图表来自思码逸效能分析洞察产品及数据分析报告。
1. 业务交付视角
年终总结不仅仅是向上级汇报，更是各部门之间的信息互通。尤其是平日里研发部门离业务可能有一定距离，刚好可以借年终总结的机会打破部门墙，一起复盘研发投入和业务目标达成情况。这样一方面让非研发部门了解研发部门的工作和贡献，另一方面也能和各部门一同发现问题，并协力推动改进。
1.1 量化研发资源分布
几年来『工时』指标饱受争议，认为是工时统计、工时管理才卷出了大小周、996和表演型加班。实际上，是一部分研发管理者误用了工时指标——工时不是研发交付的成果，而是研发团队的资源，其上限是客观存在的。
就像投资者不会用资金量来证明自己投资眼光独到一样，与其关注工时多少，其实更应关注『工时是否投入到了对的地方』『工时投入是否获得了好的回报』。
借助数据，我们可以量化研发团队在不同项目、不同类型事务上的分布情况，并与相关业务方确认研发团队的工作重心是否符合业务预期。
此外，研发团队还可复盘需求取消、需求变更、方案变更等浪费占用了多少研发资源，如果高于正常范围，则可能需要与产品团队协商改进措施。
1.2 量化研发交付价值
研发团队交付了多少价值？这个问题可以分为两个层次来回答。
第一层是研发团队给业务提供了多少支持。这是由研发团队的表现直接决定，业务方可直接感受的价值。例如需求吞吐量、需求交付周期、上线故障率、故障恢复时间等。
如果研发团队在本年度采取了一定措施来加快价值的交付，也可以对相关实践进行总结，并通过数据来验证实践的效果。同时也可以邀请业务方给出反馈，如果数据表现与业务方的感知不符，则可能需要适当调整度量关键指标，以保障研发效能建设始终服务于业务价值的高效高质交付。
第二层是研发团队的工作最终达成的价值，由业务、产品、研发团队的表现共同决定，侧重反映研发工作的“有效性”，例如各项目的用户满意度、活跃用户数、营收等。
如果研发流程比较规范，代码与需求挂钩，研发与产品团队还可以下钻复盘不同类型需求、不同达成率的需求分别占比多少，并关联工时、代码当量（编码工作量）等研发环节指标。基于当前业务表现，评估研发团队工作重心是否合理，是否需要在下一年度做出调整。
如果通过数据发现研发在某项目投入了许多时间和精力，但业务表现不如预期，则业务产研以及高层管理者等各相关方可以借年底复盘的机会，单独组织回顾会议，一起讨论是业务方向需要调整，还是需求传达或技术实现出现了偏差。
2. 研发团队/项目内部视角
领导和非研发同事对研发日常工作中的细节可能感知不多，而年终总结提供了一个契机，能够引导他们更深入理解研发团队的工作，看到功劳，理解苦劳，也对下一年度的改进方向心里有数。
因此，在做年终总结时，除了从业务交付的视角阐述现状，还要重点体现研发内部对现状的思考和改进思路。这就需要带着问题回到研发团队/项目内部，进一步复盘。
具体如何操作呢？也分为两步走：首先，找到最值得关注的焦点问题，深入挖掘避免写成平铺直叙、自说自话的流水账；其次，下钻找到关键改进点，使改进措施都有据可依，并可指导具体行动，减少“提高工作效率”这类正确而无用的泛泛套话。
2.1 找到焦点问题
焦点问题可能来自业务交付视角下的直接反馈，例如响应需求的速度太慢、上线后事故频繁等；也可能来自研发内部常规的效能度量，例如在几个业务属性/阶段/规模近似的项目中，横向对比发现某项目的产能明显不稳定，则可能需要重点关注。
关于研发内部如何复盘团队和项目表现，可以参考去年年底的这篇文章。我们也整理了一个最新的典型问题列表，团队可以根据实际情况按需裁剪使用。
2.2 找到关键改进点
焦点问题已经找到，那么如何分析现状，找到关键改进点？我们可以先基于经验和知识做出假设，再用数据去证实或证伪。
接下来我们用一个例子来示意。
某项目的业务方一直抱怨需求交付周期太长，本年度虽有所改善，但依然不如人意。一步步排查关键影响因素：
需求交付周期长，是因为研发团队产能不足以支撑需求吗？
数据显示，研发团队的代码产能高于行业中位数，且相比前一年度有显著上升，人均代码产能也呈上升趋势。从月需求吞吐量来看，进入研发与交付的需求数量基本持平。产能不足的现象并不明显。
需求交付周期长，是因为需求的颗粒度变大了吗？数据显示，已完成需求对应的工时相比去年同期有显著减少，说明需求颗粒度整体降低。但同时，已完成需求对应的代码当量的差异较大，说明依然存在需求大小不一的情况。
那么，在需求交付的整个流程中，是否存在哪一个阶段用时偏长？数据显示，需求交付中平均有 34% 时间用于等待，而待开发、待测试两个阶段用时显著偏长，过多等待拖累了需求的流动效率。
在这个信息的基础上，研发团队还可进一步下钻这两个阶段用时较长的原因，例如是否在关键技能栈上存在人手短缺，是否存在部分成员超负荷而部分成员空转的忙闲不均现象。
经过这一系列的分析、下钻和复盘，研发团队就能针对需求交付周期这一焦点问题，清晰地陈述研发团队过去一年已采取的措施（提升产能、控制需求颗粒度）以及相应成果，指出关键改进点（待开发与待测试阶段），最后给出针对性、可行动的解决方案，并告知相关方这样的解决方案预期将为焦点问题带来怎样的改变。
这些从实践摸索中获得的知识，也能够通过复盘沉淀下来，为其他研发团队、项目提供宝贵的经验参考。
总结
客观的数据能够佐证我们在过去一年的优秀工作，丰富的数据下钻能力能够支持我们找到改进的突破口，简明的数据图表能够帮助我们更好地与他人沟通。
但归根到底，数据本身的堆砌是没有价值的，数据应当为人所用，作为我们思考脉络的载体，和探索新知的能力基石。我们在一次又一次复盘中总结出的经验教训，与合作方之间的坦诚沟通与相互支持，才是年终总结中不可替代的部分。
现在，你准备好动笔写年终总结了吗？
在线客服.png)
