拿什么来衡量工程师的生产力?

引用

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

所以现在你知道了吧,原来我们并没有办法来衡量 老实说,我们现在还没有明确的方法可以衡量程序员以及整个团队的生产力。我们可以确定谁可以依赖,谁比较努力,但却无法证明这些猜想,也没有量化的方法。 我们的代码写得多,所以我们的生产力更高 既然开发人员的工作就是写代码。那么,何不通过衡量代码的多少来衡量其生产力呢——看看他们写了多少行代码? 但是,不同编程语言之间的代码行数是没办法比较的,即使使用的是相同的编程语言,在不同的框架下的程序员之间的生产效率,光看代码写了多少也是无从裁定的。 更根本的问题是,通过衡量所写的代码行数来断定生产力其实没有意义的。很多软件开发中的最重要部分还包含思考和学习——不仅仅是写代码。 最优秀的程序员会将大量的时间用于了解和解决疑难杂症,或帮助他人解决难题,而不是写代码。他们会想方设法简化代码,避免重复。他们会通过实验、建立原型等方式迭代代码,替换原先旧的代码,以获得最佳的解决方案。 所以,光从代码数量上看,还真看不出程序员的生产力水平来。 我们钱赚得多,所以我们的生产力更高 我们也可以通过财务上面的盈利能力来衡量每个团队的产出,或者其他的业务措施,如有多少用户正在使用系统——如果开发人员能为企业赚更多的钱(或节省更多的钱),那么是不是他们的生产力更高呢? 利用财政措施似乎在执行层面上是一个不错的主意,但是却有太多的商业因素是不受开发团队控制的。有些开发团队很垃圾,但他们的产品就是成功了;而有些团队兢兢业业却还是只收获了失败的果实。注重节约成本的理念很有可能会导致许多管理者裁人,企图“少花钱多办事”,而不是投资于真正的生产力提高。 看来此路不通,我们需要寻找其他更有有意义的生产力指标。 我们的开发速度快,所以我们的生产力更高 衡量开发速度——敏捷速度——看起来更像是另一种从团队层面来衡量生产力的方式。毕竟,软件开发的重点是提供可工作的软件。如果你的团队能更快地拿出产品,自然是更好。 但是,速度(一个团队在一段时间内能完成的工作)与其说是衡量生产力的,还不如更精确点说,是用来衡量预见性的:用来衡量一个团队能承受多少的工作。 但是,我们又不得不考虑人员加入或离开等对速度的影响因素。而且,有一点你得清楚,速度只能只能用于衡量已知团队——由于很多因素的不同,速度并不能用于不同团队之间的比较。 保持忙碌的状态就对了 一个我认识的经理曾这样说道,与其试图衡量生产力,还不如

引用

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

在这种情况下,我们会衡量——并优化——循环时间。 团队可以使用看板去监控——并限制——正在进行的工作,并确定瓶颈,使用价值流图可以了解需要优化的步骤、排序、延误和信息流。总之一切为了尽快地交货和发布。 但是我们还是不能将交货速度等同于生产力。这是因为只优化交付本身的循环时间/速度很有可能会导致更大的长期性问题,要知道这种方式实质上是在鼓励人们只顾眼前,从而偷工减料,背负技术债务。 我们的软件更好,所以我们的生产力更高 众所周知,软件中出现bug和错误会导致成本显著提高:不仅开发返工成本高了,维护和支持的成本也高了。而最最重要的是,差的软件可能会造成客户的流失,甚至是生意的失败。 要想衡量你正在写的软件是好是坏也很容易:缺陷密度、缺陷逃逸率,以及利用SonarQube之类的工具对代码库进行静态分析。 我们知道如何编写好的软件。但是软件质量是否真的足以定义生产力? 开发人员——衡量和改进IT性能 开发团队试着综合上述一些因素来衡量生产力:交付速度和质量。 但开发人员并不限于创建和提供代码——相反还需要着眼于为端到端提供IT服务的性能指标:交付吞吐量和服务质量。 所以这不只是软件更快、更好的问题,而是需要提供更好更快的服务,在速度和功能之间选择平衡,衡量并提高生产效率和质量。 还有一点,最近有研究表明,企业要想成功:不仅生产力要提高,更重要的是要提高市场份额和盈利能力。 衡量成效,而不是产量 不要再试图去衡量单个开发人员的生产力了。 这纯粹是在浪费时间。 每个人心中都有一杆秤。 对于表现优秀的——鼓励他们继续朝着正确的方向前进,再接再厉。对于那些努力上进的——给予他们帮助。对于那些不适合的——可以请出去了。 衡量和提高团队或组织级别的生产力将会让你收获更加有意义的回报。 所以当涉及到生产力时: 1.衡量关键因素——能对团队和组织起重要作用的因素。 2.设置的指标应该是起积极作用的——可以推动学习和改进,而不是造成团队或个人之间关于产量的恶性竞争。

原文发布于微信公众号 - 我是攻城师(woshigcs)

原文发表时间:2015-02-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

外贸SEO该如何利用Google优化工具选择谷歌优化关键词

外贸网站在做外贸seo优化的时候,优化关键词的选择是非常重要的,googlel优化关键词选好了,网站就容易获得很好的流量和排名;反之,如果最初就选择了错误的关键...

3238
来自专栏CSDN技术头条

推荐系统正成为所有领域的一种标配

近段时间团队在扩建算法小组,首当其冲的岗位就是推荐算法工程师,然而历经一、两个月的招聘后,却发现一个事实,推荐算法工程师太难招了。

1023
来自专栏JAVA高级架构

如何成为一个Java高薪架构师?

什么是架构,什么是架构师?这似乎是聊架构话题时永恒的问题。 从内心讲我真的不想回答架构具体需要做什么,架构师应该具体负责什么。因为从实际情况看,在不同的系统层级...

3548
来自专栏腾讯大讲堂的专栏

产品经理探索之路:如何理清思路确定方向?

导语 在设计和运营产品的过程中,产品经理们或多或少会遇到这样的问题:产品方向不明确,对未来也毫无头绪,不知道要如何走。针对这个问题,我们简单谈谈如何破局,更快的...

20810
来自专栏软件成本造价评估

软件成本度量体系建设应用案例分析

  随着该行组织级量化管理的不断提升,高层领导对信息化管理提出了新的要求,金融信息化每年投入了大量的人力,如何能客观地量化相应的产出?

1842
来自专栏云计算D1net

云计算离超级云计算还有多远?

单就一个行业而言,一直以来我们对于云计算所带来好处的认识可能显得过于狭窄了。如果云计算是一次真正的革命性变革,那么它就必须能够支持生产和用户体验的模式,而这些都...

4676
来自专栏腾讯研究院的专栏

腾讯云平台部总经理陈磊:大数据背后的技术支撑

image.png 大数据似乎在一夜之间迅速走红,它势不可挡地冲击着金融、零售等各个行业。云计算将如何改变计算的世界?未来将有怎样的应用前景?如何解决“...

3277
来自专栏CDA数据分析师

【干货】小白学数据分析—留存率是什么?

在网站分析、电商分析、网游分析中,对于留存率的关注度极高,这一浪潮随着APP应用、社交游戏的火爆逐渐成为一个很重要的衡量准则,也甚至有了40-20-10准则。对...

2547
来自专栏ThoughtWorks

王健:技术雷达之微服务架构

作为一家服务于全球不同类型客户的IT专业服务公司,ThoughtWorks一直追求最卓越的技术,并用它们来解决客户实际的问题。而为了体现技术卓越,Thought...

3317
来自专栏数据的力量

【干货】如何做一个好的数据产品经理?

2314

扫码关注云+社区

领取腾讯云代金券