昨天给大家讲到程序员OKR模板，今天继续为大家分析
技术团队拿到业务 OKR 后进行分解
注意这里的分解不是说技术团队背一个类似“用户量增长 20%”这样的指标，因为这样的指标是无法衡量这 20% 到底是不是技术团队的功劳，而是要从技术的角度对业务的 OKR 进行分解。
例如：“从 XX 渠道买量 XX 万”这个 KR 对技术团队来说关系不大，可以无需关注；
而针对“6 月底新增 XX 业务”这个 KR，技术团队直接将其转换为自己的目标即可。技术团队对“6 月底新增 XX 业务”这个目标进行分解，得出 1 个 KR：“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”。
评论回复“OKR”领取更多OKR行业模板
针对“用户量增长 50%”这个 KR，初看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。技术团队应该从技术的角度去分析业务的目标：哪些技术是和用户增长量相关的，这些技术目前是否具备，是否目前做得不好还有优化空间。
例如：影响用户增长量的一些技术指标有“安装包大小”、“App 启动时间”、“App 崩溃率”、“App 耗电情况”……等等，假设经过分析后技术团队认为目前安装包太大，并且 App 启动时间较长，那么可以将这两项相关的优化作为技术团队的 OKR：“App 安装包从 20M 缩减到 8M”，“App 启动时间从 2s 优化到 500ms”，而这两个 KR，业务负责人几乎是不可能提出来的。
除了上面的自上而下的目标分解外，技术团队也需要从团队和技术本身的角度来思考是否有这个阶段需要重点做的事情。
例如：我们团队目前的版本节奏较慢，而慢的原因是因为版本多而测试环境不足，测试环境不足是因为机器不够，那可以得出一个目标“解决测试环境不足导致版本等待的问题”，分解出来的 KR 可以是“添加 4 台测试环境机器”（是的，虽然是一件很简单的事情，但这也可以作为 KR），也可以是“引入 Docker，支持一台机器搭建 20 套环境”（这个 KR 比较符合技术人员的理解）。
通过这种 OKR 的方式进行思考和分解，最终技术团队要做的事情如下：
01. “5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”
02. “App 安装包从 20M 缩减到 8M”
03. “App 启动时间从 2s 优化到 500ms”
04. “引入 Docker，支持一台机器搭建 20 套环境”
关于今天的内容，你是怎么看的呢？欢迎交流分享。
想要了解更多OKR相关知识，请点击下方
源目标OKR，实效的目标管理工具
添加官方微信号：YMBOKR（源目标OKR）了解服务详情，还可免费订阅海量OKR资讯！
