【IT168 专稿】
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 基础组件组
基础组件组是为了构建企业代码库所提供的一种组织形式。
基础组件组也是采用无形态组的模式进行组织，公司内任何人员都可以提交自己开发的成品组件，要包括下列内容：
- 公司要求的设计说明书和设计模型。
- 组件详细功能说明书、接口详细说明书和详细设计文档（建议采用UML模型的表述方式进行设计，代码直接导出，有利于重用和升级）。
- 可运行组件。
- 组件全部源代码和对应版本说明（注释不得少于30%）。
- 采用本组件的示例性Demo。
