寫在介紹 Redmine 之前
Redmine 用 Ruby on Rail (RoR) 開發的專案管理、團隊協同合作、議題管理工具。
我一直很想把他帶入公司，因為覺得每家公司應該都有這樣的協作平台，他可以扮演組織內部重要的潤滑劑，同時減少 溝通成本。
不過在介紹 Redmine 之前，先整理一些問題：
- 專案管理是什麼？
- 專案管理要呈現什麼？
- 協同合作工具在團隊裡是阻力還是助力？
- 有了這個工具能為組織帶來什麼好處？
專案管理
專案管理是什麼？
宏觀地來看：管人、管事 - 可以說是政治
- 管人，更宏觀的說法是：資源。包含人力資源、資產。說到人，就會牽扯到權責、角色、組織、工作分配等問題。這也是專案管理裡最難搞、最複雜的。
- 管事，依照不同的任務分工，對應不同的組織、專業、流程，然後就是最重要的時間
所以專案管理是什麼？一種政治。
專案管理要呈現什麼？
專案管理的重點在於呈現執行 (Execution) 狀態、進度、反映成本、風險控管等。
一句話：要能看到大局的狀況。
協同合作工具在團隊裡是阻力還是助力？
那要看怎麼用，還有公司發展的狀況。
經驗以及歷史看起來，組織越小，他越不重要，因為大家只要口頭，或者用扛棒就可以搞定大部分的狀況。
但是組織越大、跨越多地理位置、時區、文化，他就會越重要。有些公司甚至有專門在制定相關流程的單位，專人專職。
所以是阻力還是助力，我覺得要看老闆想不想把公司搞大，想搞大，他就是助力；只是想依樣畫葫蘆，做做樣子，他會是很大的阻力。
這種工具，一定要有老闆支持，而且老闆也要會用，而且要很熟，而不只是讓一個助理去弄。
相關工具
我習慣用四個階段來表示專案的階段 (Stage)：規劃 (Plan)、執行 (Execution)、驗收 (Acceptance)、維運 (Operation / Go Live)
有點類似 PDCA 的想法，但不一樣，更多參閱 Software Development Lifecycle 深度介紹。
Redmine 其實比較專注在執行的階段，像是開發任務、測試問題追蹤、任務管理，其他像是規劃、維運也可以透過設計流程、定義角色，達到類似的功能，相關的細節我會在後續做更詳細說明。
規劃階段，有個很重要就是『需求管理』，比較進階的協作平台都會有這樣的功能，但是截至目前為止，我還沒遇到真的有企業在使用。我在前一個工作擔任 QA Manager 時，會把 SQA Team 的建議 (Suggestion) 當作一種需求，從驗收階段放到下個循環的規劃。
測試階段除了一般的 Bug/Defect 追蹤，另外對於測試團隊很重要的是 測試管理 (Test Management)，我個人很推薦的是 - Testrail，這是要錢的，而且不便宜，但很推薦。有機會再介紹。
系統維運部分，我現在的工作也是用 Redmine 做管理，不過維運的事情很多很雜，目前我還在摸索階段。
除了這四個階段，其他還有文件管理、IM、Mobile 等整合，也都是現代協同合作系統必要的。
Why Redmine?
其實 Redmine 已經有點歷史 (since 2007)，技術也不是很新穎，特別是前端 (Front-end) 已經是比較過時的設計。
市面上有很多新的，像是 Jira, Trello, Basecamp, Open Project, VSTS …
- Slack 是溝通工具，不是專案管理。他只能短暫找到人，但長時間來看，他上面的訊息很難變成有參考價值的資訊。
- JIRA 也是很棒的專案管理，功能非常強大，但是很貴。
- 選擇 Redmine 的另一個因素是 Redmine 可以無限制的 Parent - Children 關係，而 JIRA 不行。
- Redmine 的流程定義比較容易操作，但是不好管理
- JIRA 的流程定義可以視覺化，但是管理很複雜
- JIRA 的流程有 Project Level 的設定，Redmine 則是 Global 的。
- Trello: 小團隊可以，複雜的專案管理我沒研究過。
- OpenProject: 改 Redmine 的分支版本，主要是改 UI/UX
- wrike: UI/UX 設計得很棒，但是 workflow, permission, sso 等整合都要商業版才有，很貴。
選擇 Redmine 做專案管理很重要的是：他能夠抽象畫專案逕行過程中所有的事情，同時能讓所有人聚焦。
這跟為什麼現代的程式語言都往 OOP 發展靠攏，像是 PHP / node.js … 等？因為可以抽象畫要解決的事情。
OOP 透過定義 Class 產生 Instance / Object 可以解決很多問題，Reuse 整個架構。而 Redmine 也是，透過定義 Tracker Type (Class)，不管是最抽象的 Task、還是具體的 Feature / Improvement、維運需求，甚至是人事管理 (Absent)、資產管理、Billing … 只要可以被定義，就可以產生出無限多的 Instance (Issue)。
延伸閱讀
系列文章
- 概念篇：
- 系統篇：
Comments
About
著作
演講
AWS Certifications
