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

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

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

 

posted @ 2019-06-05 09:05  麦克*堂  阅读(...)  评论(... 编辑 收藏