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