每年Q1，技术团队都会经历一场庄严的仪式：写技术规划。

leader们关在小会议室里，对着白板画架构图，列痛点，排优先级，做资源估算。最后产出一个精美的PPT，把"技术债务治理""架构升级""效能提升"分门别类，附上里程碑和时间线。汇报的时候信心满满，老板点头通过，大家鼓掌散会。

然后呢？Q2还没结束，规划已经面目全非。Q3的时候，PPT里的那些项目，活着的大概只剩三分之一。到了Q4做复盘，大家心照不宣地跳过"规划完成率"这个话题，开始讨论明年的规划。

这个剧本，我见过太多次了。不是某一个团队的问题，几乎是一个行业现象。

规划是怎么死的

先说最常见的死法。

业务需求突然插队。 这个不用多解释，做过的都懂。理财业务突然要接一个新的资产类型，运营搞了个紧急活动，合规要求两周内整改——这些事情不会出现在你的规划PPT里，但它们会吃掉团队80%的产能。技术规划在业务需求面前，脆弱得像一张纸。

人力被抽调。 规划写的时候按10个人算的，Q1过完走了2个，Q2又借调1个去支援别的项目。你拿7个人去做10个人的规划，能完成就有鬼了。

优先级悄然下降。 这是一个更隐蔽的死法。规划里的项目并没有被明确取消，只是排期不断后延。"下个迭代开始""等这个版本发完""先把需求赶完"——一次次推迟，项目就软着陆了。没人宣布它死亡，但它确实死了。

这三种死法，本质上指向同一个问题：技术规划从来没有真正拥有过它所依赖的资源。 规划写的是"计划投入"，但资源的实际归属权不在技术团队手上。你规划的是别人的资源，那别人什么时候要回去，你管不了。

但这不是根本原因

说"业务抢资源"太表面了。业务一直在变，这不应该是个意外。如果每年都被同一个问题打脸，那问题不在业务，在规划方式本身。

我真正想说的是：年度技术规划这个做事方式，从逻辑上就是有问题的。

技术工作有两种截然不同的节奏。一种是业务驱动的——需求来了就做，上线了就完，节奏跟着业务走，短则一两周，长则一两个月。另一种是技术驱动——架构升级、基础能力建设、工具链完善，这些事情的周期和收益都跟业务节奏对不上。

年度规划试图用统一的框架来管理这两种节奏，把技术驱动的项目硬塞进业务规划的时间盒里。这就好比你把长途旅行和通勤上班放在同一个日程表里管理——不是不能做，但一旦通勤出了状况（天天出状况），长途旅行永远第一个被挤掉。

更关键的是，年度规划隐含了一个假设：我能预测未来6到12个月的技术投入方向。 但在大部分公司里，产品方向在一个季度内都可能变，你怎么预测技术方向？技术规划不是预测不准的问题，是预测这事儿本身就不靠谱。

规划的真正功能

既然规划总是被砍，为什么每年还要做？

这才是有意思的地方。年度技术规划的真实功能，从来不是"指导技术工作的执行"。它承担的是另外几件事：

要资源的筹码。 规划PPT里写10个项目，你知道能做成3个就不错了，但你得写10个。因为你要10个人的headcount，就得证明有10个人的活。这不叫规划，叫预算申请。

对齐期望的工具。 技术团队需要一个跟业务方、跟老板沟通的载体。"我们今年要做这些事"——说清楚，不是为了让所有人同意，而是为了避免后期扯皮。你规划里写过的东西后来没做，和你没规划就直接没做，性质完全不同。

团队凝聚的方式。 一起做规划的过程，是团队对齐认知、达成共识的过程。这个价值是真实的，也是规划唯一靠谱的交付物——不是PPT，是共识。

搞清楚这几件事，你就会明白为什么规划总是对的（因为它在政治上是必要的）而且总是被砍的（因为它在执行上是虚的）。这两件事不矛盾。

我对规划的态度转变

早年我对技术规划很认真，恨不得把每个里程碑都精确到周。后来经历了几轮"规划-被砍-重规划"的循环，慢慢想通了一件事：问题不在于规划被砍，而在于我用错了衡量标准。

用"规划完成率"来评估技术规划，就像用"投篮命中率"来评估一场篮球比赛的全部价值。你是投丢了，但你在跑位，在牵制防守，在为下一次进攻创造机会。规划也是这样，它最大的价值不是被线性执行，而是提供了一个方向感。

但要说我现在觉得规划没用，也不是。我现在的做法是：

把技术工作分层管理，不用一个规划管所有事。

一层是跟业务强绑定的，比如新功能的技术支撑、线上问题修复、业务侧性能优化——这些根本不需要放在"技术规划"里，它们天然会跟着业务节奏走。

另一层是纯技术驱动的，比如构建工具升级、监控体系完善、代码质量治理——这些用季度而不是年度来规划。一个季度的时间窗口足够小，业务变化的影响可控，也足够大，能交付一些有意义的东西。

不再试图在规划里做精确的资源估算。 10个人不等于10个FTE（全职等效人力）。有人的需求处理快，有人的需求处理慢；有人同时负责3个事，有人只专注1个。精确到人月的估算是伪精确，不如给一个模糊的范围，然后在执行过程中动态调整。

最重要的：规划里只放"不做什么会死"的事。 以前规划里塞满了"做了会更好"的项目，结果资源一紧张这些就全被砍了。后来只保留"不做会出事"的——安全治理、核心链路稳定性、关键依赖升级——这些项目天然有优先级免疫力，业务方也不会轻易动它们。至于"做了会更好"的事，见缝插针做就行，不需要进规划。

规划之外

其实还有一种更根本的思路：把技术投入嵌入业务节奏里，而不是试图跟业务节奏并行。

拿金融业务举例，定期理财有明显的周期——季末冲量、年末资金面波动、节假日用户活跃度变化。技术规划如果是独立于这些周期做的，大概率会被冲得七零八落。但如果你把技术升级顺着业务周期来安排——淡季做基础设施建设，旺季前做性能保障——技术工作和业务节奏就不是对抗关系，而是顺应关系。

这要求技术负责人对业务有足够的理解。不是那种"我知道产品在想什么"的浅层理解，而是真正理解业务的节奏、压力点和决策逻辑。为什么Q2比Q1忙？哪些月份需求会集中爆发？什么时候是合规整改的高频期？知道这些，你的技术规划才不是闭门造车。

我看到过一种做法挺有意思：技术团队不单独做年度规划，而是在每个业务版本的规划阶段，嵌入技术议题。业务版本要做什么功能，技术侧就提对应的架构保障和基础能力需求。看起来技术没有独立的"规划"，但实际上技术投入一直没有断过，只是换了一种姿态——从"我需要时间做技术"变成"你的功能要稳，需要先做这些技术准备"。

后者的说服力，远大于前者。

最后说一个扎心的观察

技术规划被砍这件事，技术团队自己也有责任。

很多技术规划的写法，就是写给技术人看的。架构图、技术选型、性能指标——这些在技术评审时很有用，但到了真正砍预算的时候，做决策的人根本不看这些。他们在意的是：这事儿对业务有什么影响？不做会怎样？做了能省多少钱？能避免什么风险？

如果一个技术规划里全是"提升开发体验""优化代码结构""升级框架版本"这类描述，那被砍真的不冤。不是说这些不重要，而是在资源竞争的环境里，它们的优先级天然低。你不在规划里把这些事情翻译成业务语言，没人会帮你翻译。

"升级框架版本"→"避免安全漏洞导致的线上事故和合规风险"
"优化构建速度"→"每个迭代多出2天开发时间，年化相当于多了2个人力"
"重构支付链路"→"支撑下半年3个新业务场景，否则只能临时拼烂代码堆功能"

同一个事情，不同说法。这不是话术问题，是你到底愿不愿意站在业务视角想问题。

年度技术规划总是被砍，这个现象不会消失。但你可以选择让它砍得少一点，或者让被砍的部分没那么重要。关键不是更努力地捍卫规划，而是承认规划的本质，然后把真正重要的事情放在规划之外保护好。