这是一个创建于 1827 天前的主题，其中的信息可能已经有所发展或是发生改变。
不足十人 Web 小团队.
目前公司按 bug 数量扣分, 写的越多扣的越多. 想改一下.
目前公司按 bug 数量扣分, 写的越多扣的越多. 想改一下.
 |
1
ly4572615 2019-12-27 10:00:35 +08:00  3
这么点人还盯着错误搞 kpi
|
 |
2
liqiangzjhzz 2019-12-27 10:02:04 +08:00
bug/任务 比
|
|
3
liqiangzjhzz 2019-12-27 10:02:29 +08:00
和开发量
|
 |
4
SlipStupig 2019-12-27 10:08:53 +08:00 13
这种团队 KPI 本身就不靠谱，团队 loader 应该像教练一样提高队员水平，激励和鼓舞士气，确立明确的目标。而不是想着去惩罚，你越惩罚越逆反，正确的方式应该对整个团队进行激励，比如每次按时完成一个大版本发布，给所有开发团队发一点小纪念品（比如：2.0 上线纪念章，这种需要花点小心思），这一切前提是团队靠谱，不靠谱的团队，用任何方式都无法进行推进！
|
 |
5
geying 2019-12-27 10:12:11 +08:00
建议用代码行数评
|
 |
6
cloverzrg2 2019-12-27 10:20:42 +08:00
在这种团队我肯定辞职
|
 |
7
Cabana 2019-12-27 10:23:06 +08:00 via Android 1
天天划水不敲代码，是不是绩效就第一了🤪🤪？
|
 |
8
shawndev 2019-12-27 10:26:53 +08:00 6
@SlipStupig 团队 loader 可太秀了。。。
|
 |
9
ciscoray 2019-12-27 10:29:52 +08:00 via iPhone
缺陷率
|
 |
10
NotFoundEgg 2019-12-27 10:30:00 +08:00
不到 10 个人还搞这些 是不是再排个 A+ A B+ B C....
|
 |
11
nevin47 2019-12-27 10:37:25 +08:00
建议考虑下 OKR
|
 |
12
FreshUncle 2019-12-27 10:43:01 +08:00
写的越多 bug 越多，扣的越多，不如不写，想出这种绩效方法的，也是人才
|
 |
13
pecopeco 2019-12-27 10:43:39 +08:00
有此公司名，建议黑名单
|
 |
14
goldpumpkin 2019-12-27 10:44:22 +08:00
看你的目的是要什么。搞队友，还是做好事情
|
 |
15
fatpower 2019-12-27 10:45:37 +08:00
做的越多 bug 越多 扣的越多 哈哈
|
 |
16
demoxu 2019-12-27 10:45:39 +08:00 1
考虑过 bug 产生的原因么？是需求阶段产生，还是架构阶段产生还是纯粹的代码 bug
楼主的公司有固定的流程么？ |
 |
17
classyk 2019-12-27 10:47:34 +08:00
人数太少了放弃 KPI 吧
|
 |
18
robot1 2019-12-27 10:51:05 +08:00
这样就能当领导了?
|
 |
19
luozic 2019-12-27 10:52:44 +08:00
人数太少了, KPI 不具有實際的工程效益
|
 |
20
passerbytiny 2019-12-27 10:53:24 +08:00
楼上嘲笑 bug 数量的，大概不了解实际情况。我猜这是接小型外包（或者 N 次分包后）项目的公司，（客户提出的） bug 数量直接影响能不能收到中款和尾款。我不评价这种评价方式的好坏，我只点明这种评价方式是完全不可行的，因为：客户提不提 bug，提多少 bug 是完全不受开发团队控制的。
|
 |
21
aut0man 2019-12-27 11:04:29 +08:00 1
马一下 晚点回来看。目前的做法是：开发人员和开发 boss、产品一起评定开发时间，开发人员说完后，boss 视情况砍时间，然后定下的时间就按时间走。bug 你随便写，但是耽误进度的部分自己加班解决。一切结果导向，不耽误进度就行；但是要是每个部分的内容都完不成，往后堆积一定会影响进度的，这种要提前说。大家计划也要变，但是相应的对这个人的评价就会降低。
|
 |
22
wangxiaoaer 2019-12-27 11:19:17 +08:00
怼楼主的，我觉得不一定合理吧。
KPI 大了点，换个词吧：绩效。 如果量化开发人员的绩效？因为绩效涉及到收入，这个跟什么团队士气没关系。 |
 |
23
Eirxxx69 2019-12-27 11:21:36 +08:00
每次迭代开发人员 bug 数量不能超过 10 个，测试人员提 bug 不得少于 10 个。没有完成的就扣 kpi ！
|
 |
24
deletemyself 2019-12-27 11:42:36 +08:00
这得定义好 bug 的含义
比如： 细节性的错误提示、文字之类的没做规定测试时产品或者领导觉得文字不友好之类的； 同一段文字不同人理解的不一样做出了也有差别； 产品描述没有提到的情况等。。这就不算 bug |
 |
25
janxin 2019-12-27 11:46:13 +08:00
没有固定标准，KPI 应贴近团队实际和方向引导期望
|
 |
26
SkyCity4NJ 2019-12-27 11:53:20 +08:00
这种按 bug 数量扣分的团队要多恶心就多恶心。he tui：）
|
 |
28
MrJeff 2019-12-27 11:58:47 +08:00
人日 bug 率为主 千行 bug 率为辅 以 Bug 数量评判实在垃圾！
|
 |
29
luckylo 2019-12-27 12:09:08 +08:00 via Android
先不说 10 个人搞什么 kpi 的问题。你有惩罚，有奖励没？然后再说 bug 追责问题。线上 bug 肯定是问题。测试环节呢？如果真要追责，产品，和动嘴皮子的项目经理有责任没。
|
 |
30
Sapp 2019-12-27 12:13:12 +08:00 2
十人的团队还搞 kpi 纯粹是管理人员不作为，这点人，哪个干活哪个没干活不是管理心知肚明吗？ 十个人如果心里都没数，让他管几十几百个人还得了？
|
 |
31
mhtt 2019-12-27 12:36:37 +08:00
看到小公司搞 KPI 就头疼。
说件自己的经历，十几年前在一家老板超有钱的小公司做系统开发，一共就两个开发。 某一月的晨会，老板突然说现在业务员太懒散了，为了让大家有积极性，从这个月开始搞绩效考核，原本每个月工资的 30%是绩效工资，也就是说自己绩效考核不过，能保证拿到手的只是原来工资的 70%。当时业务员没人说话，我们两个开发私心的认为当事人都不反对了，我们两个外人反对个屁啊。 谁想自己还是太年轻了，那个月老板让公司所有的人七点多到地铁站发传单，没错我们两个开发也要去，发了两次，我特码的还搞感冒了（冬天）。然后当月发工资的时候，每个人的工资都被不同程度的绩效了，包括我们两个开发。去领工资时，财务和我说因为我平时工作比较用心，做事情效率高，所以我是扣得最少的，只扣了 10%，我当时就吼了，凭什么扣我？我哪一样工作没做到位？你们是怎么想的，通过业务员的方式来算程序员的绩效？本来我就是固定的死工资，又不像业务员一样有提成，我被扣成这样，我怎么生活？吼到很多人来安抚我，我当时就觉得吧，这公司我得走，这里很多人都有一种叫斯德哥尔摩的病。 比较幸运的是，没过两三个月，我合同到期了。后来我对老板做了一件非常恶心的事情，他一直以为我会续约，至少他看我的确是会续约的样子，但我在合同到期前几天休年假，等待合同到期解约。（其实这招是向另外两个同事学的，一个是业务部的同事一个是和我一起的那个开发同事，开发的同事合同在我前两个月到期的，他被绩效后的下一个月就休年假，合同到期不续约了） |
 |
32
jobtesting 2019-12-27 12:45:59 +08:00 via iPhone
从质量、效率、团队贡献和固定项目等入手编写。
|
 |
33
alexmmog 2019-12-27 13:17:44 +08:00 via Android
别看 KPI 了，看下 OKR
|
 |
34
gaoyadianta 2019-12-27 13:27:22 +08:00
OKR 了解下
|
 |
35
whypool 2019-12-27 13:40:39 +08:00
会不会扣成倒贴？
|
 |
36
yhxx 2019-12-27 13:55:36 +08:00
10 个人怎么就不能搞了
你看某 enjoy 公司只有 2 个人的小组也要强制至少一个 3.25 ，然后组长不参与组内考核，于是。。。 |
 |
37
encro 2019-12-27 13:59:54 +08:00 1
搞 KPI 通常是因为失去方向了，
或者魅力不足希望制度来补。 通常的考核方案： 1，做的越多 BUG 越多； 2，做得越快任务越多； 3，代码越差看起来越勤劳； 4，代码越好看起来越闲； 所以考核前，先思考为什么要考核，如果不知道就无法给出方案。 如果公司能够执行 OKR，是可以考虑一下的。 |
 |
38
zhlssg 2019-12-27 14:00:39 +08:00 1
@gaoyadianta 老板傻逼的话，搞 okr 也会搞成 kpi
|
 |
39
geekvcn 2019-12-27 14:01:59 +08:00
有罚就要有奖，不然人家会认为你针对他，你现在的管理模式最好的改进就是加一条，BUG 少或者每=没 BUG 的给对应奖励，光罚不奖长期会出问题
|
 |
40
fancy111 2019-12-27 14:05:25 +08:00
工作责任分配到人，KPI 指标根据职位来定，奖惩得当。不要搞得含糊不清，人人不满。
另外，把什么是好什么是坏的标准定好，优秀的员工根本不需要什么 KPI |
 |
41
fzzff 2019-12-27 14:05:29 +08:00
@passerbytiny 先点名别人不了解情况,然后再来个"我猜" 哈哈哈哈,你也是个人才
|
 |
42
ww2000e 2019-12-27 14:07:34 +08:00
数代码行数
|
 |
43
ares586 2019-12-27 14:07:34 +08:00
大公司是什么样的？我们公司是按加班时长给考评的。。。
|
 |
44
wangyzj 2019-12-27 14:18:52 +08:00 1
即使 OKR，问题是这种老板有能力分好时间和工作量么？
|
 |
45
fengmumu 2019-12-27 14:26:25 +08:00
楼主的意思是现在是数 Bug 来做 lpi，所以他想换个，一群人开始喷，他也不是决策者啊，只能说 庙小妖风大，池浅王八多 想要高效率，低故障，钱，技术，时间缺一不可，光想靠规则来压人，不可能的，奉劝楼主好好抽抽时间准备换个公司，不要想这种东西了
|
 |
46
loryyang 2019-12-27 14:27:31 +08:00 1
总共就 10 个人，作为 leader 就应该了解每个人在做什么，做得如何，对于他们的绩效，你需要有绝对的话语权。如果 leader 觉得不清楚，无法评估，那说明沟通不到位，leader 工作有失职之处
量化的 KPI 指标，比如代码量，bug 量都应该只成为合格的标准，达不到的算不合格，超过都算合格。量化指标有非常大的问题，主要问题在于，量化指标无法完整刻画产出的质量。KPI 本身力量太过强大，只使用量化指标，最终一定会生成畸形的评价体系，对项目发展绝对是有害的 所以最终还是主要靠人来做评估，如果你要说 leader 可能评估不公正。首先没有绝对的公正，其次疑人不用用人不疑，要相信 leader，最后选择合适的下属本来就是每一级都需要认真考虑的事情 一个团队，管好人其实就成功了一半了 |
 |
47
loveour 2019-12-27 14:31:38 +08:00
我当初因为类似考核原因特别想离职的，后来也果然走了。当时有段时间组内一半的版本是我出的，我还要被扣绩效。其实当时的 leader 也觉得不对，年末年终奖给我的就比较高。但是我那段时间就很不爽。
|
 |
48
penis 2019-12-27 14:50:38 +08:00
赶紧辞职吧 垃圾公司 还按照 bug 数量扣分，笑出声
|
 |
49
IGJacklove 2019-12-27 15:39:06 +08:00
最后领导的小舅子因为一行代码没写获得年度最佳程序员
|
 |
50
AEANWspPmj3FUhDc 2019-12-27 16:14:35 +08:00 via Android
这样的话，如果和某人有矛盾，可以去报告对面的 bug
|
 |
51
weizhen199 2019-12-27 16:17:13 +08:00
越小越适合人治
|
 |
52
orange200310 2019-12-27 17:08:09 +08:00
@mhtt 其实老板是想裁人了只是让你们自己走吧。 这样还没赔偿
|
 |
53
zhiguang 2019-12-27 17:16:15 +08:00
不写那不就没 bug 咯
|
 |
54
Justin13 2019-12-27 18:49:40 +08:00 via Android
人数少不需要 kpi 机制，倒是 okr 很合适
|
|
55
mhtt 2019-12-28 00:53:53 +08:00
@orange200310 然并不是
|
 |
56
yaaaaaak 2019-12-28 08:33:51 +08:00 via iPhone
前公司考核内容包括交付质量、技术影响力和业务有效成果。所以只要你呆好部门好项目，再做点随便乱七八糟的技术分享，不加班 kpi 也随便吊打苦哈哈的加班狗。
|
Select Language