软件开发中的“需求蒸发”：上线后才涌现的需

一、上线后的需求清单

某企业的业务系统上线一个月后，业务部门提出了一串优化需求：列表页增加多选批量操作、详情页增加历史修改记录查看、导出报表增加合计行、搜索框支持模糊匹配、审批流程增加撤回功能、数据导入增加格式校验提示、权限设置增加按部门筛选……清单上的需求有二十几条，每一条单独看都不大，但全部加起来相当于几周的工作量。项目经理很困惑，这些需求在上线前为什么没有人提过。

上线前，业务部门的需求是“把系统做出来”。上线后，业务部门的需求变成了“把系统做好用”。前者是功能性需求，后者是体验性需求。功能性需求在项目阶段被关注，体验性需求在项目阶段被忽略。业务部门在项目阶段看到的是原型或测试环境，数据量小、用户少、操作路径短。体验性问题在数据量小的情况下不容易暴露，用户少的情况下流程冲突不容易发生。上线后真实数据量增长、真实用户涌入、真实业务场景出现，体验问题才集中显现。

二、需求蒸发的三个阶段

阶段一：需求调研时的蒸发

需求调研阶段，顾问访谈业务部门，问的是“你们需要什么功能”。业务部门的回答通常是“能录入订单”“能查询库存”“能生成报表”这类大方向描述。细节在调研阶段还处于未被触及的状态。业务部门不会主动说出“查询结果要支持按日期排序”“导出报表要带合计行”这种细节，因为他们默认“系统应该会这样”。默认的假设没有被验证，细节需求就沉淀下来了。

调研阶段的需求清单包含了业务部门能想到的功能，但业务部门能想到的功能不等于业务部门需要的全部功能。那些“默认系统会做到”的细节，在调研阶段不会出现在需求清单里，上线后才以优化需求的形式重新出现。

阶段二：设计稿确认时的蒸发

设计稿确认阶段，业务部门看的是页面布局和操作流程。他们关注的是“这个按钮放在这里对不对”“这个页面跳转合不合理”。交互细节在设计稿阶段还不是视觉评审的重点。列表页的排序方式、搜索框的匹配规则、报表的导出格式，这些细节在评审设计稿时通常不会被逐项检查。

项目阶段的设计评审，业务部门倾向于确认“有没有”，而不是“好不好”。按钮存在就可以了，按钮好用不好用，要到实际使用时才能判断。

阶段三：测试验收时的蒸发

测试验收阶段，业务部门测试的是功能是否跑通。点击按钮有没有反应、表单提交后有没有提示、数据保存后有没有更新。功能通不通是验收的重点，好不好用是验收的盲区。好用的标准是用户在实际操作中才会感知到的，验收测试的短暂时间内无法充分暴露。验收测试时用户会按照设计的操作路径走，实际使用时用户会走出设计之外的操作路径。

三、需求蒸发的机制分析

机制一：抽象需求到具体实现之间的决策缺口

业务部门的需求是抽象的、目标导向的。“我们要提高订单录入效率”，这是一个抽象需求。具体实现方式包括：字段预填、默认值设置、下拉选择代替手工输入、批量导入、模板下载等多种选择的组合。业务部门看到具体界面之前，没法判断哪种实现方式更适合自己的操作习惯。抽象需求到具体实现之间存在大量的决策缺口，这些缺口在项目阶段没有被填充，在上线后的使用中逐步浮现。

机制二：测试环境与实际运行之间的条件差异

测试环境的数据量远小于生产环境。列表页在100条数据下加载很快，分页逻辑看起来没问题。生产环境下数据量增长到1万条，列表页加载变慢，分页操作需要等待。性能问题在测试阶段不会暴露。测试环境的用户并发量远小于生产环境。审批流程在3个人测试时没有冲突，上线后20个人同时使用，数据锁、版本冲突、状态不一致的问题开始出现。

机制三：项目交付节奏与体验优化需求的错位

项目有明确的结束日期，验收通过即交付。体验优化类的需求在项目阶段通常会被排到“下一期”。项目阶段为了按时上线，需求优先级会按“能否按时交付”来排序，不影响核心功能的优化需求排在后面。“下一期”的安排在上线后往往被新的项目挤占，体验优化需求的交付时间持续延后。业务部门的期望和实际交付之间的差距随延长时间逐步扩大。

四、减少需求蒸发的方法

方法一：原型测试代替文档确认

需求调研的输出不是Word文档，是可交互的原型。业务部门点击原型上的按钮、填写表单、查看列表、导出报表，在操作过程中提出反馈。原型迭代一轮的需求澄清效果，远高于文档评审多遍。原型的使用场景和真实使用场景越接近，需求澄清的效果越好。

方法二：真实数据量下的性能测试

测试环境的数据量尽量接近生产环境的预期规模，使用数据生成工具创建与生产环境规模和结构相似的测试数据。性能测试应该在功能测试完成后、验收测试之前进行，而不是在验收测试时才发现。性能问题的修复周期比功能问题长，数据结构层面的问题比代码层面的问题耗时更长。

方法三：上线后设置体验优化窗口

项目上线后不立即解散项目组，预留体验优化窗口。业务部门在真实环境中使用系统，处理实际业务、操作真实数据、走通完整流程。使用中暴露的问题集中收集、分类处理。优化窗口结束后，剩余的需求正式进入运维通道。体验优化窗口是项目阶段和运维阶段之间的过渡带，过渡带的长度根据系统复杂度和用户规模确定。

五、新易编码在需求管理中的位置

编码管理是业务系统中规则相对稳定、变更相对可控的模块。编码规则的需求通常在系统上线前就已经明确，上线后变更的频率较低。新易编码通过规则配置化减少了需求变更对开发流程的依赖。

规则配置化：编码规则调整不需要走开发排期，编码管理员在新易编码的配置界面完成调整。配置变更不需要需求评审、代码开发、测试验证的完整流程。

版本管理：编码规则的多版本并行运行，新规则不破坏旧数据。规则调整不需要一次性切换所有物料，可以按类别分批迁移。迁移周期不影响业务系统的正常运行。

使用数据的可追溯性：编码的申请记录、驳回记录、变更记录、引用次数，构成需求分析的数据基础。哪些物料类别申请频繁被驳回，哪些规则经常被用户绕开，通过系统日志可以识别出流程中的断点，帮助业务系统优化需求排序。

软件开发中需求蒸发的原因不是业务部门提不出需求，是项目阶段的测试环境、数据规模、用户并发量与实际运行环境之间存在差异。抽象需求到具体实现之间的决策缺口，测试环境与实际运行之间的条件差异，项目交付节奏与体验优化需求的错位，三个因素共同导致上线后需求清单集中爆发。

将原型测试、真实数据量测试、体验优化窗口纳入项目计划，可以减少蒸发到上线后的需求比例。项目阶段的需求覆盖率越高，上线后的需求变更越少，运维阶段的资源越能集中在业务功能迭代上，而不是问题修复。资源分配的变化是长期优化软件开发流程的体现。编码管理在业务系统中需求变更频率较低，适合通过规则配置化的方式减少对开发流程的依赖。规则配置化的核心逻辑是：业务规则的变化频率高于代码的变化频率时，把规则从代码中剥离出来，交由业务人员自行维护。配置化的适用范围由规则的变化频率和规则的影响范围共同决定。变化频率高且影响范围可控的规则，配置化的价值最大。编码规则是这两项都适用的典型类型。配置化的边界由业务系统的接口稳定性决定，接口不变，规则的配置化就可以独立运行。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码