InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

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

作者 Vikas Hazrati 译者 李剑 发布于 2008年3月26日

领域
架构 & 设计,
企业架构,
过程 & 实践
主题
领导能力 ,
人力资源 ,
敏捷 ,
职业生涯
标签
管理 ,
报酬与激励
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

译者 李剑 李剑──ThoughtWorks高级咨询师,在持续集成、重构等领域具有丰富的经验;多次为国内大型企业敏捷组织转型提供咨询和培训服务。

平常那么多measurement都不顶用吗? 发表人 Guo Xiaogang 发表于
Re: 平常那么多measurement都不顶用吗? 发表人 Wu Ken 发表于
关于钱的问题总是敏感问题 发表人 曹 云飞 发表于
Re: 关于钱的问题总是敏感问题 发表人 Jiang Sha 发表于
Re: 关于钱的问题总是敏感问题 发表人 里巴人 上 发表于
Re: 关于钱的问题总是敏感问题 发表人 zhang allen 发表于
奖金的敏捷发放方式 发表人 陆 超 发表于
Re: 奖金的敏捷发放方式 发表人 Guo Xiaogang 发表于
Re: 奖金的敏捷发放方式 发表人 小刀 凉粉 发表于
  1. 返回顶部

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

    发表人 Guo Xiaogang

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

  2. 返回顶部

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

    发表人 曹 云飞

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

  3. 返回顶部

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

    发表人 Wu Ken

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

  4. 返回顶部

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

    发表人 Jiang Sha

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

  5. 返回顶部

    奖金的敏捷发放方式

    发表人 陆 超


    1,写测试: Assert(solution.NobodyIsUnhappy());
    2,写代码通过测试.

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

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

  6. 返回顶部

    Re: 奖金的敏捷发放方式

    发表人 Guo Xiaogang

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

  7. 返回顶部

    Re: 奖金的敏捷发放方式

    发表人 小刀 凉粉

    同意

  8. 返回顶部

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

    发表人 里巴人 上

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

  9. 返回顶部

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

    发表人 zhang allen

    牵扯到个人利益就是不好办啊。

深度内容

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

解析JDK 7的动态类型语言支持

随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。

Java Remoting远程服务(下)

随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。