OKR实施方法论

目录

• 前言
• OKR落地方案
  • 团队文化/价值观
  • 落地方案
• 基于Gitlab的OKR实施方法

前言

OKR这个名词最近两年在国内好像特别火，据说好多大厂都使用OKR替代KPI，我司也于去年年初的时候“风风火火”地搞过一阵，我也是借着这个机会才了解到OKR的基本概念：目标与关键结果（Objectives and Key Results），还煞有介事地买了一本《这就是OKR》研究了一下，只是后来没多久就听不到什么声音了（可能还是有的，只是我不知道），自己也就没有太当回事儿，简单地认为OKR就是一种新的管理方法或者考核方式，本质还是让员工更好的工作，也就继续努力干活去了。

去年年底的时候，部门负责人提出要进行年终答辩，每个同学都需要参与，答辩成绩决定年终的绩效评级。相较于先前仅限于团队内部的绩效评级，评委由多个部门团队负责人组成，考核成绩累积总分，可以实现更大范围内的公平公正；每一个绩效级别的人数不再受限于各自的团队人数，可以为每位同学争取更好的绩效提供更多的机会。我认为这是一件非常好的事情，积极地鼓励团队同学认真准备，自己也作为评委之一参与这次年终答辩。

答辩使用PPT汇报的形式进行，个人演讲5分钟，自由提问5分钟，主要考察以下4个方面：

1. 业务贡献（10分）
2. 架构能力（10分）
3. 创新思维（独立思考，5分）
4. 技术影响力（沟通表达、分享、指导新人，5分）

整个答辩过程进行地还是比较辛苦的，大约50~60位同学参与答辩，持续将近3天时间。期间需要听取每一位同学的工作汇报，提问并给出相应的得分。每一天结束之后，评委们还会对一天的答辩情况进行汇总，其中争议最大的就是评分标准。我自己感觉比较遗憾的是，评分标准这块儿提前没有制订标准，当时也没有能够沟通达成一致，最终的结论是评委们各自按照自己的标准进行评分。我自己也会记录自己团队同学答辩时的优缺点，白天答辩结束之后，利用晚上的时间趁热打铁与各个同学逐一沟通，详细地了解他们对答辩的看法与意见。

评委们之间的争论，和团队同学的面对面的沟通，触发我对答辩与考核方式的思考，以下仅代表个人观点：

1. PPT

   关于 PPT 的段子相信大家已经看到过不少，答辩之前就有同学提出过这样的问题：“如果有一个同学，他干的不好，但PPT讲的很好，怎么办？如果有另外一个同学，他干的很好，但PPT讲的不好，又怎么办？”。我们当时是这么回答的：

   • 干的不好，但PPT讲的很好
     一个同学可以成功的”忽悠“在座的多个评委，也是一种能力出众的表现。
      
   • 干的好，但PPT讲的不好
     基本的演讲或沟通能力应该是一个合格的员工必须具备的能力，如果有欠缺，应提前多练习。

   我认为，现实中”干的好“，而PPT”讲的很差“的同学是比较少的，更多的是“PPT讲的不如干的好”，没有把自己真实的工作价值展现出来，内心会有一种“吃亏”的感觉。

2. 数据

   “用数据说话”的理念现在已经很深入人心，以致于大家为了证明自己“干的好”，都会引用一些看起来很“好看”数字，通常都会是产品或业务的核心指标值或增长值。

   我认为，使用数据没有问题，必须满足2个条件：

   • 需要能够说明自己的工作与数据之间的联系
   • 需要能够证明数据的真实性

   假设，A同学负责系统开发工作，工作汇报时使用数据：“系统成功率：99%”，需要回答以下几个问题：

   • 系统成功率，从你接手这个服务时它就是99%，还是你做了什么优化工作带来的？如果是前者，这个数据就与A同学没有关系；如果是后者，继续回答；
   • 这块儿优化工作是与其他同学合作共同完成的，还是独立完成的？如果是前者，继续回答；
   • 自己独立完成的工作部分，对系统成功率的优化是多少？如果无法给出，A同学不应选取不可量化的数据用于工作汇报；如果可以给出，继续回答；
   • 如何证明数据是真实的？是否来源于第三方？如果无法说明，A同学不应选取未经过验证的数据用于工作汇报。

   此外，提到数据的时候，大多数同学只会提及当前值，往往会忽略目标值。例如：当前系统成功率：99%，而系统设定的目标成功率：99.99%，相当于仅完成目标规划的99.01%。

3. 人

4. 价值

5. 时间

6. 标准

OKR落地方案

团队文化/价值观

1. 集体责任感

   团队共同承担项目成功或失败的责任，每个成员对特定的重要结果负责。

2. 敢于挑战

   直面问题、解决问题。

3. 可量化的成果

   以结果为导向。

落地方案

1. 周期

   以周为单位迭代，例行周会使用OKR进行工作汇报及更新。

2. 目标/关键结果数量

   每个人可设置3-5个目标（O），每个目标可与若干个关键结果（KR）相对应。关键结果的数目原则上不限制，可自行根据需求设置，但不建议太多。

3. 目标类型

   • 承诺型
     团队整体规划的事项，必须完成。
      
   • 日常型
     业务或临时需求。
      
   • 愿景型
     自我挑战的事项，涉猎范围原则上不限制，最多可占用工作时长的20%，如：每周1天。

4. 关键结果权重

   每一个关键结果需要设置相应的权重值，范围：0.1-1.5。权重值的选取建议参考以下4个区间：

   • <= 0.6：日常型目标；
   • (0.6, 0.8]：承诺型一般目标；
   • (0.8, 1.0]：承诺型核心目标，技术或服务能力参考业界标准；

   • 1.0：愿景型目标；

5. 评分规则

   能者多得、多劳多得，以单项KR为计分单位，累计总分。

   单项KR评分公式：(工作时长 / 8) * 0.3 * 权重值 * 完成度。

   其中，工时时长以 小时为单位，计算时转换为工作日（每个工作日为8小时）；每个工作日的基础分值为0.3；完成度取值范围：[0.00, 1.00]，如果完成情况超出预期，取值也可以大于1.00。

   注： 愿景型KR不列入评分范围。

基于Gitlab的OKR实施方法

• 使用Milestone表示 目标（O）
• 使用Issue表示 （关键结果）
• 使用Label表示 关键结果权重值
• 使用/spend表示 工时
• 使用百分比表示 完成度

1. 创建Project（项目）

   

2. 创建Milestone（里程碑）

   Milestone（里程碑）用于目标（O）；其中， 标题（Title）用于说明目标名称，通常为项目名称；描述（Description）用于详细说明项目需要完成的系统功能、服务模块等；示例如下：

   

3. 创建Label（标签）

   Label（标签）用于权重值，如下：

   

4. 创建Issue（关键结果）

   Issue（事务）用于关键结果（KR）；其中，标题（Title）用于说明关键结果名称，通常为需要开发的服务模块或系统功能名称；描述（Description）用于详细说明关键结果的可衡量指标，用于团队负责人或相关业务同学可清晰判断关键结果的完成情况；执行人（Assignee）用于说明关键结果具体的执行人；里程碑（Milestone）用于说明关键结果对应的目标；Labels（标签）用于说明关键结果对应的权重值；示例如下；

   

5. 更新Issue（关键结果）进度

   Issue进行过程中，使用评论（commet）记录进展详情及工作时长，如下：

   

   注： 工作时长使用Gitlab quick actions中的 /spend 进行记录。

   Issue进行完成之后，需要团队负责人或相关业务同学使用评论确认完成度，如下：

   

   Issue完成度确认之后，即可关闭Issue。

   注： 已关闭Issue已关闭如需要更新，需要重新开启，且更新完成之后需要重新确认完成度之后才可关闭。