最近朋友咨询我一个问题,说他们公司可能有很多小项目在并行(20个左右),那么产生了下面几个问题
- “救火型”工作模式,一会儿A客户抱怨了,做A项目。一会儿B客户来了,赶紧做一下B项目,典型的被外部客户鞭策着走,也就是被客户控制了项目的节奏。
- 资源调配不过来,开发人员是有限的,做A项目,必然B项目要放下,那么到底做A还是做B呢?
- 到底要不要加资源,加班来处理项目,那么什么时候加资源,怎么加资源,加多少资源呢?
基于上面的描述我给出了,现在最重要的两个图(可视化其实是项目中应该经常考虑的方法,问题暴露了自然能有解决方案,就怕是自己陷入问题之中,而从来不知道问题在哪)
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,思维导图 基本能解决极大部分问题~~
一些新鲜,灼热的见解,没有太整理,希望能对别人有帮助,对自己也是留个记录~~
原文地址:https://www.cnblogs.com/michael703/p/10977636.html