每天都在講範圍、說需求，真的到了想整理出點什麼的時候，卻一下子不知從何說起。也許是熟悉麻痹症吧。根據我的破經歷，在需求方面有幾個是最搞人的，只要我們方法得當，雖然不一定能夠完全駕馭，但起碼可以改善一些或者說當板子落下來的時候至少我們不會受傷。
當用戶或出資方能提出要求但就是總在拖拖拉拉怎麼辦？用時間盒子限定需求！給他一個最後日期，說明在什麼什麼時候之前必須提出，否則過期不候。當然，也有可能這招沒效。沒關係，記錄下來，讓其簽字，至少白紙黑字寫下來了，以後用這個來催他會好一點。或者他不簽字，也不礙事，將相關溝通結果告知你的上層。既然遇到了這麼不配合的出資方，如果不把自己保護起來到時候嘿嘿就有得自己受了。事情要做好，這是終極目標；可是我們生活在一個現實的環境下，所以過程是相當重要的。
當用戶催的很急，資源也不能增加，範圍也框定了，怎麼辦？排定需求優先級並實現最緊急的。這個在實際操作中也不一定是那麼順利的，有的出資人很倔強——什麼都重要，那就得給他耐心解釋了，必要的時候要給他上上課。這中間會考驗項目帶頭人的多種素質，事在人爲而已。按照優先級去實現系統的功能，即使到時候真的完成不了，損失也可以降低到最小。
當需求不停變更時，該怎麼辦？建立變更控制流程！不管是甲方的，還是我們乙方內部的，都需要，好處太多了，費的那點時間後面會無數倍的賺回來。
變更，既是客戶的權利，也是客戶自己也沒有完全弄清楚的地方，雖然我們作爲乙方遇到經常變更或反覆變更的情況時會很頭疼，我們應該真誠體諒和積極配合。問題是，不能讓權力濫用，絕對不能把本來不好意思的變更，寵慣養成堂而皇之的壞毛病。我們要想辦法控制變更，目的是保證我們的有限資源儘可能配合“有效變更”，同時儘可能減少“無效變更”對成本、工期和合同履行帶來的負面影響。
1．立即（通過公司層面）建議客戶建立變更審批/下達制度，目的有兩個：第一，將客戶下達變更的流程儘可能地正規化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的“無效變更”。第二，留下書面依據，以後玩扯皮遊戲的時候掌握一點點主動權。
這個事情最好是得到對方的高層首肯，事情就好辦了。一般來講，高層都懂管理，你以“加強管理、優質服務”爲理由，對方應該是會同意的。
2．強化自身計劃管理和節點控制的功夫，向客戶正式提交一份各階段主要工作節點和技術關鍵事項的完成計劃，註明任何可能的變更必然引起的時間、成本、工期的代價，建議或要求客戶配合這個計劃，保大局棄小變，推進項目前進。
3．對於已經形成慣例的零星變更（前提是必須要處理的變更），要努力爭取“集中研究、批量處理”，每週或每兩週甚至每月召開一次變更專題會議，集中研究處理這些零碎變更事項，主動控制好工作節奏，硬着頭皮頂住要求隨時處理這些零星變更的壓力，儘量避免由於處理零碎變更而影響項目運行的總體態勢。
4．對於不合理的變更，儘量往後推，可以告知客戶“我們在下一階段實現”。切不可用戶提什麼就答應什麼，並馬上着手給他們開始處理，那樣就患上了不治之症啦。
總之，說易行難，真正要落到實處，還有很多工作要做。路漫漫其修遠兮，吾將上下而求索。
——以上是我在2010年所寫下的。
——三年過去了，有一些update。如下。
如今，我已不再做系統集成或政府相關的項目，專注於做產品，發現需求的問題更加嚴重，總是有更多未包含在規格中的的feature冒出，我熟練的運用以上總結出的規則，至今未在需求上栽大跟頭。
我已經很嫺熟的笑着對別人說“No”了，儘管如此，總會有些驚險的事情發生的。比如有一次，明明發布期已經接近，並且還有50多個bug未處理（做產品的人都知道，處理bug的優先級是很高的），產品經理（他的級別很高）非要加上矢量圖導出成html5的功能，另外加上幾個小的功能。我的處置方式是，合理評估所需工作量——告知相關人員（含老闆）——列出我們近期詳細的工作安排（也包含了幾個小功能中好做的），結果矢量圖導出成html5的功能就放在2.0版中去處理了。
當我們說不的時候，總是會讓某些人不高興，這也是不得已的，我能做的就是有理、有據、有節。
不過從另放一方面來講，我在做產品的時候，倒是也會加一些認爲好的功能（需求）進去，只要對用戶有價值的，合理排好計劃去處理這些功能也很正常。