OKR-VUCA时代目标管理利器实践分享

初识OKR在2017年，当时前公司正在引入OKR管理，有幸与公司人力的同事一起参与了外部咨询公司的OKR导入培训，并后续参与了公司OKR的推广，把OKR管理在企业中做到先僵化后固化再优化即守破离的境界。现在本人所在公司，项目管理组（本人所在的组）也在实施团队级OKR，本文将从进行产品级OKR，团队级OKR以及个人OKR的实践分享

OKR(objectives and key results)发明于英特尔，兴盛于Google，不仅是一个目标管理工具，也成为了一种工作理念。

为什么要用OKR

我们正处于VUCA的时代，卓越团队应该把精力投入到对至关重要目标最有影响的事务中。当团队在目标上下一致（聚焦）时，使用OKR能充分给予成员自由与宽松的环境，发挥成员的主动性，高效协作，持续沟通。OKR具有聚焦、透明公开、协作、挑战的特点，可以让团队不断的提升业绩。对个人而言，花在打磨OKR上的时间越多，能从⼀个更完整图景上思考，个人的策略性会越来越强，明确重要优先工作，避免伪工作（价值低），同时通过合理的衡量标准，可自我校验，发现目标与结果之间的差距，不断修正改进。

怎么实施OKR

 OKR实施需要先确定实施级别的使命愿景价值观，如实施团队级OKR，需要考虑团队的使命是什么，具有怎样的愿景，以及怎样的价值观。需要考虑以多长的周期进行实施，推荐的做法是按季度。每季度初制定OKR，无论是产品级OKR还是团队级OKR，都应该是自上而下和自下而上制定，团队成员对齐产品/团队OKR，根据产品/团队KR对接到个人的O，并根据O拆解成量化的KR。同时通过月度Review会议，对齐KR进度以及是否存在卡点障碍，需其他人协助。季度末进行OKR总结以及OKR打分，同时本季度的OKR复盘与检视的经验输入下个季度制定个人OKR，通过不断优化达到“离”的境界。在实施OKR过程中，建议选择一位团队成员作为OKR大使（类似Scrum中敏捷教练），进行维护OKR流程以及OKR实施细则。

实施产品级OKR团队级OKR经验

最开始做产品级OKR，源于是公司想要在内部的管理系统上做个全公司的报告模块结构化，包括项目周报，季报，个人周报、年度报告等。产品经理基于这个目标，写了一个产品级的O是2季度实现公司报告模块的功能，达到整个公司报告管理统一。根据产品O拆解了3个量化KR，举个例子其中一个KR2：实现项目报告结构化，至少调研公司200个项目目前报告格式，并形成统一模板，达到公司至少80%项目利用新报告系统写报告。当时整个开发团队是6人（前后端）测试1人，以及公共部门对应的系统运维1人。所有的团队成员基于产品O与KR拆解到个人，比如其中一个开发人员的O是：“理解产品需求，设计代码实现，实现报告模块”，并拆解了个人KR。因为一直采用敏捷开发，产品的O对应到敏捷中史诗故事Epic，产品KR就是Feature（特性），进一步拆分成一个迭代可以完成的Story以及Task进行实现。

现在实施团队级OKR，首先我们确定了项目管理组在公司架构里面的愿景使命以及组内的价值观。每个季度团队成员制定OKR的时候，都会先让组长给出本季度团队级O与KR。如本季度团队级O是“进度管理和质量管理优化的季度专项工作”,其中一个KR1：定义清晰的DOD，本季度6个迭代至少有4个迭代达到任务完成度100%；团队成员基于团队级的KR1去承接到个人的季度O，比如我的其中一个季度O是“自己参与的某个项目定义清晰的DOD，重点关注迭代完成度”。然后我根据O拆解了3个KR，其中一个KR1是“管控迭代任务和过程，定义DOR与DOD，保证迭代任务100%完成”。并基于自己定的OKR在每2周的一个scrum迭代中执行，以及季中review，季度末总结并对个人KR进行打分。

采坑总结

无论是实施产品级OKR还是团队级ORK，很多KR没有量化，变成了KA（关键行动）所以就导致最后的KR打分环节流于形式，没有起到“检视&调整”的作用。其次是OKR是一个自上而下自下而上的思考框架，经常我们会发现产品级OKR由产品负责人或者产品经理制定完之后，只是停留在了某个人层面或者产品本身功能层面即这个月产品要完成哪些功能，但是没有传递到整个团队，导致开发团队，测试团队，运维团队或者安全团队没有基于这个产品OKR去拆解到个人的O与KR中。把产品OKR变成产品路线图，忽略了自下而上的过程。最后是OKR不等于KPI，KPI（关键绩效指标）是用来衡量驱动当前运营模式的关键成功因素的指标。而OKR则是一个总体目标管理系统，让团队聚焦目标。