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

31 | 业务目标和技术目标两手抓:怎样打造高效团队?

葛俊 2019-11-04
你好,我是葛俊。今天,我来和你聊聊管理和文化。
今天这篇文章,是最后一个模块“管理和文化”的第一篇。在前 30 篇文章中,我已经从优化流程、团队工程实践、个人工程实践这三大方面与你介绍了很多原则、方法和具体实践。通过这些内容,相信你应该对软件研发活动的本质有了更深刻的理解,也对这条超级灵活的流水线如何提效有了新的认识。
但作为团队管理者,要提高团队的研发效能,掌握了这些原则、方法和实践后,还要通过管理和文化让它们真正在团队落地。管理是提高团队研发效能的基石,而文化是持久高效的保障。同时,管理又决定了文化,如下图所示。
所以,在接下来的几篇文章中,我会参考硅谷高效能公司的一些管理实践和原则,以及我在国内外公司的落地经验,与你介绍如何通过管理和文化来提高团队的研发效能。今天,我们就先从技术管理者的主要工作步骤出发吧。
在我看来,技术管理工作主要有如下 3 个步骤:
寻找目标;
目标管理;
计划并执行去实现目标。
其中,计划执行又包括人、流程和工具 3 个方面。

第一步:寻找目标

第 1 篇文章中,我曾和你分享研发效能的三要素是有效、快速、可持续性,其中第一条就是有效,也就是准确性。所以,要想建设高效的研发团队,技术管理者的第一项重要工作就是,作为舵手,为团队寻找方向和目标。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • 极客不落🐒
    Facebook 为啥使用 Mercurial 代替 Git?
    在 Facebook 官方博客上找到一篇介绍这个话题的文章,主要是 Mercurial 易扩展,更重要的是开发者社区友好(针对 Facebook 的现状帮忙定位问题,并在新功能开发时候考虑 Facebook 的特殊情况)。

    Instead, we chose to improve Mercurial. Mercurial is a distributed source control system similar to Git, with many equivalent features. Importantly, it’s written mostly in clean, modular Python (with some native code for hot paths), making it deeply extensible. Just as importantly, the Mercurial developer community is actively helping us address our scaling problems by reviewing our patches and keeping our scale in mind when designing new features.

    https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/

    作者回复: 是的。Mercurial社区很友好。而Git社区认为你们本来就不应该用那么大的代码仓 😂

    2019-11-04
    1
    6
  • 幻想
    这一套,在创业公司不太好实施,被业务方逼的太紧了,也没得商量。基本就是疯狂加班的节奏。别说目标啥的,大家都不认的。当时导致这个的根本原因是,高层的焦虑感。哎

    作者回复: 解决这个问题的根本是决策者掌握好长期利益和短期利益的均衡。同时决策者要了解技术的基本特点:技术债。

    2019-12-08
  • qeesung
    公司刚切到了okr上面,作为一个普通员工对okr感觉不是很大,业务目标的变化太快,okr往往跟不上业务目标的变化。。。这样okr还能发挥用处么,感觉就是走走流程而已

    作者回复: 首先我觉得O不能老变。业务目标变化,Object 可以不变。比如“提高产品的用户体验”。KR没有办法会随着具体项目变化和变化。

    这种频繁变动情况下目标管理肯定是不好做的。我建议就尽量把OKR当做目标对其的工具。根据团队的O定好自己的O,对自己的具体工作做一个指引就好。

    2019-11-07
收起评论
3
返回
顶部