九、考核机制
9.1、关注投产质量
测试中心考核机制分为两类，一是对开发项目组的考核，二是对自身测试人员的考核。在对开发项目组的考核，原则上是为了严格管控项目组的版本准入，这个需要CTO的授权，也需要业务部门的充分理解，往往很多情况为了业务快速上线，同时也是为了推卸责任，开发团队基本上开发了一个半成品，连内部交易都无法联通的版本直接提交给测试中心，而测试中心又迫于压力，不敢拒绝，结果导致测试时间巨幅拉长，整个测试阶段，变成了开发团队的第二次开发阶段，最后上线的版本跟最初提交测试的版本已经是风马牛不相及，而领导的想法是赶紧进入下一个阶段，也不管是否开发完成，就催促测试赶紧开始测起来，而测试各种不顺利，测试进度延迟严重，大领导这时反会觉得测试团队不给力，开发都测完了，测试怎么这么费劲，无形之中当了熟悉的“背锅侠”角色。
对测试人员自身的考核，主要是为了关注测试过程和结果质量，要注重结果导向，将生产上出现的生产事故，对测试人员的考核要受到一定程度的影响，引起测试人员的责任心。但是在结果考核方面，也要看实际情况，如A项目新立项新上线，B项目只是基础软硬件升级，A出现的问题的风险本来就会比B高很多，如果拿同一标准来考核，则对A项目的测试人员是非常不公平的。在过程考核方面，建议分阶段进行，在应用组装和用户测试阶段，不建议将缺陷数量作为衡量测试人员工作量和工作成效的指标，而往往很多公司都这么干，后果是测试人员与开发人员造成了严重的对立，针尖对麦芒，鸡蛋里头挑骨头，大家的工作目标原本是让项目顺利上线，逐渐变成了“大家来找茬”的游戏，弊大于利。而到了版本检验阶段，那么缺陷就要严格考核，因为理论上版本检验阶段已经是测试最后一个环节，且是在准生产环境上进行，故必须严格把关，将缺陷都消灭在之前的阶段里。
9.2、以激励为主
很多公司的考核都是满分制度，出一个问题，就扣几分，然后最后看剩了几分，再体现都薪水上，这种考核制度简单粗暴，制定者只是在制定之初一时爽，省时省事儿，但在后续运行过程中，会发现该考核制度培养了一种文化“多干多措、少干少错、不敢不错”，遇到任务大家都躲着，因为有罚无赏，搞的每次都是领导强行指派，接任务的人也是不甘不愿，这种状态下想把工作做好十分困难。另外一种是考核等级差别不大，干多的钱拿得也不会比干少的少多少，有点儿社会主义大锅饭的意思，这样制度会导致团队没有战斗力，天天混日子。
测试中心的考核制度要以奖励为主，干多干少在薪酬天上地下，不干混日子的就要走人，干的好的，在年终奖或项目奖励上，要有明显的区别，这样才能鼓励员工积极向上，用于承担。
总结一下，金融特别是银行业自身成立独立的软件测试中心势在必行，而筹备期和运行期需要考虑的问题也涉及到方方面面，但这些都是可以克服和解决的细节问题，而主要问题的关键是CTO是否真的有眼光，能够未雨绸缪，有魄力来成立这个组织，另外为了能让测试中心成立的更快或运行的更好，从成熟的商业银行测试中心机构中挖人，但一定是有经验的人，这是一个捷径，最好是经过了测试中心从创建到成熟阶段的人，这样可以快速拥有一套成熟的规范管理体系，能快速创建团队，并知道各种金融系统在生产上的脆弱点，因为其可能亲身经历过的生产问题就十分庞大。
最后希望本人能为计划筹建或正在筹建测试中心的同行业者提供一些微薄的帮助，谢谢！
