培训做完了没人会用，缺的不是课时

结论先行：培训这一项最容易变成「讲了两场、签到、结束」。要交的不是课时，是三份能被别人接着用的东西：管理员手册、用户手册，以及一份能证明「讲过之后确实会了」的考核记录。前两份证明知识被写下来了，第三份证明知识被接住了。缺第三份，项目交付的是两份文档和一屋子听过但没练过的人。

本文只谈培训这一项的验收口径与交付材料，不谈整个项目文档体系怎么分阶段，也不谈系统上线之后使用率怎么拉。文档体系是另一套东西，使用率是运营问题，两者都不该压在培训这一项上。

两类人，两套材料，别混着讲

三类合一讲，是最常见的做法，也是最无效的做法。管理员的关注点在「坏了怎么修」，用户的关注点在「这个键在哪」，主管的关注点在「出了事找谁」。同一场培训里三拨人各自听了一半，回去还是各问各的。

考核记录要能回答三个问题

考核记录不是考试成绩单。它要能回答：谁考的、考的是哪几个动作、什么标准算通过。可行的写法是把动作列成清单，一项一项勾，例如「独立创建并下发一次策略」「独立回退到变更前状态」「独立导出一次审计报表」。勾选的人签字，被考的人签字，日期写上。

这样一份记录的实际用途比想象中多。新人接手时可以照着清单再考一遍；审计问「谁有权限操作这套平台」，能拿出受过训练的证据；服务商换人时，客户也有依据要求重新过一遍。反过来，只提供一份签到表，这三件事一件都支撑不了。

上线首周，才是真正的验收期

培训结束与真正会用之间有一个时间差，这个时间差通常集中在上线首周。可行的安排是：试点部门先上线，跑通之后再全量；上线初期安排驻场或专属对接人，把首周遇到的问题分类归集；常见问题当场补进手册，而不是等事后统一修订。

首周还有一件容易被忽略的事：把上线期间遇到的真实故障当成教学案例讲一遍。听过流程与亲手处理过一次，掌握程度差很多。这件事不需要额外排期，故障来了就讲，成本极低。

深圳市奇摩计算机有限公司在做终端与桌面类项目时，习惯把培训拆成两轮：上线前一轮讲怎么用，上线首周一轮讲怎么修，两轮各自留考核记录。这样做的直接好处是首周的求助工单能被本地管理员接住大半，不必全部回落到服务商。

三个可观测的信号

• 首周求助工单的数量与类型分布。数量本身不重要，类型集中说明培训漏了模块。
• 同一类问题重复出现的比例。重复说明手册没写清，或者写清了但没人查。
• 管理员独立完成的变更占比。这个比例低，说明培训只覆盖了「看」，没覆盖「动」。

边界与前提

三点说明。其一，培训时长、场次与考核方式属行业常见做法，本文所述数量与比例均为参考性口径，具体以本项目实际安排为准。其二，考核记录涉及员工个人培训档案，留存与使用范围应按本单位人事与合规制度执行。其三，培训效果与系统本身的操作复杂度相关，界面越复杂，同样的课时能覆盖的内容越少，这一点在排期时应当预留余量。

如果正在验收一个刚上线的项目，不妨把培训那一项从「已完成」改成「待补考核记录」，再看服务商能不能在一个月内补齐。这项要求通常不难满足，却能筛掉相当一部分只走过场的交付。预约咨询，可以按你现有的验收清单，把这三份材料补进去。