这是一个创建于 310 天前的主题，其中的信息可能已经有所发展或是发生改变。
好像大家都很反感用代码行数、BUG 数等简单粗暴的手段来判定绩效，那么如果你被要求将开发的工作量化然后汇总成最终绩效，你会怎么做？或者你作为被考核者，你希望考核者考核哪些方面？
代码行数？本来一行代码解决的事情，强行写成多行；
BUG 数？ BUG 难易程度怎么定？
 |
1
0xHubNet 310 天前  11
分享下我这两年带 2 pizza 团队的绩效管理路径
1.迭代过程中的任务权重(故事点数) 60% 2.对整个团队的基础建设，组件边际效益 （ 10%） 3. BUG 数量，bug 严重等级，影响程度 （ 10%） 4. 线上 BUG 处理 SLA 及格线 （ 10%） 5. 360 环评（ 5%） 6. 直系上司评价（ 5%） |
 |
2
echo1937 310 天前 via iPhone
像打游戏一样，即时可见，数据透明，方向明确，人为因素少。
|
 |
3
LandCruiser 310 天前 1
首先团队成员学历，背景，性格要相似。然后大家吃大锅饭就好了。
搞不平均的绩效考核团队一定会散架。 根本问题就是程序员这行根本就没法客观的评价绩效。 |
 |
4
chendy 309 天前
需求响应速度，bug 数量，bug 严重程度，问题处理速度，问题严重程度，巴拉巴拉
但是只占一部分，另外一部分是团队的，比如产品收款，成本改善之类的 |
 |
5
tramm 309 天前
听不听话
|
 |
6
fishily1993 309 天前 68
我希望不考核，考你奶奶的 B
|
 |
7
Ashore 309 天前
@fishily1993 简单的嘴臭 极致的享受
|
 |
8
me1onsoda 309 天前 1
我也很奇怪。很多时候领导都喜欢强调 team ，但又喜欢搞绩效，分个三六九等，这有利于团队建设？
|
 |
9
Biluesgakki 309 天前
绩效这东西就是用来栓打工人的 好奇欧美有绩效这种东西吗？
|
 |
10
yolee599 309 天前 via Android
我不喜欢绩效考核，取消就行啦，把这钱换成项目奖金发
|
 |
11
uibobo 309 天前
天天研究考核漏洞怎么甩锅，早晚散架。
没事吃个饭啥的团队凝聚力很重要，关系都搞好工作互相帮忙搞那么复杂干嘛。 除非团队非常大才会上管理。 |
 |
12
1018ji 309 天前
问就是不做
|
 |
13
dongisking 309 天前
大多数把原本该发的钱换成绩效，oh 该死的
|
 |
14
nicaiwss 309 天前 via iPhone
吃大锅饭，让大家卷晋升就行，为了晋升程序员自己会吧自己工作的影响力总结好讲给你听
|
 |
15
xiangbohua 309 天前
我也觉得在大锅饭的基础上，适当增加一些激励即可，特别是初创公司可能没多少精力花时间研究绩效的问题。不过管理人员还是关注团队中成员。
|
 |
16
archxm 309 天前
这玩意没法用常规手段，只能平时多观察。平时工作是否饱和
|
 |
17
coderzhangsan 309 天前
绩效考核是机械的，人又不是机器，加之人群文化影响，这东西最后搞得越来越变样，脱离人本主义的考核基本就是搞员工的，不社交不走关系的人吃闷亏。
|
 |
18
connor123 309 天前 1
我更希望强制拆分大厂，限制每个 app 的业务范围，拆分出更多的细分赛道，这样大家都有饭吃，做鸡毛绩效考核啊
|
 |
20
renyi1986 309 天前
为什么要考核
|
 |
21
wqhui 309 天前
不搞考核的人，有个问题，你能接受不怎么干活或者经常把事情搞砸的人跟你拿一样的钱？
我觉得现在很多考核最恶心的点在于 1.哪怕所有人做的还可以，也必须有人低绩效 2.有些公司纯看跟上级的关系来给绩效，不看工作质量 |
 |
22
fredweili 309 天前 2
时间长了，谁的能力强都知道，谁能给别人做 code review ，谁能在一线解决客户的问题，KPI 基本都是垃圾
|
 |
23
runningowl 309 天前
抛砖引玉
低效管理：干的越多越好 高效管理：敏捷开发，两周一个迭代，站会周会，计划会合理安排 10 人天工作量 |
 |
24
nobject 309 天前
大多数考核都是看领导的喜好，上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样，有的业务产出明显，有的业务重调研，产出效果一般。 每个人职级与工资不一样，这是一个重要的维度其实，但好多可能都放在一起去考核。 所以有这么多不确定因素在，这绩效大多数还是形同虚设，最后还是变成领导喜好去打 |
 |
25
belin520 309 天前
程序员的意见不重要
|
 |
26
charlie21 309 天前 via Android
别考我了，我考核老板吧
|
 |
28
JamesR 309 天前
人月神话，可以了解一下。
|
 |
29
loryyang 309 天前
当你思考这个问题的时候，你就能理解许多作为底层员工觉得不合理的管理方式了
本质上就在于人会普遍高估自己，如果你让每个人自评绩效，那么整个团队合起来，肯定会超预算。基于这个前提，你无论怎么打绩效，都会打击部分人的逾期 PS 一下，不是说制度透明就不会受到非议，大家会说制度不合理。即使非常明确的制度，依然会受到执行层面的细节所影响，比如一楼说的几条里面，最简单的 BUG：到底算不算 BUG ，算是谁头上的，责任要怎么分，往细了说就复杂，一复杂就有人有意见。同时，当规则透明之后，这个规则是否真的能代表工作的所有内容，规则越强大，规则之外的事情越没人关心，但那些似乎可有可无的东西，依然对整体的工作有较大的影响。比如说团队合作，知识分享 |
|
30
loryyang 309 天前 2
所以我的观点是：打绩效就还是偏人治的事情，组织会选择信任 leader ，信任他做的选择。leader 在绩效中有较大自主权，由 leader 来全权管理团队，拿到好的成绩
|
 |
31
ppgs8903 309 天前
程序员考个毛~又不是销售~
|
 |
32
sch1111878 309 天前 1
无恶意的说一句, 大部分程序员知识面很单一,
看不上这看不上那, 可是看不上的偏偏是自己严重缺失的部分 原因呢, 就是编码是最简单, 心智负担最低的工作 |
 |
33
wu00 309 天前
- 以团队为单位来进行考核，leader 负全责，做得不好换 leader
- leader 掌握所有组员生杀大权，及时更换拖后腿的组员 |
 |
34
UIXX 309 天前
我 [理想] 中的考核在条条框框之前是有先决条件的，这个先决条件甚至比考核项的具体内容还要重要：
1. 被考核人信服考核人/团队的资质。 2. 考核人/团队了解被考核人的条件。 要不然考核内容的落实无从谈起，结果也与考核最原始的目的相去甚远。 现今的考核框架制定原则，个人是用这些方针： 1. 所有硬性指标由技术内部控制，不受能行政干预。（避免技术评价还行，HR 一票否决，然后人被开了的情况） 2. 按项目类型和责任人等级决定绩效是结果导向还是过程导向。 3. 考核项以小型里程碑为最小单位，尽量忽略短期时间内的细枝末节。 4. 不使用自评，也不使用 360 环评等可能影响氛围或滋生不良的机制。 5. 上级给下属打差评要有据可依且须与对方解释清楚。 |
 |
35
brader 309 天前
经历过很多绩效考核的公司，其实我感觉绩效考核，它不止是在评分阶段存在不准确不公平的现象，它在分配任务之前，就已经不公平了，比如需求它总有难的、容易的、恶心的，领导它总是会把恶心的任务分配给它不喜欢的手下，这种活其实就是吃力不讨好的，哪个人来做，都是这样子，总结就是 做多错多
|
 |
36
dhb233 309 天前
如果垂直度比较高，那就各级 leader 自由分配。可以平均分配，也可以用自己的方式考核。最烦的就是强制比例。
如果是扁平化管理，没想好。。。 |
 |
37
shuang 309 天前
bug 数、代码行数，不设硬性的考核指标。
可以作为评价的参考，最终由直属 leader 主观评价。 即使 bug 多、代码行数少，如果直属 leader 认为他绩效优，那就可以。 |
 |
38
sdjl 309 天前 2
不要搞什么绩效考核，一个小团队首先要有一个 Leader ，大家要认可这个 Leader 说的话，这个 Leader 要能观察团队中的成员是否互相帮助、互相理解、互相认可。
把大家不太认可的那个人踢出去，换一些新人进来，大家做出来的产品，产生了什么最终结果，这个才重要。 |
 |
39
FreshOldMan 309 天前
@chendy #4 不做或者做简单就没有 bug ，越难 bug 越多，你不会说你从来不写 bug 吧
|
 |
40
K120 309 天前
考核员工先考核自己，每个月按照标准考核给自己评，再来评员工。
|
 |
41
litguy 309 天前
不喜欢被考核，混就行了
|
 |
42
jones2000 309 天前
没有绩效， 就是最好的考核。
|
 |
43
jinsongzhao 309 天前
理想状态应该是有明确工作任务，或由客户驱动任务，完不成的人离开，不用强迫什么教育和管理，如果研发部门，因为管理成熟度不够，分派任务的人不到位，那还不如自由活动，能自己给自己找任务的人留下，成天闲着没事干的离开。
|
 |
44
DaveMo 309 天前
工时排名，这个离谱吗
|
 |
46
zhanshen1614 309 天前 1
以团队为单位来考核加强团队协作，取消强制比例。
BUG 数量改为“逃逸缺陷率”，对于 BUG 、生产事故的认定要有标准和分类。 完成的任务数改为“计划完成率”。 取消协作人评价，这个争议很大想做掉某个人太容易了。 取消无法量化的维度如“企业价值观”、“团队协作”、“工作积极性”、“沟通流畅度”等。 建立独立监督部门确保绩效考核结果公平公正，该部门所有人应与利益相关者构成回避关系。 我觉得绩效考核应以业务目标完成进度作为考核的重点，考核维度通过公式计算得到减少人为操作的空间，信息透明加上 leader 、组织和员工之间相互信任才行，还要给员工申辩的机会并严惩恶意操作的人，没有绝对客观公平公正只能做到基本客观，即使指标合理还有组织架构、职责、小团体等诸多因素，完美的制度也要有三观正的执行者才能落地。 |
 |
47
aulayli 309 天前
|
 |
48
laifu123 309 天前
那些说 bug 也算考核点的，我想问下前后端开发完，前端在对接接口的时候就相当于给后端接口测试一遍，有问题都能直接反馈给后端，不会记录 bug ，但是前端做完就直接交给测试了。
这样就相当于前端出现 bug 的概率比后端大很多，bug 数量也比后端多，而且就算是简简单单改个东西也得考虑特殊数据展示页面会不会和设计稿不符合以及兼容问题等。 前端 bug 只会比后端 bug 多的情况怎么算？ |
 |
49
seth19960929 309 天前
@laifu123 BUG=线上 BUG, 而不是开发时候测试发现的 bug, 不然谁敢玩啊
|
 |
50
nevin47 309 天前
@LandCruiser 实际上并不会，差异化考核更容易激发团队活力
|
|
51
LandCruiser 309 天前 2
@nevin47 你看大厂平均在职时间只有几个月你就知道了...考核是不可能公平的。比如楼上说的什么故事点数，太扯淡了，分配任务的时候就已经决定了谁的故事点数多了，可总有人得干脏活累活，凭啥给前者高绩效呢？这样一搞人心就散了。
|
|
52
me1onsoda 308 天前
@seth19960929 按照我的经历来看，开发阶段的 bug 也算，因为测试不是替你擦屁股的，自测不是说着玩的
|
|
53
wqhui 308 天前
@me1onsoda #27
1.两三个小时的面试没办法完全筛选出合适的人，需要一起工作一段时间观察 2.我认为低绩效本来设计出来就是给不合适的人，当你发现团队内有人不合适是直接踢走还是再给一次机会？低绩效就是相当于被警告，一段时间没改就踢走。不过这个被玩恶心了，一是打分是靠人，不一定会遇到公平公正、客观的打分人，二是企业强制低绩效的比例至少是多少，大部分时候团队内并不存在低绩效的人 |
 |
54
collen 308 天前
谁混谁做事，大伙儿都明白，考核，领导的🐶罢了，今天你考核我，明天我考核你的🐶命，我奉劝有点傻叉权利就分不清东西南北的人注意一点，希望社会风气回归到快意恩仇来教教这群人做人
|
|
55
me1onsoda 308 天前
@wqhui #53 1.这不就是试用期的意义吗
2.绩效制度你确定是为了选出不合适的人？只能选出不够卷的人吧，你也说到强制低绩效，绩效制度主要目的不就是为了激发团队‘卷’的活力？ |
 |
56
funcNVidia 308 天前
程序员的工作很难具体量化，不同层次能力的人对同样问题的理解和实现都有差异。
最终都是要报给客户或者金主那边认可 长有长的报法，也有短的报法 |
Select Language