这两天中间我在写总结。就在昨天，有人问我怎么写。今天我就简单说说这个话题。
首先，我今天给大家讲的只是我在36Kr的亲身经历。它当然不适用于所有人。必须根据你公司的具体考核来确定。
接下来说说我这次年中总结的背景:
1.制定基于OKR的重新报价的想法。36Kr的绩效评估工具是OKR。年初定下了每个人的目标和成就路径，年中总结会以此为基础进行总结和梳理。如果你背KPI，比如一些商业项目，那就多考虑KPI指标的达成情况。
2.根据工作量收集数据。无论是年中还是年底，最好有数据证明总结报告。对于以业务为导向的公司，比如36Kr，产品经理的目的是支持业务发展。数据将更加强调支持度，即完成项目的数量和项目对绩效的平均贡献。前者主要是在工作量层面，后者是指你设计的产品能在多大程度上帮助业务人员实现他们的KPI。有时候，后者不好统计，可以降级，或者更强调前者。
3.根据用户流量改善情况收集数据。如果是流量导向的公司，你要强调你的网络版对用户流量的帮助有多大(排除运营策略的前提下)。有些功能不好衡量，比如优化评论体验，但是你不知道评论量的增加是体验升级还是话题用户有兴趣愿意评论。可以试着从另一个角度挖掘一些数据，比如平均评论时间是否减少，每篇文章的平均评论量是否比以前高等等。
4.收集历史数据。2.上述采集后，为了说明当前半年比以前好，需要采集历史数据进行对比，可以是去年同期，也可以是倒推6个月。我们需要收集的仍然是工作负载数据和流量数据。
好了，接下来介绍我的年中总结框架:
第一部分:工作成果
1.列出上半年所有产品线所有版本的迭代记录，包括:项目名称，从项目开发到上线的时间，项目每个版本做了哪些功能，产品经理是谁，项目是商业产品还是面向用户的产品，是否是从0到1的新项目等。，最后得到如下表格:
所有版本迭代记录
2.按项目统计2019年上半年每个项目的迭代次数，从而大致得出我们对每个项目的平均支持度。然后总结2018年下半年项目版本数量，与上半年对比。
3.有时候在迭代的过程中，同一个项目有流量推广和业务支撑的功能，需要根据业务类型再做一次版本迭代的合并统计。比如36Kr会按照toC商业化、toB商业化、内容流量线、内部支持线划分为四个业务方向。如下图:
按业务线统计版本号
同样，在2019年上半年的基础上，2018年下半年的工作也将在这四个方向进行总结和统计，并与上半年进行对比。
4.按人头统计2019年上半年每人平均迭代了多少个版本。不过需要注意的是，这种统计有点粗暴。毕竟每个版本都有自己的工作量。具体统计的时候，还要根据版本大小，是否有新项目进行备注。2018年下半年，也要注意哪些人离职了，哪些人是新来的，这样才能把熟悉工作的速度纳入考核。
5.最后补充一下2019年上半年产品团队带领的从0到1的新项目有哪些，对公司的价值是什么。我也会对比2018年下半年的新项目数量，突出团队的工作状态和创新。
第二部分:工作不足
除了成绩，缺点也一定要如实汇报，才能更好的发现问题，直面问题。总结时事，一定要实事求是，不要避重就轻。比如某些版本的功能对数据增长无效，比如某个模块的设计时间过长，比如缺乏创新的增长手段等。，这也引出了下一个解决方案。
第三部分:2019年下半年，不足改进思路
连同以上不足提出改进思路。需要注意的是，最好结合2019年下半年的经营计划，也就是什么时候，做什么，解决什么问题。一是有针对性，二是有时间计划，三是有预期结果，可以作为年终复盘的参考。
以上三部分是我在36Kr年中总结的主要内容，但还是那句话，不代表适合你。我更想分享的是一个想法，希望能帮到你。
本文来自Total.不想长大投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/634105.html
微信扫一扫 
