在 UI 上如果沒有嚴苛要求的話，Redmine 算是一套非常棒的專案管理系統了，即使跟 Jira 相比也沒有差得太多(因為很多高階功能根本用不太到😅)，這篇文章會分成三大主題說明：管理者在專案創建前的準備、專案管理的實際應用、個人使用心得。
一、管理者在專案創建前的準備
➤ 角色與權限
➤ 議題狀態清單
➤ 追蹤標籤清單
➤ 設定二、專案管理的實際應用
STEP 1：建立新專案
STEP 2：分配議題(issue)
STEP 3：組員收到議題的分配通知，根據需求細分子議題
STEP 4：UIUX 完成設計，PM 分配後續工作給前端工程師
STEP 5：前端工程師細分子議題，並開 api 需求給後端工程師
STEP 6：後端工程師回復議題
STEP 7：PM 規劃測試流程
STEP 8：SIT 測試新系統功能
🤔 流程總結三、個人使用心得
一、管理者在專案創建前的準備
以下操作皆在『網站管理』分頁，僅列出重要功能，其他請自行摸索
➤ 角色與權限
系統僅會提供如下角色，但專案管理的流程中通常還會有『測試人員』、『UI/UX 人員』等角色，這裡就按造公司需求新增及分配權限即可
新增角色後會要定義他的工作流程，畢竟每個角色要做的任務不同
以測試人員來說，他們通常是要驗證已解決的議題是否處理完成，所以我會賦予的權限如下圖
➤ 議題狀態清單
如果你在剛剛操作角色權限設定時覺得狀態不敷使用可以在這裡增加
像測試人員就可能有『測試不符合預期』之類的狀態，新增後記得套用到對應的角色身上
➤ 追蹤標籤清單
這些標籤可以幫助你在尋找、歸納議題時的速度
➤ 設定
在『顯示』的地方可以調整語言
在『驗證』頁面參考調整以下選項：
- 需要驗證(是)：如果你沒改又忘記調整專案為不公開會讓一般民眾都可以瀏覽喔！
- 註冊選項(關閉)：如果開放註冊可能會被有心人士狂註冊，多了一堆垃圾帳號造成日後管理困難
二、專案管理的實際應用
以下用實際專案流程模擬操作，模擬公司實際職位如下
- PM(管理人員) — 開 issue 並且分配 issue
- UI/UX(開發人員) — 網頁設計相關任務
- frontend(開發人員) — 依據 UI/UX 設計完成前端
- backend(開發人員) — 配合前端需求給予資料
- SIT(測試人員) — 測試開發人員完成的功能並給予回饋
STEP 1 ：建立新專案
了解客戶需求後，由 PM 建立新專案
職位/角色：PM/管理人員
由 PM 建立一個新的專案並設定裡面的參數
建立專案時請注意：
- 名稱請填寫大家都看得懂的，如果專案有英文縮寫請放在代碼
- 『代碼』這個欄位儲存後無法修改，請謹慎
- 如果專案沒有要公開，請記得把公開的選項拿掉，避免無關人士看到
分配角色權限：建立專案後要加入成員並給予對應的角色權限
完成權限分配後的畫面如下，一個用戶可以有多重角色
建立專案版本：專案一定會有版本的更迭，每項議題如果都有對應的版本在管理及追蹤上可以容易釐清責任
建立議題分類：新人剛加入團隊時可能對成員的職權並不是很了解，如果在這裡建立分類的防可以快速幫助不熟悉團隊的人了解每個人的職權分配
STEP 2：分配議題(issue)
專案基礎配置完成後開始分配每個成員的任務，這裡先從 UI/UX 的設計圖開始
職位/角色：PM/管理人員
在建立議題的時候有幾點提醒一下：
- 概述：圖片可以用複製貼上，但上面只會顯示『!xxx.png!』，需要去『預覽』才能看到實際的結果
- 分類：如果選擇分類就會自動帶出被分派者
- 狀態：他的選項會跟之前賦予的角色權限有關，如果發現需要新的流程可以後續再做調整
STEP 3：組員收到議題的分配通知，根據需求細分子議題
PM 給予議題的大方向任務，組員再依據自己的專業將工作項目細分，這樣更方便追蹤議題的作業進度並評估個人績效
職位/角色：UIUX/開發人員
如果有設定郵件通知的話會收到跟下面類似的信件
閱讀完議題的需求後再依據自己實際的工作項目去細分子議題，操作方式非常直覺就不在多做介紹
議題清單：在這個頁面可以瀏覽所有議題，依據自己的工作完成進度去編輯『任務完成百分比』、『狀態』、『紀錄時間』，方便PM了解實際的工作狀況
STEP 4：UIUX 完成設計，PM 分配後續工作給前端工程師
PM 在議題狀態轉換時也會收到 email 通知，這時他可以做後續的議題分配
職位/角色：PM/管理人員
相關的議題清單：PM 新增議題的方式不再贅述，但這個議題因為需要參考 UI 設計的草圖，所以要在『相關的議題清單』與 UI 設計的議題作關聯
STEP 5：前端工程師細分子議題，並開 api 需求給後端工程師
前端工程師在設計前端頁面的同時也會開 api 的需求給後端工程師，兩者間配合才能完善網頁
職位/角色：前端工程師/開發人員
這塊比較不一樣的是前端工程師應該要更細節具體的描述每個 api 所需要的內容，所以除了『後端 api 需求』這個父議題外，也需要增加細部需求的子議題。
STEP 6：後端工程師回復議題
後端工程師在依據前端工程師的需求完善後用回應的方式說明 api 的格式讓前端工程師完成最後的串接
職位/角色：後端工程師/開發人員
後端 api 不是完成就好，要附上相關說明文件才能節省雙方溝通時間並留存紀錄。
STEP 7：PM 規劃測試流程
在前端工程師與後端工程師串接完成，也確定基礎的操作都穩定後就可以請 SIT 人員做測試了，相關的測試項目及流程一般會由 PM 做後續安排
職位/角色：PM/管理人員
STEP 8：SIT 測試新系統功能
SIT 依照 PM 分配的測試流程進行測試，如果正式成功就能把該議題狀態改為『已解決』
職位/角色：SIT/測試人員
SIT 測試過程中如果發現問題除了把議題狀態改為『測試不符合預期』以及回覆哪裡錯誤外；額外發現的問題也可以新增子任務詳細說明問題，並將子任務都先指派給 PM 讓 PM 再分配給相關人員做處理
🤔 流程總結
基本上就是測試到這個專案版本沒有任何問題後會再開新的專案版本，依據新的功能需求去實作；上面所敘述的流程僅供參考，實際的步驟還是需要公司內部有足夠共識才能真正讓這個專案管理工具發揮作用。
三、個人使用心得
- 相比之前文章介紹的 Microsoft List、Planner ，這套系統我個人認為是完勝的，各種功能都非常完善，如果想要更多的功能也能透過 plugin 去做擴充，而且還是免費的XD
- 但如果跟 Jira 相比，他功能就少了一點，比如：缺少 Sprint 的概念、沒辦法於文章中用@來tag相關人員、一個議題只能有一種追蹤標籤。但基本上功能已經夠用了，也許上面的功能都能透過 plugin 處理，這些就要後續再做研究了。
- 功能擴充自由度相當高，公司如果想要導入這個專案管理系統建議要有工程師與 PM 一起配合研究，因為一些資訊的顯示還有流程要自己手動修改才能符合真實的需求。
🙂 讀完這篇文章後
▶︎ 如果這篇文章有幫助到你1. 可以點擊下方「Follow」來追蹤我～
2. 可以對文章拍手讓我知道 👏🏻你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼▶︎ 如果你對工程師的職涯感到迷茫1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持，透過豐富的案例來重新檢視自己的職涯
