你都不知道自己有多强,衡量程序员生产力的标准是什么?

简介: 如果你用谷歌搜索“mearsuring software developer productivity”,那么你会发现出来的全都是一些废话,一点用处都没有的废话。——Nick Hodges,《Measuring Developer Productivity》 所以现在你知道了吧,原来我们并没有办法来衡量程序员的工作效率。

如果你用谷歌搜索“mearsuring software developer productivity”,那么你会发现出来的全都是一些废话,一点用处都没有的废话。——Nick Hodges,《Measuring Developer Productivity》

所以现在你知道了吧,原来我们并没有办法来衡量程序员的工作效率。

老实说,我们现在还没有明确的方法可以衡量程序员以及整个团队的生产力。我们可以确定谁可以依赖,谁比较努力,但却无法证明这些猜想,也没有量化的方法。
你都不知道自己有多强,衡量程序员生产力的标准是什么?

我们的代码写得多,所以我们的生产力更高

既然开发人员的工作就是写代码。那么,何不通过衡量代码的多少来衡量其生产力呢——看看他们写了多少行代码?

但是,不同编程语言之间的代码行数是没办法比较的,即使使用的是相同的编程语言,在不同的框架下的程序员之间的生产效率,光看代码写了多少也是无从裁定的。

更根本的问题是,通过衡量所写的代码行数来断定生产力其实没有意义的。很多软件开发中的最重要部分还包含思考和学习——不仅仅是写代码。

最优秀的程序员会将大量的时间用于了解和解决疑难杂症,或帮助他人解决难题,而不是写代码。他们会想方设法简化代码,避免重复。他们会通过实验、建立原型等方式迭代代码,替换原先旧的代码,以获得最佳的解决方案。

所以,光从代码数量上看,还真看不出程序员的生产力水平来。
你都不知道自己有多强,衡量程序员生产力的标准是什么?

我们钱赚得多,所以我们的生产力更高

我们也可以通过财务上面的盈利能力来衡量每个团队的产出,或者其他的业务措施,如有多少用户正在使用系统——如果开发人员能为企业赚更多的钱(或节省更多的钱),那么是不是他们的生产力更高呢?

利用财政措施似乎在执行层面上是一个不错的主意,但是却有太多的商业因素是不受开发团队控制的。有些开发团队很垃圾,但他们的产品就是成功了;而有些团队兢兢业业却还是只收获了失败的果实。注重节约成本的理念很有可能会导致许多管理者裁人,企图“少花钱多办事”,而不是投资于真正的生产力提高。

看来此路不通,我们需要寻找其他更有有意义的生产力指标。
你都不知道自己有多强,衡量程序员生产力的标准是什么?

我们的开发速度快,所以我们的生产力更高

衡量开发速度——敏捷速度——看起来更像是另一种从团队层面来衡量生产力的方式。毕竟,软件开发的重点是提供可工作的软件。如果你的团队能更快地拿出产品,自然是更好。

但是,速度(一个团队在一段时间内能完成的工作)与其说是衡量生产力的,还不如更精确点说,是用来衡量预见性的:用来衡量一个团队能承受多少的工作。

但是,我们又不得不考虑人员加入或离开等对速度的影响因素。而且,有一点你得清楚,速度只能只能用于衡量已知团队——由于很多因素的不同,速度并不能用于不同团队之间的比较。
你都不知道自己有多强,衡量程序员生产力的标准是什么?

保持忙碌的状态就对了

一个我认识的经理曾这样说道,与其试图衡量生产力,还不如

“保持忙碌的状态就对了。只要我们不断地挖掘问题,就一定可以找到瓶颈,解决掉这些难题。”

在这种情况下,我们会衡量——并优化——循环时间。

团队可以使用看板去监控——并限制——正在进行的工作,并确定瓶颈,使用价值流图可以了解需要优化的步骤、排序、延误和信息流。总之一切为了尽快地交货和发布。

但是我们还是不能将交货速度等同于生产力。这是因为只优化交付本身的循环时间/速度很有可能会导致更大的长期性问题,要知道这种方式实质上是在鼓励人们只顾眼前,从而偷工减料,背负技术债务。
你都不知道自己有多强,衡量程序员生产力的标准是什么?

我们的软件更好,所以我们的生产力更高

众所周知,软件中出现bug和错误会导致成本显著提高:不仅开发返工成本高了,维护和支持的成本也高了。而最最重要的是,差的软件可能会造成客户的流失,甚至是生意的失败。

要想衡量你正在写的软件是好是坏也很容易:缺陷密度、缺陷逃逸率,以及利用SonarQube之类的工具对代码库进行静态分析。

我们知道如何编写好的软件。但是软件质量是否真的足以定义生产力?
你都不知道自己有多强,衡量程序员生产力的标准是什么?

开发人员——衡量和改进 IT 性能

开发团队试着综合上述一些因素来衡量生产力:交付速度和质量。

但开发人员并不限于创建和提供代码——相反还需要着眼于为端到端提供IT服务的性能指标:交付吞吐量和服务质量。

所以这不只是软件更快、更好的问题,而是需要提供更好更快的服务,在速度和功能之间选择平衡,衡量并提高生产效率和质量。

还有一点,最近有研究表明,企业要想成功:不仅生产力要提高,更重要的是要提高市场份额和盈利能力。

衡量成效,而不是产量

不要再试图去衡量单个开发人员的生产力了。

这纯粹是在浪费时间。

每个人心中都有一杆秤。对于表现优秀的——鼓励他们继续朝着正确的方向前进,再接再厉。对于那些努力上进的——给予他们帮助。对于那些不适合的——可以请出去了。

衡量和提高团队或组织级别的生产力将会让你收获更加有意义的回报。

所以当涉及到生产力时:

1.衡量关键因素——能对团队和组织起重要作用的因素。

2.设置的指标应该是起积极作用的——可以推动学习和改进,而不是造成团队或个人之间关于产量的恶性竞争。

相关文章
|
2月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
架构师 开发者 运维
开发人员各级岗位胜任力模型
上个月,我写了一篇《架构设计师能力模型》,为开发者指出一些发展的方向、架构师的能力要求,以及需要学习的相关知识。 本月,我为公司的人力部门编制了更加量化的《2017年研发人员岗位能力模型 V1.4》。
9997 0
|
3月前
|
测试技术 持续交付 UED
软件测试的艺术与科学:平衡创新与质量的探索在软件开发的波澜壮阔中,软件测试如同灯塔,指引着产品质量的方向。本文旨在深入探讨软件测试的核心价值,通过分析其在现代软件工程中的应用,揭示其背后的艺术性与科学性,并探讨如何在追求技术创新的同时确保产品的高质量标准。
软件测试不仅仅是技术活动,它融合了创造力和方法论,是软件开发过程中不可或缺的一环。本文首先概述了软件测试的重要性及其在项目生命周期中的角色,随后详细讨论了测试用例设计的创新方法、自动化测试的策略与挑战,以及如何通过持续集成/持续部署(CI/CD)流程优化产品质量。最后,文章强调了团队间沟通在确保测试有效性中的关键作用,并通过案例分析展示了这些原则在实践中的应用。
88 1
|
3月前
|
测试技术 UED 开发者
软件测试的艺术:从代码审查到用户反馈的全景探索在软件开发的宇宙中,测试是那颗确保星系正常运转的暗物质。它或许不总是站在聚光灯下,但无疑是支撑整个系统稳定性与可靠性的基石。《软件测试的艺术:从代码审查到用户反馈的全景探索》一文,旨在揭开软件测试这一神秘面纱,通过深入浅出的方式,引领读者穿梭于测试的各个环节,从细微处着眼,至宏观视角俯瞰,全方位解析如何打造无懈可击的软件产品。
本文以“软件测试的艺术”为核心,创新性地将技术深度与通俗易懂的语言风格相结合,绘制了一幅从代码审查到用户反馈全过程的测试蓝图。不同于常规摘要的枯燥概述,这里更像是一段旅程的预告片,承诺带领读者经历一场从微观世界到宏观视野的探索之旅,揭示每一个测试环节背后的哲学与实践智慧,让即便是非专业人士也能领略到软件测试的魅力所在,并从中获取实用的启示。
|
7月前
|
搜索推荐 程序员 测试技术
研究思考|关于软件复杂度的困局
本文重点围绕软件复杂度进行剖析,希望能够帮助读者对软件复杂度成因和度量方式有所了解。
|
搜索推荐 程序员 测试技术
研究思考丨关于软件复杂度的困局
研究思考丨关于软件复杂度的困局
1306 9
研究思考丨关于软件复杂度的困局
|
Web App开发
《伟大的小细节:互联网产品设计中的微创新思维》——2.3 预期操作权衡
本节书摘来自华章计算机《伟大的小细节:互联网产品设计中的微创新思维》一书中的第2章,第2.3节,作者:文哲著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1234 0
|
测试技术 程序员
《程序员度量:改善软件团队的分析学》一数据选择
本节书摘来华章计算机《程序员度量:改善软件团队的分析学》一书中的第2章 ,Jonathan Alexander 著 张燎原 周峰 张刚 宋励奋 译更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1260 0