大型IT項目如何有效控制需求變更
2018-08-27 北京赛车直播微彩app 閱讀

北京赛车直播微彩app www.zsynos.com.cn        近年來,互聯網推動了大型IT行業信息科技的飛速發展,大型IT行業信息化手段與技術的采用越來越突出,軟件需求量越來越大。在項目需求快速增長的現狀下,業內人士在項目管理過程中不得不面對一個貫穿整個項目始末的問題——即需求變更,需求的變更在大型IT項目管理過程中對整個生命周期產生非常大的影響,如果不能及時的管控,項目計劃和交付日期便會一拖再拖,不僅使企業對整個項目失去信心,同時開發人員也會產生很大的負面情緒。如何有效的對需求變更進行科學的管控是每一位項目參與成員需要思考的問題。

項目經理需要在變更產生之初,判斷其原因并確認涉及范圍,進而采用合適的變更管控方法?;乜刂葡钅恐興謀涓?,而不是被變更所控制。

需求管理軟件概述.png

一、為什么要變更需求

大型IT項目需求變更的表現形式是多方面的,比如:項目預算增加或減少、高層領導臨時改變決策、增加或者減少功能、行業政策的變化等。企業為什么要變更需求,原因是什么?

321.jpg

1、范圍沒有圈定就急于細化

需求細化是根據客戶提出的描述性的、總結性的語言去細化的,提取其中的功能,并給出細化的描述。當細化到一定程度后并開始系統設計時,范圍可能會發生變化,那細節用例的描述可能就有很多要改動。如原來需求文檔是整體導入導出,要改為指定范圍和內容導入導出,如原來需求是多元交叉受理,要改為集中受理、統一需求入口和出口等。

2、沒有指定需求的基線

需求的基線是指是否容許需求變更的分界線。隨著項目的進展,需求的基線也在變化。是否容許變更的依據是合同以及對成本的影響,比如軟件整體結構已經設計出來是不容許改變需求范圍的,因為整體結構會對整個項目的進度和成本有初步預算。項目進展越深入,基線將越定越高,容許的變更將越少。

3、沒有良好的軟件結構適應變化

組件式的軟件結構就是提供了快速適應需求變化的體系結構,數據層封裝了數據訪間邏輯,業務層封裝了業務邏輯,表示層展現用戶表示邏輯。但適應變化必須遵循松耦合原則,各層之間還是存在一些聯系的,設計要力求減少會對接口入口參數產生變化。如果業務邏輯封裝好了,則表示層界面上的一些排列或減少信息的要求是很容易適應的。如果接口定義得合理,那么即使業務流程有變化,也能夠快速適應變化。因此,在成本影響的容許范圍內可以降低需求的基線,提高客戶的滿意度。

二、需求變更管理的實施準則

大型IT項目需求變更時,如果開發團隊缺少明確的需求變更控制過程或采用的變更控制機制無效,抑或不按變更控制流程來管理需求變更,那么,很可能造成項目進度拖延、成本不足、人力緊缺,甚至導致整個項目失敗。

當然,即使按照需求變更控制流程進行管理,由于受進度、成本等因素的制約,軟件質量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質量造成的負面影響,具體實施準則如下:

1、建立需求基線,需求基線是需求變更的依據。在開發過程中,需求確定并經過評審后(用戶參與評審),可以建立第一個需求基線。此后每次變更并經過評審后,都要重新確定新的需求基線。

2、制訂簡單、有效的變更控制流程,并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程。同時,這個流程具有一定的普遍性,對以后的項目開發和其他項目都有借鑒作用。

3、成立項目變更控制委員會(CCB)或相關職能的類似組織,負責裁定接受變更。CCB由項目所涉及的多方人員共同組成,包括行方和開發方的決策人員在內。

4、需求變更一定要先申請然后再評估,最后經過與變更大小相當級別的評審確認。

5、需求變更后,受影響的軟件計劃、產品、活動都要進行相應的變更,以保持和更新的需求一致。

6、妥善保存變更產生的相關文檔。

三、需求變更的有效管理

需求變更對大型IT開發項目成敗有重要影響,既不能一概拒絕客戶的變更要求,也不能一味地遷就客戶,所以,實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發生,而是對變更進行管理,確保變更有序進行。

322.jpg

1、明確合同約束,建立需求基線

對于大型IT開發項目,變更都無可避免,也無從逃避,只能積極應對,這個應對應該是從項目啟動的需求分析階段就開始了。對一個需求分析做得很好的項目來說,基準文件定義的范圍越詳細清晰,客戶跟項目經理扯皮的幌子就越少。如果需求沒做好,基準文件里的范圍含糊不清,被客戶抓住空子,往往要付出許多無謂的犧牲。如果需求做得好,文檔清晰且又有客戶簽字,那么后期客戶提出的變更就超出了合同范圍,需要另外收費。這個時候千萬不能手軟,不能讓客戶養成頻繁變更的習慣。

在開發過程中,需求確定并經過評審后(客戶參與評審),建立第一個需求基線。此后每次變更并經過評審后,都要重新確定新的需求基線,做到小需求可以變更,但大方向要保證不頻繁變更。

2、建立變更審批流程

成功項目和失敗項目的區別就在于項目的整個過程是否是可控的。項目經理應該樹立一個理念——需求變更是必然的、可控的、有益的??刂菩棖蠼ケ湫枰⒁庖韻錄傅悖?/span>

?  確認客戶是否接受變更的代價 要讓客戶認識到變更都是有代價的,要和客戶一起判斷需求變更是否依然進行。例如,變更是沒有問題的,但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。

一般來說,如果客戶認為該變更是必須的(不是其上級領導拍腦袋提出的)就會接受這些后果。通過與客戶協商,這樣開發團隊即使沒有回報,也不會招致公司和客戶雙方的埋怨。如果客戶認為該變更雖然有必要但是可以暫緩,雙方簽署備忘錄后留待以后解決。如果客戶認為該變更可有可無,多數情況下會取消變更。這樣即可防止頻繁變更,也讓客戶認識到不是所有的需求都需要變更。

?  需求變更,不管大小都需要經過正規的需求管理流程,否則會積少成多。在實際大型IT項目執行中,項目經理往往不愿意為小的需求變更去執行正規的需求管理過程,認為降低了開發效率,浪費了時間。但正是由于這種觀念才使需求逐漸變的不可控,最終導致項目失敗。

3、用迭代方式應對需求頻繁修訂

大型IT項目開發過程中,建議采用迭代開發方式,每個階段的產品進行版本規劃,這樣在第一版本交付過程中,質量較好可以使客戶保持對項目成功的信心,這樣也可以使客戶需求更加明確和完善產品,客戶最關住的是研發過程中與實際后續版本提供系統構架和新技術領域的探索,在后續版本過程中不斷的對運營過程中分期完善,對系統的缺陷加以修訂,這樣才能保障軟件生命周期的延續。

四、需求管理工具體現的價值

Visual RM是一款基于大型IT項目管理特點的需求內容級管理工具,以大型IT項目管理視角,幫助IT項目實現需求“管得住、控得了、可跟蹤、可沉淀、可復用”的核心目標,其價值主要體現在以下方面:

1、由文檔級轉為內容級需求管控,助力IT過程的精益管理:改變傳統的需求文檔級管理過粗的方式,通過需求結構化、條目化技術,自動對需求文檔進行自動化拆解,形成需求條目,將需求管理與跟蹤的顆粒度細化到條目級,使得需求內容切分(應用分配)、需求內容質量管控、開發和測試任務的需求分配、投產內容的需求跟蹤成為可能。

1、需求條目化.png

2、控好需求內容變更,維護好最新需求Visual RM實現了需求文檔級、條目級的需求基線管理,通過需求內容的變更控制手段,如:多人同時在線編制需求、變更需求、變更痕跡及歷史管理、變更內容前后比對、需求變更影響分析和自動通知受影響的相關人員,使需求變更過程方便、快捷,且變更過程透明、可回溯。

3、幫助項目團隊快速、方便獲取最新、最可信的需求:為解決需求來源多、需求傳遞混亂的問題,Visual RM通過需求集中管理、規范需求受理和傳遞過程,需求內容質量檢查和質量評審等措施,使得需求管理過程規范、透明和可控,同時保證需求質量。

4、推動開發過程的需求協同,避免開發測試返工:需求傳遞由文檔級過渡到需求內容級,使需求內容(全部或局部)和需求變更都能快速傳遞到項目管理、開發、測試和投產過程的各環節對應的任務,使項目組所有成員都在同一份需求內容基礎上開展工作,形成以需求為主線的開發聯動,自動構建起從業務需求->項目->切分系統->軟件需求->開發->測試-投產版本的跟蹤脈絡,使需求的提出到落地實現過程變得透明。

5、需求資產沉淀,形成企業級的需求統一視圖Visual RM可以幫助客戶按各類管理視角或框架(如:業務框架、應用系統框架、產品框架、組織框架)組織需求資產,通過從各項目需求文檔中抽取需求資產,并按管理框架歸集和維護需求資產,確??梢源幽騁還芾硎詠牽ㄈ紓耗騁幌低?、業務領域、產品類型等)獲取當前最新、最全的需求,以反映當前系統(或業務領域)的最新的需求全貌。

6、需求資產復用,快速編制需求:通過需求資產,需求分析人員在分析、編制需求時可以快速參考、引用需求資產內容,快速構建并形成新的需求;同時Visual RM可以支持多人協作并行編制需求,加速需求形成過程。

9、需求資產盤活與復用.png