毫無節(jié)制的需求變更，影響的不僅僅是項目成本，更是會影響整個團隊的士氣。本篇總結(jié)一下，我們應(yīng)該以怎樣的姿態(tài)和方法來應(yīng)對需求變更。
毫無節(jié)制的需求變更，影響的不僅僅是項目成本，更是會影響整個團隊的士氣。本篇總結(jié)一下，我們應(yīng)該以怎樣的姿態(tài)和方法來應(yīng)對需求變更。
1. 需求變更是必然的、可控的、有益的。
2. 一切的需求變更都是為了讓項目更加完善。
3. 客戶所有的變更都是有原因的，我們要積極地滿足其背后的需求，而不是機械地滿足其表面的要求。
4. 需求變更控制的目的不是控制變更的發(fā)生，而是對變更進行科學的管理，要確保變更有序地進行，最大限度地控制需求變更給軟件質(zhì)量造成的負面影響。
5. 需求分析人員和客戶的關(guān)系不應(yīng)該僅僅是記錄人員和需求提供者，他們的關(guān)系應(yīng)該更多的是戰(zhàn)略合作伙伴關(guān)系。
1. 需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。2. 用戶常常以為自己清楚，但實際上他們提出的需求只是依據(jù)當前的工作所需，而采用的新設(shè)備、新技術(shù)通常會改變他們的工作方式;或者要開發(fā)的系統(tǒng)對用戶來說也是個未知數(shù)，他們以前沒有過相關(guān)的使用經(jīng)驗。3. 隨著開發(fā)工作的不斷進展，系統(tǒng)開始展現(xiàn)功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或?qū)σ郧疤岢龅囊筮M行改動。5. 他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。1. 項目前期盡量清晰地確定需求范圍和需求基線并與客戶共同確認。2. 設(shè)計靈活的軟件架構(gòu)，以能夠?qū)ψ兓男枨筮M行快速響應(yīng)。3. 對變更的需求進行優(yōu)先排序，分批實現(xiàn)。對于零星變更，集中研究、批量處理。4. 妥善保存變更產(chǎn)生的相關(guān)文檔。如果用戶需要變更需求，則填寫《需求變更申請》，經(jīng)客戶方和服務(wù)方共同確認后，發(fā)送內(nèi)容給項目組需求負責人。《需求變更申請》的項目組接收者，錄入此變更請求到《問題跟蹤清單》，分析并標識“問題類型”。項目經(jīng)理和相關(guān)人員進行內(nèi)部變更評估、審核，決定哪些變更無法修改并說明原因，哪些變更需要修改和什么時候修改。審核通過的《需求變更申請》，確定開發(fā)時間和納入的版本，制定開發(fā)計劃。對于需求變更而進行的版本更新，需交付相應(yīng)的《版本更新說明》。1. 需求的變更要經(jīng)過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。2. 小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認為降低了開發(fā)效率，浪費了時間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽?，最終導致項目的失敗。3. 精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非需求寫細了，它就不會變化了。4. 注意溝通的技巧。實際情況是用戶、開發(fā)者都認識到了上面的幾點問題，但是由于需求的變更可能來自客戶方，也可能來自開發(fā)方，因此，作為需求管理者，項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。5.需求一定要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔，則項目需求的變更就成為必然了。所以，在項目的開始，無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投入也要變。文章來源：作者：啊莊。公眾號：曉莊同學產(chǎn)品筆記。
圖片來源：部分圖片來源網(wǎng)絡(luò)，版權(quán)歸原作者所有，不為商業(yè)用途，如有侵犯，敬請作者與我們聯(lián)系。文章為作者獨立觀點，不代表135編輯器立場。
文章申明：本文章轉(zhuǎn)載自互聯(lián)網(wǎng)公開渠道，如有侵權(quán)請聯(lián)系我們刪除
