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上了，而且都是彼此关联的。
六、其他说明：
- 能否让工具发挥它应有的作用，不是工具本身好不好，关键看使用者是否好好发挥它。
很多团队只是简单的用一下Redmine，Task更新不及时，Wiki组织不当，都反而会让Redmine成为一个累赘。
所以，重点是培养团队的习惯，而不只是学会用Redmine而已。 - 上述优势并不是Redmine的全部，还有很多值得发觉的亮点在，这些只是我亲身带一个团队使用它之后，给我们团队带来的好处。
- 像L这种项目管理的角色，能做的都做好，尽量减少组员不必要的沟通和打断，不能只做个需求传达者，
有些事先想好，然后告诉每个人他们要做的事即可，这样能大大提高团队整体的工作效率，尤其是对程序员这种需要静下心来不被打断的工种，一定要好好呵护。
当然，L还要尽量让组员了解大局，了解为什么，不能让他们认为自己只是个螺丝钉而已，要让他们成为操着整个航母心的螺丝钉
<完>