为什么很多传统软件行业做不好产品?

在传统行业做软件，卡住项目的从来不是代码。

是那些代码之外、又没人愿意摆到台面上的东西。

最近几年，我接触的项目大多落在传统行业：供水、市政、地质监测。

这些项目有一个共同点：技术方案本身不复杂，难的是让系统真正被用起来。

我见过上线那天会议室站满人、三个月后后台只剩几个活跃账号的系统。

也见过需求文档写了厚厚一叠、最后一期只交付了其中一部分功能的项目。

这些情况，在我接触过的纯互联网团队里很少发生。

所以我想认真聊聊这个题目：为什么很多传统软件行业做不好产品？

我的结论可能不太客气：问题基本不在技术侧。 下面是我看到的四个原因。

01｜先纠正一个说法：这不是"不懂技术"的问题

很多人第一反应是：传统行业不懂技术，所以做不好软件。

这个说法我不认同。

我合作过的一些传统行业 IT 部门，技术能力并不弱：有专职开发、有运维、有网络安全岗，有的还自建了私有云。

真正的问题在于，他们对"软件产品"的理解，和做软件的人不是一回事。

一边想的是"买一套系统，把事办了"。

另一边想的是"做一个产品，让它持续被用、持续迭代"。

这两种理解之间的差距，才是项目出问题的起点。

02｜原因一：软件被当成"采购品"，不是"产品"

这是最根本的一条。

在很多传统行业的流程里，软件走的是采购这条路：立项、比价、招标、签合同、验收、付款、结项。

这套流程本身没问题，用在设备、材料、工程上都合适。

但软件不是一次性的东西。它需要有人持续维护，也需要有人跟着业务变化不断调整。

采购流程的终点是"验收合格"，而软件真正考验人的地方，恰恰在验收之后。

我遇到过一个挺典型的情况。立项招标那会儿为了压预算，规划里的数据联动、移动端处理、业务闭环被划成"不是必须"，最后只留了基础的信息展示和查询。

上线那天验收很顺利，标准都满足。可真正交给一线的人用，大家发现最需要的偏偏是被砍掉的那几块。

原来的工作流程并没有因为系统上线而改变。很多事还是回到 Excel、微信群，甚至纸质记录里完成。

验收通过了，业务人员还是按原来那套在干活。

至于责任，采购部门付完款就结项了，业务部门觉得"系统的事该找 IT"，IT 觉得自己只是运维。没有人真正为"它有没有被用起来"负责。

03｜原因二：从业务语言到系统语言，中间那层翻译没人做

需求调研的时候，业务人员说的话通常是这样的：

"我希望随时能看到每个站点的运行情况。"

这句话没错，但它离"能开发的系统"还差好几步。

最少要确定五件事：哪个岗位看、实时性要求多高、什么算异常、看到异常之后能做什么、判断错了算谁的责任。

这五件事，业务人员通常不会主动说。不是不愿意说，是在他的日常工作经验里，这些本来就不需要说出来。

我做过一个核心业务模块，从第一次提需求到最后确认，来回谈了五六轮，拖了将近两周。刚开始所有人都觉得这事很简单，会上几分钟就达成了共识。

真开始拆字段、拆流程、拆权限，才发现同一句"查看某个站点的运行情况"，不同岗位脑子里装的完全不是一件事：有人盯实时数据，有人看历史趋势，有人只关心异常，还有人关心异常之后谁来处理。

拦住进度的不是技术做不到，也不是谁不配合，是把一堆"都觉得自己说清楚了"的需求，重新翻译成一套能开发、也能验收的规则。这个过程本身就很贵。

大多数项目里，这一步是没人负责的：需求文档写是写了，会也开了，但没有人拿着文档逐条问过"这句话落到系统里，具体是什么"。等开发做完，才发现双方说的不是同一件事。

04｜原因三：只考核"上线"，不考核"用起来"

在项目排期表上，"上线"是一个有仪式感的节点：有通报、有剪彩、有验收款。

而"用起来"是半年后的事。那时候项目组往往已经解散了，问题反馈到谁那里都要重新找人。

于是就出现了这个局面：

所有资源都投在了上线之前，而上线之后恰恰是最需要投入的阶段。

上线指标完成了，验收款拿到了，没有人回头看使用数据。系统从"没人用"变成"没人提"，问题被沉下去，而不是被解决。

05｜原因四：IT 是成本中心，不是能力中心

这一条在预算表上看得最清楚。

业务部门的系统建设预算，通常走的是"信息化费用"这个科目。它的性质是支出，要控制、要压缩、要论证必要性。

但软件真正的价值，是在它被用起来之后，从业务流程里一点点长出来的——这部分价值，在预算表上体现不出来。

一个部门如果把 IT 定位成"保障部门"，那么它评估 IT 的方式就会是"有没有出事、花了多少钱"，而不是"帮业务做成了什么"。

评估方式不一样，人的行为就会跟着不一样。

06｜这四件事，会连成一个循环

单看每一条，都不算致命。麻烦的是它们会互相强化。

以采购的方式立项，验收标准停在"上线"；上线之后没人管、用不起来；等到下一轮立项，"上一套系统没什么用"就成了现成的经验，于是预算收紧、更强调比价和交付速度——又回到第一步。

这个循环跑上两三轮，结果就是：钱花了不少，系统建了一堆，业务还是靠 Excel 和微信在运转。

而且每一轮都会加深同一个印象："做系统这件事，不太靠谱。"

这个印象一旦形成，比任何技术问题都难解决。

07｜那什么样的项目，能做成？

结合我自己做成的那几个，能总结出三条。

第一，找一个真正会用这个系统的人，让他参与到底。

不是挂名的负责人，是他本人每天要在这个界面上干活的那种人。

他对"能不能用"最有发言权，也最有动力把它用好。

第二，先做小，先上线，先看到真实的使用数据。

不要一上来就规划覆盖全业务的完整版。先做一块最痛的业务，两三个月上线，看它到底有没有被打开。

用真实数据决定要不要继续投，比在会议室里争论有效得多。

第三，把"用起来"写进验收标准。

比如上线三个月后的活跃账号数、某个核心流程的线上完成率。

一旦这条写进合同，项目组的注意力就会从"什么时候上线"挪到"上线之后怎么办"。

08｜最后说句实在话

有一个判断，我知道不是所有人都同意：

传统行业做不好软件，主要责任不在传统行业自己。

那些讲"甲方不懂技术"的说法，我觉得是把结构问题说成了能力问题。

真正缺的，是愿意站在"业务怎么用"和"系统怎么做"之间那层的人。这层工作既不属于纯业务，也不属于纯开发，两边的工作描述里都找不到它的位置。可它恰恰决定了一个项目能不能落地。

所以我更愿意把话说到这：传统行业不缺技术，缺的是把一个系统从"交付"带到"用起来"的人。

如果你正在做类似的系统，或者你正卡在这个环节上：你遇到的最大障碍是什么？预算、需求，还是没人管？

小程数字实验室

Software · AI · Data · Visualization

持续折腾，持续记录。