引用

木耳：
@spgoal
我最近也拿到这么个项目 很多东西写的很死 最近跟你一样纠结呢 呵呵 慢慢看吧 操作文档一般是测试开发人员写的 你也写这个。。。。

自己亲自写操作文档有利于快速了解业务流程，从而有利于跟踪代码的时候有目的性，其实跟踪代码就是在跑测试用例，测试人员在这个时候介入我觉得还为时太早，他应该也在忙于了解业务。
有时候觉得如果太多需求和BUG，干脆重写代码还快了，呵呵

我经常拿到一些什么文档没有，注释也没多少的代码，那才叫痛苦，只能现场去问用户如何操作，然后自己补文档，然后再跟程序。

我觉得绩效方案还是需要考虑到团队实际的情况，方案需要团队大部分人认可才行，不能独断专行。

绩效问题一直是我比较头痛的问题，目前的做法就是将任务分解，然后让团队成员一起评估每个任务的工作量，工作量确定就定义每个任务的执行人，定义好后就开始干活，定期进行工作量统计，一般一个月统计一次，而任务的完成是需要经过测试员确认的，如果测试不通过就要返工，不能视为完成。这样有可能出现2天工作量的任务某人花1天就完成或4天才完成，但拿到的钱是一样的，完成速度快的继续完成其他任务赚取其他任务的奖金，速度慢的就要努力完成当前任务，以求做更多的任务。