都會女子的異想世界

一定有人認為我在說廢話吧！

UML 中的 use case diagram中，為什麼要將 actor 畫進來？主要目的是什麼？

書本的標準答案是：Actor 是系統參與人員或是外部系統。這些 Actor 會去 trigger 系統（Object ），以達到一連串的系統動作。

拍拍手，答對了！

然後呢？UML 圖畫的很美，很有邏輯，結果，系統無法如期上線，時程一延再延，團隊將問題丟了出來，都是因為時程不夠、因為人力不足、因為 User 沒有將需求定義好、因為需求一再變更，所以害的系統無法如期完工…

這都是藉口！

很多時候，是開發團隊根本沒認清到，真正『使用者』的『需求』。需求沒定義好，不完全是客戶的責任，這專案經理及需求分析人員都完全沒有責任嗎？

你知道你的客戶是誰嗎？

圖中的使用者是誰？
他是什麼時候會去做扣款的作業？
他的工作地點在那裡？
他為什麼要做扣款的工作？
他要扣誰的款？
如何扣款？
需要什麼資料才能完成扣款？
完成扣款後呢？
什麼叫完成扣款了？
這位使用者如何知道己經成功或失敗？
若失敗要怎麼辦？若成功後，還有什麼後續作業嗎？
除了這位使用者外，還有人會參與這個扣款作業嗎？
若有，這個人如何幫忙？
扣款作業，會有什麼例外狀況嗎？這些例外狀況如何處理？

好了，這小小的一個作業，問題很多，這都是這個『使用者』的『需求』，請問，專案經理（或需求分析人員），有人搞清楚了嗎？若搞不清楚這個使用者的工作內容，如何去設計出他所要使用的系統呢？

為何要問這使用者是誰及工作環境？因為和使用者的操作習慣有關。

這部份，是很多需求人員及系統分析最容易忽略的地方，也是後來系統上來後，改來改去最多的地方。

KiKi 媽咪有個很好的經驗。

十多年前，KiKi 媽咪做一家 Pizza 店的店端系統，分成三大部份：接單、Make Line 及派送。KiKi 媽咪負責後兩項，當客服人員接單後，將訂單內容送至 Make Line，廚房人員依訂單內容做好Pizza 後，資料到第三關，印出發票及地址條，然後派送人員送貨。

看似簡單的流程，KiKi 媽咪因為沒有深入了解客戶的需求，導致系統全部重新開發，且，不敢向客戶抱怨！這需求，不只是三關的作業流程，還必須包含工作環境！

製作 Pizza 人員的地點在那裡？一個全是麵粉的工作台！

位置呢？很小，螢幕只能掛在牆上！

所以：根本不可能用滑鼠，只能用數字小鍵盤！再來，因為螢幕在牆上，所以字必須很大！再來，他是依訂單內容去做 Pizza，所以必須要告知佐料內容，份量，且一張訂單多個 Pizza，但他一次只能完成一個！

但是，當時完全沒考慮到這些問題，也沒有去參觀過使用者的工作環境，所以當時為了玩技術，用了花俏的不得了的 mouse 操作，結果可想而知．．．

若是做給工廠現場工作的人員，他在輸入及操作上，有何特殊需求？
若是做給店端現場工作的服務人員，他在輸入及操作上，有何特殊需求？
若是做給接電話的客服人員，他大多時候是處理什麼？他在輸入及操作上，有何特殊需求？

若是 B2C 的客戶呢？放在 7-11 的 ibon 一定是用觸控式的，不會用 mouse．若是給銀髮族呢？字型是否要大一點？操作是否要用 wizard 的方式，一步一步引導呢？

這些，都是在設計任何一個系統時，應要先去了解的，畫面的呈現及操作，會是此系統的成敗很重要的要素之一。

那如何確定客戶是誰呢？

除了問清楚外，參訪工作環境，多和客戶軟性的聊一聊，可以的話，和客戶一起參與工作幾天，都是必要的過程。

再來，UI prototyping 是一項很重要的工具！

以前沒有 html 的年代，KiKi 媽咪只能用 word 或 PE2（古老吧）一格一格的畫出來確認，現在，有了 html 方便多了，每個畫面的 Link 都可以清楚的表現出來，再加上文件的輔助，更可以讓系統表現的更清楚！千萬不要怕因為畫了 prototyping 會讓系統需求更複雜，在規劃時，問題早點顯現出來，總比人力全投入後，才發現和使用者的距離更遠來的好吧！

拉進你和使用者的距離，才會讓系統更有價值！