技术教育社区
www.teccses.org

卓有成效的工程师(精)

封面

作者:(美)埃德蒙·刘

页数:230

出版社:电子工业出版社

出版日期:2022

ISBN:9787121435881

电子书格式:pdf/epub/txt

内容简介

本书介绍一个强大的框架——杠杆率,用来推断、分析工作的有效性与影响力,研究并说明如何成为一名卓有成效的工程师(精)。更为重要的是,本书提供了一系列可落地且经过验证的策略作为框架的补充,读者可以立即应用这些策略来提高工作成效。本书的内容分为三个部分,第一部分阐述提高成效的思维模式切入;第二部分深入探讨持续提升执行力及取得工作进展的关键策略;在第三部分,作者转换角度,阐述了创造长期价值的方法。通过阅读本书,读者能够获得思维启发和高价值的实践经验,成为卓有成效的工程师(精),并打造高效的软件工程团队。

作者简介

埃德蒙·刘(Edmond Lau)是 Quip 公司的一名软件工程师,他正着力构建一个生产力套件,以提高团队的效率。
在此之前,他是 Quora 的初创成员之一,曾经领导工程团队致力于用户的增长,并为新软件工程师制定入职培训和指导计划。到 Quora 工作之前,他曾在 Ooyala 公司担任分析技术负责人,在谷歌担任搜索质量软件工程师。他获得了麻省理工学院计算机科学的学士和硕士学位。
埃德蒙·刘住在加利福尼亚州的帕洛阿尔托。访问他的网站 TheEffectiveEngineer,可以看到他分享的更多经验、故事和习惯,能够帮助软件工程师提高生产力和效率。
他热衷于帮助工程团队建立强大的文化,他的文章曾被刊登在《福布斯》、Slate、《财富》、《时代》等杂志上。他是麻省理工学院和斯坦福大学的客座讲师,并在初创公司发表过关于建立卓越的工程师文化的演讲。 【译者简介】
万学凡,数字化转型专家,行业知名敏捷转型顾问,InfoQ2020、2021年度中国十大IT产业推动者。《EDGE:价值驱动的数字化转型》、《如何写出好程序》、《敏捷回顾:反模式与重构引导实践》、《解决方案架构师手册》、《AI重新定义企业》、《内容智能:打赢每一场运营战争》、《Go语言学习指南》等书的译者。凯捷中国数字化团队总经理,首席咨询顾问。
顾宇,腾讯 PCG平台与内容事业群 T11 研发效能专家,长期专注于企业数字化转型、企业 IT 治理和软件研发效能提升,及规模化敏捷(SAFe)、领域驱动设计(DDD)、微服务架构、DevOps 和云原生技术实践。在多年软件开发和咨询过程中积累了丰富的实践和教学经验。曾参与信通院《研发运营一体化(DevOps)能力成熟度模型 第3部分:持续交付》、《研发运营一体化(DevOps)能力成熟度模型 第5部分:应用设计》、《分布式应用架构评估标准:第一部分:微服务平台》等标准的编写,及多家大型企业 DevOps 成熟度评估、指导。

本书特色

√ 既面向工程师高效工作与成长实践,又面向工程师团队的管理与建设;既带来硅谷领风气之先的工程师文化,又直指其弊高举反硅谷套路大旗。
√ Effective与卓有成效双经典系列叠加,对人人重视却不得其解的效率、时间、成本、价值等高频词,给出一套真正有效的可落地实施方案。
√ 作者先后在微软、谷歌、Quora等明星公司工作,现投身创业并客座执教名校,足以确保书中有大量鲜活而有内涵的真实案例及其教训与收益。
√ 在这本广为流传的畅销书中,以软件行业为背景的杠杆率工具,通过提出、论证及应用这一套缜密的方法论,可以惠及当今每一个企业和个人。

目录

第一部分 树立正确态度

1 聚焦高杠杆率工作 ………………………………………………………… 2

使用杠杆率衡量工作成效 …………………………………………………….. 4

提高杠杆率的三种方式 ………………………………………………………… 6

将精力投入杠杆点,而非易于完成的工作 ……………………………. 9

本章要点……………………………………………………………………………. 12

2 精益求精,优化学习方式 …………………………………………….. 13

培养成长型思维模式 ………………………………………………………….. 15

提升学习速率 …………………………………………………………………….. 19

寻求利于学习的工作环境 …………………………………………………… 22

将时间投到培养新技能的任务上 ………………………………………… 27

持续学习……………………………………………………………………………. 31

本章要点……………………………………………………………………………. 34

3 定期调整优先级 …………………………………………………………. 36

简单易用的待办事项清单 …………………………………………………… 39

关注直接创造价值的工作 …………………………………………………… 41

关注重要但不紧急的工作 …………………………………………………… 43

守护创造者日程 …………………………………………………………………. 46

限制同时进行的任务数量 …………………………………………………… 47

用“如果……就……”计划对抗拖延症 ……………………………… 48

培养调整优先级的习惯 ………………………………………………………. 50

本章要点……………………………………………………………………………. 55

第二部分 执行,执行,再执行

4 投资迭代速度 …………………………………………………………….. 58

迅速行动,快速学习 ………………………………………………………….. 61

投资节省时间的工具 ………………………………………………………….. 63

缩短调试验证周期 ……………………………………………………………… 68

熟练掌握编程环境 ……………………………………………………………… 71

不要忽视工程以外的瓶颈 …………………………………………………… 75

本章要点……………………………………………………………………………. 78

5 正确度量改进目标 ………………………………………………………. 79

用指标推动进展 …………………………………………………………………. 82

用正确的指标激励团队 ………………………………………………………. 85

建立指标监控体系 ……………………………………………………………… 91

采纳有用的数字 …………………………………………………………………. 95

质疑数据的完整性 ……………………………………………………………. 100

本章要点………………………………………………………………………….. 103

6 尽早且频繁验证想法 …………………………………………………. 104

寻找验证工作成果的低成本方法 ………………………………………. 107

用 A/B 测试持续验证产品变化 …………………………………………. 111

当心“一人团队” ……………………………………………………………. 116

建立决策反馈循环 ……………………………………………………………. 121

本章要点………………………………………………………………………….. 123

7 提升项目估算能力 …………………………………………………….. 124

使用准确的估算推动项目规划 ………………………………………….. 128

为意外情况留出预算 ………………………………………………………… 133

设定具体的项目目标和可度量的里程碑 ……………………………. 137

及早降低风险 …………………………………………………………………… 142

极为谨慎地对待重写项目 …………………………………………………. 144

不要在马拉松比赛的半程冲刺 ………………………………………….. 148

本章要点………………………………………………………………………….. 152

第三部分:构建长期价值

8 权衡质量与务实 ……………………………………………………….. 154

建立可持续的代码审查流程 ……………………………………………… 157

利用抽象控制复杂性 ………………………………………………………… 160

自动化测试 ………………………………………………………………………. 165

偿还技术债 ………………………………………………………………………. 169

本章要点………………………………………………………………………….. 172

9 最小化运营负担 ……………………………………………………….. 173

拥抱运营的简单性 ……………………………………………………………. 175

构建可以快速试错的系统 …………………………………………………. 179

持续推进机械任务自动化 …………………………………………………. 183

让批处理进程幂等 ……………………………………………………………. 188

提升快速响应及恢复的能力 ……………………………………………… 190

本章要点………………………………………………………………………….. 194

10 为团队成长投资 ……………………………………………………… 195

让招聘成为每个人的责任 …………………………………………………. 198

设计好的入职流程 ……………………………………………………………. 203

共享代码所有权 ……………………………………………………………….. 208

通过事后复盘汇聚集体智慧 ……………………………………………… 211

建设卓越的工程师文化 …………………………………………………….. 215

本章要点………………………………………………………………………….. 217

结 语 ………………………………………………………………………… 219

附录 A ………………………………………………………………………… 221

致 谢 ………………………………………………………………………… 227

关于作者 …………………………………………………………………….. 229

节选

推荐序
从斯坦福大学计算机科学专业毕业后,我的第一份工作是在谷歌担任产品经理。这份工作真的太棒了,同一间办公室的一些同事甚至编写过我的大学教材。在谷歌期间,我参与创建了谷歌地图,这至今仍然是我作为产品设计师和软件工程师最为自豪的产品。我还学会了如何在大型软件项目中富有成效地工作。离开谷歌并创办自己的第一家公司 FriendFeed 时,我已经成功交付过很多大规模的软件项目,对创业成功充满信心。
然而,在大公司担任产品经理与创办公司是截然不同的。首先,人们对你的评价方式不同。虽然从理论上讲,应该根据产品是否成功来评价产品经理的能力,但在实践中,大公司对产品经理的评判标准是他们管理与产品成果相关的人员及部门的能力,比如:产品经理是否在产品发布前给公关团队留有充分的沟通时间?产品经理是否将产品与首席执行官最为重视的项目关联起来?在企业高层评审之前,产品经理是否说服了该产品方向上竞争团队的负责人?在不像谷歌那么开明的软件公司里,人们更看重产品经理在处理这些内部政治问题上的能力,而不是产品方面的能力。
这就是为什么很多来自大公司的软件工程师和产品经理对于埃德蒙·刘(Edmond Lau)在《卓有成效的工程师》中谈到的“杠杆率”概念感到困惑。他们被“高效”地训练为关注那些低杠杆率的活动,因为训练他们的官僚组织重视这些活动并据此给他们奖励。
在我的职业生涯中,与我合作过的最成功的软件工程师是少数几个能够洞察这些官僚主义特质,并认识到那一两个真正影响产品成功的要素的人。毫无疑问,保罗·布赫海特(Paul Buchheit)就是这样一位让我更加理解杠杆率作用的软件工程师。
保罗也是 FriendFeed 的联合创始人之一。在此之前他创建了Gmail,虽然我们在谷歌并没有太多的合作,但我们都很尊重彼此。
他与吉姆·诺伊斯(Jim Norris)和桑吉夫·辛格(Sanjeev Singh)在 2007 年年中联手创办了一家公司。保罗比我认识的任何人都更愿意挑战传统思维,他彻底改变了我对软件工程和产品管理的观点。
每当遇到一个具有挑战性的技术难题时,我往往会问:“我们应该如何解决这个问题?”而保罗的回答经常让我有点恼火:“我们为什么要解决这个问题?”他并不会尝试解决那些看似无法解决的问题,而是经常去挑战这些问题背后的假设,这样我们就能简单地绕过它们,问题自然迎刃而解。尽管这种做法有时会让保罗看起来好像是在偷懒——因为不管项目难度有多大,保罗都会质疑项目的目的——但他的质疑几乎总是正确的。除非这个项目注定会成就或者摧毁我们这家新生的公司,否则为什么要将宝贵的资源投在它上面呢?
与保罗一起共事的经验向我证明,在软件工程中更重要的是杠杆率,而不是编程技能。我开始将这个经验应用到之后的所有工作中。当 FriendFeed 被 Facebook 收购后,我成为 Facebook 的首席技术官,我花在取消项目上的时间与创建项目的时间一样多。2012 年,我与凯文·吉布斯(Kevin Gibbs)创立了 Quip 公司。我们非常强烈地意识到,工作的成效与工作的时长无关,因此我们公司非常自豪地采用了硅谷公司闻所未闻的“朝九晚五”文化。
我热爱硅谷的文化,我喜欢看到年轻的软件工程师像资深专家一样对行业产生巨大的影响,我欣赏我们的行业每十年重新定义一次自己的方式,但我也认为无止尽的加班是不必要的,而且它正在被这个行业中低成效的管理者所滥用。除了没必要,加班也是阻碍人们选择软件工程师作为长期职业的主要原因之一:这样的工作方式对有家庭的人来说是不可持续的,并且在那些普遍采用这一文化的公司中营造了一种同质化的、不成熟的工作环境。
很高兴埃德蒙选择写这本书,因为我认为,如果人们接受“聪明地工作”而不是“辛苦地工作”的理念,那么硅谷对于管理者和软件工程师来说都会是一个更美好的地方。这个理念既不违反直觉,也不难以实践,但很少有人这样做。我希望能有更多的人接受埃德蒙的理念,这会使他们的公司和事业更加成功。
——布雷特·泰勒(Bret Taylor) Quip 公司首席执行官 前 言
在创业公司工作的头几年是我职业生涯中最漫长的几年。那是一段无情磨砺自己的时光,其间我经历了个人的迅猛成长和无数的“情绪过山车”。我和团队基本上每周的工作时间都在 60 小时以上,而且有几个月我们每周要苦干 70 到 80 小时。我会在办公室开始一天的工作,利用午餐时间与团队开会,晚饭后继续在家工作——有时甚至会在办公室工作到深夜。即使在假期里探亲访友时,我也会挤出时间在笔记本电脑上编写代码和回复电子邮件。
毕竟,创业公司的性质意味着我们在与强大的竞争对手的较量中处于劣势。工作越努力,创造的价值就越大,创业成功的可能性就越大,我当时就是这么认为的。
但一些经历让我不得不反思这个观点。我曾用两周时间开发了一个分析模块,但客户却从未使用过;我和团队花几个月时间调整并完善了一些提高网站内容质量的工具,但用户并没有采用。我们的产品每周都会经历流量洪峰,以及随后数小时服务器连续重启。
甚至有一次,我在夏威夷的莫纳罗亚火山徒步旅行时收到短信,被告知客户分析报告的生成系统瘫痪,问我能否看看是什么情况。
我坚持长时间的工作是希望工作能产生有意义的影响力。但我忍不住想弄清楚:每周工作 70 到 80 小时真的是确保创业公司成功的最有效方式吗?我们的初衷是好的,但能否更聪明地工作?是否可以缩短一些工作时长,但获得同样的甚至更大的影响力?
在接下来的几年里,我逐渐认识到,延长工作时间并不是增加工作成果的最有效方法。事实上,工作时间过长会导致工作效率降低并产生职业倦怠。当需要修复由于加班和疲劳所导致的错误时,工作产出甚至可能为负数。
要成为卓有成效的工程师,我们需要识别哪些工作能以更少的时间产生更大的影响力。并非所有的工作都能产生相同的影响力。
并非所有的努力——无论本意如何——都能转化为影响力。
怎样成为卓有成效的工程师
如何衡量一名软件工程师的工作成效?是看他的工作小时数,付出了多少努力,还是完成的任务量?一位勤奋的软件工程师把所有精力都投入到一个进度延迟且无人使用的功能的开发中,当一天的工作结束时,他并没有产生多大成效。我曾经就是这样的软件工程师,我所认识的很多优秀的工程师也遇到过同样状况。
十多年来,我在许多科技公司做过软件工程师,包括微软、谷歌、Ooyala①、Quora②和 Quip③。在此期间,“怎样才能成为卓有成效的工程师”这个问题一直萦绕在我的脑海。我想提升自己工作的影响力,但每周工作 70 到 80 小时的状态是不可持续的。所以我开始寻找能够事半功倍的工作方法。
其他人也提过这个问题,特别是在招聘中。我有幸参与了培养工程团队的工作。在这段经历中,我筛选了数千份简历,并面试了500 多位候选人,和同事讨论每个候选人的优缺点。每次面试讨论结束时,我们都要做出判断:这个人是否会成长为团队中强有力的贡献者,并高效地完成工作?
我还设计了软件工程师的入职流程和指导计划,并亲自培训了几十名新入职的软件工程师。我所指导的人不可避免会向我咨询:如何工作才会更有成效?找到这个问题的答案,并把这些技能传授给他人,一直是我孜孜以求的目标。在寻找答案的过程中,我与几十位软件工程领域的领导者进行了深入的交谈。同时,我在过去的几年中花费大量时间阅读了关于生产力、团队建设、个体心理学、商业和个人成长的书籍,尽管这些书大多数并不是针对软件工程师的,但我也从中提炼了一些方法,并进行实验,把它们应用到软件工程场景中。
还有很多提升工作成效的技巧有待学习。但我在自己学习的过程中总结出一个强大的框架,可以用来分析、推断任何工作的有效性。我很高兴能在《卓有成效的工程师》中与大家分享这个框架。
这本书研究并说明了如何成为一名卓有成效的工程师,它是我所学到的关键经验和教训的提炼与总结。更为重要的是,它提供了一些可实施且经过验证的策略作为框架的补充,大家可以立即应用这些策略来提高工作的成效。
究竟如何才能成为卓有成效的工程师呢?在直觉上,我们对于哪些工程师能称得上卓有成效有这样一些认知:他们能圆满完成工作;他们能交付用户满意的产品,推出客户愿意付费的功能,构建提高团队生产力的工具,以及部署有助于公司业务扩展的软件系统。卓有成效的工程师会创造出这样的工作成果。
但如果花太长时间来完成这些任务,工程师的效率就可能会被质疑。他们可能很努力,但我们会认为那些使用更少的时间和资源,但取得同样成果的人更有成效。因此,卓有成效的工程师还需要能够高效地完成工作。
然而,效率本身并不能保证成效。假设一位工程师为一个最多只有一百人使用的工具,构建了可以支撑数百万次访问请求的基础设施,那么他的工作成效就很有限。如果一位工程师构建的某个功能只被 0.1%的用户采用,而其他功能的使用率可能高达 10%,那么他也算不上卓有成效——除非这 0.1%的用户带来了超乎寻常的、巨大的商业价值。卓有成效的工程师专注于价值和影响,他们知道选择交付哪些工作成果会更有成效。
因此,卓有成效的工程师是由他们在单位工作时间内创造的价值来定义的。这就是杠杆率,这个概念贯穿全书,我们将在第 1 章中介绍。
你将从这本书中学到什么
尽管这是一本写给软件工程师的书,但你在书中找不到一行代码。关于不同的软件技术、编程语言、软件框架和系统架构的书和文章比比皆是。然而,技术知识只是卓有成效的工程师第一技能的一小部分。
相对于效率而言,更为重要但往往容易被软件工程师忽视的是元技能。这些技能帮助我们将有限的时间和精力集中在那些成效更高的工作上。本书将详细介绍这些元技能。我向大家承诺,读完本书后你就会得到有一个非常实用的框架,这个框架就是“杠杆率”,它可以帮助我们分析不同工作的影响力。我们可以用本书介绍的实操方法来提高工作影响力,并深入了解软件工程中浪费我们宝贵时间和精力的常见陷阱。
我从自身的经历、与其他工程师的交谈以及对生产力和心理学相关的科学研究中掌握了这些技能。但在本书里出现的远不止我自己的故事。我还采访了硅谷科技公司的高级软件工程师、经理、董事和副总裁,从他们的经历中提炼出提高成效的秘诀。你会读到他们的故事——他们所采用的最有价值的工作方法,以及曾经犯过的最昂贵的错误。尽管每个人的叙述方式都各不相同,但包含了许多相同的主题。
在第 1 章中,你将了解为什么杠杆率是度量软件工程师成效的标准。在接下来的每一章中,你会都发现一个卓有成效的工程师提升杠杆率的工作技巧,以及对应的研究、故事和示例。你将了解Instagram 的联合创始人迈克·克里格(Mike Krieger)遵循了什么样的关键软件工程原则,使一个 13 人的小团队高效地扩张,并为一个拥有 4000 万用户的产品提供支持;还将了解 Facebook 前主管鲍比·约翰逊(Bobby Johnson)在其基础设施工程团队中培养的关键习惯,帮助他支撑 Facebook 这一社交网络的用户数量增长到 10 亿以上。你会听到更多来自谷歌、Facebook、Dropbox、Box、Etsy 及其他第一科技公司的人物的故事,他们分享了关于自己如何成为更有成效的个人贡献者和领导者的理念。忽视这些思维习惯往往会导致惨痛的教训,因此你还会读到一些这样的血泪故事。
本书的主题分为三个部分。第一部分描述了帮助我们更严格地推理以及提高成效的思维模式。首先概述了采用杠杆率的思维模式(第 1 章),然后展示了优化学习方式(第 2 章)和定期调整优先级(第 3 章)如何使我们加速成长并充分利用时间。很多工程实践都是围绕“执行”展开的,第二部分将深入探讨持续提升执行力并取得工作进展的关键策略:提升迭代速度(第 4 章),正确度量改进目标(第 5 章),尽早且频繁验证想法(第 6 章),以及提升项目估算能力(第 7 章)。卓有成效的工程师不是短期投资者,因此第三部分将转换角度,研究创造长期价值的方法。我们将学习如何在质量和务实之间取得平衡(第 8 章),最小化运营负担(第 9 章),以及为团队的成长投资(第 10 章)。
无论你是想增加对世界的影响,更快获得晋升,减少在无意义工作上浪费的时间,还是想在不影响工作成果的情况下节约工作时间,本书都会提供你所需要的工具。本书不是包罗万象的个人全面成长指南,但它提供了一个通用的框架——杠杆率,以此来引导大家将时间投资在成效更高的技能上。我对教学和指导充满热忱,很高兴能与大家分享我所学到的东西。

下载地址

立即下载

(解压密码:www.teccses.org)

Article Title:《卓有成效的工程师(精)》
Article link:https://www.teccses.org/1376511.html