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

101 天前
 uSy62nMkdH

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

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

4949 次点击
所在节点    职场话题
58 条回复
wqhui
100 天前
不搞考核的人,有个问题,你能接受不怎么干活或者经常把事情搞砸的人跟你拿一样的钱?
我觉得现在很多考核最恶心的点在于
1.哪怕所有人做的还可以,也必须有人低绩效
2.有些公司纯看跟上级的关系来给绩效,不看工作质量
fredweili
100 天前
时间长了,谁的能力强都知道,谁能给别人做 code review ,谁能在一线解决客户的问题,KPI 基本都是垃圾
runningowl
100 天前
抛砖引玉
低效管理:干的越多越好
高效管理:敏捷开发,两周一个迭代,站会周会,计划会合理安排 10 人天工作量
nobject
100 天前
大多数考核都是看领导的喜好,上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样,有的业务产出明显,有的业务重调研,产出效果一般。
每个人职级与工资不一样,这是一个重要的维度其实,但好多可能都放在一起去考核。
所以有这么多不确定因素在,这绩效大多数还是形同虚设,最后还是变成领导喜好去打
belin520
100 天前
程序员的意见不重要
charlie21
100 天前
别考我了,我考核老板吧
me1onsoda
100 天前
@wqhui 那为什么这么糟糕的人能进团队并且留在团队?
JamesR
100 天前
人月神话,可以了解一下。
loryyang
100 天前
当你思考这个问题的时候,你就能理解许多作为底层员工觉得不合理的管理方式了
本质上就在于人会普遍高估自己,如果你让每个人自评绩效,那么整个团队合起来,肯定会超预算。基于这个前提,你无论怎么打绩效,都会打击部分人的逾期
PS 一下,不是说制度透明就不会受到非议,大家会说制度不合理。即使非常明确的制度,依然会受到执行层面的细节所影响,比如一楼说的几条里面,最简单的 BUG:到底算不算 BUG ,算是谁头上的,责任要怎么分,往细了说就复杂,一复杂就有人有意见。同时,当规则透明之后,这个规则是否真的能代表工作的所有内容,规则越强大,规则之外的事情越没人关心,但那些似乎可有可无的东西,依然对整体的工作有较大的影响。比如说团队合作,知识分享
loryyang
100 天前
所以我的观点是:打绩效就还是偏人治的事情,组织会选择信任 leader ,信任他做的选择。leader 在绩效中有较大自主权,由 leader 来全权管理团队,拿到好的成绩
ppgs8903
100 天前
程序员考个毛~又不是销售~
sch1111878
100 天前
无恶意的说一句, 大部分程序员知识面很单一,

看不上这看不上那, 可是看不上的偏偏是自己严重缺失的部分

原因呢, 就是编码是最简单, 心智负担最低的工作
wu00
100 天前
- 以团队为单位来进行考核,leader 负全责,做得不好换 leader
- leader 掌握所有组员生杀大权,及时更换拖后腿的组员
UIXX
100 天前
我 [理想] 中的考核在条条框框之前是有先决条件的,这个先决条件甚至比考核项的具体内容还要重要:

1. 被考核人信服考核人/团队的资质。
2. 考核人/团队了解被考核人的条件。

要不然考核内容的落实无从谈起,结果也与考核最原始的目的相去甚远。

现今的考核框架制定原则,个人是用这些方针:

1. 所有硬性指标由技术内部控制,不受能行政干预。(避免技术评价还行,HR 一票否决,然后人被开了的情况)
2. 按项目类型和责任人等级决定绩效是结果导向还是过程导向。
3. 考核项以小型里程碑为最小单位,尽量忽略短期时间内的细枝末节。
4. 不使用自评,也不使用 360 环评等可能影响氛围或滋生不良的机制。
5. 上级给下属打差评要有据可依且须与对方解释清楚。
brader
100 天前
经历过很多绩效考核的公司,其实我感觉绩效考核,它不止是在评分阶段存在不准确不公平的现象,它在分配任务之前,就已经不公平了,比如需求它总有难的、容易的、恶心的,领导它总是会把恶心的任务分配给它不喜欢的手下,这种活其实就是吃力不讨好的,哪个人来做,都是这样子,总结就是 做多错多
dhb233
100 天前
如果垂直度比较高,那就各级 leader 自由分配。可以平均分配,也可以用自己的方式考核。最烦的就是强制比例。

如果是扁平化管理,没想好。。。
shuang
100 天前
bug 数、代码行数,不设硬性的考核指标。
可以作为评价的参考,最终由直属 leader 主观评价。
即使 bug 多、代码行数少,如果直属 leader 认为他绩效优,那就可以。
sdjl
100 天前
不要搞什么绩效考核,一个小团队首先要有一个 Leader ,大家要认可这个 Leader 说的话,这个 Leader 要能观察团队中的成员是否互相帮助、互相理解、互相认可。

把大家不太认可的那个人踢出去,换一些新人进来,大家做出来的产品,产生了什么最终结果,这个才重要。
FreshOldMan
100 天前
@chendy #4 不做或者做简单就没有 bug ,越难 bug 越多,你不会说你从来不写 bug 吧
K120
100 天前
考核员工先考核自己,每个月按照标准考核给自己评,再来评员工。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1016652

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX