一、从问题统计看进度风险

从统计来看，近三个星期过去 了，发现了 59 个问题。28 个是性能问题还需要再细分类型，现在这个还是粗了点，比如说配置问题、代码问题。
所以笼统说来除了这里的功能问题之外，其他的基本上都是性能问题，也就是59-11=48个。

从实际工作的感觉上来说，因为是 9 个系统并行的性能实施，也就是说一个系统平均 6 个性能问题。

我再一次统计了系统角度。

显然系统五、六、七、八、九的统计是有问题的，应该是有些问题没有报上来。
考虑了这几个系统，一是因为有一同事负责了其中两个系统，并且还带了一个非常初级的新人，事情经常被打断；二是新人负责的系统根本不知道什么样的问题该报；三是系统九并不在我们团队测试的范围里，现在报出来的问题是其他系统的相关分析中看出来的。
下个星期要多关注这几个系统的具体情况。
其实做管理的分析报表是能看出不少问题的，而从报表中看出来的问题，就需要再细追一层，看是什么具体的原因，再想办法解决。
下周可能要加强这几个系统的技术支持，或许要进行人员调整。

二、项目计划的调整

上一周发现的问题，杂七杂八地分析了一下之后，对整体的项目状态有了了解。就像大部分的项目一样，现在这个项目也是处在混乱的问题爆发期。
从管理流程上看，项目整体计划、团队间协调、配置管理、版本管理、人员调配、风险控制等方面都是存在不同程度的问题的。
上周我也找了客户方高层沟通了一下，他们也是意识到了这些问题，只是百废待兴。
项目是新的不说，各方人员也是新的，所以这些问题出现在各方磨合、项目推进的过程中在主观上是合理的。
上周我也把几个系统的计划后移了几天。

不仅移了单个系统的，也把全链路端到端的性能实施计划后移了。
估计周一会引来一些讨论。
对我来说，没什么可讨论的，如果有问题阻碍了我的实施计划，我就会强制性地往后移。因为之前这个计划已经正式的announce了，并且没有人提出非议。
周五的时候，我跟一个系统的负责人说了问题之后，说会把计划往后移，他觉得是可以压缩性能实施的时间的，所以整体计划不用移。
这样的讨论在我十多年的工作经历中出现了很多次。性能实施也就是在这样的讨论中慢慢地被压缩，直到压缩至体现不出价值走个形式的结局。
如果这个性能实施同样被其他团队的问题或者管理的问题压缩了，那和我之前做的那些失败的项目又有什么区别呢，登时就没了做下去的兴趣，无非是又一个失败的项目。
在我的经历中，有一些项目是我做地觉得非常成功的，计划和进度都在预期之内。
严格地把控项目进度，并不是严格地把握项目计划。计划可以变更，但是具体的工作任务时长被压缩是只能以牺牲质量为代价的。
所以项目管理并不是，给你几个人，给你安排一个目标。就拼死拼活地做出来。在项目中，我看多了这样的不讲理的安排。

三、商务合同带来的实施风险

跟项目组的人员讨论了合同的内容，算了一下，八系统88人天，每个系统的性能实施只有11人天。这合同签得也是没谁了。留下了走过场的隐患。
我见到过不少性能实施的项目是这样安排的，如果不是整个团队都技术超高的，那肯定是项目已经是熟得不能再熟的了。不然这样的合同就是完全的不理智。
而对眼下这个项目中出现这么多问题，是不可能的事情，所以计划的后移也是必然的。

无论如何，项目还是要做下去，项目管理要做的就是把资源、进度、风险都put on table。
我不想自己做过的项目，在上线运维中出现本来应该发现的性能问题，对各方的代价都很大。对自己做的工作也会非常不认可，这种打击会导致对自己和行业的失望。
做过运维也做过性能实施的人都应该有这样的感触。当我们在线发现一个性能问题的时候会抱怨，这么明显的问题性能测试都发现不了吗？要他们干嘛？
而只做性能实施的人，如果不能贯穿前后的思考，也必然会落下这样的把柄。

希望所有做性能实施的人都能让自己的工作体现出该有的价值。