绩效管理对一个Team是比较重要的一项日常管理任务，如何做到团队内每个人的绩效得分公平公正，必须有一套行之有效的方法。下面我谈谈我们部门管理的一些方法，拿出来与大家分享，希望有相关经验的人参与讨论，说说你们的管理方法。
一般管理比较规范的公司都会在年终或者季度末发放绩效奖，而每个人的奖金多少一般是根据每个人的表现和得分来发放的，这个得分的评定是从何而来的呢？有的是按照平时的表现等主管判断来的，依据有工作态度，完成任务的效率，与其他同事的关系等，有的是按照工作日志和完成任务积分。我们部门采用的是按照平时完成的任务所获得的有效积分，然后统计每周每月的报表，并对团队内每个成员的积分结果进行排名，在Team内的每周例会上Review这些结果，让每个成员了解本周每个人的工作进展情况。这样做的好处有很多，比如公开公平，方便工作统筹管理，了解个人人力负荷等。
首先介绍一下我们团队中大概的几种角色，其中有SA系统分析员，SD系统设计人员，Dev开发人员，测试与发布人员，项目经理和绩效监管人员。平时的工作中，sa的主要职责是分析用户需求，sd负责针对需求的设计和部分开发，Dev人员专门负责自己小组产品的开发与维护，项目经理和监管人员负责整个Team的产品和人员的统一管理。平时的工作流程严格按照CMMI的一些要求，对整个团队成员的一些要求有，个人工作日志的每日维护，工时的Log，产品任务列表的维护，项目组成员的任务分派和划分等。下面我从一个需求的产生到发布正式环境的整个流程来谈一下我们平时的做法。
需要说明的是，下面说的是现有系统的维护和支持工作，新增项目的管理方式有另外的管理方法，跟这个稍有区别。我们Team大概有四个产品组，四个sa和四个sd，一个小组一般会维护几个系统或者参与开发几个项目，项目组的成员中，sa和sd的工作内容相对比较专业一些。sa专门做需求分析和与用户沟通的工作，一个需求产生之前，用户和sa会进行充分的沟通，包括这个需求的具体内容和可行性。如果这个需求确定要做之后，用户那边的窗口会在Helpdesk系统中进行填单工作，当用户填好需求单之后，会在系统中产生一个Ticket，sa会通知sd人员接受该Ticket，并针对该Ticket设计解决方案，如果任务量比较大，sd会细分任务并分派给小组内的几个成员共同完成，如果该需求比较小，会与小组内有空余时间的开发人员沟通，并将任务分派给他，当然sd人员也可能会直接开发这个需求。sd人员给出这个需求的设计方案的时候会预估它的开发时间和成本，比如说一个需求需要40个小时，其中开发时间为35H，测试发布时间为5H，并且这个需求分配给了开发人员小A，那么接下来小A开始做这个需求的开发工作，他每周的开发进展会写到Helpdesk系统中的Modify History中。无论小A开发这个需求实际使用了多少工时，那么他的有效工时基本上都是35H。如果他实际使用20H开发完成，本周的其他时间他还可以接其他的需求，比如他接受了另外一个20H的需求并开发完成，那么他本周的有效工时就是35H+20H=55H，但如果小B做这个需求，由于小B的个人能力不如小A，他实际花费了45H完成了这个需求，那么小B的有效工时还是35H。所以由于个人能力的问题，在同样是时间内不同的人会得到不同的绩效分，有可能一周之内小A得了55/8=6.875分，小B由于本周内没有完成一个需求而绩效分数为0。上面说到小A开发这个需求的过程必须在Helpdesk和个人工作日志中有记录，这个过程的监督工作一般是由PM或者管理人员来做的。写这些修改记录需要Helpdesk系统和Portal系统的支持，前者是跟需求写在一起的，后者是部门的一个知识管理平台，里面有产品任务表文档，个人工作记录文档等。当小A完成了这个Ticket的开发之后，会把代码打包并写好发布文档上传至Helpdesk上面，然后在TFS上面Check in代码，通知发布人员获取最新代码。然后是测试发布人员去Review小A的代码，发布到开发环境和用户测试环境，通知用户测试，完成自己的工作之后Log自己的工时进Helpdesk系统。如果用户测试没有问题，那么sa会关闭这个Ticket，整个需求的开发就完成了。这个过程中一般都会涉及到以上所说的四种角色，每个参与人员都必须有工时记录，并统计自己的有效工时来换算成自己的绩效得分。
接下来说说个人工作日志的问题，园子里面前段时间也有人说道写工作日志的好处和坏处。个人认为好处还是蛮多的，至少它是进行绩效管理的有效手段。但绩效管理的依据并不是工作日志，而是Ticket所需的有效工时。个人平时的工作任务类型一般分为以下几种，其中有Ticket、Runtime、Issues、study等。由于我们的开发成本是要用户分摊费用的，而能向用户收取费用的只有Ticket，所以说一个Ticket预估工时的工作非常重要，SD要尽量考虑项目组内成员的开发水平和需求实际花费的时间，尽量预估的和实际的开发时间相靠近。而Team内成员的工作日志中的任务类型一般应该以Ticket为主，当然，Team一般都会在每周有至少两次例会，开会时间每周大概四个小时，这个部分算作Runtime。如果你本周确实没有Ticket来做，那你可以做更多的Study工作，但这个一般不算作有效工时。因此，以上统计有效工时的做法督促项目组内的成员都争取Ticket来做，尽量使自己本周之内的绩效得分高一些。
最后说道一下我们推行以上做法过程中遇到的一些问题。做这种绩效管理开始的时候要经常有人督促Team内成员维护个人的工作日志，督促sa和sd管理好本小组成员的任务分派问题，及时关闭完成的任务，安排好本周和下周的事情等。还需要注意的是，怎么拆分好大的任务为小的任务，尽量让每个人本周之内都能获得有效工时而不是周绩效分为零。另外，个人认为这套管理方法还是有些小问题的，特别是任务不多的时候，大家相对比较清闲的时候，一般SD人员会参与比较多的开发任务，下面的开发人员就有可能分不到任务，长期以来，SD的绩效分遥遥领先，经常领不到任务的和做事效率比较低的人的绩效分则不到最高人员的五分之一。但反过来想，这也算是一种激励机制，所谓多劳多得嘛。