我個人完全不會寫程式，這次很幸運因為專案有機會跟HRIS和IT團隊一起合作，有機會經歷從使用者需求到功能上線0-1的流程。
如果你也跟我一樣沒有任何IT背景，也需要跟IT團隊合作，這篇分享我在專案準備「前中後」的經驗給大家參考。

文／曾耀葳 Sophie Tseng

今年六月，我們終於順利在六月舉辦的高階會議中，使用與HRIS和IT團隊共同合作開發的新功能平台，演示全球人才發展的最新現況。

一來能讓公司重要人才的資料得以保存下來，也可讓各單位的高階主管和HR隨時檢閱、編輯資訊。

在會議結束的那一瞬間，我像洩了氣的皮球，氣力放盡，跟主管相望一眼，心裡想的是： 終於順利結束了。

團隊一開始對於能不能如期在6月上線非常擔心，原因是專案時程非常緊，使用對象橫跨15個單位以上的高階主管和HR，還需保證會議上系統操作順利無誤。

我個人完全不會寫程式，這次很幸運因為專案有機會跟HRIS和IT團隊一起合作，有機會經歷從使用者需求到功能上線0-1的流程。

如果你也跟我一樣沒有任何IT背景，也需要跟IT團隊合作，這篇分享我在專案準備「前中後」的經驗給大家參考。

「前期」準備：流程化、標準化、系統化

在預備上系統之前，這九個字是需求單位需牢記，最重要的是「內部是否已經有一套有共識且標準化的行政執行流程」，且每個執行步驟拆解的畫面都要明確，沒有後面都是空談。

「行政執行流程」確認後，接下來是轉換成「IT能看懂的系統語言」，我們使用的是SIPOC模型：

SIPOC模型是戴明大師提出來的組織系統模型，是一門企業中最常用於流程管理和改進的方法論。

字母各代表：Supplier 供應者；Input 輸入；Process 流程；Output 輸出；Client 客戶，跟電腦系統運行的邏輯非常相似。

對系統和IT來說，不管是什麼業務流程，基本原理不變：在「後台」的某處提供了Input，系統用預設的邏輯判定後，產出最後使用者在「前台」看到的Output。

當初前輩教我時，用了牛肉麵當比喻，Supplier供應商就是屠宰場和麵粉廠，他們提供了原料Input牛肉和麵粉，在經過廚房料理Process後，包含材料準備、麵條製作、湯頭熬煮、牛肉切片等，最後變成了消費者看到的牛肉麵，而Customer可能是進小七買即食牛肉麵的顧客，或是麵癱的老饕。

要跟IT開啟討論，需求方要先把執行流程轉換成SIPOC的流程圖，並明確讓IT知道流程中，哪些是希望用系統取代，哪些是線下作業。

釐清SIPOC流程圖後，HRIS才能開始設計所謂的User experience(UX)使用者經驗和User Interface(UI)使用者介面，這一段我很幸運能在資深的HRIS前輩旁觀摩學習。

過程最有趣的地方是去思考：「我們想藉由系統去改變什麼行為」，如何用介面引導使用者，改變他們以往習慣的方式，不只是單純把過去的介面複製貼上。

中間討論需不斷緊扣到「我們希望解決的問題是什麼？」

設計初版內容後，需要請使用者回饋新功能使用上還有哪些痛點，訪談後，HR有提出因為每半年就需更新資訊，希望有一個「全部複製」的功能，讓他們可直接編輯之前的內容，而這個需求也成為最終設計中核心功能之一。

討論過程中，前輩說了一句讓我至今印象深刻的話、她說：「未來UX和UI是不需要提供使用者說明書的」，想像未來當一個新使用者登入系統，介面設計會自動引導他完成需要的步驟，而不需要按照說明書一步一步操作，是多麽棒的體驗！

而在功能設計上，前輩也不斷提醒我們：「Less is more」，讓使用者多一點選擇未必是好，就算是一個excel上依字母排序Sort的功能，都需要再三斟酌，這是Must-Have，還是Nice-to-Have的功能。

而到這一段都需需求單位、HRIS、使用者間有充足的對焦，才能確保功能設計不會疊床架屋！

「中期」準備：下好離手，清楚定義每個IT需求規格書的欄位

前面準備結束後，終於進到可以跟IT PM開會的階段，目的是讓他們清楚了解：為什麼會有這個需求、使用流程和情境、系統前後台Input和Output的來源。

當IT PM能完整了解業端需求，他們會產出IT需求規格書，記錄大架構下的功能設計，當輸入一個指令時，系統如何針對「所有可能出現的狀況」反應。

舉例來說，我們針對某些職位設計了績效的條件，希望系統能自動協助對比：看這個人績效有沒有符合標準，顯現符合或不符合的記號。

而單在跟IT討論這個子功能的時候，就有100個我們平常不會思考到的問題：

如果這個人對比的職位還沒有績效必需的條件，希望系統怎麼呈現？績效資料要人工輸入，還是從其他系統串連？員工如果是併購公司的員工，系統抓不到工號怎麼辦？

如果在某一個時段，管理員更改了績效條件，系統是對比當下績效還是未更改前的條件？如果前期管理員就輸入了錯誤的績效格式，系統如何自動提醒卡控？

每個欄位都需要雙方有共識，中間就是不斷來回溝通，直到雙方都用信件畫押同意，這是最終的IT需求規格書，才會開始請工程師開發。

而這段過程非常考驗窗口的邏輯能力，因為每個按鍵的反應都需要下明確的指令，在大框架下，必須確認不同資料庫的資料呈現邏輯是正確且不牴觸的。

那段時間會議討論大概都以兩個小時為限，因為超過兩個小時，大家就會開始進入頭昏腦脹，胡言亂語的階段。

而因IT資源有限，所以IT需求規格書裡沒寫到的需求，後面除非有重大情況，不然需求方是不可隨意增加功能的。

因此需求方一定要對IT規格書的內容倒背如流，不然最後少了一個重要的功能，想加也欲哭無淚，IT需求規格書就是雙方訂定的合約，一切改變以合約內容為主。

而當工程師功能開發完，就會進入UAT(User Acceptance Test)用戶驗收測試的階段，需求方和HRIS需提供「驗收測試的說明範例」，讓使用者在測試環境下，去驗證哪裡有bug，確保規格書上功能都正常運作，最後才請IT正式上線系統。

剛跟IT團隊溝通的時候，我還抓不到跟他們溝通的訣竅，後來發現較有效的溝通方法是：

解釋為什麼我們想這樣設計，不要只是單拋需求，請他們執行，有好幾次他們建議改的功能和介面都超乎我們預期，直接解了我們一直困擾的問題；

用他們喜歡的系統語言，我希望有什麼樣的Input，會產出Output，而不是我要這個碰變成這樣；

多問IT能做到什麼效果，如果做不到理想的狀況，他們會怎麼建議

「後期」準備：Bug永遠抓不完，只有更好，沒有完美的系統。

UAT測試後，我原以為可稍微放鬆，但正式上線後，使用者的問題如潮水般湧來，後來慢慢調整心態，如果系統沒有人反應bug，通常就是太難用了，所以大家也懶得回饋，有回饋就代表還有可進步的地方！

系統上線後，我都在解兩個Bug，一個是系統的bug，另一個是人為的Bug：系統的Bug通常是因為系統串連的複雜性，會有介面顯示錯誤的狀況，這時候就需回去翻IT規格書和請IT後台查證；

而人為的Bug通常是使用者不熟悉新的操作，需看分享畫面，確認是哪一步出了問題。

這次經驗過後，我對從0-1系統開發的流程有了概念，想到曾在一本書看過，工程師忍受失敗的能力會比較高，因為他們每天寫程式都會收到無數個Error的提示，抵bug抵到懷疑人生。

而這次的合作經驗讓我深刻體會到：「工作生活中也有無數個Bug等著我們去解，小白學會跟IT團隊溝通，解Bug更快速有效！」

這篇文章 沒有學過程式的小白，如何跟 IT團隊合作，在半年讓人才管理新功能成功上線 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。