一、从问题统计看进度风险
从统计来看,近三个星期过去 了,发现了 59 个问题。28 个是性能问题还需要再细分类型,现在这个还是粗了点,比如说配置问题、代码问题。
所以笼统说来除了这里的功能问题之外,其他的基本上都是性能问题,也就是59-11=48个。
从实际工作的感觉上来说,因为是 9 个系统并行的性能实施,也就是说一个系统平均 6 个性能问题。
我再一次统计了系统角度。
显然系统五、六、七、八、九的统计是有问题的,应该是有些问题没有报上来。
考虑了这几个系统,一是因为有一同事负责了其中两个系统,并且还带了一个非常初级的新人,事情经常被打断;二是新人负责的系统根本不知道什么样的问题该报;三是系统九并不在我们团队测试的范围里,现在报出来的问题是其他系统的相关分析中看出来的。
下个星期要多关注这几个系统的具体情况。
其实做管理的分析报表是能看出不少问题的,而从报表中看出来的问题,就需要再细追一层,看是什么具体的原因,再想办法解决。
下周可能要加强这几个系统的技术支持,或许要进行人员调整。
二、项目计划的调整
上一周发现的问题,杂七杂八地分析了一下之后,对整体的项目状态有了了解。就像大部分的项目一样,现在这个项目也是处在混乱的问题爆发期。
从管理流程上看,项目整体计划、团队间协调、配置管理、版本管理、人员调配、风险控制等方面都是存在不同程度的问题的。
上周我也找了客户方高层沟通了一下,他们也是意识到了这些问题,只是百废待兴。
项目是新的不说,各方人员也是新的,所以这些问题出现在各方磨合、项目推进的过程中在主观上是合理的。
上周我也把几个系统的计划后移了几天。
不仅移了单个系统的,也把全链路端到端的性能实施计划后移了。
估计周一会引来一些讨论。
对我来说,没什么可讨论的,如果有问题阻碍了我的实施计划,我就会强制性地往后移。因为之前这个计划已经正式的announce了,并且没有人提出非议。
周五的时候,我跟一个系统的负责人说了问题之后,说会把计划往后移,他觉得是可以压缩性能实施的时间的,所以整体计划不用移。
这样的讨论在我十多年的工作经历中出现了很多次。性能实施也就是在这样的讨论中慢慢地被压缩,直到压缩至体现不出价值走个形式的结局。
如果这个性能实施同样被其他团队的问题或者管理的问题压缩了,那和我之前做的那些失败的项目又有什么区别呢,登时就没了做下去的兴趣,无非是又一个失败的项目。
在我的经历中,有一些项目是我做地觉得非常成功的,计划和进度都在预期之内。
严格地把控项目进度,并不是严格地把握项目计划。计划可以变更,但是具体的工作任务时长被压缩是只能以牺牲质量为代价的。
所以项目管理并不是,给你几个人,给你安排一个目标。就拼死拼活地做出来。在项目中,我看多了这样的不讲理的安排。
三、商务合同带来的实施风险
跟项目组的人员讨论了合同的内容,算了一下,八系统88人天,每个系统的性能实施只有11人天。这合同签得也是没谁了。留下了走过场的隐患。
我见到过不少性能实施的项目是这样安排的,如果不是整个团队都技术超高的,那肯定是项目已经是熟得不能再熟的了。不然这样的合同就是完全的不理智。
而对眼下这个项目中出现这么多问题,是不可能的事情,所以计划的后移也是必然的。
无论如何,项目还是要做下去,项目管理要做的就是把资源、进度、风险都put on table。
我不想自己做过的项目,在上线运维中出现本来应该发现的性能问题,对各方的代价都很大。对自己做的工作也会非常不认可,这种打击会导致对自己和行业的失望。
做过运维也做过性能实施的人都应该有这样的感触。当我们在线发现一个性能问题的时候会抱怨,这么明显的问题性能测试都发现不了吗?要他们干嘛?
而只做性能实施的人,如果不能贯穿前后的思考,也必然会落下这样的把柄。
希望所有做性能实施的人都能让自己的工作体现出该有的价值。