非对称信息下软件企业开发团队激励机制研究

肖志良

【摘要】 软件开发是一项非常专业的技术，软件企业的经营管理者与软件项目开发团队之间往往存在严重的信息不对称，两者实际上是非对称信息下的委托人和代理人关系。本文以委托代理理论为研究基础，探索软件企业在承接软件外包项目管理中的员工激励机制设计问题，旨在建立一套既保障企业利益最大化、又充分调动开发团队积极性的激励机制，促进软件企业人才队伍的稳定。

【关键词】 非对称信息 软件企业 开发团队 激励机制

一、理论基础及研究背景

1.1 非对称信息下的委托代理理论

不完全信息和非对称信息是信息经济学中的两个重要概念，也是客观经济活动中普遍存在的现象。在现实的经济环境中，不可能存在完全信息，正因为不完全信息的普遍存在，才衍生出五彩斑斓的各种经济行为。同时，不完全信息往往体现为信息不对称性，非对称信息的普遍存在正是人们经济活动博弈的基础和根源。非对称信息源于社会分工的细化和私人信息的存在，由于信息不对称，拥有信息优势的一方有可能采取欺诈手段，来为自己谋取私利，这种行为往往损害对方或公众利益。

因此，非对称信息的存在使要素市场很难以一种最有效的方式来配置，导致资源配置偏离最优状态，严重时还会导致市场失灵。

委托人-代理人理论正是在非对称信息的认识基础上发展起来的，经济学上的委托-代理关系泛指任何一种涉及非对称信息的交易，非对称信息的存在使得市场中必然存在信息优势方和信息劣势方，通常称信息优势方为代理人，而信息劣势方为委托人。形成委托-代理关系有两个基本条件，一是市场交易中存在两个或两个以上相互独立的行为主体，他们在一定约束条件下各自追求效用最大化；二是市场交易的参与者均面临不确定性风险，而他们掌握的信息处于非对称状态。

研究委托-代理理论的一个重要目的就是建立一套科学的激励机制或政策制度，迫使代理人采取最优行动，防止道德风险的发生。

有效的激励机制的设计必须遵循两个原则：

一是参与约束，即代理人履行委托代理合同后所获收益不能低于其在等成本约束条件下从其他委托人处获得的收益水平；

二是激励相容约束，即代理人获得其自身预期效用最大化的同时，必须保证使委托人的预期收益最大化。

1.2 研究背景

二十一世纪是人才竞争的时代，作为信息产业的主要组成部分，软件行业尤其如此。软件企业对人才的需求是十分敏感的，主要有三方面原因：

一是软件开发是一项专业性很强、逻辑性非常严密的工作，软件开发技术、开发工具的更新换代也十分频繁，软件开发人员除了需要具备专业知识外，还需要终身学习和历练，培养一个成熟的软件人才绝非易事；

二是应用软件解决方案所涉及的领域十分广泛，软件企业往往长期致力于解决某一领域的应用问题，从而使得自己的开发团队成为这一领域的解决方案专家，如果开发团队成员流失，对企业来说是致命的；

三是软件系统具有长期性、延续性和周期性，软件系统的运行、维护、需求变更和系统升级都需要稳定的技术团队。

一项针对某软件产业园58家企业的调查问卷显示，51家企业的总经理最头疼的问题是人才的问题，43家企业曾因为技术人员流失而给公司造成被动局面，17家企业因核心员工辞职而不得不放弃原来的业务领域，另有3家企业因业务单一、骨干成员辞职而面临倒闭。在对这58家企业开发的203个软件项目调查中发现，因人才流失而导致项目不能及时交付的有63项。

为什么软件企业会成为人才流动的重灾区呢？究其原因主要有四个方面：

一是软件企业一般集中在统一的园区内，技术人员之间交流十分频繁，工资、待遇、企业文化、工作环境的攀比成为常态，催生了不稳定因素；

二是软件技术人才往往比较年轻，思维活跃，大多属于风险偏好者，好动求变心态严重；

三是软件企业的核心资产表面上是软件著作权，实际上是装在技术人员脑子里的解决方案，人才流动的同时本质上也是核心资产的流动，因此有经验的软件技术人才再就业相对容易；

四是因为企业经营者和开发团队之间的严重非对称信息而导致的激励机制难于设计，导致技术团队主观积极性不高，企业缺乏吸引力。

问题的核心还是激励机制的设计，前述的针对58家软件企业的调查显示，31家企业没有建立针对研发团队的激励机制，完全按固定工资和奖金发放员工报酬；8家企业建立了奖金与公司业绩挂钩的机制，但都是对全体员工而言，对开发团队没有单独的特别激励机制；在27家建立有研发团队激励机制的企业中，90%以上都是简单地根据项目的毛利按一定固定比例提成，没有建立科学的动态分配激励机制。由此可见，软件企业对研发团队的激励机制要不严重缺失，要不实行一刀切，这是造成企业人才流失的重要原因。事实上，开发团队是软件企业的核心资源，建立针对开发团队的科学有效的激励机制具有十分必要的迫切性和重要的现实意义。

二、软件企业开发团队激励机制模型

2.1软件企业项目开发过程中的非对称信息特征

软件企业的开发项目通常分为两类，一类是自行设计开发的软件产品，这类产品一般具有通用性和较强的可配置性，面向的应用领域较为广泛，比如工具型、常规管理型软件，企业在开发这类项目时往往对收益不能准确预期，也就是销售额是个变量；另一类是为甲方量身定做的软件项目，这类产品通过开发合同来约束，企业的总收益是一定的，但成本是变量，因此企业的实际利润也是变量。以上两类业务模式首先都需要开发团队来完成系统开发任务，企业实际上就是委托人，而开发团队便是代理人。由于软件开发是一项非常专业的技术，加上开发团队的成员存在个体差异，因此委托人与代理人之间存在严重非对称信息，这种非对称信息导致委托人很难观察和测量代理人的行为选择，从而无法确保企业（委托人）的效用最大化，甚至无法保障软件开发的进度和质量。

软件企业这种内部委托代理关系的非对称信息主要有以下几个特征：

⑴ 技术非对称性。

对于一个软件项目，企业经营者往往只关注项目的收益、成果、质量、成本、开发周期、市场、价格等商业性要素，而对项目所采用的体系架构、技术路线、实现方式、开发环境、数据结构、运行环境等技术性要素却知之甚少，而这些技术性要素正是开发团队所熟知和重点关注的内容，这就是企业管理层与开发团队之间的技术信息非对称性。技术信息非对称性导致企业管理层很难评价开发团队的成果，很难观察开发团队所选择的技术模式是否能最大限度地保障产品质量和产品生命力。企业管理层往往是通过项目交付后由客户反馈的评价信息，这些评价信息通常是滞后的、非系统性的、非本质性的。尽管软件产品在交付前需要通过测试工序，但测试人员本身就是开发团队的组成部分，如果企业委托第三方专业机构测试，除增加成本外，目前的测试流程也是根据开发团队提供的功能清单来进行，并不涉及软件产品的核心技术。因此，技术信息非对称性是企业定量设计激励制度的重要障碍之一。

⑵ 行为非对称性。

软件开发人员工作状态的外部呈现形式非常单一，就是安静地坐在电脑前编写代码、设计数据库、编写技术文档等，企业管理者很难观察开发人员的努力程度、工作效率、工作质量，传统的计时、计件办法派不上用场，如果以代码量来度量开发人员的工作量，很容易导致道德风险的发生，完成同样的功能节点也许只需要10行代码，但技术人员同样可以编写100行代码来完成，而且会导致软件运行效率降低。不同开发工具完成同一功能的代码量也有很大区别。

⑶ 产品非对称性。

软件项目开发完成后形成了软件产品，关于软件产品的信息，开发团队是最清楚的，企业管理者或者用户都只是了解产品的可观察的外在信息，双方存在着非对称信息。企业管理者与开发团队之间也存在公共知识，也就是说，企业管理者知道开发团队对软件产品信息了如指掌，开发团队也知道企业管理者知道自己对软件产品信息非常了解，这一高次信息与“软件质量”这一低次信息同样重要。因此，开发团队对软件产品的信息优势可能实际上变成设计激励机制的障碍。

2.2 软件企业开发团队激励机制的概念模型

激励机制的设计就是制定一定的规则，使代理人在实现自身效用最大化的同时，达到委托人规定或希望达到的具体价值标准或社会目标。也就是使代理人从自身效用最大化出发的同时，自愿或被迫选择与委托人标准或目标相一致的行动。因此激励机制的核心就是，委托人怎样使代理人按照委托人的意志或行动。

在企业与员工之间，委托-代理合同的核心内容实际上就是工资、奖金、股权或提成，因此激励机制的设计就是报酬给予方式的选择。有效的激励机制必须让代理人所得报酬与其工作成果相关，激励机制设计的关键在于这种相关性的确定。

软件企业与开发团队之间实际上是一种非对称信息下的委托-代理关系，考虑到软件企业与开发团队的风险偏好，软件企业在承接软件外包项目的业务模式下，最优激励机制应该是“底薪+项目开发提成”，约束条件是项目进度和质量。对软件开发人员，企业设置底薪是十分必要的，因为企业不能确保开发团队什么时候都有开发的任务，也不能确保软件项目的难度都是一致的。

通常底薪必须保障员工的基本生活、基本福利以及基本社会保险，底薪与企业所处的地区的消费水平要相适应。“项目开发提成”是激励机制设计的核心要素，提成低于开发团队劳动的边际成本，将无法有效激励开发人员的努力，提成高于开发团队劳动的边际成本，委托人（企业）将减少自身的实际收益，寻找这个平衡点就是设计激励机制的核心内容和任务。

首先设计一个基本模型，假设企业承接了一个软件外包项目，项目总金额为W，开发团队每月底薪总和为U，项目实际开发周期为m个月，显然m与开发团队的努力程度有关，令x为开发团队付出的努力，则开发周期可表示为m=M（x）。虽然m并不由x唯一决定，但与x高度负相关，即开发团队越努力，开发周期越短，也就是说m=M（x）为减函数。

令s为企业付给开发团队的开发提成，为激励开发团队努力工作，应将开发提成与团队的努力程度相关联，即s=S（x），也就是说，团队越努力，提成就越高，但团队努力的边际成本也随之增大。令y为企业的实际收益，显然，企业实际收益为y=W-U·M（x）-S（x），此时开发团队的实际收益为U·M（x）+S（x）。

由于开发总金额一定，只有缩短开发周期才能使得企业实际收益y最大化，因此y与m是负相关，但缩短开发周期也不是无止境的，是以团队努力程度作为条件的，努力程度越高，边际成本越大，企业付给开发团队的提成也越高，这样反而降低了企业的实际收益。

2.2.1 相关变量和函数描述

⑴ 抽象变量x

M（x）和S（x）都存在一个公共的自变量x，其含义是团队的努力程度，是一个抽象的概念，根据软件开发工作的特点，我们将努力程度定义为：在确保开发质量的前提下的工作效率，开发质量可以用单位功能点的BUG数来测量，工作效率可用单位时间完成的功能点数量或者单位时间完成的代码量来测量，这样努力程度就可以测量了。为研究方便，我们在概念模型中仍然以抽象变量x表示。

⑵ 开发周期函数M（x）和产出函数P（x）

m= M（x）是开发周期函数，努力程度x越大，开发周期m越小，但当努力程度不断增大时，比如加班时间无止境增加，开发人员的效率会降低，同时，随着努力程度x越来越大，开发质量也会下降，代码中BUG也越多，软件的测试和修改的工作量会增加，反而会增大开发周期。因此m= M（x）是一个非线性的减函数。

函数的图形如下：

图1说明了随着努力程度增大，曲线越来越平坦，也就是开发周期缩短效应越来越不显著了。由于软件项目的金额W是一定的，开发周期的缩短降低了企业支付给团队的底薪，这就是团队努力的产出。

令p=P（x）为团队的产出，则P（x）=W-U·M（x），P（x）的函数曲线如图2所示：

⑶ 提成函数S（x）和成本函数C（x）

s = S（x）是企业付给团队的提成函数，显然，团队越努力，提成就越高，另一方面，努力程度越高，团队的边际成本也越高，同样团队的效率会随着努力程度的提高而下降，加上受到项目总金额W的限制，企业不可能按照简单的线性规则给团队提成。因此，一方面团队会将获得的提成与付出努力的成本作比较，令c=C（x）为团队的成本，只有当S（x）≥C（x）时，团队才愿意接受这项开发任务，这就是“参与约束”；另一方面，企业愿意付给团队的提成S（x）也不会随着努力程度x的增加而按照C（x）的增大而增加，增加的幅度会显著下降，曲线会越平坦。由此可见，起初S（x）是大于或等于C（x）的，这是团队愿意接受任务的条件，随着x的增大，努力的成本C（x）的增速（切线的斜率）会增大，而企业愿意支付的成本S（x）的增速（切线的斜率）会放缓，最终变成水平线，代表企业不再愿意增加提成了。S（x）和C（x）的曲线如图3所示：

上图中S（x）和C（x）有一个交叉点x1，代表团队努力的成本等于团队所获得的提成，当x≥x1时， C（x） ≥S（x），这时团队将不会接受工作；当x≤x1时， S（x）≥C（x），这时团队将愿意接受工作。

2.2.2 企业与开发团队效用最大化

企业的目标是使得自己利润最大化，即y=W-U·M（x）-S（x）最大化。图4绘出了P（X）、C（x）、S（x）三条曲线，我们知道，企业的实际利润为P（X）-S（x），所以企业的利润最大化就出现在P（X）和S（x）两条曲线之间的垂直距离最大的时候，此时两条曲线的斜率相同，x*就是企业希望开发团队付出的努力。而开发团队的效用函数为S（x）- C（x），效用最大会出现在S（x）和 C（x）两条曲线之间的垂直距离最大的时候，此时两条曲线的斜率相同，因此x**是开发团队希望付出的努力。激励机制设计的本质就是使得x*无限趋向于x**，当x*=x**时，便达到了“激励相容约束”，也就是我们平时说的“双赢”。在现实的经济活动中，为达到x*无限趋向于x**的目的，企业需要采取的措施有很多，比如设定合理的开发周期、平稳化提成的增速等等。

以上针对软件企业开发团队激励机制的概念模型是根据“参与约束”和“激励相容约束”两个原则而设计的，企业和开发团队之间的约束是相互的，这样在很大程度上避免了因非对称信息而可能造成的道德风险。

三、软件企业开发团队激励机制的设计实务

尽管上一节分析并建立了软件企业开发团队的激励机制的概念模型，但对于究竟如何设计激励机制还需做许多实务性的工作。

以下从软件企业承担软件外包工程的业务模式出发，探讨具体激励机制的设计问题。在具体探讨问题之前，首先要解决几个变量的测量问题。

3.1 有关变量的测量

⑴ 努力程度的测量（x）

努力程度是一个抽象的概念，根据软件开发工作的特点，我们可以将努力程度定义为：在确保开发质量的前提下的工作效率。开发质量可以用单位功能点的BUG数来测量，记为e；工作效率可用单位时间完成的功能点数量或者单位时间完成的代码量来测量，记为v，这样努力程度就可以测量了。显然，x是e和v的函数，e越小、v越大，x也越大。为研究方便，我们将e设为限制条件，仅用v来测量努力程度。但由于开发团队的技能差异和人数不同，x也不能直接用v来表示，为使研究具有通用性，我们设定x的取值范围为0～100，正常效率工作时（比如8小时上班，不偷懒、不加班）x取值为50，这时团队单位时间内完成的功能点记为Es。 x<50时，团队偷懒，x>50时，团队超出正常效率，当x=100时团队达到极限努力，这时单位时间内完成的功能点数为2Es。

比如某企业的开发团队有10人，企业通过长期测试这个团队的业务能力，发现团队正常效率工作时每月能完成300个功能点的开发，即Es=300，这时x=50。因此我们可以用下列表达式来测量团队的努力程度：

其中v表示团队单位时间完成的功能点数量，Es为团队正常效率时单位时间可以完成的功能点数，x为实际的努力程度。显然，Es是一个参照标准，与团队的人员技能水平密切相关。一般来说，企业要掌握自己团队的Es并不难，可以通过长期的测试来得出结论。

从（3-1）式中可知，当v大于2Es时，x会大于100，这种情况一般违背常理，也不提倡，因为人的劳动是有极限的。最大努力程度定位为“完成正常效率时的两倍工作量”是有依据的，也是作者根据长期的实践得出的结论。

⑵ 开发周期的测量（M（x））

企业承接一项软件项目后，需要确定开发周期。项目的甲方一般都有交付期的要求，这是一个限制条件，实际的开发周期要小于或等于交付期。企业在承接项目之前，要根据项目的需求分析比较准确地测算工作量，也就是确定功能点的数量，然后根据自己开发团队的工作能力（也就是Es）计算实际的开发周期。如果根据Es计算的开发周期大于交付期，说明企业必须扩大开发团队的人数或者激励现有开发团队增大努力程度。

显然，实际开发周期是团队努力程度的函数，即m=M（x）。从上一章的研究得知，开发周期是随着努力程度的增加而递减的，但不是简单的线性关系，笔者根据多年的实践数据观察得出，m=M（x）近似地服从双曲线的分布规律。因此，根据图2-1的曲线，我们可以近似地定义开发周期函数的表达式为：

问题是参数K如何确定，由于x是从1～100的代表努力程度的概念数据，因此需要换算。假设某个软件项目有E个功能点，开发团队的正常工作效率为每月完成Es个功能点，我们知道团队在某种努力程度x下每月能完成的功能点为v，那么开发周期（也就是需要的开发月数）为：

⑶ 努力成本的测量（C（x））

团队努力成本是指团队为完成任务而花费的金钱、时间、脑力和体力等，同样是个抽象变量，它与成员的技能、工作环境、开发条件、地区生活成本都有关系。由于影响因素关系复杂，这里用当地同类职业平均工薪水平来处理，这种处理方法很具有代表性，根据笔者的经验，团队员工比较愿意接受。

首先根据团队成员的技术级别（如程序员、高级程序员、系统分析师等），分别套取本地区同类级别的软件开发人员的平均收入，将团队全部人员的收入求和，以此作为团队在正常工作效率下的标准收入，记为Bs。

从上一章分析得知，努力的成本函数近似于抛物线，所以我们用下列表达式代表成本函数：

3.2 激励机制实例分析

假设某企业承接了一项软件外包项目，总金额为W=100万元，甲方要求交付期为5个月。根据需求分析，该项目的功能点为1000个，企业决定组成10人的开发团队，企业支付给每人每月的底薪为5000元，团队的月底薪为10×5000=50000元，即5万元。

这支10人的开发团队正常工作效率下每月能完成200个，根据当地的同类职业的工资平均水平，团队正常工作效率下完成项目任务应该获得5万元的提成。那么，企业应该支付团队多少提成才能使得团队愉快接受任务并努力工作，而企业的收益又最大呢？

从以上实例得知的已知条件为：项目总金额W=100，团队底薪U=5，项目功能点E=1000，团队标准开发效率Es=200，团队正常效率下的努力成本Bs=5。

由于效用函数y是一条由双曲线和抛物线组成的混合曲线，不能通过求导数的方法求得极值，因为那时的x取值范围会远远超出100的最大取值点，而且也没有任何经济学上的现实意义。

因此，我们利用Excel来测算y的局部极值。由于项目甲方要求5个月交付期，根据团队的正常工作效率Es=200和项目的功能点E=1000得知，团队正常工作效率正好可以按期交付项目，因此该项目团队努力程度必须达到x≥50的要求。

下表是不同努力程度企业的实际收益和团队收益：

从上表的测算结果可以得知：

① 企业的最大收益出现在团队努力程度为68时，即x*=68，这时企业实际收益为72.37万元。那么团队的效用最大点x**会出现在哪里呢？由于上表中的总提成S（x）是按照努力成本C（x）来近似计算的，在起初阶段，企业会同意根据团队的努力程度的提高来增加提成，但随着x的增大，企业会放慢提成增加的速度，直到不再愿意增加。从上表中我们发现，当x>80时，企业的收益下降明显了，因此企业将不会希望团队采取x>80的行动了，而这时团队的月平均收益为最大，因此 可以近似地确定x**=80。

② 团队的总收益呈现两头大、中间小的分布，表面上团队不愿采取x=68的行动，但实际上团队是乐意接受的。原因有两方面，一方面如果团队采取的行动越趋向50，团队月平均收益反而会下降；另一方面如果团队采取的行动越趋向100，似乎总收益和月平均收益都会增加，但付出努力的边际成本上升更快，很可能会导致C（x）>S（x），这意味着繁重的加班和体力脑力消耗，使得团队不愿接受任务。

③ 苛刻的企业老板会希望团队选择x*=68的努力程度，这时需要支付给团队的总提成为9.248万元；而聪明和宽容的老板会让团队选择x=75至x=80之间的努力程度，因为这时企业收益下降的速度远远低于团队月平均收益增长的速度，有利于激发团队。

④ 一旦企业确定愿意支付团队的提成的额度，团队应该根据上表确定开发周期，进而确定单位时间内需要完成的功能点数，并分解任务到各成员，以确保完成任务。比如，企业愿意按照x=75的团队努力程度支付报酬，这时开发周期要求是3.333个月，团队必须每月完成1000/3.333=300个功能点的开发任务。

企业也可根据团队实际完成任务的开发周期来修正实际支付给团队的报酬。

参 考 文 献

[1] 马费成. 信息经济学. 武汉大学出版社，2012.

[2] 查先进. 信息经济学. 清华大学出版社，2007.

[3] 晁亮. IT项目风险管理理论与实践[D]. 华东师范大学，2005.

[4] 陈钊. 信息与激励经济学. 上海三联书店、上海人民出版社，2005.

[5] 韩金荣. IT项目投资中的成本效益分析[D]. 中国海洋大学，2004.

[6] 何亚琼，李一军，黄梯云. 信息产业成长的动力机制研究. 决策借鉴，2000，13（2）.

[7] 李刚. 不确定性风险与信息约束. 情报理论与实践，1998，21（1）.