地球人都知道IT人喜歡自黑。
經過作者的非常不完全統計，99.9%的IT圈段子，都來源於同一個素材——改需求。
比如下面這個：
這麼多關於“改需求”自黑，說明了大家普遍對這件事情感到很無奈。
在如何面對捱罵鏈底端的產品經理一文中，我說過一個事實：
“
需求變更是無法完全杜絕的，因為沒有人能一開始就知道所有事。
”
但這就意味著我們對變更永遠無能為力嗎？
不是。
“
變更雖然無法杜絕，但是是可以管理的。
”
這篇文章將一次性解決所有需求變更的問題：
1. 什麼是需求變更，這篇文章討論的需求變更是哪一類？
2. 需求變更這件事，到底是好事，還是壞事？
3. 我們用什麼態度來面對需求變更?
4. 為什麼需要管理需求變更？
5. 如何高效管理需求變更？
6. 送給大家一個可以拿來就用的需求變更管理流程圖。
7. 行動起來，和變更問題做了結！
1
這篇文章討論的需求變更是什麼？
這篇文章中討論的需求變更指的是，在計劃已經定稿，團隊開始工作之後，所有不在當前團隊的工作計劃中的任務（包括需求）。
包括：
新加入的任務
現有任務的改動
如果是要改動下一個工作週期/階段的計劃，不在這篇文章的討論範圍之內。
如果是在這個工作週期/階段的計劃定稿、團隊開工之前做的計劃的改動，也不在這篇文章的討論範圍之內。
本篇討論的需求變更，僅限於已經排好了計劃，團隊已經開始工作之後，要做本個工作週期中的變動。
2
需求變更這件事，到底是好事，還是壞事？
需求變更可以分為兩類，一類是需求的優化，比如功能優化，性能增強等；一類是需求的往復變更，就是今天要方案A，明天說要改成B，後天又說覺得改成C比較好。
看到這裡，有人會說：
“
我知道我知道！第一類變更是好變更，第二類變更是壞變更！
我還知道，第一類好變更，是優化嘛，改是理所應當的，你怎麼說我怎麼改！
第二類變更，是壞變更，不改不改，還要把產品經理打20大板，不，50大板！
”
以上整個思路表面上是正確的，但是本質卻是錯誤的。
今天早上，我的一個同事問了我一個問題：
“
你覺得什麼是價值？
”
我思考了一下，回答說：
“
價值就是用戶的真正的需要。 如果我們滿足了用戶的需要，我們就創造了價值；反過來，如果我們做了很多事情，但是沒有滿足用戶的需要，我們就沒有創造價值。
”
這兩類的需求變更，無論是需求的優化，還是需求的往復變更，都是為了更好的貼近用戶的真正的需要，所以，這兩類的變更，都是好事情。
所以，
我們的問題不是變更是好事情還是壞事情，也不是該不該變，而是如何更高效的達成變還是不變的決策——即，如何更高效地管理變更。
找到正確的問題，問題就解決了一大半，到現在為止，我們找到了正確的問題了：
如何更高效地管理變更。
3
我們用什麼態度來面對需求變更?
這個問題其實在第2個問題裡已經側面回答過了。需求變更的目的是為了更好的滿足用戶需要，關乎我們創造的價值大小，所以我們要積極面對。
積極面對包含兩部分的含義：一，不牴觸或者反對，二，不迎合和歡迎。而是積極的去管理。
4
為什麼需要管理變更？
如果不管理，就會出現下面的場景：
5
如何高效管理需求變更？
做好下面的6點，就可以高效地管理變更。
1
各個渠道提出來的變更統一提到產品經理。研發團隊只和產品經理對接。
反例1：變更直接提給開發團隊，開發團隊直接被外部多方打攪，不知道哪些做哪些不做，哪些先做哪些後做，就只能打亂仗。
反例2：開發在工作中自己覺得設計不合理，就自行把原來的定義給改了，連產品經理都不知道。最後驗收的時候才發現。
反例3：開發團隊直接接收了一個高管的新加入需求，就憑直覺接受了這個需求去做了，結果造成現階段的交付目標不能按時達成，而這個交付目標是在之前和高層承諾過的。
2
產品經理對變更請求進行初步評估，評估第一個標準是：這個變更是否和本階段的工作目標對齊。
反例1：團隊收到一個和本階段產品發佈目標完全沒有關係的突發奇想。
反例2：團隊收到一個損害本階段產品目標/與產品目標背道而馳的改動建議。
3
產品經理對變更請求進行進一步評估。評估第二標準是：這個變更是否已經定義清晰，清晰的標準是團隊清楚理解需求和解決方案
反例：團隊收到一個還在概念階段（缺乏詳細定義）的新增需求，邊開發邊澄清需求和返工，造成本階段工作目標受到嚴重影響。
印象派作品《日出》
4
產品經理進行初步評估後，變更請求需要團隊各方代表進行評估
是否接受變更，至少需要團隊的各方代表，包括開發代表，測試代表，運維代表進行統一的評估。如果是屬於產品目標的變更，同時還需要投資人，用戶代表，和業務方代表參與評估。
反例1：一個項目干係人提出了一個重要的需求，這個需求需要完全地改變本階段的工作目標，團隊在沒有向投資人請示的情況下接受了這個變更，導致最後無法滿足投資人對本階段團隊工作的期待。
反例2：變更請求未通過團隊各方代表評估，直接提給開發去開發，最後交付運營才發現性能無法滿足要求。如果在評估的時候就請包括運營代表在內的各方代表評估，就可以在開始開發之前有更周全的考慮。
5
產品經理可以提建議，但是由研發團隊代表（開發代表和測試代表）負責最終決定是否接受該變更（進入本次迭代）
理論支持：《Scrum指南》，團隊是迭代待辦列表的Owner。
反例：產品經理說要改，團隊就要無條件接受，產品經理說要加需求，團隊就要無條件加班完成。導致範圍蔓延，交付延期。
6
如果研發團隊接受變更請求，研發團隊可以選擇同時請產品經理從當前迭代待辦列表中移除同樣工作量大小的待辦項，產品經理需要按照研發團隊的要求進行移除，移除哪些待辦項由產品經理決定。
理論支持：《Scrum指南》，團隊是迭代待辦列表的Owner。
反例：研發團隊接受了很多變更，沒有提出移除的請求，造成團隊常態性加班，帶來產品質量風險和團隊士氣低落。
6
最後，免費送給大家一個需求變更管理的流程圖
需求變更管理流程圖
關注本文插畫中的_號， 發送“變更”就可以啦！
7
行動起來，和變更問題做了斷！
團隊成敗，匹夫有責。如果你認同本文的變更管理理念和方法，也希望優化你的團隊現有的變更管理流程，你可以做下面的行動：
行動指南
1. 下載第6步的變更管理流程圖；
2. 將本文發到你的團隊群裡，請大家閱讀;
3. 組織一個正式的會議，邀請大家對這個主題進行討論，可以展示下載的變更管理流程圖請大家參考；
4. 形成你們團隊自己的變更管理方案。
祝你成功！
嗨，我是敏捷教練珍妮,
前微軟亞洲搜索技術中心卓越工程顧問,
我的目標是幫助所有IT人更輕鬆地做軟件！
如果你是IT人，想要高效工作，按時下班，工資翻倍，歡迎關注我喲！
