职业经理人门户网站,打造专业的商务信息分享平台 手机版
erweima.png
如有投稿需求,请把文章发送到邮箱
jingliren_tougao@163.com

探究项目管理中的棘轮效应 如何解决项目管理的三大难题

关键词:领导力
发布时间: 2019-10-30 17:04

本文引入信息经济学中“棘轮效应”理论,阐明了软件管理过程中“棘轮效应”产生的原因、必要条件以及相应的对策。本文可以为项目经理制定科学的业绩评价标准提供建议。

棘轮效应(ratchet effects)一词最初来自对苏联式计划经济制度的研究。在计划体制下,企业的年度生产指标根据上年的实际生产不断调整,好的表现反而由此受到惩罚(因此,聪明的经理用隐瞒生产能力来对付计划当局)。这种标准随业绩上升的趋向被称为“棘轮效应”。其实,这种现象普遍存在于经济、管理领域,当然也存在于项目管理过程中。下面,我们主要研究一下软件项目管理过程中的棘轮效应及其对策。

产生的原因

在软件开发过程中,如何评价开发人员的业绩是一个非常棘手的问题。项目经理总是希望评价标准尽可能客观一些,因为评价标准越客观,对开发人员的努力水平的推断越准确,激励效果越明显。由于软件项目开发本身的信息不对称性,开发过程中存在着各种各样的不确定因素,项目经理对开发人员的评价标准是逐渐完善的。即通常情况下,项目经理是将开发人员过去的业绩作为评价标准,并以此制定新的工作计划。然而,开发人员的水平参差不齐,努力程度也高低不一。比如说,有一个开发人员能力水平高或努力工作,提前完成了项目经理分配给他的任务;而另一个开发人员能力水平低或工作偷懒,结果没有按时完成任务。那么,项目经理有可能认为前者的工作量小,需要提高工作量;后者的工作量大,需要减少工作量。这时,“棘轮效应”出现了:作为理性的高水平或努力工作的开发人员,是不会选择继续努力工作的,因为他们清楚,越努力项目经理评价他的业绩标准越高,自身利益损失越大。

产生的三个必要条件

下面我们简要描述一下“棘轮效应”产生的三个必要条件。

第一,项目经理和开发人员的合作具有长期性。在临时性的小型软件项目组中,由于开发周期很短,工作量小,开发人员的努力程度或水平差异没有明显的区别,项目经理也没有开发人员过去的业绩作为参考来评价其现在的业绩。或者在大型软件项目中,由于不同的技术支持需要,项目组常常从不同部门借调人员加入(完成工作后借调人员回原部门)。这部分人员具有很大的流动性,他们过去的业绩也不为项目经理所了解。在类似的情形下,“棘轮效应”是不会发生的。

第二,项目经理和开发人员之间存在着信息不对称。“棘轮效应”发生的关键在于项目经理对如何看待开发人员的业绩,缺乏一个客观的评价标准。造成这种现象的原因关键又在于双方之间的信息不对称。项目经理想建立一个客观的评价业绩标准,但他不知道开发人员各自的真实水平和努力程度;项目组成员清楚自身的能力和努力状况,但很难让项目经理相信他所拥有的能力水平和努力程度是所有成员中最大的(因为项目经理倾向于相信自己的评价标准是客观公正的)。

第三,开发人员是“理性人”。所谓“理性人”,是指能充分理解自身利益所在,并能采取正确对策去最大化谋取自身利益的人。如果“理性人”的假设不成立,软件开发人员即使知道努力工作的后果是项目经理提高其业绩评价标准,他仍然会继续努力工作。此时,不存在“棘轮效应”。

相应的对策

1.工时研究与标准化

我们可以在这里引入泰罗的科学管理理论——工时研究与标准化。它不是简单地对每位开发人员完成一项任务作出时间上的统计,而是把一项任务分解成各种基本的步骤,并作测试,然后根据其合理性,重新进行安排,以寻求最佳开发方式。采用工时研究的好处是,通过任务的分解,去掉无用的步骤,可以对高水平的开发人员在软件开发过程中的每一个基本步骤进行观察,并记录下完成每个步骤所需的时间。在所记录的时间上,再加上不可避免的耽搁和停顿所需的百分比,所得到的时间就是完成这个基本步骤的标准时间。项目经理可以以此作为评价开发人员业绩的标准。有了这个标准,开发人员就不用担心自己的努力得不到承认,“棘轮效应”也就不会发生了。当然,由于软件开发本身所固有的特性,这个标准不可能是精确的,开发工具的选取、开发环境的好坏、业务需求的清晰与否、软件质量的高低,等等,都可能改变标准时间的结果。

2.加强项目经理与开发人员的沟通

加强项目经理与开发人员的沟通是克服两者之间信息不对称的重要途径。在缺乏信息的情况下,任何高明的项目经理都难以客观评价开发人员的业绩。我们建议,除了在开发实践中自发的交流,项目经理还应有意识地抽取一定时间,召集开发人员进行沟通,了解开发过程中的问题,制定下一步开发计划;开发人员应严格按照软件工程的要求,详细记录自己所做的每一步工作,实现开发过程文档化,并提交项目经理,使其能清楚地了解自己所做的工作。在沟通过程中应该注意:提高沟通的效率,只沟通必要的信息;排除个人之间的成见;改善沟通环境,避免外界环境的干扰;沟通之后,对沟通进行追踪,了解执行情况。

3.建立长期的合作关系

虽然项目经理和开发人员之间长期合作关系是“棘轮效应”产生的必要条件之一,但这种长期关系发展到一定阶段就能弱化“棘轮效应”。在长期合作关系下,项目经理和开发人员都有足够的耐心来实现自己的利益最大化。一方面,根据大数定理,开发过程中的外生不确定性可以剔除,项目经理可以相对准确地从观测到的信息中推断开发人员的努力水平和能力高低,开发人员不可能用偷懒的办法提高自己的利益;另一方面,长期合作关系以保险的方式克服了项目经理和开发人员双方的风险,通过长期的合作,双方了解加深,项目经理不会坚持给努力工作或高水平的开发人员制定高标准(这样会打击他们的积极性);而工作偷懒或低水平的开发人员也不可能永远滥竽充数。因此,在长期合作的项目组中,初期可能存在“棘轮效应”,但随着时间的推移,“棘轮效应”将逐渐淡出。

4.采取有效的激励方法

消除“棘轮效应”的另一个途径是采取有效的激励方法,让所有开发人员都有积极性努力工作。莱瑟尔(Lazear,1979)证明,在长期的合作关系中,“工龄工资”制度可以遏制员工的偷懒行为。直观地讲,在工作的早期阶段支付的工资低于边际生产率,二者的差额等于一种“保证金”;当被发现偷懒时,偷懒者被开除,损失了保证金;因此,偷懒的成本增加,努力工作的积极性提高。当一个项目中所有的开发人员都努力工作时,所作出的成果分别反应了他们的真实状况,项目经理也比较容易从获得的这些信息中制定业绩评价标准。

5.引入相对业绩比较

另一个办法是使用他人的业绩,使开发人员业绩评价标准的建立不仅依赖于自己而且依赖于其他开发人员的业绩。即引入“相对业绩比较”。通过比较开发人员相互之间的业绩,反应出一定程度的各自努力水平,为制定相应的业绩评价标准提供依据。注意,“相对业绩比较”只适用于开发人员业绩相关的情况,此时它可以剔除更多的不确定因素从而使项目经理对开发人员努力水平的判断更为准确,既降低风险成本,又强化激励机制。在开发人员的业绩不相关时,参考价值不大,容易诱发项目经理的错误判断。

6.确保充足的统计量作为参考

在建立客观的业绩评价标准时,保证充足的统计量作为参考是一个很重要的因素,它直接影响到标准的准确性。

数据的主要来源应该是在软件开发过程中一点一滴的积累,而不是为制定标准临时杜撰的;其次也可以来自项目经理与开发人员之间的讨论总结;以及借鉴其他类似项目的历史数据。做好统计的关键在于开发人员要有良好的软件工程意识,理解做数据统计的意义;项目经理要鼓励并时刻督促开发人员完成这项工作,同时加强检查。

7.强调项目的整体利益

前面我们所提到的对策,都是从“理性人”的角度考虑的。现实中,人还有“道德”的一面,即所谓“道德人”。“道德人”是把项目的整体利益放在第一位的,即使明知努力工作会导致业绩评价标准提高的后果,只要对项目整体利益有益,他仍然会努力工作。因此,在一个软件项目开发过程中,项目经理要注重培养开发人员的团队意识,要树立整体利益高于一切的思想。如果所有的开发人员都是“道德人”,每个人都自觉努力工作,显然会是一个双赢的局面,不存在“棘轮效应”。

小结

上面,我们把研究重点放在项目经理与开发人员之间的“棘轮效应”。在软件开发中,项目需求方与项目承包方、部门主管与项目经理、项目经理与软件维护人员等等,都存在着“棘轮效应”。我们应该根据软件开发中各个领域的特点,研究出相应地管理方法,弱化“棘轮效应”。我们前面所提到的七点对策,具有普遍的借鉴意义。

作为老板我当然希望开店速度又快,成本又低,营业额还高;可是鱼与熊掌很难兼得,公司负责执行的经理必须知所取舍。“要马儿好,又要马儿不吃草”,这句话不知是谁发明的;发明这句话的人,想来是项目管理的高手。为什么呢?因为项目管理的精义,就是又要马儿好,又要马儿不吃草。

一个成功的项目,通常有三个要素:时间的要素──完成的时间要快;成本的要素──完成的成本要便宜;效果的要素──完成后的表现要好。这三个彼此互斥的要素,就像一个等边三角形的三边一样,缺了一边,或任何一边比其它两面边短,我们就不能再称这个三角形为等边三角形了。

在我的经验中,如果在这三个要素中只要做到一项的话,这种项目好做,百分之八、九十以上的经理大概都可以胜任愉快。如果在三个要素中要做到两项,就不是一般的经理能胜任的了。在比例上,我认为能把以上三个要素中的任何两项做到的经理,大概不会超过百分之五十。真正能够把项目中三个主要需求都能做到的高手,在一百位经理中,最多不到十个。 有人听我这么说也许会不服气,认为我有些危言耸听,他们不了解我的本意。我的本意只有两点: 第一、项目成功的要素,彼此之间是鱼与熊掌的关系。第二、要兼顾的难度,是照几何级数上升而不是按算术级数上升。这样一个三角难题,要我们怎么去解呢?我认为应该从两方面去着手。

1. 我如果是个项目经理,一定要问:什么是好?什么是快?什么是便宜?在项目管理中,好就是好,不好就是不好,这没有什么主观或客观的差异,也没有什么明示或暗示的问题存在。要谈到项目管理中好的定义,第一个条件就是要看它是不是有用。有用和能用是两回事。很多能用的东西不一定有用,这牵涉到客观价值的问题。我有一只瑞士名表,是属于那种很贵,很多仿制品那种。因为要动,它才会上链,不动它,隔一阵就停了。我后来不胜其烦,换了一个电子表,价钱只有那只瑞士表的几十分之一,不但不用上链,打球、洗澡也懒得把它脱掉,并且是夜明的。你说这两个表那个比较好?我可以很坦白地告诉你,因为后者比较有用,后者比较好。因此,在项目管理上,关于好的定义,是有用而非能用。

2. 好的第二个条件,要看它是不是能达到原先要达到的目的。 如果说目的是代步,汽车比脚踏车好;如果说目的是运动,脚踏车却比汽车好。在日常生活中,有人叫你去买苹果,结果你买了橘子回来 。苹果和橘子虽然不是一样,但也许还勉强可以混过去。在项目管理上,如果要的是苹果,交货的时候却变成了橘子,这就不能算是一个成功的项目。为了避免这种错误,项目经理必须在项目设计时把项目结果的规格先弄清楚。口说无凭,要的东西都要写下来。交货的时候 ,如果我交给你的是规格上写明的东西,那我就算给你一个好东西。从项目管理「好」的 定义来看,简单、好用的东西,就是「好」的东西。

3. 好的第三个条件,除了有用和好用之外,还要具有可塑性和可扩展的弹性。前者表示它的功能,在必要时可以加以改变。后者表示在时间上,它不但可以持久并能扩展。扩充性比可塑性更重要。如果说一套计算机实用软件的设计,在开发完成上线不久,就不能满足公司业务上的新需要的话,设计这套系统的项目还够格称为一个好项目吗?当然,未来的需要也许不是目前能预料的,为了不可预测的将来而牺牲了现在的需要当然不对,但无论如何,一个好的项目,它所设计的产品必须具有容易修改,可以扩充,并且不会马上就失效的弹性。缺乏有这种弹性的产品,就不是一个好的产品。 一个生产没有弹性产品的项目,就不能算是一个好的项目。

以上就是我的一些经验,希望博策堂和四方易联的管理者们作为2007年执行集团战略目标时的参考,尤其在客户开发,人员选用,开店选址和开店速度上,应该有其借鉴意义。