一文秒懂！程序员OKR模板详解（上）

无论是OKR依然KPI，都有“可权衡的”“可量化的”协议规定，不过关于非营业团队比方工夫团队来说，绩效考察圭臬何如协议却是个令人头疼的题目。

比方某通讯大厂考察步骤员的 bug 数和等第，而且尤其让人蛋疼的是同时考察测试职员浮现 bug 的数目，结果步骤员和测试员为了一个题目是 bug 依然需求漏掉、bug 等第是告急依然通常，或许吵上 2 个小时，2 个小时吵不下那就拉上两边主管再吵 2 小时，还吵不下那就拉上司理一连吵 2 小时，于是最终就看谁会吵，谁官大，搞得步骤员和测试员身心俱疲，干系很仓促！

比方：假设考察步骤员用 bug 数、代码行数、版本数，那 2020 年用这个目标，2023 年也依然这个目标，如此的绩效宗旨有什么意旨呢？

能够看两个团队谁的代码行何等？能够看谁的团队 bug 数何等？能够看谁的团队版本数何等？能够看谁的团队分享次数何等？这些原来都弗成。

比方：引入 ElasticSearch 外面上是能够擢升查找功能的，但也许正在引入的这一年反而会带来良众题目，而能带来众少收益还不确定，这个时刻何如定 KPI？

咱们以一个假念的工夫团队为例，假设这个工夫团队做一款购物 APP，咱们看看 OKR 该当何如做。

比方：营业宗旨能够是用户量增进，也能够是用户灵活度，也能够是商场职位，还能够是订单量，还能够是成交金额，还能够是利润……那这半年事实该当以哪个或者哪几个为宗旨，这是营业担任人（或者决定团队）要念显露的，而不行像 KPI 相同，每个目标都按部就班的设定一个增进量就能够了。

然后营业担任人解析了几个 KR，比方：“用户量增进 50%”，“从 XX 渠道买量 XX 万”（这个是 KPI 式的 KR）、“6 月底新增 XX 营业”（这个是里程碑式的 KR）。