系統上線之使用者教育訓練_旁觀心得



第一次參與了實務上，一個系統上線的前置階段（使用者教育訓練），第一線體會到使用者的真實反應，覺得有趣，紀錄一下自己的心得。


1.     使用者覺得系統太複雜
系統設計上，有時候要思考的是流程上的改變，而不是純粹把原本的流程做成電子化，這樣不僅沒有增加效率，使用者還需要多學一套新系統的操作，難怪使用者反彈。
（但這部分有時候是各個子單位的流程本來就不一致，所以系統沒辦法提供這麼大的彈性，因此就有部分人會覺得無法支持他們的流程。）

2.     系統上線太趕
這要跟甲方討論，牽扯到的使用者太多的話，事前訓練或是推廣可能要提早或是增加場次，至少讓使用者早點有心理準備，這樣反彈的聲音會比較小。但另一方面不管怎樣都還是會有使用者反彈，就要看上層的執行力了。

3.     教育訓練的方式
以實機操作為主？究竟是要先操作帶一遍流程，還是說明後再demo，是個trade off，因為假設聽一兩小時的說明，聽到後來應該都恍神(或睡著)了。
我覺得可以根據使用案例，一邊進行實際操作流程，一邊講解，比靜態的ppt畫面截圖有效果。
至於提供影片教學，還是靜態的操作文件教學，一定都會有人反彈；提供影片有人說太長，只需要看某一個功能會找不到；提供靜態操作會說這樣看不懂，有影片step by step教學一看就懂，這完全取決於預算跟人力，資源不足的話還是只能擇一吧。

4.     使用者不想學習新的系統
這部分真的就要看導入的高層有沒有強力手段去推廣，或是即使造成反彈也有辦法解決。E.g.舊系統會下線，只剩下新系統，使用者不用也不行…
另一方面，要反省思考是不是系統真的設計不佳，導致使用者操作困難，所以才不想使用。（我覺得設計的最高境界就是：「第一次操作，不需要看說明就會用。」
實務上，我們買了家電，也不會去看使用說明書，這東西是當我們不會用的時候，才去查！而不是要完整看完才會用，那東西絕對沒人會買。）

5.     新舊並行？一次導入？分階段導入？

假設沒有強制性的話，通常大家不會想換系統啦（畢竟要花學習成本，這個是額外的工作量），簡單記錄一下可能的情境。
(a) 如果是新舊並行，可能新系統根本沒什麼人用，等到舊系統要下線的時候，才是使用者真正轉換新系統的時機XD
(b) 如果階段性導入，反彈比較小，但成本比較高，花的時間長；或是系統先天上的限制，一定要全部統一使用新系統，否則新的資料無法與舊系統介接。
(c) 一次導入，陣痛期只有一次，但爆發出來的bug或是使用者反應會超多，設計廠商不一定能快速消化掉。




總結而言，很多情境都是trade off，不管是在人力配置上還是系統設計上；有多少人力影響可以做多少事、時程上可以做多快，有多少錢則影響有多少人力可以用。

嗯..

有錢(資源)，什麼都好辦！哈哈




系統設計上，感覺也是很多trade off，如果提供太多固定的功能有時候反而怕overdisign，這就之後再思考了XD

留言

張貼留言

這個網誌中的熱門文章

API、Method和Library是什麼東西和關係？

圖片
這三者我一直搞不清楚，有時候API跟Method好像差不多，有時候覺得API概念不就跟Library一樣嗎？ 後來發現這三者差別，需要視它們是對於一個"應用程式"而言是在什麼位置。是應用程式本身，還是不相關的應用程式，還是想要與應用程式互動的外部應用程式。 先來個例子： 今天有一個甲應用程式提供了API ReturnNumber(int a) 而甲應用程式裡面的處理是 int ReturnNumber(int a){ return round(random(a)); }; 接著我們一一解釋它們各是甚麼。 round()、random()：是由內建library提供的兩個method ReturnNumber()：是一個自己寫的Method，但因為我們提供它給外部使用，所以也是個API。 假設乙應用程式用了ReturnNumber()這個API，則只能傳進一個參數a，實際上他不知道這個API裡面寫了什麼，只能透過甲提供的文件說明來知道用途。 這個例子可以看到三者的實例，接著再來進一步說明。 ----------------------------------------------------------------------------------------------- API、Method和Library的關係 【Library】 函式庫，指將一群已經寫好的Method(Function)包成一個Library，當我們import這個Library後就能使用其包含的Method。(此處只是個程式語言的稱法不同，Method指Java、Function指C) 【API( A pplication P rogramming I nterface)】 應用程式介面，指提供給 外部程式 存取或是已經寫好的功能，事實上可以把它當作一群Method的集合，外部程式只能用這些Method。 【Method】 在Java稱為Method，類似C的Function，但不完全相同，這又是另一段故事了。 (在物件導向中的Method是綁定Class，所以要用Method一定要先實體化一個Object。ex. student.gohom
閱讀完整內容

《人月神話》簡易心得

這本真的是很有收穫的書籍，對於在軟體產業工作(尤其是by專案)，看完有著很大的共鳴跟反思。（還沒進產業時曾看過一遍，實際工作後再看一遍又有更深的體會。） 重點是這是三十年前寫的書，而隨著技術與工具的進步，軟體專案發展到現在仍然有書中所說的種種困境與難題，看完會覺得作者真的對軟體專案看得很透徹。 簡短心得就把每一章濃縮成我覺得最重要的「一兩句話」，避免太發散。 但書裡面的內容絕對不只、也無法用一句話精準的概括，只是這樣比較方便記憶而已。
閱讀完整內容

新增欄位，該用alter還是create and drop

最近遇到一個需求是需要DB新增欄位 思考後發現有兩種做法 1. Alter Table ... ADD Column 2. create&drop重新建一個新的table：複製舊的資料表格式，並加入新的欄位，再將舊資料表的資料SELECT INTO至新的資料表，最後重新命名為原本的資料表名稱。 作法1的速度非常快，但是在SQL Server中，ALTER ADD的欄位是無法指定排序的，因此新加入的欄位一定會排在最後，我是認為在觀看上有點不便與醜陋。 由於兩種做法都可行，因此問了資深前輩，trade off的考量點應該要有哪些，得到一些原本沒想到的觀點，順便整理記錄一下。 1. 系統是否已經上線 已經上線的系統，如果採用方法2，風險會比較高，因為轉換資料的過程中會lock住資料，萬一資料量大的時候，需要的時間就很長，萬一有其他使用者需要使用，可能會導致連線逾時。 且轉換的過程中，萬一中途有些資料失敗了，會不知道斷在哪裡，造成資料的不一致；如果採用transcation，則會lock更多資料。 2. 造成的影響最小化 在擴充功能的時候，優先考量的一定是有沒有side effect，如果造成side effect會讓系統品質變得更難維護。而方法1跟2，基本上都不太會影響原本系統邏輯（如果當初寫在系統中的使用語法都有明確指定欄位，沒有使用select * from table的寫法），因此在變動所產生的影響最小化考量，1跟2是都可以採用的。 3. 資源耗用量 MS SQL server有提供的圖形化介面操作，可以移動欄位的順序，看起來非常的方便。但如果我們再進階一點去使用「產生指令碼」的功能，會發現 系統做的事情底層還是select into綁上交易的作法 ，只是沒讓我們看到而已，因此資料量愈大（上千萬筆），採用方法2所耗用的資源就愈多。 最終還是選擇的方法1的做法，因為影響最小，且系統已經上線使用。
閱讀完整內容