InfoQ

新闻

给敏捷团队发奖金就像在刀尖上跳舞

作者 Vikas Hazrati译者 李剑 发布于 2008年3月26日 下午4时2分

社区
Agile
主题
人力资源,
领导能力,
职业生涯
标签
管理,
报酬与激励
Sam Bayer在精益开发组中发起了一个很有意思的讨论,参与者们都在试图找到发奖金的最佳方式。

Mary Poppendieck认为,既然软件开发是团队活动,那么发奖就不应该针对个人,而是要根据团队的绩效。Robin Dymond的观点跟他有些类似,他说,正确的算法应该是50%根据团队绩效,50%根据个人绩效。但这里就有地方可能出现问题,因为它会去检查敏捷团队中个人的绩效。他补充说:
另一个关键问题是,团队怎样自己推选出他们的领军人物来,比如一步一步给所有人都进行测试和QA工具培训的QA,或者严守自动化流程纪律,经常改进整体生产力的开发人员。
Adrian Howard认为,通过个人绩效评估发奖金往往都会影响生产力,我们应该避免这种做法。它会成为团队内部冲突的主要因素,让一个运作良好的团队很快分崩离析。按照他的观点来看,一旦按照个人绩效来发奖金,那人们就会把个人目标凌驾于团队目标之上。

那到底怎样发奖金才最合适?

Matt Swaffer认为,
有两种方式,第一种是每个人得到X%的工资作为奖金,另一种是整个团队得到$X平均分配。
不过很多人都对这种方案表示不满。有些人认为,把奖金平均分配就是明显的吃大锅饭,这对多干活的人是不公平的,会让他们情绪低落,效率降低;这种做法代价太大。而另一种做法也欠妥,按百分比来算,只会让工资越多的人拿得奖金也越多。假设A的工资是100K,B是50K,奖金是5%,那就是A拿5K,B拿2.5K。

另一种比较新颖的想法就是让团队决定怎么分配奖金。Mary对此持有很强硬的反驳意见。她提到:
Mike Cohn说到过这样一种情景,团队拿到了一笔很大的奖金,被告知他们自行分配。他们会想办法让大家的意见达成一致,但是这个过程会在团队内部造成巨大的难以修复的裂痕。最后他们能够做到的就是平均分配,尽管很多人会认为它不公平。让他们自行分配导致的冲突,会让大多数人觉得还不如一开始没有这笔钱呢。
到现在为止讨论组内好像还没有得出最好的分配方案。在某些团队内可以生效的方案,也许放到其他团队中就会造成混乱。但是,貌似大多数人都赞同这一点:给敏捷团队发奖金就如同在刀尖上跳舞。

查看英文原文Distributing Bonus to Agile Teams is Like Playing with Dynamite

相关赞助商

InfoQ中文站敏捷社区,关注敏捷软件开发和项目管理,通过新闻、深度文章、视频访谈和演讲以及迷你书等为中国技术社区提供一流资讯。

8 条回复

回复

平常那么多measurement都不顶用吗? 发表人 Xiaogang Guo 发表于 2008年3月26日 下午4时12分
Re: 平常那么多measurement都不顶用吗? 发表人 Ken Wu 发表于 2008年3月26日 下午8时12分
关于钱的问题总是敏感问题 发表人 cao yunfei 发表于 2008年3月26日 下午7时58分
Re: 关于钱的问题总是敏感问题 发表人 Sha Jiang 发表于 2008年3月26日 下午9时8分
Re: 关于钱的问题总是敏感问题 发表人 上 里巴人 发表于 2008年3月28日 上午1时26分
奖金的敏捷发放方式 发表人 超 陆 发表于 2008年3月27日 上午5时5分
Re: 奖金的敏捷发放方式 发表人 Xiaogang Guo 发表于 2008年3月27日 上午6时27分
Re: 奖金的敏捷发放方式 发表人 凉粉 小刀 发表于 2008年3月27日 上午6时38分
  1. 返回顶部

    平常那么多measurement都不顶用吗?

    2008年3月26日 下午4时12分 发表人 Xiaogang Guo

    1、给“指标”发奖金应该比给人发奖金强吧(当然怎么选择指标也是一个问题)。 2、老手的价值应该在工资上体现出来,奖金我觉得应该偏向新人一点。 3、如果完全黑箱作业,会不会反而好一点?

  2. 返回顶部

    关于钱的问题总是敏感问题

    2008年3月26日 下午7时58分 发表人 cao yunfei

    其实奖金和工资一样,是工作带来的收入。既然目前的公司中工资都是不透明的,那么奖金也可以不透明。没有人会有意见。一旦奖金公开了,其后果与工资公开是一样的。这样看的话,奖金的分配根本就不应该公开,除非这个公司的工资是公开的。

  3. 返回顶部

    Re: 平常那么多measurement都不顶用吗?

    2008年3月26日 下午8时12分 发表人 Ken Wu

    小团队发奖金应该适当透明。 大团队黑箱操作,是必然的。

  4. 返回顶部

    Re: 关于钱的问题总是敏感问题

    2008年3月26日 下午9时8分 发表人 Sha Jiang

    不患寡,患不均(公平、合理)。但要达到"均",何其难也。

  5. 返回顶部

    奖金的敏捷发放方式

    2008年3月27日 上午5时5分 发表人 超 陆

    1,写测试: Assert(solution.NobodyIsUnhappy());
    2,写代码通过测试.
    
    3,如果发现永远无法通过测试,修改测试: Assert(solution.HappyPeople.Count > solution.UnhappyPeople.Count);
    4,写代码通过测试.
    
    5,如果发现永远无法通过测试,修改测试: Assert(solution.HappyPeople.Count > 0);
    6,写代码通过测试.
    

  6. 返回顶部

    Re: 奖金的敏捷发放方式

    2008年3月27日 上午6时27分 发表人 Xiaogang Guo

    负面情绪是会扩散的,有一个人不爽,受影响的可不止一个人。 所以你那后两种方案都是很危险的。

  7. 返回顶部

    Re: 奖金的敏捷发放方式

    2008年3月27日 上午6时38分 发表人 凉粉 小刀

    同意

  8. 返回顶部

    Re: 关于钱的问题总是敏感问题

    2008年3月28日 上午1时26分 发表人 上 里巴人

    在发奖金的时候千万不要忘了发奖金的目的,如果因为发奖金而搞的众说纷纭,而且团队崩溃,那就很不爽了。如果真是为了提高士气,建议可以参考一下有些团队使用的象征性奖励法,小学生用的那个大红花有时就挺有用的:)但同时也建议团队让成员的薪水能够高到奖金多少对他们都没有太多意义的程度,这种情况下精神奖励才更加凑效。

独家内容

Hadoop中的集群配置和使用技巧

本文介绍了Hadoop如何配置分布式框架运行环境,同时特别讲解了其中的一些细节。Hadoop可以单机跑,也可以配置集群跑,这里主要重点说一下集群配置运行的过程。本文是Hadoop入门实践三部曲的第二部。

JavaScript多线程编程简介

虽然有越来越多的网站在采用AJAX技术,但是开发复杂的AJAX应用仍然是个难题。本文探索了如何应用多线程缓解其中一些问题。

Ruby的开放类──或者:怎样避免动态打补丁

Ruby的开放类(Open Classes)功能强大,但很容易被误用。这篇文章关注于怎样减少使用开放类的风险,介绍了一些其他可替代的类似方法,并分析了其他语言如何实现类似的功能。

REST反模式

在本文中,Stefan Tilkov讲解了一些经常出现在自称“符合REST式设计”的应用中的反模式(比如:全部采用GET或POST,忽视缓存及响应代码,误用cookies,忘记超媒体与MIME类型,以及破坏自描述性等),并给出了避免这些反模式的对策。

分布式计算开源框架Hadoop介绍

Hadoop是Apache开源组织的一个分布式计算开源框架,在很多大型网站上都已经得到了应用,如亚马逊、Facebook和Yahoo等等。本文是Hadoop入门实践三部曲的第一部,主要讲述了What和Why的问题。

37 Signals的实用最小主义实践

本文结合37 Signals公司在开发Basecamp等产品时的实践,介绍了实用最小主义开发方法。实践证明,尤其是在开发Web应用时,这一方法非常有效。根据作者的观察,Google现在之所以那么成功,其所遵循的软件开发哲学和最小实用主义非常类似。

与林昊一起探讨OSGi

在今年5月份的网侠大会上,InfoQ中文站有幸与国内OSGi的先锋林昊(BlueDavy)在一起探讨了OSGi的相关话题,包括它的优势、复杂度以及Java下的实现等等。

超越F#基础——异步工作流

Robert Pickering在F#的第三篇文章中,他继续着上次的话题,不过这次他要关注的是异步工作流(Asynchronous Workflows),以及在使用这个特性后获得的性能改善。虽然这篇文章是关于F#的,但是这样的知识对于所有的.NET语言都是适用的。