EBT训练正在变得时髦,有些人开始宣称自己是EBT教员了,伴随着目光的离散。可是EBT到底是什么呢?和以前的训练到底有什么区别?离散的目光意味着什么?为什么提及哈希和JSON?让我们在这里仔细挖一挖。
EBT,即循证训练,医疗系统早就有循证医学,并不是什么新事物。可是循证训练到底是什么呢?如果精准翻译的话,Evidence-based Training应该是“实事求是的训练”,意思是不要搞那些想象中的、现实世界不存在或这辈子很难出现的科目来难为人,转而针对实际中存在的问题、带有普遍性的问题进行训练,从而回归训练的本意,提升飞行质量。
简单讲,就是EBT以后,你不会再碰到诸如单发叠加大侧风,还碰巧旅客心梗这类科目,而是感受到更加贴近现实的培训。
既然这么简单,为什么EBT看上去这么高大上而又神秘莫测?
首先是人的问题
人的问题解决了,EBT也就建立了。
专家问题:每当看上去很新的概念出来后,就会涌现一批专家,用一堆新词、缩写词来一顿狂轰滥炸,把大伙儿搞晕,乱而后治,这是专家们的责任和义务。
解决办法:勒令专家说人话,严禁反复口吐生僻的缩写词。
缩写 | 实际含义 |
CD-Course Developer | 课程开发人员 |
TI-Theory Instructor | 理论教员 |
SC-Simulator Coach | 模拟机教员 |
LSC-Leading Simulator Coach | 资深模拟机教员 |
II-Implement Instructor | 飞行教员 |
IE-Implement Examiner | 检查员 |
ADDIE-Analyze-Design-Develop-Implement-Evaluate | 演进过程-分析、设计、开发、执行、评估 |
KSA-Knowledge,Skills and Attitudes | 知识,技能和态度 |
CRM-Crew Resource Management | 机组资源管理 |
TEM-Threat and Error Management | 威胁和差错管理 |
SBT-Scenario-based training | 基于场景的训练 |
课程开发人员问题:传统上造成训练科目生搬硬套、拉郎乱配的情况,一种可能是课程设计部门人手不足,把开发工作交给了精通word、excel的工作人员,他们并不具备飞行经验;或者是层层转包,最后干活儿的是个临时来帮忙的刚毕业副驾驶。他们只会搬手册,不会搬实际运行情况。
解决办法:EBT课程开发组需要飞行教员、IT工程师、其他技术人员组成,但要以实际参加飞行的教员为主,建立课程开发团队并保证深度参与。同时,重视负责案例收集的小组(也称为数据收集),这个小组需要飞行教员深度参与,而不是IT工程师(一说到数据,就以为是QAR,就以为是IT的事儿)。
教员问题:教员传统上都按科目教学,教会一课是一课,喜欢打听考试科目,随即陷入应试教育的泥潭。很多教员只会简单打分,还不知道或尚不理解胜任力评估方法。
解决办法:EBT则要让教员摒弃应试教育,回归快乐教育,增强互动性;开展胜任力评估培训,让教员理解新的评估体系的好处。
看到这里,很多人会有疑问,胜任力评估又是什么鬼?下面我们说第二个问题。
CBTA是什么?
EBT不复杂,但是它是基于CBTA(基于胜任力的培训和评估)的,我们之前并没有普及CBTA,所以这是两步并作一步走,稍微有点吃力。
CBTA最开始称为CBT(Competency-Based Training),基于能力的培训的缩写,由于和之前的基于计算机的培训缩写重样,所以改成了CBTA(Competency-Based Training and Assessment),中文也改成了基于胜任力的培训和评估。
基于胜任力是什么意思?
还记得实践考试工作单、熟练检查工作单吧?前面两页是科目,最后有一个综合评估页面,检查员要对整场训练做出总结后填写这部分内容,然后才能签字做结论。
这部分现在不叫“综合评估”了,改称“胜任力评估”,内容还是那些内容,只是被整合成九条,并设定了新的、更实用的打分规则。这是CBTA的基本盘。
这里打个比方,如果液压故障没飞好,可能是人工飞行能力欠佳,也可能是知识基础薄弱;如果单发后关错发动机,可能是程序执行出了问题,也可能是工作量管理混乱。总之,每一个不达标的科目,都涉及到一个或多个胜任力的问题,从胜任力角度去训练,比反复训练单一科目,更符合安全运行的需要。
九项胜任力中,知识基础就是K-Knowledge,人工飞行+自动飞行+程序执行对应S-Skills,其余五项对应A-Attitudes,合起来就是KSA。其中A的训练就是之前的CRM训练。九项胜任力合到一起,干的就是TEM。所以,CBTA实际上让KSA、TEM、CRM走进了历史。
每项胜任力处于什么状态,可以基于新的打分规则来判断,就像战士打靶:
完美战士,值得赞扬、鼓励(少数)
这个战士够标准,没毛病(大多数)
可以参战,还有提升空间(较少数)
还不能上战场,但还有希望(很少)
纯属浪费子弹,考虑安排到炊事班(罕见)
基于对各训练科目的九项胜任力打分,确实有利于对飞行员训练水平的追踪,可以较为清晰的判断一个飞行员当前的水平,以便提供更有针对性的教学。
理想很丰满,现实很骨感......,改革带来了令人头疼的新问题:CBTA的评分方式令教员和检查员的评分表格填写量巨大,如下图,每个科目都需要按九项能力逐一评分,虽然个别能力可以忽略,但总量依然庞大。
基于纸张的胜任力评估,导致教员、检查员们深陷胜任力矩阵的汪洋大海,目光离散、手疲劳、指纹磨损,几番操作后还能否认真教学令人怀疑。
于是有人提出,能否和以前一样,把最后的表格稍微改一下,九项能力各打个总分就行?这样的缺点是,缺陷对应的具体科目不清楚,时间长了这个数据失去价值。
如果按阶段呢?起飞阶段打一遍,巡航阶段打一遍?这样的话,上面两种方式的缺陷兼备,得不偿失。
上面的方案都是基于蔡伦以降根深蒂固的纸张思维,电子时代应该采用电子思维,一如乔布斯所为。
这也是为什么PLM路线图第一阶段要实现电子化。电子化绝不是在PAD上干纸张的活儿。
哈希来了
电子化很适合规模化管理、异地管理,但也有其固有缺陷。如果是纸张记录,一旦放入保险柜存放,篡改的可能性就很低;电子记录容易访问、方便分发,也就容易被攻击篡改,无论是分发副本、数据库还是后台log。
解决办法是电子签名或者区块链技术,其原理是将数字档案压缩加密为一个字串,称为哈希(hash),然后将哈希交给第三方存证,这叫电子签名;交给多方存证,这叫区块链;古人称一言九鼎。具体可看:
哈希是基础,解决了电子系统的可靠性,接下来,解决矩阵的汪洋大海,需要另一个大神来加持:JSON。
JSON
JSON: 全称JavaScript Object Notation,即JS对象简谱 , 是一种轻量级的数据交换格式。
它不需要绘制大量表格,不需要填写大量重复而不重要的内容,它可以针对任何层级,既可以针对科目,也可以针对阶段,还可以针对整场训练。
{
"日期":"2023-6-9",
"机型":"A-320",
"胜任力":["知识","人工","自动","程序",{
"阶段": "巡航",
"科目": "单发",
"问题": "关错发动机",
"得分": "2"
}
"工作量","情景意识","决策",
"领导力","沟通"],
"加课":{
"场次":"2场",
"教员":"李四"
}
}
上面是一个完整的JSON实例。不过这是给IT工程师看的,飞行员看到的应该是一个漂亮的标签。
例如,某一场训练全是蹲起落,就可以针对整场训练填写主要问题;
某一场训练中,紧急下降科目中某些问题比较突出,可以针对这个科目填写主要问题;
如果是一场训练中,多个进场组织都很忙乱,也可以针对阶段填写工作量管理的问题。
这样一来,教员可以有针对性的填写任意科目、阶段或整场发现的问题,并做出几项能力方面的评估,节约大量时间,把主要精力回归到教学中。
简单来讲,使用JSON就像使用一个标签,一旦发现有5分、3分、2分、1分的情况,便将这个分数和说明、处置情况写入标签,插入相应科目、阶段或者整场训练,所有的4分都不用理会。
如果习惯看矩阵,IT工程师可以轻松将JSON还原为矩阵;
如果需要分析,也可以把历史JSON整合,实现表格化或可视化都很方便。
JSON还具备便于存储,易于跨平台、跨系统,传送方便等优势。
试想一下,当一个人放机长时,考官面对他历史上100场训练,每场200个数据组成的矩阵,或者基于327个JSON的可视化图形,会选择哪一个?
EBT并不复杂,CBTA也很好理解,哈希和JSON只是手段,用于扫除新道路上的障碍,祝愿大家的训练越来越实事求是。
Keep it Simple,Stupid
深入了解民航,请进入下列链接: