Transcription
在大多数时候，当你正在做一个项目时，你实际上并没有在工作。你是在等待，等待访问权限、批准、回复，或者你发现你所构建的并不是实际想要的，因为直到为时已晚才有人澄清需求。我合作过的最优秀的工程师已经找到了如何消除几乎所有这些障碍的方法。他们做事的方式看起来完全是反向的。他们试图尽快被阻碍。
我叫史蒂夫·温。我在亚马逊工作了近20年，在那里我晋升到首席工程师的级别，我注意到那些10倍效率的工程师不一定工作更长时间。在这个视频中，我将向你展示他们是如何做到的。如果你是新来的，我制作的视频提供实用的建议，告诉你如何加速你的职业发展。如果你喜欢这类内容，请点击喜欢和订阅按钮。
这是第一个问题。当你认为前面可能存在问题时，你就会立即停止工作。你看到一个潜在的依赖项，所以你安排了一个会议。你怀疑你可能没有访问权限，所以你发送了一封电子邮件询问。需求仍然模糊不清，所以你犹豫不决，直到它们自行澄清。你实际上并没有被阻碍。你被一个猜测阻碍了。当你为那个会议等待8天的时候，快速的工程师已经有了他们的答案。
这是一个我亲身经历的场景。你的应用程序需要与另一个团队拥有的安全数据库通信。所以，你和他们安排了一个会议，并抄送了安全团队。你等待了几天才开会。然后你讨论了边缘情况和威胁模型，并带着行动项离开，其中包括授予你访问权限的行动项，但你仍然不知道它是否真的有效。快速的方法是编写一个脚本，尝试从你的开发环境通过端口443连接到那个数据库。你在第一天就这么做。如果连接成功，你就可以跳过所有会议。如果超时，那么你才是真正被阻碍的，但现在你有了具体的错误日志。你不再是猜测了。最重要的是，你有一个工具来验证你何时真正获得了访问权限。
当这发生在我身上时，本应授予我访问权限的团队确实给了我资源数据库的访问权限，但没有更新防火墙规则。我们又花了一周时间诊断这个问题。然后我们又浪费了一周，因为我们需要访问正确的模式。
这是教训。理论上的障碍和真正的障碍之间有很大的区别。理论上的障碍是你因为预见到问题而停止。真正的障碍是系统物理上阻止你前进。所以，这是新规则。除非你触发了错误消息，否则永远不要宣布自己被阻碍。你需要被阻碍的物理证据。我称之为“失败证明”规则。等待访问权限？尝试登录并截取“访问被拒绝”的屏幕。等待决定？发送一封电子邮件，内容是：“我将继续进行，除非现在有人提出充分的理由反对。”理论上的障碍是无形的。你希望在宣布自己被阻碍之前，有相当于有人物理上阻止你的情况。
现在，有趣的事情来了。你们中很多人在观看时会点头同意，并想：“是的，我应该停止在项目上等待。”然后你又会回到等待你的职业生涯，等待你的经理注意到你，等待合适的时机要求加薪，等待有人告诉你需要做什么才能获得晋升。这就是为什么我与今天视频的赞助商Strawberry.me合作的原因。Strawberry将你与专业的职业教练联系起来，他们帮助你停止猜测并开始行动。他们帮助你找出究竟是什么阻碍了你的成长，制定解决策略，并真正让你对采取行动负责。因为等待在项目上不起作用，在你的职业生涯中也绝对不起作用。请访问strawberry.me/ifeengineered参加他们的快速测试。[音乐]链接在描述中。感谢Strawberry赞助今天的视频。
这是第二个问题。你需要将不确定性视为黄灯。你看到前方有不清楚的地方，所以你减速。你想在前进之前确保道路安全，所以你等待有人告诉你前进是安全的。这感觉很负责任，但实际上这是最慢的方法，因为你无法解决尚未发生的问题。
我当时正在开发一个功能，它需要另一个团队提供一个新的API端点。礼貌的工程方法是等待他们的设计文档出来后再编写任何代码。我没有等。我编写了客户端代码，假设API已经存在。我定义了我想要的契约，并尝试运行它。当然，它失败了。当另一个团队最终准备好时，API的形式略有不同。所以，我在我这边做了小的修改，以确认他们所构建的内容。但事情是这样的。我的代码在端点上线的那一刻就暴露了他们API的问题。他们在发布当天我就提醒了他们。通过不为黄灯而减速，我们至少节省了两周时间。
所以，这是教训。等待确定性是最昂贵的研究形式。错误消息是免费的。猜测会让你付出你没有的数周时间。如果你认为需求可能会改变，那就先构建你现在理解的部分，并推动对话。最坏的情况是你学到了一些东西。最好的情况是你已经完成了。
这是第三个问题。你被困在等待别人，感到无能为力。你发送一封电子邮件。你发送一条Slack消息。没有回复。你发送一封友好的跟进邮件。仍然一无所获。所以，你等待。也许你向同事抱怨，但你没有升级问题，因为你不想成为那种小题大做的人。所以，障碍物静静地在那里侵蚀你的时间线，而你却希望它能自行解决。
现在，在云计算出现之前，我需要在数据中心安装一个服务器机架。工单一直排队，并开始成为一个问题。我先发了一个友好的提醒，然后是一个不那么友好的。当截止日期面临风险时，我联系了该团队的经理。仍然没有回应。我的一位同事正要去数据中心，所以我请他亲自去找技术员。结果发现那个人没有从供应商那里拿到正确的电缆，而且他的经理正在度假。就是这样。我们在亚马逊上买了电缆，交给他，然后就完成了。我的升级处理并不粗鲁。这是发现实际问题的唯一方法，如果我一直发送礼貌的信息，它就会在那里排队数周。
所以，这是教训。当你有一个有证据的真正障碍时，你就有了权威。你不是在请求帮助或惹麻烦。你是在报告业务中的故障。专业的做法是逐步升级。如果障碍威胁到交付日期，你必须升级。提交工单或通过电子邮件告知项目经理具体的错误或你被阻碍的证据。如果你没有收到回复，将其转发给你的经理。如果这仍然失败，则向上转发到下一级。不要停止，直到领导层中的某人告诉你错过截止日期是可以接受的。将此记录在电子邮件中，这样如果你最终因为错过日期而受到指责，你就可以向人们展示。
这是第四个问题。项目中有你没有完全理解的部分。因为不知道某些事情会让你感到不舒服，所以你把它推迟了，转而处理你确实知道的部分。你告诉自己以后再解决困难的部分。但“以后”是学习成本最高的时候。第一天的困惑给你最多的时间去弄明白。第90天的困惑会让你错过截止日期，并让你在晚上和周末加班。
我曾经构建了一个支付订阅服务，需要处理复杂的循环计费。我以前从未使用过特定的支付提供商，而且文档零散且有点令人困惑。默认的方法是构建我理解的部分，然后稍后再解决计费问题。但我做了相反的事情。在前几周，我没有编写一行生产代码。相反，我花时间编写了一个一次性原型，只是为了让测试支付通过沙盒。我与认证头作斗争。我与不理解的参数搏斗。这真的感觉我没有在实际产品上取得任何进展。但最终，我让测试支付通过了，然后我删除了脚本。然后我在4小时内编写了实际的生产集成。我不需要停下来查找任何东西。我只是打字，一次性创建了一个带有测试的超级坚实的生产代码。
这叫做研究性探索（research spike）。目标不是构建一个成品。目标是编写一些“垃圾代码”，以证明你理解系统是如何工作的。如果你不能向一个初级工程师解释清楚，你就还没有准备好编写生产代码。要将此付诸实践，请找出项目中你最不理解的部分，然后全身心投入其中，直到你被物理阻碍。你不允许做你已经知道如何做的事情。只有到那时，你才被允许真正地构建。当没有任何模糊不清的地方时，你会惊讶于自己的速度有多快。
这是你脑海深处的东西。这是恐惧。如果你是快速的工程师，你会筋疲力尽。你会因为更多的工作而受到惩罚。你会永远冲刺，而其他人则慢慢来。这种想法没有任何意义。让我来解释一下。
工程中最累人的部分不是工程本身。它是摩擦、上下文切换、等待模糊性消除、以及在会议上谈论工作而不是实际工作的荒谬之处。想想精英马拉松运动员。在健身展上，他们将跑步机设置为世界纪录马拉松配速。普通人跳上去，然后在30秒内从后面摔下来。他们是在为生命冲刺。而精英跑者能以那个配速坚持2小时。他们冷静而高效。他们从自己的步幅中消除了每一盎司浪费的能量。这就是区别。慢速的工程师连续跑了100次短跑。他们允许自己被阻碍，直到他们不能再等了。然后他们筋疲力尽地冲向终点线。这就是倦怠的秘诀。
快速的工程师已经消除了阻力。他们不是在更努力地工作。他们以可持续但快速的节奏更顺畅地运行。这样想吧。如果你达到了这样的地步：要么你的项目被物理阻碍，要么瓶颈只是你敲代码的速度，那不就是梦想吗？我在这段视频中描述的一切都不是更多的工作总量。它只是将相同的工作提前到更便宜修复且压力更小的时间段来处理。你的目标是分散你反正都要做的工作，并避免在临近截止日期时出现的时间紧迫。
你不仅会行动更快，更早完成更多事情，你还会赢得勤奋和偏向行动的声誉。所有这些都仅仅来自于从等待事情发生在你身上的模式，转变为为自己创造机会的模式。如果你被分配了比同事更多的工作，那么你猜怎么着？你正在比你的同事更高的水平上运作。而且通过可持续地这样做，你不会筋疲力尽。你已经成为一名精英马拉松运动员，能够以惊人的速度跑出疯狂的距离。你不是一个只能跑几次百米冲刺就会因精疲力尽而倒下的短跑运动员。
如果你觉得这个视频有用，它与我制作的关于“如何轻松被视为高绩效者”的视频非常搭配。如果你已经弄清楚如何比其他人更快地交付，那么如果没人看到你的工作，其他一切都无关紧要。去看看吧。我知道你会喜欢的。