本文章轉載于搜狗測試
周六送福利已經進行三期了，現已到尾聲，大家還記得我們約定的四個階段嗎：
“項目進度”尾篇：不慌不忙應對突發狀況
引言
前幾個周六，我們了解了怎么做項目計劃，但是執行過程中，除了在項目前期盡可能的預估并屏蔽所有風險以外，總不可避免的仍然會出現計劃變更，突發風險，突發任務，該怎么處理呢？該怎么處理呢？該怎么處理呢？（重復三遍以形容我心亂如麻）
項目中，接觸計劃變更，突發風險的第一線人員是模塊負責人，因此，模塊負責人對突發狀況的處理直接關系著進度能否合理delay，抑或連滾帶爬的保持正常，以下主要從兩方面對這個問題進行討論
① 當模塊負責人意識到計劃變更以及風險
② 項目負責人接到突發任務
項目計劃變更和突發風險
執行項目期間，進度和質量是整個測試組的最重要的兩個指標。模塊負責人在執行任務的過程中，如有對項目進度產生影響的問題（影響項目進度的問題），應該第一時間主動進行推進，并將推進結果同步項目負責人
模塊負責人說坑：怎么判斷什么是影響項目進度的問題？
小編曰：分三個階段來說
第一， 一輪測試執行時，雖然時間充裕，也應把握前緊后松原則，如遇到下面的問題，應引起足夠的重視并立即進行推進，千萬不能等著，否則到后期只能是壓縮測試時間（若推進無果時，可反饋給項目負責人）。另外，對于影響進度的問題則第一時間同步項目負責人，以便及時調整計劃
①阻塞模塊負責人繼續執行任務的（有其他任務可以置換的略過）
例如：未提測的；阻塞bug導致不能繼續執行的；沒有需求文檔的；沒有設計圖的，……
②有風險可能導致模塊負責人執行任務不順利的，會拉長測試周期的，
例如：分批提測（因為分批測試完后，還需要時間將分批的功能進行聯調測試）；bug修改影響范圍很大的……
③任務進行三分之一時，實際進度和預計進度不符（說明delay原因與后期的方案安排）
第二，回歸測試執行時，測試人員對于bug的判斷角度和產品可能不一樣，但是bug是否修改是以產品為準，因此，對于不能準確把握的“是否修改的問題”應第一時間與產品同步，如需修改，再及時同步給項目負責人，以便及時調整計劃
第三，回歸測試階段應屬于穩定階段，嚴格把控此階段修改的bug帶來的影響，如影響范圍較大的，引發新問題的，應該第一時間告知項目負責人（bug修改范圍太大可能導致回歸范圍變大，已經完成的入口測試重新回歸），再向項目組人員同步
突發任務
模塊負責人的突發任務一般來自于項目負責人，項目負責人說：好不容易和大家核對好各自的任務，剛才開發（產品）說要修改個邏輯，然后。。。又被打亂了
小編曰：
執行項目期間，由于各種原因，可能臨時插入其他任務
例如：緊急修復線上問題，后臺優化接口等等。當項目負責人接到如下任務時，建議從以下3方面著手
1. 先了解需要提測的是什么事情
2. 了解提測這個功能的目的（解決什么問題？為什么突發而不是順延進行排期）
3.如是早有計劃的任務，和對方約定，提前多長時間告知測試以便測試同學排期
4.和對方咨詢事情的優先級，并和手頭上的事情的優先級做對比
5.評估優先級后，想出后續的解決方案并和leader同步；如不能確定優先級的，則和項目組人員（產品leader，開發leader）進行確認，再同步leader
①如果可以插入該臨時任務，需要和項目組人員同步正在執行的任務會出現相應的delay，并同步更新進度列表并公示項目租
②如果順延該臨時任務，則需要和項目人員同步該任務的預計執行時間是哪天，以及完成時間是哪天
結語：如果是正常版本的迭代，可將第一個版本在執行期間出現的突發狀況一一記錄，在第二個版本前期排粗略計劃時提前進行規劃也是減少突發的一種方法
寫在最后
祝大家周末愉快~
