多并行项目管理 -- 多则乱，退一步！让其一目了然！

最近朋友咨询我一个问题，说他们公司可能有很多小项目在并行（20个左右），那么产生了下面几个问题

1. “救火型”工作模式，一会儿A客户抱怨了，做A项目。一会儿B客户来了，赶紧做一下B项目，典型的被外部客户鞭策着走，也就是被客户控制了项目的节奏。
2. 资源调配不过来，开发人员是有限的，做A项目，必然B项目要放下，那么到底做A还是做B呢？
3. 到底要不要加资源，加班来处理项目，那么什么时候加资源，怎么加资源，加多少资源呢？

基于上面的描述我给出了，现在最重要的两个图（可视化其实是项目中应该经常考虑的方法，问题暴露了自然能有解决方案，就怕是自己陷入问题之中，而从来不知道问题在哪）

1. 关于资源的问题，第一反应在我脑海中的就是甘特图（我这个是excel做的，敏捷的思想让我放弃了MS project这样的重量工具），

　　这个图里有有这么几个要素我觉得很重要

　　　　-- 每个格子里需要的资源数

　　　　-- 虚线表示的项目milestone （如6月的那条竖线）

　　　　-- 最下面，资源超载的，颜色警示

　　　　-- 这个资源列表每月review的时候，都生成一个，然后每次在右边写上变动的change log

2. 关于项目是否出现交付的时间问题，那么作为敏捷工作者，release burndown chart第一时间跳出在了我的脑海，每个项目做一个release burndown chart。

每月update一次，这样很容易发现失控的项目了，如下图：就是看actual burn down那条线，是否大大偏离target burn down那条斜线，图一中黄色的4~7月之间项目是有个停滞开发期的，

还好7月份采取了重要措施，让项目回到了正轨，按时发布

3.上面图表用excel来做还算简单，轻量级，也不需要频繁更新，每月一次的项目组大会之前，项目经理更新一下。

（可以分两次会议，一个是项目预备会议，项目组大会上一次展示更新的项目图，并记录问题。第二次会议，基于项目图上的问题，进行逐个讨论）

问题当天讨论不出结果的时候，过一两天随着时间的推移，人一般会有更好的解决方案的。可能是人变聪明了，也可能是在放松的情况下，大脑更活跃。

没有结果的时候，千万不要坐在一起，浪费时间。

4.最后这些图建议都贴墙上，走过路过不会错过。这样大家都知道公司项目的运行情况，以及是否有问题需要帮助.

在问题本来就多，复杂度很高的是否，千万不要再引入复杂流程和复杂工具，来加大项目的复杂度。

excel，ppt ，Visio，思维导图  基本能解决极大部分问题~~

一些新鲜，灼热的见解，没有太整理，希望能对别人有帮助，对自己也是留个记录~~