對于四級需求,如果時間和資源條件都允許的話,不妨做下去。對于五級需求,正如對它的描述一樣,做與不做是“Maybe”。
2、全生命周期的需求變更管理
各種規(guī)模和類型的軟件項目的生命周期大致可以分為三個階段,即項目啟動、項目實施、項目收尾。不要以為需求變更的管理和控制只是發(fā)生在項目實施階段,而是要貫穿在整個項目生命周期的全過程中。
站在全局角度的需求變更管理,需要采用綜合變更控制的方法。
?。?)項目啟動階段的變更預(yù)防
正如前面強調(diào)的,對于任何軟件項目,需求變更都無可避免,也無從逃避,無論是項目經(jīng)理還是開發(fā)人員只能積極應(yīng)對,而這個應(yīng)對應(yīng)該是從項目啟動的需求分析階段就開始了。
對一個需求分析做得很好的項目來說,基準文件定義的范圍越詳細清晰,用戶跟項目經(jīng)理提出需求變更的幾率就越小。如果需求沒做好,基準文件里的范圍含糊不清,被客戶發(fā)現(xiàn)還有很大的“新需求空間”,這時候項目組往往要付出許多無謂的犧牲。
如果需求分析做得好,文檔清晰且又有客戶簽字,那么后期客戶提出的變更就超出了合同范圍,需要另外收費。這個時候,項目經(jīng)理一定要據(jù)理力爭,此時這并非要刻意賺取客戶的錢財,而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣,否則后患無窮。
(2)項目實施階段的需求變更
成功的軟件項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。
項目經(jīng)理應(yīng)該樹立一個理念,即“需求變更是必然的、可控的,并且是有益的”。項目實施階段的變更控制需要做的是分析變更請求,評估變更可能帶來的風險和修改基準文件。
控制需求漸變需要注意以下幾點:
需求一定要與投入有聯(lián)系,如果需求變更的成本由開發(fā)方來承擔,則項目需求的變更就成為必然了。所以,在項目的開始,無論是開發(fā)方還是出資方都要明確這一條:需求變,軟件開發(fā)的投人也要變。
需求的變更要經(jīng)過出資者的認可,這樣才會對需求的變更有成本的概念,能夠慎重地對待需求的變更。
小的需求變更也要經(jīng)過正規(guī)的需求管理流程,否則會積少成多。
在實踐中,人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程,認為降低了開發(fā)效率,浪費了時間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽?,最終導(dǎo)致項目的失敗。
精確的需求與范圍定義并不會阻止需求的變更。
并非對需求定義得越細,就越能避免需求的漸變,這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的,并非需求寫細了,它就不會變化了。
注意溝通的技巧
項目開發(fā)過程中的實際情況是用戶、開發(fā)者都認識到了上面的幾點間題,但是由于需求的變更可能來自客戶方,也可能來自開發(fā)方,因此,作為需求管理者,項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。
?。?)、項目收尾階段的總結(jié)
能力的提高往往不是從成功的經(jīng)驗中來,而是從失敗的教訓(xùn)中得來。許多項目經(jīng)理不注重經(jīng)驗教訓(xùn)總結(jié)和積累,即使在項目運作過程中碰得頭破血流,也只是抱怨運氣、環(huán)境和團隊配合不好,很少系統(tǒng)地分析總結(jié),或者不知道如何分析總結(jié),以至于同樣的問題反復(fù)出現(xiàn)。
事實上,項目總結(jié)工作應(yīng)作為現(xiàn)有項目或?qū)眄椖砍掷m(xù)改進工作的一項重要內(nèi)容,同時也可以作為對項目合同、設(shè)計方案內(nèi)容與目標的確認和驗證。項目總結(jié)工作包括項目中事先識別的風險和沒有預(yù)料到而發(fā)生的變更等風險的應(yīng)對措施的分析和總結(jié),也包括項目中發(fā)生的變更和項目中發(fā)生問題的分析統(tǒng)計的總結(jié)。
3、需求變更管理原則
雖然需求變更的內(nèi)容和類型有各種各樣,但需求變更管理的原則卻是萬變不離其宗。實施需求變更管理需要遵循如下原則:
(1)建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中,需求確定并經(jīng)過評審后(用戶參與評審),可以建立第一個需求基線。此后每次變更并經(jīng)過評審后,都要重新確定新的需求基線。
?。?)制訂簡單、有效的變更控制流程,并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時,這個流程具有一定的普遍性,對以后的項目開發(fā)和其他項目都有借鑒作用。
?。?)成立項目變更控制委員會(CCB)或相關(guān)職能的類似組織,負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成,應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。
?。?)需求變更一定要先申請然后再評估,最后經(jīng)過與變更大小相當級別的評審確認。
(5)需求變更后,受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更,以保持和更新的需求一致。
溫馨提示:因考試政策、內(nèi)容不斷變化與調(diào)整,信管網(wǎng)網(wǎng)站提供的以上信息僅供參考,如有異議,請以權(quán)威部門公布的內(nèi)容為準!
信管網(wǎng)致力于為廣大信管從業(yè)人員、愛好者、大學(xué)生提供專業(yè)、高質(zhì)量的課程和服務(wù),解決其考試證書、技能提升和就業(yè)的需求。
信管網(wǎng)軟考課程由信管網(wǎng)依托10年專業(yè)軟考教研傾力打造,官方教材參編作者和資深講師坐鎮(zhèn),通過深研歷年考試出題規(guī)律與考試大綱,深挖核心知識與高頻考點,為學(xué)員考試保駕護航。面授、直播&錄播,多種班型靈活學(xué)習(xí),滿足不同學(xué)員考證需求,降低課程學(xué)習(xí)難度,使學(xué)習(xí)效果事半功倍。
發(fā)表評論 查看完整評論 | |