研发 Leader 怎样写出非研发也看得懂的年终总结？

离 2022 年结束还有不到二十天，是时候从百忙之中腾出手来，整理一年一度的年终总结了。年终总结不仅是让领导了解过去一年的辛勤工作，也是为自己和并肩奋斗伙伴们做个系统性的梳理。

如果你刚好是一名研发 Leader，那么恭喜，你写年终总结的难度要比其他同事更上一层楼。你不仅需要清晰地概括团队过去一年的工作，还需要让非研发背景的领导同事们都看得懂，进而为下一年度工作争取支持。

如果还不知道如何下笔，先来看看最近当红的 ChatGPT 怎么说：

ChatGPT 虽然还无法代笔年终总结，但它的建议依然有一定参考价值——研发 Leader 在复盘年度工作时，可以从两方面动笔：

• 从业务交付的视角，回顾主要工作，让业务方乃至偏后台的财务、人事部门听得懂

• 从研发团队/项目自身的视角，复盘现状并定位关键问题，进而提出下一年度的改进思路

这篇文章也将从以上两方面，介绍研发 Leader 如何基于数据写出精彩又有干货的年终总结。

本文数据图表来自思码逸效能分析洞察产品及数据分析报告。

业务交付视角

年终总结不仅仅是向上级汇报，更是各部门之间的信息互通。尤其是平日里研发部门离业务可能有一定距离，刚好可以借年终总结的机会打破部门墙，一起复盘研发投入和业务目标达成情况。这样一方面让非研发部门了解研发部门的工作和贡献，另一方面也能和各部门一同发现问题，并协力推动改进。

量化研发资源分布

几年来『工时』指标饱受争议，认为是工时统计、工时管理才卷出了大小周、996 和表演型加班。实际上，是一部分研发管理者误用了工时指标——工时不是研发交付的成果，而是研发团队的资源，其上限是客观存在的。

就像投资者不会用资金量来证明自己投资眼光独到一样，与其关注工时多少，其实更应关注『工时是否投入到了对的地方』『工时投入是否获得了好的回报』。

借助数据，我们可以量化研发团队在不同项目、不同类型事务上的分布情况，并与相关业务方确认研发团队的工作重心是否符合业务预期。

此外，研发团队还可复盘需求取消、需求变更、方案变更等浪费占用了多少研发资源，如果高于正常范围，则可能需要与产品团队协商改进措施。

量化研发交付价值

研发团队交付了多少价值？这个问题可以分为两个层次来回答。

第一层是研发团队给业务提供了多少支持。这是由研发团队的表现直接决定，业务方可直接感受的价值。例如需求吞吐量、需求交付周期、上线故障率、故障恢复时间等。

如果研发团队在本年度采取了一定措施来加快价值的交付，也可以对相关实践进行总结，并通过数据来验证实践的效果。同时也可以邀请业务方给出反馈，如果数据表现与业务方的感知不符，则可能需要适当调整度量关键指标，以保障研发效能建设始终服务于业务价值的高效高质交付。

第二层是研发团队的工作最终达成的价值，由业务、产品、研发团队的表现共同决定，侧重反映研发工作的“有效性”，例如各项目的用户满意度、活跃用户数、营收等。

如果研发流程比较规范，代码与需求挂钩，研发与产品团队还可以下钻复盘不同类型需求、不同达成率的需求分别占比多少，并关联工时、代码当量（编码工作量）等研发环节指标。基于当前业务表现，评估研发团队工作重心是否合理，是否需要在下一年度做出调整。

如果通过数据发现研发在某项目投入了许多时间和精力，但业务表现不如预期，则业务产研以及高层管理者等各相关方可以借年底复盘的机会，单独组织回顾会议，一起讨论是业务方向需要调整，还是需求传达或技术实现出现了偏差。

研发团队/项目内部视角

领导和非研发同事对研发日常工作中的细节可能感知不多，而年终总结提供了一个契机，能够引导他们更深入理解研发团队的工作，看到功劳，理解苦劳，也对下一年度的改进方向心里有数。

因此，在做年终总结时，除了从业务交付的视角阐述现状，还要重点体现研发内部对现状的思考和改进思路。这就需要带着问题回到研发团队/项目内部，进一步复盘。

具体如何操作呢？也分为两步走：首先，找到最值得关注的焦点问题，深入挖掘避免写成平铺直叙、自说自话的流水账；其次，下钻找到关键改进点，使改进措施都有据可依，并可指导具体行动，减少“提高工作效率”这类正确而无用的泛泛套话。

找到焦点问题

焦点问题可能来自业务交付视角下的直接反馈，例如响应需求的速度太慢、上线后事故频繁等；也可能来自研发内部常规的效能度量，例如在几个业务属性/阶段/规模近似的项目中，横向对比发现某项目的产能明显不稳定，则可能需要重点关注。

关于研发内部如何复盘团队和项目表现，可以参考去年年底的这篇文章。我们也整理了一个最新的典型问题列表，团队可以根据实际情况按需裁剪使用。

找到关键改进点

焦点问题已经找到，那么如何分析现状，找到关键改进点？我们可以先基于经验和知识做出假设，再用数据去证实或证伪。

接下来我们用一个例子来示意。

某项目的业务方一直抱怨需求交付周期太长，本年度虽有所改善，但依然不如人意。一步步排查关键影响因素：需求交付周期长，是因为研发团队产能不足以支撑需求吗？

数据显示，研发团队的代码产能高于行业中位数，且相比前一年度有显著上升，人均代码产能也呈上升趋势。从月需求吞吐量来看，进入研发与交付的需求数量基本持平。产能不足的现象并不明显。

需求交付周期长，是因为需求的颗粒度变大了吗？数据显示，已完成需求对应的工时相比去年同期有显著减少，说明需求颗粒度整体降低。但同时，已完成需求对应的代码当量的差异较大，说明依然存在需求大小不一的情况。

那么，在需求交付的整个流程中，是否存在哪一个阶段用时偏长？数据显示，需求交付中平均有 34% 时间用于等待，而待开发、待测试两个阶段用时显著偏长，过多等待拖累了需求的流动效率。

在这个信息的基础上，研发团队还可进一步下钻这两个阶段用时较长的原因，例如是否在关键技能栈上存在人手短缺，是否存在部分成员超负荷而部分成员空转的忙闲不均现象。

经过这一系列的分析、下钻和复盘，研发团队就能针对需求交付周期这一焦点问题，清晰地陈述研发团队过去一年已采取的措施（提升产能、控制需求颗粒度）以及相应成果，指出关键改进点（待开发与待测试阶段），最后给出针对性、可行动的解决方案，并告知相关方这样的解决方案预期将为焦点问题带来怎样的改变。

这些从实践摸索中获得的知识，也能够通过复盘沉淀下来，为其他研发团队、项目提供宝贵的经验参考。

总结

客观的数据能够佐证我们在过去一年的优秀工作，丰富的数据下钻能力能够支持我们找到改进的突破口，简明的数据图表能够帮助我们更好地与他人沟通。

但归根到底，数据本身的堆砌是没有价值的，数据应当为人所用，作为我们思考脉络的载体，和探索新知的能力基石。我们在一次又一次复盘中总结出的经验教训，与合作方之间的坦诚沟通与相互支持，才是年终总结中不可替代的部分。

现在，你准备好动笔写年终总结了吗？

如果您想进一步了解研发团队如何通过有效的复盘与管理来提升效能，可以点击获取思码逸解决方案。

思码逸为企业软件研发团队提供一站式研发效能分析平台及配套解决方案。

思码逸怎么做？

思码逸产品从代码和 DevOps 工具链中提取数据，呈现多视角数据洞察，包括：

￮ 交付效率：及时洞察项目效率、下钻了解团队效率、深入理解开发者贡献、动态调整开发负荷

￮ 交付质量：全周期度量软件品质、多指标度量软件工程质量、精准定位提质关键点、明确分配提质责任

￮ 组织与人才发展：分析开发者技能、了解开发者工作习惯、分析开发者质效表现、了解开发者活跃度、盘点人才资源

我们的客户？

目前，思码逸已为腾讯、美团、滴滴出行、中国平安、泰康保险、戴尔 EMC、中电万维、PingCAP、自如、贝壳、商汤科技、蔚来汽车、长亭科技、和讯网、云砺科技、知道创宇、百融云创、凯叔讲故事 等众多行业标杆客户提供服务。