研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

02 | 效能度量:效果不好甚至有副作用,怎么回事?

葛俊 2019-08-26
你好,我是葛俊。今天,我来和你聊聊研发效能的度量。
在和技术管理者,尤其是高层管理者聊起研发效能的时候,常常提起效能的度量这个话题。管理学大师彼得 · 德鲁克(Peter Drucker)曾经说过,“一个事物,你如果无法度量它,就无法管理它”(If you can’t measure it, you can’t manage it)。要想提高研发效能,自然要首先解决效能的度量的问题。
在软件研发过程中,数据驱动的手段被大量采用,比如说通过使用漏斗指标和 A/B 测试,用数据来指导产品的方向。按理说,软件开发行业是数据驱动的高手,用数据驱动来理解研发效能应该早被研究透了啊。
但事实上,效能的度量却是一个出了名的难题,至今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此,绝大部分软件公司在使用研发效能度量这个工具时,不但没有起到正向作用,还伤害了产出和团队氛围。
所以,在今天这篇文章中,我就与你一起看看研发效能度量到底是什么、常见错误,以及度量困难的原因。

研发效能度量的定义和作用

首先,我来介绍一下效能度量的定义和作用。
研发效能的度量代表一组可量化的数据或参数,用来跟踪和评估开发过程的“健康”状况。 换句话说,研发效能的度量,从应用程序开发的生命周期中获取数据,并使用这些数据来衡量软件开发人员的工作效率。我们希望通过这样的度量,能够根据客观的数据而不是个人的主观意见去决策,从而实现以下几点:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • 陈大宏
    代码行数和 bug 数量这两个无聊的指标。居然都在公司的绩效考核中出现了。无语。

    作者回复: 根本原因是:不知道怎么样度量开发人员的绩效。就是用了这两个指标作为Proxy。

    2019-08-27
    3
    7
  • 囧囧冰淇淋
    1.研发效能的定义和作用
    研发效能的度量,从应用程序开发的生命中期中获取数据,并使用这些数据来衡量软件开发人员的工作效率。
    主要为实现三点:
    1.跟踪团队的表现、提高团队的绩效。
    2.提高项目计划的准确度。
    3.了解流程是否高效,寻找需要改进的关键领域。
    达到度量目的:简化流程、发现瓶颈、帮助团队改善产品生命周期、更高效地产出质量更好的产品。

    理解:关注团队的表现,团队的成长;关注项目的准确性,不要经常走弯路;关注流程的高效,实现迅速,也方便新人快速加入。
    工作都是人去做的,首先关注人、团队,而不是数字。关注人,给予团队支持和信心,即使走错路了,大家会一起想办法一起努力。关注数字,人和团队就可能发生数字造假或者数字失效,比如案例1和3。

    个人碰见的数字造假:
    客服团队造假。某天,老板想优化下客户服务,从客服下手,根据行业标准定出了一个指标,询单转化率、回复率、回复时长、未回复数,这些指标再分解成工资。老板十分鸡贼,算了下认为这可以提高客服工资,店铺转化也可以提升,双赢。然而客服团队一算,只有达到一个高标准,才会比以前工资高,只有平均就比以前差几百。客服们很抱怨,但当面也说不赢老板,于是发明了过墙梯:对于回复率呢,以前一句话说完,拆成2-3句。回复时长使用表情大法,先来一个表情缩短时间。最后客户服务没有优化,转化率也没提升,客服团队怨声载道,当时能力有限,感觉也对不起他们。

    作者回复: 你认真学习,不断追求进步的样子真是棒!!

    你讲的客服例子很有意思。我记得以前好像是亚马逊还是哪个公司的客服也出现过类似的事情。

    2019-08-26
    2
    6
  • 西西弗与卡夫卡
    写的很好,有点等不急,好想催更

    作者回复: 多谢支持!后面有问题建议欢迎啊 😀

    2019-08-26
    4
  • stefli
    我们目前是基于scrum的软件数据来粗略跟踪一些执行过程数据。包括:每个迭代的周期数据,估算与实际登记数据,线下和线上Bug数据,Bug分类数据,团队成员任务及估算、实际工时等。从这里也能看出一些信息:
    1. 估算与实际操作之间耗时是否匹配,准确度是多少,基本在70-80之间,除了造假数据。造假的化可以拿每日登记情况进行粗略判断
    2. 每个职级团队成员的大致行为,比如单位用时产生的Bug数量,每个迭代的平均任务数,Bug等,包括大致每个任务的平均估算时间。有的大概在3-6小时一个任务,拆分越小越容易把控进度。有的团队平均是8小时一个,时间会比较“充裕“
    3. 随着质量团队和研发团队质量意识的提高,月度Bug或线上Bug有减少,质量在提升。临界点尚未得到,到时再观察任务数、估算等数据
    总的来说,数据可以来自多方面,至于如何去用,还需要更多的研究和分析

    作者回复: 我的经验是这些数据可以用作参考,帮助团队改进,但是不要跟绩效直接挂钩。

    “随着质量团队和研发团队质量意识的提高,月度Bug或线上Bug有减少,质量在提升。”这个就是度量可以用来参考,它显示出来一个趋势。👍👍 (不过要注意单个指标有的时候可能不全面。比如bug减少,会不是因为功能减少等其他原因?当然这只是随便的一个例子。)

    2019-08-27
    2
  • 🌀Pick Monster 🌀
    我们公司现在受制于客户,每月要求1000行代码量达标,我作为基层管理,主要代码都有团队成员编写,而我除了客户对接,需求分析和算法设计之外则主要编写关键点和优化点代码,每个月代码量都无法达标,给领导各种解释啊。而且公司严管外网访问,我作为团队首领也是没有外网权限,只能有手机查看需要的资料。这样的开发环境很难高效开发。

    作者回复: > 每个月代码量都无法达标,给领导各种解释啊
    领导能理解吗?1000行代码量是客户要求的吗?如果你能说服你领导你的工作提供了足够的价值,问题只是客户那边不理解的话,那就比较好办。说服客户,或者可以把一行分成两行写。如果你不能说服你的领导,就比较麻烦了。

    > 只能有手机查看需要的资料。这样的开发环境很难高效开发。
    这个的确是麻烦。可以花点时间研究一下手机上学习的工具。同步手机和电脑的工具应该是比较有用。比如:Pocket(https://getpocket.com)用来记住感兴趣的URL,Evernote,Mac Note,OneNote,等等用来记笔记,讯飞输入法可以记录有声笔记,等等。

    2019-08-27
    3
    2
  • Geek_98dc22
    常见研发效能度量失败的案例应该归属量化的绩效考核,为了追求较好的绩效指标,采取以绩效指标为目的的工作方式,导致忽视了本职工作,也间接伤害了那些以团队利益为出发工作的员工。
    对于度量,没有经验,但个人觉得团队度量会比个人度量更好一些,促进团队的成长,也促进了个人发展,同时增加一些个人奖项,激励某方面能力突出的员工。

    作者回复: > ...但个人觉得团队度量会比个人度量更好一些,促进团队的成长

    说的非常对!

    2019-09-03
    1
  • Anders
    请教老师:实际工作中有的「需求」简单改几字就可以交付花个几分钟,有的「需求」要修改很多地方,耗时可能上月,这时如何评价效能?假如有的尽是前一类需求,有的团队都是后一种,组织层面如何公平的来度量不同团队的效能?

    作者回复: 这种情况,如果指望客观的数据是行不通的。我的经验是只能考管理者主观的判断。组织层面必须要能够给做脏活累活的团队足够的认可。

    2019-09-02
    1
  • 杜林
    指定流程、标准、考核指标以及选择适合的工具,搭配好了可以爆发出巨大的效能

    只可惜很多时候,是自上而下的管理,不懂基层真正需要什么,而做了错误的决策,导致一系列问题

    作者回复: 这种情况,如果管理者心态开放,能接受改变和改进,还有一些办法,比如在底层做出一些东西,让管理者看到能解决关注的问题,会有一些正面的效果。如果管理者自认为自己懂,那就比较难了。

    2019-08-27
    1
  • 寒光

    大概的准确胜过精确的错误,放任不管,让团队自由发挥,如果是BAT这种大厂的自有研发人员,OKR当然没问题,反之,就肯定行不通。期待接下来的课程。

    作者回复: 肯定不能放任不管。如果工作跟团队方向不对,产出达不到预期,Facebook这些公司砍人是很果断的。专栏最后一个模块,我会介绍一些绩效考评相关的内容。

    2019-08-26
    1
  • 💪😊
    问题复杂之后方法需要使用完全不一样的工具了,比如今天的深度学习使用了完全不同于传统算法的办法,虽然说可解释差,但是还是有一些好和坏的准则的。就像现在提倡okr而不是kpi,鼓励共同成长,相互尊重,分享收益等都是很积极的应对措施,还有更用心的过程控制不可缺少

    作者回复: 👍👍

    2019-08-26
    1
  • 桥墨
    那到底该如何考核程序员,效能组成员呢

    作者回复: 在Facebook度量开发人员东公司的贡献度(impact)。具体度量主要是采用360度绩效考评系统。我在最后一模块“管理和文化”中会介绍。

    2019-10-27
  • 江不白
    度量如果是基于成功OKR的,会发生什么?

    作者回复: OKR的使用。也有一个重要的原则是不要把它的度量和绩效强挂钩。

    我的理解,OKR更是一个目标对齐的工具。

    2019-09-24
    1
  • 旭东
    pmp十年了还是工时随意填,凑够上班时长,且必须大于等于上班工时的填报率才不会扣团队绩效。

    小组长为了自己的业绩,开发一堆功效demo。但对规范的推广却望而却步。一心为了自己业绩和升职的领导对于公司研发的积极性压制很大。往往是抓住芝麻丢了冬瓜。而这一切在考核里却看不到,可悲

    作者回复: 考核系统需要改进。应该增加收集成员反馈的机制。

    2019-09-11
  • 大河
    尝试在前端团队中推行Code Review,每个项目分配一名同事和一名主管负责审核,主管还是比较负责,能够提出一些问题,另一名同事则比较敷衍,整体的Review效果并不理想,但如果强制要求每次Review必须提出问题,又有点过于死板,不知道有没有比较好的方式方法,可以借鉴

    作者回复: 后面会有两篇文章专门讨论代码审查。敬请期待 :)

    针对你的描述,我觉得比较有效的代码审查不应该是集中式的,而应该是p2p的。也就是说,开发人员之间互相审查,而不是有专门的人来审查。

    2019-09-03
  • L
    突然想到了那个用代码量来评KPI的梗了

    作者回复: 再讲一遍!

    2019-08-29
    2
  • 张普
    接手前人的代码,不断补坑,bug修复的多,没有新需求

    作者回复: 我的一个好朋友,在Google工作10年,技术过硬。关于维护别人的代码,他推荐这本书:
    英文版:
    Working Effectively with Legacy Code https://book.douban.com/subject/1428943//

    中文版:
    修改代码的艺术
    https://book.douban.com/subject/2248759/

    2019-08-29
  • 麦兜
    销售导向型的公司,根据项目成本和利润进行度量。项目赚钱,技术人员按不同比例获得利润。但存在一个问题,项目合同额度不是项目组技术人员可直接决定的,而是销售人员决定的,所以技术人员只是被动的接受项目利润或者因为合同额度降低引起的裁员问题。

    作者回复: 所以,具体的问题是技术人员觉得项目额度估计的非常不准确,导致不公平吗?

    2019-08-26
  • 许童童
    效能到底高不高,确实很难度量,当效能和绩效挂钩时,那效能的度量标准就不能随便定了,否则很容易伤到团队。能否这样,开发一个标准功能,我们把这个功能的工作量定为1,然后在评估其它功能的时候,就以这个标准定好工作量为几,比如5,这个由大家投票,取平均值。以这种方式来度量,老师觉得怎么样。

    作者回复: 这种方式感觉要花比较多的时间去做。工作中常常会出现新的工作,那是不是每个任务都要评估呢?另外这种评估本身就是一个大家主观的评价,需不需要做的那么频繁?能不能绩效考评的时候,通过同事之间的互相反馈,收集大家的贡献度呢?

    2019-08-26
  • 舒偌一
    公司采用任务驱动开发,度量的目标是考核程序员的效能,后来发现对互相协作带来的很大影响,后来改为针对团队,再后来就取消了。失败的原因是从影响个人或团队的收益出发而不是从提高效能出发。现在尝试要求团队在冲刺完成后提交改善意见和上次改善意见实施情况,慢慢试验中。

    作者回复: > 公司采用任务驱动开发,度量的目标是考核程序员的效能,后来发现对互相协作带来的很大影响

    这个“任务驱动开发”中使用的度量具体是什么度量,能解释一下吗?

    2019-08-26
    2
  • 李双
    问题大于解决方案哈,

    作者回复: 我们一起讨论,一起找办法 :)

    2019-08-26
收起评论
21
返回
顶部