我自己很喜歡案例實作，因為在實作的過程中，會讓你更能夠將軟體功能與現實的需求有所連結。所以後續幾天有為數不少的案例實作，並且也會分享我自己的拆解脈絡。

這些拆解脈絡與規劃 Redmine 的方式，也適用其他專案管理工具，並且不是「唯一正確解」，所以如果有不同的想法也歡迎留言補充！

那麼我們就來進入今天的實作：
[Part 6: Redmine 案例實作 - 工作篇] 的第 1 篇 [ IT 報修 ] 。

案例訴求

1. 目前如果有電腦設備等問題，都會是個別私訊特定人員，無統一的記錄處 & 分配任務較容易不均。
2. 所有公司人員都可以透過 Redmine 通報議題，請求 IT 人員協助
3. 若還是有私訊狀況，仍要統一記錄，就需要由 IT 人員進行。
4. 需要可以知道問題被解決、完成的時間點，並且也想知道問題的解決。
5. 處理人員處理時，需要將議題類型進行分類，方便後續統計歸類分析。已知分類想分成設備需求、軟體需求、設備排錯、軟體排錯、門禁監控。

案例思考

我們分 3 個面相分別切如，幫助自己判斷後續實作時，需要關注到的細節。

角色與權限

這邊提到兩個大角色，公司的所有人員 & IT 人員

1. 所有人員：可以建立議題
2. IT 人員：可以處理議題、更新議題、可以建立私訊而來的議題

議題類型與流程

1. 在這邊的訴求裡面沒有特別的流程訴求，就先以最基本的開始、處理、結束等 Redmine 基礎預設狀態來使用。
2. 提報議題不需要填寫的欄位就不要出現，避免填寫者疑惑

欄位需求

1. 想要知道誰解決這些問題
2. 想要知道每個議題的類型
3. 想要知道總共花費的時間

實作脈絡

定義、確認帳號的角色權限

先確認 Redmine 預設建立的角色裡，有沒有合適選項，最後決定就以 Reporter 作為全公司提報議題的角色，而IT人員，就選擇使用 Develop 角色，不另外建置新角色權限。

如果這個 Redmine 是專屬於 IT 單位內部處理，但是開放給全公司可以在這個 Redmine 上面提出議題，這樣也可以考量去設定「非會員」（aka. 非專案成員）權限，這樣就不需要還在特定專案中，還需要多執行添加帳號到指定角色裡面。（簡而言之，就是可以偷懶一點 XD）

添加群組

考慮到如果後續添加新成員的權限方便性，建置一個全公司群組，這樣後續就會自動加入到這個專案裡面。

（偷偷抱怨一下 UX ：應該要有個全選會比較好啦🤣 ）

議題的追蹤標籤

因為想要自定義流程，並且也需要後續的議題分類，所以就需要多額外添加不同的追蹤標籤。

當所有人一開始建置提報的議題時，都需要統一一個預設的分類，有點類似 Inbox 概念，為了不要跟別人的議題流程混合，就不能又再以 原本 Redmine 就預設建置的「Support」，我需要建立一個「議題提報」追蹤標籤。（為什麼要這樣的原因還記得嗎？因為所有權限是 角色 x 追蹤標籤 x 流程 組合，所以當我們在角色那邊，選擇用大家通用，那標籤和流程段，就要自己客製化，才不會影響到其它專案的使用流程）

已知需求上希望後續的議題標籤分 設備需求、軟體需求、設備排錯、軟體排錯、門禁監控，所以也要建置對應的追蹤標籤。而因為其實這些分類目前的流程都會是一樣的要求，所以在這邊就先建立一個追蹤標籤「設備需求」，後續等流程設定完成後，再回頭件至其它追蹤標籤，就可以直接複製元流程與欄位需求。

設置對應的角色的流程權限與欄位

首先是針對議題提報的部分設置。需要分成一開始的初始議題追蹤標籤，還有後續分類標籤，以下就以初始議題設定做代表設定示意。

再來是針對 IT 人員的 Develop 角色設置權限與欄位，也同樣要注意，同樣也要記得在一開始初始議題的追蹤標籤跟後續分類的追蹤標籤都要設定，以下就以後續分類的追蹤標籤設定為示意。

補回剩餘追蹤標籤

在這邊有一個小細節，就是在這些追蹤標籤建置的預設狀態，都是選擇了 In Progress，這是因為對於提報問題的使用者來說，一定不會知道到底算是哪一個分類的議題。但是如果他們採取私訊 IT 人員處理，而IT 人員去建置的時候，就會清楚知道類型，就也不需要從最一開始的狀態開始跑。

添加專案 Developer 成員

設定專案用的議題追蹤標籤

案例成果

公司人員角度 - 提報議題

IT 人員角度 - 處理議題

IT 人員角度 - 提報議題

IT 人員角度 - 查看議題分類狀況

IT 主管角度 - 查看個人議題分配比例

今天的 [ 案例實作 - 工作篇] IT 報修 就到這邊，後續幾天都會是不同的案例實作，明天的實作主題案例是人資的「招募管理」，有興趣的話就下一篇再見囉！