系統部署交流會上，專案經理們共用的一些心得體會

情境一：

培訓過程中，詢問了各位專案經理關於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表嗎？