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