在大厂交付大型项目的策略
原始链接: writing.samsonhu.com/tactics-for...
六年前我刚加入 Pinterest 做后端工程师时，还带着以前在初创公司的工作习惯：追求速度、缩小范围、尽快交付。但这些在小团队很管用的招数，在大厂反而成了绊脚石。我必须重新学习。
在大公司，单打独斗行不通。这里不鼓励走捷径，正确性和安全性比速度更重要。我一度很不适应，甚至想回初创公司。但后来我坚持了下来，并总结出了一套新经验。本文将分享我这几年学到的如何交付大型项目（即跨多个团队、耗时一年以上的项目）。如果你是想提升自己、扩大影响力的资深工程师，这篇文章正适合你。这些经验都源于我一路上的不断试错。
前期：把风险降到最低
只要是在自己团队内部的项目都好办，只要你的主管支持，你想怎么做都行。但如果需要跨团队借调资源，难度就会成倍增加。离你自己的汇报线越远，你对项目进度和资源的把控力就越弱。
你自己必须非常了解现有系统和要解决的问题，同时还要能向其他团队解释清楚。面对缺乏背景知识和时间的同事，你的沟通越清晰，获得支持就越容易。我发现使用架构图（如 C4 模型、Mermaid）和用户故事（User Stories）能很好地描绘出项目完成后的愿景。
只有大家对问题达成共识，才能去谈资源配置。毕竟你是在占用其他团队原本可以做其他事的时间，或者要求他们增加人手。因此，多花点时间评估项目影响，并与合作团队的领导层搞好关系是非常值得的。你的项目必须在众多备选项目中"脱颖而出"。
接下来要明确每个团队的具体交付任务。这是项目最关键的阶段，前期准备越充分越好。跨团队项目中如果遗漏了需求，会严重拖延进度，因为你的合作伙伴还有别的任务，很难在中途为你腾出时间。
通常，很难分清哪些是"发布前必须解决的阻塞需求"，哪些可以延后。你需要多花时间与用户及利益相关者沟通，明确这些界限并对外同步。
有时候需求比较模糊，解决方案可能依赖于你还不了解的底层系统。这时候也要尽量在前期搞清楚；如果实在搞不清，就明确标记为"未知风险"，并在推进中尽早解决。
各团队确认需求后，就可以初步制定项目时间表了。与合作方一起，明确各团队在什么时间点需要交付什么关键里程碑，并理清依赖关系。虽然计划赶不上变化，但时间表能明确各方的基本承诺。
最后，需求和时间表敲定后，确保你的项目被写进了自己团队和合作团队的 OKR（目标与关键结果）里。你可以让双方的领导层开个会，把合作关系正式敲定下来。
大型项目的前期阶段至关重要。你必须争取到其他团队的承诺，并预判未来的任务。前期准备越充分，中途遇到的意外就越少。
执行：把控进度不跑偏
项目启动后，你可以通过以下几种方式来保障进度：
首先是跨团队定期同步会。邀请所有利益相关者，特别是能解决卡点问题的负责人。会议初期可以讨论技术方案，但后期的核心目标应该是排定需求优先级、跟踪时间表。必须适时从"讨论技术"转向"降低交付风险"。
其次是团队内部的 1v1 沟通。不要理所当然地认为只要分配了任务，进度就会按时推进。你的队友不仅要做这个项目，还有日常运维、其他项目和个人目标。1v1 的目的不是聊技术，而是深入了解他们的工作优先级，确保他们有足够的时间按时完成项目的里程碑。
利用 Sprint（敏捷冲刺） 来安排内部工作。你需要对团队负责，确保进度。让每个人把任务拆解成具体的子项目和个人里程碑，并在 Sprint 规划中进行追踪。小心一个陷阱：不要以为每个 Sprint 都有任务完成就是有进展，真正的衡量标准是关键里程碑是否按期达成。
为了更好地关注里程碑，最好有一份汇总了整个项目时间表的单页文档，方便各方随时查阅。其目的是一旦发现延期苗头，就能及早预警并补救。
各方的交付成果可能会有偏差。可以通过两种方式解决：一是在前期设定好验收标准（如产品演示或跑通具体用例）；二是一旦功能就绪，你自己要第一时间去"试驾"体验，这样能最真实地掌握进展。
此外，建立一个统一的沟通群组也很有用。鼓励大家在群里随时 @ 人解决问题，特别是在远程办公环境下。但要避免在聊天软件里长篇大论，如果问题很复杂，请直接写文档，否则信息很容易丢失，导致错误决策。
发布：平稳落地
到了发布阶段，大部分风险应该已经排除了。关于系统迁移的技术挑战，业界已有成熟的经验（参考：现实世界中的工程挑战），我个人的建议是尽量多做自动化迁移工具。
此时最大的风险是需求遗漏。因此在迁移或上线前，要通过主管指定的委员会或实验数据来全面验证发布的可靠性。
如果发布阶段突然冒出新需求，而合作团队来不及处理，项目就可能延期或被降级。这通常超出了你的权限，需要向上级汇报，争取高层支持来解决问题。
如果项目面向用户，且灰度实验结果不理想，你可能需要将排查工作分配给其他人。如果你能在前期把问题拆解得足够清晰，别人接手排查的效果就会更好。
应对挑战与向上汇报
在大型项目中，你主要会遇到两类问题。
第一类是设计和执行问题。比如漏了需求，或者团队被其他事分心导致进度落后。通过前期的风险排查和扎实的项目管理，你能尽早发现并解决这些问题。尽早沟通进度变化，有助于维持与其他团队的信任。如果缺乏透明度，信任很快就会崩塌。
第二类是你无法控制的问题。比如你的项目与别的团队核心目标冲突，或者合作方突然改变计划导致项目被推迟半年，再或者大客户拒绝使用导致业务目标落空。
面对这类不可控的路障，如果没有领导层的支持，项目注定会失败。你需要能够向上汇报（Escalate），并在总监（Director）或副总裁（VP）的帮助下跨越部门壁垒解决问题。
如何以及何时向上汇报？
首先，评估你是否有条件去推进：你的项目对公司或合作方的影响力够大吗？你的直属领导支持你吗？其次，确保你已经穷尽了和合作团队沟通的所有办法。如果依然无解，那就该向上汇报了。
你需要准备一份正式的汇报文档，并获得团队核心成员和主管的背书。在文档中说明背景，以及项目受阻会对公司用户或财务造成的具体影响。文档要简明扼要、实事求是，并准备好为你的每一个数据辩护。
文档经过评审后会层层上报。你的总监会去和对方的总监沟通，或者上升到 VP 级别。向上汇报的目的不是用职级压人，而是寻找在团队层面无法解决的方案。高层能做出的决策包括：允许你的项目破例绕过某些设计规范、调动人员填补空缺，或者根据你提供的数据重新向全公司强调该项目的重要性，从而让合作团队优先解决你的问题。
写在最后
在大厂挑战大型项目是我职业发展中很有趣的一环。它不仅锻炼了跨团队协作的软技能，还培养了我排除项目风险的直觉。在这个领域我也还在不断学习，希望我的这些经验能帮到面临类似情况的大家。