2012-08-29

從IT產業重新定位ADDIE

當提及系統化教學設計模式時,就不能不提ADDIE,也就是所謂的分析(Analysis)、設計(Design)、發展(Development)、建置(Implementation)、評鑑(Evaluation)這五大階段,其模式之所以會受到廣泛歡迎的原因,不外乎提供系統化的步驟及客觀的評量方式,讓教學者在設計課程時能有所適從,而不致於茫無頭緒。因此,ADDIE不僅是多年來系統化教學設計的首選,也是ASTD職能模式的一部分,並且跨足多個專業領域,包括設計學習、培訓提供、人力績效改善(HPI)、衡量和評鑑等。

然而,隨著資訊科技的蓬勃發展,職能學習與評鑑已不再限定於傳統的教室授課形式,亦將場所帶到線上虛擬教室,採用數位學習或是混合式學習的方式,來開設課程、監控並評鑑學習者的學習成效。因此,ADDIE仍適合套用到所有的方案嗎?是否有更快速、更有效的方式呢?

Shor認為可透過IT產業的軟體開發實踐法,擴展ADDIE系統化教學設計模式,並將重新擴展的模式命名為ADDIE+。意指將所有項目視為軟體項目的方法,套用IT產業所使用的指導原則、團隊模型、傳統ADDIE流程的修正、風險管理原則,以及版本控制等五大方式,將ADDIE轉化為ADDIE+,以提昇學習與績效改善項目。

一、指導原則
指導原則有時會處在「宣言」的保護傘之下,它不僅提供了基本的觀念,且定義出會影響權衡決策的價值。舉例來說,學習解決方案項目的指導原則會是:「每個ADDIE +項目都應該有一個所有團隊成員都同意的願景聲明,可準確地取得解決方案所希望達到的未來狀態。」指導原則與所有規模的項目皆具關聯性。

二、團隊模型
團隊模型應明確地界定出核心職能以及參與各方的角色和責任。其中包括了可能會受到HPI方案實施所影響的個人,無論是直接參與或作為延伸的利益相關者。

這種模型不僅決定了團隊成員所屬的責任,也限定了成員間的溝通管道。它應當顯示出,當超過RASCI(負責者、批准者、支持者、諮詢者與知情者)的範圍時,每個團隊成員或利益相關者該如何與他人進行互動。(RASCI是一種標準的項目管理方法,用以映射利益相關者角色對項目過程中所創造出之各種加工品和輸出品的參與程度)
這裡所提的核心團隊模型具有六大職能,有時也稱為宣傳組(見下圖)。

(一)項目管理:負責管理資源、時間表、規範和風險,其最終目標為提供限制範圍內的解決方案。此項目管理職能將協調與聯繫使用者、客戶、以及組織中須用同個解決方案之其他學習計畫的利益相關者代表。

(二)商業分析(在IT產業中通常稱為產品管理):旨在確定解決方案的需求。這一組必須知道客戶端(最終須支付解決方案費用以及獲取利益者)和即將參與或接受其學習計畫的使用者兩方之需求。

(三)使用者經驗:主張以使用者檔案和背景資料為基礎,幫助使用者確保該解決方案適合其參與者或接受者。除了與使用方合作之外,使用者經驗團隊也會與組織中的學習管理團隊合作,以確保此解決方案的銷售、時間表與交付皆和現有的標準和程序保持一致。

(四)生產管理(在IT產業通常稱為發布管理):必須協調將學習解決方案的許多組成部分合併為許多不同的版本,以供審查和測試。此職能基本上即是將其小組之努力,與組織中的學習管理團隊以及IT操作(如學習管理系統)整合在一起。

(五)測試:在於證明該解決方案能夠(或不能夠)符合文件所紀錄的需求,如功能性、易用性、以及與其他系統的整合性。測試主要與組織中的操作人員合作。與傳統的ADDIE流程模型相反,在ADDIE +的各個階段中,測試都非常地活躍,會在正式發展前建立各種測試計劃和案例。

(六)開發:是一個有一點特殊的情況,因為此職能孤立於組織的利益相關者和核心團隊的測試組之外。開發負責交付以設計或規範為基礎的解決方案之組件,並且會與核心團隊的使用者經驗、生產管理、項目管理等職能之間密切地合作。

然而,並非所有的學習與績效項目皆需要六種職能,或甚至連六個人也不用。在小型項目中,只要其代表的職能不會互相衝突,一個人就可能同時扮演多個角色。在這兒,最重要的一點也許是獨立的開發與測試職能。開發者應做好自己的基本(「單位」)測試;但測試者應嘗試「打破」開發者所組成的解決方案,思考解決的成果。

三、傳統ADDIE流程週期的修正
在此,包括了為核心團隊和關鍵利益相關者所定期提供的解決方案內部版本,以及當開發完成時所明確排程之穩定階段。內部版本能夠讓項目持續進行並上軌道,使擴展團隊的其他人能看到進展的情況,以提出意見或標記問題所在。當解決方案的功能完備之後,即開始趨於穩定,開發職能組便能針對解決方案的問題進行修復,準備正式實施。

四、風險管理原則
風險管理原則能夠追蹤可能會影響項目成功與否的潛在問題。風險有各種不同的規模與型態:不合理的客戶期望、組織的變化、突如其來的預算限制、新技術的使用、或是團隊資源正著手進行一個不熟悉的項目。

風險管理原則有助於確認和減輕潛在的問題,並在無法避免風險的情況下建立應急預案。儘管此原則對大型項目來說最為適用,但即使是最小的風險,它也有助於思考並加以應對。在ADDIE+中,風險管理是一個連續進行的程序。

五、版本控制
應針對學習解決方案的原始組件實施版本控制,以避免因團隊無法識別和組織生產與交付解決方案所需的正確文件,而造成各種混亂和必須重做的情況。這點可以先從簡單的地方做起,譬如檔案文件的標準命名慣例,應當包含組件類型、標題、日期、以及可辨識的最終修改者的縮寫(例如:「Handout_Scenario1_04_12 2012_RMS」)。

更好的方法,則是設定一個集中的檔案庫,裡面的文件可供單一個人使用時鎖定(登入),完成後解鎖(退出),並且能夠恢復至前一個版本(回溯)。這種職能由一些學習教材管理系統(LCMS)所提供,如微軟(Microsoft)的SharePoint 2010,或是較小範圍的免費雲端計算服務產品,如Google的Docs和微軟的SkyDrive。版本控制應在設計階段完成前就著手進行,因此階段之後的文件數量會開始迅速地增加。

綜述之,除了這五個ADDIE方法的額外核心組件,新軟體開發環境和過程的特有優勢,也可供職場學習和績效的專業人士加以採用,如內容庫、可重複使用的組件庫、以及標準的系統介面。由於現今學習與績效之解決方案的創建,皆依賴於軟體工具和成果傳遞機制,故讓人難以忽略它與IT產業有太多相似之處,尤其是在軟體開發方面。倘若能套用IT產業的軟體開發或是系統分析等概念,實則有助於大大提昇績效成果。

資料來源:ADDIE+: Adopting Proven Practices From the IT Industry
http://www.astd.org/Publications/Magazines/TD/TD-Archive/2012/05/ADDIE-Plus-Adopting-Proven-Practices-from-the-IT-Industry

資料整理:工研院產業學院副研究員 鄭伃珊



沒有留言:

張貼留言