1000行代码 VS 10行代码，解决同样问题谁绩效更好？

导读

程序员们讨厌各种莫名其妙的衡量标准，技术 Leader 们也总苦恼于从何维度去考量团队里的程序员们。以至于长久以来，将代码行数与生产力划等号，将 Bug 数量与绩效直接挂钩的 OKR 设定时有发生。

程序员的 OKR 究竟该如何设定？本文作者从技术负责人的角度给出了自己的看法与实践经验，对程序员、技术 leader 都有较大的参考价值！点赞收藏转发，一键三连，为好文章的传播扩散添砖加瓦～

目录

1 前言

2 第一性原则

3 效能

4 质量

5 可持续

6 可度量

7 写在最后

01

前言

开篇抛出几个思考题，大家可以想一想：

如果 1000 行代码和 10 行代码都能解决同一个问题，哪个版本的代码应该得到更好的绩效？

如果奖励开发人员编写额外代码，是否会导致软件变得更为臃肿就，变得难以维护、变更？

如果鼓励开发人员用最短行数代码，是否会导致协作人员难以理解代码含义，增加沟通成本？

近年来，OKR 逐渐替代了 KPI，在包括 IT 行业在内的各行各业落地。一般而言，OKR 的制定往往有从上至下，从下至上两种方式。

从上至下的方式一般由团队负责人制定，层层下发逐层对齐，常见的误区往往将团队代码行数与生产力对齐，将 Bug 数量与绩效直接挂钩，导致动作变形贻笑大方。

从下至上的方式对于研发同学而言也并非易事，在实际场景中不少提交上来的内容往往不如人意，少不得一通口舌几番修改。

过去的几年间，大环境下行带来了降本增效的要求，大家的认知都或主动被动地进行了刷新，对 OKR 的本质也有了更深层面的理解：在产品需求面前，研发不应是被动的响应者。研发也需要有高度，需要站在业务的角度去思考哪些是对业务有价值的需求，优先级是怎样的。因此，研发 OKR 不应局限在牛逼地完成产品需求，而是要牛逼地完成那些对业务有价值的需求。不要只是瀑布流式地接受产品的指派，而是走在前面，一起思辨，这个需求创造了什么价值，它重要吗？合理吗？急迫吗？

为了帮助研发同学更加理解 OKR，将本人关于 OKR 的思考，作文以记。

02

第一性原则

业务部门中的研发团队其实是支撑团队，业务目标才是第一性的。此即有第一层的延伸：

层次：目标是有层次的。在业务目标的层次下，研发团队本身是无目的、无意识的，只具备工具属性。

正如微信支付的业务负责人，他的目标可以是“打造极致的用户体验”，而绝不会是“系统实现5个9的可用性”。在业务的讨论层次下，研发没有主导权。条条大路通罗马，研发目标只是实现业务目标的一个可行路径，研发目标无条件对齐业务目标。不会出现超越业务目标的研发目标，这样对组织而言是人力和经费的浪费。

那么在落地执行的层次上讲，研发的目标是怎样的呢？如果说研发团队本身是工具属性，即如庖丁手中的刀，那是否意味着研发的 OKR 直接跟随产品 OKR 即可了呢？以产品的目标为目标，完成产品的需求即是开发人员的 OKR，岂不是快哉，很省事？！

这里我们就要谈到第二层的延伸：

研发团队的主观能动性：一个需求，由张三完成和李四完成有何区别？如果两个人都以完成产品需求为 OKR 目标，那相当于抹平了差异，忽略了研发人员的主观能动性。

那么完成相同的需求，研发之间的差异性体现在什么地方呢？当我们说一个研发靠谱，活干得漂亮，究竟是在说什么呢？我们通常是指两点：效能和质量！我们下文对这两点展开论述。

因此，对研发团队而言，如何完成需求不是 OKR，如何牛逼地完成需求，才是 OKR！---- 完成需求是第一位的，体现研发团队的价值；牛逼地完成是必要的，体现开发个人的价值。

其中，牛逼 = 高效能 + 高质量 + 可持续！

03

效能

效能就是快，包括：

需求交付快；

低运营，免运营；

后续迭代快等；

所有研发人员对此效能的目标应该是一致的，但如何实现，则与各人具体的工作相关。

比如，有的团队瓶颈在于研发环境糟糕，一次编译需要10分钟，那么其中一条KR可能就是：编译耗时缩短到2分钟以内。至于如何落地，那可能又要把KR当成目标，对实际情况进行细化分析。

那么2分钟是如何得来的呢，如果我们只会从上到下的拆分目标，那难免会出现拍脑袋的情况。此时又需要由下而上的反馈机制。提升编译速度的技术路线是什么，常规可以达到什么程度，实施阶段及各阶段在何时可以完成，这些在制定 OKR 时都是要有概念的。

04

质量

质量就是好，同样包括多方面：

用户体验好，如响应快；

无资金、数据等安全问题；

无现网故障问题；故障时低 MTTR 等；

质量是效能的基石，没有质量的快是无任何意义的。对研发人员而言，实现质量的路径是明确的，就是规范。

质量保证有明确的模式，在各个团队的差异就在于各环节执行的到位程度。有的团队可能对代码把控比较强，但是灰度发布执行并不到位等，可能就需要提升系统面向灰度发布的能力。

再如对资金安全保障，同样需要将业界的套路与自己实际场景进行结合，查缺补漏，并以此作为自己的 OKR。

质量的保证措施可能会拖慢效能，如此团队的 OKR 也可以是如何高效能地保证质量，包括通用能力的快速复制等。

05

可持续

一次快不算快，可能以后步步慢。同样，一次好未必是真好，可能是运气好。高效能和高质量必须是可持续的。为了完成可持续的目标，可能就有很多负债需要解决。这也可以作为研发的 OKR。

06

可度量

当每位同学在年初都设计好了自己的 OKR，年终我们来评定的时候，如何清楚他们的完成程度呢？

如果某个同学的目标是：提升某某业务系统的开发效能。年终核算，该同学说自我感觉效能提升了很多，值得一个五星。那最后五星指标肯定是不够用的。因此 OKR 必须客观可度量。

某管理学大师即称：若你无法衡量它，即无法改进它。不可衡量的目标是没有意义的。若不可衡量，说明当前工作模模糊糊，一塌糊涂。

举例而言，研发同学的产出可以从两个方向量化：

从交付周期，比如对某类需求，开发都需要较长时间交付，那我们要思考是否可以抽取共性能力，加快迭代速度；量化指标就是此类需求（如表单收集类需求）免开发；

从产品质量上，如境外支付 RTT 是 300ms，那我们的量化指标是提升到 200ms 内。

07

写在最后

在 OKR 的制定中，可以遵循两个简单的衡量指南：

使用专注于结果而不是输出的衡量指标。

使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。

衡量指标是激励研发工作的重要机制，希望大家都能从本文中获取到有效信息，制定出合理且具有牵引性的OKR～