手机版|
二维码|
下面介绍的就是一种经过信息技术（IT）产业实践验证的、能更有效地使用ADDIE的方法来改进学习与绩效的模式——“ADDIE+”。
对ADDIE的改进
对于学习和绩效专业人员来说，ADDIE (分析/设计/开发/实施/评估）几乎无人不晓。作为教学系统设计的首选方法，它已被沿用多年，跨越了多种专业领域，包括设计学习项目、实施培训、人力绩效改进（HPI）以及评测与评估。
除了传统的课堂教学外，学习与绩效改进的方式还有很多，比如从教练指导、工作指南，到大规模的综合性学习项目，以及集在线电脑学习、虚拟课堂学习和传统的实地教学为一体的模式等。然而，ADDIE并不能满足所有的课程设计需求。实际上，ADDIE仅仅为我们提供了一个行之有效的体系和架构，而在实际操作上，我们会遇到许多它所不能涵盖的需求。其中，我们从IT产业中就能借鉴到不少可以有效改进学习和绩效项目的方法，并将之作为对ADDIE的发展和补充。
HPI的发展和软件开发几乎是平行的。而它和传统的ADDIE之间却没有什么特别的关联，也没有太多的相似之处（见图表1）。
传统的ADDIE是一个带有普遍性的五步模型。然而，在教学设计的实际操作上，它没有作具体的区分，比如小型的设计项目，一次小规模的团队建设活动，或者是给销售组织设计和实施的、基于LMS（学习管理体系）的、可供上千人多年使用的综合学习项目。尽管我们现在可以通过做出样品，较快地从评估结果中得到反馈（这已是一个不小的跃进），但是， ADDIE模型中没有包括可调控的管理绩效改进项目的部分，这是它的一个关键缺失。
在IT业，我们从实践中总结了五点做法，从而将ADDIE改进为ADDIE+，包括一套指导原则、一个团队模型、对传统ADDIE的改进、一系列风险管理方法以及控制文件。
一套指导原则
“指导原则”是指通过一定的宣传说明，让人们看到其中潜在的愿景，以决定是否值得在需要的时候做出取舍。
举例来说，对学习解决方案项目的一个指导原则是：每一个ADDIE+项目都必须有一个所有团队成员都认可的愿景声明，这个声明应能反映出解决方案的理想状态。它适合于任何规模的项目。
团队模型
在需要由团队完成的项目中，我们时常因为团队成员分工不明确，或者与项目外的利益相关人的沟通不到位，而使项目处于被动。我们建议的“团队模型”要求：在立项时，就需清楚表明与项目有关的所有人的关键职能及其角色和责任。其中，不仅包括直接参与人员，还应包括在HPI 活动实施中有可能受到影响的利益相关人。
这个团队模型不仅明确职责，还确立了团队成员之间全部的沟通渠道。它表明，除了RASCI 之外，每一位成员或利益相关人还应该知晓如何相互配合。（RASCI即标准的项目管理方式，它将项目利益相关人如何处理项目过程中产生的各种情况和结果制成图表）
下面，针对团队模型中的六个主要职能，分别做具体介绍。有时候，我们也将之称为“样板组”（见图表2）。
项目管理职能
它主要负责资源配置、日程管理、特殊情况处理和风险管理。其最终目标是排除各种困难，按时交付解决方案。负责项目管理的人员要和客户或终端用户保持沟通，还需和组织内部负责其他学习项目的利益相关代表保持沟通，因为对于组织而言，所有的学习项目都是息息相关的，任何一个项目都有可能涉及到其他项目。
业务分析职能
业务分析的目的是确定解决方案的需求。这部分人要向最终用户了解他们的需要，因为他们要为解决方案付账，所以会时时关心着切身利益。业务分析人员也还要了解参加项目或最终接收项目的人的需求。一个好的学习解决方案应能最大限度地了解所有相关人的需求，才能得到最有效的接纳和应用。
用户体验职能
用户体验的目的是，根据最终用户的背景描述以及使用状况向他们进行宣传，让他们相信无论对于参加者还是接收者，当前所确定的解决方案都是行之有效的。除了和这部分人保持沟通外，用户体验组的人还要和组织内部负责学习管理的团队保持沟通，让他们了解这个项目已经做了市场宣传，定妥了时间表，并在符合现行标准和流程的情况下加以实施。
生产管理职能
生产管理负责将学习解决方案的各个部分加以整合，形成可供审查和测试的多种版本。这个职能最典型的作用是负责与组织的学习管理团队和IT的运营部门进行协调，及时解决运行时可能产生的系统或技术环节的问题。
测试职能
测试的主要作用是，确认该解决方案形成符合公司规格要求的文件，能够清楚说明其职能、使用和与其它系统的协调情况。测试组的人应和组织的运行部门人员共同工作。与传统ADDIE模式不同的是，测试功能在ADDIE+模式的所有阶段都十分活跃，这样，可以早在实施之前就定好了测试计划和内容。
开发职能
与以上职能不同，开发职能往往独立于组织的利益相关人（甚至核心团队的测试人员）之外。开发组主要负责根据设计或特殊要求开发设计方案的各个部分。他们更多的是与核心团队的客户体验、生产管理和项目管理打交道。
ADDIE+的模式并不要求所有的学习和绩效管理项目都要配备六个甚至七个职能的人员。在小型项目中，一个人可以担负起所有这些角色，只要其所代表的职能彼此间不冲突。不过，最需要强调的是，要将开发和测试职能分开。开发人员应对他们负责的部分作测试，而测试组的人则要将开发组整合起来的项目“打散”，以便向开发组的人证实解决方案的结果。
修正传统ADDIE过程周期
对传统ADDIE过程周期的修正包括：向核心团队和关键的利益相关人定期发布内部通知，以及在项目的完成阶段留出一个完整的有明确进度表的定型过程。
发布内部通知能够保证项目顺利并按时进行，还能让与项目有关的人看到项目的进展，发表意见，或对可能出现的问题提出意见。当各个方面的因素都考虑周全了，项目的稳定性也会随之提升。这样，开发人员就可以将重点只放在解决可能出现的一些问题上，为实施作好铺垫。
风险管理必要性
风险管理可以跟踪可能会危及到项目成功的潜在问题，其作用非同小可。风险及其大小可能以各种形式出现，例如最终用户不合理的期望、组织变化、突然的预算消减、使用新技术，或是团队遇到了不熟悉的项目。
风险管理可以帮助人们看到或规避潜在的问题，并在预见无法避免的风险结果时，制定可行的应对计划。虽然这种情况大多适合大型的项目，但小型项目也可以预先考虑到风险因素。风险管理在ADDIE+模型中自始至终都是不可忽视的部分。
版本控制
对学习项目的原始版本进行控制，可以避免由于团队成员的变换导致工作的混乱和重复性，令我们确定并着眼于必要的工作，然后加以实施。它可以从最简单的统一文件的所有名称开始，统一各个组成部分的格式、标题、日期，还要有最后一个修改文件的人的签名（比如“使用手册_04_12_2012_RMS”）。
理想状态是建立一个保存所有文件的中心，锁定每个人使用的情况（取出）直到完成（放回），这样可以恢复到文件最基本的版本上（复原）。
有一些学习控制系统（LCMS），像微软的SharePoint2010产品和某些较少使用的免费的云计算服务都带有这样的功能，比如Google Docs和微软的SkyDrive。版本控制不要等到设计阶段快要结束时才做，因为那时文件就要开始大量、迅速地涌入了。
除了上述ADDIE+的五个主要组成部分，负责学习和绩效的专业人员还可以从最新的软件开发环境和诸如内容储存库、可反复使用的内容部件储备库以及标准的可互动的系统中得到启发。例如对于那些谁都可能遇到的情形（见图表3），ADDIE+可以帮助你避免再次发生。
