3. 绩效管理办法基础
本绩效管理办法需要通过下面几个内容的积累才能获得准确执行。
3.1 项目管理
- 实施项目计划管理，制定项目计划和工程过程的基本规范，不需要太详细，将来根据情况和需要进行扩充。
- 制定项目计划模板、项目周任务安排模板、项目风险评估模板和项目计划评审模板。
- 切实实行项目周工作例会，有效安排工作任务和工作总结。
- 每项任务完成后都必须经过文档评审和代码测试来进行审核。
- 版本管理规则、开发基线管理规则都需要制定。
3.2 绩效管理
- 任务安排：周例会上进行工作量安排，配合工作完成后的审核机制及再分配方式进行。
- 工作内容带绩点值。
- 绩点的合作分配规则（主管/组长/项目经理和主承接人员商议分配）。
- 配置库中的check in次数配合每次的comment内容进行绩点调整（通过次数体现时间加成和工作量加成，详情参见配置库）。
- 任务分配不满造成每个月被分配任务所得到的绩点奖金低于前三/六个月平均值，则按照前三/六个月平均奖金发放。每月按照22个工作日计算，如果每个月被分配任务所占用的工作时间少于18个工作日（这个数字可以按照企业现状来进行重新设定），则认定任务分配不满。
- 配合工作绩点根据情况通过加权累计方式计算额外奖金。
3.3 配置库
配置库可以采用各种知名的配置管理工具来实现。要求所有使用者在每天check out其开发工件的时候，必须写明本次的任务。在每次check in其开发的工件时，应该写明本次check in的完成情况。这些信息都可以写在comment中（各种配置管理工具都提供这一功能）。
如果是撰写文档，则必须保持每次check in的内容和文档上的历史修订记录的内容时间相一致，时间由工具自动保持一致性，而修订内容则由技术人员自己填写，只需要填写一次，进行复制粘贴即可。
额外的问题：公司如果考虑到代码安全性问题，那么建议采用下面的代码管理规则：
在软件进行系统测试前，代码完全组内公开；系统测试后，对于需要控制的代码实行专项工作小组模式进行管理和后续的开发延续，代码就不再全部公开了。
3.4 企业代码库
组件代码库的建立和支持办法可以在开发过程启动前进行相应的培训和指导。代码库主要是构建企业代码基础库，降低企业的重复劳动，提高代码的通用性和共用性。这在2002年我到四川院的时候提出过做法和具体操作措施，技术人员很支持，不过，因为当时是做工程的缘故，同时加上当时企业并没有考虑到如此长远的技术发展规划，因此没能做起来。
每个人可以在闲暇时间，或者任务间隙来完成。具体要求如下：
- 完成具体代码的全部开发和测试（建议和别人合作）。
- 完成一个调用的Demo例子程序，以便于其他人使用。
- 提交（提交内容按照基础组件组中的要求进行）到配置库中的审核区，等待审核。
这个代码库在一次完成后可以由本人升级，也可以由其他人升级完成。每次升级后进行评审，确定参与人员的贡献度比例，以便于今后相关绩点或奖励的分配。
3.5 绩效体系的执行时间
进行两个月的配置库和开发过程的数据积累，所有技术人员一方面在积累数据，同时还要熟悉整个过程。
第三个月开始制定绩效体系的数学模型，然后通过三个月的数据或者根据情况加上第四个月的数据进行分别计算，确保模型的有效性和稳定性，确保平稳过渡。
算法完成后的执行期到稳定期大约需要5个月，基本包括下面的内容：在基础模型算法的基础上，需要增加调整优化算法，调整优化算法的作用是逐渐减弱的，也就是六个月后这个调整优化算法的任务就结束并退出模型。其目的是让所有人员的工资收入在潜移默化的微量变化中走向规范，而不是一下子出现大的收入变化波动。
所以，整个绩效体系的执行时间为下面三个阶段：
- 前三个月数据积累，在第三和第四个月构建数学模型，同时完成调整优化算法，进行数学推演，反向计算每个人的收入变化情况和可能的今后六个月的变化情况。
- 最早在第五个月开始应用该模型，同时调整优化算法起作用，直到第六个月底为止（这个时间可以根据具体情况进行分析，不是固定的六个月时间，而是会有变化的）。
- 从调整优化算法推出模型前两个月开始，对算法进行进一步的计算和修改，从第十二个月开始，整个公司的薪酬体系就将完全按照该绩效管理办法来计算奖金和贡献度。
整个过程的实施计划表
注：上面这个计划表是按照每周5个工作日，每天8小时工作时间的方式计算出来的。如果各个公司的工作周期不同，则需要作适当的调整。
