敏捷开发中的绩效如何管理呢？
chenyy
代码行？BUG数量？
感觉都有点违背敏捷的意图。
大家都是如何来做绩效管理的呢？
weihello
Shane Duan
--
Shane
http://www.shaneduan.com
mo ying
Li Mo
而不是靠任何的code，bug啥的，谁能写东西没bug呢。例如某x，负责的都是最复
杂最艰巨的任务，出的bug也都是大bug，要按bug评绩效早该fire了
mo ying wrote:
> 同问，这个话题很有意思的，：）
>
> 在06-11-17，*Shane Duan* <shane...@gmail.com
> <mailto:shane...@gmail.com>> 写道：
>
> 什么叫因子？能解释一下吗？
>
> On 11/16/06, weihello <weih...@gmail.com
> <mailto:weih...@gmail.com>> wrote:
> > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。
> >
> > 在 06-11-16，chenyy< city...@gmail.com
> <mailto:city...@gmail.com>> 写道：
> > > 这里的"绩效"是指的目标被执行的程度的表征。
> > >
> > > 代码行？BUG数量？
> > > 感觉都有点违背敏捷的意图。
> > > 大家都是如何来做绩效管理的呢？
> > >
> >
> >
> > --
> > Ｘ斗米
> >
>
>
> --
> Shane
> http://www.shaneduan.com
>
>
>
>
> --
> Will. Mo
Kingfish (Wang Yu)
对了，想问问
如果这样review总是不很理想的员工
怎么处理？
有分数？几次不及格fire掉？
www.niufish.com
Li Mo
Kingfish (Wang Yu) wrote:
> 当我第一次听到这样review时，确实感觉挺有意思的，但是同样感觉到巨大的压力
>
> 对了，想问问
>
> 如果这样review总是不很理想的员工
>
> 怎么处理？
>
> 有分数？几次不及格fire掉？
>
>
> On 11/17/06, *Li Mo* < icec...@gmail.com <mailto:icec...@gmail.com>>
> wrote:
>
>
> 我们都是做360度review，由一起工作的同事来评价你的performance
> 而不是靠任何的code，bug啥的，谁能写东西没bug呢。例如某x，负责的都是最复
> 杂最艰巨的任务，出的bug也都是大bug，要按bug评绩效早该fire了
>
> mo ying wrote:
> > 同问，这个话题很有意思的，：）
> >
> > 在06-11-17，*Shane Duan* <shane...@gmail.com
> <mailto:shane...@gmail.com>
> > <mailto: shane...@gmail.com <mailto:shane...@gmail.com>>> 写道：
> >
> > 什么叫因子？能解释一下吗？
> >
> > On 11/16/06, weihello <weih...@gmail.com
> <mailto:weih...@gmail.com>
> > <mailto: weih...@gmail.com <mailto:weih...@gmail.com>>> wrote:
> > > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具
> 有参考性。
> > >
> > > 在 06-11-16，chenyy< city...@gmail.com
> <mailto:city...@gmail.com>
> > <mailto: city...@gmail.com <mailto:city...@gmail.com>>>
> 写道：
> > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > >
> > > > 代码行？BUG数量？
> > > > 感觉都有点违背敏捷的意图。
> > > > 大家都是如何来做绩效管理的呢？
> > > >
> > >
> > >
> > > --
> > > Ｘ斗米
> > >
> >
> >
> > --
> > Shane
> > http://www.shaneduan.com
> >
> >
> >
> >
> > --
> > Will. Mo
> > http://morningspace.51.net < http://morningspace.51.net>
>
>
>
>
> --
tao wen
Shane Duan
这个问题"敏捷开发中的绩效如何管理呢？"里的绩效是指的开发项目的绩效呢还是个人的绩效？
我觉得首先要做好整个开发项目的绩效评估，一方面如果一个人的绩效好但整个项目就是一个失败的话，这个人的个人功绩是没有任何意义的。另一方面这样也可以避免一个项目用某一个人来做替罪羊的现象。
--
Shane
http://www.shaneduan.com
chenyy
项目失败可能就意味着没有饭吃，；-|
所以我的本意还是指个人的绩效。
"Shane Duan 写道：
Shane Duan
你没见过这样的项目和这样的人么？那你应该是真的很幸运了。
--
Shane
http://www.shaneduan.com
chenyy
考虑中国人的性格，这样的review容易操作吗？
担心这样的Review容易流于形式
On 11月18日, 上午12时14分, "tao wen" <tao...@gmail.com> wrote:
> 要get rid of
> someone不用拿绩效考核来做吧。tw做review主要是给大家一个认识自身的机会，听取多方的feedback，是一个促进成长和提高的过程。如果是要抓出坏份子来，我想至少在真正的agile工作环境中，很容易。不干活，不好好干活，那是不可能的。
>
> 在06-11-18，Kingfish (Wang Yu) <niuf...@gmail.com> 写道：
>
>
>
> > 当我第一次听到这样review时，确实感觉挺有意思的，但是同样感觉到巨大的压力
>
> > 对了，想问问
>
> > 如果这样review总是不很理想的员工
>
> > 怎么处理？
>
> > 有分数？几次不及格fire掉？
>
> > On 11/17/06, Li Mo < icecl...@gmail.com> wrote:
>
> > > 我们都是做360度review，由一起工作的同事来评价你的performance
> > > 而不是靠任何的code，bug啥的，谁能写东西没bug呢。例如某x，负责的都是最复
> > > 杂最艰巨的任务，出的bug也都是大bug，要按bug评绩效早该fire了
>
> > > mo ying wrote:
> > > > 同问，这个话题很有意思的，：）
>
> > > > 在06-11-17，*Shane Duan* <shane.d...@gmail.com
> > > > <mailto: shane.d...@gmail.com>> 写道：
>
> > > > 什么叫因子？能解释一下吗？
>
> > > > On 11/16/06, weihello <weihe...@gmail.com
> > > > <mailto: weihe...@gmail.com>> wrote:
> > > > > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。
>
> > > > > 在 06-11-16，chenyy< cityyo...@gmail.com
> > > > <mailto: cityyo...@gmail.com>> 写道：
Jeff Xiong
我个人感觉，我们的performance review有几点很重要：
1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWorkers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只会催生拈轻怕重偷奸耍滑。
3、实事求是。给别人的review feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
我 闭上眼睛
天空 变得透明
Shane Duan
至于多听长处还是多听短处的事，我倒是觉得好的方便也很重要。因为一个人是不可能十全十美的，真正成功的人是知道怎样能把自己的长处最大限度的发挥出来，同时能与别人合作来弥补自己的不足。正所谓"扬已之长，补已之短"。
当然，也有可能这是由我个人的不同的经历造成的。呵呵。
有一本书有人向我推建过。买来了，还一直没机会看：
http://www.amazon.com/Discover-Your-Strengths-Marcus-Buckingham/dp/0743201140/sr=8-1/qid=1160678333/ref=pd_bbs_1/102-6255330-8729744?ie=UTF8
Jeff Xiong
那本书我草草的看过一下。我认为不管是要扬长也好补短也好，首要的是充分认识自己。其实一个公司、一个项目也是同样，好也罢不好也罢，首要的是让大家都清楚知道究竟是怎么一回事。最怕的是藏着掖着，小病拖大大病拖死。
chenyy
一种是以提高团队成员素质为目标的performance
review；还有一种是跟薪水业绩挂钩的salary review。
这么来划分的话就相对容易操作一些了。
很是羡慕TW的公司文化呀，：）
On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
wrote:
> 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance review照样进行得很好。
>
> 我个人感觉，我们的performance review有几点很重要：
>
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWorkers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
>
> 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只会催生拈轻怕重偷奸耍滑。
>
> 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
>
mo ying
yk where
research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
jayden guan
在 06-11-22，yk where<ykw...@gmail.com> 写道：
yk where
(但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
对人的系统的测量，必然要影响被测者，
一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成本越大，这些成本是企业能够或者愿意承受的吗？
所以，真的如jayden guan
所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
Kingfish (Wang Yu)
mo ying
关于定量的问题，Pete Mcbreen早在前几年出版的Qestioning XP中就提到了，提到了霍桑，提到了亨利，。。。觉得这些都在向我们表明，别迷信数据，别在乎是不是精确。而且有意思的是，这本书是专门针对XP的，像在给狂热者们善意的泼冷水，因为按照这样的逻辑，其实传统方法和敏捷方法并没有本质上谁好谁坏之分，因为没有办法通过"精确测量"的手段来得出结论，换句话说，那些能"证明"敏捷方法或传统方法更有效的实验也好，数据也好，那都只是参考而已，不能太叫真。因而我们现在所讨论的东西，大多都是根据主观来的，都是经验谈，事实也是如此，相信大多数实践敏捷者首先都是在讲自己的个人经验和体验，都是实践中来的，然后再传播给其他人，所以这些东西也都具有不确定性，并不是每个人都能完全复制的。在人们中间能复制的是什么，只有所谓的Values，Principles，Practices，这些东西都不是定量的，包括Practice在内。
不过另外一点，其实最开始在讨论这个话题的时候我没有理解题目的意思，于是首先想到的是一个敏捷里很重要的Value，那就是Feedback，其实无论是定量也好定性也好，都是在强调这一点，正是因为团队内外的不同人希望对当前所做的东西有一个反馈，所以才要有这样那样的方法和手段。但是不管怎样，Feedback确定无疑是很重要的，而从经验和实践的角度而言，敏捷方法很强调Feedback，同时也有一些实际的做法在体现这个东西，比如从项目进度的角度，将问题域分解为一个个可实现的User Story就是一个很好的主意，因为这样就可以通过关注众多不同User Story的*状态*来一定程度的掌握项目的进展情况。而这是定量的。是一种简单的*定量*，但又是能足够说明问题的*定量*。当然，这个和题目里讲的绩效是两码事，呵呵。。。
Tony Qiao
如果"人"也可以定量的话，这个世界就是完全理性的了。
用CMMI管理的公司，我也没看出好多少。
"Kingfish (Wang Yu) 写道：
Shane Duan
CMM的起始点是统查一遍所有的项目的各个方面，以期望能从中能找到成功的规律。仔细想想，这真的是实际得不能再实际的方法。他们也确实找着了不少的规律。那些各种等级的划分也就是这里的量。
我觉得的问题的所在不是我们找在找项目中的量，而应该是我们想怎么用这些数据。数据只是项目进行的怎么样的一个表面现象，是很好的的参考。但如果我们只迷信这些数据，以这些数据为而不是项目的成功为目标的话，就是舍本逐末了。
我读过一个笑话：
外星人想进攻地球, 但经过调查以后就放弃了。原因是他们发现地球上有不少地方被一片片的石头砸在地上，一方面石头砸的很准，每一个下面都是一个死人。另一方面他们查来查去也不知道这些石头哪来的。唯一似乎有用的信息是地球管这种地方叫"坟场"。
--
Shane
http://www.shaneduan.com
jayden guan
在 06-11-23，Shane Duan<shane...@gmail.com> 写道：
Tony Qiao
首先，我是支持度量和度量分析。用数据说话更容易说服人。
但是，如何选择被度量的指标，以及如何利用这些度量数据才是关键的问题。度量的数据一般是做为项目指导，而很多公司用它来做考评。拿它来考核，那数据就变味了，变成了一堆漂亮的垃圾。原因很简单，就不说啦。
另外，产生这些度量数据的背景也是很重要的。听说业界代码产出是60行/人日，可这个数据是怎么得来的，多少个项目，什么样的项目，有没有可比性，有没有参考性都是值得推敲的。
之所以很喜欢敏捷，原因之一就是它以某个具体项目为目标，根据项目选择适合的实践。
CMMI的思想原来是很好的，可到了中国就变味了（听说，在美国推广也有问题。为了适应发展，现在CMMI出了1.2版。）
个人观点，CMMI之所以受到老总们的关注和重视，一方面是证书有用；另一方面就是，CMMI更强调过程，而不是人的能动性。听到过这样的说法，如果严格按照CMMI来做事，只要严格控制过程，谁做项目都一样。
说到绩效，如果分成两个来考核，对个人来说，哪个考核准？一般认为，薪资考核的依据就是个人的表现呀。
Shane Duan
--
Shane
http://www.shaneduan.com
jayden.guan
推荐个贴子:
主题: potian的软件开发常用工具箱
http://www.javaeye.com/topic/8355
看看人家在度量点什么.
Shane Duan
你这么说似乎是在说CMM度量的东西不对。我觉得度量的东西是对的，只是我们怎么对待。正如Tony Qiao所说的一样
--
Shane
http://www.shaneduan.com
机枪兵
再严格的管理，也不能把一群猴子训练成善战的士兵。
很多管理手段实际上降低了而不是提高了开发效率，项目成员应该抵制这些政治干扰。
Donald
TW的做法我觉得挺对路，但不是所有公司都合适，TW的目标和其他公司的目标不太一样。人员配备显然也不同。
--
jayden.guan
最近在看Gerald M. Weinberg 的<质量.软件.管理--系统思维>
我基本同意Shane Duan 的说法.
至于怎么对待,我觉得基本有几种:
一种把度量结果作为一个反馈,根据反馈做调整.
另一种把度量作为一种例行公事,行为并不受到度量结果的影响.
在一个以类瀑布型风格的模式中,很有可能是后者.
"Shane Duan 写道：