软件交付后的维护问题，怎样划清处理范围？

第一类：原来能做的事，现在没有按约定完成第二类：功能没增加，运行条件发生了变化第三类：原定范围之外，又想增加一种做法收到问题、开始处理和验证通过，要分别记录结束前，把结果和遗留项分开

软件交付以后，一句“后面有问题再找我们”，往往不够用。使用者可能把页面报错、操作不熟、外部接口变化和新增功能，都叫作“维护”。接到问题的人如果没有共同的判断依据，就容易一边调查，一边争论这次到底该做什么。

维护范围可以先写成一张处理表：记录什么现象，依据哪份版本和说明判断，由谁接手，处理到什么状态才算结束。下面用一个假设的内部报修登记系统说明做法，不对应真实客户，也不讨论具体服务报价。

假设交付检查记录写明，普通员工可以提交报修单，登记人员可以查看本部门的单据。使用时却出现“提交成功，但列表里找不到”的情况，先对照当时确认的账号角色、数据范围和操作步骤。

问题单需要留下期望结果、实际结果、发生时间和复现条件。可以附脱敏截图或记录编号，但不要把密码、密钥和完整个人信息直接塞进群聊。材料的目的，是让接手人能够找到同一次操作，而不是收集越多越好。

这里还不能直接认定是程序缺陷。权限配置、筛选条件和数据写入问题，都可能出现相似表现。先保留证据，再确认原因，避免凭一句“以前能用”就决定修改哪里。

同一套代码，换了操作系统、浏览器、数据库版本或者外部接口，结果可能不同。维护表应记录交付时确认的运行条件，以及哪些变化已经经过验证。

例如，报修系统原先接收一种表格模板，使用者后来增加了合并单元格；或者短信接口改变了验证要求。这些问题需要先说明变化发生在哪里，再评估处理方法，不能只因为界面上还是同一个按钮，就当作完全相同的任务。

依赖更新也应留下版本记录。采用语义化版本的组件，会用版本号区分不兼容变更、兼容的新功能和兼容的问题修复。但版本号只是一个判断线索，不能替代阅读变更说明和实际测试，更不能单凭版本号决定维护责任。

方法示意：先确认发生了什么，再讨论处理范围。

假设系统已经能登记报修单，现在希望自动判断紧急程度，并把任务分配给不同人员。这增加了判断规则、输出和例外处理，与修复一个无法提交的按钮不同。

新增需求应单独记录：谁使用、输入是什么、产出是什么、有哪些暂时不做的情形，以及怎样检查结果。这样既不会让故障修复被新想法不断扩大，也不会让有价值的新需求只停在聊天里。

分类只是为了把工作说清楚，不是为了提前把责任推给某一方。同一个问题也可能拆成两段：先恢复已有功能，再评估新需求。各段分别留下处理依据和结果，便于之后核对。

“已经收到”表示有人接手信息；“开始调查”表示正在定位；“提供临时处理办法”表示可以暂时继续工作；“修复已部署”表示某个版本发生变化；“验证通过”还需要回到原来的使用场景检查。

这些状态不能合并成一个“已处理”。如果只记录回复了几次消息，就难以知道问题是否真的解决；如果只记录代码已改，也看不到使用者那边是否恢复。

约定处理方式时，可以写明信息从哪里提交、谁负责接收、哪些时段有人处理，以及什么情况需要升级给负责人。具体时间和覆盖范围应按真实安排填写，不在缺少人员和运行条件时写一个看上去很快的保证。

流程示意：一次状态变化应对应一份可核对的记录。

回到前面的报修例子，若原因是筛选条件设置错误，处理记录应说明调整了哪项条件，以及使用什么脱敏样例确认结果。如果原因是程序问题，则记录修改版本、验证步骤和仍受影响的范围。

无法立即解决的问题，也要写明当前影响、临时办法和下一步需要的材料。暂时恢复使用不等于根因已经修好；定位到原因也不等于修复已经上线。

还有一项容易遗漏：后续日常工作由谁负责。运行监测、备份检查、依赖更新和使用问题解答，可以分别列明负责人及实际覆盖范围。交付了一份代码，并不会自动决定这些工作由哪一方持续承担。

一张实用的维护表，可以依次记录问题现象、对应版本、运行条件、责任人、处理状态、验证记录和遗留事项。先让这些信息能相互对应，再讨论哪些任务属于已有维护安排、哪些需要另行确认，沟通才有共同依据。

参考资料：GOV.UK Service Manual《How the live phase works》；《Semantic Versioning 2.0.0》；Google SRE《Effective Troubleshooting》《Monitoring Distributed Systems》。本文的分类表与报修例子为独立整理，不代表上述资料统一规定的维护责任。

作者：聂亚奇。文字经AI辅助整理，配图为AI生成的方法示意。