肖志良

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

【關(guān)鍵詞】 非對稱信息 軟件企業(yè) 開發(fā)團隊 激勵機制

一、理論基礎(chǔ)及研究背景

1.1 非對稱信息下的委托代理理論

不完全信息和非對稱信息是信息經(jīng)濟學中的兩個重要概念，也是客觀經(jīng)濟活動中普遍存在的現(xiàn)象。在現(xiàn)實的經(jīng)濟環(huán)境中，不可能存在完全信息，正因為不完全信息的普遍存在，才衍生出五彩斑斕的各種經(jīng)濟行為。同時，不完全信息往往體現(xiàn)為信息不對稱性，非對稱信息的普遍存在正是人們經(jīng)濟活動博弈的基礎(chǔ)和根源。非對稱信息源于社會分工的細化和私人信息的存在，由于信息不對稱，擁有信息優(yōu)勢的一方有可能采取欺詐手段，來為自己謀取私利，這種行為往往損害對方或公眾利益。

因此，非對稱信息的存在使要素市場很難以一種最有效的方式來配置，導致資源配置偏離最優(yōu)狀態(tài)，嚴重時還會導致市場失靈。

委托人-代理人理論正是在非對稱信息的認識基礎(chǔ)上發(fā)展起來的，經(jīng)濟學上的委托-代理關(guān)系泛指任何一種涉及非對稱信息的交易，非對稱信息的存在使得市場中必然存在信息優(yōu)勢方和信息劣勢方，通常稱信息優(yōu)勢方為代理人，而信息劣勢方為委托人。形成委托-代理關(guān)系有兩個基本條件，一是市場交易中存在兩個或兩個以上相互獨立的行為主體，他們在一定約束條件下各自追求效用最大化；二是市場交易的參與者均面臨不確定性風險，而他們掌握的信息處于非對稱狀態(tài)。

研究委托-代理理論的一個重要目的就是建立一套科學的激勵機制或政策制度，迫使代理人采取最優(yōu)行動，防止道德風險的發(fā)生。

有效的激勵機制的設(shè)計必須遵循兩個原則：

一是參與約束，即代理人履行委托代理合同后所獲收益不能低于其在等成本約束條件下從其他委托人處獲得的收益水平；

二是激勵相容約束，即代理人獲得其自身預期效用最大化的同時，必須保證使委托人的預期收益最大化。

1.2 研究背景

二十一世紀是人才競爭的時代，作為信息產(chǎn)業(yè)的主要組成部分，軟件行業(yè)尤其如此。軟件企業(yè)對人才的需求是十分敏感的，主要有三方面原因：

一是軟件開發(fā)是一項專業(yè)性很強、邏輯性非常嚴密的工作，軟件開發(fā)技術(shù)、開發(fā)工具的更新?lián)Q代也十分頻繁，軟件開發(fā)人員除了需要具備專業(yè)知識外，還需要終身學習和歷練，培養(yǎng)一個成熟的軟件人才絕非易事；

二是應(yīng)用軟件解決方案所涉及的領(lǐng)域十分廣泛，軟件企業(yè)往往長期致力于解決某一領(lǐng)域的應(yīng)用問題，從而使得自己的開發(fā)團隊成為這一領(lǐng)域的解決方案專家，如果開發(fā)團隊成員流失，對企業(yè)來說是致命的；

三是軟件系統(tǒng)具有長期性、延續(xù)性和周期性，軟件系統(tǒng)的運行、維護、需求變更和系統(tǒng)升級都需要穩(wěn)定的技術(shù)團隊。

一項針對某軟件產(chǎn)業(yè)園58家企業(yè)的調(diào)查問卷顯示，51家企業(yè)的總經(jīng)理最頭疼的問題是人才的問題，43家企業(yè)曾因為技術(shù)人員流失而給公司造成被動局面，17家企業(yè)因核心員工辭職而不得不放棄原來的業(yè)務(wù)領(lǐng)域，另有3家企業(yè)因業(yè)務(wù)單一、骨干成員辭職而面臨倒閉。在對這58家企業(yè)開發(fā)的203個軟件項目調(diào)查中發(fā)現(xiàn)，因人才流失而導致項目不能及時交付的有63項。

為什么軟件企業(yè)會成為人才流動的重災(zāi)區(qū)呢？究其原因主要有四個方面：

一是軟件企業(yè)一般集中在統(tǒng)一的園區(qū)內(nèi)，技術(shù)人員之間交流十分頻繁，工資、待遇、企業(yè)文化、工作環(huán)境的攀比成為常態(tài)，催生了不穩(wěn)定因素；

二是軟件技術(shù)人才往往比較年輕，思維活躍，大多屬于風險偏好者，好動求變心態(tài)嚴重；

三是軟件企業(yè)的核心資產(chǎn)表面上是軟件著作權(quán)，實際上是裝在技術(shù)人員腦子里的解決方案，人才流動的同時本質(zhì)上也是核心資產(chǎn)的流動，因此有經(jīng)驗的軟件技術(shù)人才再就業(yè)相對容易；

四是因為企業(yè)經(jīng)營者和開發(fā)團隊之間的嚴重非對稱信息而導致的激勵機制難于設(shè)計，導致技術(shù)團隊主觀積極性不高，企業(yè)缺乏吸引力。

問題的核心還是激勵機制的設(shè)計，前述的針對58家軟件企業(yè)的調(diào)查顯示，31家企業(yè)沒有建立針對研發(fā)團隊的激勵機制，完全按固定工資和獎金發(fā)放員工報酬；8家企業(yè)建立了獎金與公司業(yè)績掛鉤的機制，但都是對全體員工而言，對開發(fā)團隊沒有單獨的特別激勵機制；在27家建立有研發(fā)團隊激勵機制的企業(yè)中，90%以上都是簡單地根據(jù)項目的毛利按一定固定比例提成，沒有建立科學的動態(tài)分配激勵機制。由此可見，軟件企業(yè)對研發(fā)團隊的激勵機制要不嚴重缺失，要不實行一刀切，這是造成企業(yè)人才流失的重要原因。事實上，開發(fā)團隊是軟件企業(yè)的核心資源，建立針對開發(fā)團隊的科學有效的激勵機制具有十分必要的迫切性和重要的現(xiàn)實意義。

二、軟件企業(yè)開發(fā)團隊激勵機制模型

2.1軟件企業(yè)項目開發(fā)過程中的非對稱信息特征

軟件企業(yè)的開發(fā)項目通常分為兩類，一類是自行設(shè)計開發(fā)的軟件產(chǎn)品，這類產(chǎn)品一般具有通用性和較強的可配置性，面向的應(yīng)用領(lǐng)域較為廣泛，比如工具型、常規(guī)管理型軟件，企業(yè)在開發(fā)這類項目時往往對收益不能準確預期，也就是銷售額是個變量；另一類是為甲方量身定做的軟件項目，這類產(chǎn)品通過開發(fā)合同來約束，企業(yè)的總收益是一定的，但成本是變量，因此企業(yè)的實際利潤也是變量。以上兩類業(yè)務(wù)模式首先都需要開發(fā)團隊來完成系統(tǒng)開發(fā)任務(wù)，企業(yè)實際上就是委托人，而開發(fā)團隊便是代理人。由于軟件開發(fā)是一項非常專業(yè)的技術(shù)，加上開發(fā)團隊的成員存在個體差異，因此委托人與代理人之間存在嚴重非對稱信息，這種非對稱信息導致委托人很難觀察和測量代理人的行為選擇，從而無法確保企業(yè)（委托人）的效用最大化，甚至無法保障軟件開發(fā)的進度和質(zhì)量。

軟件企業(yè)這種內(nèi)部委托代理關(guān)系的非對稱信息主要有以下幾個特征：

⑴ 技術(shù)非對稱性。

對于一個軟件項目，企業(yè)經(jīng)營者往往只關(guān)注項目的收益、成果、質(zhì)量、成本、開發(fā)周期、市場、價格等商業(yè)性要素，而對項目所采用的體系架構(gòu)、技術(shù)路線、實現(xiàn)方式、開發(fā)環(huán)境、數(shù)據(jù)結(jié)構(gòu)、運行環(huán)境等技術(shù)性要素卻知之甚少，而這些技術(shù)性要素正是開發(fā)團隊所熟知和重點關(guān)注的內(nèi)容，這就是企業(yè)管理層與開發(fā)團隊之間的技術(shù)信息非對稱性。技術(shù)信息非對稱性導致企業(yè)管理層很難評價開發(fā)團隊的成果，很難觀察開發(fā)團隊所選擇的技術(shù)模式是否能最大限度地保障產(chǎn)品質(zhì)量和產(chǎn)品生命力。企業(yè)管理層往往是通過項目交付后由客戶反饋的評價信息，這些評價信息通常是滯后的、非系統(tǒng)性的、非本質(zhì)性的。盡管軟件產(chǎn)品在交付前需要通過測試工序，但測試人員本身就是開發(fā)團隊的組成部分，如果企業(yè)委托第三方專業(yè)機構(gòu)測試，除增加成本外，目前的測試流程也是根據(jù)開發(fā)團隊提供的功能清單來進行，并不涉及軟件產(chǎn)品的核心技術(shù)。因此，技術(shù)信息非對稱性是企業(yè)定量設(shè)計激勵制度的重要障礙之一。

⑵ 行為非對稱性。

軟件開發(fā)人員工作狀態(tài)的外部呈現(xiàn)形式非常單一，就是安靜地坐在電腦前編寫代碼、設(shè)計數(shù)據(jù)庫、編寫技術(shù)文檔等，企業(yè)管理者很難觀察開發(fā)人員的努力程度、工作效率、工作質(zhì)量，傳統(tǒng)的計時、計件辦法派不上用場，如果以代碼量來度量開發(fā)人員的工作量，很容易導致道德風險的發(fā)生，完成同樣的功能節(jié)點也許只需要10行代碼，但技術(shù)人員同樣可以編寫100行代碼來完成，而且會導致軟件運行效率降低。不同開發(fā)工具完成同一功能的代碼量也有很大區(qū)別。

⑶ 產(chǎn)品非對稱性。

軟件項目開發(fā)完成后形成了軟件產(chǎn)品，關(guān)于軟件產(chǎn)品的信息，開發(fā)團隊是最清楚的，企業(yè)管理者或者用戶都只是了解產(chǎn)品的可觀察的外在信息，雙方存在著非對稱信息。企業(yè)管理者與開發(fā)團隊之間也存在公共知識，也就是說，企業(yè)管理者知道開發(fā)團隊對軟件產(chǎn)品信息了如指掌，開發(fā)團隊也知道企業(yè)管理者知道自己對軟件產(chǎn)品信息非常了解，這一高次信息與“軟件質(zhì)量”這一低次信息同樣重要。因此，開發(fā)團隊對軟件產(chǎn)品的信息優(yōu)勢可能實際上變成設(shè)計激勵機制的障礙。

2.2 軟件企業(yè)開發(fā)團隊激勵機制的概念模型

激勵機制的設(shè)計就是制定一定的規(guī)則，使代理人在實現(xiàn)自身效用最大化的同時，達到委托人規(guī)定或希望達到的具體價值標準或社會目標。也就是使代理人從自身效用最大化出發(fā)的同時，自愿或被迫選擇與委托人標準或目標相一致的行動。因此激勵機制的核心就是，委托人怎樣使代理人按照委托人的意志或行動。

在企業(yè)與員工之間，委托-代理合同的核心內(nèi)容實際上就是工資、獎金、股權(quán)或提成，因此激勵機制的設(shè)計就是報酬給予方式的選擇。有效的激勵機制必須讓代理人所得報酬與其工作成果相關(guān)，激勵機制設(shè)計的關(guān)鍵在于這種相關(guān)性的確定。

軟件企業(yè)與開發(fā)團隊之間實際上是一種非對稱信息下的委托-代理關(guān)系，考慮到軟件企業(yè)與開發(fā)團隊的風險偏好，軟件企業(yè)在承接軟件外包項目的業(yè)務(wù)模式下，最優(yōu)激勵機制應(yīng)該是“底薪+項目開發(fā)提成”，約束條件是項目進度和質(zhì)量。對軟件開發(fā)人員，企業(yè)設(shè)置底薪是十分必要的，因為企業(yè)不能確保開發(fā)團隊什么時候都有開發(fā)的任務(wù)，也不能確保軟件項目的難度都是一致的。

通常底薪必須保障員工的基本生活、基本福利以及基本社會保險，底薪與企業(yè)所處的地區(qū)的消費水平要相適應(yīng)?！绊椖块_發(fā)提成”是激勵機制設(shè)計的核心要素，提成低于開發(fā)團隊勞動的邊際成本，將無法有效激勵開發(fā)人員的努力，提成高于開發(fā)團隊勞動的邊際成本，委托人（企業(yè)）將減少自身的實際收益，尋找這個平衡點就是設(shè)計激勵機制的核心內(nèi)容和任務(wù)。

首先設(shè)計一個基本模型，假設(shè)企業(yè)承接了一個軟件外包項目，項目總金額為W，開發(fā)團隊每月底薪總和為U，項目實際開發(fā)周期為m個月，顯然m與開發(fā)團隊的努力程度有關(guān)，令x為開發(fā)團隊付出的努力，則開發(fā)周期可表示為m=M（x）。雖然m并不由x唯一決定，但與x高度負相關(guān)，即開發(fā)團隊越努力，開發(fā)周期越短，也就是說m=M（x）為減函數(shù)。

令s為企業(yè)付給開發(fā)團隊的開發(fā)提成，為激勵開發(fā)團隊努力工作，應(yīng)將開發(fā)提成與團隊的努力程度相關(guān)聯(lián)，即s=S（x），也就是說，團隊越努力，提成就越高，但團隊努力的邊際成本也隨之增大。令y為企業(yè)的實際收益，顯然，企業(yè)實際收益為y=W-U·M（x）-S（x），此時開發(fā)團隊的實際收益為U·M（x）+S（x）。

由于開發(fā)總金額一定，只有縮短開發(fā)周期才能使得企業(yè)實際收益y最大化，因此y與m是負相關(guān)，但縮短開發(fā)周期也不是無止境的，是以團隊努力程度作為條件的，努力程度越高，邊際成本越大，企業(yè)付給開發(fā)團隊的提成也越高，這樣反而降低了企業(yè)的實際收益。

2.2.1 相關(guān)變量和函數(shù)描述

⑴ 抽象變量x

M（x）和S（x）都存在一個公共的自變量x，其含義是團隊的努力程度，是一個抽象的概念，根據(jù)軟件開發(fā)工作的特點，我們將努力程度定義為：在確保開發(fā)質(zhì)量的前提下的工作效率，開發(fā)質(zhì)量可以用單位功能點的BUG數(shù)來測量，工作效率可用單位時間完成的功能點數(shù)量或者單位時間完成的代碼量來測量，這樣努力程度就可以測量了。為研究方便，我們在概念模型中仍然以抽象變量x表示。

⑵ 開發(fā)周期函數(shù)M（x）和產(chǎn)出函數(shù)P（x）

m= M（x）是開發(fā)周期函數(shù)，努力程度x越大，開發(fā)周期m越小，但當努力程度不斷增大時，比如加班時間無止境增加，開發(fā)人員的效率會降低，同時，隨著努力程度x越來越大，開發(fā)質(zhì)量也會下降，代碼中BUG也越多，軟件的測試和修改的工作量會增加，反而會增大開發(fā)周期。因此m= M（x）是一個非線性的減函數(shù)。

函數(shù)的圖形如下：

圖1說明了隨著努力程度增大，曲線越來越平坦，也就是開發(fā)周期縮短效應(yīng)越來越不顯著了。由于軟件項目的金額W是一定的，開發(fā)周期的縮短降低了企業(yè)支付給團隊的底薪，這就是團隊努力的產(chǎn)出。

令p=P（x）為團隊的產(chǎn)出，則P（x）=W-U·M（x），P（x）的函數(shù)曲線如圖2所示：

⑶ 提成函數(shù)S（x）和成本函數(shù)C（x）

s = S（x）是企業(yè)付給團隊的提成函數(shù)，顯然，團隊越努力，提成就越高，另一方面，努力程度越高，團隊的邊際成本也越高，同樣團隊的效率會隨著努力程度的提高而下降，加上受到項目總金額W的限制，企業(yè)不可能按照簡單的線性規(guī)則給團隊提成。因此，一方面團隊會將獲得的提成與付出努力的成本作比較，令c=C（x）為團隊的成本，只有當S（x）≥C（x）時，團隊才愿意接受這項開發(fā)任務(wù)，這就是“參與約束”；另一方面，企業(yè)愿意付給團隊的提成S（x）也不會隨著努力程度x的增加而按照C（x）的增大而增加，增加的幅度會顯著下降，曲線會越平坦。由此可見，起初S（x）是大于或等于C（x）的，這是團隊愿意接受任務(wù)的條件，隨著x的增大，努力的成本C（x）的增速（切線的斜率）會增大，而企業(yè)愿意支付的成本S（x）的增速（切線的斜率）會放緩，最終變成水平線，代表企業(yè)不再愿意增加提成了。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è)與開發(fā)團隊效用最大化

企業(yè)的目標是使得自己利潤最大化，即y=W-U·M（x）-S（x）最大化。圖4繪出了P（X）、C（x）、S（x）三條曲線，我們知道，企業(yè)的實際利潤為P（X）-S（x），所以企業(yè)的利潤最大化就出現(xiàn)在P（X）和S（x）兩條曲線之間的垂直距離最大的時候，此時兩條曲線的斜率相同，x*就是企業(yè)希望開發(fā)團隊付出的努力。而開發(fā)團隊的效用函數(shù)為S（x）- C（x），效用最大會出現(xiàn)在S（x）和 C（x）兩條曲線之間的垂直距離最大的時候，此時兩條曲線的斜率相同，因此x**是開發(fā)團隊希望付出的努力。激勵機制設(shè)計的本質(zhì)就是使得x*無限趨向于x**，當x*=x**時，便達到了“激勵相容約束”，也就是我們平時說的“雙贏”。在現(xiàn)實的經(jīng)濟活動中，為達到x*無限趨向于x**的目的，企業(yè)需要采取的措施有很多，比如設(shè)定合理的開發(fā)周期、平穩(wěn)化提成的增速等等。

以上針對軟件企業(yè)開發(fā)團隊激勵機制的概念模型是根據(jù)“參與約束”和“激勵相容約束”兩個原則而設(shè)計的，企業(yè)和開發(fā)團隊之間的約束是相互的，這樣在很大程度上避免了因非對稱信息而可能造成的道德風險。

三、軟件企業(yè)開發(fā)團隊激勵機制的設(shè)計實務(wù)

盡管上一節(jié)分析并建立了軟件企業(yè)開發(fā)團隊的激勵機制的概念模型，但對于究竟如何設(shè)計激勵機制還需做許多實務(wù)性的工作。

以下從軟件企業(yè)承擔軟件外包工程的業(yè)務(wù)模式出發(fā)，探討具體激勵機制的設(shè)計問題。在具體探討問題之前，首先要解決幾個變量的測量問題。

3.1 有關(guān)變量的測量

⑴ 努力程度的測量（x）

努力程度是一個抽象的概念，根據(jù)軟件開發(fā)工作的特點，我們可以將努力程度定義為：在確保開發(fā)質(zhì)量的前提下的工作效率。開發(fā)質(zhì)量可以用單位功能點的BUG數(shù)來測量，記為e；工作效率可用單位時間完成的功能點數(shù)量或者單位時間完成的代碼量來測量，記為v，這樣努力程度就可以測量了。顯然，x是e和v的函數(shù)，e越小、v越大，x也越大。為研究方便，我們將e設(shè)為限制條件，僅用v來測量努力程度。但由于開發(fā)團隊的技能差異和人數(shù)不同，x也不能直接用v來表示，為使研究具有通用性，我們設(shè)定x的取值范圍為0～100，正常效率工作時（比如8小時上班，不偷懶、不加班）x取值為50，這時團隊單位時間內(nèi)完成的功能點記為Es。 x<50時，團隊偷懶，x>50時，團隊超出正常效率，當x=100時團隊達到極限努力，這時單位時間內(nèi)完成的功能點數(shù)為2Es。

比如某企業(yè)的開發(fā)團隊有10人，企業(yè)通過長期測試這個團隊的業(yè)務(wù)能力，發(fā)現(xiàn)團隊正常效率工作時每月能完成300個功能點的開發(fā)，即Es=300，這時x=50。因此我們可以用下列表達式來測量團隊的努力程度：

其中v表示團隊單位時間完成的功能點數(shù)量，Es為團隊正常效率時單位時間可以完成的功能點數(shù)，x為實際的努力程度。顯然，Es是一個參照標準，與團隊的人員技能水平密切相關(guān)。一般來說，企業(yè)要掌握自己團隊的Es并不難，可以通過長期的測試來得出結(jié)論。

從（3-1）式中可知，當v大于2Es時，x會大于100，這種情況一般違背常理，也不提倡，因為人的勞動是有極限的。最大努力程度定位為“完成正常效率時的兩倍工作量”是有依據(jù)的，也是作者根據(jù)長期的實踐得出的結(jié)論。

⑵ 開發(fā)周期的測量（M（x））

企業(yè)承接一項軟件項目后，需要確定開發(fā)周期。項目的甲方一般都有交付期的要求，這是一個限制條件，實際的開發(fā)周期要小于或等于交付期。企業(yè)在承接項目之前，要根據(jù)項目的需求分析比較準確地測算工作量，也就是確定功能點的數(shù)量，然后根據(jù)自己開發(fā)團隊的工作能力（也就是Es）計算實際的開發(fā)周期。如果根據(jù)Es計算的開發(fā)周期大于交付期，說明企業(yè)必須擴大開發(fā)團隊的人數(shù)或者激勵現(xiàn)有開發(fā)團隊增大努力程度。

顯然，實際開發(fā)周期是團隊努力程度的函數(shù)，即m=M（x）。從上一章的研究得知，開發(fā)周期是隨著努力程度的增加而遞減的，但不是簡單的線性關(guān)系，筆者根據(jù)多年的實踐數(shù)據(jù)觀察得出，m=M（x）近似地服從雙曲線的分布規(guī)律。因此，根據(jù)圖2-1的曲線，我們可以近似地定義開發(fā)周期函數(shù)的表達式為：

問題是參數(shù)K如何確定，由于x是從1～100的代表努力程度的概念數(shù)據(jù)，因此需要換算。假設(shè)某個軟件項目有E個功能點，開發(fā)團隊的正常工作效率為每月完成Es個功能點，我們知道團隊在某種努力程度x下每月能完成的功能點為v，那么開發(fā)周期（也就是需要的開發(fā)月數(shù)）為：

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

團隊努力成本是指團隊為完成任務(wù)而花費的金錢、時間、腦力和體力等，同樣是個抽象變量，它與成員的技能、工作環(huán)境、開發(fā)條件、地區(qū)生活成本都有關(guān)系。由于影響因素關(guān)系復雜，這里用當?shù)赝惵殬I(yè)平均工薪水平來處理，這種處理方法很具有代表性，根據(jù)筆者的經(jīng)驗，團隊員工比較愿意接受。

首先根據(jù)團隊成員的技術(shù)級別（如程序員、高級程序員、系統(tǒng)分析師等），分別套取本地區(qū)同類級別的軟件開發(fā)人員的平均收入，將團隊全部人員的收入求和，以此作為團隊在正常工作效率下的標準收入，記為Bs。

從上一章分析得知，努力的成本函數(shù)近似于拋物線，所以我們用下列表達式代表成本函數(shù)：

3.2 激勵機制實例分析

假設(shè)某企業(yè)承接了一項軟件外包項目，總金額為W=100萬元，甲方要求交付期為5個月。根據(jù)需求分析，該項目的功能點為1000個，企業(yè)決定組成10人的開發(fā)團隊，企業(yè)支付給每人每月的底薪為5000元，團隊的月底薪為10×5000=50000元，即5萬元。

這支10人的開發(fā)團隊正常工作效率下每月能完成200個，根據(jù)當?shù)氐耐惵殬I(yè)的工資平均水平，團隊正常工作效率下完成項目任務(wù)應(yīng)該獲得5萬元的提成。那么，企業(yè)應(yīng)該支付團隊多少提成才能使得團隊愉快接受任務(wù)并努力工作，而企業(yè)的收益又最大呢？

從以上實例得知的已知條件為：項目總金額W=100，團隊底薪U=5，項目功能點E=1000，團隊標準開發(fā)效率Es=200，團隊正常效率下的努力成本Bs=5。

由于效用函數(shù)y是一條由雙曲線和拋物線組成的混合曲線，不能通過求導數(shù)的方法求得極值，因為那時的x取值范圍會遠遠超出100的最大取值點，而且也沒有任何經(jīng)濟學上的現(xiàn)實意義。

因此，我們利用Excel來測算y的局部極值。由于項目甲方要求5個月交付期，根據(jù)團隊的正常工作效率Es=200和項目的功能點E=1000得知，團隊正常工作效率正好可以按期交付項目，因此該項目團隊努力程度必須達到x≥50的要求。

下表是不同努力程度企業(yè)的實際收益和團隊收益：

從上表的測算結(jié)果可以得知：

① 企業(yè)的最大收益出現(xiàn)在團隊努力程度為68時，即x*=68，這時企業(yè)實際收益為72.37萬元。那么團隊的效用最大點x**會出現(xiàn)在哪里呢？由于上表中的總提成S（x）是按照努力成本C（x）來近似計算的，在起初階段，企業(yè)會同意根據(jù)團隊的努力程度的提高來增加提成，但隨著x的增大，企業(yè)會放慢提成增加的速度，直到不再愿意增加。從上表中我們發(fā)現(xiàn)，當x>80時，企業(yè)的收益下降明顯了，因此企業(yè)將不會希望團隊采取x>80的行動了，而這時團隊的月平均收益為最大，因此 可以近似地確定x**=80。

② 團隊的總收益呈現(xiàn)兩頭大、中間小的分布，表面上團隊不愿采取x=68的行動，但實際上團隊是樂意接受的。原因有兩方面，一方面如果團隊采取的行動越趨向50，團隊月平均收益反而會下降；另一方面如果團隊采取的行動越趨向100，似乎總收益和月平均收益都會增加，但付出努力的邊際成本上升更快，很可能會導致C（x）>S（x），這意味著繁重的加班和體力腦力消耗，使得團隊不愿接受任務(wù)。

③ 苛刻的企業(yè)老板會希望團隊選擇x*=68的努力程度，這時需要支付給團隊的總提成為9.248萬元；而聰明和寬容的老板會讓團隊選擇x=75至x=80之間的努力程度，因為這時企業(yè)收益下降的速度遠遠低于團隊月平均收益增長的速度，有利于激發(fā)團隊。

④ 一旦企業(yè)確定愿意支付團隊的提成的額度，團隊應(yīng)該根據(jù)上表確定開發(fā)周期，進而確定單位時間內(nèi)需要完成的功能點數(shù)，并分解任務(wù)到各成員，以確保完成任務(wù)。比如，企業(yè)愿意按照x=75的團隊努力程度支付報酬，這時開發(fā)周期要求是3.333個月，團隊必須每月完成1000/3.333=300個功能點的開發(fā)任務(wù)。

企業(yè)也可根據(jù)團隊實際完成任務(wù)的開發(fā)周期來修正實際支付給團隊的報酬。

參 考 文 獻

[1] 馬費成. 信息經(jīng)濟學. 武漢大學出版社，2012.

[2] 查先進. 信息經(jīng)濟學. 清華大學出版社，2007.

[3] 晁亮. IT項目風險管理理論與實踐[D]. 華東師范大學，2005.

[4] 陳釗. 信息與激勵經(jīng)濟學. 上海三聯(lián)書店、上海人民出版社，2005.

[5] 韓金榮. IT項目投資中的成本效益分析[D]. 中國海洋大學，2004.

[6] 何亞瓊，李一軍，黃梯云. 信息產(chǎn)業(yè)成長的動力機制研究. 決策借鑒，2000，13（2）.

[7] 李剛. 不確定性風險與信息約束. 情報理論與實踐，1998，21（1）.