不管是员工个人的年底绩效考核，还是技术团队的整体年度计划，学会总结、整理以及恰当表达自己这一年的工作成果和对未来接下来的规划，都是很有意义和价值的。除了有可能拿得到更多的奖金、年终奖和晋升调薪的机会外，也是自己和团队一次思维提升的契机。
很多人，尤其是做技术的，平时写代码就很6，到了要写文档、做PPT就很犯难，更别说还要在正式的场合上进行汇报和演讲了！
其实掌握了思路、多写几次，就会发现并不难。
如果你和你的团队正在使用YesDev项目管理，那么以下内容或许可以帮助你减少烧脑的时间。如果使用其他项目管理工具，也值得阅读，思路和总结框架是类似的，只是填充的数据和内容不同而已。
首先，年底总结就像开发需求一样。
明确提交时间：要先了解年底总结提交的时间截止时间，提前拿到公司统一的PPT模板、格式、要求和大纲，再及时分发给其他需要帮忙汇总的同事一起同步年底总结的注意事项和分工整理。
多人编辑PPT：其次可以尽量使用支持在线PPT协作的工具进行多人编辑（我发现钉钉就很好用，把PPT文件发到群里，就可以直接和同事一起在线改PPT）。
良好的PPT全名：还有要注意PPT文件的命名，要把自己的作者姓名和最后更新日期也加上，例如好的PPT命名：《XXXX部门2023年底总结-XXX姓名-20240116.ppt》。
用数字说话：少写一堆文字、多用具体的数字来说话，来表明/证明/陈述过往的工作业绩和成果。
会总结的人，职场发展都不会差。下面正式进入主题。
年底总结应重点包括的内容核心的业绩陈述
全场最亮眼的核心业绩数据，莫过于销售业绩。例如电商平台的GMV数据、传统企业全年的营收金额、SaaS软件产品平台的付费金额等有钱相关的数据。当然，如果你和你的团队能说明，这些增长的收入和你的工作或贡献息息相关、或是强关联，那就说明你的工作贡献更强。
如果没有这块的数据，或关联度不高，也没关系，可以再选取第二梯队的亮点数据，就是辅助核心业绩数据的支撑数据。例如：平台类型的供应商的接入量、新增商品录入的数；做ToC产品的新增注册用户数量、活跃度、留存转化率和客单价的提升等；又如做ToB企业服务的可以说明和汇报内部提升的效率情况。
如果这些都没有，说明你所在的部门不是业务部门，可能是更偏向后勤保障的职能部门，那么就可以保底从一些日常工作量化的数据和指标进行汇报。
以上，都是属于你的功劳、核心亮点的总结。
基于STAR法则重点汇报专项成果
全年工作下来，肯定会参与到公司的一些重要项目当中，例如：全新的项目研发、核心业务系统的架构优化、历史项目的重写重构、公司一级项目专项的主导研发、和第三方平台系统的合作项目等。
这些项目，都有它的特点，就是：大、难、新、复杂、协作人员多、时间紧、要求高等。
这些专项，可以单独一页PPT，挑选2~3个专项进行重点汇报，同时结合STAR法则进行汇报会更有成效，即：你在什么样的背景下、负责了哪个项目的哪部分工作、在这个艰难的过程中你主要做出了和别人不一样的哪些工作和贡献、最后取得了怎样的结果。
图片来自网络
结合YesDev汇总年度项目整体交付成果
对于使用YesDev项目管理的团队，我推荐是使用以下的交付指标，作为衡量你团队全年有效需求交付的关键指标数量。
我来给大家解释和解读一下。
首先，第一列先说明自己所负责的团队有多少人员，5个人如果干了10个人的活，那么效果和谁管理、谁带团队带得好就更容易进行对比。当然咯，每个团队负责的系统不一样，需求颗粒度有大有小，这方面另外再作对比。
中间蓝色的四列，分别是：总需求、已完成需求、需求完成率、人均每月完成需求。
总需求呢是全部提交和收集过来的需求总数量，表示了整个团队所面临的需求压力。就通常而言，需求肯定是比研发人员都要多的，如果需求少，那么这个研发部门是要被裁员的。总需求交代了背景，即我有这么多人，却要开发这么多需求。接着，再介绍已经完成的需求，已完成的需求呢，在汇报时，可以把：已上线、挂起、已验收、已通过的，都列入在其内。需求完成率则是老板和其他负责人都能看得懂的百分比，最好可以在75%以上，表示良好，如果是需求完成度是在85%以上，恭喜你是优秀的团队。还有最后一个指标是用来指导内部进行效率提升，就是：人均每月完成需求。和跟体育运动跳高、跳远、跑步一样。你要证明比别人跳得高、跑得快、跳得远，得有数据来证明。那么人均每月完成需求，我觉得是可以作为开发人员开发和交付需求效率和速度的一个很好指标。
据我经验评估，如果一个开发人员每个月只能交付和完成5个需求及以下，说明效率是低下的，或者需求颗粒度过大（没有拆解、一个项目当一个需求来做），或整体研发流程不顺畅（需求不明确、技术开发能力弱、或交付质量差、返工多），或需要进行大量的需求调研分析和研讨（开会时间大于研发时间）。如果每个月每人做到成功交付7个需求，是属于良好正常的状态。优秀的个人和团队，则可以做到每个月交付9个及以上。很哇塞！
在后半段，标注红色背景的，老板通常不会太关心，因为是属于质量方面，如果不是产生线上故障、没有发生损失的话，老板一般都不会心痛也不会关心。但如果Bug缺陷影响到了需求和项目交付或者产品上线发布，那老板就会介入和关注。但这类情况，建议还是统一按需求交付指标来汇报即可。所以，这里针对：总问题数、已修复问题、每需求Bug数量、Bug修复率、测试用例、平均每个需求用例，有需要的朋友，可以私自研究，或者有疑问的也可以留言评论我再来展开补充。
除此之外，YesDev还有哪些项目汇总数据可以直接拿来、直接用的呢？
全年项目集统计，适合全年回顾，例如：常规产品系统的每月迭代项目、按版本规划和上架发布的研发项目、按一期二期三期逐步交付的实施项目等，都可以直接拉取对应的项目集统计数据。
举例：图1：全年项目集统计（全年回顾），以下是 YesApi接口大师 的项目集。
如果需要查看和统计专项，可以深入查看YesDev的具体项目详情和项目汇报。如：图2：十月份YesDev产品的迭代详情和细节（有代表性的专项）。
又如YesDev全年的统计数据，图3：全年多维度历史统计数据（一年比一年好）。
用YesDev管理了这一年的项目，为每个系统/每个产品/每个平台的研发、维护进行了全年的项目管理、登记、汇总和跟进，通过每个月创建一个项目，可以进行持续的追踪，全年的快速复盘。从完成的总需求、交付速度、项目质量、研发效率和工时多个维度提供数据和记录支撑。每张截图，都能生动直观反映研发团队的交付、产出和成果。每一个数字的背后，都是团队一起努力的见证。
日常事务的回顾和提升总结
除了有效的需求研发和交付外，作为产品研发技术团队，难免还会有其他的日常事务，也可以进行总结和提炼。例如：工单处理、效率提升、创新、流程规范、老大难历史遗留问题解决等。
具体的再进行展开，以工单处理为例。可以统计一下，全年处理的工单有多少条、平均回复、响应和处理速度是多少、工单处理满意度怎么样，这些都可以借助YesDev进行系统的统计。例如：
通过丙图，也能直观看出每个产品线的用户反馈情况和客服的压力所在。
年底总结汇报时应注意的事项
最后，总结分享一下，在年底总结会议上进行汇报时，要注意的细节。
1、注意控制时间，简明扼要进行汇报；
2、去掉所有的切换效果和动画（除非真的很有必要）；
3、转存一份PDF作为备用，避免ppt有兼容性或打不开；
4、整理好ppt后先发给你的老大看一下；
5、可以适当补充一下个人的总结和感想（加分项）；
6、尽量不要说得太专业，要说一些普通老百姓都能听得懂的成果。
