博客统计信息

51cto博客之星
用户名:mk6yeung
文章数:50
评论数:226
访问量:89381
无忧币:1583
博客积分:2712
博客等级:7
注册日期:2008-06-11

我的技术圈(3)

更多>>
目标的影响与作用
2009-12-07 07:56:48
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://mk6yeung.blog.51cto.com/400635/239661
 
目标的影响与作用
无论举措是如何容易,我觉得任何改进都离不开目标的问题。我们的目标一定需要与改进相关的。否则就很难收到改进的效果。
但是掌握目标不容易。举一个例子。在大家还不习惯用需求主导项目活动的情况下,把需求写道非常细是不错的方法。这样会帮助提高需求的分析能力,同时也会让测试的策划与执行非常容易。其中得副产品,就是需求的数量会变得多了好多。这个其实也不错,因为需求项粒度越小,需求数量越大,从统计的角度看,需求数量反而越能正确反映项目的规模。如此,我们就可以使用需求的数量作为项目规模的测量了。
好,有一位部长实施了这个概念。因为他希望测量效率,就定义项目效率为:
        需求数量/项目的工作量
然后就把这个测量的值拿来考核。结果就是没有使用这个测量之前,需求粒度比较大,然后效率就比较低。用这个测量考核之后,每一位系统工程师都拼命地把需求做细,把项目效率的值立刻提高了很多。领导立刻停止了这个做法。我问他为什么要停止?回答就是,“这些人的态度不好,为考核把需求做的太细了。”
留意这个目标。这样的管理理念,就是在于控制行为。我们的目标应该在于提高效率。如果我们相信降低需求粒度会帮助提高需求开发的能力,以及提高下游的工作效率,那么这个结果就是期待的结果。这个激励就是不错的激励。原因就是如何的现象才是有助过程效率的。在这个情况,明显地是一个可喜的发展。以前曾经试过很多激励方法,还不能成功鼓励系统工程师改变习惯呢!
话得说回来,用过程数据进行考核作为一个激励方法是一个双刃剑,短期内可以影响行为,但长远的害处很大。其中三个明显的后果就是数据不可信,或是认证数据的成本太高;另一个问题就是可能导致项目成员之间或是部门之间的利益冲突。因为这里讨论的需求数量是一个比较单面的测量,影响第三方的风险可能不太。一个可能的影响就是不同的项目,不同的产品,不同的技术,就可能有不同的效率。如果就这样拿来对比,复杂的项目会觉得需要与简单的项目竞争,项目之间可能有一定的抵触情绪。第三个问题就是把员工的关注点从效率与质量,转移到眼前利益上面。这样长远来讲,是会妨碍员工的能力提升的。
其实不是说不可以考核,只是需要知道如何更有利地使用它。鼓励项目提高效率的测量是必要的,否则我们就看不见效率了,效率就变得不可视了,就不能够提高了。只是如果我们把不同项目的效率列出来之后,就已经是一个不错的激励。复杂的项目也不会觉得需要与简单的项目竞争。项目本身也有机会观察自身的效率发展趋势。如果领导的目标真正在于效率,通过适当地表达对质量、效率的重视,这就是足够的激励了。这就是明确了一个共同的目标:提高效率。
再回到领导的想法。领导看到员工的“不良”行为:为争取考核利益而“歪曲”了过程,把效率的数量一下子提高太多倍了。这个“不正常”。
如果我们用考核来提供导向,员工按着到导向有所反应,是最正常不过的。用考核作为导向的目的就是要他们有这样的反应。而且一般员工自然会这样反应。为什么我们还会要求员工不这样呢?如果要避免这样的结果,我们应该不用考核,而不是放弃这个测量。
如果继续使用这个效率的测量又会有什么结果呢?
短期内,效率忽然提高很多很多。然后慢慢地回稳定在一个某一个比较高的效率值。这不一定代表高效率,只是代表一个小需求粒度的结果。长远来说,需求就会写得细好多。这样有什么好处?
当系统工程师有一个把需求写得细的欲望的时候,无论这个欲望是否正当,它也不能把重要的需求漏掉的。他只可能增加一些没有这么重要的需求。但是如果这是额外的需求,这就需要有额外的工作量来实现。那么,算出来的效率值就没有这么高。其它的项目成员在评审需求的时候,是会指出这些需求是额外的,价值不大的。这样大家就可以避免做一些无用功。
这样的调整,会进行一段时间。在这个时间内,效率会有一点抖动,最后在项目找到最适合大家的需求粒度之后会稳定下来。这个粒度,代表最佳的平衡:让下游的工作明确,但没有太多的冗余的需求。在这个过程中,项目的真正效率其实不会被破坏。波动只是测量值的抖动而已。但是,这样恰恰是提高需求开发能力的途径。因为大家都关注需求在项目里的使用。当需求受到项目的重视的时候,需求的水平就会不断提高。
系统工程师也不能把需求写得无限细。需求粒度有一个限度。每一个需求一定是一个完整的概念。我们满不成把一句话硬生生地拆分开来么?需求最细的粒度,就是一个必需测试的因素。试想想,不能再细了。当然可以粗一点,把好几个需要测试的因素都放在一起。但是效率的测量定义就是一个强力的导向,让我们把需求写细一点。
所以如果我们的目标在于提高过程效能,我们就不需要关注员工为什么把需求写得太细。只要他把需求写细一点,让下游更明确需要实现的细节,整个项目的过程效率就会跟着需求水平的提高而提高。
我希望大家看到目标的不同如何影响结果。也希望大家可以看到价值观如何影响我们的目标。我们需要有正确的目标来提供正确的导向。我鼓励大家在履行每一件有意义的任务的时候,都明确一下这个任务的目标。培养目标驱动的习惯。这样会帮助大家提高自己的能力。
当然,我还是希望领导会明确鼓励用功关注质量与效率,从而提高过程效能。这样会做得更快更好。

本文出自 “过程改进论坛” 博客,请务必保留此出处http://mk6yeung.blog.51cto.com/400635/239661

分享至
更多
一键收藏,随时查看,分享好友!
0人
了这篇文章
类别:过程、管理理念技术圈()┆阅读()┆评论() ┆ 推送到技术圈返回首页

文章评论

 
2009-12-07 17:44:55
领导的出发点总是好的
但是在执行的时候就会发生偏颇
所以说一个企业成功的原因有50%是在执行力上

2009-12-08 11:57:43
走直线
就怕走不直

2009-12-12 10:59:19
读了之后我觉得两个问题。
一个是领导的目标是什么?将“需求数量/项目的工作量”这个方法叫停,本质的原因是他对员工的管理很在乎“态度”。
第二个问题算是第一个的引申吧。按规则进行管理还是按情感进行管理?这个问题我觉得比较难说平衡点。

2009-12-13 23:11:36
我认为,如果测量效率有公式,并切是“需求数量/项目的工作量”,那么需求数量和项目的工作量到底如何准确的衡量?合理的机制是否不应该由工程师来主观评估,需要客观衡量。

2009-12-16 13:37:36
对 怎么能保证主观判断是正确的?

2009-12-16 15:09:26
哥们写得很不错,有关需求这块以及领导这块的确是个需要让人深思的原因。需求的粗细程度不应该工作量方在一起,应该和具体的目标放在一起。也就是说工作量的驱动不应是领导,而是工作的具体目标。就拿组件化业务模型来说,需要反复进行需求调研,首次需求调研的粒度不应过隙,不是说领导要统计工作量就越多越好。其实在创建组件化业务模型阶段,需求调研的粒度过隙其实会让项目的进度在一定程度上减慢。
哈哈,告诉你,这可是我咨询服务项目上发生的具体事情呢。

2009-12-16 22:31:02
过程数据不可以用于考核,应该视为清规戒律。今年某单位部门员工考核有20多项,科长每月整理考核数据要花两个整天,怨声载道,值得好好反省。

 

发表评论            

【技术门诊】专家解析:软考重点难点及应试技巧
昵  称:
登录  快速注册
验证码:

请点击后输入验证码博客过2级,无需填写验证码

内  容: