简单的说，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还要尽量让组员了解大局，了解为什么，不能让他们认为自己只是个螺丝钉而已，要让他们成为操着整个航母心的螺丝钉。