3、那么技术团队拿到业务 OKR 后进行分解，注意这里的分解不是说技术团队背一个类似“用户量增长 20%”这样的指标，因为这样的指标是无法衡量这 20% 到底是不是技术团队的功劳，而是要从技术的角度对业务的 OKR 进行分解。例如：“从 XX 渠道买量 XX 万”这个 KR 对技术团队来说关系不大，可以无需关注；而针对“6 月底新增 XX 业务”这个 KR，技术团队直接将其转换为自己的目标即可。技术团队对“6 月底新增 XX 业务”这个目标进行分解，得出 1 个 KR：“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”、

4、针对“用户量增长 50%”这个 KR，初看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。技术团队应该从技术的角度去分析业务的目标：哪些技术是和用户增长量相关的，这些技术目前是否具备，是否目前做的不好还有优化空间。例如：影响用户增长量的一些技术指标有“安装包大小”、“App 启动时间”、“App 崩溃率”、“App 耗电情况”……等等，假设经过分析后技术团队认为目前安装包太大，并且 App 启动时间较长，那么可以将这两项相关的优化作为技术团队的 OKR：“App 安装包从 20M 缩减到 8M”，“App 启动时间从 2s 优化到 500ms”，而这两个 KR，业务负责人几乎是不可能提出来的。

5、除了上面的自上而下的目标分解外，技术团队也需要从团队和技术本身的角度来思考是否有这个阶段需要重点做的事情。例如：我们团队目前的版本节奏较慢，而慢的原因是因为版本多而测试环境不足，测试环境不足是因为机器不够，那可以得出一个目标“解决测试环境不足导致版本等待的问题”，分解出来的 KR 可以是“添加 4 台测试环境机器”（是的，虽然是一件很简单的事情，但这也可以作为 KR），也可以是“引入 Docker，支持一台机器搭建 20 套环境”（这个 KR 比较符合技术人员的理解）。

通过这种 OKR 的方式进行思考和分解，最终技术团队要做的事情如下：

“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”

“App 安装包从 20M 缩减到 8M”

“App 启动时间从 2s 优化到 500ms”

“引入 Docker，支持一台机器搭建 20 套环境”

　　写在最后

OKR 对很多人来说还是一个新事物，我接触 OKR 并不久，也许还有很多东西没有彻底理解，也许实践中也还会遇到各种各样的困惑，但是单纯从思路的转变来看，我认为 OKR 不仅仅是一个绩效和目标管理方法论，更是一种“聚焦目标”的思维方式，掌握这种思维方式后，不仅可以在工作中应用，在个人生活中也完全可以应用，并都能够取得很好的效果！

　　作者介绍

李运华，阿里游戏资深技术专家，带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责；专注于开源技术、系统分析、架构设计，对互联网技术的特点和发展趋势有较深入的研究，对系统解耦、高性能、高可用架构有丰富的经验。

最后，安利一发小广告：

《聊聊架构》现货新鲜上架，

京东物流急速发货！

　　今日荐文

　　据说培养这些软技能，可以有效提升程序员的幸福感！