對於軟件開發領域來講，變更始終是最讓人頭疼的東西，大家對於如何消除變更，如何控制變更，提出了很多很多的理論與方法。無奈變更這東西就像是個打不死的小強，倔強的與軟件開發一起生存了半個多世紀，到了現如今的網絡時代，不但沒有被壓制住，反倒更加猖獗了。那麼在小強最繁榮的遊戲圈裏面，大家是如何面對變更的呢？
整體而言，遊戲行業（尤其是網絡遊戲行業）對於變更是又愛又恨的，很糾結，很痛苦。因此在網絡遊戲行業中，變更管理也不是簡單的放任或者控制，而是要權衡各方面的因素，讓變與不變維持在一個平衡點上。一句話概括其管理方式就是：胡蘿蔔+大棒政策。
遊戲公司中對於變更的兩種意見
主變派：策劃、製作人；觀點：變化乃遊戲生存之本
變化是網絡遊戲生存之根本，大家評判一個網絡遊戲發展勢頭的最重要的標準有兩個：在線人數與更新頻率。一個更新頻率趨於變緩的遊戲，基本上可以說是快進入消亡期了。追逐玩家們不斷變化的口味，引領遊戲圈的新潮流，創造更高的吸金效率，這些都是以不斷的變化爲基礎的。
因此，遊戲必須變。不讓遊戲發生變化，就等於是要了遊戲的命。就算是限制變更，也相當於扼住了遊戲賴以生存的咽喉。
不變派：開發團隊，項目經理；觀點：變化是浪費，是隱患
說到底，遊戲還是個軟件，單機遊戲也好，網絡遊戲也好，無非都是運行在計算機上的軟件。變更對於軟件開發而言，災難性的，這一點所有軟件開發人員都深有體會，變更會導致大量的重複工作，嚴重影響開發進度；會對已完成的所有工作產生衝擊與影響，帶來更多的不可預期的Bug；沒有被良好重新設計的變更，甚至會直接威脅到軟件構架的穩定性，爲將來埋下極大的隱患，等等。這些軟件本身的問題，同樣也適用於遊戲開發。
更要命的是，頻繁的變更會讓開發團隊感到強烈的挫敗感，自己辛辛苦苦做好的東西，沒過幾天就被徹底改掉了，感覺自己就像是做了很多沒有用的東西一樣，長此以往，開發團隊將會士氣受挫，導致開發效率低下。
看來矛盾是不可避免了。那麼到底聽誰的呢？聽策劃的，還是聽開發的？按照大自然物競天擇的自然規律來判斷的話：誰強，聽誰的。
誰更強？策劃，還是程序？如果我在這裏挖個坑，蓋個樓的話，邀請大家來評價一下的話，我相信會相當的火爆。
實施證明，策劃與程序，都很重要。
變更的分類，哪些可以變？哪些不能變？
如果我們根據變更是否會對開發工作產生影響來對遊戲需求變更進行分類，我們可以整體上分爲兩種變更：1.對當前的遊戲開發工作產生直接影響；2.不會對當前的遊戲開發工作產生直接影響。
當前的工作，是指正在開發、測試、美術人員手上處理，或者進入到當前迭代週期內待處理的工作。發生直接影響，則是指會打斷當前正在進行的開發工作，比如一個遊戲需求：玩家自定義聊天頻道功能，現在這個需求已經到了程序手中，開始編寫代碼了，這時候如過策劃人員發起變更，就會對當前工作產生直接的影響。而如是另一種情況：這個需求目前還在策劃階段，還沒有送到程序員與美術人員的手中，這時候策劃人員發起需求變更，不會對當前的開發任務產生直接影響，因爲現在還根本沒有人在開發這個功能。
如果我們仔細分析一下程序人員反對變更的理由的話，我們會發現，其實程序人員僅僅是反對會產生直接影響的變更，而對於那些不會產生直接影響的變更，則不是很反對。那些不產生直接影響的變更，雖然也會對現有的工作產生一些間接的影響，但是影響不會很大，這個問題我們會在後面來討論。
胡蘿蔔+大棒
基於上面提到的變更的分類方法，我們可以得到這樣一個變更管理的方法：
當一個需求（或者策劃案）還處在策劃階段，還沒有被送去開發與實現的時候，我們允許這個需求發生改變，甚至允許它發生任何的改變，沒有任何限制。而一旦這個需求被送去開發與實現了，那麼我們將不再允許這個需求發生任何改變，需求與設計將會被鎖定，開發人員將會按照鎖定的版本進行開發。
如果在開發過程中，策劃人員實在忍不住要提出變更，那麼他僅有兩個選擇：
1，要求項目經理徹底終斷掉該需求當前的開發工作，將該需求從當前的開發列表中取消，待其將需求變更修改好後，再重新納入到下一輪開發計劃中；
2，等待已經送交開發的需求開發完成，在已經完成的基礎上提出修改（作爲一個新需求）並納入到下一輪的開發計劃中。
當一個需求被完成後，如果策劃人員需要對已經完成的內容進行變更，那麼他需要提出一個新需求，就叫做“對自定義聊天頻道修改”，將這個需求納入到需求庫中，並要求項目經理納入到接下來的開發週期中，作爲一個新的開發任務來處理。
那麼以上的假設是否可行呢？有沒有人真的這麼實踐過呢？答案是肯定的，敏捷開發方法論（不論是Scrum與XP）都是在以這種方法在管理需求變更，實踐的結果也是相當不錯的；另外，據我接觸的遊戲公司中，也有一些公司在採用類似的方法來管理變更（金山的一些項目組就是這麼做的，效果很好）。如果想更多的瞭解敏捷式變更管理，可以參考Ken Schwaber伯伯的書：《Scrum敏捷項目管理》（Agile Project Management With Scrum）
以上的做法，基本上滿足了策劃與程序的不同需求：策劃需要變更，開發不需要變更。開發人員應該對這個方法很滿意，既然變化是勢不可擋的，但是隻要不會直接影響當前工作，也是完全可以接受的；但是策劃人員心裏還是有一絲不爽：在漫長的開發週期內不能變更，是否太不人道了？
應用正確的開發模型
網絡遊戲開發應該是有週期性的，短迭代週期的增量式開發是比較好的開發模型。瀑布模型肯定是行不通的，如果還有公司在用瀑布模型開發網絡遊戲，唉，只能默默的祝願他們一路走好了。長週期的迭代（半年一個週期）也是行不通的，這倒不是這種方法本身有什麼問題，而是太長的迭代對於這個快速變化的花花世界來說，太痛苦了。
但是在我們訪談記錄中，卻發現很多遊戲公司居然沒有任何開發模型，完全是一種混沌的開發方法，買來一個現成的遊戲引擎，想到什麼就開發什麼，感覺做的差不多了就打個包上線，沒采用任何開發模型，沒有什麼明確的開發週期，一切都是憑着感覺來。這是一個很危險的事情，很多這樣的公司，在遊戲上線以後，會發現這個遊戲製作工作徹底陷入了一團糟的境地，任何局域性方法都無法提供有效的幫助，最終公司進入一個死循環，決的辦法也變得很殘忍：要麼死掉，要麼徹底改革。
任何的針對具體軟件開發管理問題的解決辦法，都是要在軟件開發模型的大框架下才能起效果的。我們不可能把瀑布模型中制定計劃的方法用在敏捷開發模型下，我們也不能把打牌估算的方式用在瀑布模型中，因爲這些具體方法都是在具體的開發模型的框架下，才具備了生存的條件。就像生態系統一樣，熱帶雨林裏的鱷魚，放到沙漠裏面，肯定活不下去的。所以如果一個遊戲公司連基本的開發模型都沒有引入的話，那麼就不要考慮變更怎麼管理了；就像在真空中任何生物都無法生存一樣，在沒有開發模型的環境中，任何開發管理方法也都無法取得效果。
所以，上文提到的這種這種需求（策劃）變更管理方法，是要在敏捷開發的大環境下，才能夠起作用的，在瀑布、長週期的迭代式開發模型中，都不會有啥正面作用。
迭代週期的選擇
一般的共識是這樣的：相對較長的Sprint迭代週期，能夠有效的提高開發效率。因爲一個Sprint週期中，有些工作是不能被省略的，如Backlog的整理、估算、計劃會、評審會與反思會、代碼集成、測試、打包等，這些活動一般都要佔用不少的時間，越長的Sprint週期，這些活動所佔用的時間比例會越少，爲開發人員留下的整塊開發時間就越多，工作效率也越高。
而Sprint週期越短，對於需求變化的響應速度就越快。人們對於未來變化的把握能力其實很弱，越短的時間，把握越強，考慮的也越詳細，太長時間以後的事情（如2個月以後），則基本沒有什麼把握能力了。
Sprint週期的選擇，就是開發效率與響應速度之間的一個平衡。
一般在開發期的遊戲，會選擇相對較長的Sprint週期，如1-2個月左右，這時候策劃相對比較明確，還沒有引入玩家與運營反饋，需求變更相對較少，選擇相對較長的開發週期能夠保證開發期的遊戲開發效率，爭取儘早達到上線標準。這時候也希望策劃團隊能夠儘可能減少不確定的變更，如果一個功能或玩法沒法確認真的比改變前更好，那麼就不要貿然提出改動，等到上線之後聽到玩家的反饋後再提出，能節省不少工作量。
而從遊戲上線封測開始，Sprint週期就開始逐步縮短，以適應逐漸增多的Bug、調整與變更，在遊戲正式運營後，一般都會將Sprint週期控制在1-3周左右，一般都是與遊戲的更新週期保持同步。從管理的角度來說，爲了適應更短的Sprint週期，很多管理上的規章與流程也要隨之相應的簡化，以適應高相應速度的要求。