This topic created in 2530 days ago, the information mentioned may be changed or developed.
 |
lietoumaiDec 3, 2019
1
领导：忙什么呢？
撸主：忙着写 Bug 呢 |
 |
Risin9Dec 3, 2019 via Android
3
我们公司要出个根据解决 bug 修改文件的提交记录追溯 bug 的责任人的系统，有点扯...
|
 |
oott123Dec 3, 2019 via Android
4
bug 越多工资越高吗
|
 |
opengpsDec 3, 2019
5
有参考意义：
bug 太少可能存在隐含问题开发私吞了等原因 bug 太多则可能是业务复杂或者水平不够等情况 但是 bug 数量一定不能用来形容项目质量好不好 |
 |
learnshareDec 3, 2019
6
总要找个办法裁员嘛
|
 |
7
想想，为啥这种人都可以做经理。
你细品。 |
1 |
Frank520Dec 3, 2019
8
我们 CTO 看 bug 数量评绩效
|
 |
q8515620Dec 3, 2019 via Android
9
你还没说经理的考核标准。
越多越好：说明工作量饱和？ 越少越好：说明代码质量高？ 是哪种呢？当然，这两种情况都不应该作为考核标准。 |
 |
10
@php01 我没觉得我们经理有问题，这个事我也说不清好坏，想听大家各个角度讲讲。但是您的逻辑好像有点不对，一个人做了一件脑残的事，不能说这个人做啥都脑残。
|
 |
golden0125Dec 3, 2019
11
只有惩罚,没有奖励的机制都是耍流氓
|
 |
coderluanDec 3, 2019
12
如果你签合同时候不涉及绩效相关内容，就没任何问题。否则的话，就不好说了，可能是单纯的作为绩效标准，只要不是唯一标准问题就不大，也可能是为减薪或者裁员做铺垫和找理由。
|
 |
RwingDec 3, 2019
13
那么如何统计 bug 数量呢？是不是可以徇私？
|
 |
bkmiDec 3, 2019 via Android
14
所以你们没一个人能提出异议，并且怼回去，就这么执行了？
|
|
anterosDec 3, 2019
15
@cong 在这个遍地是机会和选择的时代，选择一叶知秋观人法是性价比最高的办法。
特别是当你脑袋里的样本库足够大，分好类的时候。 比如，据我观察，中医的拥趸者，大多也对反转基因有兴趣。比如大多数基督徒和佛教徒是伪善的，不可交，满嘴谎言，话不可信。 虽然会有误伤，但是性价比高。 |
 |
16
有啊。 测试部门还以此来发奖金，有一个刚毕业的测试妹子，同一个 bug 给我提了 5 次，然后我不干了。
|
 |
beidounanxiziDec 3, 2019
18
拿这个 来当做绩效裁定 也不会被劳动仲裁部门 支持的呢 需要你确认同意
|
 |
fhsanDec 3, 2019
19
就和 kpi 一样，最大多数人的最大价值相对可靠的计算方法
|
 |
fenDec 3, 2019
20
BUG 不能作为唯一标准。
但 BUG 多的人，要么需求理解有问题，要么水平真不行。 |
 |
NonClockworkChenDec 3, 2019
21
@fen 难道不能是需求本身不合理或者文档不够清晰吗
|
 |
xcstreamDec 4, 2019
22
考核 2 个字就是有恶意的，不管什么指标
|
 |
chinunoDec 4, 2019 via Android
24
bug 数量做考核没有，但是以前有过提交 patch 数做绩效考核，要求每个人每周至少提交十几个 patch
|
 |
jrtzxh020Dec 4, 2019
25
我们公司，bug 是 kpi 一个指标哦，当然是指生产上的 bug。。
|
 |
aut0manDec 4, 2019
26
这不应该是..很正常的吗。我司一个后端，我来的时候她就在了，开发个模块，bug 不断，提了改，改了提。一周过去了，刚把一个模块写好（一般人 2-3 天吧），我看了眼 sql，一言难尽。你说这种的你不考核一下，年底了，她和别的开发又快又好的领一样的钱，别人不难受？那不成了劣币驱逐良币？（当然我入职后没俩月她被辞退了）
|
 |
luckbbsDec 4, 2019
28
对测试部门来说很正常
|
 |
aobocoDec 4, 2019
29
不扣钱就行了
|
 |
zjl03505Dec 4, 2019
30
这需要看 bug 的权重以及是否是唯一的绩效考核点来评判，若并不是唯一的且不是占据主要权重并没有什么不可接受
|
 |
flankechenDec 4, 2019
32
其实，怎么衡量程序员的工作量就是一个天大的难题，不知道有没有管理大师研究过这个问题了
|
 |
lagoonDec 4, 2019
33
没啥好说的。所以那么多人，要爬到管理位。
人家权力大，就是为所欲为。 |
 |
hantsyDec 4, 2019
36
哈哈，那些开源项目，要是这样评价就完了。
一个开源项目是否活跃，流行，Bug 数据是最基本的依据。如果你关注一些国外的技术大会，经常在介绍一些新兴项目的时候，他会给一个统计图，我们 BUG 数量从去年的 XXX 增加到今年的 XXX，来说明这个项目关注的人数急剧的增加。一个没有 Bug 的软件，只能说这个软件没有人用，只要有人用怎么会不提 BUG。 有这种想法的公司说明领导可能以前真的是搬砖的，认为软件和 BUG 都是死的，就和砖一样，搬了一块少一块。 |
 |
tabris17Dec 4, 2019
39
以后就不叫 bug 了，叫 feature 吧
|
 |
DarrenLuoDec 4, 2019 via Android
40
我能说有公司拿代码行数来玩的麽
|
 |
ErroadDec 4, 2019
41
可以作为指标，但是要综合开发量、工期、任务难度才行
|
 |
m0moDec 4, 2019
42
我之前有家公司是这样，结果有个牛逼的同事写复杂点的逻辑都直接 catch Exception
|
 |
jason19659Dec 4, 2019
43
少写少错？
|
|
aut0manDec 4, 2019
44
@hantsy 我之前是认可 bug 数量统计这一套的。看了你说的觉得很有道理...那什么维度评价开发才是一个比较合理的评价体系呢？（喜欢可以说详细点，忙的话随便点我两下，printf “thx (σﾟ∀ﾟ)σ..:*☆”；）
|
 |
MmdhejxDec 4, 2019
45
好像之前看过类似的帖子……
|
 |
300Dec 4, 2019 via Android
46
快年底了
|
 |
zhiguangDec 20, 2019
47
我不写不就没 bug 咯
|
Select Language