工作一般是由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的绩效分遥遥领先，经常领不到任务的和做事效率比较低的人的绩效分则不到最高人员的五分之一。但反过来想，这也算是一种激励机制，所谓多劳多得嘛。