你拒绝需求的时候，产品经理根本没听懂你在说什么

华子上网 | 随笔

会议室里，产品经理问了一个问题。

他说，这个功能能不能三天上线？

你沉默了几秒钟。脑子里跑过一万行代码——数据库要改，接口要调，缓存要清，历史数据要迁移，还有那两个十年前留下的祖传表，牵一发动全身。

你说，不行。

他说，为什么？

你说，系统复杂度太高，改不了那么快。

他点点头，走了。但你感觉到，他没听懂。

这就是最经典的死结。

业务端的人活在一个叫"消除不确定性"的循环里。他们每天睁开眼想的是——用户想要什么，市场往哪走，这个功能上了能不能跑通，下个季度指标怎么完成。他们的核心生存法则是：快。越快越好。越快越安全。

你不知道的是，他们背后也有压力，上面要业绩，竞品在追，老板在催。他们提需求的时候，其实是在求救。

而你活在一个叫"管理复杂性"的循环里。

你的核心职责不是写代码，是为系统长期的稳定性承担责任。一个功能改了，今天好用了，三个月之后出故障了，第七个月数据坏了——到时候没人记得当初是"紧急需求"，所有人只会说"代码写的什么东西"。

所以我问你一个问题——

你拒绝需求的理由，是"控制复杂性"。他想要的东西，是"消除不确定性"。

这两件事，根本不在一个频道上。

你跟他讲技术债务，他听不懂。你跟他讲架构耦合，他听不懂。你跟他讲重构成本，他还是听不懂。

但他不是笨。

我有一个朋友，前些年带一个技术团队。

每次产品来提需求，他第一反应也是拒绝。后来他发现不行，因为每次都被产品经理绕到老板那里，最后还是要做，而且更难做。

他换了个招。

产品说要做A功能。他说，好，我明白你要解决什么问题。我们能不能试一个更快的办法？用现有的数据先搭一个摸底试试，三天出结果，告诉你这个东西行不行。

产品愣了一下，说，行。

你看，神奇的事情发生了。

他说的还是"受控的实验"，但产品听到的是"三天就能有答案"。

两个循环，突然就对接上了。

现在大家都在聊AI写代码。

GitHub Copilot、Claude Code、Codex——这些工具确实能写，写的还不错。

但你知道什么不会被替代吗？

是"承担责任"这件事。

AI不会为系统三年后的稳定负责。它不会在你睡着之后突然惊醒，想起某个配置文件可能在六个月后触发雪崩。它不会在一个凌晨三点的电话里被叫起来修复生产事故。

真正的资深开发者，不是代码写得快的人。

是那个出了事，所有人都看着他的人。

外面天快黑了。

茶水间的咖啡机还在咕噜咕噜响。你端着杯子，想着一会儿还要跟产品经理确认下周的排期。

这次，你打算换一种说法。

不聊复杂度了，不聊技术债了。

你打算问他一句——

你最想确认的问题是什么？我们一起用最快的办法找到答案。