開源的專案管理工具 - OpenProject

專案管理相信在各行各業都扮演著很重要的一環。專案管理的核心就是追蹤專案進度，確保能準時交付。當專案結束或封存後，也能回頭檢討當初做的好或不好的地方，以及遇到困難的處理方式，這些紀錄幫助後續的持續改善。因此，好的專案管理工具能大幅提升管理的效率，節省時間成本。在軟體開發的工作經驗中，或多或少都接觸了一些管理工具和平台，在這之中，想介紹一套開源的專案管理工具 - OpenProject，這個工具在我們新創團隊中也使用了半年以上，所以文中也會穿插一些使用心得。

---

在開始介紹前，我想先說一下自己分享開源專案的初衷以及挑選工具的幾個方向:

初衷:

• 推廣開源，資訊共享
• 有趣味性
  • 能從專案本身看到或學到一些事情
• 使用過也覺得不錯的專案

挑工具的重點:

• 操作介面友善
• 官方文件架構清楚和資訊簡單透明
• 專案持續更新與維護
• 不能綁架使用者
  • 例如: 若是筆記工具要能支援匯出、轉移
• 安裝環境的支援程度
• 開放的社群以及活躍度 (加分項目)
• 支援第三方整合 (加分項目)
  • 例如: 有開放的 API 和 API 使用文件
• 學習門檻低 (加分項目)

[補充] 但有時候也是要看當下的需求以及情況來做重點調整

---

OpenProject 介紹

基本介紹

OpenProject 的創始人是 Niels Lindenthal，Niels Lindenthal 本身的學術背景就是管理相關，並且也有專案經理的工作經驗，所以在產品設計上，更貼近使用族群，從使用介面能體會到順暢的管理操作動線。OpenProject 分為商用和開源兩種版本，開源版有完整的程式碼放置於 Github，後端開發的主要語言為 Ruby，而前端為 TypeScript 搭配 Angular 框架。官方建議的安裝方式是使用 DEB 或 RPM 軟體包來建置環境，當然也有支援 Docker 的建置方式，安裝細節可以參考官方安裝文件。OpenProject 有自己的社群 (OpenProject Community) 以及 bug 的回饋管道，從 OpenProject 的 release note 和社群互動中不難看出他們持續維護和改善的積極度。

[註解] DEB 和 RPM 套件是 Linux 系統中兩種主要的軟體包格式, ex. DEB (.deb) 給 Debian 相關系統和 RPM (.rpm) 給 Red Hat 相關系統

值得學習之處

比起一般官方的介紹方式，我想從另一個角度切入來介紹，就是介紹這個專案值得學習的幾個地方:

文件的撰寫和架構

想學習如何撰寫一份好的技術文件卻缺乏範本和參考的話，OpenProject 的官方文件就會是一個很好的學習資源，在文件的整個架構規劃上相當完整，並且針對不同的群眾身分有相對應的閱讀文件，像是分類出一般使用者的操作文件、系統管理者的指引文件、企業的引導文件和開發協作者等相關文件。

軟體產品的設計

OpenProject 的文件中，有放置自家產品開發設計的相關文件，其中的兩個部分引起我的注意，一個是 Product Development, 另一個是 Application Architecture。

• Product Development 的文件中提到了他們產品的工作流，將產品需求收集到最後釋出給客戶的流程圖開放出來並持續改善這點，就有很多知識點可以學習，學習別人如何將流程任務拆分，從起初透過需求層面定義規格到開發建置再到最後發行和回饋。這個讓內部工作流程資訊透明化的好處是除了內部員工，外部想加入或貢獻此開源專案的開發者都可以很快融入團隊並了解團隊的運作。

• Application Architecture 文章內容有展示目前 OpenProject 的應用架構，從架構圖中可以得知系統包含的伺服器建構資源如 Puma 應用伺服器，中間的連結方式像是 Proxy 的導向和 HTTPs 請求以及內部使用到的服務項目如 database 和 email gateway 等，也有設計與第三方資源透過 HTTPS 請求的整合方式等資訊。對思考軟體產品設計架構這塊也是可以參考學習的地方。
  

核心功能

OpenProject 的功能這邊不會逐一介紹，畢竟一般專案管理系統會有的基本功能像是任務的新增、移動和分配等專案管理工具都會有，所以本段落會側重介紹個人使用下來覺得很有記憶點的功能。

任務管理

• 檢視方式
  在任務管理中，掌握任務的進度相當重要，當任務一旦被拖延到就有可能拖垮整項專案。在實務經驗中，甘特圖是我最常用也覺得最有效率的方式，一來是圖像化的表達方法很好閱讀，二來是能快速掌握資訊以及時間軸。OpenProject 除了有基本的任務條列和方格顯示，也有提供甘特圖的狀態顯示，只要先在任務中輸入開始時間和結束時間，就能在專案的甘特圖頁面中看到這項任務預計的時間軸。另外，切到 Overdue 頁面中會條列出目前專案中已經延遲的任務，因此也不用再額外自己篩選。
• 關聯性
  一個專案底下通常會有多個任務，而每一個任務底下可能又會拆分出好幾個小任務，不同任務之間也可能會有相關性或重複的技術議題，所以在 OpenProject 中任務彼此之間能透過關聯的方式去做連結，也就是說除了一般的樹狀結構方式，也可以有重疊的關聯設置。樹狀的連結方式我們通常都用父子關係來比喻，一個孩子只會有一個父親，而一個父親可能會有多個孩子，從血緣來看是這樣沒錯，但是有了重疊關聯的方式，孩子也可以認他人為乾爹，故孩子可以有兩個或多個父親。舉實例來說，小明將一項專案拆分成任務 A ~ C，任務 A 的執行者在項目下加入了小任務 a，與 A 任務同樣階層的 C 任務內容有牽涉到小任務 a ，這時就可以搭建 C 和 a 的關聯性。

時間成本計算

OpenProject 有內建計時工具這點令我頗感興致，這項功能主要是來計算每個人實際在一項專案中花費了多少時間。在任務內容頁面的右上角有時鐘 icon 點下便會開始計時，可以針對一項項任務內容計算所花費的時長，最後將一個專案底下的每個任務時間加總得到專案的總時長。此功能如果使用的恰當準確，的確可以了解花費的時間成本，也可以用來推測下個專案的時間安排和人力需求，但是會說使用”恰當”的原因是因為實際操作下來的心得是很常會忘記要去停掉計時XD。

統計圖

在 OpenProject 各個專案的首要頁面 (Overview) 中會顯示專案的基本資訊，像是專案描述、目前狀態、主要成員等資訊，比較特別的地方是 OpenProject 加入了統計直方圖，能快速地從圖中獲取整體資訊。直方圖上方有下拉選單可以選擇有興趣的主題，例如有針對任務狀態的顯示，會去統計並顯示目前待辦、進行中和已關閉的任務數量; 或是要考核個人績效時，選擇任務指派人已完成和未完成的任務數目統計等。

專案的圖書館

在專案的主選單中有 Wiki 的選項。Wiki 在這裡的定位很像維基百科，通常會放置專案中的重要或相關資訊。將細節和冗長的資料從一項項任務內容中獨立出來並彙整成一個資訊庫，再搭配 OpenProject 強大的全文檢索功能，可以說是為專案量身打造的圖書館。這樣的設計理念好處是可以避免需要點進任務中查看一些比較 general 的資訊 (大多是外部參考資料的整理)，並且也方便團隊建立自己的資訊檢索系統。另外，專案的主選單中也有 Documents 的項目，這個頁面適合放置專案的技術文件像是平台架構描述、API 說明文件等資料 (團隊內部產出的資料)。

優點和改善建議

在這個時代，好像優缺點可以直接問 AI 就會有整理好且清楚的表格比較，但是有沒有可能有 AI 沒看到的優點和缺點? 答案肯定是有的，因為切入的角度不同，還有就是人會有實際使用的經驗分享，當然 AI 也可以統整使用者的心得分享，就能從使用者角度切入了。這邊優點和改善建議會是我實際使用在專案管理的想法，以及部分與 Microsoft Azure 的比較，只會比較這兩款是因為我目前有接觸過並且有實際執行在專案上的工具是他們。

優點

• 是開發者也是使用者
  OpenProject Community 這個社群是使用 OpenProject 平台本身，所以在他們專案的 Github 是沒有 Issue 和 Discussion 頁面，因為都是回報到 OpenProject 上。我覺得這點很有意義，因為開發者有實際去使用，所以會直接感受到介面的操作難易度，或是請求回應時間過長等體驗感受，這樣做的好處，一方面是比較不需要一直等待用戶們的回饋，另一方面是團隊成員也會較積極的想去改善自己每天有在使用的工具。
• 支援多國語言
  在軟體的專案中，會有很多遠端開發者，所以很常會遇到不同國家間的協作開發，在這樣的情況下，專案管理工具要能支援多國語言似乎變得格外重要，才能減少不同國家間的協作隔閡。
• 介面友善
  操作介面的友善程度是我本人很在意的事情，在使用過 OpenProject 和 Azure 的介面後，個人偏好 OpenProject 介面以及操作動線。舉例來說，若要添加專案底下的子項目時，我是無法很直覺或直接在 Azure 上找到，相反地，OpenProject 關聯性的添加和移動相對來說直覺很多。
• 搜尋功能和效率
  使用上來說，OpenProject 的檢索功能令人驚豔。OpenProject 除了有基本的篩選器能針對 owner, time, …等項目做過濾以外，他的全文檢索功能使用起來速度很快 (有可能是團隊文件數量不到大量的程度)，而且上傳的附件檔案名稱也會包含在搜尋的範圍之內。不過這項優點在 AI 工具出來後可能競爭性就沒那麼高了。

改善建議

• 多元化輸出格式
  雖然 OpenProject 有支援 markdown 文法的寫入，但下載格式是沒有 markdown 的選項，這點讓人覺得很神奇。OpenProject 的內容輸出格式只有支援 PDF 和 Atom，選擇上來說相當侷限，希望未來有多一些的選項。

  [註解] Atom: 資料格式主要是基於 XML 的一種標準化語法，用於發布和交換資訊，被拿來取代早期 RSS (Really Simple Syndication) 資料格式

• 時間計時更彈性
  文章在核心功能的時間成本計算中，有提到 OpenProject 時間計算的功能，若要計時專案中的項目需要手動式啟用和關閉計時器，但這往往需要使用者養成開關計時器的習慣，不然常常會只記得開啟，然後休息或下班時就忘了計時器還在運作，導致就算頁面關閉了但是計時器並沒有停止的狀況。針對這個功能想建議是不是能在關閉項目頁面時就自動停止計時或是有其他更好的做法。

總結

開源版本的 OpenProject 比較適合有預算考量的中小型或新創公司，雖然在整合第三方資源上沒有那麼多元還有沒有付費版本的備份功能(需要額外建立備份流程)等小缺點，但這個版本提供的功能對小團隊來說其實已經相當足夠。若需要代託管或更進階的功能通常就需要考慮商用版本的 OpenProject 或其他付費工具，因為有付費所以有技術支援、分析報告、多元的角色權限分配和較完整的第三方資源整合，例如跟 DevOps 結合，有些甚至有提供 KPI 指標等進階功能。在挑選工具時，除了文章上提到的挑選方向，最根本的還是先確認團隊的需求，先把需求列出來再做篩選，這樣更容易找到適合團隊的資源。

Reference

OpenProject official document
Installation & operations guide
OpenProject community