非對稱信息下軟件企業開發團隊激勵機制研究

肖志良

【摘要】 軟件開發是一項非常專業的技術，軟件企業的經營管理者與軟件項目開發團隊之間往往存在嚴重的信息不對稱，兩者實際上是非對稱信息下的委托人和代理人關系。本文以委托代理理論為研究基礎，探索軟件企業在承接軟件外包項目管理中的員工激勵機制設計問題，旨在建立一套既保障企業利益最大化、又充分調動開發團隊積極性的激勵機制，促進軟件企業人才隊伍的穩定。

【關鍵詞】 非對稱信息 軟件企業 開發團隊 激勵機制

一、理論基礎及研究背景

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）.