The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet. Your reply message has not been sent.
Your post was successful
 |
From: "chenyy" <cityyo...@gmail.com>Date: Thu, 16 Nov 2006 17:54:57 -0800
Local: Thurs, Nov 16 2006 8:54 pm
Subject: 敏捷开发中的绩效如何管理呢？
这里的"绩效"是指的目标被执行的程度的表征。 代码行？BUG数量？
感觉都有点违背敏捷的意图。
大家都是如何来做绩效管理的呢？
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: weihello <weihe...@gmail.com>Date: Thu, 16 Nov 2006 21:41:24 -0600
Local: Thurs, Nov 16 2006 10:41 pm
Subject: Re: [agilechina] 敏捷开发中的绩效如何管理呢？
考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。 在 06-11-16，chenyy<cityyo...@gmail.com> 写道：
> 这里的"绩效"是指的目标被执行的程度的表征。 > 代码行？BUG数量？
> 感觉都有点违背敏捷的意图。
> 大家都是如何来做绩效管理的呢？
-- Ｘ斗米
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Shane Duan" <shane.d...@gmail.com>Date: Thu, 16 Nov 2006 21:04:07 -0800
Local: Fri, Nov 17 2006 12:04 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
什么叫因子？能解释一下吗？ On 11/16/06, weihello <weihe...@gmail.com> wrote:
> 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。 > 在 06-11-16，chenyy<cityyo...@gmail.com> 写道：
> > 这里的"绩效"是指的目标被执行的程度的表征。
> > 代码行？BUG数量？
> > 感觉都有点违背敏捷的意图。
> > 大家都是如何来做绩效管理的呢？
> --
> Ｘ斗米
-- Shane http://www.shaneduan.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "mo ying" <morningsp...@gmail.com>Date: Fri, 17 Nov 2006 18:05:53 +0800
Local: Fri, Nov 17 2006 5:05 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
同问，这个话题很有意思的，：）
在06-11-17，Shane Duan <shane.d...@gmail.com> 写道：
> 什么叫因子？能解释一下吗？
> On 11/16/06, weihello <weihe...@gmail.com> wrote:
> > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。
> > 在 06-11-16，chenyy<cityyo...@gmail.com> 写道：
> > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > 代码行？BUG数量？
> > > 感觉都有点违背敏捷的意图。
> > > 大家都是如何来做绩效管理的呢？
> > --
> > Ｘ斗米
> --
> Shane
> http://www.shaneduan.com
-- Will. Mo http://morningspace.51.net
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: Li Mo <icecl...@gmail.com>Date: Fri, 17 Nov 2006 20:36:40 +0800
Local: Fri, Nov 17 2006 7:36 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
我们都是做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>> 写道：
> > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > 代码行？BUG数量？
> > > 感觉都有点违背敏捷的意图。
> > > 大家都是如何来做绩效管理的呢？
> > --
> > Ｘ斗米
> --
> Shane
> http://www.shaneduan.com
> --
> Will. Mo
> http://morningspace.51.net <http://morningspace.51.net>
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Kingfish (Wang Yu)" <niuf...@gmail.com>Date: Fri, 17 Nov 2006 22:46:54 +0800
Local: Fri, Nov 17 2006 9:46 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
当我第一次听到这样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>> 写道：
> > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > 代码行？BUG数量？
> > > > 感觉都有点违背敏捷的意图。
> > > > 大家都是如何来做绩效管理的呢？
> > > --
> > > Ｘ斗米
> > --
> > Shane
> > http://www.shaneduan.com
> > --
> > Will. Mo
> > http://morningspace.51.net <http://morningspace.51.net>
-- www.niufish.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: Li Mo <icecl...@gmail.com>Date: Fri, 17 Nov 2006 23:22:06 +0800
Local: Fri, Nov 17 2006 10:22 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
不知道耶，国内要fire一个人挺困难的。。。
Kingfish (Wang Yu) wrote: > 当我第一次听到这样review时，确实感觉挺有意思的，但是同样感觉到巨大的压力 > 对了，想问问
> 如果这样review总是不很理想的员工
> 怎么处理？
> 有分数？几次不及格fire掉？
> On 11/17/06, *Li Mo* < icecl...@gmail.com <mailto: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>
> > <mailto: shane.d...@gmail.com <mailto:shane.d...@gmail.com>>> 写道：
> > 什么叫因子？能解释一下吗？
> > On 11/16/06, weihello <weihe...@gmail.com
> <mailto:weihe...@gmail.com>
> > <mailto: weihe...@gmail.com <mailto:weihe...@gmail.com>>> wrote:
> > > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具
> 有参考性。
> > > 在 06-11-16，chenyy< cityyo...@gmail.com
> <mailto:cityyo...@gmail.com>
> > <mailto: cityyo...@gmail.com <mailto:cityyo...@gmail.com>>>
> 写道：
> > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > 代码行？BUG数量？
> > > > 感觉都有点违背敏捷的意图。
> > > > 大家都是如何来做绩效管理的呢？
> > > --
> > > Ｘ斗米
> > --
> > Shane
> > http://www.shaneduan.com
> > --
> > Will. Mo
> > http://morningspace.51.net < http://morningspace.51.net>
> --
> www.niufish.com <http://www.niufish.com>
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "tao wen" <tao...@gmail.com>Date: Sat, 18 Nov 2006 03:14:50 +1100
Local: Fri, Nov 17 2006 11:14 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
要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>> 写道：
> > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > 代码行？BUG数量？
> > > > > 感觉都有点违背敏捷的意图。
> > > > > 大家都是如何来做绩效管理的呢？
> > > > --
> > > > Ｘ斗米
> > > --
> > > Shane
> > > http://www.shaneduan.com
> > > --
> > > Will. Mo
> > > http://morningspace.51.net < http://morningspace.51.net>
> --
> www.niufish.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Shane Duan" <shane.d...@gmail.com>Date: Fri, 17 Nov 2006 08:27:58 -0800
Local: Fri, Nov 17 2006 11:27 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
问一句： 这个问题"敏捷开发中的绩效如何管理呢？"里的绩效是指的开发项目的绩效呢还是个人的绩效？
我觉得首先要做好整个开发项目的绩效评估，一方面如果一个人的绩效好但整个项目就是一个失败的话，这个人的个人功绩是没有任何意义的。另一方面这样也可以避免一 个项目用某一个人来做替罪羊的现象。
--
Shane
http://www.shaneduan.com
On 11/17/06, tao wen <tao...@gmail.com> wrote:
> 要get rid of
> someone不用拿绩效考核来做吧。tw做review主要是给大家一个认识自身的机会，听取多方的feedback，是一个促进成长和提高的过程。如果是要 抓出坏份子来，我想至少在真正的agile工作环境中，很容易。不干活，不好好干活，那是不可能的。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "chenyy" <cityyo...@gmail.com>Date: Sat, 18 Nov 2006 05:19:17 -0000
Local: Sat, Nov 18 2006 12:19 am
Subject: Re: 敏捷开发中的绩效如何管理呢？
Shane Duan：项目的绩效如何来定义呢？ 项目失败可能就意味着没有饭吃，；-| 所以我的本意还是指个人的绩效。 "Shane Duan 写道：
"
> 问一句： > 这个问题"敏捷开发中的绩效如何管理呢？"里的绩效是指的开发项目的绩效呢还是个人的绩效？
> 我觉得首先要做好整个开发项目的绩效评估，一方面如果一个人的绩效好但整个项目就是一个失败的话，这个人的个人功绩是没有任何意义的。另一方面这样也可以避免一 个项目用某一个人来做替罪羊的现象。
> --
> Shane
> http://www.shaneduan.com
> On 11/17/06, tao wen <tao...@gmail.com> wrote:
> > 要get rid of
> > someone不用拿绩效考核来做吧。tw做review主要是给大家一个认识自身的机会，听取多方的feedback，是一个促进成长和提高的过程。如果是要 抓出坏份子来，我想至少在真正的agile工作环境中，很容易。不干活，不好好干活，那是不可能的。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Shane Duan" <shane.d...@gmail.com>Date: Fri, 17 Nov 2006 21:25:59 -0800
Local: Sat, Nov 18 2006 12:25 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
或者本来上失败的项目因为没有正确对绩效的定义而给说成了成功的项目，只有在底下开发的人员和最后使用的人才知道其中的苦处。管理项目的人从而可以继续拿着他的 证书到处招摇撞骗。 你没见过这样的项目和这样的人么？那你应该是真的很幸运了。
On 11/17/06, chenyy <cityyo...@gmail.com> wrote:
> Shane Duan：项目的绩效如何来定义呢？ > 项目失败可能就意味着没有饭吃，；-| > 所以我的本意还是指个人的绩效。 > "Shane Duan 写道：
> "
> > 问一句：
> > 这个问题"敏捷开发中的绩效如何管理呢？"里的绩效是指的开发项目的绩效呢还是个人的绩效？
> > 我觉得首先要做好整个开发项目的绩效评估，一方面如果一个人的绩效好但整个项目就是一个失败的话，这个人的个人功绩是没有任何意义的。另一方面这样也可以避免一 个项目用某一个人来做替罪羊的现象。
> > --
> > Shane
> > http://www.shaneduan.com
> > On 11/17/06, tao wen <tao...@gmail.com> wrote:
> > > 要get rid of
> > > someone不用拿绩效考核来做吧。tw做review主要是给大家一个认识自身的机会，听取多方的feedback，是一个促进成长和提高的过程。如果是要 抓出坏份子来，我想至少在真正的agile工作环境中，很容易。不干活，不好好干活，那是不可能的。
-- Shane http://www.shaneduan.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "chenyy" <cityyo...@gmail.com>Date: Sat, 18 Nov 2006 05:31:14 -0000
Local: Sat, Nov 18 2006 12:31 am
Subject: Re: 敏捷开发中的绩效如何管理呢？
听着怎么有点像"民主生活会"呢？ 考虑中国人的性格，这样的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>> 写道：
> > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > 代码行？BUG数量？
> > > > > > 感觉都有点违背敏捷的意图。
> > > > > > 大家都是如何来做绩效管理的呢？
> > > > > --
> > > > > Ｘ斗米
> > > > --
> > > > Shane
> > > > http://www.shaneduan.com
> > > > --
> > > > Will. Mo
> > > >http://morningspace.51.net<http://morningspace.51.net>
> > --
> >www.niufish.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Jeff Xiong" <gigix1...@gmail.com>Date: Sat, 18 Nov 2006 13:45:26 +0800
Local: Sat, Nov 18 2006 12:45 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance review照样进行得很好。
我个人感觉，我们的performance review有几点很重要：
1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
3、实事求是。给别人的review
feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> 听着怎么有点像"民主生活会"呢？
> 考虑中国人的性格，这样的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>> 写道：
> > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > 代码行？BUG数量？
> > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > --
> > > > > > Ｘ斗米
> > > > > --
> > > > > Shane
> > > > > http://www.shaneduan.com
> > > > > --
> > > > > Will. Mo
> > > > >http://morningspace.51.net<http://morningspace.51.net>
> > > --
> > >www.niufish.com
-- 我 闭上眼睛 天空 变得透明
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Shane Duan" <shane.d...@gmail.com>Date: Fri, 17 Nov 2006 22:01:51 -0800
Local: Sat, Nov 18 2006 1:01 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
我同意不要用中国人的性格来说事。我听到过不少这样的说法，每一次都很反感。如果自己都已经瞧不起自己了，那还怎么能指望赶上别人。如果你已经对你的同事持放弃 的态度了，那还怎么会尽你最大的努力一起合作做好当前的项目。正所谓"用人勿疑，疑人勿用" 至于多听长处还是多听短处的事，我倒是觉得好的方便也很重要。因为一个人是不可能十全十美的，真正成功的人是知道怎样能把自己的长处最大限度的发挥出来，同时能 与别人合作来弥补自己的不足。正所谓"扬已之长，补已之短"。
当然，也有可能这是由我个人的不同的经历造成的。呵呵。
有一本书有人向我推建过。买来了，还一直没机会看：
http://www.amazon.com/Discover-Your-Strengths-Marcus-Buckingham/dp/07...
On 11/17/06, Jeff Xiong <gigix1...@gmail.com> wrote:
> 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance > review照样进行得很好。 > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Jeff Xiong" <gigix1...@gmail.com>Date: Sat, 18 Nov 2006 14:25:45 +0800
Local: Sat, Nov 18 2006 1:25 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
啊……大概是同一个人推荐的吧 :>
那本书我草草的看过一下。我认为不管是要扬长也好补短也好，首要的是充分认识自己。其实一个公司、一个项目也是同样，好也罢不好也罢，首要的是让大家都清楚知道 究竟是怎么一回事。最怕的是藏着掖着，小病拖大大病拖死。
On 11/18/06, Shane Duan <shane.d...@gmail.com> wrote:
> 我同意不要用中国人的性格来说事。我听到过不少这样的说法，每一次都很反感。如果自己都已经瞧不起自己了，那还怎么能指望赶上别人。如果你已经对你的同事持放弃 的态度了，那还怎么会尽你最大的努力一起合作做好当前的项目。正所谓"用人勿疑，疑人勿用"
> 至于多听长处还是多听短处的事，我倒是觉得好的方便也很重要。因为一个人是不可能十全十美的，真正成功的人是知道怎样能把自己的长处最大限度的发挥出来，同时能 与别人合作来弥补自己的不足。正所谓"扬已之长，补已之短"。
> 当然，也有可能这是由我个人的不同的经历造成的。呵呵。
> 有一本书有人向我推建过。买来了，还一直没机会看：
> http://www.amazon.com/Discover-Your-Strengths-Marcus-Buckingham/dp/07...
> On 11/17/06, Jeff Xiong <gigix1...@gmail.com> wrote:
> > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > review照样进行得很好。
> > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
-- 我 闭上眼睛 天空 变得透明
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "chenyy" <cityyo...@gmail.com>Date: Tue, 21 Nov 2006 08:45:13 -0000
Local: Tues, Nov 21 2006 3:45 am
Subject: Re: 敏捷开发中的绩效如何管理呢？
那就是说有两种review： 一种是以提高团队成员素质为目标的performance review；还有一种是跟薪水业绩挂钩的salary review。 这么来划分的话就相对容易操作一些了。 很是羡慕TW的公司文化呀，：）
On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
wrote:
> 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance review照样进行得很好。 > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > 听着怎么有点像"民主生活会"呢？
> > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > 代码行？BUG数量？
> > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > --
> > > > > > > Ｘ斗米
> > > > > > --
> > > > > > Shane
> > > > > > http://www.shaneduan.com
> > > > > > --
> > > > > > Will. Mo
> > > > > >http://morningspace.51.net<http://morningspace.51.net>
> > > > --
> > > >www.niufish.com--
> 我 闭上眼睛
> 天空 变得透明
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "mo ying" <morningsp...@gmail.com>Date: Tue, 21 Nov 2006 16:49:43 +0800
Local: Tues, Nov 21 2006 3:49 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> 那就是说有两种review：
> 一种是以提高团队成员素质为目标的performance
> review；还有一种是跟薪水业绩挂钩的salary review。
> 这么来划分的话就相对容易操作一些了。
> 很是羡慕TW的公司文化呀，：）
> On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> wrote:
> > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance review照样进行得很好。
> > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > 听着怎么有点像"民主生活会"呢？
> > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > 代码行？BUG数量？
> > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > --
> > > > > > > > Ｘ斗米
> > > > > > > --
> > > > > > > Shane
> > > > > > > http://www.shaneduan.com
> > > > > > > --
> > > > > > > Will. Mo
> > > > > > >http://morningspace.51.net<http://morningspace.51.net>
> > > > > --
> > > > >www.niufish.com--
> > 我 闭上眼睛
> > 天空 变得透明
-- Will. Mo http://morningspace.51.net
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "yk where" <ykwh...@gmail.com>Date: Wed, 22 Nov 2006 21:41:07 +0800
Local: Wed, Nov 22 2006 8:41 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
CMMI强调的是定量（quantitative research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。 On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效 > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > 那就是说有两种review：
> > 一种是以提高团队成员素质为目标的performance
> > review；还有一种是跟薪水业绩挂钩的salary review。
> > 这么来划分的话就相对容易操作一些了。
> > 很是羡慕TW的公司文化呀，：）
> > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > wrote:
> > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> review照样进行得很好。
> > > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > 听着怎么有点像"民主生活会"呢？
> > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > --
> > > > > > > > > Ｘ斗米
> > > > > > > > --
> > > > > > > > Shane
> > > > > > > > http://www.shaneduan.com
> > > > > > > > --
> > > > > > > > Will. Mo
> > > > > > > > http://morningspace.51.net<http://morningspace.51.net>
> > > > > > --
> > > > > >www.niufish.com--
> > > 我 闭上眼睛
> > > 天空 变得透明
> --
> Will. Mo
> http://morningspace.51.net
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "jayden guan" <jayden.g...@gmail.com>Date: Thu, 23 Nov 2006 00:09:14 +0800
Local: Wed, Nov 22 2006 11:09 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
没本事定量才只能定性. 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> CMMI强调的是定量（quantitative > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。 > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。 > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > 那就是说有两种review：
> > > 一种是以提高团队成员素质为目标的performance
> > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > 这么来划分的话就相对容易操作一些了。
> > > 很是羡慕TW的公司文化呀，：）
> > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > wrote:
> > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > review照样进行得很好。
> > > > 我个人感觉，我们的performance review有几点很重要：
> > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > 3、实事求是。给别人的review
> > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > 听着怎么有点像"民主生活会"呢？
> > > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > > --
> > > > > > > > > > Ｘ斗米
> > > > > > > > > --
> > > > > > > > > Shane
> > > > > > > > > http://www.shaneduan.com
> > > > > > > > > --
> > > > > > > > > Will. Mo
> > > > > > > > > http://morningspace.51.net<http://morningspace.51.net>
> > > > > > > --
> > > > > > >www.niufish.com--
> > > > 我 闭上眼睛
> > > > 天空 变得透明
> > --
> > Will. Mo
> > http://morningspace.51.net
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "yk where" <ykwh...@gmail.com>Date: Thu, 23 Nov 2006 11:23:50 +0800
Local: Wed, Nov 22 2006 10:23 pm
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
比较同意jayden guan 的说法, 没有本事定量才只能定性. (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的) 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
对人的系统的测量，必然要影响被测者，
一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
所以，真的如jayden guan
所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
On 11/23/06, jayden guan <jayden.g...@gmail.com> wrote:
> 没本事定量才只能定性. > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > CMMI强调的是定量（quantitative
> > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > > 那就是说有两种review：
> > > > 一种是以提高团队成员素质为目标的performance
> > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > 这么来划分的话就相对容易操作一些了。
> > > > 很是羡慕TW的公司文化呀，：）
> > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > wrote:
> > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > review照样进行得很好。
> > > > > 我个人感觉，我们的performance review有几点很重要：
> > > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > 3、实事求是。给别人的review
> > > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > > > --
> > > > > > > > > > > Ｘ斗米
> > > > > > > > > > --
> > > > > > > > > > Shane
> > > > > > > > > > http://www.shaneduan.com
> > > > > > > > > > --
> > > > > > > > > > Will. Mo
> > > > > > > > > > http://morningspace.51.net<http://morningspace.51.net>
> > > > > > > > --
> > > > > > > >www.niufish.com--
> > > > > 我 闭上眼睛
> > > > > 天空 变得透明
> > > --
> > > Will. Mo
> > > http://morningspace.51.net
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Kingfish (Wang Yu)" <niuf...@gmail.com>Date: Thu, 23 Nov 2006 13:03:54 +0800
Local: Thurs, Nov 23 2006 12:03 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
我比较认同"对定量数据的一种迷信"这种说法
On 11/23/06, yk where <ykwh...@gmail.com> wrote:
> 比较同意jayden guan 的说法, 没有本事定量才只能定性.
> (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
> 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
> 海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
> 由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
> 对人的系统的测量，必然要影响被测者，
> 一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
> 所以，真的如jayden guan
> 所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
> On 11/23/06, jayden guan <jayden.g...@gmail.com> wrote:
> > 没本事定量才只能定性.
> > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > > CMMI强调的是定量（quantitative
> research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > > > 那就是说有两种review：
> > > > > 一种是以提高团队成员素质为目标的performance
> > > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > > 这么来划分的话就相对容易操作一些了。
> > > > > 很是羡慕TW的公司文化呀，：）
> > > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > > wrote:
> > > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > > review照样进行得很好。
> > > > > > 我个人感觉，我们的performance review有几点很重要：
> 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > > 3、实事求是。给别人的review
> feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > > > > --
> > > > > > > > > > > > Ｘ斗米
> > > > > > > > > > > --
> > > > > > > > > > > Shane
> > > > > > > > > > > http://www.shaneduan.com
> > > > > > > > > > > --
> > > > > > > > > > > Will. Mo
> > > > > > > > > > > http://morningspace.51.net<http://morningspace.51.net>
> > > > > > > > > --
> > > > > > > > >www.niufish.com--
> > > > > > 我 闭上眼睛
> > > > > > 天空 变得透明
> > > > --
> > > > Will. Mo
> > > > http://morningspace.51.net
-- www.niufish.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "mo ying" <morningsp...@gmail.com>Date: Thu, 23 Nov 2006 13:40:54 +0800
Local: Thurs, Nov 23 2006 12:40 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
一点个人联想：
关于定量的问题，Pete Mcbreen早在前几年出版的Qestioning
XP中就提到了，提到了霍桑，提到了亨利，。。。觉得这些都在向我们表明，别迷信数据，别在乎是不是精确。而且有意思的是，这本书是专门针对XP的，像在给狂热 者们善意的泼冷水，因为按照这样的逻辑，其实传统方法和敏捷方法并没有本质上谁好谁坏之分，因为没有办法通过"精确测量"的手段来得出结论，换句话说，那些能" 证明"敏捷方法或传统方法更有效的实验也好，数据也好，那都只是参考而已，不能太叫真。因而我们现在所讨论的东西，大多都是根据主观来的，都是经验谈，事实也是 如此，相信大多数实践敏捷者首先都是在讲自己的个人经验和体验，都是实践中来的，然后再传播给其他人，所以这些东西也都具有不确定性，并不是每个人都能完全复制 的。在人们中间能复制的是什么，只有所谓的Values，Principles，Practices，这些东西都不是定量的，包括Practice在内。
不过另外一点，其实最开始在讨论这个话题的时候我没有理解题目的意思，于是首先想到的是一个敏捷里很重要的Value，那就是Feedback，其实无论是定量 也好定性也好，都是在强调这一点，正是因为团队内外的不同人希望对当前所做的东西有一个反馈，所以才要有这样那样的方法和手段。但是不管怎样，Feedback 确定无疑是很重要的，而从经验和实践的角度而言，敏捷方法很强调Feedback，同时也有一些实际的做法在体现这个东西，比如从项目进度的角度，将问题域分解 为一个个可实现的User
Story就是一个很好的主意，因为这样就可以通过关注众多不同User
Story的*状态*来一定程度的掌握项目的进展情况。而这是定量的。是一种简单的*定量*，但又是能足够说明问题的*定量*。当然，这个和题目里讲的绩效是两 码事，呵呵。。。
在06-11-23，Kingfish (Wang Yu) <niuf...@gmail.com> 写道：
> 我比较认同"对定量数据的一种迷信"这种说法
> On 11/23/06, yk where <ykwh...@gmail.com> wrote:
> > 比较同意jayden guan 的说法, 没有本事定量才只能定性.
> > (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
> > 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
> > 海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
> > 由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
> > 对人的系统的测量，必然要影响被测者，
> > 一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
> > 所以，真的如jayden guan
> > 所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
> > On 11/23/06, jayden guan < jayden.g...@gmail.com> wrote:
> > > 没本事定量才只能定性.
> > > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > > > CMMI强调的是定量（quantitative
> > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > > > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > > > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > > > 在06-11-21，chenyy < cityyo...@gmail.com> 写道：
> > > > > > 那就是说有两种review：
> > > > > > 一种是以提高团队成员素质为目标的performance
> > > > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > > > 这么来划分的话就相对容易操作一些了。
> > > > > > 很是羡慕TW的公司文化呀，：）
> > > > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > > > wrote:
> > > > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > > > review照样进行得很好。
> > > > > > > 我个人感觉，我们的performance review有几点很重要：
> > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > > > 3、实事求是。给别人的review
> > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > > > 考虑中国人的性格，这样的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:
> > > > > > > > > > > > > 考核绩效非常重要的一个指标： 因子。 因子的变化图极其具有参考性。
> > > > > > > > > > > > > 在
... read more »
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Tony Qiao" <sagittatius.q...@gmail.com>Date: Wed, 22 Nov 2006 21:46:05 -0800
Local: Thurs, Nov 23 2006 12:46 am
Subject: Re: 敏捷开发中的绩效如何管理呢？
很多公司没有用CMMI这种方法来管理，我看也管得不错。 如果"人"也可以定量的话，这个世界就是完全理性的了。
用CMMI管理的公司，我也没看出好多少。
"Kingfish (Wang Yu) 写道：
"
> 我比较认同"对定量数据的一种迷信"这种说法 > On 11/23/06, yk where <ykwh...@gmail.com> wrote:
> > 比较同意jayden guan 的说法, 没有本事定量才只能定性.
> > (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
> > 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
> > 海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
> > 由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
> > 对人的系统的测量，必然要影响被测者，
> > 一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
> > 所以，真的如jayden guan
> > 所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
> > On 11/23/06, jayden guan <jayden.g...@gmail.com> wrote:
> > > 没本事定量才只能定性.
> > > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > > > CMMI强调的是定量（quantitative
> > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > > > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > > > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > > > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > > > > 那就是说有两种review：
> > > > > > 一种是以提高团队成员素质为目标的performance
> > > > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > > > 这么来划分的话就相对容易操作一些了。
> > > > > > 很是羡慕TW的公司文化呀，：）
> > > > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > > > wrote:
> > > > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > > > review照样进行得很好。
> > > > > > > 我个人感觉，我们的performance review有几点很重要：
> > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > > > 3、实事求是。给别人的review
> > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Ｘ斗米
> > > > > > > > > > > > --
> > > > > > > > > > > > Shane
> > > > > > > > > > > > http://www.shaneduan.com
> > > > > > > > > > > > --
> > > > > > > > > > > > Will. Mo
> > > > > > > > > > > > http://morningspace.51.net<http://morningspace.51.net>
> > > > > > > > > > --
> > > > > > > > > >www.niufish.com--
> > > > > > > 我 闭上眼睛
> > > > > > > 天空 变得透明
> > > > > --
> > > > > Will. Mo
> > > > > http://morningspace.51.net
> --
> www.niufish.com
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Shane Duan" <shane.d...@gmail.com>Date: Thu, 23 Nov 2006 00:07:20 -0800
Local: Thurs, Nov 23 2006 3:07 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
我觉得定量本身是没有什么不好的。是你把这些量放在什么样的位置上才是真正重要的。 CMM的起始点是统查一遍所有的项目的各个方面，以期望能从中能找到成功的规律。仔细想想，这真的是实际得不能再实际的方法。他们也确实找着了不少的规律。那些 各种等级的划分也就是这里的量。
我觉得的问题的所在不是我们找在找项目中的量，而应该是我们想怎么用这些数据。数据只是项目进行的怎么样的一个表面现象，是很好的的参考。但如果我们只迷信这些 数据，以这些数据为而不是项目的成功为目标的话，就是舍本逐末了。
我读过一个笑话：
外星人想进攻地球, 但经过调查以后就放弃了。原因是他们发现地球上有不少地方被一片片的石头砸在地上，一方面石头砸的很准，每一个下面都是一个死人。另一方面他们查来查去也不知道 这些石头哪来的。唯一似乎有用的信息是地球管这种地方叫"坟场"。
On 11/22/06, Tony Qiao <sagittatius.q...@gmail.com> wrote:
> 很多公司没有用CMMI这种方法来管理，我看也管得不错。 > 如果"人"也可以定量的话，这个世界就是完全理性的了。
> 用CMMI管理的公司，我也没看出好多少。
> "Kingfish (Wang Yu) 写道：
> "
> > 我比较认同"对定量数据的一种迷信"这种说法
> > On 11/23/06, yk where <ykwh...@gmail.com> wrote:
> > > 比较同意jayden guan 的说法, 没有本事定量才只能定性.
> > > (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
> > > 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
> > > 海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
> > > 由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
> > > 对人的系统的测量，必然要影响被测者，
> > > 一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
> > > 所以，真的如jayden guan
> > > 所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
> > > On 11/23/06, jayden guan <jayden.g...@gmail.com> wrote:
> > > > 没本事定量才只能定性.
> > > > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > > > > CMMI强调的是定量（quantitative
> > > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> > > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > > > > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > > > > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > > > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > > > > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > > > > > 那就是说有两种review：
> > > > > > > 一种是以提高团队成员素质为目标的performance
> > > > > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > > > > 这么来划分的话就相对容易操作一些了。
> > > > > > > 很是羡慕TW的公司文化呀，：）
> > > > > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > > > > wrote:
> > > > > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > > > > review照样进行得很好。
> > > > > > > > 我个人感觉，我们的performance review有几点很重要：
> > > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > > > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > > > > 3、实事求是。给别人的review
> > > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > > > > 考虑中国人的性格，这样的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>> 写道：
> > > > > > > > > > > > > > > 这里的"绩效"是指的目标被执行的程度的表征。
> > > > > > > > > > > > > > > 代码行？BUG数量？
> > > > > > > > > > > > > > > 感觉都有点违背敏捷的意图。
> > > > > > > > > > > > > > > 大家都是如何来做绩效管理的呢？
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Ｘ斗米
... read more »
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "jayden guan" <jayden.g...@gmail.com>Date: Thu, 23 Nov 2006 21:45:12 +0800
Local: Thurs, Nov 23 2006 8:45 am
Subject: Re: [agilechina] Re: 敏捷开发中的绩效如何管理呢？
怎么看不懂大家在讨论什么 -_-! 在 06-11-23，Shane Duan<shane.d...@gmail.com> 写道：
> 我觉得定量本身是没有什么不好的。是你把这些量放在什么样的位置上才是真正重要的。 > CMM的起始点是统查一遍所有的项目的各个方面，以期望能从中能找到成功的规律。仔细想想，这真的是实际得不能再实际的方法。他们也确实找着了不少的规律。那些 各种等级的划分也就是这里的量。
> 我觉得的问题的所在不是我们找在找项目中的量，而应该是我们想怎么用这些数据。数据只是项目进行的怎么样的一个表面现象，是很好的的参考。但如果我们只迷信这些 数据，以这些数据为而不是项目的成功为目标的话，就是舍本逐末了。
> 我读过一个笑话：
> 外星人想进攻地球, 但经过调查以后就放弃了。原因是他们发现地球上有不少地方被一片片的石头砸在地上，一方面石头砸的很准，每一个下面都是一个死人。另一方面他们查来查去也不知道 这些石头哪来的。唯一似乎有用的信息是地球管这种地方叫"坟场"。
> On 11/22/06, Tony Qiao <sagittatius.q...@gmail.com> wrote:
> > 很多公司没有用CMMI这种方法来管理，我看也管得不错。
> > 如果"人"也可以定量的话，这个世界就是完全理性的了。
> > 用CMMI管理的公司，我也没看出好多少。
> > "Kingfish (Wang Yu) 写道：
> > "
> > > 我比较认同"对定量数据的一种迷信"这种说法
> > > On 11/23/06, yk where <ykwh...@gmail.com> wrote:
> > > > 比较同意jayden guan 的说法, 没有本事定量才只能定性.
> > > > (但是大陆业界一般把qualitative翻译成"质",台湾翻作"质性", 与以往那种拍脑袋的"定性"是有区别的)
> > > > 所谓的定量是借鉴自然科学的研究方法----所谓实证主义简化还原论.即使在自然科学界本身,这种方式也已然受到挑战.
> > > > 海森伯格"测不准原理"已经昭示：过去那种确定论的自然观和人对自然的研究可以保持中立,不影响被研究对象的观念都是不切实际的幻想.
> > > > 由人构成的开发团队的系统,并不比自然系统更简单. 所谓的定量测量, 是否就一定能保证不影响被测量者,一定能"测得准"?
> > > > 对人的系统的测量，必然要影响被测者，
> > > > 一个最简单的例子就是著名的"霍桑效应"。（不熟悉的朋友狗狗一下就知道了。）此外，香农定理说"采样频率应不小于信号变化频率的二倍,所得采样数据可以还原原 信号".你知道团队成员的情绪、动机、信息获取这些变量的变化频率是多少吗？你的采样频率能保证是这些变量变化频率的两倍以上吗？而人的系统也不仅仅只涉及区区 这么几个变量吧。即使严格按照统计学原则，基于大样本的统计，在样本推总体的时候，还有个置信度的问题呢，谁敢说100%可信。而置信度要求越高，需要投入的成 本越大，这些成本是企业能够或者愿意承受的吗？
> > > > 所以，真的如jayden guan
> > > > 所说"没有本事定量"。（往大里说，人类也根本没本事单靠定量分析就能认清楚真实的世界。）而拿着那些不可靠的所谓定量数据就开始说事，就开始指导项目管理，开 始评定绩效，好象挺"科学"的。这其实是对定量数据的一种迷信。
> > > > On 11/23/06, jayden guan <jayden.g...@gmail.com> wrote:
> > > > > 没本事定量才只能定性.
> > > > > 在 06-11-22，yk where<ykwh...@gmail.com> 写道：
> > > > > > CMMI强调的是定量（quantitative
> > > > research）项目管理，但是无论软件工程界还是管理学界都已经认识到，定量并不是研究管理问题唯一的方法，（在某种情况下）也不一定是最好的方式。从某种 意义上，敏捷实际上是在打破定量管理的乌托邦神话，走质的研究（qualitative
> > > > research）的路子去处理项目管理问题，更多强调信息背后的实际背景，而不是耗费大量经历去抽取那些无背景信息且有待进一步V&V的数据。很多CMMI项 目不成功的原因就是用这些半成品的数据说事，而不去考虑这些数据是否真的有意义。
> > > > > > 与此相对应，敏捷的绩效管理也应该放弃抽象的定量管理的思路，走质的思路去更深入地关注团队背景下的个人。
> > > > > > On 11/21/06, mo ying <morningsp...@gmail.com> wrote:
> > > > > > > 一个问题，salary review是如何奏效的，因为一般认为的，xp团队是很难评估个人绩效的，更多的是整个团队的绩效
> > > > > > > 在06-11-21，chenyy <cityyo...@gmail.com> 写道：
> > > > > > > > 那就是说有两种review：
> > > > > > > > 一种是以提高团队成员素质为目标的performance
> > > > > > > > review；还有一种是跟薪水业绩挂钩的salary review。
> > > > > > > > 这么来划分的话就相对容易操作一些了。
> > > > > > > > 很是羡慕TW的公司文化呀，：）
> > > > > > > > On 11月18日, 下午1时45分, "Jeff Xiong" <gigix1...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > 我不喜欢用"中国人的性格"来说事。ThoughtWorks中国分公司绝大多数都是中国人，performance
> > > > > > > review照样进行得很好。
> > > > > > > > > 我个人感觉，我们的performance review有几点很重要：
> > > > 1、共识。大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWork ers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大--我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时 提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。
> > > > > > > 2、不与运营挂钩。这分为两个方面，第一我们的review不与收入直接相关，HR和managing团队有另一个salary
> > > > review；第二不会把项目的成败牵扯进来，review看的是这个人的各方面特质，而不是找人给失败项目扛包背锅，更不能拿代码量和bug量作为标准，那只 会催生拈轻怕重偷奸耍滑。
> > > > > > > > > 3、实事求是。给别人的review
> > > > feedback不需要全面，也不需要客观公正，但是每一条必须有事实佐证。假设我说谁谁技术很好，我必须举出例子，他做了什么什么很牛的东西；或者我说谁谁缺 乏耐性，也要举例说他遇到什么事是怎么处理的。这就避免了空话套话和扣帽子。
> > > > > > > > > On 11/18/06, chenyy <cityyo...@gmail.com> wrote:
> > > > > > > > > > 听着怎么有点像"民主生活会"呢？
> > > > > > > > > > 考虑中国人的性格，这样的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>> 写道：
... read more »
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
|
