為什麼要用Redmine來管理專案？

歷程

只要是研發性質的工作，必然會有大量的實驗過程。這些過程都是需要花時間建構環境，執行測試，驗證結果，再迴歸分析假設的。很多人都知道這些經驗很重要，所以會花時間去製作文件，把這些重要的資訊給留存下來。你或許會想，這樣不就解決問題了嗎？只要記得把最終的結果記錄下來就行了，中間的過程記它們做什麼呢？

我想有些在業界打滾夠久的讀者就會知道，這是非常理想化的假設。在萬物連網的未來，基本上不會再有”離線”的產品了。許多專案一執行就沒有「結案」的時間，一年365天全年無休的都會有新的feature要做，有新的bug要修，有新的環境要測試，有新的相容性問題要處理。

一整天下來，別說是判斷什麼是「最終的結果」了。很多時候你會連「這是不是個問題？」都很難判斷。而且更糟的是，這種事情通常不怕一萬，就怕萬一，那”一次”你認為沒什麼，不用多想的問題，有時會搞到你在睡夢中都在想解法。

你以為只有軟體需要煩這件事嗎？編導不記下討論的結果，不留下開會的決議，就會在改來改去的規格中喪失熱情及思考能力，這樣的遊戲怎麼會好玩呢？美術不把畫過的設定，線稿，特效試做的中間產物留下來的話，之後要怎麼面對每個人的「我覺得」這種主觀問題呢？5個人會有10種審美主觀，若沒留下記錄，大家都會忘記自己是怎麼同意美術風格的。

當大家習慣每天就像寫Blog一樣，覺得應該寫，值得寫，最好寫下來的事情，都在Redmine上的時候，這些歷程就是最好，也最重要的文件。

或許你會說，在mail上的討論不就是歷程的記錄嗎？是沒錯，但這就是用Redmine的第二重要理由，也就是「同步」。

同步

根據每個工作者的領域及職務內容不同，大家接觸的媒體及主題差異自然很大。軟體要找編導討論規格，編導要找美術確定風格，專案負責人要找技術總監瞭解可行性，美術總監要找軟體確認效能…大家的mail會有所有的訊息，但卻沒辦法同步給「有需要」的人。

A和B討論的內容，C過一個月後才會想知道，他不會收到mail；B和C決議的做法，其實需要D的配合，但他們不知道，所以D不會收到mail； 專案運行到一半人手不足，調了一位E來支援，當然他也不會收到之前大家討論的mail。這些沒收到mail的人，要怎麼找到他需要的資訊呢？他們可以叫大家把自己討論過的mail都轉一份給他嗎？我想他自己都不願意😅…更別說這位苦主，其實並沒有辦法去”搜尋”其他人的mail，看看有沒有他需要的資料。

當大家習慣在Redmine上討論事情的時候，這些記錄集中到這個系統中，對每個人而言，就沒有同步的問題了。因為透過搜尋或瀏覽，每個人都可以很輕易的找到重要的關鍵資訊(還是那句老話：如果有寫的話…)，或是很清楚的瞭解每個結論的來龍去脈，大家不用從公私不分的mail整理出重要的業務訊息，只要去Redmine搜尋就好。

如果你的團隊人數夠多，多到你已經沒辦法理解他們在做什麼，你只想瞭解是否還有人有空能做些什麼😛，那你就值得花點時間來理解Redmine能怎麼解決你的問題，滿足你想搾乾每個工作者的需求。也就是第三個很重要的理由：篩選器。

篩選器

Redmine原生就支援，把工項以清單或是以甘特圖的型式顯示的功能。透過各種不同欄位來篩選，很容易就可以看出，現在每個工作者負擔的工作有哪些，優先權高不高，時程排到什麼時間等等。所以若是懂得怎麼使用篩選器(filter)，可以輕易的排出像是「本週xxx的工作中，有多少人投入，都在作新功能還是都在除錯？」這類的人力資源的使用表，而且是看你需求可加減欄位，複合起來一起搜尋整理出來的。

這裡有一個很重要的觀念是：「用戶自己排出來」的篩選器。

我自己的經驗是，隨著專案持續運行，再加上時常天外飛來，不只一筆的插件急單，所有的人員倒底都在忙什麼，若沒有Redmine這樣的系統，讓我依據當下的狀況，設置篩選器去篩出我需要的資料，我真的是得一個個詢問才能有個全盤影像。那種預先寫好的「功能」，通常不見得能應付得了剛剛提的那種實務狀況。

雖然Redmine也有它的設計限制，不一定總是能滿足你的需求，但是它開源，你願意的話可以自己動手解決問題。不然它的插件也很多，不管是免費的，或是花點小錢就能解決問題，都遠比你的時薪便宜許多。

最後一個，也是一開始最不容易見到成效，但卻是最無庸置疑的理由，就是「累積」。

累積

電玩產業也是一個科技產業，共同的一個特色就是變化非常的快，伴隨而來的就是組織內的分工及配置也會變動的非常快。這個月A小組的人還在做產品的feature，下個月可能就要跑去支援B團隊的人趕產品上架。當人員在各團隊間移轉，我們要怎麼樣確保他們的移轉成本降到最低，到新的團隊，做新的產品，馬上可以上工，學習成本越低越好？

這個問題通常沒有什麼銀彈，答案只有一個，就是紮實的文件化。

如同一開始就講到的事情，要期待每個在前線營運的團隊，騰出時間去寫文件，是不切實際，不食煙火，不懂行規的期待。唯一能期待的，也是唯一能做得到的，就是要求團隊成員，將每天重要的研發歷程或是結論，好好的在Redmine中寫下來。不用花心思排什麼版，有需要的前提下簡單畫個圖就行，不是要做簡報。

人員在不同團隊的移轉，基本上都是要求要能馬上上戰場的。可整個專案的每個規格，每個細節，背後的來龍去脈到底是為什麼這樣設計，如果有人願意回答，那當然很好。若沒人有辦法回答(不管是因為沒空，不懂，還是不想…)，那最後一道防線就是Redmine的工項的那些歷程記錄了。或許不是多正式的文件，但要摸出設計脈絡，光看歷程紀錄就可以八九不離十了。

我常跟團隊成員講，Redmine Notes要寫到什麼程度？只要寫到你3個月後再回來看，你還知道你在寫什麼就可以。但其實我覺得還不夠，最好的是你寫的可以讓身邊的工程師也可以看得懂。這樣哪天你突然發生車禍需要住院休養時，你的工作別人才可接手繼續執行，整個專案才不會因為一個人的失能，而造成整個專案也一併失能。

就像複利效應一樣，每個人每天寫，一個專案寫過一個。不僅在職務交接的磨擦力降到最低，在知識傳承的深度也越修越精煉，你的團隊在經過幾個大案子的累積後，呈現出來深厚的技術底蘊就會讓其他團隊嘆為觀止。

整理到這裡算是告一段落了，為什麼要Redmine來管理專案，我想還有很多理由是不容易馬上整理出來的。但大方向很明確倒是真的：這不是「一個人的武林」，不管是封于修還是夏候武，都要有隨時把身上工作交出去的思維及心態。大家都會說要Team Work，都會說「我們是一個團隊」。比起這個，我比較喜歡說，我們是為每一天負責的知識工作者。