模版大全（2）：技术研发部门如何制定OKR？

2018-03-06 10:51:00

有这样一则笑话：说的是程序员为了给自己的代码预留“优化空间”，在其中植入延迟的代码。笑话归笑话，其背后的问题发人深思——用僵硬的指标去衡量开发人员的工作量无异于自欺欺人。此时，就到了 OKR 大显神威的时候。本期《有干货》，将为您介绍技术研发部门的 OKR 模板。本文为模版大全（2）：技术研发篇

OKR 实施过程中，起草、制定好目标和关键结果是非常重要的一环，有效的 OKR 制定，需要满足 SMART 原则—— 明确的、可衡量的、可实现的、有相关性和有时限性。
目标（O）回答的是：我们想做什么，是定性的，要求能够鼓舞人心，激发团队共鸣。
关键结果（KR）回答的是：我们如何知道自己达成了目标要求，是定量的，设计 KR 最具挑战的部分是如何把目标中定性的描述抽象为定量的表示。

敏捷开发团队

1. 角色：研发主管

目标：成功完成 Web 组 Sprint
关键结果：

成功完成 Sprint1
成功完成 Sprint2
成功完成 Sprint3
目标：成功完成移动组 Sprint
关键结果：
成功完成 Sprint1
成功完成 Sprint2
成功完成 Sprint3
目标：截止三月底将开发工作进行外包
关键结果：
截止一月底签署新的供应商
截止二月中旬每个成员都加入 Worktile
截止三月中旬细化外包小组权限
截止三月底与产品管理部门就如何与外包团队合作进行培训
目标：截止二月底清理警报和监测
关键结果：
截止一月中旬对警报和监控基础设施进行差距分析
截止一月底确定前25％的服务
截止二月中旬提出5个，针对前25％服务的提醒

2. 角色：研发经理

目标：截至三月底完成新产品发布的所有需求
关键结果：

截止一月中旬完成第一阶段需求
截止一月底完成第二阶段需求
截止二月中旬完成第三阶段需求
目标：第一季度 100% 确认每个 Sprint 中的 P0 和 P1 级别 Bugs
关键结果：
截止一月中旬完成 Sprint1 中的 Bugs
截止一月底完成 Sprint2 中的 Bugs
截止二月中旬完成 Sprint3 中的 Bugs
目标：第一季度响应 98％以上的 SLA 用户请求
关键结果：
截止一月中旬完成 Sprint1
截止一月底完成 Sprint2
截止二月中旬完成 Sprint3
目标：在第一季度完成 90％以上的 Story Points
关键结果：
截止一月中旬完成 Sprint1
截止一月底完成 Sprint2
截止二月中旬完成 Sprint3
1. 角色：软件工程师
  目标：完成 Sprint1 所有 Sprint Stories 和 Bugs
  关键结果：
完成 Sprint1 中所有 Committed Stories
完成 Sprint1 中所有的 P0 和 P1 级别 Bugs
完成 Sprint1 中 75% 的 P2 级别 Bugs
在 Sprint1 中完成10次 Code Reviews
目标：完成 Sprint2 所有 Sprint Stories 和 Bugs
关键结果：
完成 Sprint2 中所有 Committed Stories
完成 Sprint2 中所有的 P0 和 P1 级别 Bugs
完成 Sprint2 中 75% 的 P2 级别 Bugs
在 Sprint2 中完成10次 Code Reviews
目标：完成 Sprint3 所有 Sprint Stories 和 Bugs
关键结果：
完成 Sprint3 中所有 Committed Stories
完成 Sprint3 中所有的 P0 和 P1 级别 Bugs
完成 Sprint3 中 75% 的 P2 级别 Bugs
在 Sprint3 中完成10次 Code Reviews

传统开发团队

1. 角色：研发副总裁

目标：确保以高质量按时交付 Release 版本
关键结果：

截止三月底，工程团队贡献了 200 个 Story Points
截止三月底，完成数据迁移
截止三月底，工程团队贡献 750 个 Code Review Points
截止三月底，添加100个自动化的前端测试
目标：搭建一个优秀的开发团队
关键结果：
第一季度沟通 50 名工程师
第一季度聘请 5 名新工程师
截止三月中旬为开发商实施精简的产品建议流程
截止三月中旬组织第二季黑客马拉松赛

2. 角色：首席架构师

目标：扩大我们的平台战略
关键结果：

截止三月底，对接 SalesForce
规划和完成基于 REST 的 API 规范，以便在3月底之前对我们的模型执行数据操作
截止三月底，完成架构图和平台白皮书
在 Clojure 中对我们的 NG 产品进行原型设计，以便在3月底之前与现有的基于 FORTRAN 的产品在性能和可维护性进行比较
目标：确保我们的产品横向扩展
关键结果：
重构产品架构以处理 200次／秒的平均负载，并在第一季度末达到 100ms 内响应 90% 的请求
第一季度维持当前服务器成本占公司收入的 5％
第一季度引入消息队列来扩展事件处理框架
第一季度用 NoSQL 替换 Oracle 数据库

3. 角色：软件工程师

目标：实施邮件发送体系重构
关键结果：

截止二月初与QA和首席架构师会面，确定重构计划
截止二月中旬清理电子邮件进程
通过代码冻结 Ship 邮件发送体系
通过代码冻结完整的文档传输和单元测试
目标：保持头脑和身体的状态，让工作更出色
关键结果：
第一季度参加 5 场开发者聚会
做一个开放源代码项目，在第一季度末获得超过 150 颗星
第一季度开发 Swift 和 Objective C 的初级应用程序
第一季度做 2000 次俯卧撑

4. 角色：软件测试工程师

目标：通过二月的 Release 版本驱动软件质量进步
关键结果：

截止二月底发现 50 个 Bugs
截止二月底发现 250 个开放的 P2 或更高级别的 Bugs
截止二月底将 Karma 测试覆盖率从86％提高到90％
三月保持 Zero Regressions
目标：学习巩固知识，并在第一季度迅速增长
关键结果：
观看所有 Egghead D3视频，并在第一季度末创建自己的功能部件
第一季度观看 25 部 Egghead 视频
第一季度使用node.js和socket.io制作浏览器游戏
完成 Codeschool 的3门课程

5. 角色：数据工程师

目标：为整个数据平台提供数据面板修改和分析
关键结果：

截止一月底实施新的队列分析数据面板
截止一月底优化销售和市场数据面板
截止二月底建立销售预测模型
截止三月底设计完成多元测试以获取对用户的影响
目标：以之前没有发现的角度来提升 Bottom Line
关键结果：
找出三个导致用户进入死循环的 Web 页面
总结五个最重要的影响用户合同的因素
总结公司或市场部门的大小对用户轨迹的影响
发现用户放弃使用的十大原因

总结

OKR 实施过程中，起草、制定好目标和关键结果是非常重要的一环，直接关系到公司实施 OKR 的成败，此系列文章会提供企业中大部分职位的 OKR 制定示例，帮助您更好的实施 OKR 。
下期预告：模版大全（3）：客户成功篇