數字化轉型：PMO項目管理六大“誤區”

姜兆華

隨著大數據、云計算、區塊鏈、人工智能等互聯網新技術的廣泛應用，科技賦能數字化轉型已成大勢所趨。加快金融科技系統升級換代，提高IT系統建設管理水平，打牢企業級系統開發“底座”根基，成為商業銀行數字化轉型的重要驅動與關鍵支撐。本文以恒豐銀行與建信金科聯合建設大型軟件系統開發項目——恒心工程為例，歸納總結企業級IT系統建設項目管理（Project Management Office，PMO）六大誤區，為商業銀行數字化轉型提供參考和借鑒。

誤區一：堅持結果第一

堅持結果導向不等于堅持結果第一。上線是工程項目交付的一個標志性結果。一切為了上線，不管過程只管結果的碾壓式推進，沒有計劃管控、沒有質量監督、沒有考核激勵，其結果將是“一地雞毛”。

歷史上最著名的豆腐渣軟件開發工程——美國聯邦調查局虛擬案件文檔系統（VCF）項目就是一個典型案例。該項目由于缺乏計劃管理，項目需求不斷變更，致使項目交付物反復延期;由于缺乏質量管理，系統上線前幾乎沒做任何測試;為了趕上線工期，甚至連系統上線前的應急預案都沒有做。從項目開發到徹底失敗，前后換了四批項目管理團隊，五年耗資1.7億美金，最終項目不得不廢棄，另起爐灶重新開發。國內外大型軟件系統開發，由于項目管理缺失造成上線失敗的案例也不在少數。

大型軟件系統開發上線過程比較復雜，但計劃管理、質量監督、考核激勵始終是工程項目管理的重中之重。

落實計劃管理。“天天編計劃，天天變計劃，計劃不如變化快”，這是工程計劃管理最令人頭痛的事情。優秀的項目計劃一定是資源、時間、任務、技術等要素的有效集成，其中至少包括計劃事項、資源配置、技術路線、交付標準、交付時間等五大關鍵要素;里程碑計劃還要拆分成若干個子計劃，執行組對照子計劃“一對一”設計執行方案。從執行效果看，項目組“里程碑”計劃按季編制為宜，執行組執行計劃按月編制為宜。做計劃的過程就是計劃分解落實的過程，讓團隊成員真正參與計劃制訂，確定的任務事項不能只在電腦系統一錄了之，而應貼在墻上隨時可見，重要事項反復宣講，盡最大程度避免窩工、返工現象;要加強任務計劃跟蹤管理，及時掌握工作動態，確保各項任務計劃入腦入心、執行落地。

嚴控交付質量。工程交付物是貫穿整個項目驗收的核心抓手。一個項目能否按期交付，很大程度取決于工程交付物的質量水平。嚴控交付質量應重點把握三大環節：一是嚴控軟件開發質量。從源頭上講，軟件開發質量依賴開發人員的業務能力和技術水平。在軟件開發過程中，通過建立需求開發分析制度，制定軟件開發標準，提高軟件系統開發質量。二是嚴控驗收測試質量。用戶驗收測試的主要任務是通過案例測試，最大程度發現交付系統存在的問題和缺陷，并跟蹤處理。系統交付用戶驗收測試前，必須保證開發方交付的軟件符合系統集成測試（SIT）標準。一旦移交用戶驗收測試（UAT）就要根據測試計劃，進行軟件配置評審、功能測試、性能測試等，嚴把軟件交付質量關。三是嚴控缺陷修復質量。對于用戶驗收測試中的問題處理和缺陷修復要制定統一復檢復測標準。強化問題處理和缺陷修復后驗收測試的系統性與連通性，保證交付驗收的一致性與統一性，避免問題缺陷“按下葫蘆起來瓢”。

強化考核激勵。考核激勵是工程項目管理的重要抓手。大型IT項目建設中， 項目組多為臨時性機構甚至是虛擬團隊， 人員組成來自四面八方，管理難度相對較大;如果沒有績效考核作為抓手，工程項目很難快速推進。工程項目的考核激勵應重點關注三個方面：一是強化計劃進度考核。將里程碑計劃拆分納入團隊、員工月度KPI考核，每月獎懲兌現，每月通報點評，將計劃完成情況和所在團隊、個人績效掛鉤，增強工程計劃的剛性約束。二是強化交付質量考核。把交付質量作為工程考核的重要維度，工程交付質量與用戶評價掛鉤，同時引入第三方監理作為工程質量的第三只“眼睛”，客觀公正地評價工程交付質量。三是強化成本控制考核。大型工程項目建設費用支出主要是軟件開發費及項目管理費用。管理成本控制重點在集中地、住宿、差旅及外包服務費用等， 其中，集中地尤為關鍵，選擇北京、上海等一線城市和選擇三四線城市作為集中地， 最大差別在于工程管理費用及人工成本的高低。以恒心工程為例，工程實際造價較預算節省10%，其中管理費用支出較預算節省45%，成本費用大幅降低，主要得益于項目管理費、外包服務費用的大幅降低。

誤區二：排斥并行迭代

大型應用軟件開發，承建方常常面臨項目需求不封版、交付標準不統一、團隊協作不緊密、客戶方案不確定等一系列問題。在保工期、保交付壓力之下，并行迭代既是敏捷開發的一種統籌方法，也成為工程項目開發不得不采取的一種“折中” 方案。

企業級系統開發與一般科技項目相比，上下游組建勾稽關系交錯、左右平衡關系復雜，系統開發難度更大。因此，企業級系統開發不能簡單套用普通科技項目開發模式，需要集合多種軟件開發模式優勢，綜合加以運用。基于此，項目組大膽采用敏捷迭代開發新方法。

實行聯合測試。將S I T（系統集成測試）和UAT（用戶驗收測試）進行聯合。SIT階段以乙方集成測試主導，甲方驗收測試前置SIT，聯合確定測試范圍、案例，將業務流程及業務功能融入SIT測試，完成一項準出交付一項。進入UAT 用戶驗收測試階段，乙方后置至甲方用戶驗收測試，利用乙方熟悉輸出系統功能優勢，對不同專項、維度、重點進行體系化重檢、補充和執行。甲乙雙方對分工負責工序設立嚴格標準。由于工作任務明確、責任標準清晰、準出準入嚴格，保證了聯合測試工作的順利開展。

采取并行迭代。并行迭代的最大挑戰是上下游間工序耦合和資源統籌。企業級項目系統開發分為數據遷移、SIT（系統集成測試）、UAT（用戶驗收測試）、數據清理補錄、總賬初始化、監管報送等七大工序。項目組采取齊頭并進，各個擊破的施工策略。七大工序、11個條線、75個執行組對照里程碑計劃，發起全面總攻。由于工序責任劃分清晰，項目經理對負責領域精益求精;每道工序反復驗證、查疑補缺、不斷迭代升級。

強化過程管控。迭代并行工藝幾乎囊括所有IT開發模式。對PMO項目管理來說無疑是一次高難度挑戰，存在諸如資源、版本、環境等不確定性風險。并行迭代成功與否關鍵在過程管控。過程管控重點在資源統籌，把資源效能發揮到極致， 強化計劃、版本、參數、環境統一管理; 過程管理難點在信息管理，把工序腳本、參數、版本、環境等最新變化，納入統一視圖管理，強化高度協同，通過雙方聯合攻關，增強容忍度，保證交付物在“不完美”基礎上逐步完善。

并行迭代猶如在鋼絲上行走，技術難度之大、協同性要求之高非普通項目所能及。其成功的關鍵在于開發測試團隊能否遵守同一規范標準、統一行動、協作排查問題;在關鍵方案選擇上，相關各方能否快速達成一致;是否有足夠權威“決策人”拍板定案。并行迭代工作法在恒心工程項目得到成功驗證，但并行迭代的項目管理方法仍有待進一步探索實踐。

誤區三：依賴管理工具

做工程項目離不開管理工具，但管理工具畢竟只是工具，工程項目可以依靠工具，但不能依賴工具。管理工具最重要的不是形式，而是有效落地執行。

統一度量衡。做工程項目，有人習慣使用Project、甘特圖等工具管理工程計劃，有人習慣用知微系統管理項目任務。不同的管理工具有不同特點，功能各有千秋，性能千差萬別。大型IT項目開發，管理工具不能共享，不能統一歸口，就會出現自拉自唱、自娛自樂的情況，不可能形成統一的項目管理視圖。因此，項目建設各方必須統一度量衡，共享管理工具，保證計劃發布、問題追蹤和任務考核統一出口，避免計劃調度、資源配置口徑不一，出現工程認知偏差。比較可行的方法是在工程項目開工前，合作方提前約定工具使用范圍、歸口管理團隊、系統使用權限和運行規則等。

關注執行力。管不住使用工具的人，使用再先進的管理工具也是徒勞的。工程施工中，最難的往往來自員工不情愿使用管理工具，有的人感覺登錄手續太麻煩，有的人排斥用管理工具管理自己。因此，項目組要最大程度發揮好管理工具的使用效能，重點關注執行力，保證工具使用者在同一語境、規定時序內完成既定任務。為保證工程任務有序執行，項目組探索實施魚骨計劃：將工程里程碑計劃按時間軸分解到班組，里程碑計劃對應業務條線、技術條線相關干系人任務目標;通過計劃宣講、掛圖作戰、月度考評等方式，強化管理工具的可視化和可執行性。

保持迭代中。科技進步催生先進管理工具，如臉書、推特、釘釘、儀表報告系統等溝通管理平臺。實踐中，企業都有自己獨特的管理方法，包括表格、指導方針、模板和核對報表等;同時，任何管理工具都不是萬能的，或多或少都存在一些缺陷和不適用性，需要不斷迭代完善。比如，任務發布沒有提醒功能，計劃完成沒有和執行人考核掛鉤等。恒心工程采用人臉識別和釘釘打卡考核員工，并將工時長短作為考核依據之一。剛推行時勞動效率明顯提升，很多人加班加點趕工期。推行兩個月后發現，人臉識別和釘釘打卡存在漏洞，有的員工在辦公樓附近打卡，有的甚至在附近酒店打卡。為解決這一問題，項目組在人臉識別、釘釘打卡基礎上增加門禁卡比對和監控視頻抽查，堵住人員管理上的漏洞。

誤區四：迷戀一套工藝

軟件項目開發一般要經過項目可研、現場部署、數據遷移、現場開發、參數配置、聯調測試、用戶測試、系統培訓、投產演練、試運行、正式上線等工藝流程。開發項目規模不同，工序流程方法也不同。大型IT項目建設一定千差萬別，項目規模越大、工序越復雜，就越需要進行差異性分析。無論先前工藝、流程、方法多么成熟，新舊系統的差異性分析始終是工程項目最重要的施工前提之一。

統一分析方法。差異性分析立足于統一分析方法，以確保新舊系統在同一語境下分析比對。差異性分析一般采用價值鏈、TOGA五級建模、FSDM金融數據模型等方法，從業務邏輯和技術路線兩個層面對組織體系、業務流程、管理邏輯、產品特性、客戶結構、數據治理等進行分類對比，找出新舊系統之間的差異點。

系統差異溯源。識別系統差異是系統差異性分析的關建，比識別差異更為重要的是對系統差異點進行溯源。系統差異溯源是對數據源中的原始記錄加以追溯，通過對比、細分、假設、逆向、演繹等分析方法，找到差異背后的因果關系，進而得出系統差異性結論。比如，新舊線總賬差異，通過舊線總賬與舊線分戶賬核對、舊線分戶賬與新線分戶賬核對、新線總賬與新線分戶賬核對等方法，識別新舊線總賬差異原因，追根溯源至產生差異的業務種類及分戶明細，鎖定差異來源。

系統差異對齊。差異性分析的最終目標是消除新舊系統差異，差異性對齊是為保證新舊系統處理規則、科目、總賬等數據信息的一致性、準確性和完整性，而采取的一系列調整措施。針對系統差異點，業務技術人員逐一研究制訂系統對齊的數據遷移方案，明確哪些是舊線系統中需要清理的垃圾數據，哪些是數倉必須遷移的歷史數據，哪些是新線系統需要補錄的信息數據，哪些是新線系統需要新增的開發需求。無論采取哪種工藝方法，系統差異分析始終是工程項目施工的重要前提。

誤區五：遠程線上支持

遠程線上支持是IT行業通行的溝通方式。很多人之所以選擇遠程線上支持，除了線上方便快捷優勢之外，還出于惰性心理，不習慣接受時間、環境約束。大型工程項目啟動最難辦的事情莫過于項目組人員大集中，大集中往往牽扯許多敏感性問題，這是很多大型項目不得不采取遠程線上支持的重要原因。但是大型IT項目建設，必須實行人員大集中，開展集約化項目管理。

組建混編團隊，強化現場管理。大型IT項目開發，甲乙雙方施工隊伍不混編，業務需求與技術開發就很難真正融合。施工雙方即使在同一樓層辦公，只要歸屬兩個不同組織，信息交流就會“打折”。因此，大型IT項目開發，首先要考慮組建“混編”團隊。組建混編團隊最大好處是資源共享、優勢互補，對項目溝通、工程推進起到至關重要的作用。通過隊伍混編，承擔共同任務目標，信息溝通更加透明順暢，資源統籌更加高效。PMO通過工程現場管理，可以隨時發現工程管理問題的隱患，而遠程線上作業脫離組織監督，一切行動靠自覺，不可避免地存在表里不一，執行力不強等管理問題。

開展專項攻關，強化問題導向。專項攻關是針對系統上線某一難題而采取的專項治理行動。項目攻關最要緊的是，準確判斷問題出現部位及問題解決方案是什么，解決問題的關鍵人是誰。搞清楚關鍵人，項目攻關才可能一路綠燈，項目進展自然會水到渠成。比較通行的做法是抽調相關業務、技術骨干組成臨時專門工作組，圍繞需要解決的難點問題，集中有效資源、合署辦公，直到相關問題徹底解決。比如，在工程建設中，項目組先后組織監管報送、手機銀行、交易銀行等27個專項攻關，保證了系統上線的賬平表對。

實行封閉管理，強化組織協同。集中力量辦大事是攻堅克難的一條寶貴經驗，這一做法對大型IT系統開發同樣適用。2020年3月，恒心工程項目啟動，由于新冠肺炎疫情散點頻發和多地分散辦公等原因，項目團隊一直未能集中作業，僅靠遠程支持和視頻溝通等線上渠道溝通項目，工程進展比較緩慢。2021年3月，項目組下決心把來自全國各地2500多人，全部集中到煙臺集中攻關，連續攻堅9個月，工程進展突飛猛進，終于在2021年11月26日成功投產，時間之短、質量之高，開創了中國金融界軟件項目開發先河。實踐證明，工程項目規模越大、工藝越復雜，越要實行集約化封閉管理。

誤區六：糾結PMO背景

PMO能力素質決定工程項目管理水平，工程項目管理水平決定工程建設品質。PMO項目管理根據職能定位，一般有以下三種管理類型：

部門級PMO管理。一般來說，規模較小的IT項目開發，往往不需要做跨企業、跨部門溝通與協調，PMO只是做為部門內部項目協調人，只要能夠按照既定需求開發程序辦理即可。在這種情況下，項目之間溝通大多限于技術層面的問題交流，很少牽涉組織管理、業務推動等問題，PMO有IT技術背景，程序需求開發可能會更加快捷。

條線級PMO管理。為快速響應業務需求，一些銀行建立IT條線PMO管理體系，跟進條線重點項目和重點工作事項，主動識別問題風險并輔助管理，提高團隊間協同和信息共享，實現信息科技從傳統支持保障向引領業務發展的戰略轉變。目前，招商、平安等股份制銀行已率先實行IT條線PMO管理體系。其中，平安銀行打造精益和敏捷雙模研發體系，推動敏捷轉型，強化科技與業務深度融合。在零售條線、對公條線推行科技派駐PMO模式，在“口袋財務”App、“FB遠程柜面”“智慧管理”等項目試點敏捷開發模式，使產品迭代速度、交付質量和客戶體驗等方面都取得顯著提升。

企業級PMO管理。對于規模較大，涉及跨內部組織體系、跨企業間協同的大型項目管理，要由企業級PMO組織推動，否則工程項目很難落地。企業級PMO管理的重要作用是從繁雜系統開發和具體業務組織中脫離出來，全視角審視影響工程質量和項目工期的問題，協調相關資源，提出問題解決方案。從企業級PMO管理定位看，PMO作為獨立且專職牽頭管理部門，其重要程度明顯高于企業其他內設部門。企業級PMO既不是工程方案的設計者，也不是項目的具體實施者，而是工程推進的組織管理者。其職責可以概括為：組織管理、協調資源、信息溝通。以恒心工程為例，工程啟動后，總行成立企業級PMO，同時成立業務委員會、IT委員會，分別負責項目管理、業務方案制訂、技術路線等工作。在總行各部門、一級分行分別成立PMO辦公室，自上而下企業級PMO組織管理體系得到健全。

從PMO工作內容不難看出，企業級PMO從事的不是單一技術管理，而是組織、協調和溝通的綜合管理。事實上，在PMO選擇上，至今都有一個爭論，即PMO是否應具有IT技術背景。在大多數技術派看來，管理大型IT項目沒有技術背景，簡直就是外行領導內行，根本無法開展項目管理;在行政管理派看來，PMO是純粹行政主管，懂不懂業務，懂不懂IT不重要，只要會管理就行了。每一個項目發起人，都希望能夠找到一個既懂IT技術，又了解業務邏輯，還有管理技巧的業務干部做PMO項目管理。然而，這樣全才PMO往往很難找到。對PMO出身背景的爭論，主要源于管理層和項目發起人對PMO的職能定位、期望值的不同。從實踐看，技術干部往往沉浸于具體研發細枝末節，而業務干部又常常糾結于外部環境變化，所以擅長組織、協調、溝通的復合型管理干部，可能是PMO項目管理的最佳人選。

（作者系山東師范大學碩士生合作導師、恒豐銀行科技部副總經理、恒心工程PMO辦公室主任）

責任編輯：劉 彪