V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
jiangchou
V2EX  ›  职场话题

贵司是怎么考察研发绩效的?

  •  
  •   jiangchou · 14 小时 6 分钟前 · 2108 次点击
    领导让量化研发工作,定性定量考察,难住了……
    想问下 V 友,贵司是怎么考察研发绩效的?
    40 条回复    2025-11-14 01:30:24 +08:00
    kiryu1227267094
        1
    kiryu1227267094  
       13 小时 29 分钟前   ❤️ 1
    统计代码行数
    Lanayaaa
        2
    Lanayaaa  
       11 小时 50 分钟前
    首先 pass 掉只会按部就班做业务需求的人。
    为什么? 因为这是研发应该做的,工资已经包含了这些工作。
    kamikaze472
        3
    kamikaze472  
       11 小时 48 分钟前
    公司业绩好, 就发满绩效
    msg7086
        4
    msg7086  
       11 小时 46 分钟前
    我们现在的研发绩效已经变成问有多少代码是 AI 写的,AI 用得越多越好……
    jiangchou
        5
    jiangchou  
    OP
       11 小时 25 分钟前
    @kiryu1227267094 如果不 CR 的话,可能会堆无效代码;如果都 CR 的话,时间成本太高了。
    jiangchou
        6
    jiangchou  
    OP
       11 小时 24 分钟前
    @msg7086 纯靠嘴说么😂

    我这边新项目 AI 代码可占到 50%,老项目只能到 20%左右。
    你们那边能占到多少
    jiangchou
        7
    jiangchou  
    OP
       11 小时 23 分钟前
    @kamikaze472 好像是这样。公司最近几年业绩不行,没发满过,真实醉了
    jiangchou
        8
    jiangchou  
    OP
       11 小时 22 分钟前
    @Lanayaaa 平时没有绩效,主要是年终奖的绩效,以及汰换依据
    92pretty
        9
    92pretty  
       11 小时 21 分钟前   ❤️ 2
    @Lanayaaa 把本职工作做好,不出问题才是最重要的。虚头巴脑的搞什么拔高,最后还是会卷到自己身上。
    ZXYF
        10
    ZXYF  
       11 小时 18 分钟前
    加班时长
    aiwoshishen
        11
    aiwoshishen  
       11 小时 15 分钟前 via iPhone
    @Lanayaaa 牛逼牛逼 会做事儿的 pass 掉,绩效都给做 ppt 的?
    wecgwm1998yichen
        12
    wecgwm1998yichen  
       10 小时 37 分钟前
    不统计代码

    统计每个需求拆解后的工时数会不会好点,这个工时由执行者和他的+1 预估

    然后另一个维度是 bug 的比例
    lysf0515
        13
    lysf0515  
       10 小时 16 分钟前
    没有绩效,纯纯基本工资
    0987363
        14
    0987363  
       10 小时 15 分钟前
    看老板心情
    tclm
        15
    tclm  
       10 小时 10 分钟前
    1.没绩效
    2.每月会统计代码行数并公布排名
    3.我是外包
    lswlray
        16
    lswlray  
       10 小时 5 分钟前
    开发人员的绩效考核可不是简单的事儿,需要有多个制度配合
    目前国内互联网企业中的管理者,会正确考核的人很少

    简单来说,就是: 工时制+技术职业通道+专家组+工作量评估,导向就是:多劳多得、上不封顶

    我之前空降一家企业时,他们实行的固定薪资+年终奖模式,大部分人都缺少工作积极性、天天划水摸鱼
    我和老板要了支持、按照我的要求实施上述规定,然后第一个月、大多数人还不相信,我就找了一个中等绩效的、鼓励他理解和积极抢工单,结果月底核算,这个人当月奖金累计底薪超过了 7 万,之后开始大家立刻都主动了起来,因为工作的每一分钟都有自己可以核算出来的回报。
    JacksonC
        17
    JacksonC  
       9 小时 59 分钟前
    @lswlray 程序员做 1 小时工作,然后再让其他人花 1 小时来评估这个人这 1 小时的绩效?
    lswlray
        18
    lswlray  
       9 小时 57 分钟前
    当然不是 @JacksonC
    8byte
        19
    8byte  
       9 小时 57 分钟前 via iPhone
    代码行数有点扯,啰哩啰嗦搞几个大函数,谁受得了
    p2007
        20
    p2007  
       9 小时 24 分钟前
    下一步是不是准备裁员了
    imesrdfi8dzs
        21
    imesrdfi8dzs  
       9 小时 24 分钟前
    @lswlray 工单模式,让我想起了我以前待的一家公司:取消各种福利,采用工单多劳多得,第一个月大家都很积极肯干,第二个没有工单都不肯干活,第三个月限制工单发放、工单奖励减半,第四个月只发工单奖励近乎于无(费劲巴拉搞一天的工单,买不起两支可乐),后续时间全是工单,没有奖励。

    并不是说这模式不好哈,只是有所经历,感慨一下
    lswlray
        22
    lswlray  
       9 小时 15 分钟前
    所以我第一句话就强调了 [需要有多个制度配合] —— 工单制需要和其它制度配合一起实施才有价值,显然你们领导只知其一不知其二,学了一个皮毛,有这样的结果不足为奇。 @imesrdfi8dzs
    zsc8917zsc
        23
    zsc8917zsc  
       9 小时 11 分钟前
    @imesrdfi8dzs #21 工单绩效的前提是,这个工单真的值这个钱,否则赔死老板
    midsolo
        24
    midsolo  
       8 小时 51 分钟前
    @lswlray #16 以前在港企就用的这一套模式,有个任务池,需求全放在这个池子里,自己手头上的活干完之后,可以向 leader 申请一个 ticket ,leader 会根据实际情况评估,是否给你发放 ticket ,如果给你发放,你就可以用 ticket 去任务池领取新任务。

    需求量最多的那个月,除了工资之外,我多拿了 4w 港币。后面公司来深圳搞分公司,这套制度就玩不转了,老板说大陆人太卷,平均每天可以干 14 个小时,1 个季度的需求被我们 3 周就干完了,他去哪找这么多需求给我们干。
    Lanayaaa
        25
    Lanayaaa  
       8 小时 44 分钟前
    @92pretty #9 标题讨论的是绩效,什么叫绩效?或者说为什么你能拿好绩效,别人拿不到好绩效。 如果都是做本职工作,那大家一开始就可以躺平了,分到好活的绩效好,没有好活的直接摆烂等死就行。
    Lanayaaa
        26
    Lanayaaa  
       8 小时 44 分钟前
    @aiwoshishen #11 然而,事实就是这样
    sxms77777
        27
    sxms77777  
       8 小时 33 分钟前
    对每个任务进行估点,注意不是人天,是客观工作量估点。 比如 写个登录界面是 1 个点 那么写个登录加注册就是 2 个点。 然后每个月对完成的点数进行考核
    lswlray
        28
    lswlray  
       8 小时 26 分钟前
    @midsolo 你们对工单的内容还是少了一些东西,例如:在我们的规范中,一个开发工单包含的不仅仅是对应的代码,还包含对应比例的注释,一般要求 1 个小时写的代码、至少要有 0.5 小时写注释。再比如,我们还有技术研究工单,就是对一些新技术的研究任务;有会议工单,就是参加产品经理组织的产品评审会议等;有学习工单,就是内部技术交流会议;有测试工单,就是配合测试进行的调试和开发任务等等。 一个成长的团队,工单是不缺的。
    kristofer
        29
    kristofer  
       8 小时 26 分钟前
    随便定吧,考察指标与实际绩效不是正相关。
    poiz
        30
    poiz  
       8 小时 22 分钟前
    看老板心情。
    Tuee
        31
    Tuee  
       8 小时 14 分钟前
    主要还是看公司赚不赚钱,不赚钱哪里有钱发绩效?赚钱也不用去考察,统一都发,很多东西都不是通过数据库考核能简单评价的
    Lee2019
        32
    Lee2019  
       8 小时 8 分钟前
    看领导心情
    msg7086
        33
    msg7086  
       6 小时 18 分钟前
    @jiangchou 我们是定期开会然后研究多少人在开发中用 AI 跑,然后上面还给我们做了各种 cline workflow 让我们来用,用了以后还要填反馈问卷,然后老板还要来问多少人平时用了 AI ,用得怎么样,节约了多少时间,等等。我们也是刚开始搞这东西。
    92pretty
        34
    92pretty  
       6 小时 11 分钟前
    @Lanayaaa #25 本质工作是什么?时保质完成需求才是工作第一要义。如果阶段内某一个人的本职工作没有出现任何纰漏就应该是 A, 有人天天向上管理,搞 demo ,写 ppt ,搞再多可扩展组件,只要负责的功能需求出现一点问题,那么他就是 B-。

    想想公司找你来是干什么的?本质工作就是你来公司的本质价值,这个考核比例应该是 80%,甚至 90%
    92pretty
        35
    92pretty  
       6 小时 10 分钟前
    @92pretty #34 按时保质
    queue
        36
    queue  
       5 小时 49 分钟前
    @sxms77777 #27 谁负责估点,谁来保证估点的客观性
    laminux29
        37
    laminux29  
       4 小时 13 分钟前
    研发方向是无法进行绩效量化的,因为研发类的成果产出与时间并非简单的线性关系。

    历史上有两位诺奖得主就经历过这种事情,Kenneth Wilson 、Peter Higgs ,他们所在学院实行绩效化,曾因多年无绩效产出,差点被裁员。

    大厂的某些重要组件,比如某厂的云服务,也是经历过几年的改进,才达到商用化的程度。如果用绩效去考核,项目开始的前几年,绩效有可能为零。

    而且研发还有失败的可能与风险,但这并不能说明研发是在摸鱼。

    业界对研发进行监督的方法,一般是通过评估研发的计划、数据与报告来实现的。
    drydiy
        38
    drydiy  
       3 小时 52 分钟前 via iPhone
    @Lanayaaa 你没病吧?工资包含这部分工作,那把这部分工作做好不就是配拿这部分工资了?这不是绩效好?那些写 ppt 的人你叫他来写代码能没有 bug 吗?脱实向虚迟早完蛋。
    enihcam
        39
    enihcam  
       1 小时 50 分钟前
    零、
    首先,单纯拿代码行数来考察研发绩效的都是“弱智耍流氓”。

    一、
    代码行数是债务,功能特性是价值。
    代码行数是分母,功能特性是分子。

    二、
    缓解债务的办法是通过有效单测覆盖。
    无效单测不是技术问题,是职业道德问题,需要 HR 介入,即时劝退。

    三、
    量化公式:价值 /(代码总行数 - 有效单测覆盖行数)
    注:“价值”选择有代表性的业务指标形成综合指数代替。
    Lanayaaa
        40
    Lanayaaa  
       14 分钟前
    @drydiy #38 似乎你没明白什么叫做好绩效。这样说吧,你就当年终奖(比如 1-3 个月的工资)。那么问题来了,你把本质工作做好没毛病,那么工资正常拿也没毛病,但是为什么有的人是 1 个月,有的人是 3 个月?为什么裁员的时候裁你而不是裁别人?
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1186 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 17:44 · PVG 01:44 · LAX 09:44 · JFK 12:44
    ♥ Do have faith in what you're doing.