寫在介紹 Redmine 之前


RedmineRuby 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