上线后的运营、支持与迭代

本章目标：建立应用上线后的责任、反馈、问题处理和持续改进机制，让应用随着业务变化保持可靠，而不是上线后无人维护。

1. 上线后谁负责什么

责任	推荐负责人
业务规则和优先级	业务负责人
日常使用答疑	业务支持人员或应用管理员
应用配置和发布	应用开发者
角色成员维护	应用管理员与相关负责人
组织账号和平台服务	实例管理者
验收新版本	业务代表与应用开发者

一个人可以承担多项，但责任必须明确。

2. 建立统一反馈入口

不要让问题散落在多个聊天群和个人消息。

反馈至少记录：

• 提出人和角色；
• 发生时间；
• 业务记录或场景；
• 操作步骤；
• 期望和实际结果；
• 是否影响继续工作；
• 截图或必要材料；
• 临时处理方式。

统一记录便于发现重复问题和高频障碍。

3. 给问题分类

使用问题

应用正确，但用户不知道如何操作。处理方式可能是改提示、培训或入口。

配置缺陷

应用没有按已确认设计运行。需要修复和回归。

业务规则变化

组织政策或职责发生变化。需要重新确认并分析影响。

新需求

希望扩展新的对象、流程或管理能力。进入需求分析。

数据问题

错误、重复、缺失或分类不一致。需要确认责任和修正方式。

平台或环境问题

登录、服务或跨应用问题，需要与实例管理者协作。

分类正确才能选择正确处理路线。

4. 先复现，再修改

遇到“流程不对”“金额错了”：

1. 获取具体记录和时间；
2. 确认用户角色；
3. 还原操作步骤；
4. 对照当前规则和版本；
5. 判断是数据、配置、权限、流程还是理解问题；
6. 确认影响范围；
7. 再决定修复或变更。

应用日志可以辅助定位保存、动作和流程问题，使用方式参见应用日志，但最终仍要回到业务场景判断结果是否正确。

5. 监测应用是否真正被使用

上线后观察：

• 新业务有多少进入应用；
• 是否仍大量使用旧表格或聊天；
• 草稿和退回是否长期无人处理；
• 审批和采购是否积压；
• 用户是否频繁导出后在外部继续加工；
• 哪些字段经常为空或填错；
• 哪些操作最常求助。

如果用户绕开应用，不一定是“不配合”，可能是流程、体验或范围没有覆盖真实工作。

6. 监测业务结果

回到最初成功标准：

• 申请遗漏是否减少；
• 行政是否减少重复登记；
• 申请进度是否可见；
• 审批记录是否完整；
• 积压能否被发现；
• 管理统计是否可用。

应用上线只是手段，业务结果没有改善就需要继续分析原因。

7. 定期权限检查

建议定期核对：

• 角色成员是否仍符合岗位；
• 离职和调岗人员的旧权限是否回收；
• 临时代理是否到期；
• 应用管理员是否过多；
• 导出和敏感数据权限是否仍需要；
• 当前责任是否完成交接；
• 是否出现为了方便不断扩大权限的趋势。

权限会随着人员变化自然漂移，不能只在上线时检查一次。

8. 建立迭代优先级

可以从四个维度评分：

维度	问题
业务价值	能改善多大问题？
影响人数	影响一个人还是主要角色？
风险	不处理会造成错误、越权或中断吗？
成本和依赖	需要改多少对象、规则、流程和培训？

优先处理：

• 权限和数据风险；
• 阻塞核心业务；
• 高频且影响多人；
• 明确的小改进。

低价值、范围大、规则不清的新想法继续留在待分析清单。

9. 每次迭代都回到完整链路

例如新增“紧急采购”：

• 业务定义是什么；
• 谁可以标记；
• 是否需要理由；
• 表单增加什么；
• 流程是否分支；
• 通知是否变化；
• 视图是否需要紧急清单；
• 权限是否变化；
• 指标是否单独统计；
• 测试新增哪些场景；
• 对已有申请和在途流程是否有影响。

不要只加一个“是否紧急”字段就结束。

10. 维护应用文档

每次重要变更同步更新：

• 业务词汇表；
• 数据字典；
• 状态和规则；
• 流程图；
• 权限矩阵；
• 视图与指标口径；
• 用户教程；
• 测试回归集；
• 版本说明。

文档长期不更新后，新应用开发者只能从界面猜测规则，维护风险会迅速增加。

11. 备份与恢复意识

在重大调整和重要业务阶段前：

• 确认应用有可用备份；
• 知道由谁执行恢复；
• 了解恢复会影响哪些新数据；
• 不在没有确认的情况下覆盖正式应用；
• 破坏性修改前单独保留证据和恢复方案。

具体操作参见应用备份与还原。

12. 定期复盘

建议在上线后第一周、第一个月以及重大版本后复盘：

1. 原目标实现了多少；
2. 哪些用户仍在绕行；
3. 哪些规则最常出问题；
4. 哪些异常没有被设计；
5. 权限是否合理；
6. 指标是否可信；
7. 下一阶段最值得改什么；
8. 哪些功能应停止或简化。

复盘不仅增加功能，也可以删除无价值步骤、简化表单和收回不必要权限。

13. 判断应用是否健康

一个健康的业务应用通常表现为：

• 用户知道从哪里开始、下一步是谁；
• 核心业务不依赖私下补充信息；
• 异常有清楚处理方式；
• 责任和状态可查询；
• 权限随人员变化得到维护；
• 指标口径稳定；
• 修改有版本、测试和说明；
• 业务负责人和应用维护人明确。

14. 常见错误

• 上线后没有明确负责人；
• 所有问题都在聊天中临时处理；
• 没有具体场景就直接修改；
• 用户绕行被简单归因于不愿改变；
• 权限只增不减；
• 每次新需求只加字段；
• 正式规则变化但文档和测试不更新；
• 只增加功能，从不简化。

15. 本章完成标准

• [ ] 业务、应用、权限和平台责任已明确；
• [ ] 有统一反馈和问题记录方式；
• [ ] 使用问题、缺陷、规则变化和新需求能够区分；
• [ ] 先复现和判断影响，再修改；
• [ ] 持续观察采用率、积压、错误和业务目标；
• [ ] 角色成员和敏感权限定期检查；
• [ ] 每次迭代检查完整业务链路；
• [ ] 蓝图、教程、测试和版本说明随变更更新；
• [ ] 有固定复盘节奏。

下一步

方法已经完整。下一章通过办公用品采购申请完整案例，把需求、分析、设计、开发和验收串成一套可直接参考的示范。