系统部署交流会上，项目经理们共享的一些心得体会

场景一：

培训过程中，询问了各位项目经理关于Hotfix与ServicePack的区别，除了时间计划性不同以及部署增量方式的相同外，其实还有一点就是ServicePack往往还包括针对一段时间用户报障或者自身发现的缺陷的集合，详细见《业主说我们项目经理上线很随意，“爱发就发”！》。在场有不少项目经理对这个问题不是很理解，其实换一个角度去理解这句话就非常简单了：

 

如果你做的东西是一个产品，可以销售给多个客户，在市场上有多份拷贝。假如用户A给你汇报了某一个故障，你决定针对用户A使用到的功能进行Hotfix，但是此功能对其他用户来讲，他们还没有使用到或者暂时没有此情况发生，那么是否以往其他用户没有存在此故障隐患呢？结果当然不是，所以需要有计划性地给用户发放ServicePack，将包括在一段时间内用户的报障与自身发现的缺陷一起打包发放。

当然，做产品你得负责任，三鹿的婴幼儿奶粉就像你在市场上发放了产品的很多拷贝，可不是靠发放ServicePack能够解决的！

 

场景二：

前两周进行的系统部署培训交流会，会上最后一个部分是各个项目经理交流以往在部署方面的感触和体验，项目经理举了在实践工作中，让他们自己感触很深刻的部署实际案例：

1. 项目经理A：给系统部署Hotfix中，冲突分析很重要。详细见《生产环境出现Bug，应该如何部署Hotfix？》一文中的第5步骤。的项目在部署Hotfix时，只进行了功能分析，但是缺少性能分析，导致在Hotfix上线后的第一天出现IT系统的数据服务器负载过重而Shutdown的故障；
2. 项目经理B：冲突分析非常重要，项目经理B举了他负责的项目中，由于对Hotfix考虑不到，导致部署Hotfix之后，再针对Hotfix进行Hotfix，导致用户对系统的信任度下降；
3. 项目经理C：部署Hotfix时，需要明确Hotfix部署列表以及相关的影响。在C的项目中，功能存在问题，用户投诉，后来经过分析，需要进行功能修订，不仅修改Web代码，还需要对Table修改，增加一个列，以为问题不会很大，结果部署到生产系统上发现了问题，忽略了Table还有Trigger，而Trigger中还有逻辑处理；因此部署过程也很重要，如果Hotfix列表已经在测试系统上验证，就不用等到上了生产环境才发现问题；
4. ...

分析：

项目经理们不约而同而向我们培训讲师询问，如何更好地进行冲突分析？

对于这个问题，最好的答案就是CMMi管理体系上的功能跟踪矩阵。一个需求，影响那些功能，在那些代码实现，涉及到那些后台的Table和逻辑，用那些测试案例来测试这个功能，都在跟踪矩阵中展现，如果我们在整个过程管理中，一直清晰地维护着功能跟踪矩阵，那么进行冲突分析，不就是查一查这个Excel表吗？