根本不存在\n \n \n \n\n\n年底绩效考核，有这样一个场景：\n\n程序员小张和小王在同一个项目上开发，遇到了同样的问题需要去解决。\n\n小张自己写了一个 1000 行代码的轮子，完美地解决了问题。代码写得好，测试也充分，部署和操作都有很好的文档记录。\n\n小王去码头待了半天，在喂鸽子薯条的时候思考问题。然后他回到办公室，删除了100行代码，部署了更改——问题也解决了。\n\n那么问题来了，这两位程序员，谁今天的工作是更“高效”的？\n\n问题引申得更广泛一点：\n\n如果1000行代码和10行代码都能解决同一个问题，哪个版本的代码应该得到更好的绩效？\n\n如果奖励开发人员编写额外代码，是否会导致软件变得更为臃肿，难以维护、变更？\n\n如果鼓励开发人员用最短行数代码，是否会导致协作人员难以理解代码含义，增加沟通成本？\n\n所以，Martin Fowler才会在十年前就做下定论——软件开发的生产力无法有效地衡量，换言之：\n\n所谓的软件生产力根本不存在？\n\n优秀的软件开发人员所做的是解决问题。实际上，这与生产刚好相反。创建技术工件，如代码、文档、数据等……都是实现消除问题目标的必要操作。\n\n然而很多时候，解决问题的最有效方案可能只是一次5分钟的对话。\n\n但对于程序员而言，OKR的存在又是必要的，一方面方便指导工作方向，另一方面也总是需要被评估一年的工作产出。但怎么写好OKR去量化可能并不存在的软件生产力似乎又是个悖论，或许可以这样拆解一下？\n\n业务部门的研发团队是支撑团队，业务目标是第一性的。而评判研发活干得怎么样，通常指的是他的效能和质量。\n\n完成需求是第一位的，体现研发团队的价值；\n牛逼地完成是必要的，体现开发个人的价值。\n\n牛逼 = 高效能 + 高质量 + 可持续！\n\n效能就是快，包括：需求交付快；低运营，免运营；后续迭代快。\n\n质量就是好，包括：用户体验好；无资金、数据等安全问题；无现网故障；故障时低 MTTR 等。\n\n可持续就是前二者必须是持续性的，一次的好坏可能都是运气。\n\n目标还应该是可度量的，从交付周期上看能否抽取共性能力，加快迭代速度。从产品质量上看，提升关键性能指标。\n\n最后，你对这个问题怎么看？欢迎评论留言，我们将选出一条优质评论送出精美周边一份。
云加社区约 2 分钟根本不存在
年底绩效考核，有这样一个场景：
程序员小张和小王在同一个项目上开发，遇到了同样的问题需要去解决。
小张自己写了一个 1000 行代码的轮子，完美地解决了问题。代码写得好，测试也充分，部署和操作都有很好的文档记录。
小王去码头待了半天，在喂鸽子薯条的时候思考问题。然后他回到办公室，删除了100行代码，部署了更改——问题也解决了。
那么问题来了，这两位程序员，谁今天的工作是更“高效”的？
问题引申得更广泛一点：
如果1000行代码和10行代码都能解决同一个问题，哪个版本的代码应该得到更好的绩效？
如果奖励开发人员编写额外代码，是否会导致软件变得更为臃肿，难以维护、变更？
如果鼓励开发人员用最短行数代码，是否会导致协作人员难以理解代码含义，增加沟通成本？
所以，Martin Fowler才会在十年前就做下定论——软件开发的生产力无法有效地衡量，换言之：
所谓的软件生产力根本不存在？
优秀的软件开发人员所做的是解决问题。实际上，这与生产刚好相反。创建技术工件，如代码、文档、数据等……都是实现消除问题目标的必要操作。
然而很多时候，解决问题的最有效方案可能只是一次5分钟的对话。
但对于程序员而言，OKR的存在又是必要的，一方面方便指导工作方向，另一方面也总是需要被评估一年的工作产出。但怎么写好OKR去量化可能并不存在的软件生产力似乎又是个悖论，或许可以这样拆解一下？
业务部门的研发团队是支撑团队，业务目标是第一性的。而评判研发活干得怎么样，通常指的是他的效能和质量。
完成需求是第一位的，体现研发团队的价值；
牛逼地完成是必要的，体现开发个人的价值。
牛逼 = 高效能 + 高质量 + 可持续！
效能就是快，包括：需求交付快；低运营，免运营；后续迭代快。
质量就是好，包括：用户体验好；无资金、数据等安全问题；无现网故障；故障时低 MTTR 等。
可持续就是前二者必须是持续性的，一次的好坏可能都是运气。
目标还应该是可度量的，从交付周期上看能否抽取共性能力，加快迭代速度。从产品质量上看，提升关键性能指标。
最后，你对这个问题怎么看？欢迎评论留言，我们将选出一条优质评论送出精美周边一份。
言简意赅聊技术 , 6