[轉載]用绩效模型对IT技术人员进行有效管理

用绩效模型对IT技术人员进行有效管理

1. 【引言】

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

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

总体来说，这个绩效管理模型是为了实现有效的绩效管理，提高技术人员工作的积极性，同时为团队后续进行个人贡献度计算及奖金的分配提供绩效计算基础数据，因此采用了以数据为基础的管理办法来衡量技术人员的工作量和贡献度。

本文涉及的内容将包括开发过程中的项目计划管理、风险管理、团队组成、配置管理和企业代码库构建等几个方面的内容。

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 项目管理

1. 实施项目计划管理，制定项目计划和工程过程的基本规范，不需要太详细，将来根据情况和需要进行扩充。

2. 制定项目计划模板、项目周任务安排模板、项目风险评估模板和项目计划评审模板。

3. 切实实行项目周工作例会，有效安排工作任务和工作总结。

4. 每项任务完成后都必须经过文档评审和代码测试来进行审核。

5. 版本管理规则、开发基线管理规则都需要制定。

3.2 绩效管理

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

2. 工作内容带绩点值。

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

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

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

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

3.3 配置库

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

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

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

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