请教下程序员应该怎样考核？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2002 天前的主题，其中的信息可能已经有所发展或是发生改变。

曾一下热点，程序员究竟该怎样考核呢？

- 主管的主观评价，人少时似乎还可以，人多了就不可取了，前提还得主管比较客观靠谱；
- 按时间（工作时长，加班时间），肯定不可取，很多人也不赞同；
- 计件（类似搬砖，包饺子），也不可取，软件开发的脑力劳动要多于体力劳动；

那么问题来了，针对一个 30 人左右的小型软件公司，怎样考核比较合适？

诚心欢迎各路大神赐教！

第 1 条附言 · 2019-06-19 09:01:38 +08:00

感谢各路大神的回复，结合现状，目前想出来的是：

## 组员

- 任务，以 gitlab 的 issue 为准，一个 issue 就是一个任务，由开发组组长进行分配，评估工时；
- 实现，组员按时完成任务，得 5 分，超时完成得 3 分；
- 流水线，自动运行代码规范性检查，单元测试（目前还没集成测试，准备上），通过则再得 1 分，失败则扣 1 分；
- 代码评审，技术负责人进行抽查，对于不符合规范的，要求组员修改，不扣分，但是会影响实现的时间，间接影响的分；
- 测试，经测试，无 bug 则加 1 分，有 bug 扣 1 分；

## 测试

- 任务 / bug 比例？

## 组长

在组员考核内容的基础上，增加下面的几项：

- 任务的难度以及工时评估的合理性，小于 60% 不得分，小于 75% 得 20 分，大于 85% 得 50 分；
- 测试覆盖率，达到 80% ，得 20 分，否则不得分；
- 流水线成功率，达到 80% ，得 20 分，否则不得分；
- 任务 /bug 比例，小于 30% ，得 50 分，小于 50% 的 20 分，再大则不得分；

第 2 条附言 · 2019-06-19 09:10:23 +08:00

主要涉及三类，开发，助长以及测试，欢迎给出意见。

可取

考核

程序员

赐教

79 条回复 • 2019-06-20 13:13:25 +08:00

BCy66drFCvk1Ou87

2019-06-18 20:03:29 +08:00

会摸鱼划水的加工资

MinQ

2019-06-18 20:07:59 +08:00 via Android

燃尽图

choury

2019-06-18 20:33:36 +08:00 via Android

当然是按代码行数，哈哈

robin1008

2019-06-18 20:49:21 +08:00 via iPhone

工作投入、产出质量，按比例考核

uTOmOuk3L6sb4MSI

2019-06-18 20:54:35 +08:00 via iPhone

今天去面试，说没加班费；绩效里面也有按工作时长这项；
我？？？

MrUser

2019-06-18 20:59:27 +08:00

搞笑版：
拆成功能模块后“拍卖”，谁出的考核分少谁拥有开发权，月底计算每个人的考核总分。
如果没人竞拍，就指定一个考核分，然后抓阄。

jobtesting

2019-06-18 20:59:27 +08:00 via iPhone

分几块看
1.团队贡献
2.质量与效率
3.项目完成情况

大方向是结合团队目标，如果团队没目标，那就不要考核了。不然，你想清楚考核的目的是什么

piloots

2019-06-18 21:00:02 +08:00

资深 hr 告诉你，程序员考核？自找苦吃

zzn

2019-06-18 21:02:51 +08:00

30 个人应该是有几个小组的，小组长主观评价？

luozic

2019-06-18 21:05:31 +08:00 via iPhone

质量性能效率。活多活块活好。

Jirajine

2019-06-18 21:07:25 +08:00 via Android

当然是三者结合了。首先是主观评价，谁会来事谁分高；然后看工时，和代码行数🐶

luozic

2019-06-18 21:15:20 +08:00 via iPhone

团队目标那种更多是小组长以上人的事，用来框普通程序猿？也是牛逼了。

yangzhezjgs

2019-06-18 22:33:21 +08:00

软件工程里面专门就有一个研究方向叫软件度量，个人觉得可以按功能点，bug 数和代码行数之类的建立一个量化的评价标准

php01

2019-06-18 22:38:45 +08:00

管人很爽吧

ruandao

2019-06-18 23:04:37 +08:00

一个技能档工资 + 项目效益啊

wenzhoou

2019-06-18 23:12:27 +08:00 via Android

很简单。项目组长门清，你问他我拿张三和李四跟你换你们组的王大麻子，组长说滚，不换！
怎么样，人家考核 1 秒都不用。

chenliangngng

2019-06-18 23:13:01 +08:00

当然是发量啊，这个最准了

zengming00

2019-06-19 09:08:27 +08:00

你想考核程序猿？就 HR 那点算计人的智商怎么跟程序猿斗

beginor

2019-06-19 09:11:14 +08:00 via Android

@yiome404 @zengming00 我不是 HR，也是程序员

xuanbg

2019-06-19 09:17:21 +08:00

1、考核能力而不是考核工作量、业绩
2、考核主动性而不是考核犯错的次数
3、价值观什么的老板最喜欢了。。。

Tomorr

2019-06-19 09:31:24 +08:00

分小组管理，组长负责组员情况，再考核组的情况
评估每个组的工作量、难度系数、价值
个人能力加分评估，很重要，对能力强的人表扬

KylinJiang

2019-06-19 10:18:00 +08:00

OKR 了解一下？
https://www.infoq.cn/article/gU*236UQhE5FYgDsYXoB

piaochen0

2019-06-19 10:25:13 +08:00

还是组长门清吧，HR 视图指定一套规则来衡量程序员，按我待过公司的经历，最终都会导致很严重的抵制。

lastpass

2019-06-19 10:33:48 +08:00 via Android

你这样考核的目的无外乎想外行管理内行。
管理人员先提高自己的专业姿势水平再想着管理。

mikicomo

2019-06-19 10:37:55 +08:00

考核和薪酬体系挂钩不

考核分数高钱多给吗

tt67wq

2019-06-19 10:38:46 +08:00

按颜值！

xsiong

2019-06-19 10:38:51 +08:00

比较反感

pmispig

2019-06-19 10:43:39 +08:00

按加班时间最客观。
加班越多水平越差。

askfilm

2019-06-19 10:51:34 +08:00

@beginor 考核不就是为了扣工资的嘛，不管你怎样设计方案，只要扣钱了，老板就认为你做事不错

beginor

2019-06-19 10:54:56 +08:00 via Android

@mikicomo 肯定会挂钩的

beginor

2019-06-19 10:56:40 +08:00 via Android

@askfilm 扣工资不是目的，但是考核垫底的就不好说了

SmiteChow

2019-06-19 10:57:18 +08:00

按效率，工作流分状态，看板自动记录每个状态时间，个体和自己做比较

beginor

2019-06-19 11:02:18 +08:00 via Android

@lastpass 是的，就是想让外行管理内行。你程序员不是牛逼吗，多干活，多拿分，没 bug，就 OK 了。不行就别瞎 bb

beginor

2019-06-19 11:03:01 +08:00 via Android

@tt67wq 那是鼓励师

Dex7er

2019-06-19 11:14:36 +08:00

咱们本就是最会挖墙脚的民族，
你面对的还是这个民族中智商最出色的一群，
即便你智商也是一个水平的，
你能一个打十个？

HR 们你们就承认吧，
搞不过这帮高智商的孙子。。。
代码行数，bug 数量，加班时间，工作效率，
哪一个参数都可以摸鱼，
你信不信。
管那么多啥，按时出活就行了。。。

hzgit

2019-06-19 11:20:00 +08:00

提到考核无非按时、按质、按量，至于怎么把具体工作对应到时、质、量，就需要考验组长们的任务拆解能力了。考核项的设定可以参考 S.M.A.R.T。

评论里很多 ver 提到被考核人抵触考核的问题，个人觉得其实主要是考核规则不透明，考核目的不单纯的问题。其中考核目的不单纯是最大的因素。

试想一下，如果你的考核目的就是要把一部分人挤走，或者就是为了进一步压榨剩余价值，那员工如果不抵触，我觉得肯定是脑子有问题。但如果你的考核目的是为了激励员工提高工作效率、提升工作质量，并围绕这个目的进行考核设计，我相信正常的员工不会有抵触。原因在于目的决定手段，是奖，还是罚。

考核规则不透明，主要是对于员工对考核点完成情况的评价方式、评估标准不透明。很少见到有公司的 leader 会公开一份像题主列的那么明确的加分 /减分规则。也很少有 leader 敢拍着胸脯说我制定的考核规则是在切合实际的基础上做到尽量公开、公平、公正的。我猜可能是因为他们的考核目的本身就不单纯，又或者他们对自己设计的考核标准是否合理也是心理画着问号的吧（手动围笑）

以上，一些个人观点，欢迎在友好的氛围下进一步讨论，抬杠的就算了，搬砖已经摧毁了我的身体，老了，抬不动了：）

beginor

2019-06-19 11:21:49 +08:00 via Android

@Dex7er 所以，要让程序员的工作产生数据，用数据来考核。摸鱼肯定是少不了的，但是不会让你摸得那么爽

beginor

2019-06-19 11:47:07 +08:00 via Android

@hzgit 说的太对了，佩服佩服！

deepzz

2019-06-19 12:03:06 +08:00 via iPhone

个人挺反感这种方式的，考核应该是用来鼓励

ritaswc

2019-06-19 12:11:09 +08:00

告诉你一个情况。
程序员可能某一天什么活儿都没出。但是他去学习了接下来项目中所需要的新知识。如果不学，项目 100 天完成，因为他学了，可以缩短工期 20 天，并且提高了软件产出质量。
请问各个精明的 hr，你要设计出一个什么样子的 KPI 来评判程序员的质量。
你是希望程序员假装干活儿很热闹，假装一副加班修 bug 的样子
还是希望程序员看起来没写几行代码，但是他就是 bug 少，质量高

q8164305

2019-06-19 12:21:23 +08:00 via Android

@ritaswc 两个人都干掉，把工资给进来就可以 20 天搞定的人

coolair

2019-06-19 12:28:41 +08:00

我觉得一年以后你可以写一篇文章，叫：论程序员的从“同甘共苦”到“反目成仇”。
技术这东西不像销售，比较难量化。在小公司，如果非要用量化来体现员工价值，说明这个管理者的管理水平本身就是有问题的。

alw

2019-06-19 12:39:40 +08:00

这个可谓是世界性难题了，如果能完全做到合理评价那么就能大大推动远程工作了。

beginor

2019-06-19 12:49:53 +08:00 via Android

@deepzz 那么请问怎样鼓励才是合理的呢？

beginor

2019-06-19 12:52:32 +08:00 via Android

@ritaswc 所以考核是分阶段的，按月，按季度，而不失按天。学几天新技术没问题，如果整月都在学习新技术，甚至整个季度都在学习，那就有问题了。

jingyulong

2019-06-19 13:18:07 +08:00

程序员还想考核？预估好工作量，按时完成就好了。要以目标为导向。参考：OKR

jsondog

2019-06-19 14:14:14 +08:00

看 bug 多少吧，不好量化

Edsie

2019-06-19 14:47:33 +08:00

脑力劳动，量化起来比较困难，而且也难以达到相对公平，一旦不公平出现，可能会促使内部矛盾。。。🤐

yuankui

2019-06-19 15:03:58 +08:00

用心去感受~

pipixia

2019-06-19 15:16:04 +08:00 via Android

秃头程度(⑉꒦ິ^꒦ິ⑉)

ww940521

2019-06-19 17:05:16 +08:00

//任务能否按时完成，完成质量是否达标。
工作时长

yuriko

2019-06-19 17:06:37 +08:00

在菊花待了一段时间，深刻认识到，即使像大厂这样花尽心思搞的考评体系，合理性也不过尔尔

mikicomo

2019-06-19 17:26:25 +08:00

@yuriko #52 对的，到头来，你真要较真这个，舔就完事了

beginor

2019-06-19 17:41:43 +08:00

@Edsie 确实是这样，不可能做到对每个人都是公平的。能做到对多数人相对公平的就可以了。

sanqian

2019-06-19 17:46:43 +08:00

考核过加工资么？

mikuazusa

2019-06-19 17:48:39 +08:00

公司只需要定大方向和定大目标，然后落实细化目标给主管，主管自己再去拆分，要给到足够的自由和权力给主管，而不是事事关心！ 30 人的公司也不算小了吧。

beginor

2019-06-19 17:56:18 +08:00

@sanqian 那肯定了

wawehi

2019-06-19 18:37:11 +08:00

看 bug 多少的。。。不知道多做多错么，写越多错越多
看代码量的，也许系统核心部分占 10%，但重要程序也许比 90%的要大的多，开发占时间也可能长的多，难度也可能大的多
所以这玩意其实是真难衡量

Liudong1999

2019-06-19 18:47:36 +08:00

建议楼主找找资料，看阿里或者 Google 对于程序员的绩效考核是怎么样的，看看是否有值得借鉴的地方

libook

2019-06-19 18:57:21 +08:00

感觉 Story Point 可以尝试。
每一个任务是一个 User Story，Story Point 由团队成员共同评定，每个人单位时间可以完成不同量 Story Point，而随着能力提升，一个员工单位时间可以完成的 Story Point 是会增多的，最后根据完成的 Point 数来作为绩效评估的要素之一。

绩效评定可以采用类似 Peer Review|360 Degree Feedback 的方法，需要花费比较多的精力，但是相对公道，不会导致普遍性的反抗，唯一的缺点就是可能会导致死海效应。

jsjgjbzhang

2019-06-19 19:16:06 +08:00

开盘了，猜下可以执行多久，我猜一个月，因为我公司之前用过类似的，在不断变动的需求和填坑之旅后，果断放弃

lijingyu68

2019-06-19 19:23:09 +08:00

想用点数或分数来量化绩效基本都是自找苦吃。

原因有：
1. 分数多的成员干的活的确会多，但干活多会有助于业务成功吗？写代码又不是搬砖。
2. 软件质量的成功很大因素在于团队协作，量化绩效会间接破坏团队协作，损害技术领导的领导自由度，进而阻碍创新。
3. 有的事情无法用点数衡量，但却很重要。比如，对业务的重视程度，技术选择的方向，团队成员能力的建设，促成团队成员的协作，对非技术流程的梳理及知识传递，等等。

那么最好的方式是什么，那就是拆团队，打通团队之间的流动性，考核整个小团队的产出，营造优胜劣汰的环境，并将产出和义务挂钩。

russian

2019-06-19 19:26:27 +08:00

你考核多了，他们会主动挖坑的，本来不需要的坑现在变成必须完成的任务。

你怎么办？

gavindexu

2019-06-19 19:30:49 +08:00 via iPhone

到现在领导还没有告诉我我的绩效怎么定……

wdlth

2019-06-19 23:32:07 +08:00

纯粹用数值来衡量无法正确考核，开发任务的周期、难度、激励都没有考虑进去，简单和难的一样考核，会导致烫手山芋没人接。

seabirds

2019-06-20 00:29:23 +08:00 via iPhone

@Dex7er 孙子？多大仇

beginor

2019-06-20 08:11:36 +08:00 via Android

@seabirds 淡定，不要和这种人生气，不值得，林子大了什么鸟都有。

wmc18064028066

2019-06-20 08:47:16 +08:00 via Android

这种太细了，这样多压抑啊，一起干活，各自负责部分，有错一起分析。这种技术型公司氛围关系越简单越好，反正工资入职已经定了，大家都知道涨薪水基本不可能。

seabirds

2019-06-20 10:00:28 +08:00 via iPhone

@beginor 这吊毛自认孙子，别扯上别人。我认为如何考核也是技术问题，扯上人身攻击的真的没素质。

Dex7er

2019-06-20 10:02:59 +08:00

@lijingyu68 nice，管理者其实只需要关注最终产出，量化团队绩效就可以了。至于团队内部，如何细分到个人，就要放权给团队领袖了。设置一个开放的投诉渠道，对于各个团队内部的不同意见给予重视即可。。。想要给个人员工打分的考核计划，目前见过的几家最终都是走形式，纯属浪费时间。。。

严重赞同摸鱼和处理个人事务是基本人权。。。

Dex7er

2019-06-20 10:05:06 +08:00

@seabirds 自嘲懂不懂捡骂干嘛呢

icharm

2019-06-20 10:12:53 +08:00

只要是用打分，就有空子钻，上有政策，下有对策这个我在一家大厂深有体会，我猜一下给程序员考核的最终目的是什么？
1. 找出优秀员工，升官，找出垃圾员工，干掉
2. 让员工全情投入工作
3. 让开发的产品质量更高
我个人觉得楼主的考核细则还可以，但是如果让员工们知道这些细则，他就知道如何去钻空子，如何去刷分，如何摸鱼，所以我觉得考核可以有，但是不能公开细则和具体的结果，因为不管细则多么完美，考核的结果和实际的情况绝对是有出入的。如 58 楼 @wawehi 所说，具体的工作是很难衡量的，用一个简单的工时是不够的，据一个简单的例子，程序员 A 接到要求 2 天内完成一个 issue，A 可以用自己很熟悉的方式完成这个 issue，只需要一天，但是 A 觉得可以尝试一些新的思路来实现它，可以获得更好的性能，结果 A 花了 3 天才完成。所以 A 的考核垫底，这会打击 A 的积极性，A 从此以后和其他员工一样老老实实完成工作，开开心心摸鱼。
所以一切具体的考核规则，都会磨灭人的创造性和积极性，考核得有，但是不能作为唯一的评判依据。
回到上面的三个目的，第一个优秀的员工自然会随着时间脱颖而出，既然能进入公司的就不能说是垃圾员工，至少一开始不是。
第二个考核不但不能激发员工的工作热情，而且会让员工找到安全的摸鱼方法，想要员工全情工作，估计得在企业文化和氛围下功夫。
第三个保证软件质量，最重要的还是测试，外企的测试流程很规范，可以学习一下，不过完整的测试会拉长开发周期。
既然是软件公司，那么最重要的还是要留下优秀的人，有两种方式，一是靠钱，二是靠联系，联系是什么简单的理解就是让优秀的员工和公司产生更多的关联，让他感觉不仅仅是来打工的赚钱的，所以公司内的各种团建活动，技术交流活动神马的必不可少。

seabirds

2019-06-20 10:35:46 +08:00 via iPhone

@Dex7er 自己当孙子就行，别扯上别人