前一篇寫了與MIS/IT合作的一些小技巧與經驗分享,這一篇將分享系統需求相關的流程與內容喔~
通常在使用系統上有新需求時,就會需要向MIS提出,大略來說會有以下步驟:
(1) 提出需求spec:此階段HR需撰寫系統開發或修改需求的詳細細節,撰寫的規格格式則視公司的文件撰寫方式,以我的經驗來說,我們會列出修改前(As is)系統使用的現況,以及修改後(To be)系統預定的運作方式。這個部分寫得愈詳細、考量到愈多狀況愈好,可以在事前預先知道系統使用的情境或會遇到的狀況,讓MIS能全面的考量各種狀況來撰寫程式邏輯,做好相關卡控,對於後續的流程也會更行順利。
(2) 系統開發:此部分為MIS收到需求spec後,將需求排入開發時程進行開發。開發過程中常遇到的狀況是:MIS會針對細節或不清楚的部分與HR溝通,在彼此的討論中能發掘更多的狀況加以考量,討論後須將細節與結論重新寫進spec中更新並回寄給MIS留存,以使spec更加完善。另個會遇到的狀況是,有另外的緊急需求插單或是多個單位共同使用MIS的資源,此時就必須定期檢視系統的開發時程、訂定MIS開發與HR測試的交期,必要時也需要討論開發項目的優先順序,例如:哪些項目較緊急?緊急者須先插單開發 (例如與法令相關的就會超緊急);或是哪些項目所需的工作人天數較短?若為較短的項目通常會插在兩個大項目中間、或是與某個大項目平行開發,以免影響效率。
(3) MIS交測與HR測試:MIS開發完成後,便會通知HR於系統的"測試區"進行測試,以了解修改後的系統運作邏輯是否如預期。此時HR需先針對系統使用上會遇到的各式狀況來撰寫測試劇本(測試腳本),包含公司的各種身分別、項目類型等,視不同function有不同的測試內容。除了被測者的基本資料外,測試欄位會壓上測試日期、測試人員、測試細節條件、測試結果、測視畫面等。此步驟能考量到各種狀況,愈能知道是否有邏輯錯誤而能即時修正,則日後系統上線後遇到的問題也會較少。
(4) 測試報告回饋:如上所說,將測試腳本列完並實際完成測試後,將測試報告回饋給MIS以及給主管審閱,若測試有遇到NG狀況,則請MIS依此找出問題進行修改,並會重複上述的第(3)步驟;若測試結果皆OK如預期,則測試報告檔案則給MIS同時留存,並於信件中敲定系統正式過版上線的時程。
(5) 正式過版上線:通常除非超緊急需求,否則測試完成後不會馬上將程式過版到系統正式區,因為還會有一些考量,比如MIS需做上線的前置作業、避開某些後台拋資料的排程時段、避開系統較多使用者使用的時間、避開某些忙碌的時程(比如以C&B來說就是避開月底的結薪時程,以免新功能上線萬一有問題的話會影響當月結薪作業而又沒有多餘心力處理)。此部分需彼此做好溝通,如有緊急需求,也應於測試完成前事先口頭告知希望過版的時間,做好溝通協調,能讓彼此合作更順利。
(6) 後續追蹤與維護:系統上線後,需於一定期間內較頻繁的檢視系統使用的狀況與相關數據,看是否有異常或特殊狀況,檢視是否有先前沒考量到、沒測試到的狀況導致正式上線使用時出現的問題,即時的進行修正與調整。待一段時間系統穩定後,即可讓其一般運作與定期檢視就好。
上述的幾個步驟看似簡單例行,但中間還是有需多細節須注意,細節可參考上一篇文章"如何與公司內的MIS/IT部門合作良好的小技巧 (上)",
但其實不外乎就是溝通協調、熟悉系統與自己提出的需求、謹慎細心等,另外就是時程的管控!因與MIS是跨部門合作,他們不見得會把你的需求擺第一,此外我們的需求可能同時有多個項目在go、又各有分短、中、長期的需求,故各需求間的優先順序、資源運用等就有賴PM的協調與控管囉!