###### tags: `部門文件`****

維運專案計劃書
===

[TOC]

## 背景說明

維運系統已經上線N年，但維運錯誤的數字似乎已達到瓶頸，無法在做有效的下降。但對同仁來說，維運的工作量並未因此而減少，因此，維運系統的效率需要進行檢討與改善。

## 需求分析

維運系統主要的目標對象為資訊主管和同仁，我們根據此兩個對象做需求訪談。

### 主管痛點
1. 逾時類的問題，無後續處理方式
2. 未包含API類型的程式
3. 無趨勢類的統計報表
4. 無法得知同仁耗費在處理&修復bug所花的工時
5. 無法反應問題是否已確實被解決，只能知道同仁有做過處理

### 同仁的痛點
1. 維護維運問題，無法自由安排時程修改
* 因維運系統有時效追蹤，導致得先壓已處理
3. UI設計界面不良
* 同程式發生多種類錯誤時，同仁需重複維護
* 篩選條件不直覺
* 報表操作介面和維護介面部分名詞和邏輯不統一
4. 無法得知修改後的改善狀況
5. 錯誤訊息不夠明確

## 設計概念

針對主管和同仁的痛點，我們以下列5點原則為目標，做整體的調整設計。
1. 強化錯誤分類機制
2. 詳細錯誤訊息
3. 支援API錯誤捕捉
4. 優化UI操作介面
5. 更多功能性報表

### 畫面設計
https://9i6f08.axshare.com

### 功能清單
新Feature介紹
1. API錯誤自動提報
* 整合目前API專案的錯誤資訊
3. 問題處理追蹤
* 自行排定修改時程
* 追蹤是否重複發生
* 修復進度的追蹤頁面管理
* 修改類型
* 已處理
* 處理中
* 無法處理
* 申訴
4. 強化錯誤訊息呈現
* 錯誤發生類型
* 首次發生
* 再發生
* 修復後再發生
* 錯誤原因類型
* 物件未指向參考的執行個體
* 連線未開啟
* etc
* 支援tag查詢
* 錯誤細節
* 發生問題的行數
* 呼叫的堆疊
* 當下發生問題的操作者身分
5. 提供自定義的Log元件
* 系統部可自行定義寫入的log
* 當報錯時，會繫結此次session的LogId，方便系統部取出自定義的log
* 需申請才會記錄
6. 優化操作UI介面
* EMAIL連結可直接導到該維運錯誤的ERP畫面
* 以程式為群組的方式維護錯誤
7. 更多角度的報表
* 以事業部區分
* 以錯誤類型區分
* 新發生
* 再發生
* 程式錯誤管理
* 可填寫備註
* 可一次瀏覽所有錯誤

## 人力分配表


### 開發時程表

## 預期效益

1. 把API專案的維運錯誤也納入管控
2. 專案可以有更多指標，顯示系統維運的狀況
* 錯誤修正率
* Bug修復數
* 錯誤Tag分類
3. 讓同仁更有效率的維護維運錯誤，降低同仁負擔