大家来谈谈在敏捷中个人绩效考评的正面和负面实践
克强
利为目的的自组织团队（非盈利的团队也许好一些）。因此希通过本贴来看看这方面的实践，避免犯典型的错误。
我所知甚少，抛砖先。
负面实践：
1,项目经理对团队成员进行考评，项目经理同时担当如Scrum Master或Coach之类的角色
2,全部公开团队成员的收入或与收入直接关联的等级
正面实践：
1, 个人每季度公开设立MBO（management by objectives），每季度公开自评，听取同伴意见，年度进行360度考评，本人
自评，并请三位（上级，平级，下级）同事来写评语，然后people manager层面进行汇总，分级和排名。
对于平衡记分卡和KPI的个人绩效评估在敏捷中的应用不是太清楚，理论上分析可能存在冲突，不知实践中如何？
有没有朋友可以提供例子？
valpa
Daniel Teng
Performance Reviews/Job Descriptions in an Agile Environment
http://groups.yahoo.com/group/scrumdevelopment/message/38765?var=1&l=1
Measuring Perfomance on SCRUM
http://groups.yahoo.com/group/scrumdevelopment/message/38706;_ylc=X3oDMTJybXE1YTdoBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA3MjA5MDIxBG1zZ0lkAzM4NzA2BHNlYwNkbXNnBHNsawN2bXNnBHN0aW1lAzEyNDMyOTg5NDE-
On 6月2日, 上午6时06分, 克强 <zhangkeqi...@gmail.com> wrote:
mingo
晋升、提薪等参考，并不能完整的反映真实业绩。
不管是用敏捷，还是CMMI，还是别的啥啥啥，绩效考评都要提炼出反映工作业绩的KPI，比如开发人员可以用BUG数，测试人员用客户发现BUG与自己
发现的BUG之比值，项目经理就用进度、成本等，这样指标都是大家都能看得见的实际数字，这样的绩效考评才是最有说服力的。
On 6月2日, 上午6时06分, 克强 <zhangkeqi...@gmail.com> wrote:
Liang Qiao
胡凯
--
Twitter: http://twitter.com/iamhukai
Blog: http://iamhukai.blogspot.com/
Jeff Xiong
另一方面我认为360度考评实际上是一个客观性很强的活动。第一，有效的360度考评需要对员工进行相关的教育，尽力让feedback具客观性。第二，更重要的是，即便是主观性很强的个人意见，放在统计层面上它就是客观的。说俗点，如果一整个团队都认为你一个人有毛病，那么你就应该离开这个团队，不论事实究竟是你有毛病还是整个团队都有毛病。管理本身就是一个关于人的问题，管理中的客观性仍然是基于人的客观性。
2009/6/3 胡凯 <iamk...@gmail.com>:
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
mingo
On 6月3日, 上午7时32分, 胡凯 <iamka...@gmail.com> wrote:
> 用这样的标准看起来客观了但是对个人提高，团队提高没用，当你把代码的产出和绩效挂钩，我很难想像开发者可以有高的工作热情，不写code的人bug最少，是不是涨他工资？这样的标准明明是在鼓励不要努力工作。人的问题就是人的问题，没法用一套技术指标简单粗暴的解决。
>
> 2009/6/2 mingo <zhangweib...@gmail.com>
mingo
~~
如果按照你的说法，实施了敏捷开发的team，最好不要搞绩效考核，因为绩效考核就是本着"人性本懒"才有的。而敏捷开发则是更大程度的发挥个人主观能
动性，依靠个人素质~搞了绩效考核，就是对team的不信任......
我觉得，在任何团队，搞绩效考核凭单纯的技术指标不行，单纯的360度打分也不行，两者需要结合起来。
On 6月3日, 上午7时32分, 胡凯 <iamka...@gmail.com> wrote:
> 用这样的标准看起来客观了但是对个人提高，团队提高没用，当你把代码的产出和绩效挂钩，我很难想像开发者可以有高的工作热情，不写code的人bug最少，是不是涨他工资？这样的标准明明是在鼓励不要努力工作。人的问题就是人的问题，没法用一套技术指标简单粗暴的解决。
>
> 2009/6/2 mingo <zhangweib...@gmail.com>
George Lei
--
George Lei
Jeff Xiong
2009/6/3 mingo <zhangw...@gmail.com>:
--
George Lei
--
George Lei
My web2.0 name card: http://www.georgelei.net
Jeff Xiong
没链接没真相。引用一段大牛的明确阐述来看看吧。
2009/6/3 George Lei <george...@gmail.com>:
> 其实我觉得你对敏捷开发和绩效考评的关系的理解是对的。敏捷团队就是不要绩效考评，至少不要传统意义上的绩效考评。从scrum到XP，几乎所有的敏捷大牛都对这个问题有明确阐述。
>
> --
> George Lei
>
> My web2.0 name card: http://www.georgelei.net
>
>
>
valpa
On 6月3日, 上午9时05分, Jeff Xiong <gigix1...@gmail.com> wrote:
> 也不好简单粗暴的就说"没法"。我们可以看到一些现行的指标明显不再适用，但这也不是放弃寻找适用的指标的理由。其实关键在于一种持续改进的态度：只要发现旧的-指标没有帮助就敢于抛弃，只要发现新的指标有帮助就敢于尝试。和开发实践一样，绩效考核实践也是从摸索和改进中逐渐优化出来的，不是拿一个模板套出来的。360-度考核可以作为一个起点，原有的KPI也可以作为一个起点，最终是持续改进的过程决定你的终点。
>
> 另一方面我认为360度考评实际上是一个客观性很强的活动。第一，有效的360度考评需要对员工进行相关的教育，尽力让feedback具客观性。第二，更重要-的是，即便是主观性很强的个人意见，放在统计层面上它就是客观的。说俗点，如果一整个团队都认为你一个人有毛病，那么你就应该离开这个团队，不论事实究竟是你有-毛病还是整个团队都有毛病。管理本身就是一个关于人的问题，管理中的客观性仍然是基于人的客观性。
>
> 2009/6/3 胡凯 <iamka...@gmail.com>:
>
>
>
>
>
> > 用这样的标准看起来客观了但是对个人提高，团队提高没用，当你把代码的产出和绩效挂钩，我很难想像开发者可以有高的工作热情，不写code的人bug最少，是不-是涨他工资？这样的标准明明是在鼓励不要努力工作。人的问题就是人的问题，没法用一套技术指标简单粗暴的解决。
>
> > 2009/6/2 mingo <zhangweib...@gmail.com>
George Lei
尤其如果涉及对个人建立绩效考评的指标，就要把每个人的工作独立出来，这与敏捷的团队协作和代码共享的基本原则是冲突的，矛盾无可调和。
我能理解在现有公司体制下为实施敏捷而作的妥协。但这是一种倒退，对于敏捷团队和项目本身并无益处。
Ken Schwaber在他那本经典的《Scrum敏捷项目管理》专门有一个章节讨论这个话题。更早一些，Kent Beck等人写的那几本XP的小书也有类似的表达，只不过那时的表述还没有这么深入。
网上的证据也不难找，随手摘两条。
Individual velocity measurement has wrong focus on individual performance. The focus should be on team performance, individual performance is not important. If Jerry knows that his velocity is measuring, he maybe will not help other team members a lot. He will focus on his performance as an individual developer. The worst thing company can do is to bind bonuses to individual performance. This nips teams in the bud. The right solution is to measure team performance, but in agile development we already have team performance metric, it is a well-known iteration velocity - very good, very simple and very helpful metric that enough for iteration planning. Individual velocity will not bring additional benefits there.
http://www.targetprocess.com/blog/2007/12/should-you-measure-individual-velocity.html
For most teams, each person’s achievement is all commingled with the other members of the team. Trying to pull out individual performance is futile. Emphasizing or rating individual performance undermines collaboration. Individual skills are only a small part of the performance equation anyway. The quality of management, the environment and organization culture are major factors in individual performance. And most rating and ranking schemes ignore those factors.
http://runningagile.com/2008/05/11/death-by-appraisal/
--
George Lei
alsor zhou
但是，以上的说法是对于公司而言，可以根据各个团队的绩效分发不同的budget，但如何在团队内部进行小范围的评估，并且分蛋糕呢？谁来分？按照什么分？这个问题始终没有解决.
Jeff Xiong
我一直觉得，定论不要下得那么快。“可量化的最小单位是团队”，依据是什么？首先明白你想要达到的价值是什么，然后寻找一种成本收益合适的方式去做就是。下定论会束缚你的思路。
2009/6/3 alsor zhou <alsor...@gmail.com>:
> 在实施了敏捷的公司范围内，可量化的最小单位是团队，传统的以个人考评为中心的绩效体制应该转化为以团队为中心进行效率评估。评估的依据可以是过程和产出，实施过程评估可能会花费较大代价，但产出的质量以及时效评估应该是可以做到的。
--
欧阳丹
- 只考核团队：形式是客户，相关经理组成的客户评委会评审每个迭代会议的展示，依据预先和团队商量好的标准针对每个故事的承诺和实现给出评分
- 设定标准以惩罚： 达不到基本标准的团队会遭受惩罚，但现在基本上是一些调侃性质的惩罚，比如说 “下个迭代中午午饭必须在所有团队打完饭之后才能进餐厅”.... ，基本标准是偏客观的，是各项分值的加权计算
- 设定目标以奖励：达到预先设定目标导向的行为会得到额外的分数，评分结果关联一些偏荣誉话性质的奖励，比如说“免打扰金牌”，“迟到豁免权”（我们的迟到有给同事买饮料惩罚的） 目标奖励是偏主观的是评委和议后由评委会组长（通常的大boss）综合各方面意见拿出的鼓励导向。
- 奖励尽量到团队不到个人: 到团队，比如说1000块的腐败大礼包之类的奖励，或者一个工作日的团队休整集体活动（公司报账去欢乐谷游园一天）
- 有分数，就会有各个团队之间的比较，虽然在设计这个体系的时候我们期望大家能够自己纵向历史比较而少进行团队间的比较（避免由团队间的主观之间的，换句话说，每个团队都会觉得自己的问题有特殊性而感觉不公平），但是一旦推出过后大家无可避免的进行比较。
所以我们打算在第二次实施的时候，引导大家比较所有团队一样的标准部分的原始分，纵向比较自己团队的目标部分的历史分
- 分数出来了之后，对于依赖其他团队的故事没有完成遭到差评，可能存在埋怨的不和睦的情况
下次打算提供PO申述机制来保证评委评价的是团队的努力。 - 对于分数和奖励惩罚之间的关系期望明确：
设计的时候没有明确是想保留重奖或者重惩罚的权利，但是下次还是尝试把大部分分值对应奖励惩罚都明确了。
张伟.BroadText
有一个问题，是不是奖励没有奖金的形式？
--
Best regards
-----
张伟
公司：上海宽文是风软件有限公司
地址：上海市浦东新区东方路800号宝安大厦2802B室，邮编200122
电话：13512165346
Email：zhan...@broadtext.com.cn
Web： www.broadtext.com.cn
George Bernard Shaw - "A government that robs Peter to pay Paul can always depend on the support of Paul."
欧阳丹
alsor zhou
完成项目的实体应该是团队，这点没有异议？
呵呵，我同意你的部分观点，我自认为不是方法论者，所以也只是讲出我的个人感觉而已。
张克强
1, 收入，包括未来的收入，比如期权
2, 竞升，职位的提升，级别的提升，反过来就是降级和载员
目前看来，无论采用CMMI，Agile或其它任何东东，都无法避开上述的两个问题。
Agile大师们的阐述主要在于说明个人绩效定量指标存在较大问题，可没有说不要个人绩效考评。
在这次危机中有没有Agile团队载员的实例？可知为何载掉这个人，而不是另一个，谁主要作了决定？
On 6月3日, 下午12时32分, George Lei <george.z....@gmail.com> wrote:
> 为了避免不必要的争论，先澄清一下我上面表述的歧义。敏捷提倡对每个人的信任，以及团队成员的平等地位，所以不需要对每个人做绩效考评，因为这么做除了引起团队-成员的分歧，对于个人的激励没有太多的正面作用。但是可以把整个团队作为一个单位进行绩效考评。
>
> 尤其如果涉及对个人建立绩效考评的指标，就要把每个人的工作独立出来，这与敏捷的团队协作和代码共享的基本原则是冲突的，矛盾无可调和。
>
> 我能理解在现有公司体制下为实施敏捷而作的妥协。但这是一种倒退，对于敏捷团队和项目本身并无益处。
>
> Ken Schwaber在他那本经典的《Scrum敏捷项目管理》专门有一个章节讨论这个话题。更早一些，Kent
> Beck等人写的那几本XP的小书也有类似的表达，只不过那时的表述还没有这么深入。
>
> 网上的证据也不难找，随手摘两条。
>
> Individual velocity measurement has wrong focus on individual performance.
> The focus should be on team performance, individual performance is not
> important. If Jerry knows that his velocity is measuring, he maybe will not
> help other team members a lot. He will focus on his performance as an
> individual developer. The worst thing company can do is to bind bonuses to
> individual performance. This nips teams in the bud. The right solution is to
> measure team performance, but in agile development we already have team
> performance metric, it is a well-known iteration velocity - very good, very
> simple and very helpful metric that enough for iteration planning.
> Individual velocity will not bring additional benefits there.
>
> http://www.targetprocess.com/blog/2007/12/should-you-measure-individu...
>
> For most teams, each person's achievement is all commingled with the other
> members of the team. Trying to pull out individual performance is futile.
> Emphasizing or rating individual performance undermines collaboration.
> Individual skills are only a small part of the performance equation anyway.
> The quality of management, the environment and organization culture are
> major factors in individual performance. And most rating and ranking schemes
> ignore those factors.
>
> http://runningagile.com/2008/05/11/death-by-appraisal/
>
> --
> George Lei
>
> 2009/6/3 Jeff Xiong <gigix1...@gmail.com>
>
>
>
> > 一不小心又把我震惊了。
>
> > 没链接没真相。引用一段大牛的明确阐述来看看吧。
>
> > 2009/6/3 George Lei <george.z....@gmail.com>:
>
> > 其实我觉得你对敏捷开发和绩效考评的关系的理解是对的。敏捷团队就是不要绩效考评，至少不要传统意义上的绩效考评。从scrum到XP，几乎所有的敏捷大牛都对-这个问题有明确阐述。
>
> > > --
> > > George Lei
>
> > > My web2.0 name card:http://www.georgelei.net
>
> > --
> > Jeff Xiong
> > Software Journeyman -http://gigix.agilechina.net
> > Open Source Contributor -http://fluorida.googlecode.com/
> > Technical Evangelist -http://www.infoq.com/cn/- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Jeff Xiong
review只能也只应该作为一种参考。让专业技能在于软件开发和项目管理的人来考虑薪酬期权之类的事情，我认为是一件低效而浪费的蠢事。
2009/6/6 张克强 <zhangk...@gmail.com>:
> 对于营利组织中的个人利益，为简单计，划分两大类：
> 1, 收入，包括未来的收入，比如期权
> 2, 竞升，职位的提升，级别的提升，反过来就是降级和载员
> 目前看来，无论采用CMMI，Agile或其它任何东东，都无法避开上述的两个问题。
> Agile大师们的阐述主要在于说明个人绩效定量指标存在较大问题，可没有说不要个人绩效考评。
> 在这次危机中有没有Agile团队载员的实例？可知为何载掉这个人，而不是另一个，谁主要作了决定？
>
--
Jeff Xiong
Henry Xiao
2009/6/6 Jeff Xiong <gigi...@gmail.com>:
Daniel Teng
On 6月6日, 下午3时00分, Henry Xiao <henryx...@gmail.com> wrote:
> 同意，绩效考评只是绩效管理的一部分，HR专业人士研究很多。已经远远超出了我们开发团队管理的范围。
>
> 2009/6/6 Jeff Xiong <gigix1...@gmail.com>:
>
>
>
> > 我一向认为涉及薪酬晋升裁员一类的事情应该由HR和RM的专业人士们来考虑和讨论，团队的performance
> > review只能也只应该作为一种参考。让专业技能在于软件开发和项目管理的人来考虑薪酬期权之类的事情，我认为是一件低效而浪费的蠢事。
>
> > 2009/6/6 张克强 <zhangkeqi...@gmail.com>:
> >> 对于营利组织中的个人利益，为简单计，划分两大类：
> >> 1, 收入，包括未来的收入，比如期权
> >> 2, 竞升，职位的提升，级别的提升，反过来就是降级和载员
> >> 目前看来，无论采用CMMI，Agile或其它任何东东，都无法避开上述的两个问题。
> >> Agile大师们的阐述主要在于说明个人绩效定量指标存在较大问题，可没有说不要个人绩效考评。
> >> 在这次危机中有没有Agile团队载员的实例？可知为何载掉这个人，而不是另一个，谁主要作了决定？
>
> > --
> > Jeff Xiong
anders lin
张克强
中层以下会被要求提供方案所需的定量评价或定性评价。比如接到上级要求，给团队的每一个人打一个系数之类的。
某些原有的个人绩效考评方法与引入Agile还是存在冲突的。
虽然可能是“低效而浪费的蠢事”，但在项目经理层面、一线经理层面必须要处理的。
On 6月6日, 上午11时18分, Jeff Xiong <gigix1...@gmail.com> wrote:
> 我一向认为涉及薪酬晋升裁员一类的事情应该由HR和RM的专业人士们来考虑和讨论，团队的performance
> review只能也只应该作为一种参考。让专业技能在于软件开发和项目管理的人来考虑薪酬期权之类的事情，我认为是一件低效而浪费的蠢事。
>
> 2009/6/6 张克强 <zhangkeqi...@gmail.com>:
>
> > 对于营利组织中的个人利益，为简单计，划分两大类：
> > 1, 收入，包括未来的收入，比如期权
> > 2, 竞升，职位的提升，级别的提升，反过来就是降级和载员
> > 目前看来，无论采用CMMI，Agile或其它任何东东，都无法避开上述的两个问题。
> > Agile大师们的阐述主要在于说明个人绩效定量指标存在较大问题，可没有说不要个人绩效考评。
> > 在这次危机中有没有Agile团队载员的实例？可知为何载掉这个人，而不是另一个，谁主要作了决定？
>
> --
> Jeff Xiong
Henry Xiao
试想假如一个企业按代码行数跟客户结算，那我们考核维度之一很可能就是开发者写了多少行代码。
个人觉得如果真说敏捷影响考核，那可能是加强了团队内合作，从而同事之间更能坦承互评，而传统的更多是直接上级评。
--
Henry Xiao
-------------------------------------------------------------------------
Statement of Confidentiality: This message and any attachments are
intended only for the use of the intended recipient(s), are
confidential and may be privileged. If you are not the intended
recipient, you are hereby notified that any review, transmission,
conversion to hard copy, circulation or other use of this message and
any attachments is strictly prohibited. If you are not the intended
recipient, please notify the sender immediately by return e-mail, and
delete this message and any attachments from your system. Thank you.
Yiding He
在敏捷的方法论中一般都不谈个人绩效考评，但是在实践中这是不得不做的，而且对个人影响巨大，一个不公平合理的个人绩效考评足以毁掉任何一个成熟的以营
利为目的的自组织团队（非盈利的团队也许好一些）。因此希通过本贴来看看这方面的实践，避免犯典型的错误。
我所知甚少，抛砖先。
负面实践：
1,项目经理对团队成员进行考评，项目经理同时担当如Scrum Master或Coach之类的角色
2,全部公开团队成员的收入或与收入直接关联的等级
正面实践：
1, 个人每季度公开设立MBO（management by objectives），每季度公开自评，听取同伴意见，年度进行360度考评，本人
自评，并请三位（上级，平级，下级）同事来写评语，然后people manager层面进行汇总，分级和排名。
对于平衡记分卡和KPI的个人绩效评估在敏捷中的应用不是太清楚，理论上分析可能存在冲突，不知实践中如何？
有没有朋友可以提供例子？
Xu Yi
考评不能以个人为对象。以个人为对象的考评存在两大缺陷：1、繁琐的度量手段造成了对开发工作的扰乱，降低了开发效率和质量；2、扼杀了团队形成的可能性。
ls能否解答我的两个疑问：
- 不以个人为对象，那么应该以啥为对象？
- 不管你以啥为对象，它会不会最终落实到个人头上？
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
Yiding He
Xu Yi
考评应该以团队为单位，换句话说，项目做得好，大家都有功。首先，项目不是一个人做的，而是一个团队做的。这点无需说明。其次，团队是一个复杂的关系体，是多个个体的融合，而不是他们简单的组合。团队的效率不是简单的个人效率的相加。这一点非常重要，它决定了任何考评方式都无法看出一个人在团队中的作用有多大。举个例子，有的人事情做得不多，但是有他/她在的时候，团队效率就特别高。这种人不但该留，而且是极其难得的。什么叫管理？对很多人来说，管理就是两部分：1）考核；2）奖惩。可惜这种方式在软件项目中行不通。为什么？归根结底原因在于：编程是一项脑力劳动，而且是创造性的脑力劳动。用那些管理体力劳动的方式来管理项目，只会适得其反。
Yiding同学，我会用偏质问的方式和你讨论，如果你觉得反感那就直接不用理我就可以了。
如果说“项目做得好，大家都有功”，那么
- 我做好做坏有什么区别？
- 项目做得不好，谁造成的？或者说我们在意否是谁造成的
“项目是一个团队做的”，没错，那么
- 如果项目包含好多个团队呢？
没错，“团队的效率不是简单的个人效率相加”，但既然你提议以团队为单位考评，那么
- 团队的考评模型应该考虑哪些因素呢？
- 究竟要不要考虑个人效率的因素呢？
- “有他/她在的时候团队效率就特别高”，那么把这个考虑到考评模型中去如何呢？
如果只是“考核”和“奖惩”，你讲的是绩效管理吧，管理可远不止这么一点点工作哦。
Yiding He
- 我做好做坏有什么区别？
- 项目做得不好，谁造成的？或者说我们在意否是谁造成的
项目管理是实时跟进的。如果项目进行的不顺利，应该马上召集成员讨论！
“项目是一个团队做的”，没错，那么
- 如果项目包含好多个团队呢？
没错，“团队的效率不是简单的个人效率相加”，
- 团队的考评模型应该考虑哪些因素呢？
参考我们 group 之前讨论过的话题吧。原则是凡是受到团队抵制的考评手段一律去掉。
- 究竟要不要考虑个人效率的因素呢？
无法和团队其他人配合的人，让团队感到不快的人是隐藏不了的，不需要任何考评就能看出来。
- “有他/她在的时候团队效率就特别高”，那么把这个考虑到考评模型中去如何呢？
这还是在考虑个人因素。
如果只是“考核”和“奖惩”，你讲的是绩效管理吧，管理可远不止这么一点点工作哦。
仔细想想，我这些说法的前提是：要有一个团队存在。而要达到这个条件，很难。
--
致
礼！
yidi...@gmail.com
alsor zhou
任何团队或者个人都无法避免这个问题。只是对于宣称自己遵循敏捷的团队而言，这个劳资双方谈判的个体“可能会”发生变化。或者说我们可以提出一种“理想的”解决办法，考评不在是每年或者半年一次的例行公事？而是在项目结束，或者达成一致的某个时间点进行的？ 或许大家可以回顾一下怎么样用直尺和铅笔画出一个近似圆的过程。
从我们公司的情况来看，敏捷实际上可以影响到HR部门。
张克强
这是我开这个贴子最想知道的。
On 6月7日, 下午6时43分, alsor zhou <alsor.z...@gmail.com> wrote:
> 或许讨论到现在，话题有点儿偏离了原来的轨道。敏捷是什么？我个人不敢跟它下定义，但直觉他不应该是公司的组织形式或者制度。绩效考评说的直白一点儿，是资方对劳方生产能力的要求（确切一点儿就是工厂里面你一小时能拧多少个螺丝钉），并且资方对劳方的生产能力付出相应回报的考核。但与传统工业生产不同的是，在脑力劳动行业很难对个人产出有比较量化的衡量。前面有人说开发人员按照bug数，恐怕就算是一个牛人（牛团）在接触新技术的时候他的bug也不少多少吧，资方就说不行，你最近bug太多了，得减薪。如果这样的话，恐怕就没有人去触摸新技术了吧。
>
> 任何团队或者个人都无法避免这个问题。只是对于宣称自己遵循敏捷的团队而言，这个劳资双方谈判的个体"可能会"发生变化。或者说我们可以提出一种"理想的"解决办法，考评不在是每年或者半年一次的例行公事？而是在项目结束，或者达成一致的某个时间点进行的？
> 或许大家可以回顾一下怎么样用直尺和铅笔画出一个近似圆的过程。
>
> 从我们公司的情况来看，敏捷实际上可以影响到HR部门。
>
> 2009/6/7 Yiding He <yiding...@gmail.com>
>
> > 如果说"项目做得好，大家都有功"，那么
> > - 我做好做坏有什么区别？
> > 没有区别！
> > - 项目做得不好，谁造成的？或者说我们在意否是谁造成的
> > 项目管理是实时跟进的。如果项目进行的不顺利，应该马上召集成员讨论！
>
> > "项目是一个团队做的"，没错，那么
> > - 如果项目包含好多个团队呢？
> > 每个团队有自己的工作方式。
>
> > 没错，"团队的效率不是简单的个人效率相加"，但既然你提议以团队为单位考评，那么
> > - 团队的考评模型应该考虑哪些因素呢？
> > 参考我们 group 之前讨论过的话题吧。原则是凡是受到团队抵制的考评手段一律去掉。
> > - 究竟要不要考虑个人效率的因素呢？
> > 无法和团队其他人配合的人，让团队感到不快的人是隐藏不了的，不需要任何考评就能看出来。
> > - "有他/她在的时候团队效率就特别高"，那么把这个考虑到考评模型中去如何呢？
> > 这还是在考虑个人因素。
>
> > 如果只是"考核"和"奖惩"，你讲的是绩效管理吧，管理可远不止这么一点点工作哦。
> > 很多项目经理对于开发人员就只关心这两点。
>
> > 仔细想想，我这些说法的前提是：*要有一个团队存在*。而要达到这个条件，很难。
>
> > 2009/6/7 Xu Yi <kaverj...@gmail.com>
>
> >> 2009/6/7 Yiding He <yiding...@gmail.com>
alsor zhou
个人觉得，虽然只是在PM那一级有了些许变化，但对传统的部门主管一言堂的方式是一个有力的补充，不过这种方式也会给HR部门带来额外的工作量。个人看法，敬请斧正。
Daniel Teng
挂钩只是一种过于简单的评价方式，是把西方思维中的科学分析法应用到人力资源管理上。但是对于人员管理问题这个问题，把东方的传统的整体思维
(Measure Up)和西方的思维结合起来应该更加有效。绩效考评评分看似客观，科学，其实十分主观，武断。
如果把考评与工资脱钩，怎样解决工资及奖金的问题呢？我觉得可以换一个角度看问题，每年不是来review应该给涨多少工资，而是有老板作出判断，他愿
意花多少钱来从市场上把这个人挖过来。这样就与这个员工的能力以及承担的责任挂钩了。对于好的团队，他们做出的成果，承担的责任会更大，有更大的提升空
间，因此相应的获得的工资以及奖金也应该更高。
要在团队中做到绝对的公平是不可能的，而且每个员工感觉的绝对公平也是不同的，因此更重要的是感觉上(Perceived)的公平。HR要和经理一起创
造这种氛围，机制。
其实对于Knowledge Worker来说钱是重要的，但是不是最重要的，因此其实HR应该配合经理们设计出综合多样的有效的激励机制，比如培训，
假期，各种奖项等等。
Daniel
On 6月7日, 下午8时48分, alsor zhou <alsor.z...@gmail.com> wrote:
> 首先要声明，我个人的角色不是PM一级的，也不属于HR部门，只是从之前的一些细微之处感觉到了和之前的不同。例如，之前的公司通常就是一言而决，首先是HR部 门拿到总的一个基准点，然后各部门有个基数，然后部门的老大给每个人定基数，然后谈（这些是听PM们说的）。实施敏捷之后，从PM一级会把一些考评的权利下放给 团队（我们部门是给团队中的高级工程师，注意，不一定是team
> lead）。当然，有人可能会说了，怎么能保证这些高级工程师的考评足够客观和科学呢？我只能说，那换了别人来打分谁能保证客观和科学呢？但有一个好处是，这样 做更切合团队实际。最了解团队的，永远是他们自己。
>
> 个人觉得，虽然只是在PM那一级有了些许变化，但对传统的部门主管一言堂的方式是一个有力的补充，不过这种方式也会给HR部门带来额外的工作量。个人看法，敬请 斧正。
>
> 2009/6/7 张克强 <zhangkeqi...@gmail.com>
>
>
>
> > 能否详讲讲是敏捷如何影响HR的？前后有什么不同?
> > 这是我开这个贴子最想知道的。
>
> > On 6月7日, 下午6时43分, alsor zhou <alsor.z...@gmail.com> wrote:
>
> > 或许讨论到现在，话题有点儿偏离了原来的轨道。敏捷是什么？我个人不敢跟它下定义，但直觉他不应该是公司的组织形式或者制度。绩效考评说的直白一点儿，是资方对 劳方生产能力的要求（确切一点儿就是工厂里面你一小时能拧多少个螺丝钉），并且资方对劳方的生产能力付出相应回报的考核。但与传统工业生产不同的是，在脑力劳动 行业很难对个人产出有比较量化的衡量。前面有人说开发人员按照bug数，恐怕就算是一个牛人（牛团）在接触新技术的时候他的bug也不少多少吧，资方就说不行， 你最近bug太多了，得减薪。如果这样的话，恐怕就没有人去触摸新技术了吧。
>
> > 任何团队或者个人都无法避免这个问题。只是对于宣称自己遵循敏捷的团队而言，这个劳资双方谈判的个体"可能会"发生变化。或者说我们可以提出一种"理想的"解决 办法，考评不在是每年或者半年一次的例行公事？而是在项目结束，或者达成一致的某个时间点进行的？
> > 什么叫管理？对很多人来说，管理就是两部分：1）考核；2）奖惩。可惜这种方式在软件项目中行不通。为什么？归根结底原因在于：编程是一项脑力劳动，而且是创造 性的脑力劳动。用那些管理体力劳动的方式来管理项目，只会适得其反。