Redmine 是以 Issue Tracking 為概念核心。一開始的目的是為了追蹤軟體的 Bug，後來衍伸出追蹤 事情、議題 的概念，最後集結的就是專案管理的功能。

什麼叫做 議題？

Issue: 翻譯成『議題』，泛指需要被管理、處理、關注、討論、追蹤 事，後來我也延伸到 物 的管理。在組織裡面，每天有一堆事情要處理，大的事情、小的事情、專案的、非專案、很多人在意的、沒人關心的 …. 每件事情，都是 議題 Issue。

議題關注的重點有兩個：流程、角色

• 角色 (Roles)：誰負責？誰處理？重點在於 人
  • 角色代表可以有不同權限，或者走不同流程。
  • 軟體開發最基本的角色：Developer, Reporter, Manager
  • 在組織裡角色也代表著權力與資源的多寡
• 流程 (Workflow)：流程代表 SOP，可以 SOP 代表問題少。
  • 流程由一堆 狀態 (Status) 組成
  • 最簡單的流程： New -> In Progress -> Done
  • 流程所有狀態又分成 open, close 兩種。
  • 簡單說 Workflow 就是 有限狀態機 (Finite-State Machine, FSM)

每個議題可大可小，但是基本的需要知道以下資訊：

• 時間的起迄 (Start Date, Due Date)：開始時間、結束時間
• 估時 (Estimate)：需要粗略的工時估計，雖然叫工程師估時很不切實際，但是管理上還是要做。。。
• 發起人 (Author)：誰發起 (issue) 這個議題？
  • 這個發起人必須說清楚要做啥，跟 Assignee 溝通
• 負責人 (Assignee)：主要由誰負責這個議題， 只能是一個人。
  • 如果需要兩個以上的人處理，就需要 breakdown 成兩個以上的 issue，而由一個人負責管理所有的子議題。
  • 不適合的用法：循序 (Sequence) 的協作項目，也就是一件事情需要很多人做，把這張 Ticket 一個人傳給另一個人，這樣的用法不適合 Redmine，因為沒有主要的負責人。如果流程不常，建議 Breakdown 成不同的 Task。
• 狀態 (Status)：現在是在什麼樣的狀態？
  • 狀態代表著決策者接下來動作的參考點，也是整體進度的狀況
  • 狀態的集合代表著 Tracker 的流程
  • 狀態跟角色權限有關係，狀態可以透過流程規劃，限制角色的權限，達到全縣管控目的，例如只有 Tester 可以關閉 Bug

其他 Optional 的欄位，用在任務進行中管理使用：

• 優先權 (Priority): 優先次序
• Milestone / Version: 階段性任務的時間點，重點在時間。
  • 以軟體來講就是 Version
  • Redmine 會彙整相關的 Task 的進度，PM 要關注的是這個
  • Redmine 原始的關鍵字叫做 Target Version，後來我跟同事討論，覺得 Milestone 更適合
  • 使用 Agile 可以把這個當作 Sprint 使用，概念上是一樣的。
  • 相關文章：Version Control
• Category: 以 人 為主的任務分類。
  • 工作分類很多種，不知道找人，就找分類，每個分類會有一個預設的處理角色。
• 進度 (% Done)：完成到哪裡了？
  • 這個欄位的資訊會被彙整到 Milestone / Version

所以什麼是 一個議題 ？簡單說，只要需要花時間的，就是議題，例如：

• 讓公司今年達到 10 億獲利 –> 大議題
• 讓公司今年員工都加薪 –> 大議題
• 今年導入 DevOps 精神 –> 大議題
• ooxx 功能效能不好，要修正 –> 議題
• 應該要有 ooxx 功能，可以改善 aaazzz –> 大議題
• 某某功能上有一個 bug –> 小議題
• 利用自動化改善系統管理 –> 大議題
• 用大數據，找到公司的金礦 –> 大議題

這些大大小小需要被管理 事情 都是 議題，議題都會有主要的目的性、達到的效果，怎麼有效、有組織的管理這些東西，就是管理者要思考的。這件事情可以讓公司有淺力、有想法的員工參與，訓練獨立思考與判斷的能力。

Issue 的種類：Tracker Type - 以軟體開發為例

Issue 的種類在 Redmine 裡稱為 Tracker Type，針對不同類型的問題與需求，有不同的 流程 與 狀態。

以軟體開發為例，最常見的會有以下：

• Requirement: 需求，通常就是抽象的 商業目的，像是：
  • 提升轉換率
  • 供金流功能
  • 追蹤使用者點擊率
  • 相關說明參閱：需求管理 (Requirement Management)
• Feature: 新功能、新特色，需求經過系統分析、設計，轉換成技術人員可以時做的具體項目
• Improvement: 跟 Feature 很像，但是差異在於，Feature 是全新的功能，以前沒有的。Improvement 則是把既有的功能，做修改，不管是增強、調整、修 bug 等等。
  • 跟 Feature 很大的差異，被 Improved 的 Feature ，後續驗證階段必須增加回歸測試 (Regression Test)
• Defect: 測試階段發現的問題都叫做 Defect (缺失)
• Bug: 上線後發現的問題叫做 Bug
  • Defect, Bug 跟測試都有關係，相關文件參考： 淺談軟體測試的階段與策略
• Operation: 系統維運的工作項目，像是 Provisioning, Deployment, Obervation, Maintain, SecOps … 等

不再上述的工作項目全部用 Task ，是最一般化的任務，不知道選什麼就是 Task。

上述 Tracker 站內相關文章：

• 需求管理 (Requirement Management)
• 淺談軟體測試的階段與策略
• Resource Provisioning and DevOps

標題 Issue 的種類：Tracker Type - 以軟體開發為例 說明前述的設計是為軟體開發，其實我也曾經為 系統管理、人事請假 設計過不同的 Tracker Type，這些都是不同領域的 Know How，也是最珍貴的知識。

更多 Tracker Types

只要有自己的流程的議題，都可以定義成獨立的 Tracker Type，以下是可以獨立定義的：

• PoC (Proof of Concept)
• Budget
• Plan
• Release Engineering, DevOps, CI/CD, InfraCode
• Deployment
• Backlog
• Sprint
• 更多參閱 需求管理 的舉例

要注意的是，Redmine 的 Tracker Type 跟 狀態 (Status), 角色 (Role) 是直接關聯的，所以定義很多 Tracker Type 就代表會把流程搞複雜。流程複雜代表的 溝通成本 提升。

不同階段的企業

不同階段的企業，有不同的需求

• 草創期：通常是第一年
  • 每個人都身兼數職的階段。
  • 基本上這階段 Bug, Issue, 專案管理系統都不重要，有白板就夠了。
  • 還在燒錢與快倒閉階段，先穩定產品再說。
• 剛起步的新創事業
  • 大概是前兩年
  • 如果方向正確，會接到很多市場的需求，最需要 Time to Market 的時候
  • 使用 Scrum 這種方法是最適合的。
  • 議題管理系統還不是那麼重要，但是可以開始導入了。
• 發展中的事業
  • 通常是已經燒錢 2-5 年的公司，已經抓到基本的商業模式，同時已經開始獲利。
  • 轉大人 的關鍵時期，轉不過瞬間會在市場消失
  • 員工數量快速增加，搶人才的時候
  • 組織衝突每天都會上演，甚至是政治戲碼
  • 因為權責不清處，所以組織重構是很常見的
  • 開始需要用 制度 匡 人事物
  • 系統的歷史包袱漸漸浮現
  • 有不同地區的辦公室，但是都還是同一個國家
• 成長中的企業
  • 組織框架大致確立，在市場上已經有能見度和基本的品牌形象
  • 商業模式已經確立，但是持續調整組織以及經營模式。
  • 開始跨國、跨境
  • 有不同地區的辦公室，通常是跨國。
  • 沒有議題管理系統不行，而且需要有專門的部門負責流程制定、導入與管理
• 穩定獲利的企業，發展第二春
  • 商業模式經得起市場的考驗，且穩定獲利
  • 維運會比開發重要
  • 通常可能已經上市上櫃
  • 開始有不同的嘗試，嘗試新的商業模式
  • 集團式組織組織，開始分不同 事業群、事業部，像是 不務正業的先驅者 - YAMAHA

我以前的公司是一家穩定獲利的企業，內部有一套產品流程管理，使用的是 Oracle Agile PLM ，這套系統用來管理整個開發中的產品流程，可以設計各式各樣的關卡，做審核機制。

這樣的流程是可以透過軟體設定制訂出來的，非常的有彈性，但也很複雜。這種大型的流程管控是直屬 IT 部門的流程稽核部門負責。後來有了新的事業部 (就是我加入的事業單位)，他們就會來要求要走這套系統。

這段故事參閱 協同合作系統建制與導入 - 以 Redmine 為例 的介紹。

這段獨立另一篇： 不同階段的企業

議題管理

Redmine 在議題管理方面不是最好的工具，但卻是帶出 如何組織議題 這個思維的工具。

著名的專案管理 JIRA 也是以此為概念，甚至延伸到人事管理、HelpDesk、Operations、Legal 等項目，其實重點就是在如何分類議題以及定義流程，這些都是屬於 Domain Know How，atlassian 嘗試把他們包成不同的產品線，擴大市場。

我已經有一套屬於軟體工程專案管理的心法，未來再持續整理分享。

延伸閱讀

系列文章

• 概念篇：
  • 協同合作系統建制與導入 - 以 Redmine 為例
  • Issue Tracking in Redmine
  • 寫在介紹 Redmine 之前
  • 需求管理 (Requirement Management)
  • Software Development Lifecycle
• 系統篇：
  • Redmine 安裝篇：Redmine 4.0.x on Ubuntu 16.04
  • 系統整合：Integrate GIT in Redmine
  • 如何透過 Email 建立 Issue
  • 系統整合：Redmine Plugins and Themes

站內延伸

• Software QA 的職能條件
• 淺談軟體測試的階段與策略
• 軟體自動化測試常見的問題
• 溝通成本
• Version Control

參考資料

• 不務正業的先驅者　YAMAHA的科技樹到底是怎麼點的