程序员的工作怎么量化？bug 数？代码行？版本数？
做过程序员的都知道，这些指标都是不可行的。
例如某通信大厂考核程序员的 bug 数和等级，并且更加让人蛋疼的是同时考核测试人员发现 bug 的数量，结果程序员和测试员为了一个问题是 bug 还是需求遗漏、bug 等级是严重还是一般，能够吵上 2 个小时，2 个小时吵不下那就拉上双方主管再吵 2 小时，还吵不下那就拉上经理继续吵 2 小时，于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张！
即使程序员的工作可以量化，那每次绩效都是这几个指标，定绩效目标还有意义么？
例如：假设考核程序员用 bug 数、代码行数、版本数，那 2000 年用这个指标，2017 年也还是这个指标，这样的绩效目标有什么意义呢？
团队 leader 如何制定团队的 KPI？
可以看两个团队谁的代码行多么？可以看谁的团队 bug 数多么？可以看谁的团队版本数多么？可以看谁的团队分享次数多么？这些其实都不行。
前瞻性的工作谁愿意做，有风险的工作谁愿意做？
例如：引入 ElasticSearch 理论上是可以提升搜索性能的，但可能在引入的这一年反而会带来很多问题，而能带来多少收益还不确定，这个时候怎么定 KPI？
如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是可以引入大数据来做精准推荐；而如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、bug 数、单元测试覆盖率这些。
一个技术团队 OKR 的实例
我们以一个假想的技术团队为例，假设这个技术团队做一款购物 APP，我们看看 OKR 应该怎么做。
1、首先，业务负责人（或者决策团队）要确定半年的业务目标。
这个业务目标不能是眉毛胡子一把抓，而应该综合市场、用户、竞争对手等分析的出来。
例如：业务目标可以是用户量增长，也可以是用户活跃度，也可以是市场地位，还可以是订单量，还可以是成交金额，还可以是利润……那这半年到底应该以哪个或者哪几个为目标，这是业务负责人（或者决策团队）要想清楚的，而不能像 KPI 一样，每个指标都按部就班的设定一个增长量就可以了。
2、假设业务负责人确定这半年业务目标是“用户量增长”。
然后业务负责人分解了几个 KR，例如：“用户量增长 50%”，“从 XX 渠道买量 XX 万”（这个是 KPI 式的 KR）、“6 月底新增 XX 业务”（这个是里程碑式的 KR）。
3、那么技术团队拿到业务 OKR 后进行分解。
注意这里的分解不是说技术团队背一个类似“用户量增长 20%”这样的指标，因为这样的指标是无法衡量这 20% 到底是不是技术团队的功劳，而是要从技术的角度对业务的 OKR 进行分解。
例如：“从 XX 渠道买量 XX 万”这个 KR 对技术团队来说关系不大，可以无需关注；
而针对“6 月底新增 XX 业务”这个 KR，技术团队直接将其转换为自己的目标即可。技术团队对“6 月底新增 XX 业务”这个目标进行分解，得出 1 个 KR：“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”。
针对“用户量增长 50%”这个 KR，初看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。技术团队应该从技术的角度去分析业务的目标：哪些技术是和用户增长量相关的，这些技术目前是否具备，是否目前做的不好还有优化空间。
例如：影响用户增长量的一些技术指标有“安装包大小”、“App 启动时间”、“App 崩溃率”、“App 耗电情况”……等等，假设经过分析后技术团队认为目前安装包太大，并且 App 启动时间较长，那么可以将这两项相关的优化作为技术团队的 OKR：“App 安装包从 20M 缩减到 8M”，“App 启动时间从 2s 优化到 500ms”，而这两个 KR，业务负责人几乎是不可能提出来的。
4、除了上面的自上而下的目标分解外，技术团队也需要从团队和技术本身的角度来思考是否有这个阶段需要重点做的事情。
例如：我们团队目前的版本节奏较慢，而慢的原因是因为版本多而测试环境不足，测试环境不足是因为机器不够，那可以得出一个目标“解决测试环境不足导致版本等待的问题”，分解出来的 KR 可以是“添加 4 台测试环境机器”（是的，虽然是一件很简单的事情，但这也可以作为 KR），也可以是“引入 Docker，支持一台机器搭建 20 套环境”（这个 KR 比较符合技术人员的理解）。
通过这种 OKR 的方式进行思考和分解，最终技术团队要做的事情如下：
01. “5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”
02. “App 安装包从 20M 缩减到 8M”
03. “App 启动时间从 2s 优化到 500ms”
04. “引入 Docker，支持一台机器搭建 20 套环境”