V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zhang5388137
V2EX  ›  程序员

如何看待公司把开发人员 bug 列入考核?

  •  
  •   zhang5388137 · 2020-02-27 11:47:45 +08:00 · 7019 次点击
    这是一个创建于 812 天前的主题,其中的信息可能已经有所发展或是发生改变。

    开发人员没有驳回权限, 个人感觉不公

    51 条回复    2020-02-29 08:30:18 +08:00
    myd
        1
    myd  
       2020-02-27 12:32:15 +08:00   ❤️ 1
    很好的方案,软件的 BUG 少了,测试人员的绩效也少了。大大节省公司成本
    luckylo
        2
    luckylo  
       2020-02-27 12:33:49 +08:00 via Android
    @myd 然后软件开发部门就是光杆司令了。更加节约成本了
    MangozZ
        3
    MangozZ  
       2020-02-27 12:42:38 +08:00
    主要看能不能体现总体工作量。
    不然就是 “不做不错”
    azcvcza
        4
    azcvcza  
       2020-02-27 13:34:34 +08:00
    请他先定义什么类型的属于 bug,产品想不到的东西不要把锅甩来甩去
    HollowKnight
        5
    HollowKnight  
       2020-02-27 13:36:46 +08:00
    这样的方式,已经在我司实行半年了,颇有成效,挺好
    dilu
        6
    dilu  
       2020-02-27 14:40:19 +08:00   ❤️ 11
    方法可以但是不能一刀切,不然就会出现多做多错、少做少错的情况。

    如果非要启用这种绩效考核方式,最起码有一件事需要保证就是绝对不能压工期,同时插入了别的需求就一定要延长工期。

    同时统计 bug/工时比,我 5 天 5bug,他只有 1 天的任务但是就 1 个 bug,两人的绩效应当大体一致。

    同时应当对 bug 定等级和影响,文案不一致。颜色不一致、位置不一致这种要轻一些。

    测试期间测出的 bug,和上线期间出现的 bug,以及上线很久出现的 bug 定级绝对不能一样。

    不然最后就会变成公司扣钱的一种方式而不是真正的绩效考核。

    顺便说一句,绩效考核的目的是给员工送钱而不是给员工扣钱。

    老板们要明白一句话,重赏之下必有勇夫。你钱给的不够,眼前他们不会说什么,有机会一定会跑的。
    FantaMole
        7
    FantaMole  
       2020-02-27 14:40:47 +08:00
    前提是明确工期是否合理
    longbowape
        8
    longbowape  
       2020-02-27 14:41:45 +08:00   ❤️ 10
    @dilu "绩效考核的目的是给员工送钱而不是给员工扣钱"
    longbowape
        9
    longbowape  
       2020-02-27 14:42:35 +08:00
    赞这一句
    KENNHI
        10
    KENNHI  
       2020-02-27 14:54:17 +08:00
    突然想起来按代码行数算钱的搞法
    很多管理人员就根本搞不明白怎么管理程序员,这不是搬砖小工搬一块是一块,可以随便量化的
    soulmt
        11
    soulmt  
       2020-02-27 14:58:07 +08:00
    如果整个生产流程严谨, 未尝不是个好办法,但是大部分公司都是催命+无脑修改需求的方式来开发业务。。这种要实行这个模式....
    shapl
        12
    shapl  
       2020-02-27 14:59:44 +08:00
    我们把代码行数当做贡献量。。
    loveour
        13
    loveour  
       2020-02-27 15:00:59 +08:00
    @MangozZ #3 +1.不考虑工作量只考核 BUG 那就是耍流氓。
    zjq123
        14
    zjq123  
       2020-02-27 15:15:40 +08:00
    @longbowape 怎么解释很多私企领导人对待下属的态度 "你怎么怎么就扣钱奥" 我第一家实习的公司还每个人每个月的工资都是部门经理写在一张表格上的 所以你想想看好了 你的生杀大权都在他手上
    hantsy
        15
    hantsy  
       2020-02-27 15:20:41 +08:00
    这样的只有一种结果,大家结果都是打酱油,相互敷衍,而不是把事情做好。
    xsen
        16
    xsen  
       2020-02-27 15:22:32 +08:00
    1.评估工期极可能长
    各种可能都要考虑到

    2.把自动化测试都自己搞起来
    开发个小模块小功能,没事慢慢把所有用例过一遍\两遍\三遍,确认没问题再提交测试


    其实一句话就是,把测试的工作顺手就做了,而且要反复多做.测试会轻松很多,建议内部转岗测试
    hantsy
        17
    hantsy  
       2020-02-27 15:23:34 +08:00
    hantsy
        18
    hantsy  
       2020-02-27 15:28:10 +08:00
    BUG 数量能够和绩效持钩,突然想起以前报道那个军方的写了多少 G 代码的美女程序员。。。
    leafre
        19
    leafre  
       2020-02-27 15:28:24 +08:00 via iPhone
    找个降薪的理由,要么忍要么滚
    bk201
        20
    bk201  
       2020-02-27 15:28:29 +08:00
    需要一套科学的计算方法,否则就是不做。
    justin2018
        21
    justin2018  
       2020-02-27 15:28:38 +08:00
    不写代码 岂不是啥 bug 都没 美滋滋~
    shaohan0228
        22
    shaohan0228  
       2020-02-27 15:44:45 +08:00
    少干少 BUG 多干多 BUG
    项目中不会存在 BUG
    BUG 会与所有人有关
    产品会简单的同时更复杂
    anjuyiyu
        23
    anjuyiyu  
       2020-02-27 15:53:39 +08:00
    bug 分级制度,
    bug 所产生环境,
    bug 指派人,实际产生人,实际区分人的定位
    个人工时,
    bug 是一个考核因素。
    不能做全面的考核因素
    nozer
        24
    nozer  
       2020-02-27 16:15:50 +08:00
    兄弟,早点下班吧。

    每天划划水,做慢点,写的越多错的越多。

    时间拉长了,单位时间的 BUG 量不久少了。

    代码总量少了,单位代码的 BUG 总量不就下来了么。

    这分明是福利。。
    xau
        25
    xau  
       2020-02-27 16:24:42 +08:00 via iPhone
    多好啊 哪来的不公?
    lei2j
        26
    lei2j  
       2020-02-27 17:15:20 +08:00
    简单粗暴的 BUG 考核就是对开发的及其的不公。
    wellsnake
        27
    wellsnake  
       2020-02-27 17:18:06 +08:00
    这个标题没有完整的描述清楚,如果是针对一个需求测试反复测出问题来,说明开发的质量存在问题,那么这一类信息如果纳入考核指标内我觉得没毛病
    deep777blue
        28
    deep777blue  
       2020-02-27 17:19:16 +08:00
    不写 bug 的程序员 还是个好程序员吗?
    xy90321
        29
    xy90321  
       2020-02-27 17:22:30 +08:00 via iPhone
    看怎么评价

    我司的绩效考核里也有 bug 评价,但仅限于很恶质、低级、完全可预防或者应该在 merge 到正式分支前自己检知出来的 bug。

    这部分有些有定性或者定量的标准,有些则是需要小范围评审之后决定。

    至于说绩效是给员工送钱,话是没错,但是人家不要你也没办法。

    赏罚不分明,一刀切大锅饭就是对表现优秀的人不公平…
    ChoateYao
        30
    ChoateYao  
       2020-02-27 17:30:11 +08:00
    我们也用 BUG 考核,但是只考核线上的 BUG,功能上线之后出 BUG 就要扣绩效分。
    MrBrand
        31
    MrBrand  
       2020-02-27 17:32:07 +08:00
    把日报质量列入考核咋样?还占 20%!!!
    xinyewdz
        32
    xinyewdz  
       2020-02-27 17:55:54 +08:00
    我们公司有一个专门做项目管理的人员,整天就是发布审核下,催我们写工时,写日报。最近又自己开发了一个软件,准备每天给开发人员打分(根据提交代码行数,bug 数)。
    kurotsuchi
        33
    kurotsuchi  
       2020-02-27 18:04:06 +08:00
    一个月工作 330 多个小时 , 临时救火匆忙上线需求, 测试都没测完就上线, 出了 bug,绩效降了一档, 直接少了 4000 多块, 再这么拼, 我就是狗
    venster
        34
    venster  
       2020-02-27 18:04:08 +08:00 via Android   ❤️ 1
    武汉活生生的例子,让领导看一下不允许出 bug 是什么后果
    pastgift
        35
    pastgift  
       2020-02-27 18:09:44 +08:00
    如果类似外包,东西都设计好了只要程序员老老实实对着做,这个 bug 数量本来就要管理的,作为绩效没什么问题
    如果自己做产品,设计比较粗放,需求经常改,很大程度依靠个人技术水平的,一般作为参考吧。只要不是大量低级 bug,常规流程中的 bug,复杂一点的功能有几个 bug 也没人会说什么。

    不要只看老板怎么怎么样,想象你的同事给你的接口全是 bug,反反复复都改不好,你都看出来了他就是改不好,该判断的异常情况都不判断,搞得自己都没法干活的话,你会觉得外部力量来控制这种情况是有必要的。
    关键看怎么执行的,执行得不好什么绩效都是没有用的
    bengol
        36
    bengol  
       2020-02-27 18:12:37 +08:00
    因为这些,所以还是能去 BAT、TMD 就去吧
    Leonard
        37
    Leonard  
       2020-02-27 18:51:58 +08:00
    不写代码就没有 bug
    charlie21
        38
    charlie21  
       2020-02-27 21:07:12 +08:00 via iPhone
    赞成

    建议写在合同里
    raphael008
        39
    raphael008  
       2020-02-27 21:47:20 +08:00
    上家公司就这么做,然后倒闭了。
    jasamboro
        40
    jasamboro  
       2020-02-27 21:56:14 +08:00
    bug 纯粹看数量还是还得判断什么类型的 bug
    bobuick
        41
    bobuick  
       2020-02-27 21:57:53 +08:00
    每个公司、每个团队情况不一样。不要意淫,自己没在那个位置,没在那个场景不要随便评判就是不合理。

    你一堆博士,自主能力高高的,自觉性高高的,自驱动更没问题,出几个 bug 都羞愧都不行。这团队当然不用

    反之,你往下降几档,降十档你再观摩一下。说不定你来管这团队,你按博士那个团队来管,死都不知道死透了几轮了。
    TransAM
        42
    TransAM  
       2020-02-27 22:03:59 +08:00 via Android
    典型的官僚主义,导致多干多错,少干少错,不干不错。
    lleohao
        43
    lleohao  
       2020-02-27 22:14:11 +08:00
    我们公司还把前端产出的页面数量当作考核项
    WinnieNumberTwo
        44
    WinnieNumberTwo  
       2020-02-27 22:48:23 +08:00
    从细节上来看,看需求文档的撰写者的水平了,这个撰写者可能是产品 /项目经理、可能是 BA、甚至可能是个别程序员自己。

    需求文档能写好的人其实并不多,尤其是公司的小项目组,这种情况如果要实行 bug 数量作为绩效考核的话,其实困难重重,很容易造成技术人员流动。然后项目经理还会甩锅给下面,其实真正的源头都是需求文档写的烂,然后项目经理直接把给客户和领导的 BRD/PRD 原封不动的扔给程序员去做,这种基本上都是高 bug 率的。在大厂做产品或者功能的团队,需求的细化情况反而会好一些,但感觉楼主这个公司不想大厂。
    ziggear
        45
    ziggear  
       2020-02-27 23:19:53 +08:00
    开发人员 bug 列入考核,那就要先问:怎么考核?我想无非就是那几种方案,比如常用的“千行变更 bug 率”——这个规则一旦实施之后其实会引发另一个问题:对于模棱两可的 issue,QA 到底要不要提为 bug ?比如前端开发字体过大(即使需求如此?),很多时候 QA 会提为 bug,严格来说应该分类到“体验优化”的 issue 里,但是互联网公司一切都要求快速推进的节奏,我不知道有多少 QA 团队会去细化和贯彻提 bug 的界限、分拣规则,以及后续的无效 bug 打回或转需求等问题。

    我所在的团队曾经就面临这样一个恶性循环:领导提出要考核 bug 率 —— QA 提 bug 后频繁被打回 —— QA 开始变得谨慎,提 bug 之前先找开发确认 —— 开发效率降低 —— 代码质量下降。所以我个人认为,bug 列入考核确实不合理,但并不是从不公平角度来看的,真正能很好执行考核流程,还能解决上面我提到的问题的团队,相信都是无论是个人的业务能力还是团队的合作能力都非常到位的团队,自然不用太担心 bug 率的问题。

    另外,如果是为了恶心你们,那就另说了。
    xypty
        46
    xypty  
       2020-02-28 10:08:26 +08:00
    绩效给员工送钱。。。。那要是从你工资拿一部分出来做绩效的公司呢
    zhang5388137
        47
    zhang5388137  
    OP
       2020-02-28 10:47:12 +08:00
    @WinnieNumberTwo 是的 非大厂
    lyzy
        48
    lyzy  
       2020-02-28 13:13:37 +08:00
    @dilu 说的好
    winglight2016
        49
    winglight2016  
       2020-02-28 20:52:20 +08:00
    总体来看,搞绩效、KPI 这种东西,唯一的用途就是生成一堆文档,白白耗费大家的时间。。。

    CMM-5 级又如何?须知软件行业,获得 CMM-5 的都是那几家外包公司,真正生产力高的团队从来不玩这些虚的。

    上有所好,下必甚焉。老板或者客户喜欢这些,HR 就来折腾程序员,还有舔狗程序员主动迎合,实在是真正的工贼。
    whywhywhy
        50
    whywhywhy  
       2020-02-29 08:28:25 +08:00
    那就自己测,可以匿名发邮件给大家,每个人都自己测,每天发日报给公司,当公司觉得这个成本不能接受的时候。

    bug 就会被接受。

    有的 bug 是业务上的 bug,那就每次提交的时候和需求提出人确认,最好每一行代码都解释一下,让对方盖章 /签名。

    这些就是你工作的一部分,你都写上。

    另外,别“自愿”加班了,多打几个 12345 电话了解一下劳动法,行政规定,有疑惑就解惑,没疑惑就学习。

    “把 bug 列入考核”,那开发人员就有必要确认清楚需求是否和代码一致,你也是公司的一份子,你也可以要求别人。



    为什么要这样做呢?不是抬杠,是让别人了解一下,要做到这一条有多难,成本有多难以接受。如果公司都接受了,那你接受一下也没什么,大家是来工作的,尽力吧。
    whywhywhy
        51
    whywhywhy  
       2020-02-29 08:30:18 +08:00
    哦对了,自己测 bug 往往难测试出来,开发互相测吧,至少要 3 个人都测试 ok,这样靠谱一点
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1109 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 21:08 · PVG 05:08 · LAX 14:08 · JFK 17:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.