在專案管理過程中,需求管理是專案經理必須面對的問題,而需求變更是需求管理的重要組成部分,可以說貫穿專案始終。因此總結出幾點應對方法是非常必要的。

 

一、需求分析階段採用原型方法明確客戶需求

在軟體專案的需求分析階段,有大量需求資訊需要收集、篩選、加工,這是需求管理的開始。客戶和研發兩方面的人員對需求的理解呈現“大體上共識多,細節上差異多”的特點。即使通過反複溝通,最終在時間表限制之內也能拿出一份“客戶需求說明書”,但是以實踐經驗,客戶需求的描述永遠是“不夠清晰”、“不夠明確”的。這主要是因為在這個階段,所謂的產品都在大家的大腦中構思,正如100個人讀《射雕英雄傳》,就有100個郭靖的形象一樣,每個人的想法都是大致輪廓相同,而細節差異很大。在此階段,原型開發是一個較好的輔助手段,它將存在於大家頭腦中的虛境實實在在的表達出來,一個界面,幾個控制鍵,外觀形式固定了,功能描述明確了,這就是研發部門對客戶的需求理解。此時與客戶再次溝通,客戶基本上可以說出來:“這是我想要的”,或者“不,這不是我想要的,我要的是……”。一般情況下,原型之後的需求溝通就實際得多,雙方的理解迅速向一個折衷方案靠攏,一個可以指導研發過程的需求說明書正式誕生了。

demandchange 1

二、需求分析之後的研發過程採用嚴格的需求變更管理流程

一旦需求分析階段結束,此後如果客戶要求有新的需求加入交付的軟體系統中,需要走需求變更管理流程。這個流程必須在軟體專案成立之初與客戶約定好,一般的軟體企業內部有需求變更的管理流程,可以向客戶解釋這種管理的必要性,直至與客戶就此問題達成共識為止。不必擔心客戶不會接受,有過多次成功研發軟體專案經驗的需求變更管理流程,有著它不容置疑的合理性,這正是軟體企業的經驗和價值所在,客戶最終會理解和同意的。

需求變更管理流程各家企業有各家的做法,借用CMM的需求管理KPA來講,需要兩級需求變更管理委員會(以下簡稱CCB)來處理,即產品CCB和專案CCB。產品CCB處理涉及到產品一級的需求變化,主要體現在需要多個職能部門,多個軟體專案,以及與其他產品線的協調等問題;專案CCB處理本專案內部的需求變更,如不同小組之間的協調,接口變化等等。每一個需求都要經過CCB的審批,決定這個需求的各種屬性描述是否合適,如時間緊迫性,採用的技術是否有風險,對系統的重要程度,需求變更的波動分析,需求實現的資源狀況。在與會人員對需求屬性取得共識之後,規劃需求實現的版本,確定時間計劃。

demandchange 2

在此提醒大家,切忌對客戶提出的需求拍胸脯,在此之前可以捫心自問:“如果拍了胸脯,以後不能按時完成,我能不能負擔全部責任?”這樣冷靜一下就不會隨便承諾了。有一個比較好的方式減少這樣的麻煩,就是在需求分析階段之後,與客戶不要頻繁接觸,而是按照軟體專案的周期,或者雙方在初期的約定,定時通報軟體研發的進展。如果軟體研發採用叠代式開發,就可以在每一期交付產品發布時做這個事情,徵詢到的客戶需求將納入以後某期的軟體版本中。

三、為將要頻繁改動需求的軟體專案進行版本規劃

如果考慮到軟體專案比較大,周期比較長,如超過一年,其間的需求變化必然多得不可勝數,建議採用叠代式開發,為每個階段的產品進行版本規劃。第一個版本一般是包括了軟體系統最基本的功能,客戶最關心的功能,它的研發過程實際上還為後續版本提供了系統構架和新技術探索。一個按時交付、質量較好的版本可以讓客戶保持對專案成功的信心,並給了客戶在最終產品未出來之前逐漸接近最終產品的機會,這個過程將使客戶需求更加明確和完善,以提高最終產品的一次成功的機率。所以第一個版本的完成是專案的重要里程碑,建議專案組在此時舉行慶祝會來提高凝聚力,鼓舞員工士氣。後續的版本規劃,一般是需求的分期完善,對系統的缺陷做持續改進。這個過程將一直持續到軟體的生命周期結束。

demandchange 3

在軟體專案的研發過程中,需求變更貫穿了軟體專案的整個生命周期,如果不能有效處理這些需求變更,專案計劃會一再調整,軟體交付日期一再拖延,客戶的耐性漸漸消逝,研發人員的士氣也越來越低落,最後所有的人都在等待一個結果:專案最好馬上結束。

 

文章節錄:中國項目管理者聯盟

圖片來源:1 2 3 

 

ProjectClub 平台聚焦於提昇職場人溝通軟技巧與做事硬實力,提升您的超級競爭力讓您Work Hard 到 Work Smart

comments
標籤:

登入

會員消息

投影片庫新增PPT超酷動畫!!!

免費註冊會員!就可以獲得!!

triangle docking rl

🔵官網會員使用說明書 

🔵忘記密碼嗎??快點跟小幫手說

🔵找文章請善用搜尋功能!

🔵每天登入就有一點!!!

🔵FB註冊的朋友 帳號是你的FB姓名唷

🔵搶點數!

🔵範本軍火庫