作为程序员，你希望绩效考核怎么来做？

[uSy62nMkdH]

好像大家都很反感用代码行数、BUG 数等简单粗暴的手段来判定绩效，那么如果你被要求将开发的工作量化然后汇总成最终绩效，你会怎么做？或者你作为被考核者，你希望考核者考核哪些方面？

代码行数？本来一行代码解决的事情，强行写成多行；
BUG 数？ BUG 难易程度怎么定？

[litguy]

不喜欢被考核，混就行了

[jones2000]

没有绩效， 就是最好的考核。

[jinsongzhao]

理想状态应该是有明确工作任务，或由客户驱动任务，完不成的人离开，不用强迫什么教育和管理，如果研发部门，因为管理成熟度不够，分派任务的人不到位，那还不如自由活动，能自己给自己找任务的人留下，成天闲着没事干的离开。

[DaveMo]

工时排名，这个离谱吗

[Torpedo]

@me1onsoda #8 大部分公司绩效是强制的

[zhanshen1614]

以团队为单位来考核加强团队协作，取消强制比例。
BUG 数量改为“逃逸缺陷率”，对于 BUG 、生产事故的认定要有标准和分类。
完成的任务数改为“计划完成率”。
取消协作人评价，这个争议很大想做掉某个人太容易了。
取消无法量化的维度如“企业价值观”、“团队协作”、“工作积极性”、“沟通流畅度”等。
建立独立监督部门确保绩效考核结果公平公正，该部门所有人应与利益相关者构成回避关系。

我觉得绩效考核应以业务目标完成进度作为考核的重点，考核维度通过公式计算得到减少人为操作的空间，信息透明加上 leader 、组织和员工之间相互信任才行，还要给员工申辩的机会并严惩恶意操作的人，没有绝对客观公平公正只能做到基本客观，即使指标合理还有组织架构、职责、小团体等诸多因素，完美的制度也要有三观正的执行者才能落地。

[aulayli]

打标签就是好用，https://v2ex.com/t/1003196

[laifu123]

那些说 bug 也算考核点的，我想问下前后端开发完，前端在对接接口的时候就相当于给后端接口测试一遍，有问题都能直接反馈给后端，不会记录 bug ，但是前端做完就直接交给测试了。
这样就相当于前端出现 bug 的概率比后端大很多，bug 数量也比后端多，而且就算是简简单单改个东西也得考虑特殊数据展示页面会不会和设计稿不符合以及兼容问题等。
前端 bug 只会比后端 bug 多的情况怎么算？

[seth19960929]

@laifu123 BUG=线上 BUG, 而不是开发时候测试发现的 bug, 不然谁敢玩啊

[nevin47]

@LandCruiser 实际上并不会，差异化考核更容易激发团队活力

[LandCruiser]

@nevin47 你看大厂平均在职时间只有几个月你就知道了...考核是不可能公平的。比如楼上说的什么故事点数，太扯淡了，分配任务的时候就已经决定了谁的故事点数多了，可总有人得干脏活累活，凭啥给前者高绩效呢？这样一搞人心就散了。

[me1onsoda]

@seth19960929 按照我的经历来看，开发阶段的 bug 也算，因为测试不是替你擦屁股的，自测不是说着玩的

[wqhui]

@me1onsoda #27
1.两三个小时的面试没办法完全筛选出合适的人，需要一起工作一段时间观察
2.我认为低绩效本来设计出来就是给不合适的人，当你发现团队内有人不合适是直接踢走还是再给一次机会？低绩效就是相当于被警告，一段时间没改就踢走。不过这个被玩恶心了，一是打分是靠人，不一定会遇到公平公正、客观的打分人，二是企业强制低绩效的比例至少是多少，大部分时候团队内并不存在低绩效的人

[collen]

谁混谁做事，大伙儿都明白，考核，领导的🐶罢了，今天你考核我，明天我考核你的🐶命，我奉劝有点傻叉权利就分不清东西南北的人注意一点，希望社会风气回归到快意恩仇来教教这群人做人

[me1onsoda]

@wqhui #53 1.这不就是试用期的意义吗
2.绩效制度你确定是为了选出不合适的人？只能选出不够卷的人吧，你也说到强制低绩效，绩效制度主要目的不就是为了激发团队‘卷’的活力？

[funcNVidia]

程序员的工作很难具体量化，不同层次能力的人对同样问题的理解和实现都有差异。
最终都是要报给客户或者金主那边认可
长有长的报法，也有短的报法

[laifu123]

@me1onsoda #52 然而大部分时候轮到前端开发完根本就没什么时间自测 就要交给测试了。这不是整前端吗

[me1onsoda]

@laifu123 #57 不应该是自测完在联调吗，可以 mock 数据自测