參加過很多專案，也遇到過許多需求變更。
記得n多年前系統半夜發布，結果發布當晚，那次release的乙個功能緊急變更，是乙個彎了十幾個彎的邏輯，所以當時寫的時候就很麻煩，leader說立刻改，於是吭哧吭哧開始改，改完發布，等著客戶確認，結果沒等來確認，等來了一次又一次的變更，很不爽，心裡暗暗鄙視客戶，繼續吭哧吭哧改，就這樣那天晚上客戶邏輯能改了七八次，最後兩次都是某個小部分改，改到最後一次已經是早上10點多了，我已經不知道最後的整體邏輯是什麼了，腦子裡一片漿糊，然後客戶終於通過了。打車回家休息，路上覺得自己好想躺下就不起來了，支撐著回去後，打算蒙頭睡覺。但是卻被一起租房的室友吵得睡不著，之後有很長一段時間，腦子裡就像有漿糊一樣，寫著**都能突然忘記自己寫什麼了，直到後來下班就去鍛鍊，半個多月後，才緩過來。
後來，我也逐漸開始帶團隊，開始與客戶談需求，談需求變更。
記得有乙個專案，因為是package的專案，客戶對錢非常計較，需求變更付費，非常非常的難，所以一開始我們做需求時，所有的流程設計、介面、高畫質圖等，我都追著讓客戶簽字確認，他們開始口頭確認，沒簽，我就給訂了個最終簽字日期，告訴客戶必須在那之前簽好字，最後客戶終於簽字了。但是即使文件上簽字了，也是擋不住客戶的需求變更的，由於合同是做pc端，不包含手機端，還特意確認過與不做自適應，其實用我們的平台做自適應也很麻煩，除非手機和pc資料一摸一樣，但是不可能呀。實施過程中客戶提出一些變更，我們記錄，討論，最後確定了其中幾個可以做，其他對專案影響比較大，沒同意。當一切看起來比較順利，我們就要上線時，客戶突然又來了乙個重磅炸彈，要我們必須給他們實現手機端，還不願意另外付費，因為我們的預算根本不可能支撐這個變更，所以經過多次協商未果後，他們給我老大打了**，老大說，客戶言明：「不給實施手機端，他們最終的確認就不會給」，事情陷入膠著，後來老大想了個折中的辦法，和客戶籤了個小合同，在那個合同裡，我們把他們的手機端實現了。
當時覺得這個客戶有時也滿難纏的，然而之後發現，這世上只有更難纏的，沒有最難纏的，這個客戶很多地方其實都讓我們認為是個比較講理的客戶。
還有個專案，我是架構師，和我們的業務人員對接，不對接客戶業務人員，開始我列出了專案的backlog，客戶負責人、我和團隊的人一起確定了backlog，等我們開發完成後，客戶領導已經換人，業務負責人說範圍不止這些，最後談不攏，做的東西客戶也不付費，公司和他們打官司去了。
還有一次，我是pm，但是到後來只是掛名，由另乙個pm帶隊，專案要上線時，pm打**說 原本客戶訂好了上線時間，都準備好了，他們又不肯上線了，因為有幾個變更他沒同意，和客戶吵了一架，pm大致說了一下，變更確實需要花多些時間，然後客戶打**來抱怨，說我們的人不同意，還和他們吵架，而且是他們認為很簡單而且合理的變更，我向他們表達了對他們的理解，也表示了我們的困難，然後詳細問了一下具體他們為何要那麼改，結果客戶只是覺得那個邏輯他們最開始訂的太麻煩，客戶使用不方便，所以想去掉麻煩的部分，因為客戶不懂技術，他們給的變更方案實現起來很麻煩，但是實際上要實現那個目的可以很簡單，於是我重新給了客戶技術方案的建議，並且告訴他，這樣既能實現他們的目的，我們也能很簡單迅速的完成，客戶很痛快的同意了，其實他們只關心你能不能實現他們的目標，至於方法，大家都是很容易商量的，最後專案正常上線。
很晚了，今天就寫到這裡了
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...