为什么企业信息化总是“需求失控”？

很多企业的信息化项目，都会经历一个看似不可避免的过程：

一开始，需求是清晰的。中间，需求开始变多。最后，需求变成了“无法收敛”。

项目上线那天，所有人都有一个共同感受：

“这个系统，好像哪里都不太对。”

奇怪的是。

没有人明确做错什么，但系统还是变得越来越复杂、越来越难用。

这不是偶然。

这是一个非常稳定、甚至可以预期的现象。

需求，是怎么一步步“失控”的？

来还原一个你一定见过的场景。

项目刚启动时，需求讨论会是这样的：

业务部门：提出核心流程
IT部门：评估可行性
乙方：给出实现方案

一切看起来都很理性。

但项目推进到中期，就开始出现变化：

“这个地方能不能顺便改一下？” “这个字段我们其实还想多加两个。” “这个流程稍微调一下就行，不复杂。”

注意这几个关键词：

顺便
稍微
不复杂

这些词，在现实世界里，是危险信号。

因为在系统世界里：

没有“顺便”，只有结构变化。

真正的问题，不是需求多，而是“需求没有边界”

很多人以为问题是：

需求太多

但更接近事实的说法是：

需求没有被定义清楚什么叫“需求”

在很多企业里：

想法 ≈ 需求
领导一句话 ≈ 需求
临时意见 ≈ 需求

于是系统就变成了一个奇怪的东西：

它不再是“设计出来的”，而是：

被不断叠加、修改、妥协出来的。

像什么？

像一栋没有总图纸的楼。每一层都有人在加东西，但没有人对整体结构负责。

需求的本质，其实是“权力的体现”

这里有一个不太友好，但非常真实的结论：

谁可以提需求，本质上是谁有权力。

在很多企业中：

业务部门有话语权
领导有最终决定权
IT没有否决权
乙方只能执行

于是会发生什么？

需求不再是“经过设计的”，而是“被权力推动的”。

这就会带来一个经典现象：

同一个系统里，同时存在三种逻辑：

业务逻辑
系统逻辑
领导逻辑

而这三者，往往是冲突的。

为什么IT总是“挡不住需求”？

很多IT人都有一种无力感：

“我知道这样做不对，但我拦不住。”

这不是能力问题。

这是角色设计问题。

在大多数企业中，IT的定位是：

服务部门

而不是：

结构设计者

于是：

IT没有决策权
IT无法拒绝需求
IT只能不断“实现需求”

结果就是：

系统越来越复杂， IT背锅越来越多。

乙方，其实早就看透了这一切

从乙方视角看，这件事更“现实”。

乙方的目标是：

项目交付 + 风险控制

当需求不断变化时，乙方通常有三种策略：

能做就做（保证关系）
做，但走变更（控制风险）
不建议做（但不一定拦得住）

所以很多时候，乙方并不是“不会做”，而是：

知道做了以后系统会变差，但项目必须继续。

这是一种非常典型的工程妥协。

系统为什么会“越用越难用”？

因为系统不是一次性设计完成的。

它是在不断的需求变更中，被“塑形”的。

如果这些需求：

没有统一原则
没有优先级控制
没有整体架构约束

系统就会出现一个现象：

局部最优，整体失控

每一个需求单独看都合理，但组合在一起，就是灾难。

真正成熟的企业，是怎么控制需求的？

他们做了一件看似简单，但极难坚持的事情：

不给“想法”直接进入系统的权力

而是设置“缓冲层”。

常见做法包括：

1. 需求必须被“评审”，而不是直接执行

不是谁提了就做，而是要回答三个问题：

这个需求解决什么问题？
有没有替代方案？
是否影响现有结构？

2. 需求必须分级

不是所有需求都一样重要：

必须做（合规 / 核心流程）
应该做（效率优化）
可以不做（体验优化）

否则结果就是：

所有需求都变成“必须做”。

3. 版本节奏控制

成熟企业不会“随时改系统”。

而是：

按版本发布
集中变更
控制节奏

因为他们知道一件事：

频繁改动，是系统稳定性的敌人。

IT部门真正该做的，不是“接需求”

而是做一件更重要的事：

定义什么才算需求

换句话说：

IT的职责，不是实现需求。

而是：

过滤需求、重构需求、约束需求。

如果IT只做第一件事（实现），系统一定失控。

写在最后

很多企业在信息化项目中，总在讨论：

“需求是不是还不够完善？”

但真正的问题往往不是：

需求不够多。

而是：

需求没有被约束。

系统不会因为需求多而失败，系统会因为——

没有边界的需求，而走向混乱。

当一个企业开始认真对待“需求的边界”，它的信息化，才真正开始走向成熟。