组织用户验收并准备上线

本章目标：让代表性业务用户用接近真实的方式验证应用，形成明确验收结论，并完成上线所需的人员、数据、培训和支持准备。

1. 用户验收和开发测试的区别

开发测试主要确认设计是否被正确实现。

用户验收主要确认：

• 应用是否真的支持日常工作；
• 业务规则是否符合组织决定；
• 一线用户能否理解和完成任务；
• 管理者能否得到需要的信息；
• 异常处理是否现实可执行；
• 组织是否准备好改变原来的工作方式。

一个功能完全按蓝图实现，仍可能在验收中发现蓝图本身不适合真实工作。

2. 选择验收人员

至少包括：

• 真实申请人代表；
• 真实主管代表；
• 行政采购员；
• 行政负责人或业务负责人；
• 应用开发者；
• 必要时实例管理者。

选择人员时注意：

• 既有熟练用户，也有普通或新用户；
• 覆盖不同部门和常见差异；
• 参与者有时间完整执行，而不是只看演示；
• 最终确认人明确。

不要让应用开发者代替所有角色演示后，请业务负责人只口头说“可以”。

3. 准备验收环境和数据

验收前：

• 使用与正式使用相近的角色和组织关系；
• 使用脱敏但真实感足够的数据；
• 准备普通、高金额、退回、缺货、作废等场景；
• 清楚标记验收数据，避免与正式记录混淆；
• 确认通知和外部协作不会误发给无关人员；
• 为每位参与者准备账号和操作说明。

4. 用业务任务而不是功能菜单验收

不要给用户一份这样的清单：

打开模板，点击新增，输入字段 A，点击按钮 B。

更好的任务：

你的部门需要购买 10 盒打印纸和 2 个键盘，预计总额 710 元。请创建申请、保存草稿、补充一行物品并提交。随后以主管身份退回，要求补充用途；申请人修改后重新提交，主管同意。最后由行政登记采购完成。

任务只提供业务背景和必要前提，不替用户决定每一步怎么点。这样才能发现导航、命名和交互是否真正清楚。

5. 验收剧本

剧本一：普通采购

• 创建两行明细；
• 保存草稿并重新打开；
• 提交；
• 主管同意；
• 行政完成采购；
• 申请人查看结果。

剧本二：高金额

• 总额 5000.01；
• 主管同意；
• 确认增加负责人审批；
• 全部通过后进入待采购。

剧本三：退回修改

• 审批人填写明确退回原因；
• 申请人看到原因；
• 修改金额；
• 重新提交并按新金额选择路线。

剧本四：权限

• 申请人 A 尝试查看申请人 B；
• 主管尝试修改申请明细；
• 行政尝试进入应用设计；
• 未授权用户尝试访问旧链接。

剧本五：管理

• 行政查看待采购；
• 负责人查看积压和月度金额；
• 使用筛选、导出或打印完成真实管理任务。

6. 观察而不是指导

验收时应用开发者应记录：

• 用户在哪里停顿；
• 哪些词看不懂；
• 是否需要口头解释才能继续；
• 是否走错入口；
• 是否没注意到错误提示；
• 是否仍然打开原 Excel 或聊天补充工作；
• 是否对状态和下一责任人理解一致。

除非用户完全无法继续，不要立即指导。需要指导本身就是使用体验证据。

7. 收集反馈的方式

不要只问：

“感觉怎么样？”

可以问：

• 哪一步最难理解？
• 哪些信息你需要但没看到？
• 哪些内容要求你重复输入？
• 出错时是否知道怎样修正？
• 你是否知道提交后由谁处理？
• 哪个现有工作仍然要在应用外完成？
• 如果明天正式使用，你最担心什么？

8. 给反馈分类和定级

类型	示例	处理方式
阻塞缺陷	正常申请无法提交	上线前必须修复
严重业务错误	5000 元走错流程	上线前必须修复
权限风险	能看到他人敏感申请	上线前必须修复
使用障碍	用户找不到退回原因	优先修复或改善
一般改进	列顺序更符合习惯	评估当前或后续
新需求	增加供应商比价	进入后续范围评估

验收不是现场无限增加功能。新需求仍要经过范围和影响分析。

9. 验收通过条件

建议同时满足：

• 所有必须业务场景通过；
• 关键异常和权限反例通过；
• 没有阻塞缺陷和严重业务错误；
• 目标角色无需开发者代操作即可完成主要任务；
• 统计和输出口径由负责人确认；
• 已知限制有清楚说明和业务接受；
• 上线范围、日期和负责人明确；
• 验收结论有记录。

10. 准备正式角色和成员

上线前核对：

• 哪些部门进入首批范围；
• 每个角色的正式成员；
• 直属主管等组织关系是否完整；
• 临时测试人员是否从正式角色移除；
• 应用管理员和业务负责人是谁；
• 人员离岗和角色变更由谁维护。

11. 准备初始数据

确认：

• 是否需要导入基础资料；
• 是否需要导入历史申请；
• 历史数据导入到什么程度；
• 数据由谁清理和确认；
• 重复和无效数据怎样处理；
• 导入后如何抽样核对；
• 上线切换时旧表格是否停止新增。

如果第一版不迁移历史，明确旧资料保留在哪里、用户如何查询，以及新旧业务按什么日期切分。

12. 培训不是逐个讲按钮

培训应按角色和任务：

申请人

• 何时使用应用；
• 如何保存草稿、提交和查看进度；
• 退回后如何处理；
• 遇到问题联系谁。

审批人

• 从哪里看到任务；
• 作决定需要看什么；
• 同意、退回和拒绝的区别；
• 人员不在时如何代理。

行政采购员

• 如何查看待采购；
• 如何登记结果和异常；
• 如何完成和作废；
• 如何使用管理视图。

培训要解释新工作方式，不只是界面操作。

13. 上线切换计划

明确：

• 正式启用时间；
• 哪些部门和业务开始使用；
• 旧渠道何时停止；
• 进行中的旧申请怎样处理；
• 上线当天谁负责支持；
• 出现严重问题时怎样暂停或恢复；
• 第一天和第一周检查哪些结果。

采购案例可采用：

周一 9:00 起，试点部门新办公用品申请统一从 Kimpo 发起；此前已在处理的申请继续按旧方式完成。试点一周后评估是否扩大。

14. 上线后第一轮检查

当天检查：

• 用户能否进入；
• 角色和数据范围；
• 第一笔申请保存和提交；
• 正确审批任务；
• 退回和通知；
• 行政待采购视图。

第一周检查：

• 是否仍有大量申请走旧渠道；
• 是否有无人处理或超时；
• 是否出现权限问题；
• 用户最常卡在哪里；
• 指标和视图是否能反映真实业务；
• 是否有需要立即修正的高频问题。

15. 常见错误

• 验收等于开发者演示；
• 参与者全是管理者，没有一线用户；
• 任务清单把每一步点击都告诉用户；
• 新需求在验收现场全部承诺加入；
• 只确认正常流程；
• 没有清理测试角色和测试数据；
• 应用上线但旧渠道没有停止；
• 没有第一天支持和严重问题处理方案。

16. 本章完成标准

• [ ] 真实角色代表独立完成业务任务；
• [ ] 验收覆盖正常、边界、异常、权限和管理场景；
• [ ] 使用障碍通过观察而不是只靠问卷发现；
• [ ] 反馈已分类，没有把所有内容当成当前缺陷；
• [ ] 通过条件和签字确认人明确；
• [ ] 正式成员、组织关系和应用管理员已准备；
• [ ] 初始数据和旧渠道切换方案明确；
• [ ] 培训按角色任务设计；
• [ ] 上线当天和第一周检查清单已准备。

下一步

上线不是结束，而是应用第一次进入真实业务。下一章学习上线后的运营、支持与迭代。