數位教學設計師研修課程設計

【數位教學設計師研修課程設計】

☆適合對象

擬從事數位教學設計工作或欲瞭解規劃教育訓練課程、教學設計或教材設計之人員，並建議需有1年以上相關產業之工作經驗。

☆課程設計理念

杜威(Dewey)曾說：「哲學是教育的普遍原理；教育是哲學的實驗室。」本課程將以杜威(Dewey) 的知識論作為設準，知識應是實用、行動與富創造性的，而教學設計應為解決企業中之問題而不斷作精進，符合真實情境且必須是實用的。

據此，從事教學設計的從業人員應瞭解教與學的基本原理、教學策略設計方法、訓練評鑑…等各方面應具備的基礎知識，並具備跨領域思考與整合能力，能以期能在實踐過程反映、回觀，進而精進、止於至善。

如何搞定SME？

elearning是洋人的東西，解決方案自然要"思夷之長以制夷"。

底下三篇文章,乃傳授我們如何制服難稿的內容專家(subject matter exper,SME)！

Managing SMEs #1 - Understanding ISD & SME Tensions in eLearning & mLearning Instructional Design
http://rapidintake.com/elearning-mlearning-development/index.php/entry/managing-smes-1-understanding-isd-sme-tensions-in-elearning-mlearning-instructional-design

Managing SMEs #2 - Creating ISD & SME Collaboration in eLearning & mLearning with SME Content Development Plan
http://rapidintake.com/elearning-mlearning-development/index.php/entry/managing-smes-2-content-development-plan

Managing SMEs #3 - Tools and Tips for Gathering SME Content for eLearning & mLearning Development
http://rapidintake.com/elearning-mlearning-development/index.php/entry/managing-smes-3-tools-and-tips-for-gathering-sme-content-for-elearning-mlearning-development

---
2012.8.17

延伸閱讀：
65 Tips on Managing Projects and SMEs for eLearning
http://www.elearningguild.com/surveys/?sid=207

專案中的浪費系列（二） – 等待

專案中的浪費系列（二） – 等待

．現象：
1、等待核准：例如，等待老闆核准簽呈、等待客戶畫押需求、等待客戶批准需求核准變更。
2、等待確認：例如，等待客戶確認大綱、腳本，等待腳本、成品通過測試（QA）。
3、等待資源：例如，等待合約寄達、等待款項撥下、等待人力備齊。
4、等待某人有空：例如，等待其他部門協力合作，等待技術部門排除技術障礙、等待「隊友」幫忙一起解bug。
5、等待某項知識：例如，等待新人搞清楚專案狀況、等待專案成員技能上手熟悉、等待技術部門告訴你障礙如何排除。

．浪費：
1、停下手邊的工作，被迫去找尋答案：等待答案將造成原先工作中斷，若答案的找尋不是很順利，則會造成工作被迫在不同項目中切換，導致不良多工。

2、被迫找其他事來做：原有工作安排未如期進來，為避免造成人力閒置，被迫進到其他工作事項。這段轉換間的時間，將可能導致不良多工。

3、半成品/bug的產生。因搞不清狀況、技能不純熟導致的錯誤，將需要額外人力協助找答案、排除。

---
2012.8.11
摘自Teddy Chen〈減少不必要的浪費 - 延遲〉，《敏捷開發法的逆襲》，P183~186。因摘錄、改寫導致文意不同，文責概由本人負責。

專案中的浪費系列（一） – 不良多工

專案中的浪費系列（一） – 不良多工

．現象：一人一時兼顧1個以上的專案工作。

．浪費：
1、個人轉換工作之間耗費的時間。好比說，人的大腦不是機器，無法立即輸入指令即刻運作，需要花時間摸索、熟悉，這段啟動後回到正常工作狀況的時間，即是浪費。

2、交接工作上造成的浪費。例如：同一隻檔案先後由甲、乙兩人接手負責，甲需花時間說明，乙需要花時間摸索、熟悉，這段時間即是浪費。

3、轉換工作環境造成的浪費。例如：同一隻檔案先後由甲、乙兩人接手負責，乙接手後因軟體版本、製作方式上不同，額外花去的時間。若因此產生bug，之後需再投入丙校正、檢驗 的時間，將產生重工！

4、組織層面上造成的浪費。例如：同一隻檔案先後由甲、乙兩人接手負責，而甲、乙分屬不同小組，各有1位PM、組長，前製作業上討論甲、乙兩人的人力調動上，將影響到4人的時間，並為額外增加溝通成本！

---
2012.8.8
解決方法總比問題多，且根據不同組織、專案環境，方法並非放諸四海皆準，因此我只描述現象，不討論解法。