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