場景一：
培訓過程中，詢問了各位專案經理關於hotfix與servicepack的區別，除了時間計畫性不同以及部署增量方式的相同外，其實還有一點就是servicepack往往還包括針對一段時間使用者報障或者自身發現的缺陷的集合，詳細見《業主說我們專案經理上線很隨意，「愛發就發」！
》。在場有不少專案經理對這個問題不是很理解，其實換乙個角度去理解這句話就非常簡單了：
如果你做的東西是乙個產品，可以銷售給多個客戶，在市場上有多份拷貝。假如使用者a給你匯報了某乙個故障，你決定針對使用者a使用到的功能進行hotfix，但是此功能對其他使用者來講，他們還沒有使用到或者暫時沒有此情況發生，那麼是否以往其他使用者沒有存在此故障隱患呢？結果當然不是，所以需要有計畫性地給使用者發放servicepack，將包括在一段時間內使用者的報障與自身發現的缺陷一起打包發放。
當然，做產品你得負責任，三鹿的嬰幼兒奶粉就像你在市場上發放了產品的很多拷貝，可不是靠發放servicepack能夠解決的！
場景二：
前兩周進行的系統部署培訓交流會，會上最後乙個部分是各個專案經理交流以往在部署方面的感觸和體驗，專案經理舉了在實踐工作中，讓他們自己感觸很深刻的部署實際案例：
專案經理a：給系統部署hotfix中，衝突分析很重要。詳細見《生產環境出現bug，應該如何部署hotfix？
》一文中的第5步驟。的專案在部署hotfix時，只進行了功能分析，但是缺少效能分析，導致在hotfix上線後的第一天出現it系統的資料伺服器負載過重而shutdown的故障；
專案經理b：衝突分析非常重要，專案經理b舉了他負責的專案中，由於對hotfix考慮不到，導致部署hotfix之後，再針對hotfix進行hotfix，導致使用者對系統的信任度下降；
專案經理c：部署hotfix時，需要明確hotfix部署列表以及相關的影響。在c的專案中，功能存在問題，使用者投訴，後來經過分析，需要進行功能修訂，不僅修改web**，還需要對table修改，增加乙個列，以為問題不會很大，結果部署到生產系統上發現了問題，忽略了table還有trigger，而trigger中還有邏輯處理；因此部署過程也很重要，如果hotfix列表已經在測試系統上驗證，就不用等到上了生產環境才發現問題；
...
分析：
專案經理們不約而同而向我們培訓講師詢問，如何更好地進行衝突分析？
對於這個問題，最好的答案就是cmmi管理體系上的功能跟蹤矩陣。乙個需求，影響那些功能，在那些**實現，涉及到那些後台的table和邏輯，用那些測試案例來測試這個功能，都在跟蹤矩陣中展現，如果我們在整個過程管理中，一直清晰地維護著功能跟蹤矩陣，那麼進行衝突分析，不就是查一查這個excel表嗎？
準備測試交流會
應朋友的要請，20天之後要去他們公司做一次測試交流會。第一天，收到朋友的 答應要去。並請朋友幫忙收集他們公司的測試部同事關心的問題 第四天，收到朋友的mail，列出了交流會要討論的問題如下 1.測試用例設計及測試用例優先順序和類別的劃分 2.測試工具的引入 3.測試過程管理 4.測試人員的職業發展 ...
常大佬交流會
二 大學裡面可以選擇的兩個方向 三 個人感想 這個對我們大學生來說已經晚了，沒做過多介紹 1 這種辦法是一種嘗試的人不多，但是相比讀完整個大學以後再申請國外留學要有優勢 的方法，具體原因如下 2 這種出國會遇到的問題 3 這種方式出國所帶來的回報有？1 這是大多數有出國意願的人會選擇的道路，需要提早...
談談專案部署交流會的體會
今天早上給同事培訓了專案部署的一些實踐經驗，並且邀請了上個星期進行系統部署的專案組給大家介紹案例。經過培訓，我發現來參加培訓的同事其實都還沒有讀過或者仔細讀過我的寫過的關於部署的blog，我今天的培訓都圍繞這兩個帖子展開。我看到有不少部門經理來詢問下週什麼時候再培訓，他們還會再安排人員來參加，其實，...