项目管理中“棘轮效应”应对策略

《项目管理中“棘轮效应”应对策略》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、项目管理中“棘轮效应”应对策略一、前言A公司是一家纯软件开发型公司，开发人员及项目管理人员有过两年多的共事经历，对各自的能力水平、工作之余爱好及平时工作投入努力程度都彼此较了解。在实际分配任务时，项目经理相对平均分配，并且项目经理在切割任务时优先熟悉者（以前曾经接触过、或有实际参与过的项目）,再将剩余任务分配给其他组员，以求公平、公正。但问题由此产生：开发任务往往不能按期完成。这就是常说的项目管理中的瞬轮效应”。所谓缚朿轮效应”是指在计划体制下，企业的年度生产指标根据上年的实际生产不断调整，好的表现反而由此受到惩罚。这种标准随业绩上升的趋向被称为缚朿轮效应”。这种现象

2、同时存在于项目管理过程中。本文浅谈了笔者在实际管理过程中遇到的瞬轮效应”及其对策。二、问题分析（一）公平公正的前提在法律上的“公平”是指保障法律面前人人平等和机会均等,避免歧视对待。“公正”是指维护正义和中立，防止徇私目程序开发人员“等同工作量”往往被认为是公平公正的前提。即项目经理在分割任务时，一般以等同工作量为划分的基础，他的逻辑前提是每个程序员具有“同质性”和“可替换性”，即对项目的熟悉程度、理解程度、个人能力及努力程度是一致的。舞弊，是作为公开的补充。在项目管理过程中，保证每个项（二）人力资源利用最大化的误区在项目管理中，项目经理往往有两种倾向，一是将关键技术

3、人员用在最难问题的解决上；二是对项目成员的评价有“定势”的趋向，做完一个项目后对项目成员的评价，经常带到以后的项目管理中去。这看上去没有什么不对的地方，项目经理认为人力资源必须最大化利用，但他的最大化是一维函数，是简单地叠加。实际上人力资源利用的最大化是一个多维函数，涉及到项目难易程度、进度，程序员个人能力、努力程度、环境因素、激励、项目组文化、领导力等等因素，并且每个参数在不同的项目有不同的权重，是一个非常复杂的数学模型。（三）开发人员都是丫型人所谓丫型人，是指给予人们恰当的期望和激励，他们总是会最努力地工作。项目经理在相互熟悉的环境下，经常以所谓“公平、公正”的原

4、则来等量分割开发计划。并且都以个人的感情和相互信任为前提作为激励的方法，认为他们是会努力工作的。但在实际管理中，项目经理经常“碍于相当熟悉的面子”,而忽视小问题的解决，进而影响了整个开发进度。三、相应的对策(-)建立“公平公正”的有效手段k工时标准化及权重分配。我们可以对项目进行WBS分解，得到各个“工作包”,并对各个工作包进行难度测评，把工作包按进度、难易程度、工作环境、个人能力、激励程度五个因素进行权重分配，然后根据其合理性，重新进行安排，以寻求最佳开发方式。以排除简单地对每位开发人员完成一项任务做出时间上的统计。通过WBS任务的分解，去掉无用的步骤，并进行权重分

5、配，可以对开发人员在软件开发过程中的每一个基本步骤进行观察，并记录下完成每个步骤所需的时间。项目经理可以以此作为评价开发人员业绩的标准。有了这个标准，开发人员就不用担心自己的努力得不到承认，“棘轮效应”也就不会发生了。当然，由于软件开发本身所固有的特性，这个标准不可能是精确的，开发工具的选取、开发环境的好坏、业务需求的清晰与否、软件质量的高低，等等，都可能改变标准时间的结果。2、引入相对业绩比较。另一个办法是使用他人的业绩，使开发人员业绩评价标准的建立不仅依赖于自己而且依赖于其他开发人员的业绩。即引入“相对业绩比较”。通过比较开发人员相互之间的业绩，反应岀一定程度的各

6、自努力水平，为制定相应的业绩评价标准提供依据。注意，“相对业绩比较”只适用于开发人员业绩相关的情况，此时它可以剔除更多的不确定因素从而使项目经理对开发人员努力水平的判断更为准确，既降低风险成本，又强化激励机制。在开发人员的业绩不相关时，参考价值不大，容易诱发项目经理的错误判断。3、确保充足的统计量作为参考。在建立客观的业绩评价标准时，保证充足的统计量作为参考是一个很重要的因素，它直接影响到标准的准确性。数据的主要来源应该是在软件开发过程中一点一滴的积累，而不是为制定标准临时杜撰的；其次也可以来自项目经理与开发人员之间的讨论总结；以及借鉴其他类似项目的历史数据。做好统计

7、的关键在于开发人员要有良好的软件工程意识，理解做数据统计的意义；项目经理要鼓励并时刻督促开发人员完成这项工作，同时加强检查。（二）提高人力资源效率避免棘轮效应的产生K加强项目经理与开发人员的沟通。项目经理所依据的能力强的人应该解决更多问题或承担更多的开发任务。一旦能力强的开发人员在发现没有任何好处时，久而久之“棘轮效应”就开始作用了。沟通在一定程度上可以避免“棘轮效应”的作用。加强项目经理与开发人员的沟通是克服两者之间信息不对称的重要途径。在缺乏信息的情况下，任何高明的项目经理都难以客观评价开发人员的业绩。我们建议，除了在开发实践中自发的交流，项目经