Nokia KPI Management System
2020台灣5G網路正式上線，通訊工程師需要一個好的系統監測基地台數據。
Nokia是全台最大的通訊服務供應商。負責中華電信、台灣大哥大、台灣之星、亞太的基地台通訊維護解決方案。我的任務，就是提供軟體的解決方案
年分: 2019 - 2020
任務: 整合並建立新的5G基地台效能管理系統
夥伴: 從一位資料庫管理員，到一位前端、兩位後端、一位資料庫管理員
要產出什麼產品？
我們四大客戶（中華電信、台灣大哥大、台灣之星、亞太電信）發射的訊號，需要整合出一個的5G效能分析平台。通訊工程師需要洞悉各地基地台效能，來追蹤基地台歷史趨勢。
我的任務
提供軟體工程的解決方案。
負責尋找使用者的切身需求
使用者操作的情境、利用系統解決什麼問題、有什麼困擾？
理解管理者的績效指標
為什麼會支持開發產品？希望能交出怎樣的成績單？
理解資料庫管理員的處境
資料庫管理員總是幫使用者做怎樣的額外查詢？這些查詢是系統做不到的嗎？還是資料庫的限制？
熟悉硬體上面的限制。
原始資料是怎麼匯入的？資料是怎麼建表、配置的？經過了什麼優化？
我需要探索每個角度的視野。
困難點是，初期我對通信不熟，沒辦法理解什麼是Throughput、NRBTS。這是我相當大的挑戰，但為了設計產品我非學不可。
我決定從訪談開始，傾聽使用者的需求，並學習基地台知識。
研究過程
我訪談負責基地台優化的工程師，這期間訪談7位工程師、2位主管，留存近43份錄音檔，留下一疊珍貴的使用者隨手草稿。
透過大量的訪談，我能快速理解使用者口頭上的需求並學習基地台知識。
檢索、操作各種數據分析系統的使用介面
包含Excel樞紐分析、Tableau、Google Analysis等分析系統，找出每個功能的設計方式、流程、推敲不同類型的UI設計的道理。
觀察的地方例如，Excel樞紐分析表裡面，使用者透過拖曳欄位名稱於欄、列、值、Filter來達成不同樣式資料的排列組合；Tableau中則透過Dimension, Measurement將數據組成不同圖形檢視，且資料匯入的形式如同SQL一般能夠Left Join, Inner Join以決定資料形式等。
很多問題在過程中湧現，例如「為什麼Tableau會分Dimension, Measurement而樞紐分析就不會?」、「為甚麼Tableau的Date可以設定Continous跟Discrete?」研究期間不僅僅要熟悉分析工具，還要探勘使用者是如何分析的，甚至要學會像通訊工程師一樣從資料觀察出洞見。
訪談、觀察使用者操作舊系統
透過使用者的介紹、操作，可以直接觀察使用者的行為以及使用者所認知的系統長什麼樣子。此外，基地台細胞、TDD、FDD等各種通信基礎知識、架構也能讓我在期間快速學習、吸收。
訪談過程中，我不斷詢問他們通常要解決什麼問題、解決的過程、找出一些他們覺得困難的地方，向下探索。
有趣的訪談現象：
心中已有答案
有時候他們表現的向心理已經有個解答似的希望我處理，告訴我他們發生什麼事情，然後需要「這個功能」，麻煩你幫我做「這個功能」就好。但往往他們想要的功能背後有更深層的原因。
「一般來說」，「通常」，「正來的話...」已經跳脫自己的操作情形。
有時候能看出使用者講的流程不是他的情境，而是他認為「理想的模樣」長什麼樣子。
繪製草稿
訪談、操作的同時利用草稿來向使用者諮詢、操作。其中在想法交流裡最有價值的是Lo-fi線框搞。不是只有我在繪製線框稿，使用者也會用線框稿來說明他覺得可行的。透過草圖的互動所得到的現象，在後來成為設計洞見的基石。
一些洞察
使用者內化既有功能
有些功能因為使用者長期使用，自然而然變成合理。會出現「透過A功能實現B功能」，「加強A功能讓B功能更好用」的情境。
其中一個例子是：總覽報表裡面有線條圖功能。使用者要產生十個線條圖，就要查詢十次總覽報表。「那為什麼不給我個按鈕一次口氣查詢十個總覽報表就好了？」
非常、非常挫折
舊系統設計不良，非常容易出錯。一旦出錯，使用者就要麻煩資料庫管理員善後。
「欸，我犯了蠢事，你懂的」當資料庫管理員聽到使用者這番話，就知道當事人查詢了範圍太大的日期。當我看到舊系統介面上Date Picker「預設」就是一個月那麼長，就知道問題出在哪裡。
想要的方向不太一樣
使用者總是希望有多種報表，於是資料庫管理員發明了一個功能－－讓使用者用SQL查資料。問題是解決了，但提高了很多系統資源消耗、資料的意外狀況、拋出錯誤。
管理員接著改善這些錯誤，但事實上使用者不應該像管理員一樣用SQL直接存取Database。
趨勢的分析不是產出報表，而是尋找關連、推敲原因
基地台優化是大工程。一個KPI的波峰，可能有多種原因。透過來回查詢各種KPI、調出各種資料來推敲原因，並提出改善計畫。
例如，一個站台的掉話率增加了，可能代表通話基數增加，也可能設備壞掉。這個站台設備如果壞掉，那其他相同型號設備的基地台也會壞掉。這些就是使用者的日常案例之一。
更多相關洞察最後都成為了產品設計的立足點。
易用性研究
使用Figma製作Hi-fi原形，讓多位各部門的使用者「各自」或「一起」操作，尋找問題點。
由於基地台分析是艱澀的專業，一旦設計錯誤將造成災難。透過易用信研究不僅僅我能得到回饋，也能讓使用者理解未來的產品，並給予利害關係人信心。
使用者關懷更多的是可行性、資料流、呈現方式等。
各種數據分析系桶探索－Excel樞紐分析
Excel樞紐分析表裡面，使用者透過拖曳欄位名稱於欄、列、值、Filter來達成不同樣式資料的排列組合
各種數據分析系桶探索－Tableau
Tableau中透過Dimension, Measurement, Attribute將數據組成不同圖形檢視
訪談的錄音檔
期間訪談7位工程師、2位主管，留存近43份錄音檔，留下一疊珍貴的使用者隨手草稿。
各種影響產品的角色
我訪問各個角色的需求。這專案專乎哪些角色？
高階主管（利害關係人）。我訪談他們對系統的期待、他們關心的績效指標、成果。
通訊工程師。我訪談使用行為、每位工程師的業務、處理業務的情境、整個系統操作的流程、向客戶呈現的報告格式、圖表、資料。
資料庫管理員。我討論資料流、資料庫的Schema、自動化流程、SOP
多方訪談，切身關懷，問題發掘
情境: 使用者希望多選很多績效指標群組，雖然會查詢到多餘的績效指標，但這樣按一下就能全部跑好報表群組了。但是資料庫管理員擔心Join太多database Table所以不願開發。
註：基地台的KPI很多，上千種，還被分成數值種不同群組。每天都會有好幾GB的原始資料資料匯入進來表格，如果使用者查詢一整年的趨勢，資料庫就不堪負荷。這些使用者的查詢甚至會讓SQL查一整天。
核心問題: 想要多選群組是因為一個群組不夠，「群組」在這情境下已經失去群組的用意。資料庫管理員不願開發，因為開發了，會浪費了很多系統資源在Join多餘的資料表上。
解決方式: 設計出容易編輯的績效指標群組，讓使用者活用群組，不僅能跑出使用者需要的報表，也能減少Table Join的數量。
情境: 按下查詢按鈕之後，使用者會等待資料跑出來，但不知道系統到底有沒有在作用，有可能是條件設錯了? 多按了幾下也沒反應。
核心問題: 使用者不知道現在的情形。他需要一點回饋，至少告訴他哪裡錯了。
解決方式: 如果產品開發要快還需要顧及易用性，那可以直接導入Material Design Component，不僅相當適用於Angular，也能提供豐富的微互動回饋。
解決方式: 任何按鍵都要有Material Ripple回饋，並且明顯提示使用者。即使是錯誤也要詳細回報錯誤訊息、種類。
解決方式: （附圖）按下Query一定會有執行中的畫面、（附圖）一旦匯入出錯，至少要說第幾行第幾列的資料出現什麼問題。
情境: 我不太敢去使用「公共」KPI的資料，有些都是錯誤的。可能以前是對的，但隨著每年更新，就變錯誤的了。不知道的人如果用了，資料就不正確。
核心問題: KPI會與時俱進，但系統的KPI沒人維護，是公共財的難題
解決方案: 分成Public跟Private的績效指標，讓每個人有自己能管理的Private績效指標。就算是Public也有主管能管理的公共績效指標。
種種發現，不勝枚舉。
我與不同部門確認產品功能，並過做數次易用性研究之後，驗證上面舉的點子。
其他類似的問題像是，將管理績效群組的功能下放給使用者編輯而非資料庫管理員編輯、多選輸入基地台功能、各種基地台細胞群組顯示方式、圖表上下界左右軸需求等等。
還有開發人員的難題
除了產品外，前端開發跟後端開發，都出現挑戰。
前端方面，開發速度慢，追不上後端。
後端方面，人員流動率高，內部資料庫知識出現斷層。
明年的七月5G要開台，我們快沒有時間。
要如何解決呢？
一個解法是，撰寫需求規格書，模組化元件，然後在會議上提出外包前後端程式寫手，並尋找正職後端。在這期間不斷開會，爭取資源、評估產品功能的可行性、評估時程、規劃分工方式，最後定案。
在這個方案裡，我負責介面設計、程式架構，外包則負責實現程式碼。
透過分工，外包開發人員不需要重頭學習基地台知識，只需要遵循需求規格書，就能完成程式碼。
不僅如此，前端所採用的Angular接近MVC的架構，能讓每個人負責不同模組，分頭開發，加速開發。（附圖，模組化分工）簡報
更多、更多的開發難題
情況變成後端趕不上前端的開發，怎麼辦？
In Memory Server
使用In-memory-server，讓前端能用Javascript製作假後端，在前端模擬Http協定傳送API。透過這個方式顯示查詢結果、製作錯誤訊息、處理異步的問題。更重要的是，由於是模組化開發，到時候只要在Server上線時，換掉模組就好了。
如何驗證資料都是正確的？
情境是，在KPI Management System裡面都是相當龐大的查詢、關連跟邏輯運算，運算出來的資料可能因為來源資料有誤、函式錯誤而導致結果不正確。當然使用者不可能知道是函式錯誤。
兩萬種函式的排列組合，就算是一個厲害的工程師也沒辦法在短時間內驗證。
Excel函式
我曾經有聽過數據分析師的講座，他的工作雖然用Python, SQL處理資料，洞悉問題，但他建議我們，學會基礎的Excel就有很多函式能夠分析數據。
確實，在Nokia的案例中我大量使用Excel的函式。
為什麼？
考量到多人合作去驗證巨量資料，人工比對不可能，但函式能。
只要先設計好每個儲存格的函式，再把資料原封不動貼上來，就能直接看到答案。
我們用這個方式，發現許多計算問題，並修正我們SQL，成功防止資料呈現錯誤，也大幅增加工作效率。
運用Regex疏理資料
在這期間有很多屬於來源資料的探勘與資料的疏理都需要花大量時間處理。
我們使用Regex解決很多屬於資料上的問題，例如：
如何從一大份公式文檔裡面把所有「Throughput」類別常數抓出來？
找出所有用到「Throughput」這個變數的函式
官方資料少了一個結尾小括號，這結尾括號應該在哪裡？
該如何移除一個常數的前綴詞？
Regex上我們在資料處理方面更得心應手，加速開發的效率。
追蹤使用行為
隨著5G上線，產品開發即將告一段落，但這才是認識使用者的另一個開始。
在追蹤使用者行為之前，有問題都藏在心裡－－
透過追蹤使用行為回答的問題
他們都下多大的搜尋範圍？
如果出現錯誤訊息，他們會做些什麼事？
他們查詢的資料中，最常用到哪張資料庫的資料表？
使用者都在哪個地方下錯搜尋條件呢？
如果重複查詢那會是因為發生什麼事？
前期的質化訪談不夠，我們需要數據背書，我們導入分析工具。
Mixpanel
Mixpanel擅長於蒐集使用者點擊的資料以及帶入的資料。
透過這些點擊，不僅能知道宏觀的使用狀況、不同條件（情境）下的流量、看到不同點擊所夾帶的參數為何，也可以觀察每個個體的點擊情形、點擊次序與數量。
這些數據資料拓展了我對使用者的新視野
HotJar
與Mixpanel不一樣的是，Hotjar能夠呈現網站上面滑鼠停留的熱度圖。比起每次點擊的紀錄，HotJar能觀察到的視野十分獨特。對於使用者研究來說能夠補足Mixpanel的缺點，然而我還正在熟悉這個工具。
成長
無論研究、設計、開發、專案管理，我找到很多解決問題的方式，
如你所見，我所解決的問題不僅是介面設計，而是整個軟體開發的解決方案，無論研究、設計、開發、專案管理，我從很多解決問題的方式中學習。
以問題出發，跳脫職位框架
解決方法從不屬於特定的職位範疇，而是以「核心問題」做出發點，學習方法，並利用方法處理問題。這不代表每個技能都蜻蜓點水，而是在不同的開發階段找出問題、找出解決方式、學習使用工具，最後交付服務。
現況
台灣在2020/7/1由中華電信首次開台5G服務，中華電信的5G資料在我們系統中能被觀測到。
我們團隊也在這個重要的里程碑中，幫助5G服務的通訊穩定、優化效能。
產業知識需要時間學習，陳浸越久越能展在使用者角度
我沒有想到我能設計那麼複雜的系統。這系統的使用者有著艱澀的專業知識、上以千計的數據種類。我以為的設計，是像之前的專案一般，設計社群軟體、地圖App找到新的玩法並且推廣、優化。但在Nokia的系統不一樣，讓我在視野上有更多的見識。
設計稿與目前產品界面
我將研究流程與介面設計分開，本篇著重設計過程、發現以及解決方法。 線框稿、視覺稿、實際產品可以透過線下簡報呈現。