簡單的說，Redmine是個項目管理軟件。
如何降低溝通成本、如何規避開發風險、如何壓縮項目人力？
這些問題看似高屋建瓴，實際上都不是非高手不可觸及的。
假設有一個研發團隊，L是老大，他負責接入需求並安排任務。
一、分配任務
L理解某波需求后，會拉上相關人討論，講一下為什么做，做成什么樣，怎么做。
會后，經常有不清楚的、不理解的、有矛盾的問題會問到L，L的時間就這么被碎片化的浪費掉了。
而且，那些討論出來的實現思路、設計方法，以及之后瑣碎問題及答案都沒有被記錄了下來，
日后需要回顧的時候，只能靠腦子回憶，或者找人幫你回憶了。
不管對於L來說，還是對組員們來說，需要一個地方記錄下這些事，無論是當時還是半個月后，總會有用到的時候。
用Redmine的話
L理解需求后，創建Task及其子Task，並指派給相應的人，在Task描述上寫清楚任務內容。
相關人會收到任務通知，查看任務內容后，對不理解的、有疑問的地方進行回復詢問，然后等待L回復解答。
無論時隔多久，大家都可以檢索到什么時候做了什么事、遇到哪些問題、當初的設計思路是什么等內容。
二、任務跟蹤
L答應產品經理說xx時間點完成項目，所以他要清楚每個人是否能在這個點之前完成任務，而且要時不時的問一下每個人完成進度如何。
組員對於L來說往往是個黑盒，往往只有在任務完成或者要延期時，盒子才會被打開，才能知道，哦~完成了呀，或者，哦？為什么延期？
L無法做到及時的延期風險控制，真的非常不專業。
用Redmine的話
組員每天下班前更新自己的任務進度，登記工時，並寫上今天完成的內容。
L可以隨時看到這些進度和任務內容，通過項目甘特圖，就能及時發現風險並對其進行事先規避。
三、周報
L需要每周對上匯報團隊工作進度，所以他也要求組員們每周都要發周報給他。
可是組員們對寫周報真的很反感，每次都要努力的回憶這周做了什么，還要計算好工時，不能讓L覺得自己偷懶，必要的時候還要編一點。
用Redmine的話
因為每天的工作有TASK記錄，並有工時記錄，所以周報只需要點幾下鼠標就能導出了，上邊有本周詳盡的工作內容以及消耗的工時。
四、線上操作
線上系統的升級、維護、事故處理等都需要嚴格的執行步驟，特別是與錢有關的關鍵服務，都要謹慎處理。
但是經常會有人馬虎大意，不是忘記這個就是忘記那個，一不小心，公司就損失了xx萬，執行人可能會被批斗一頓，L也會被要求加強流程管理。
領導說的輕松，一句我們要有流程呀，L就要好好想想了，怎么保證不出錯呢？
用Redmine的話
線上操作的執行人創建一個TASK，寫清楚操作的目的，步驟，以及每一步的check方法。
寫完后他需要找另外一個人進行review，檢查步驟是否合理，是否有遺漏，有問題就回復拋出建議，沒問題就回復review通過。
通過后執行人才可以執行，關鍵步驟最好也讓審核人在旁邊看着操作，完成后讓審核人檢查執行結果。
這樣做到了至少雙人的double check，而且線上操作的TASK記錄了操作的整個過程，一旦出現問題，回顧以及追責都是非常方便的。
五、項目Wiki
Word、PPT、PDF、郵件，寫文檔、發文檔、更新文檔，要不要這么麻煩！
我們需要一個集中的、有層次的、方便分享的文檔管理工具，那就是Wiki。
Redmine的Wiki本身的優勢並不大，但是一個明顯的好處是它和項目、版本、甚至具體TASK結合在一起。
比如在某個Task中需要出一個小文檔，那就可以寫一個Wiki頁面，並附在Task中，反過來依然可以。
就像自從超市有了燈泡賣，就不用非要去五金店買了，你要的，都在Redmine上了，而且都是彼此關聯的。
其他說明：
1. 能否讓工具發揮它應有的作用，不是工具本身好不好，關鍵看使用者是否好好發揮它。
很多團隊只是簡單的用一下Redmine，Task更新不及時，Wiki組織不當，都反而會讓Redmine成為一個累贅。
所以，重點是培養團隊的習慣，而不只是學會用Redmine而已。
2. 上述優勢並不是Redmine的全部，還有很多值得發覺的亮點在，這些只是我親身帶一個團隊使用它之后，給我們團隊帶來的好處。
3. 像L這種項目管理的角色，能做的都做好，盡量減少組員不必要的溝通和打斷，不能只做個需求傳達者，
有些事先想好，然后告訴每個人他們要做的事即可，這樣能大大提高團隊整體的工作效率，尤其是對程序員這種需要靜下心來不被打斷的工種，一定要好好呵護。
當然，L還要盡量讓組員了解大局，了解為什么，不能讓他們認為自己只是個螺絲釘而已，要讓他們成為操着整個航母心的螺絲釘。