在项目开发中，存在的无数的任务分解，问题管理，流程跟踪。因为直接说话或者直接在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--