為什麼軟體需求常常發生變更

Ⅰ 如何應對頻繁的軟體需求變更

作為項目建設實施掌舵人的項目經理及架構師們，最痛苦的事情之一就是：軟體需求經常變更，導致工期不斷拉長、成本投入持續增長、項目風險也越來越大，有一種想把這些善變的客戶，哦不對、是需求，給砍了的沖動

這時，請先反省一下：自己是否還有哪些地方做的不夠？或者，還有哪些地方應該做得更好？

我們不妨從項目過程生命周期的各個階段來看看我們可以做到哪些

Ⅱ 需求變更常見原因

1，臨時加了緊急需求，范圍變更；

2，前期沒想到，後期進行需求完善；

3，開發實現過程中有困難，有更好替代方案；

4，開發工期壓縮；

5，需求分析溝通不充分，產品設計出的東西不是用戶想要的；

6，市場更新過快，產品設計需進行相應變更；

7，需求變更後未落實到項目進度，未識別出相關方，

8，出現更緊急任務，延誤。

9，需求未通知到所有相關方。

Ⅲ 為什麼在軟體開發過程中需求變更是不可避免的

因為什麼事情都不可能一次就能想完善，在你做的過程中會發現前期一些不夠完善的地方。

Ⅳ 需求變更是軟體項目區別於傳統項目的顯著特點

需求變更是最讓碼農頭疼、抓狂的事。有時候會讓你從頭再來。

Ⅳ 如何解決需求變更頻繁

首先,我們來分析一下用戶需求變更的原因.
其實,無論我們做什麼項目,面對什麼樣的客戶,客戶需求總是認真對待的,因為這是整個項目的起點.然而，在你直接面對客戶之前，請先問自己一些問題，你是否對客戶的行業需求有過事前的分析，是否對客戶可能的需求有過充分的准備，是否准備好了去應付用戶所提出的種種意外的要求，如果，對這些問題你都是否定的回答得花，那麼，對於帖子中提出的問題，你肯定會應接不暇的。還有，在首次聽取用戶需求的時候，你是否有足夠的敏銳力去識別客戶的需求，是否能夠以專家的身份和能力去引導客戶的需求，如果不能，那末後期頻繁的需求變更也就不足為怪了。
總結起來，客戶需求變更的主要原因有二，一是對客戶的了解太少，缺少相關的專業經驗；二是缺少對客戶需求的控制能力。
接下來，就要看看如何來應對這樣的問題了。
做好事前的准備，這是應對客戶需求最有效的方法，在與客戶接觸之前，充分了解客戶的行業，做到心中有數，這樣才能在了解客戶需求的過程中做到有的放矢，順水推舟。
做好需求控制，一旦基本的需求明確，就要通過有約束能力的合同來是雙方就需求內容、需求變更流程達成一致。
最後還有一個問題，就是市場與需求變更的應對。
在做項目的過程中，無論你怎樣控制，由於市場的壓力，總會碰到客戶提出的「無理」要求，如何看待這樣的問題，就不是簡單的控制問題了，這就需要管理層去權衡利弊，如果，確實不值得，也只能放棄。

Ⅵ 為什麼在軟體開發過程中需求變更是不可避免的

這個問題很復雜。因為客戶不了解軟體是如何運行的

Ⅶ 為什麼需求總是在變更

軟體能不能像汽車一樣，事先就設計好，然後流水線的造出來，一氣呵成？

這可能是所有程序員最夢寐以求的願景！但事實上這是不可能的。

這其實就涉及到另外一個問題：為什麼需求會一直在變更？是CEO腦子抽風，還是產品經理做事不認真？

在知乎看到了這樣一個新的思路：不是需求的變更驅動著軟體的不斷更改，而是「軟體可以隨意更改」的這種特性刺激了不斷的需求變更。

裝修好的房子，是不是住一段時間之後就會覺得這里不舒服那裡不合適？少了一個插座，該加一個龍頭，櫥櫃用著不順手……「要是能改改就更好了！」只是這樣的改動太費力，所以大多數時間我們都還是算了。

汽車也一樣，開著開著想換個自動擋，開個天窗，加一個陡坡起步的防滑坡功能……只是你加不了而已！所以只好將就用，直到最後換個新車。

但軟體不一樣！理論上怎麼改都可以，而且好像改動沒多少成本？既然如此，這些我用著不舒服的地方，為什麼我不改呢？改其實是一種「改進」，是一個不斷完善產品的過程。「沒有最好，只有更好」，所以只要產品在用，就一定會有不斷的持續改進。「敏捷」所強調的「擁抱變化」，不是無奈之舉，也不是為了裝酷，而是有很深刻的現實基礎和邏輯支持的。

所以我們必須改變觀點，正確的認識「需求變更」。偶爾的吐槽可以緩解壓力，但在思想上必須認識到：需求變更不是一種我們必須無奈接受的折磨，而是我們必須勇敢面對的挑戰，是項目邁向卓越的機遇和必然。

Ⅷ 頻繁需求變更導致我的項目失敗了

李澤剛剛出任項目經理，聊到叮囑他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，項目也按照計劃的軌道正常進行，客戶相當滿意。但進入後期，客戶就開始了頻繁的需求變更要求，給項目團隊隊增加了不少的額外工作。

到後來甚至越過李澤，直接與程序員溝通，程序員本來手頭工作就多，加上客戶不斷的增加的要求，最後直接改程序，卻不做任何記錄，最終導致很多問題產生，大家都說不清系統被改成什麼樣了

這個例子中存在的問題有很多。項目應以需求為核心，一個項目是否能夠成功，對需求的准確把握在成功因素中要佔上60%的比例。如果需求出現偏差很容易導致項目失敗，項目開發過程中能夠與客戶建立有效快速的溝通渠道，是項目成功的關鍵。

需求必須獲得客戶的確認。通過需求調研與分析後獲得的用戶需求說明書，以及軟體需求規格說明書都必須得到客戶的簽字確認。確認的內容包括項目的目標、范圍以及項目需求功能點。

注意維護需求調研記錄以及需求跟蹤表。由於需求調研人不夠專業，而項目經理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有好的工具或流程來監控這一過程，使得需求調研記錄沒有發揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何項目的需求都不是固定不變的，需求隨時會發生變更，而開發人員實現的需求也可能會與客戶的要求偏差。

項目組對於需求變更的響應不夠及時，這一點項目經理與項目管理小組要擔負一定的責任。

如何有效控制需求變更？

1、明確合同約束。

需求變更給軟體開發帶來的影響有目共睹，在與客戶簽訂合同時，可以增加一些相關條款，如：限定客戶提出需求變更的時間，規定何種情況的變更可以接受、拒絕或部分接受，還可以規定發生需求變更時必須執行變更管理流程。不能忽視合同的約束力。

2、建立變更審批流程。

項目中，人們往往不願意為小的需求變更去執行正規的需求管理過程，認為降低開發效率，浪費時間。正是這種觀念才使需求變更變得不可控，最終導致項目的失敗。因此，小的需求變更也要經過正規的需求管理流程，否則會積少成多，積重難返。

明確需求變更審批環節、審批人員、審批事項、審批流程。凡未履行審批程序的變更，一律是無效變更不予受理。

3、分級管理變更。

項目開發中「客戶永遠是對的」和「客戶是上帝」並不完全正確，因為客戶所要求的可能並不能實現，而且任何新需求的變更和增加除了影響項目的正常進行以外，還影響到客戶的成本投入收益。

當客戶堅持變更新需求時，可以建議客戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據。向客戶正式提交一份需求變更計劃，註明變更引起的時間、成本、工期代價和增加工作量等。

4、安排專職人員負責變更管理。

如果沒有專職人員，項目中其他人員可能因為工作原因不能隨時與客戶溝通。因此，需要安排一名專職的需求變更人員，負責與客戶及時交流，跟蹤和匯報需求變更完成進度和情況。同時，可以成立項目變更控制小組，負責裁定接受哪些變更，小組由項目所涉及的多方人員共同組成，應該包括客戶方和開發方的決策人員在內。

5、告訴客戶變更的代價。

要讓客戶認識到變更都是有代價的，例如：進度延遲、費用增加、效率下降等問題。一般來說，如果客戶認為該變更是必須的，就會接受這些後果。通過與客戶協商，這樣開發團隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。