公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。專案開始比較順利，但進入到後期，客戶頻繁的需求變更帶來很多額外工作。Steven動員大家加班，保持了專案的正常進度，客戶相當滿意。 但需求變更卻越來越多。為了節省時間，客戶的業務人員不再向Steven申請變更，而是直接找程式設計師商量。程式設計師疲於應付，往往直接改程式而不做任何記錄，很多相關文件也忘記修改。很快Steven就發現：需求、設計和程式碼無法保持一致，甚至沒有人能說清楚現在系統“到底改成什麼樣了”。版本管理也出現了混亂，很多人違反配置管理規定，直接在測試環境中修改和編譯程式。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題，客戶已經明確表示“失去了耐心”。 而這還只是噩夢的開始。一個程式設計師未經許可擅自修改了核心模組，造成系統執行異常緩慢，大量應用程式超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的專案管理水平”。更糟糕的是，因為擔心繫統中還隱含著其他類似的錯誤，客戶高層對專案的質量也疑慮重重。 隨後發生的事情讓Steven更加為難：客戶的兩個負責人對介面風格的看法不一致，併為此發生了激烈爭執。Steven知道如果發表意見可能會得罪其中一方，於是保持了沉默。最終客戶決定調整所有介面， Steven只好立刻動員大家抓緊時間修改。可後來當聽說因修改介面而造成了專案一週的延誤後，客戶方原來發生爭執的兩人這次卻非常一致，同時氣憤地質問 Steven：“為什麼你不早點告訴我們要延期！早知這樣才不會讓你改呢！”Steven很無耐，疑惑自己到底錯在哪裡了。 需求變更往往是不可避免的。通常是專案負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味著專案開發人員不應該做這方面的工作，專案開發人員對於需求變更的正確態度應該和軟體測試的態度一樣，在需求變更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。專案開發人員切忌在專案設計之前試圖消除需求變更，這樣做往往費力不討好。 相比於需求開發人員而言，客戶可能對需求變更認識不足，認為他們出錢，程式設計師或軟體開發公司就要為它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或使用者部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟體的定價應該與軟體的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和專案開發者共同承擔。透過這樣做，讓客戶在需求分析之前就儘量對他們所需要的功能有個整體的瞭解和確定的思路，而不是等到程式設計師開始編碼了，才提出以前原本在需求分析時就可以提出的需求。 讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作伙伴關係。雖然需求分析人員和客戶存在著服務商和顧客的關係，但是他們有著一個共同的目標：開發出適合客戶需求的軟體，因此需求分析人員除了記錄客戶提出的需求以外，還應和使用者討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，儘量多的召集需求研討會，邀請開發人員和客戶共同協商探討，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠儘量使得需求完備。在需求開發時，開發人員採用原型的方法啟發客戶思考功能需求也不失為一個好辦法。
公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。專案開始比較順利，但進入到後期，客戶頻繁的需求變更帶來很多額外工作。Steven動員大家加班，保持了專案的正常進度，客戶相當滿意。 但需求變更卻越來越多。為了節省時間，客戶的業務人員不再向Steven申請變更，而是直接找程式設計師商量。程式設計師疲於應付，往往直接改程式而不做任何記錄，很多相關文件也忘記修改。很快Steven就發現：需求、設計和程式碼無法保持一致，甚至沒有人能說清楚現在系統“到底改成什麼樣了”。版本管理也出現了混亂，很多人違反配置管理規定，直接在測試環境中修改和編譯程式。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題，客戶已經明確表示“失去了耐心”。 而這還只是噩夢的開始。一個程式設計師未經許可擅自修改了核心模組，造成系統執行異常緩慢，大量應用程式超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的專案管理水平”。更糟糕的是，因為擔心繫統中還隱含著其他類似的錯誤，客戶高層對專案的質量也疑慮重重。 隨後發生的事情讓Steven更加為難：客戶的兩個負責人對介面風格的看法不一致，併為此發生了激烈爭執。Steven知道如果發表意見可能會得罪其中一方，於是保持了沉默。最終客戶決定調整所有介面， Steven只好立刻動員大家抓緊時間修改。可後來當聽說因修改介面而造成了專案一週的延誤後，客戶方原來發生爭執的兩人這次卻非常一致，同時氣憤地質問 Steven：“為什麼你不早點告訴我們要延期！早知這樣才不會讓你改呢！”Steven很無耐，疑惑自己到底錯在哪裡了。 需求變更往往是不可避免的。通常是專案負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味著專案開發人員不應該做這方面的工作，專案開發人員對於需求變更的正確態度應該和軟體測試的態度一樣，在需求變更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。專案開發人員切忌在專案設計之前試圖消除需求變更，這樣做往往費力不討好。 相比於需求開發人員而言，客戶可能對需求變更認識不足，認為他們出錢，程式設計師或軟體開發公司就要為它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或使用者部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟體的定價應該與軟體的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和專案開發者共同承擔。透過這樣做，讓客戶在需求分析之前就儘量對他們所需要的功能有個整體的瞭解和確定的思路，而不是等到程式設計師開始編碼了，才提出以前原本在需求分析時就可以提出的需求。 讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作伙伴關係。雖然需求分析人員和客戶存在著服務商和顧客的關係，但是他們有著一個共同的目標：開發出適合客戶需求的軟體，因此需求分析人員除了記錄客戶提出的需求以外，還應和使用者討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，儘量多的召集需求研討會，邀請開發人員和客戶共同協商探討，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠儘量使得需求完備。在需求開發時，開發人員採用原型的方法啟發客戶思考功能需求也不失為一個好辦法。