Staff 工程师如何推动重大技术变革？大型技术规划与 RFC 实战指南

一份面向 Staff 级及以上工程师的跨团队技术规划实战指南

很多资深工程师都会在职业生涯的某个阶段遇到这样的时刻：

你发现了一个非常重要的问题，也想到了一个颇具雄心的解决方案——也许是一次重大的架构调整，也许是一项关键的长期技术投资。你确信，如果组织想在未来取得成功，这项改变迟早必须发生。

于是，你认真写了一份 RFC，发给相关人员评审。

你收到了一些诸如“这个方向不错”“听起来值得研究”的反馈……

然后，就没有然后了。

路线图没有变化，没有团队投入资源，也没有人明确告诉你计划究竟是被否决了，还是只是“以后再说”。

这种既缺少明确反馈、又看不到实际结果的状态，非常令人沮丧。一方面，公司似乎在不断回避一个重要问题；另一方面，资深工程师也失去了展现更高阶技术领导力的机会——毕竟，晋升到 Staff 级及以上，往往需要证明自己能够产生跨团队、跨年度的影响力。

但换个角度看，这也是迈向更高层级工程工作的必经之路。

过去，你可能已经很熟悉如何编写团队级 RFC，并通过技术评审推动一个方案落地。但当你开始推动一项影响多个团队、持续数年甚至改变组织技术方向的重大变革时，原来的方法往往就不够用了。

对于 Staff 工程师而言，真正困难的已经不只是设计一个好方案，而是如何推动重大技术变革获得资源、形成共识，并最终真正落地。

你会遇到一组全新的挑战。

Staff 工程师推动大型技术变革，真正难在哪里？

管理层利益相关者

工程经理、总监以及更高层的管理者，对于重大技术变革能否真正落地至关重要。

说服其他工程师相信一个技术方案安全、合理，通常并不是最难的部分。

更困难的是说服管理者：

这项技术投资值得占用宝贵的工程时间和人力。

毕竟，大型技术改造通常意味着团队必须暂时放下一部分产品功能、业务需求或其他短期目标。

技术方案再好，如果没人愿意为它配置资源，也无法真正发生。

技术利益相关者

来自其他团队的 Staff 工程师、首席工程师或技术负责人，也需要认可新的架构方向。

而这同样并不容易。

他们往往比你更了解自己负责的系统，也更加清楚重大变革可能给团队带来的风险。

他们自然会担心：

这次架构调整会不会影响现有系统的稳定性？

会不会给我的团队增加大量迁移工作？

新的设计会不会破坏我们当前依赖的某些特性？

因此，仅仅证明“新方案在技术上更加先进”远远不够。

你还需要证明：

这个变化值得让其他团队承担相应的成本和风险。

系统复杂性

当一个技术计划横跨多个团队，甚至持续数年时，涉及的系统、依赖关系、迁移步骤和决策节点都会迅速增加。

最终，你很容易得到一个异常复杂的总体设计。

问题也随之而来：

计划越来越难解释，RFC 越来越长，评审者越来越难理解整个方案，而你自己也越来越难清晰表达哪些决定才是真正重要的。

规划周期

大型技术变革的规划和评审，往往需要几个月；真正实施起来，则可能持续数年。

这期间还有大量并不明确的协调工作。

因此，你很难判断：

这个计划现在只是在正常推进，只是本来就需要这么长时间，还是其实已经悄无声息地停滞了？

我参与过几个持续数年的大型重构项目，也帮助过一些工程师规划他们自己的长期技术项目。

我无法告诉你应该如何解决你所在公司的具体技术问题——这当然要视实际情况而定。

但我可以分享一套自己经常使用的规划框架，帮助这类大型技术计划持续向前推进。

里程碑 0：先把当前系统的架构与权衡讲清楚

大型技术计划首先会遇到一个非常现实的问题：

负责评审的高级领导者，通常已经离代码比较远了。

因此，他们对当前系统的认知很可能已经过时、不准确，甚至彼此之间完全不同。

更现实的是，他们通常也没有时间亲自重新研究整个系统。

如果参与讨论的人对“系统今天到底是怎么工作的”都没有形成共同认知，那么评审时，大量时间就会被浪费在理解现状上，而不是讨论真正重要的问题：

我们下一步究竟应该往哪里走？

因此，在真正提出解决方案之前，你需要先帮助所有相关人员迅速建立一套共同的系统认知。

这就是“里程碑 0”。

可以从下面几件事情开始。

更新系统架构文档

为现有系统补充一份简明的架构概览，重点讲清楚：

• 当前采用了哪些核心架构模式；
• 为什么会采用这些设计；
• 这些设计带来了哪些收益和代价；
• 系统与其他系统之间有哪些关键连接和依赖。

目标并不是写出一份百科全书式的技术文档。

真正的目标是让一个已经不熟悉实现细节的评审者能够迅速理解：

这个系统为什么会变成今天这样，它当前最大的权衡是什么。

补齐架构决策历史

很多重要的架构决策，并不是某一天通过一次正式技术评审做出来的。

它们可能来自一次临时选择、历史条件限制，甚至只是一个无意间延续至今的默认做法。

因此，最好把重要架构决策及其背景补充记录下来，尤其是过去从未正式写下的那些隐性决策。

这样一来，团队才能分辨：

哪些设计是经过认真权衡后的主动选择；

哪些只是特殊历史条件留下来的结果。

建立共同的技术语言

如果问题涉及一个相对成熟的技术领域，也可以组织读书会、论文阅读小组或技术分享，让相关人员熟悉行业中常见的模式、概念和术语。

这看起来可能与项目本身没有直接关系，但实际上非常重要。

只有当大家使用相同的语言讨论问题时，复杂的技术沟通才能真正高效。

值得注意的是，“里程碑 0”本身也可能改变你最初的判断。

在整理系统架构、历史决策以及既有约束的过程中，你可能会发现新的信息，从而意识到：

原本设想的改造方式并不是最优解。

因此，我更建议把这一阶段视为探索性工作、技能发展项目，或者一项值得主动承担的技术改进，而不是从一开始就承诺：

“我一定会用某种方式解决这个问题。”

这也是一个很好的检查点。

完成这些工作之后，再问自己一次：

这个问题现在真的还值得解决吗？

也许深入研究之后，你会发现还有其他更重要的问题需要优先处理。

这并不意味着之前的努力白费了。

即使最终没有启动大型改造，你整理出来的架构文档、决策历史和系统说明，对于新加入的工程师依然非常有价值。

里程碑 1：如何让管理层支持重大技术投资？

涉及多个团队的技术变革，通常意味着你需要和大量工程师合作。

你需要他们帮助理解其他系统受到的影响，参与探索不同方案，并最终承担一部分实施工作。

而现实往往是：

说服工程师从自己的日常工作中抽出时间来帮助你，可能比完成技术设计本身还要困难。

因此，要推动这样的大型技术项目，最好先在管理层找到一位明确的支持者。

这个人可能是一位总监，也可能是一位更高层的工程负责人。

然后，你需要写出一份清晰的问题陈述，回答一个最重要的问题：

为什么这个问题值得占用如此宝贵的工程时间？

我通常会使用下面这样的结构。

理想状态

用一句话描述你希望系统最终达到的状态。

理想情况下，<用一句话描述愿景>。

现实状态

用一句话描述当前系统真正存在的问题。

但目前，<描述当前最核心的痛点>。

造成的影响

列出这些问题正在给业务、团队或工程效率造成的实际影响。

例如：

• 浪费多少工程时间；
• 导致多少额外成本；
• 影响哪些关键业务指标；
• 带来哪些可靠性、性能或效率问题。

建议

明确提出下一步应该由谁来评估和设计解决方案。

例如：

建议由 <工作组> 评估并设计解决上述问题的变更方案，并由 <相关利益相关者> 进行评审。在此过程中，我们需要确保变更不会损害 <必须保留的关键系统特性>。

其他需要考虑的问题

简要列出：

• 与这个问题有关、但不属于当前范围的事项；
• 过去已经尝试过的方案；
• 仍待解决的问题；
• 当前存在的重要约束。

我建议把完整的问题陈述控制在 1～2 页。

如果篇幅太长，往往说明你还没有真正找出问题最关键的部分。

而如果连问题本身都无法明确优先级，后续的方案设计通常也会变得困难。

反过来，如果写得过短，则可能意味着你还没有进行足够深入的调查，也没有与足够多的利益相关者沟通，因此还没有真正理解相关风险。

这会让后面的审批更加困难。

此外，最好在这一阶段就明确记录关键的质量属性和业务影响。

例如：

性能需要达到什么水平？

系统可用性需要达到什么目标？

预计能够减少多少工程投入？

预计能够降低多少成本？

这些内容本质上都是非功能性需求。

提前把它们写清楚，可以帮助后面的讨论回答两个非常重要的问题：

技术方案做到什么程度才算“足够好”？

以及：

为了达到这个目标，值得投入多少工程资源？

里程碑 2：如何写一份适合大型技术规划的高层级 RFC？

经过几周甚至几个月的探索，你应该已经可以使用团队现有的 RFC 模板，写出第一版计划草案。

但这时通常会遇到另一个挑战：

把一个庞大的技术计划讲清楚，往往和设计这个计划本身一样困难。

如果把所有研究过程、技术细节和边缘场景全部塞进同一份 RFC，最终往往会得到一份异常庞杂的文档。

作者很难写。

评审者更难读。

因此，对于大型技术变革，我建议单独抽象出一份高层级 RFC。

这份文档不应该试图解决所有实现细节，而应该专注于那些真正需要跨团队认可的重要决策。

通常包括以下几个方面。

关键架构权衡

哪些决定会改变系统的核心特性？

我们通过这个设计获得了什么？

又必须放弃或者承担什么？

有哪些重要的技术权衡需要在现在这个阶段形成共识？

价值交付里程碑、决策点和预计成本

一个持续数年的技术计划，不应该只有一个遥远的最终目标。

你需要把它拆成若干阶段，并明确：

每个阶段能够交付什么价值；

哪些节点需要重新做出决策；

预计需要投入多少工程成本。

这样一来，即使完整计划需要几年时间，组织也能够不断判断：

这个项目是否依然值得继续推进？

对于涉及多个团队、周期较长的技术计划，如果目标、需求、阶段性任务、研发进展和技术文档分散在不同系统中，后续追踪成本也会迅速上升。此时可以借助 PingCode 这类覆盖目标、需求、项目、测试、发布和 Wiki 知识沉淀等研发全流程的管理工具，把高层级 RFC 中的目标和里程碑进一步映射到实际研发工作中，便于跨团队持续跟踪计划进展、依赖关系和阶段性交付结果。

后续团队级 RFC 的范围

不要试图在高层级 RFC 中把所有组件都提前设计完。

更好的做法，是把整个问题拆分成若干较小的范围。

这些具体部分可以等项目真正推进后，再由负责实施的团队分别编写更详细的团队级 RFC。

至于制定总体计划过程中产生的深入分析、实验数据和技术探索，则可以放到附录或辅助文档中。

这些细节对于一部分利益相关者非常重要，但并不是所有评审者都需要阅读。

这样做还有一个额外的好处：

给未来真正负责实现这些组件的工程师留下设计空间。

他们能够利用届时获得的新信息进一步改善方案，也有机会通过独立撰写 RFC 来展示自己的技术设计和领导能力。

当然，无论高层级设计还是团队级设计，只有真正吸收并回应了评审意见之后，才算完成。

里程碑 3：如何推动跨团队技术方案获得真正支持？

如果一个计划存在大量技术依赖和人员依赖，那么最终必须由所有负责实施的团队进行评审和认可。

而我发现，大型技术计划评审中最常见的一个陷阱是：

资深工程师太习惯团队级 RFC 的评审方式了。

团队内部的小型 RFC 通常遵循一个比较简单的原则：

只要方案充分处理了风险，而且不会给现有系统造成明显损害，就可以批准实施。

可以把它理解为一种“不造成伤害”的标准。

但对于跨团队、跨年度的重大技术变革而言，仅仅证明方案“不会把系统搞坏”远远不够。

你真正需要获得的是：

相关团队愿意支持这个方向，并愿意为它投入实际资源。

这是完全不同的标准。

在正式评审之前，先建立跨团队共识

对于这类重大技术计划，一种非常有效的方法，是在正式决策之前提前建立共识。

在一些管理实践中，这种方式被称为“根回”。

不必过分纠结这个术语。

它的核心思想非常简单：

在集体正式做出决定之前，先分别与每一个重要决策者沟通。

不要让相关负责人第一次认真看到你的复杂方案，就是在十几个人参加的正式评审会上。

正式评审之前，安排与你所影响到的系统负责人和团队负责人进行一对一沟通。

和他们一起讨论提案。

了解他们如何评价方案的质量。

询问他们认为哪些部分最重要。

听听他们对风险和权衡的判断。

同时，也要注意那些他们可能不方便直接写进公开 RFC 中的敏感意见。

然后，根据这些反馈修改 RFC。

再沟通。

再调整。

必要时重复几轮。

当涉及的团队和利益相关者越来越多时，也要避免关键信息只停留在会议和私聊中。对于跨团队项目，可以利用 Worktile 这类集任务、项目、文档、目标、即时沟通、日历等能力于一体的协作系统，把讨论结论、责任人、后续动作和关键时间点沉淀下来，让各方对“已经达成什么共识、还有哪些问题没有解决”保持一致认知。

这并不是为了绕过正式评审，更不是为了在会前“拉票”。

真正的目的是：

提前暴露分歧，让每一个关键利益相关者都有机会充分理解计划、表达问题并影响最终方案。

大型技术决策最不应该出现的情况，就是：

到了正式审批会议，你才第一次发现某个关键团队从根本上反对整个方案。

当你已经和所有关键决策者充分沟通，而且他们基本认可当前方向之后，再召开一次简短的正式审批会议。

这时，会议的目的不再是从头开始讨论整个设计，而是完成最终确认。

一种简单清晰的方式，是让所有关键决策者依次表态：

如果你认为这是目前最好的可行方案，也认为团队应该开始实施，那就明确表示支持。

如果有人仍然无法支持，也应该把剩余的阻碍清楚地摆出来。

当所有关键参与者都给出明确支持后，规划阶段才真正结束。

结语：Staff 工程师如何真正推动重大技术变革落地？

至此，你的计划终于得到了批准。

恭喜。

一项可能涉及多个团队、持续数年的重大技术变革，现在终于可以真正开始实施了。

但回头看整个过程，你会发现：

推动这种规模的技术计划，真正困难的地方，从来不只是设计一个优秀的架构。

首先，你需要帮助所有人建立对当前系统的共同理解；

然后，证明这个问题值得投入宝贵的工程资源；

接下来，把一个复杂、庞大的技术构想压缩成能够被理解、评审和决策的高层级计划；

最后，还要在正式审批之前，与各方反复沟通，逐步建立真正的共识。

这恰恰体现了 Staff 级及以上工程工作的一个重要变化：

你创造价值的方式，不再只是亲自解决最困难的技术问题，而是让一个复杂、跨团队、需要长期投入的重要技术变革真正有机会发生。

到了这个阶段，技术能力依然重要。

但你还需要具备另一种能力：

让正确的人理解问题，让组织愿意投入资源，让复杂的方案变得可以讨论，让利益相关者真正形成共识，并让一个原本可能永远停留在 RFC 里的想法最终变成现实。

对于 Staff 工程师来说，一份好的 RFC，只是推动重大技术变革的开始。