BugFree的使用：开发过程的量化统计工具
上海互联网同行经常能有一些很务实交流，比如：VeryCD向博客大巴介绍过Google的免费企业邮箱的注册方法和CDN服务商， 而同客齐集的交流中我向王建硕请教过：微软是如何量化开发人员的工作饱和度，评估开发人员的工作效率并鼓励开发者按时完成任务的？从后来通过对BugFree这套系统的使用交流中了解了一些考核机制在任务跟踪系统中影响这些因素的方法。
如果说GTD是一个人的目标管理，那么任务跟踪系统就是帮助实现团队的目标管理： 而且一件事情同时被多个人跟踪，还是非常有助于减少任务的被跟“丢”几率的，一个任务的角色有任务的创建者（甲方）和任务执行者（乙方）两个角色； 而开发团队一般会有3个角色来进行任务的跟踪，项目的发起者（产品经理），项目的执行者（开发人员），项目的确认（测试人员），而一个任务按照进行中，完成确认，关闭这几个状态，也有发起时间（创建者），解决时间（执行者），完成确认时间（创建者）这几个关键时间点， 利用这几个时间因素结合创建人，创建原因等因素，通过BugFree的查询生成器可以完成很丰富的开发过程指标统计甚至完成一些初步的KPI考核指标统计；
开发人员的工作饱和度
就是简单的任务量累计，按照每个需求的预算时间进行累加，比较开发人员的工作时间；
任务的平均关闭时间
总工作时间 ÷ 关闭的任务数，用于评估开发人员的工作效率；
1 开发人员不要将手边积累过多的任务，从而让大量的任务处于等待状态；
2 开发人员会要求需求人员尽量将任务分解： 不要有超过2天的任务，便于及时的确认进展；
3 开发人员完成任务后主动告知需求人员，尽快确认完成并关闭任务；
项目响应速度
项目无更新时间不得超过一定时间（比如： 24小时） ，就是统计：项目状态不等于关闭， 最后更新时间相比现在大于24小时的任务，每天统计：被发现就要发出警告相应项目的执行者； 即使项目没有完成，也要通过编辑项目向项目的发起者进行反馈，避免任务被长期无响应状态；
为此： 项目的开发者还需要遵循以下规则；
1 跟踪系统本身只是用于备忘和时间的统计，任务完成还是需要同事间直接（最好是面对面的）交流；
2 项目的执行方不能关闭任务，只能由创建者关闭；
3 执行者另外需要其他开发人员帮助的时候，需要开启新的任务作为咨询；
4 任务类型只计算新增需求，旧需求的错误修正，不计算为工作时间；
设计以上的规则的目的是：
开发者：作为任务的执行者在任务启动后应及时的解决并要求创建者关闭任务，开发者会尽可能多和任务的创建者沟通，尽可能在项目进入任务跟踪前将项目的需求细化并在完成后及时提交测试并关闭，从而达到满足工作工作饱和度的同时，减少单项目完成时间指标；
需求人员：细化需求合理估算工时避免返工，因为项目的执行者是不用对项目需求的合理性负责的，按时开发完毕后因为需求设计错误为开发者计入工作时间，让需求的提出者（产品经理）成为项目风险的承担者，从而避免产品经理即无责任也无权利的状态；
此外： 什么指标可以体现开发者除了完成任务本身外还在不断找新方法提高效率呢？
