@llb123 业务复杂的项目, 负责任务分发的管理人员可以适当的提高绩效分数

@xiangyuecn 还是拿"装修"举例子, 每个工程师接到"装修"工作后, 需要自己来衡量工作进度和安排, 不可能每个装修项目到了, 都需要管理人员去现场看下预估几号到几号做什么事情, 开发人员自己其实就是"项目经理".

问题在于, 假如装修公司雇佣的"项目经理"都是固定薪资的话, 一个月做几个装修项目跟薪资没有关系, 那么在人性懒惰的前提下, 拖工时 /不想接项目都是肯定存在的问题, 指望装修公司管理人员的威严和管理能力, 都是不靠谱的.

@11wangyaoda 其实你举得"装修"的例子很合适, 每个开发工程师都是独自负责一个装修的 case 的, 不管他挥了几下锤子, 最后都是按照这个装修工程结束后算绩效成绩的, 而不是按照挥锤子的次数

@zw1one 开发人员都是在公司的, 不需要出差

@huruwo 可能你对 toB 端的软件不熟悉, 每个 B 端企业用户的需求都是独特的, 并且不一样的(主要是流程), 基本上开发的主要工作就是业务流程的重构, 而不是例如应付高并发这样的需求, 一旦高并发解决了,以后就没有什么问题了.

B 端软件的实施过程, 都是流程重构和打通, 并且几乎每个企业的需求都是不一样的.

@huruwo 任何根据"绩效"发放的薪资制度都有这种可能性, 这就只能靠公司内部的默契, 以及另一方如果觉得对方做的过分, 用脚走人投票来平衡了

@wxw752 考核是根据员工完成的 "项目"来计算的而不是根据代码行数, 例如一行代码也是完成项目, 10 行代码也是完成项目, 我相信没有人会把一行写成 10 行的

@plk403 case 是固定的, 例如这个月就这一单 case, 你写垃圾代码用了 20 天也可以; 高效率的话, 1 天把项目完成了, 后面摸摸鱼也 OK

@huruwo 如果按照这种模式的, 效率高的话假如一个月前 10 天自己完成了 2 个 case,只想拿 12K 的话, 后面可以摸鱼, 大家都高兴.