好文转载: "在大型科技公司如何交付项目?"
在过去大约10年的科技行业中，我交付了各种不同的项目。当需要确保项目成功时，我经常被指派领导新的项目，因为我在这方面很擅长。在大型科技公司交付项目是一项与编写代码截然不同的技能，许多擅长编写代码的人在项目交付方面却表现得很差。
以下是我在领导项目时的思考以及我看到人们常犯的错误。
交付项目很难
最常见的错误是认为交付项目很容易。项目的默认状态是不交付：无限期延迟、取消或推出半成品并失败。项目不会因为所有代码都已编写完成或所有Jira任务都已关闭而自动交付。项目之所以能够交付，是因为有人承担了这项困难且微妙的工作。
这意味着在几乎所有情况下，交付必须放在首位。你不能将其他任何事情作为你的首要优先级。如果你把所有时间都花在担心优化用户体验（例如）上，你就无法交付！专注于用户体验是团队工程师值得赞扬的行为，但如果你是项目负责人，这就会是一个错误。你应该珍惜团队中那些正在做这项工作的其他工程师，并给予他们尽可能多的支持。但你的首要关注点必须是交付项目。这项工作太难了，不能靠业余时间来完成。
根据我的经验，几乎所有的项目都是因为某一个人使它们得以交付。明确一点，这个人并不是编写所有代码或完成所有工作的那个人，我也不是说没有整个团队的支持项目就能交付。但非常重要的一点是，项目中的某个人必须对整个项目有端到端的理解：它在技术上是如何整合的，以及它服务于什么产品或业务目的。优秀的团队和公司理解这一点，并确保每个项目都有一个单一的责任工程师（通常这个职位被称为“技术负责人”或“DRI”角色）。糟糕的团队和公司则不这样做，项目能否成功完全取决于是否有工程师自发地承担起这个角色。
什么是交付？
为什么那么多工程师认为交付项目很容易？我知道这听起来很极端，但我认为许多工程师甚至不明白在大型科技公司里交付项目到底是什么意思。交付项目意味着什么？它并不意味着部署代码或让用户使用某个功能。交付是在公司内部的一种社会构建。具体来说，当公司的关键人物认为项目已经交付时，项目才算真正交付。如果你部署了系统，但你的经理、副总裁或CEO对此非常不满意，那你就没有交付。也许你交付了一些东西，但你并没有真正交付项目。只有当你公司的领导层认可你已经交付时，你才算真正交付。在Slack上收到副总裁的祝贺消息或内部博客发布胜利声明都是好迹象。对于小项目，经理的认可就足够了。
这听起来可能有些循环，但我认为这是一个非常重要的观点。当然，如果你部署了一个用户喜欢并带来大量收入的项目，那你确实交付了。但这只是因为满足用户需求和赚钱是让领导层满意的事情。如果你交付了一个用户不喜欢且没有盈利的项目，但领导层满意，你也算交付了。你可以对这一点有你自己的看法，但这是事实。如果你不喜欢这一点，你可能应该去那些真正关心用户满意度的公司工作。
认为交付项目就是交付规格或部署代码的工程师会反复陷入失败的项目。
沟通
因此，如果你的主要职责是让公司的领导层对项目感到满意，那么这在实践中意味着什么？首先，你需要明确公司希望从项目中得到什么。有时是为了从一小部分用户那里获得更多收入（例如企业功能）。有时是为了花钱扩大用户总数（例如引人注目的免费层级功能）。有时是为了通过为某个特定的大客户构建功能来安抚他们。有时只是一个有影响力的副总裁或CEO的宠儿项目，你需要与他们的愿景保持一致。有很多潜在的原因，如果你想交付项目，你需要知道哪些原因适用于当前情况。相应地调整你的工作和沟通方式！例如，企业功能通常不需要华丽的UI，但在要求上完全没有灵活性；终端用户功能需要打磨；宠儿项目意味着你需要与那个特定的决策者保持积极沟通，等等。
其次，无论项目目标是什么，你的领导层（即你汇报链中关心该项目的人）相对于你来说，对项目的 技术背景基本上一无所知。这意味着他们会信任你提供的时间估计、回答技术问题以及预见技术问题。维护这种信任应该是你的首要优先事项。如果他们对你完成任务的能力和及时通报信息的能力没有信心，你就无法交付。他们可能会通过取消项目或让项目在无人关注的情况下推出来降低风险（记住，未庆祝的发布不算真正的交付！）。或者，他们会把你边缘化，转而找另一个工程师，后者正式或非正式地成为实际交付项目的人。无论是哪种情况，你都会在绩效评估时感受到影响，他们也会在下一个项目中找其他人。
如何维护与领导层的信任？这本身可以写成一篇文章（或一本书），但以下是我的总结：
- 最好的是有一个过去的成功交付记录，如果你能获得的话。
- 项目自信（如果你显得很担心，他们也会担心）。
- 项目能力。你应该努力达到NASA任务控制中心的那种感觉。
- 专业且简洁地沟通，不要让他们追着你要更新：定期发布每日或每周的状态更新。
这些比项目在确切截止日期前零缺陷交付要重要得多。如果项目因技术原因需要延期，在我看来，只要你清楚、自信地（最好提前）沟通，你不会受到惩罚。事实上，如果有一些问题迫使项目延期，反而对你更有利，就像那位在紧急情况下修复问题的英雄工程师比预防问题的谨慎工程师更受重视一样。
进入生产环境
即便如此，你通常仍然需要将项目投入生产。这里最常见的问题是忽略了一个关键细节。有时是技术细节：比如我们依赖于将用户文档存储在Memcached中，但许多文档有几兆字节，会超过Memcached的块大小。有时是协调细节：比如拥有Memcached的平台团队预计我们的项目只会给他们带来十分之一的流量，所以他们召开会议与VP讨论，导致项目延期。有时是法律细节：比如用户数据意外敏感，我们的系统没有处理这些数据所需的安全控制。这些问题可能来自任何地方，很难预料。处理这些问题需要对系统有深入的技术理解，并能够迅速转向。
例如，你可能读了第一个例子，现在在想“嗯，你可以将文档拆分到多个Memcached键中，或者增加块大小，或者迁移到Redis等……”。这些都是潜在的解决方案！但除非你有深入的理解，否则不可能知道哪些解决方案可行，更重要的是，哪些解决方案不会延长项目时间线。
这尤为重要，因为所提到的问题甚至不必是真实的。在项目启动前，其他团队或工程师经常会提出潜在问题（例如“嘿，我们确定用户数据能放进Memcached吗？”）。如果没有人站出来解释这不是问题（或者如果是，如何在启动前解决），项目将会延期，这将是你的责任。为什么？因为你的经理（或他们的经理）不知道这是否是一个严重问题。这就是他们付钱给你做的！如果你不站出来解决这个问题，他们自然会出于谨慎考虑而不交付。
你需要保持灵活，以便在这些问题出现时能够迅速应对，而不是深陷其他工作中。这通常意味着不要完全沉浸在实现细节中（即将任务委托给项目中的其他工程师）。理想情况下，项目初期至少20%的时间应从实现中解放出来，接近最后几天时这一比例应增加到90-100%。如果你能做到这一点，当问题出现时，你就能全身心地应对。
我们现在能交付吗？
特性开关是我见过的最好的方法，但测试环境也有效，等等。关键是尽可能多地让尽可能多的人看到你正在构建的东西：你自己，其他工程师，以及理想情况下领导、产品和设计团队等。即使在一个非常粗糙的状态下，五分钟左右的实际操作也能发现没人预料到的问题。能够直接看到这些也能大大增强领导的信心，让他们相信你已经掌控了一切。
预测问题的最佳方法是尽早部署。一般来说，一个有用的问题是“我现在能交付吗？”不是本周，也不是今天，而是此时此刻。如果不是，需要改变什么才能让我交付？如果交付需要部署，现在可以在特性开关后面部署吗？如果我们在等待其他团队在他们那一端做出更改，我可以做些什么让系统在没有他们更改的情况下也能运行吗？例如，如果平台团队正在设置缓存层，我可以使我的功能在找不到缓存时仍然能工作（尽管速度稍慢）。
记住，你的主要优先级是维护与领导层的信任。没有什么比有备选方案更能建立信任了，因为备选方案表明你对情况有控制。如果最坏的情况发生，你无法在预定日期发布，你的经理在向他们的经理报告时会更高兴，因为他们可以说“我们的选择是推迟四天，或者明天牺牲X来交付”——即使牺牲X是不可能的。这意味着他们更有可能将延期视为一个不可避免的问题，你处理得很好，而不是一个你犯的错误，使他们无法依赖你。
我认为很多工程师基本上是出于恐惧而推迟部署。如果你想要交付，你需要做完全相反的事情：尽可能早地进行尽可能多的部署，并尽可能早地进行最可怕的变化。记住，你是对项目有最全面了解的人，这意味着你应该对可怕的变更最不害怕。其他人都在处理更多的未知数，对拉动大杠杆的兴趣更低。（如果你在等待某个了解所有这些情况的其他工程师，坏消息是：他们可能是实际交付你项目的人）。
总结
- 交付项目非常困难，你必须将其作为主要优先级。
- 交付项目不意味着部署代码，而是让领导层满意。
- 你需要领导层的信任才能交付项目。
- 大多数关键技术工作在于预见问题和制定备选方案。
- 随着接近发布日期，减少实现工作量，以便自由应对最后一刻的问题。
- 你应该不断问自己“我现在能交付吗？”
- 有勇气！
