1. 引言

目前中国国内几乎所有的软件公司或者技术性公司都存在一个十分困扰的问题，那就是：如何评定技术人员的工作量和贡献度！而在国际上通常情况下使用的工作日报、周报、月报、年度总结和计划的绩效考核模式下，让技术人员头疼欲裂却又不得不因为工资和奖金与此相关而被迫填写这些东西。

但是因为技术人员工作的特殊性，加上市场项目的不确定性，使得技术人员的年度计划往往等于空谈。而每天的日报填写虚空无物，因为技术人员的工作量实在是难以衡量，比如说，这一天写了多少代码，但是谁又能保证这些代码有多少行是不需要修改的，这些代码带来的价值到底有多大？同样周报和月报也遇到了类似的问题。除非是写文档和一些外围辅助内容的时候，文档的字数和文档的重要性可以进行一定程度的衡量，而毕竟技术人员主要的工作内容是写代码，代码的价值和有效性可是无法轻易衡量的。

本文所提到的绩效管理方法是笔者在 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       绩效管理

1、         任务安排：周例会上进行工作量安排，配合工作完成后的审核机制以及再分配方式进行。

2、         工作内容带绩点值。

3、         绩点的合作分配规则（主管 / 组长 / 项目经理和主承接人员商议分配）。

4、         配置库中的 check in 次数配合每次的 comment 内容进行绩点调整（通过次数体现时间加成和工作量加成，详情参见配置库）。

5、         任务分配不满造成每个月被分配任务所得到的绩点奖金低于前三 / 六个月平均值则按照前三 / 六个月平均奖金发放。每月按照 22 个工作日计算，如果每个月被分配任务所占用的工作时间少于 18 个工作日（这个数字可以按照企业现状来进行重新设定），则认定任务分配不满。

6、         配合工作绩点根据情况通过加权累计方式计算额外奖金。

 

3.3       配置库

配置库可以采用各种知名的配置管理工具来实现。

要求所有的使用者在每天 check out 其开发工件的时候，必须写明本次的任务。在每次 check in 其开发的工件时，应该写明本次 check in 的完成情况。这个信息都可以写在 comment 中（各种配置管理工具都提供了这个功能）。

如果是撰写文档，则必须保持每次 check in 的内容和文档上的历史修订记录的内容时间相一致，时间由工具自动保持一致性，而修订内容则由技术人员自己填写，只需要填写一次，进行复制粘贴即可。

 

额外的问题：

公司如果考虑到代码安全性的问题，那么建议采用下面的代码管理规则：

在软件进行系统测试前，代码完全组内公开，系统测试后，对于需要控制的代码实行专项工作小组模式进行管理和后续的开发延续，代码就不再全部公开了。

 

3.4       企业代码库

组件代码库的建立和支持办法可以在开发过程启动前进行相应的培训和指导。

代码库主要是构建企业代码基础库，降低企业的重复劳动，提高代码的通用性和共用性。这在 2002 年我到四川院的时候提出过做法和具体的操作措施，技术人员很支持，不过，因为当时是做工程的缘故，同时加上当时企业并没有考虑到如此长远的技术发展规划，因此就没能做起来。

每个人可以在闲暇时间，或者任务间隙来完成，具体要求如下：

1、         完成具体代码的全部开发和测试（建议和别人合作）。

2、         完成一个调用的 Demo 例子程序，以便于其他人使用。

3、         提交（提交内容按照基础组件组中的要求进行）到配置库中的审核区，等待审核。

这个代码库在一次完成后可以由本人升级，也可以由其他人升级完成，每次升级后进行评审，确定参与人员的贡献度比例，以便于今后相关绩点或者奖励的分配。

 

3.5       绩效体系的执行时间

进行两个月的配置库和开发过程的数据积累，所有技术人员一方面在积累数据同时还要熟悉整个过程。

第三个月开始制定绩效体系的数学模型，然后通过三个月的数据或者根据情况加上第四个月的数据进行分别计算，确保模型的有效性和稳定性，确保平稳过渡。

算法完成后的执行期到稳定期大约需要 5 个月，基本上包括下面的内容：

在基础模型算法的基础上，需要增加调整优化算法，调整优化算法的作用是逐渐减弱的，也就是六个月后这个调整优化算法的任务就结束并退出模型了。其目的是让所有人员的工资收入在潜移默化的微量变化中走向规范，而不是一下子出现大的收入变化波动。

所以，整个绩效体系的执行时间为下面三个阶段：

1、         前三个月数据积累，在第三和第四个月构建数学模型，同时完成调整优化算法，进行数学推演，反向计算每个人的收入变化情况和可能的今后六个月的变化情况。

2、         最早在第五个月开始应用该模型，同时，调整优化算法起作用，直到第六个月底为止（这个时间可以根据具体情况进行分析，不是固定的六个月时间，而是会有变化的）。

3、         从调整优化算法推出模型前两个月开始，对算法进行进一步的计算和修改，从第十二个月开始，整个公司的薪酬体系就将完全按照该绩效管理办法来计算奖金和贡献度。

整个过程的实施计划表

注：上面这个计划表是按照每周 5 个工作日，每天 8 小时工作时间的方式计算出来的，如果各个公司的工作周期不同，则需要作适当的调整。

 

4. 绩效管理实现模型

对应的计划文件资源下载： http://download.csdn.net/source/535604

 

 

 

 

5. 薪资收入组成模型

整个薪资的组成包括两个部分，一个是基本工资，这个部分是每个月固定的收入，保证员工的基本生活水平不受到影响，另一个部分是绩效奖金，这个部分根据员工的工作情况和贡献度来进行计算。

 

5.1       基本工资

基本工资采用下面这些计算加成：

1、         参加工作年限指标：这是考虑到工作经验的影响指标。

2、         进入公司年限指标：为公司工作的历史贡献影响指标。

3、         学历指标：大专、本科、硕士、博士各有不同，这是考虑到每个人求学历程的时间，以及他们进入公司时的基础贡献的影响指标。

等等，诸如此类的一些个人因素性指标来决定基本工资的组成和数额。

 

5.2       绩效奖金

绩效奖金分为了三个部分，一是开发工作绩效，二是管理工作绩效，三是代码库贡献度。

 

5.2.1 开发工作绩效

根据任务安排和协助任务安排，并且完成这些任务后所获得的工作绩效。

这一项的范围最容易定义，但是，具体计算的时候却必须依靠历史数据的积累进行模型分析。

 

5.2.2 管理工作绩效

参与管理工作所付出的劳动对应获得的工作绩效。

这一项包括：

团队工作任务计划安排等、任务审核（包括各种评审、代码走查等）、配置库等的管理和维护，以及其他事务性工作所占用的工作时间对应的工作绩效。

可以初步定义，一次评审任务为每个参与者一个基础绩点，并以此工作量来计算相关任务的绩点。

 

5.2.3 代码库贡献度

一个人对公司代码库的付出，同时这个付出在当月内被引用的次数以及相应的加权。

代码库主要是对代码的分类管理，要求每一个维护的技术人员撰写维护文档和代码功能说明书，企业内给以相应的支持和奖励。

在积累的时候，通过配置管理软件来支持，或者自行开发一个简单的检索管理工具都是可行的。

比如对于代码库的构建和使用，这里举一个相对简单的例子：每一个人创建一个新的类，撰写完成它的所有说明文档和使用手册后，公司给予 20 元的奖励，每被别人调用一次，则奖励 5-10 元或者一个绩点。如果发现有人能使用公司代码库中的现成内容而没有使用，则进行每次每模块 20 元罚款或者其他处罚方式。维护代码库，给代码升级一次奖励 5-10 元。个人认为：虽然不高，但是积累多了，还是能够促进大家的使用和沟通交流的。

 

6. 绩效管理算法模型

6.1       模型概述

关于绩效管理的算法模型的基本形态从上面可以看到一些，不过，更具体的算法和实现必须根据各个企业的不同进行构建，简单来说，它包括基本算法模型和调整优化算法。

前者将是持续的，当然也要随着公司的发展每年或者固定时间进行一些调整，后者则是短时期的，主要在整个模型实际应用的前两到三个月内进行应用，过期后，其作用逐渐减弱并被消除掉。

 

6.2       应用结果

在每个月进行工资和奖金发放前，只需要根据所有技术人员的绩点进行数字计算即可。

如果一个产品 / 项目获益，公司决定对项目组成员进行奖励，这时候，就可以用该产品 / 项目总绩点数来除每个人的绩点，这样就可以相对客观的得到每个人应该得到的奖励，而不会因为管理者与员工之间的亲疏关系造成他人的不满，也就避免了公司因此带来的不稳定因素。

 

7. 综述

通过上面的方式，就可以将一家公司的技术人员划入到一个整体范畴内，而不会因为个人好恶来影响到公司整体技术人员的心情和变动。

将人为的数字影像放在周工作任务安排上，而此后的一切内容都是用模型和数字说话的，因此就可以在最大的程度上避免因为个人好恶而产生相对的不公平事件发生，同时也可以在很大程度上避免一些弄虚作假的行为。

更有利于促进软件企业的合理分配。

 

BTW：本文首发于it168，按照约定一个月后可以发布于个人blog。本文中涉及到的计划表将放置在blog资源中提供下载。