研发效率破局之道
葛俊
前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讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

03 | 效能度量:如何选对指标与方法,真正提升效能?

葛俊 2019-08-28
你好,我是葛俊。今天,我来和你聊聊如何正确使用效能度量。
在上一篇文章,我给你介绍了效能度量的定义、作用,以及几个使用误区。我们先简单回顾一下:
软件系统异常复杂,度量指标无法覆盖其所有参数,从而容易被“数字游戏”欺骗。
竖井指标的提高不等于全局指标的提高,局部优化不等于全局优化。
研发效能度量指标一般用来衡量软件产品的生产过程和产品质量,但公司真正需要关注的是能否产生用户价值。这两者之间存在着难以跨越的鸿沟。
正是因为这种种看似难以解决的问题,业界甚至有人认为研发效能的度量是一个无解的问题。但我并不这样认为。如果使用得当,效能度量可以给公司的研发带来非常大的好处。
举一个真实的例子。国内一个大概 20 人的研发团队,研发流程混乱,产品发布经常推迟,但是大家都不清楚问题出在哪儿。于是,团队负责人决定引入数据驱动开发:项目经理正式跟踪研发过程中每部分的耗时,并在功能发布后复盘。复盘时大家发现,整个研发过程耗时分布如下:
开发耗时 1 周;
联调耗时 1 周;
测试、发布耗时 1 周。
大家一致认为联调耗时一周,是最需要优化的地方。于是对联调部分进行深入讨论,发现根本原因在于前后端沟通不顺畅:常常出现后端改动 API,但前端不知情的情况,这是耗时最主要的原因。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(22)

  • Criss Chan
    问题:dev工作block了

    作者回复: 对啦。厉害!

    2019-08-28
    1
    4
  • Johnson
    本地构建是指的工程师在自己的笔记本上?还是说工程师通过本地笔记本登录到的开发服务器上?工程师的笔记本环境有可能有多种,比如有的同事入职时选的PC,有的选的MAC,如果在笔记本上构建,那这个环境很不好维护啊

    作者回复: 本地构建指的是在自己的开发机器上,也就是代码所在的地方进行构建。如果代码是在远程的开发服务器上,那这个本地指的就是远程的服务器,如果代码是在笔记本上,那这个本地就是笔记本。

    在你的例子当中,如果大量的开发都是在笔记本上进行的。那么虽然环境维护有一些麻烦。还是很值得投资的。大不了在Windows上面做一套环境,在Mac上面做一套环境。具体方法,最直接的是使用脚本自动化。

    另外这个环境最好和你们的生产环境保持一致。避免在本地构建出来的东西,在生产环境上会出现因为环境不同而造成问题。

    2019-08-28
    2
    3
  • witluo
    看质不看量,都是耍流氓
    2019-08-28
    3
    2
  • Xin
    需求评审完后在开发过程中频繁加需求及修改,开发过程中不停应对不同部门的咨询打断各种都强调优先级,这是最痛的😂

    作者回复: 这个问题在开发资源被共享的情况下的确是很常见,也很棘手。我看到有两个可能的处理办法,第一个是。有一个统一的接口人来对接这些优先调节优先级的要求,挡住一些,并且根据全局情况进行合理调节。第二个方法是改变开发资源的共享方式,从按智能划分团队,转变成按产品划分团队,或者是矩阵式管理。

    2019-08-28
    2
  • Geek_eddy
    本地开发机使用线上数据验证对开发来说确实很爽,Facebook是如何保证线上数据安全性?

    作者回复: 这一部分我也不是特别了解细节。但是知道主要原则大概有几个:
    1. 数据库中都有特定的Field指出是否是测试数据
    2. 能够快速恢复。这个是基本
    3. 强大的监控。开发人员账号触碰到生产数据,如果是TA本人不应该有权限的,必须要有任务ID才能有Access。这些行为都会被记录下来。

    2019-08-28
    1
  • 李双
    学习!每个方面都是内功和外功的修炼!

    作者回复: 👍👍

    2019-08-28
    1
  • P.X.yuan
    有个问题想请教,需求周期时间,一个需求是怎么定义的?

    作者回复: 我不确定我是否正确理解了你的问题。需求的“定义”一般就是一个功能,比如完成某个用户的需求。

    2019-10-22
    1
  • 龙
    问题:
    从11开始产品的需求越来越多,需要更多的dev来做事

    作者回复: 从图上看到的是开发被阻塞了,没有接受新的开发任务。 具体原因和解决方法还需要调查,根据实际情况而定 :)

    2019-10-20
  • 二狗
    在编码和编码设计以外消耗的时间,主观感受浪费的时间占工作时间的大多数

    作者回复: 这个是比较常见的一个状态 😟

    团队管理者在这个方面比较能够进行改变。作为个人,也能做一些努力,我在后面的个人效能部分会给一些建议,比如深度工作,多了解业务等。

    2019-09-30
  • Geek_98dc22
    产出持续增加,但待做任务数量未减反增。开发后期开发人员效率低下,处于无产出状态,而对测试人员处于较高负荷。大体上体现产品后期质量出现较为严重且难以修复的问题,处于修复问题状态。

    作者回复: > 待做任务数量未减反增
    其他都对。除了上面这个似乎不是很准确。

    2019-09-03
  • 不能把效能度量与绩效挂钩,看到这突然有种豁然开朗的感觉,也许这就是效能很糟糕的"症结"所在。但是问题又来了,效能度量与绩效脱钩后,如何评估绩效?尤其对于中大型公司来说,数字化的绩效最简单也最直观,也没有人为因素的掺杂,也能被大家接受。

    作者回复: > 数字化的绩效最简单也最直观,也没有人为因素的掺杂,也能被大家接受。

    这个的确,这也是很多管理者倾向使用这种数字度量进行管理的重要出发点:至少帮助我打考评!而且有数字支持,员工也难以提出异议。

    但是因为研发的特殊性,我看到的情况是客观收集数据直接用来打考评不行(可以做参考)。反而是主观收集反馈来做考评才有效(难点是做到公正)。

    2019-09-01
  • sde
    我个人觉得和绩效挂钩并不是问题,关键是其占个人整体绩效的比重
    适当的权重是可以激励开发关注效能的。

    作者回复: 这个主要看度量的方法。如果是用死板的通过工具收集数据,而且明确强相关,我觉得还是不行。比如,“完成功能点数量个数在团队排名,决定10%绩效排名”。这种占比虽然只有1/10,我觉得还是会出现数字游戏。

    你能举一个具体你觉得会有效的例子吗?

    2019-08-31
  • Jerry
    效能度量不要与绩效挂钩,而应该作为参考和工具,帮助团队提高效能。先从全局上找瓶颈,再深入细节……总结得真好。另外请教下,在facebook全局指标和局部指标之间会有一些关联么

    作者回复: > 在facebook全局指标和局部指标之间会有一些关联么

    我不太清楚你的问题。全局指标一般不是局部指标组合而成的吗?能重新解释一下你的问题吗?

    2019-08-29
    2
  • 八哥
    做云计算相关产品的,本地开发和测试,环境都不具备,写好代码都是要到现网环境联调。新手在高速公路开车一样。需要度量指标,首先很多内容要信息化,不应该在纸上,现在jira和conf用的就很糟糕。

    作者回复: > 本地开发和测试,环境都不具备,写好代码都是要到现网环境联调
    这个要尽量把可以本地验证的地方本地实现。应该能有一些workaround能做一部分吧。同时尽量在本地模拟线上环境。

    >...信息化...
    wiki用好效果就很好。conf一个常见用法是每个团队内部使用,外部不可见。我觉得很不可取。最好全公司用一个,所有可以公开的信息都公开,放到上面

    2019-08-29
  • 囧囧冰淇淋

    老板:效能度量不能与绩效挂钩,那我怎么知道你们提高了啊?我现在看到的就是,我们的产品经常上不了线,产品部和运营部那边经常抱怨。我看了下XXX公司(同行但非顶尖),他们用的这套绩效考核很有用,我们要多向他们学习学习,这套指标先定下了。

    在小公司比较容易发生,老板会拿比自己好一些的同行对比。大公司不知道会不会发生这种质疑:因为业务的进展缓慢,从上至下产生不信任感,导致团队开始埋怨和打混。

    以下是自我理解:
    老板:
    1.需要开明,问题可以从外部去参考,但不能直接套用到团队上,要考虑公司整体情况。比如需求经常被更改,经常着急上线,那就要把产品,运营,软件一起叫进来讨论,坚决抵制互相甩锅,而是每个团队做哪些可以便利下一个部门效率,形成一个整体提升。
    2.允许员工反对,倾听员工的想法,让相关人员围绕问题一起谈谈,可以不用马上得到答案,把它当成一种倾听、持续改进的沟通方法。
    3.允许一定的失败,小公司是在磕磕碰碰中长大的,经验欠缺,人员不齐,不要出了问题就大骂一通。
    4.关心员工,成功或者失败了,大家都付出了努力,还可能经常加班,加班可是没有工资;失败后的大骂,成功后的轻描淡写都让给团队丧气。
    5.提供一些工具或者课程帮助员工。
    6.公司和团队成长后提供更好的待遇。

    作者回复: 从我的经验看,对开发工作,绩效考核通过360反馈,通过相对主观的方式,反而比较有效。

    2019-08-28
    5
  • 许童童
    思考题:可以看出dev逐渐减少到了没有,全部进入backlog了。可能的原因是开发停止了、开发被流程阻塞了。

    作者回复: 对的对的!

    通过这个图一下子就可以看到问题。

    2019-08-28
  • 舒偌一
    葛老师,小公司没有参考点,怎么衡量研发效能有问题?能不能提供一个参考?

    作者回复: 这个一般来说,效能方面肯定是有很大提升空间的 :)

    我觉得,可以用我文章中提到的,用NPS方法对开发人员进行研发环境满意度的调研,你会发现问题的。然后尝试解决中间最痛的点,看看效果。

    2019-08-28
  • 舒偌一
    大概在11前产生了大量的bug,之后在修改之前的任务,dev没有接受新任务。

    作者回复: 答对了!赞

    2019-08-28
  • gucs
    wip 多,导致周期长,不能快速流动

    作者回复: WIP是大概100左右,但是我们不清楚团队多大,所以不能确定是否这个WIP太大。

    2019-08-28
  • 杜杰
    思考题分析啊~

    1.dev休假
    2.购买了软件产品
    3.需求做不了

    作者回复: 从图上看到的是开发被阻塞了,没有接受新的开发任务。你这个直接给出开发被阻塞的三个可能原因,哈哈,厉害 :)

    2019-08-28
收起评论
22
返回
顶部