首頁>項目管理 > 正文

福建農(nóng)信需求變更管理的思考與實踐

2018-11-09    來源:蔣穎璇 新金融世界雜志
      求變更在軟件項目中是經(jīng)常發(fā)生的,許多項目失敗的根源就是需求變更失控;金融行業(yè)由于自身的特殊性,對于系統(tǒng)的穩(wěn)定性、安全性與可用性要求更高。如何管理來源眾多、紛繁復雜的需求變更請求,成為每個銀行軟件項目必須重視的問題。本文針對當前銀行軟件項目需求變更管理中存在的一些問題,提出福建農(nóng)信需求變更方法論,并據(jù)此總結(jié)在有效管控軟件項目上的實踐經(jīng)驗。
  需求變更在軟件項目中很常見,設(shè)計初期的不合理、后續(xù)需求的追加及成本控制等因素都會導致需求變更。每一次的需求變更,對項目成本、軟件質(zhì)量、交付時間而言,都是一次沖擊與考驗。2004年,美國麻省StandishGroupInternational公司公布了一項調(diào)查數(shù)據(jù),在已完成的13522個軟件項目中,絕對成功的項目僅為29%,徹底失敗的項目為18%,受到質(zhì)疑的項目高達53%。受到質(zhì)疑的項目包括費用超支、超出工期的項目。在項目不成功原因的調(diào)查中提到最多的就是“需求變更”。
  由上可知,軟件項目需求變更必然出現(xiàn),影響深遠,甚至決定項目的最終成敗,故銀行軟件項目建設(shè)過程中要規(guī)范管理,根據(jù)項目推進過程中越來越豐富的項目認知,不斷調(diào)整項目開展方向和資源配置,對各方提出的需求變更申請進行匯總管理,方能最大程度地滿足客戶等相關(guān)干系人的需求,避免需求變更失控,提升項目價值。為此,筆者將就銀行軟件項目的特點,描述需求變更管理基本原則,結(jié)合福建農(nóng)信的特點,提出適合銀行乃至二級法人的需求變更方法論。
 
銀行軟件項目需求變更的來源和影響
  
      銀行軟件項目需求變更來源廣泛,與傳統(tǒng)軟件企業(yè)需求變更差別在于對穩(wěn)定性、安全性與可用性要求更高,根據(jù)其產(chǎn)生原因?qū)⒅攸c幾項概括為:
 ?。ㄒ唬╉椖啃枨蠓治鲭A段的偏差,包括:產(chǎn)品范圍定義的偏差、業(yè)務(wù)規(guī)則不合理,例如網(wǎng)易貸平臺項目組對貸后預(yù)警功能提出需求變更申請,要求由原來的僅POS貸進行貸后預(yù)警改為全線產(chǎn)品進行貸后預(yù)警,修改了原有不合理的業(yè)務(wù)規(guī)則,使系統(tǒng)更符合實際需求;
 ?。ǘ╉椖繉嵤╇A段中的意外狀況,包括:應(yīng)對風險的緊急措施或規(guī)避措施、項目執(zhí)行過程中無可避免的被動調(diào)整、團隊人員調(diào)整、外部事件,例如福萬通e平臺項目出于規(guī)避風險的考慮,新增對每人每月開戶次數(shù)的控制,提高了風險防控能力;
  (三)隨項目發(fā)展提出的必要變動,包括:市場戰(zhàn)略調(diào)整、技術(shù)革新要求、新政策出臺等,例如:福萬通e平臺項目中電子賬戶注冊時的“四要素認證”根據(jù)人行302號文件變更為“五要素認證”,新增了對賬戶類型的校驗,滿足了監(jiān)管的要求。
  
銀行軟件項目需求變更對軟件開發(fā)的影響是多方面的,包括:
  
       (一)增加項目的人員和費用開支,影響開發(fā)進度。
在一般的項目計劃中,對需求變更都有一定預(yù)算,需求變更往往意味著業(yè)務(wù)規(guī)則的重新梳理、代碼接口的重新設(shè)計、測試工作的反復,大量的、頻繁的需求變更無疑會增加項目人員的工作量、費用開支;而需求變更失控往往會導致生產(chǎn)問題無法得到及時解決、經(jīng)濟損失無法挽回、項目延期交付等問題,增加了項目的實施風險,嚴重時可能直接導致項目的失敗。
  (二)影響軟件質(zhì)量。
銀行軟件項目關(guān)聯(lián)系統(tǒng)過多,需求之間總是具有一定關(guān)聯(lián)性,相關(guān)需求形成需求鏈。一個業(yè)務(wù)規(guī)則的變更,小則影響關(guān)聯(lián)交易,大則影響至外圍系統(tǒng)。如果變更提出、評審時遺漏需求鏈中的某些環(huán)節(jié),就可能在變更實施中引入一些難以察覺的錯誤,投入生產(chǎn)后就會出現(xiàn)非但沒有優(yōu)化功能,反而影響到的其他正常交易的情況,比如新增放開電子賬戶的柜面操作時,就需要對調(diào)用到改動的接口的其他柜面交易進行測試,不可影響原有功能的實現(xiàn)。
 ?。ㄈ┯绊戦_發(fā)部門與業(yè)務(wù)部門的合作關(guān)系。
軟件項目是業(yè)務(wù)部門與開發(fā)部門之間的一種相互信任、相互合作的過程。如果二者之間在軟件需求變更上產(chǎn)生不同意見,而且沒有得到妥善的處理,將會導致二者之間的合作關(guān)系破裂,甚至造成軟件開發(fā)中斷等嚴重后果。
 
需求變更管理的基本原則
 
  需求管理涉及3個主要問題:將需求進行標識、分類以及組織,為需求建立文檔;管理需求的變更,說明不可避免的需求變更是如何被提出、協(xié)商、確認的,并且將整個變更過程記錄在案;對需求進行跟蹤,保持需求和軟件產(chǎn)品之間的一致性,及相互關(guān)聯(lián)性。需求變更是缺陷放大的一個體現(xiàn),若不能正確面對并加以實質(zhì)性地解決,需求變更未能及時處理所造成的影響將可能被放大,甚至導致不可挽回的嚴重后果。因此,需求分析人員、軟件設(shè)計開發(fā)人員應(yīng)當建立需求變更管理的基本原則,主要包括以下方面:
 ?。ㄒ唬┻M行項目基準管理
  需求變更管理貫穿項目始終,并應(yīng)用于項目的各個階段,項目經(jīng)理對此負最終責任。對于項目管理計劃、項目范圍說明書和其他可交付成果需要通過謹慎、持續(xù)地變更管理。項目計劃一經(jīng)批準,就成為項目執(zhí)行和考核的基準,也只有經(jīng)過規(guī)定的變更程序才能做出修改。在一般銀行項目中,業(yè)務(wù)是骨,技術(shù)是肉;業(yè)務(wù)是業(yè)務(wù)規(guī)則的制定者,技術(shù)是業(yè)務(wù)規(guī)則的實現(xiàn)者,二者相輔相成,缺一不可;技術(shù)需要在業(yè)務(wù)確定系統(tǒng)功能、業(yè)務(wù)規(guī)則的基礎(chǔ)上進行程序設(shè)計,如果項目計劃在一開始就漏洞百出、含糊不清,那么后期業(yè)務(wù)與開發(fā)的溝通勢必出現(xiàn)相互推諉,浪費時間與精力,嚴重影響項目進度。
 ?。ǘ┙⒆兏刂屏鞒?/span>
  變更的過程應(yīng)該有嚴格的控制,確保只有經(jīng)過批準的變更才能進行修改。所有的變更請求都必須以書面形式記錄,并納入變更管理以及配置管理系統(tǒng)中,按照變更控制系統(tǒng)和配置控制系統(tǒng)中規(guī)定的過程進行處理,保證有跡可循。需求變更可能來自業(yè)務(wù)部門、開發(fā)部門、運維部門,只有將各方需求變更納入規(guī)范化的管理,才能保證業(yè)務(wù)需求、架構(gòu)設(shè)計的合理性、一致性、完整性、準確性,避免出現(xiàn)矛盾、混亂。
 ?。ㄈ┙⒆兏刂莆瘑T會
  每項記錄在案的變更請求都必須由一位責任人批準或否決,該責任人應(yīng)該在項目管理計劃或組織流程中被指定。必要時,由變更控制委員會(CCB)來決策是否實施整體變更控制流程。CCB應(yīng)是一個正式組成的團體,包括項目經(jīng)理、業(yè)務(wù)代表、開發(fā)代表、測試代表,負責審查、評價、批準或者否決項目變更,以及激勵和傳達變更處理決定,組織驗證被修改的配置項。
 ?。ㄋ模┩暾w現(xiàn)變更的影響
  變更控制的具體實施程度,取決于項目所在應(yīng)用領(lǐng)域、項目復雜程度、合同要求,以及項目所在的背景與環(huán)境。變更請求得到批準后,受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更,以保持和更新的需求一致,比如:需求規(guī)格、架構(gòu)設(shè)計、成本估算、活動排序、進度日期、資源需求和風險應(yīng)對方案分析。
 
福建農(nóng)信需求變更實踐方法
 
  由于福建農(nóng)信二級法人體制,導致各行社發(fā)展不平衡,存在較多個性化需求,一個軟件項目總是難以同時滿足所有行社的發(fā)展需要,在項目開發(fā)乃至后期運行階段就會存在各種需求變更請求,變更申請的管理就顯得尤為重要;此外,福建農(nóng)信系統(tǒng)復雜,特別是涉及外圍系統(tǒng)多的項目,每一次的需求變更往往需要其他系統(tǒng)的配合改動,風險較大,在管理上更需嚴謹。針對這種現(xiàn)狀,福建農(nóng)信提出了項目變更規(guī)程,規(guī)程通過定義項目變更的全過程,指導項目組有效地控制項目處理進程,保障項目的順利實施和項目目標的達成。結(jié)合需求變更原則,實踐的項目的流程如圖所示:
(一)項目變更請求。
      項目經(jīng)理收集可能導致項目范圍、配置項和/計劃調(diào)整的變更請求(《需求變更申請單》),對收集的變更申請單,進行初步整理后,提交CCB評估。項目變更請求范圍,包括但不限于:
  1.項目關(guān)鍵時間點變化,如:里程碑時間點、投產(chǎn)時間點;
  2.需求變更;
  3.設(shè)計變更,如:架構(gòu)設(shè)計、軟件設(shè)計、數(shù)據(jù)庫設(shè)計;
  4.因需求或設(shè)計導致的代碼變更;
  5.因需求或設(shè)計導致的測試方案、測試用例的變更。
 ?。ǘ〤CB評估。
      CCB(CCB即變更控制委員會,成員至少包括項目經(jīng)理、業(yè)務(wù)代表、開發(fā)代表)對收集的變更申請進行初步判斷,提交需求部評審;
 ?。ㄈ┬枨蟛吭u審。
      需求部組織對通過CCB評估的《需求變更申請單》進行評審,判斷是否接受這些變更,并判斷這些變更是否影響了項目的關(guān)鍵時間點:
  1.變更涉及到需求規(guī)格調(diào)整,執(zhí)行4-更新需求規(guī)格;
  2.變更涉及到架構(gòu)調(diào)整,執(zhí)行5-更新架構(gòu)設(shè)計;
  3.需要提交計劃變更申請,執(zhí)行6-項目重估算、重計劃;
  4.涉及其它配置項變更,執(zhí)行7-更新受影響的配置項。
  (四)更新需求規(guī)格。
      業(yè)務(wù)代表根據(jù)《需求變更申請單》中的內(nèi)容,組織更新《需求規(guī)格說明書》。更新后的《需求規(guī)格說明書》應(yīng)提交需求部進行審核,如審核不通過,應(yīng)繼續(xù)進行修改。
 ?。ㄎ澹└录軜?gòu)設(shè)計。
      開發(fā)代表根據(jù)《需求變更申請單》內(nèi)容,組織更新《架構(gòu)設(shè)計說明書》。更新后的《架構(gòu)設(shè)計說明書》應(yīng)提交開發(fā)部進行審核,如審核不通過,應(yīng)繼續(xù)進行修改。
 ?。╉椖恐毓浪恪⒅赜媱?。
      當變更內(nèi)容導致需要提交計劃變更申請時,項目經(jīng)理應(yīng)依據(jù)變更內(nèi)容組織進行重估算,并依據(jù)估算結(jié)果更新項目計劃包(含總體計劃和進度計劃),并作為計劃變更申請的輸入和附件。
 ?。ㄆ撸└率苡绊懙呐渲庙?。
      一般由項目經(jīng)理或開發(fā)代表指定變更實施人。變更實施人根據(jù)《需求變更申請單》內(nèi)容,檢出已經(jīng)基線的相關(guān)配置項,對配置項實施變更操作。
 ?。ò耍┙M內(nèi)計劃調(diào)整。
      當變更內(nèi)容不需要提交計劃變更申請時,項目經(jīng)理根據(jù)需要調(diào)整并更新項目計劃包(含總體計劃、進度計劃),并通知組內(nèi)成員及其他受影響的相關(guān)方。
 ?。ň牛┯媱澴兏u審。
      項目經(jīng)理根據(jù)需求部評審結(jié)果,向計劃評審小組提交計劃變更申請。計劃評審小組根據(jù)需要組織相關(guān)方對調(diào)整后的《項目計劃包》和《需求規(guī)格說明書》《架構(gòu)設(shè)計說明書》。
 ?。ㄊ┳兏鼪Q策確定。
      項目經(jīng)理根據(jù)技術(shù)評審小組結(jié)論,提交更新后的《項目計劃包》給業(yè)務(wù)部門和科技部領(lǐng)導進行審批。如審批不通過,應(yīng)進行重新修訂。
 
  福建農(nóng)信項目變更規(guī)程嚴謹定義了從提出變更請求,經(jīng)需求部評審后并更新受影響的配置項,到涉及項目關(guān)鍵時間點變動時提交上一級管理層進行變更決策的全過程。具體做到了以下幾點:
      
      1.流程規(guī)范。
      該規(guī)程正式版于2013年首次發(fā)布,要求項目組對需求變更進行帶準入的收集整理以及系統(tǒng)化的處理跟蹤、各部門嚴格按照規(guī)程對需求變更申請進行規(guī)范化的評審,避免雜亂無序的需求變更造成CCB成員負擔;避免因未經(jīng)評審的不合理的變更請求對代碼、配置進行隨意的改動;避免遺漏對關(guān)聯(lián)需求點的系統(tǒng)改造;確保更新需求規(guī)格、更新架構(gòu)設(shè)計、更新受影響的配置項、項目重估算、重計劃、組內(nèi)計劃調(diào)整等環(huán)節(jié)未被忽略。
  2.評審嚴格。
      CCB對收集的變更申請進行初步判斷,需求評審部門在收到書面的需求變更申請單時根據(jù)實際情況組織原需求評審人員進行線上或線下的需求評審會,控制時間,保證質(zhì)量。評審前,要求評審人員對項目原先需求、變更內(nèi)容以及現(xiàn)狀進行深入了解;在評審階段,評審人員充分聽取各部門、各方面意見,例如涉及會計科目變更的,就應(yīng)要求經(jīng)過財會部門的審批;需求變更評估要求初步確認需求類型,分析開發(fā)資源,分析關(guān)聯(lián)業(yè)務(wù)的需求合理性、安全性及全面性,確認進度計劃,關(guān)注變更時間和成本的影響;必要時將項目組提出申請時未考慮到的關(guān)聯(lián)項目關(guān)聯(lián)功能包含進來進行綜合評估;綜合考慮最終形成處理意見,接受或者拒絕變更請求。
  3.基線化管理。
      根據(jù)項目計劃和項目配置管理計劃,在項目開發(fā)的不同階段,均有建立相應(yīng)的基線,將相關(guān)的配置項納入變更管理。同時,將配置狀態(tài)報告發(fā)送給各相關(guān)方,相關(guān)方都能及時了解項目進展狀況,和項目的變更情況。
  4.建立變更跟蹤機制。
      實際研發(fā)過程中,往往由于需求變更缺乏跟蹤,帶來許多問題。軟件項目建設(shè)中,福建農(nóng)信通過建立變更跟蹤機制來加強管理,建立與維護“需求-開發(fā)-測試”的一致性,確保所有工作成果符合項目需求。在《需求規(guī)格說明書》完成后,或需求變更通過CCB批準后,需求人員建立《需求跟蹤矩陣》,保存到SVN項目文件夾下,以作跟進。
  5.進行有效溝通。
      項目進行過程中應(yīng)當強調(diào)成員間的溝通,避免不必要的反復的變更增加開發(fā)工作量。實際工作中很多變更其實只是由于業(yè)務(wù)人員與開發(fā)人員對需求的理解不一致,而有效的事前溝通是可以降低需求變更的頻率的。例如:e平臺電子賬戶登錄用例中,對于輸入格式錯誤的登錄密碼是否計入錯誤次數(shù)等隱性規(guī)則是存在疑義的,但經(jīng)過項目組內(nèi)有效溝通,最終確定方案就避免了不必要的需求變更。故需求討論時,開發(fā)人員與業(yè)務(wù)人員應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度,積極尋求可行的替代方案。既然需求變更是必然的,那項目成員就應(yīng)當注重采用各種溝通技巧來使各方的利益達到綜合的最大值。
  變更管理本身并沒有一成不變的規(guī)則,福建農(nóng)信根據(jù)自身情況,以積極的態(tài)度,進行完整而合理的考慮,嚴格規(guī)范執(zhí)行流程,進行了有效科學的需求變更管理,規(guī)避需求脫離控制、產(chǎn)品與預(yù)期不符等不利影響;但科技發(fā)展的腳步不會停,改革創(chuàng)新的腳步也不應(yīng)該停,作為農(nóng)村金融的主力軍,福建農(nóng)信將保持嚴謹態(tài)度的同時,不斷完善項目建設(shè)規(guī)程,使得項目需求明確,開發(fā)有跡可循,項目運轉(zhuǎn)有序高效,最終產(chǎn)品才能更加符合客戶需求、市場需求,進而提高經(jīng)濟收益。
 


分享到:

免責聲明:
  1、項目經(jīng)理人發(fā)布的所有資訊與文章是出于為業(yè)界傳遞更多信息之目的,并不意味著贊同其觀點或證實其描述。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實,對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請瀏覽者僅作參考,并請自行核實相關(guān)內(nèi)容。
  2、本站部分內(nèi)容轉(zhuǎn)載于其他網(wǎng)站和媒體,版權(quán)歸原作者或原發(fā)布媒體所有。如文章涉及版權(quán)等問題,請聯(lián)系本站,我們將在兩個工作日內(nèi)進行刪除或修改處理。敬請諒解!

關(guān)于我們 聯(lián)系我們 版權(quán)聲明 隱私保護 投訴建議 卓橡資源

Copyright ? 2021 項目經(jīng)理人 版權(quán)所有 京ICP備17062359號-3 如轉(zhuǎn)載本站文章,請注明原作者和原發(fā)布媒體
本著互聯(lián)網(wǎng)分享精神,本站部分內(nèi)容轉(zhuǎn)載于其他網(wǎng)站和媒體,如稿件涉及版權(quán)等問題,請聯(lián)系本站進行刪除或修改處理
客服電話:010-89506650 89504891 非工作時間可聯(lián)系:18701278071(微信) QQ在線:511524637
新聞與原創(chuàng)文章投稿:tougao#cpmta.com 客服郵箱:info#cpmta.com(請將#換成@)
項目經(jīng)理人——我國項目經(jīng)理職業(yè)發(fā)展門戶網(wǎng)站,隸屬卓橡公司