在項目開發中，存在的無數的任務分解，問題管理，流程跟蹤。因為直接說話或者直接在IM里喊話是很容易的，所以在一個還沒有習慣使用issue管理軟件的團隊中，直接說話或者直接在IM里AT，就在某些時候變成了主要的任務通知渠道。
就像為什么我們不能用IM傳遞代碼給別人，讓別人覆蓋到自己項目里一樣。事實上我們應該擯棄那種把任務分解和任務跟蹤用IM這種方式“便利”通知的方式。思考一下，如果你在程序里寫一個任務調度系統，你會嚴格的設計任務調度系統的管理器、隊列、排序、優先級、執行時許等等。可是到了項目開發這種“人”來做的事情，你卻放棄了這種編程的思維。轉而依賴那種非結構化、不能歸類、不能分發、不能同主題討論、不能打標記的IM來做，豈不是很蠢？
怎樣才能在一個team里有效使用上issue管理軟件？一個充分條件是項目的管理者要主動沖在前面使用。無論成員會不會覺的習慣，如果項目的管理者強化使用issue管理來創建、分發、討論、跟蹤、消滅項目開發中的任務分解、問題管理、流程跟蹤，那么issue管理軟件就被有效使用起來了。可以假設的是每個成員只能有精力關心自己的那部分任務、問題，而無暇關注其他部分。所以項目管理者需要對issue做持續的跟蹤、復審，把握整體的進度和質量，及時發現風險和問題，並給予必要的重點關注。
選擇怎樣的issue管理軟件？有一種看法認為隨便選一個就好了。其實這只是一種主觀上的看法，有的人自己從來沒有成功使用成issue管理，就認為用什么都一樣，沒差別。如果是這樣的話，為什么源代碼管理軟件需要從cvs、svn、到git一直演化下來？如果是這樣，為什么issue管理軟件人們還需要一直開發更好用的？使用好的軟件不是為了趕時髦，而是人沒必要跟機器過不去，我們人的精力是最寶貴的，不應該在不知不覺中變成“沒效率”，把996當作是一種自然而然的必須。
基本上，如果你覺的git是有必要和自然而然的。也就應該覺的issue管理軟件應該是有必要和自然而然的。你覺的不想用cvs，應該用git。那么也應該覺的應該要用現代一些的issue管理軟件，而不是覺的無所謂，隨便用一個老掉牙的。
@寶玉 補充了下面三個明顯的issue管理的好處：
- issue是有生命周期的
- issue是可跟蹤的
- issue是有優先級的
為什么要用工具，因為工具已經把重要的東西“編程”進去了。
--end--