本文章轉載于搜狗測試

前言

在整個測試過程中，大家應該或多或少都遇到過”需求變更“，“項目一旦啟動，變更也就隨之而來。”變更是無法避免的，作為一個合格的項目管理者，我們應該用有效的方法來管理需求變更。

先看幾個情景：

情景1：需求變更沒有通知到測試，也沒有更新需求文檔。

開發(fā)都寫完代碼了，測試接手測試時發(fā)現(xiàn)和需求文檔完全不一樣或者有很大出入，找產品確認的時候，產品同學才告知說需求有變更，和開發(fā)說了，忘記和測試說了。

情景2：需求新增量大，超出版本排期。

在開發(fā)階段或者測試階段，產品覺得策略或者方案不是特別好，就對其中一些策略進行了調整，導致開發(fā)和測試工作量驟增，直接影響到版本的發(fā)布。

情景3：來自于不同源頭的需求變更。

設計端的需求新增、運營端的需求新增，需求較多，且來源渠道不同，如果管理不當，就容易出現(xiàn)遺漏的情況。

情景4：在測試一輪都快要結束的時候，發(fā)生需求變更，測試和開發(fā)都措手不及。

需求變更是為了讓產品更完美，策略更優(yōu)化，所以我們接受合理的需求新增。那么，為了讓項目高效運行，我們今天就針對”需求變更“，梳理一下對應的流程規(guī)范和相關的文檔。

發(fā)生需求變更后，我們的處理過程大體是以下幾步：

第一步：需求變更的原因分析&成本評估

目的，也是對本次需求變更的優(yōu)先級和影響范圍進行評估，具體請參考上一篇《“你不得不知道的流程規(guī)范“@需求的優(yōu)先級排期》

在軟件測試流程中，需求變更建議三方溝通，即測試、開發(fā)、產品同時對需求變更內容和影響范圍進行評估，達成一致。

要注意需求變更發(fā)生的時機：

①項目開始前

在項目開始前發(fā)生需求變更，因為各配合團隊還處在資源準備、需求理解、策劃方案的階段，需求變更帶來的影響較小，是比較容易控制的。

②項目進行中

我們大部分的需求變更都是發(fā)生在項目進行過程中，這樣就要嚴格遵循本文的流程規(guī)范處理。

③項目將要結束前

因為項目已經接近尾聲，開發(fā)和測試工作基本告一段落，特別是測試已經經過完整的測試流程，如果在這個時候發(fā)生需求變更，很有可能導致開發(fā)代碼有較大的變動，測試也需要重新評估改動帶來的測試范圍和影響。工作量增加，質量出現(xiàn)風險。所以不建議在項目將要結束前進行需求變更，甚至可以要求在二輪測試之后，不允許需變。

第二步：提出需求變更

在三方達成共識后，由產品同學提出變更，提出變更有2個要求：

（1）項目相關人員周知

小編現(xiàn)在所在的搜狗手機輸入法項目，需求變更郵件規(guī)范，內容詳盡。借此，向各位同學簡單介紹下需求變更郵件的內容：

（此郵件會發(fā)送給相關開發(fā)和測試，并抄送整個項目大組、項目管理同學知曉。）

（2）變更內容清晰明了

具體需求文檔的規(guī)范請參考《"你不得不知道的流程規(guī)范"@需求文檔規(guī)范》。當發(fā)生需求變更時，產品同學應該將對應的需求文檔更新，特別是在文檔最前寫明變更記錄：

第三步：實施需求變更

到具體實施階段，就按照接到需求→排期→測試的流程進行。

第四步：項目排期變更

如果需求變更影響到項目排期，項目管理人員應該及時更新項目排期/進度匯報（最好在郵件中紅色標注delay或者延期的字樣），發(fā)郵件通知各方配合團隊周知。

總結環(huán)節(jié)

一件事情做完后無論成功與否，坐下來把當時預先的想法、中間出現(xiàn)的問題、為什么沒達成目標等因素整理一遍，在下次做同樣的事時，自然就能吸取上次的經驗教訓。這就是復盤。我們應該對每次需求變更進行復盤，精益求精：

（1）是否能盡早提出需求變更

（2）需求變更帶來了多少工作量，成本如何

（3）需求變更是否達到了預期