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

最近朋友咨询我一个问题，说他们公司可能有不少小项目在并行（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，思惟导图  基本能解决极大部分问题~~

一些新鲜，灼热的看法，没有太整理，但愿能对别人有帮助，对本身也是留个记录~~