不会写研发部门OKR？来这里看看吧

研发部的人对于项目管理非常熟悉，每个迭代的过程就是一个项目管理进行的过程，可以说属于能把项目管理做好的人群中的佼佼者。但也正是因为对于项目管理过于熟悉，会导致在写研发部的OKR的时候收到影响，错将项目里程碑当成目标的关键成果来建立。

什么是项目里程碑？

项目的各个阶段需要达成的目标可以设立为项目里程碑，通常都会有时间线，上一个里程碑完成进入下一个里程碑。

什么是OKR的关键成果？

衡量OKR是否达成的几个关键标准，没有时间线的先后顺序但会有优先级，关键成果通常会是一个具有挑战性的数据指标或者某件事情具体的一个状态。

那么接下来让我们看具体的例子：

研发部5月产品迭代项目：

里程碑一：完成产品设计与宣讲（5/1-5/8）

里程碑二：进行产品开发与提测（5/9-5/21）

里程碑三：完成二轮验收与上线（5/22-5/31）

研发部5月OKR：

完成一次高质量不延期的迭代：

关键成果一：上线时间为XXX

关键成果二：测试环境bug数量少于XXX

关键成果三：线上相关客户事务少于XX

对比项目规划和OKR，就能看出上文提到过的两者之间的不同。一个是挑战标准，一个是做事情的规划。所以一定不要再用项目管理的思维来思考如何制定OKR了。

如果你还是不能确定自己制定的是否为正确的OKR，那么建议使用Tita的OKRs-E的框架来制定。首先制定目标，目标是一个比较抽象的方向，目标之下制定关键成果指标，最后在关键成果下再分解E执行。制定完之后再审视你的OKRs-E，要确保目标与关键成果，关键成果与E执行是不同的，这样可以避免大部人将具体的执行制定成关键成果，在执行下分解执行就能很容易的发现问题所在。

最后分享给大家一个研发部门的OKRs-E:

O：打造一支高效配合的研发团队

KR1：完善一套完整的迭代流程规范

E：开展迭代流程沟通讨论会（任务）

制定迭代流程规范并进行公示（任务）

每天检查是否有不符合规范的行为进行讨论纠正（循环任务）

开展新迭代规范执行情况反馈会议（任务）

KR2：本周期无因团队配合产生的交付延误

E：本周期产品迭代（项目）

每天检查是否出现延期现象进行讨论与工作调整（循环任务）

KR3：本周期无因团队配合导致的线上事务

E：每天进行线上产品半小时测试（循环任务）