本文出處:http://blog.csdn.net/sodme
前記：
過去，在傳統軟體行業裡，開發的流程一般是：先作需求分析，然後確定功能，最後實施開發。也就是說，需求分析之後，需求基本就很少變了，會在相當長一段時間內，維持乙個穩定的需求。
但是，在進入網際網路軟體時代後，事情已經發生了變化，僅就需求而言，「朝令夕改」已經不是什麼新鮮事，作為系統的實現者，我們當然都希望需求越穩定越好，但那僅僅是「理想」，甚至，有時僅僅是「夢想」。因為，對於乙個尚未成熟的市場，尚未成熟的網際網路產品或者尚未成熟的團隊來說，需求變動的推動者，可能是市場，可能是使用者，也可能僅僅是老闆的一句話，你無法說這個改動是對是錯，很多的情況下，我們也沒有那個精力和時間去爭辯誰對誰錯，對於我們而言，最切實可行的一條路，就是：擺正心態，積極應對。
這是一篇有關「如何應對需求變化」的作團隊感悟，其核心思想是：
引入正文----
寫程式，最痛苦的是什麼？就是辛辛苦苦弄了半天，寫好了，人家的需求卻變了，剛寫好的**沒用了，全部刪掉。曾經以為，只有網際網路軟體裡，才會比較經常的出現這種情況，但是，跟一些朋友聊了之後，才知道，原來，現在的傳統軟體行業裡也存在同樣的問題。不管這個需求**於**，程式設計師除了抱怨一下，發一下火(還要看有沒有那個「資歷」)之外，該作的，還仍然要作，乙個都逃不掉。
我們的開發中，也會經常遇到這樣的問題，面對不斷變化的需求，我們有過懊惱，有過氣憤，有過不平，但當所有的情緒都發洩完了之後，靜下心來想一想，為了產品，這些新需求還都挺有道理，都必須來實現。
對於我們憑一己之力無法改變或者無力決定的事，應該秉持兩種心態：
1. 要以積累的心態去用自己的實際行動對它產生積極的影響力；
2. 既然我們無法改變它，就只有接受它，適應它，再慢慢引導它。
對待需求變化，也是同樣的道理。
很多的需求，為什麼會有，為什麼會變，可能本身就是沒有太多道理的，老闆說這個得改一下，那個得改一下，在產品沒有推向市場之前，在使用者沒有最終體驗之前，你也很難說他的這個需求就是不對的或者不合適的，那這時怎麼辦？我們的策略是：爭取一下，溝通一下，想想其它辦法，實在不行，就什麼也不用說，動手作吧。當然，這是一種被動應對的方式。
我們認為，這是沒辦法的事，乙個團隊，需要成長才能成熟，乙個老闆，也同樣需要成長才能成熟。只有越來越成熟了，才可能會越來越多的提出更合理的更穩定的需求，而反之，當他不成熟時，他作出的需求就談不上穩定和合理，那這時，是不是我們就不要作事了，是不是就只有散夥了？我想，動不動就這樣去想的朋友，還沒有真正悟出開發者應該具有的覺悟：其實，老闆都差不多的，當你換了一家後，你可能也會遇到同樣的問題，你能作的，不是逃避，而是正面面對它，如果他的想法不成熟，就幫著他成熟，如果他堅持，就照作，讓事實教育他。當事實一次次告訴他，你的想法和作法才是正確的之後，他才會更願意放權給你。而在此之前，你沒有其它更好的辦法，只有忍著。
也許，我們經常會有這樣的抱怨：「我們不是約定好了嗎，就按***來作的，怎麼又改了」。我想鄭重的告訴大家：不要相信約定，對於乙個尚處在生存期的專案而言，你一切努力的目標，都是為了專案生存和發展，而不是為了乙個「浪漫的約定」。市場和使用者，只看需求，不會看你所謂的「約定」。
從另一方面說，很多時候，並不是老闆自己想作出需求改動，他們可能是受壓於市場環境，受壓於同類產品競爭，也可能是受壓於使用者，總之，方方面面的原因，都可能造成需求改動，所以，我們沒有理由、也沒有必要一直堅持在「需求需不需要改動」這一點上來回的扯皮浪費時間，我們更多需要作的，是要考慮一下，在我們團隊內部，以何種開發方式，以何種流程，以何種組織架構來靈活適應這種經常性的需求變化。
除了上面所說的被動應對，還有一種主動應對的方法，那就是，作為系統開發者，我們自己要不斷的使用我們自己的產品，不斷思考我們的系統需求，在你使用和思考的過程中，很容易發現一些極可能帶來變化的需求，這樣，你在設計和實現時就可以提前規避。不要認為乙個系統你開發完了，就是完事了。很多的細節完善，其實是在你第一遍開發完成之後再慢慢新增的，而如何才能發現這些細節，只有你自己不斷的使用自己開發的系統。
面對需求變化，首先，我們要擺正自己的心態：
1. 不要一上來就發火，要分析為什麼會有這個需求，新需求的核心點是什麼？
2. 對比一下舊的實現，這個新需求用舊的框能不能簡單改改就可以間接實現？
3. 從心態上，把需求變化當作是一種專案常態，但是，要學會控制這種需求變化的趨勢，不能任其發展。
也就是說，在我們所有開發的系統中，針對於其中每乙個具體的系統，都只有乙個負責人，不會有兩個或者兩個以上的負責人，這樣便可以最大限度的加快專案決策本身所耗費的時間，有利於快速決策和快速實施。
小團隊協作，是指，乙個具體的系統，從開發到測試到實施，涉及的人盡可能少，兩三個人，四五個人，最好。因為，乙個系統，從設計，開發，編碼，到測試與交付，其中可能會涉及到諸多環節，並不是由程式設計師作完編碼整件事就完了，產品可不可用，最終還是要由客戶說了算，所以，應該想辦法盡可能提高產品從編碼到交付乃至到使用者反饋這樣乙個完整流程的效率，涉及到這個系統的所有人員的反應速度就決定了整個產品對於使用者需求的響應速度。
團隊協作，最主要的兩點：分工明確+資訊分享。分工明確，是說哪一些人負責作哪一些事，有明確說明，但除此之外，我們比較提倡的一點，就是：每乙個人，其最終，都是對產品負責，並不能只關注自己所作的那一塊工作，把屬於自己作的工作作好，只是乙個基本前提，具備完整產品思想的人，才能談得上合格。而資訊分享，是指通過im群、郵件、小會等多種方式把需求變化的資訊盡可能快的通知到所有涉及到的人員，以讓這些人員更好的進行協同。
除了組織架構，我們還需要提高團隊成員個體應對需求變化的相應能力，這些能力包括：
**的靈活，可以在一定程度上適應需求變化。但是，這並不是解決需求變化的萬能靈藥。因為，在實際的操作中，我們經常會因為無法把握「靈活的程度」而把**本身寫得過於複雜，從而甚至讓**本身喪失易維護性，這是我們所無法接受的。我們認為，**靈活性的底限，是不能破壞**的可讀和易維護，如果到達這個底限，我們寧願丟棄靈活性，寧願將**寫得笨一點。
我這裡所說的這種方法，對人員也是有一定要求的，比如，這個負責人，就必須是能獨當一面的，要有比較成熟的作事方式、方法和態度，知道如何在高壓力和短時間內開展最有效的協作。
很多網際網路產品，可能都會遇到一種情況：乙個產品的新版本剛剛發布了，但是，在引入大使用者量測試時，卻突然發現出現嚴重的問題，這時，就特別考驗負責人的應變能力，這種情況往往都是比較緊急的，成千上萬的使用者可能在網上排著隊用你的東西，你需要在一小時、半小時甚至十幾分鐘內作出有效修改，這種感覺，已經類似於打仗，雖然很刺激，但確實需要相當大的處變能力。
每個團隊，剛開始的時候，可能都不會這麼完美，有這麼多能獨當一面的人，但萬事總要有個開頭，團隊的成熟並不是靠讀一兩本書，看一兩篇博文就能實現的，它需要你和你的團隊在具體實踐中不斷的磨合、提高、總結。
作團隊感悟 13 如何應對需求變化
本文出處 前記 過去，在傳統軟體行業裡，開發的流程一般是 先作需求分析，然後確定功能，最後實施開發。也就是說，需求分析之後，需求基本就很少變了，會在相當長一段時間內，維持乙個穩定的需求。但是，在進入網際網路軟體時代後，事情已經發生了變化，僅就需求而言，朝令夕改 已經不是什麼新鮮事，作為系統的實現者，...
用敏捷方法應對需求變化
一 問題的提出 筆者近幾年一直從事資訊系統的開發，特別是有關國家機關和企業資訊系統的開發工作，取得了許多的經驗和教訓。其中乙個深切的體會是，需求的不斷變化，如果不能很好的應對，會導致整個專案的進度和質量都難以控制，最終使整個系統失敗。特別是在我國，使用者對於如何應用計算機軟體並沒有乙個成熟的經驗，在...
全程建模 需求變更如何應對
伊達 11 37 25 3 對於需求不斷變更，使用者老覺得加點東西沒什麼，覺得很簡單，導致系統越改問題越多。你有什麼好辦法嗎？青潤 11 36 06 這是最難以解決的問題，我一般是採用文件積累變更的方式，適當的時間讓他們看看已經變更了多少次，通過這個，可以讓他們有所顧慮。伊達 11 39 55 文件...