软件项目交付后的维护边界：缺陷、调整与新需求怎么分
软件上线后，维护阶段容易出现两种声音：一方认为“这个功能交付时就应该有”，另一方认为“这是新加的需求”。争议不完全是技术问题，更多是边界没有写清。维护条款只写“免费维护一年”并不够，还要说明维护对象、响应方式、包含什么、不包含什么。
先分清三类事项
实际项目里的事项大致可以分为三类，但具体边界要结合合同、需求文档和验收记录判断。
- 缺陷：系统在约定环境下未按已确认需求运行，例如页面报错、数据计算错误、流程无法走通。判断依据是需求文档、原型、验收标准和日志，不是口头印象。
- 调整：原需求方向不变，只改文案、字段顺序、提示语、权限范围或交互细节。它可能工作量不大，但会涉及设计、开发、测试和文档更新。
- 新需求：新增角色、新增流程、新增外部系统对接、改变数据口径或业务规则，通常会影响排期和费用。
三者不是按“改动行数”来分，而是按是否改变已确认范围和业务规则来分。一个字段的改动也可能牵动报表、接口和权限；一个看起来很大的页面改版，也可能只是样式调整。所以要先看影响面，再谈归属。
维护条款要写清四个对象
写维护条款时，不要只写期限。至少把下面四个对象写清楚。
维护对象
是仅维护本次交付的软件，还是包含服务器、数据库、第三方账号、接口和移动端安装包？第三方服务升级导致的问题由谁协调？这些要在交付清单中列明。若包含服务器运维，还要写清巡检频率和备份恢复责任。
响应与处理
区分咨询、一般问题、影响使用的问题和无法运行的情况，分别约定受理方式、响应时间和处理目标。响应时间不等于修复时间，修复时间受复现条件、日志完整度、第三方配合影响，不宜写成模糊承诺。
包含的工作
明确是否包含缺陷修复、数据备份检查、安全补丁、日志排查、基础操作答疑和版本发布支持。若涉及数据库或服务器，还要说明由谁执行、在什么时间窗口执行。
不包含或另行计价的工作
新需求、界面整体改版、第三方接口变更适配、历史数据清洗、超出约定并发的性能优化，通常应另行评估。不是所有维护都该免费，也不是所有小改动都该另收费，关键看合同约定和影响范围。
处理流程：先记录，再判断，最后排期
维护事项进入处理前，先做一张简单记录：现象、发生时间、影响范围、复现步骤、相关账号、截图或日志。没有这些信息，开发只能猜，沟通成本会迅速上升。
- 先复现：确认是个别账号、特定设备还是全部用户。
- 再对照：查需求文档、验收记录和变更记录，判断是否偏离约定。
- 定分类：缺陷进入修复流程；调整和新需求进入评估流程。
- 给方案：说明影响范围、工作量、排期和是否需要额外费用。
- 留记录：变更内容、上线时间、验证结果写进版本记录。
这套流程的价值不是把责任推来推去，而是让双方对同一件事有共同依据。特别是涉及数据口径、权限和外部接口时，口头确认很容易在后续变成争议。先记录再判断，也能避免“顺手改一下”累积成无法核对的隐性工作。
适用边界与合同写法
上述分类适用于有明确需求文档和验收记录的定制软件项目。如果项目采用敏捷迭代、按人天计费，边界会不同，应以迭代范围和工时记录为准。若系统涉及医疗、金融、支付等强监管场景，维护还要叠加合规、审计和日志留存要求，不能只按普通软件处理。
合同里可以用“附件加变更单”的方式：附件列明交付范围和维护对象，变更单记录新增或调整事项。这样既不把维护条款写得过死，也避免所有口头需求都变成免费工作。交付时把源代码、部署文档、账号清单和已知问题列表一并交接，后续维护才有可查的依据。