这两天在写年中总结，正好昨天也有人问到我怎么写，今天就简单聊聊这个话题。
首先声明，今天和大家讲的，只是我个人在36氪的经验，肯定不适用所有人，务必要根据你们公司的具体考核情况来定。
接下来说下我这次写年中总结的背景：
1、基于OKR制定复盘思路。36氪的绩效评估工具是OKR，年初就制定好了每个人的目标和达成路径，年中总结也会基于此来总结和梳理。如果你是背KPI的，比如一些商业化项目，那考虑更多的则是KPI指标达成情况。
2、基于工作量收集数据。无论是年中还是年末，但凡总结汇报，就最好有数据证明。对业务导向型公司，比如36氪，产品经理的目的是支持好业务发展，数据上会更强调支持力度，也就是完成项目数和平均项目对业绩的贡献额，前者主要是工作量层级的，后者是指你设计的产品对业务人员达到他的KPI有多大帮助，有时候后者不太好统计，那可以降级处理，或者更强调前者。
3、基于用户流量提升收集数据。如果是流量导向型公司，则更应该强调你上线的版本对用户流量提升有多大帮助（在排除掉运营策略的前提下），有些功能不好衡量，比如优化了评论体验，但不知道评论量提升到底是体验升级了还是话题用户感兴趣愿意评论，那可以尝试换个角度去挖一些数据，比如平均发评论时间是否减少了，平均每文章评论量是否比以前提高了等等。
4、收集历史数据。上述2、3收集完毕后，为体现当前这半年做的比之前更好，还要去收集历史数据进行对比，可以是去年同期，也可以是按6个月倒推。要收集的仍旧是工作量数据和流量数据。
OK接下来再介绍我的年中总结框架：
第一部分：工作成果
1、罗列上半年所有产品线的所有版本迭代记录，包括：项目名称、项目开发到上线的时间、项目每个版本都做了哪些功能、负责产品经理是谁、项目是商业化产品还是用户向产品、是否是从0到1的新项目等等，最终会得到一个如下表格：
所有版本迭代记录
2、按项目，统计2019上半年每个项目共迭代的版本数，从而大概得出我们平均对每个项目的支持力度。再汇总2018年下半年项目版本数，和上半年做比较。
3、有时候同一个项目在迭代过程中，又有流量提升的功能，又有业务支持功能，那就需要再根据业务类型对版本迭代再做一次合并统计，比如36氪就会按toC商业化、toB商业化、内容流量线、内部支撑线再分为4个业务方向。如下图：
按业务线统计版本数
同样，在2019上半年基础上，再把2018下半年的工作按这4个方向汇总统计，和上半年做对比。
4、再按人头，统计2019上半年平均每个人迭代了多少版本。但要注意这种统计有点粗暴，毕竟每个版本的工作量各有大小，具体统计时还应该根据版本大小，是否新项目进行备注说明。在统计2018下半年的时候，还要备注哪些人是已离职的，哪些人是新入职的，以把熟悉工作的速度也纳入考核。
5、最后，我会加上产品团队在2019上半年主导的从0到1的新项目有哪些，以及这些项目对公司的价值是什么，同样会对比2018年下半年的新项目数，突出团队的工作状态和创新性。
第二部分：工作不足
除了说成果，不足之处肯定也是要如实汇报的，目的是为了更好地发现问题，直面问题。总结时务必要实事求是，不要避重就轻。比如某些版本的功能对数据增长无效，比如某个模块的设计时间过长，比如缺乏创新的增长手段等等，也是为了引出接下来的解决思路。
第三部分：2019下半年，对不足之处的改进思路
沿着上面的不足，提出改进思路。需要额外注意的是，最好这里结合2019下半年的业务规划来讲，也就是具体什么时候，要做什么事，为了解决什么问题。第一是有针对性，第二是有时间计划，第三是有期望结果，以便年终再进行复盘时参考。
以上三部分就是我在36氪的年中总结主要内容，但还是那句话，不代表就适合你，更多想分享的是一种思路，希望能帮到你。
