目前國內幾乎所有的軟件公司或者技術性公司都存在一個十分困擾的問題，那就是：如何評定技術人員的工作量和貢獻度。而在國際上通常情況使用的工作日報、周報、月報、年度總結和計劃的績效考核模式下，技術人員頭疼欲裂，卻又不得不為工資和獎金而被迫填寫這些東西。
因為技術人員工作的特殊性，加上市場項目的不確定性，使得技術人員的年度計劃往往等于空談。而每天的日報填寫虛空無物，因為技術人員的工作量實在難以衡量，比如，這一天完成多少代碼，但誰又能保證這些代碼有多少是不需要修改的，這些代碼帶來的價值到底有多大呢？同樣地，周報和月報也遇到類似的問題。除非是寫文檔和一些外圍輔助內容的時候，文檔的字數和重要性可以進行一定程度的衡量。畢竟技術人員的主要工作內容是寫代碼，代碼的價值和有效性卻是無法輕易衡量的。
本文所提到的績效管理方法是筆者在2004年產生的想法，從2004年起到今天不斷地進行補充和豐富，終于在今年得到一定程度的系統化，同時開始在一些公司里推行。
總體來說，這個績效管理模型是為了實現有效的績效管理，提高技術人員工作的積極性，同時為團隊后續進行個人貢獻度計算及獎金的分配提供績效計算基礎數據，因此采用了以數據為基礎的管理辦法來衡量技術人員的工作量和貢獻度。
本文涉及的內容將包括開發過程中的項目計劃管理、風險管理、團隊組成、配置管理和企業代碼庫構建等幾個方面的內容。
2. 團隊組成與管理劃分
團隊的組成模式要根據各個公司的現狀進行考慮，不能一概而論。下面這種模式適用于一些做產品的公司。
2.1 團隊組建依據
團隊的組成模式要根據各個公司的現狀進行考慮，不能一概而論，尤其是對于已經有自己相對穩定管理模式的公司，更需要根據具體情況進行考慮。
2.2 人員平等，技術至上
所有人員一律平等，人員根據經驗、畢業年限、為公司工作年限設定基本工資，然后根據項目組情況設定獎金和特殊獎勵。
獎金部分根據所參加的項目組獲得相應的獎金收入，同時還根據所開發的基礎組件當月被重用的次數獲得額外的獎金收入[參見企業代碼庫構建]。
2.3 方向引導，產品集中
在沒有具體產品和用戶需求的時候，進行公司方向性開發和研究，并根據方向進行團隊組織和管理，同意隸屬部門經理或者某一個級別的管理者管理。
在有具體用戶需求、訂單和產品的時候，進行人員重新組合，選擇合適的人員設定為項目經理，由項目經理全權根據公司產品架構組的建議進行人員選擇和搭配，然后進行項目開發。
2.4 基本團隊劃分
2.4.1 產品策劃組
產品策劃組考慮為無形態組的方式進行組織，公司內任何人員都可以自行或者自由組隊的方式進行產品的策劃和規劃考慮，并將相應的策劃和規劃案提交給公司產品架構組進行分析定位和評審。評審通過的，公司將考慮進行投資研發。
產品策劃成形的相關參與人員都可以在公司投資研發的費用中獲得1%（一個設定的比例）的獎勵，同時得到后期產品研發成功后的銷售股份和提成。
2.4.2 內容開發組
內容開發組是負責游戲內容開發和實現的團隊。這個團隊根據具體項目需求進行組建，不屬于常設團隊。
2.4.3 工具開發組
工具開發組主要是進行機構設計和游戲輔助工具開發的團隊。
這個團隊根據具體項目需求進行組建，不屬于常設團隊。但是，基本上每一個內容開發組都可能對應有一個同樣的工具開發組進行配套支持。工具開發組也可能獨立成立來進行機構研究。
工具開發組的可能人員的技能與內容開發組差異較大，主要是具有機械設計方面知識和技能的人主要執行，有部分軟件設計和策劃人員參與輔助工作。
2.4.4 基礎組件組
基礎組件組是為了構建企業代碼庫所提供的一種組織形式。
基礎組件組也是采用無形態組的模式進行組織，公司內任何人員都可以提交自己開發的成品組件，要包括下列內容：
1. 公司要求的設計說明書和設計模型。
2. 組件詳細功能說明書、接口詳細說明書和詳細設計文檔（建議采用UML模型的表述方式進行設計，代碼直接導出，有利于重用和升級）。
3. 可運行組件。
4. 組件全部源代碼和對應版本說明（注釋不得少于30%）。
5. 采用本組件的示例性Demo。
3. 績效管理辦法基礎
本績效管理辦法需要通過下面幾個內容的積累才能獲得準確執行。
3.1 項目管理
- 實施項目計劃管理，制定項目計劃和工程過程的基本規范，不需要太詳細，將來根據情況和需要進行擴充。
- 制定項目計劃模板、項目周任務安排模板、項目風險評估模板和項目計劃評審模板。
- 切實實行項目周工作例會，有效安排工作任務和工作總結。
- 每項任務完成后都必須經過文檔評審和代碼測試來進行審核。
- 版本管理規則、開發基線管理規則都需要制定。
3.2 績效管理
- 任務安排：周例會上進行工作量安排，配合工作完成后的審核機制及再分配方式進行。
- 工作內容帶績點值。
- 績點的合作分配規則（主管/組長/項目經理和主承接人員商議分配）。
- 配置庫中的check in次數配合每次的comment內容進行績點調整（通過次數體現時間加成和工作量加成，詳情參見配置庫）。
- 任務分配不滿造成每個月被分配任務所得到的績點獎金低于前三/六個月平均值，則按照前三/六個月平均獎金發放。每月按照22個工作日計算，如果每個月被分配任務所占用的工作時間少于18個工作日（這個數字可以按照企業現狀來進行重新設定），則認定任務分配不滿。
- 配合工作績點根據情況通過加權累計方式計算額外獎金。
3.3 配置庫
配置庫可以采用各種知名的配置管理工具來實現。要求所有使用者在每天checkout其開發工件的時候，必須寫明本次的任務。在每次check in其開發的工件時，應該寫明本次checkin的完成情況。這些信息都可以寫在comment中（各種配置管理工具都提供這一功能）。
如果是撰寫文檔，則必須保持每次check in的內容和文檔上的歷史修訂記錄的內容時間相一致，時間由工具自動保持一致性，而修訂內容則由技術人員自己填寫，只需要填寫一次，進行復制粘貼即可。
額外的問題：公司如果考慮到代碼安全性問題，那么建議采用下面的代碼管理規則：
在軟件進行系統測試前，代碼完全組內公開；系統測試后，對于需要控制的代碼實行專項工作小組模式進行管理和后續的開發延續，代碼就不再全部公開了。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
