產(chǎn)生影響，但一旦產(chǎn)生影響，處理起來就很麻煩，這也是為什么大家都提倡在需求階段把需求做充分，在設(shè)計(jì)階段把架構(gòu)設(shè)計(jì)靈活。前者可以預(yù)防問題發(fā)生，后者則可以盡量降低問題發(fā)生后對(duì)設(shè)計(jì)的影響。
(三) 測(cè)試階段的需求變更
在這個(gè)階段需求變更發(fā)生較少，但也會(huì)出現(xiàn)，有可能是用戶突然又增加新的內(nèi)容，而更多情況是測(cè)試人員發(fā)現(xiàn)的BUG是由需求的誤差引發(fā)的。這也是為什么現(xiàn)在的軟件測(cè)試從需求分析階段就開始，而不是等到階段性編碼結(jié)束再開始。把問題盡量消滅在開始階段總比在問題出現(xiàn)后再補(bǔ)救更合理。
(四) 實(shí)施階段的需求變更
這個(gè)階段出現(xiàn)的需求變更就更少，即使出現(xiàn)也不是功能方面的問題，可能是和實(shí)施相關(guān)的軟硬件或網(wǎng)絡(luò)問題。若要避免，則只能在設(shè)計(jì)時(shí)就考慮多種實(shí)施方案，以防萬一。凡事預(yù)則立，不預(yù)則廢。
(五) 系統(tǒng)維護(hù)階段的需求變更
借用80/20原則，80%的需求變更產(chǎn)生于這個(gè)階段，剩余的20%則產(chǎn)生于其他幾個(gè)階段。系統(tǒng)上線后，用戶在使用起來肯定和原來的想法會(huì)有很大的出入，這就是理想與現(xiàn)實(shí)的差距。這個(gè)階段的變更無法預(yù)料，只好認(rèn)真的管理。
上面分析了各個(gè)階段的需求變更，那么對(duì)于變更控制也就有了清晰的解決思路。國內(nèi)講需求變更管理，大多提到加強(qiáng)溝通、區(qū)分對(duì)待、合同約束等問題，這種功利化的處理方式無可厚非，但是卻沒有講到重點(diǎn)上。對(duì)于需求變更控制，我覺得仍要沿用需求分析的處理方式，先分主次，再具體分析。這個(gè)過程中就需要標(biāo)明是哪個(gè)階段的需求變更，還要估計(jì)變更對(duì)程序帶來的影響，而不是泛泛的記錄變更的內(nèi)容。很多軟件在系統(tǒng)維護(hù)階段變得異常的被動(dòng)，主要還是沒有把需求變更帶來的影響分析準(zhǔn)確。
把方法再明確一下，就是需求變更需要有專門的人員記錄，這個(gè)人最好是項(xiàng)目組內(nèi)部的人員，記錄內(nèi)容包括需求變更具體內(nèi)容、發(fā)生于哪個(gè)階段、以及由誰提出的等內(nèi)容。項(xiàng)目經(jīng)理需要每天關(guān)注需求變更記錄，每周必須對(duì)需求變更產(chǎn)生的影響進(jìn)行預(yù)估，并將預(yù)估結(jié)果記入到需求變更記錄當(dāng)中，以便于確定今后的工作計(jì)劃。