談技術轉管理後銀行項目的管理體驗

過去的一年是從技術崗位轉到項目管理崗位的開頭年，在去年做銀行渠道類系統的項目管理過程中遇到了很多各種各樣的問題，雖然最後都得到了解決，但有的解決的好，有的解決的不太好。我一直覺得應該總結一下當時這些問題引發的思考，今天終於有時間把之前的思考梳理了一下，形成這樣一篇文章與大家分享。

1.1. 渾然一體，新陳代謝

之前作為技術人員時往往只關注自己的一畝三分地，而項目管理的職位需要有大局觀、發展觀。早期的銀行系也屬於單體應用（monolith application），後來隨著業務發展和監管的需要才拆成了目前多個子系統「各司其職、協調配合」的應用架構。大局觀就是要有整體觀念，統一規劃，統一設計。說到大局觀有這樣一個例子，多個渠道系統給用戶提供服務的視覺和交互方式應該是相似的，我們在建設新型的渠道時，需要考慮到要兼容舊有系統的交互方式。 另外還有公用系統的介面開發時也要考慮兼容調用方系統的需求，而不是把自己系統應該完成的事推給各個系統自己實現，比如錯誤碼和錯誤信息等。說到發展觀，系統是不斷變化的，有需求、設計、開發、測試、投產、運維這樣的生命周期的。這裡有這樣幾個例子，一是APP升級功能時不能只考慮新版本APP對服務端的兼容，應該對舊版本APP兼容新服務端的情況加以考慮。二是系統投產後一定要注意生產數據的增長情況，系統投產後後續的數據是在不斷變化的，比如要特別注意日誌文件的增長對磁碟空間的影響。三是有些功能是關聯在一起的，而有些開發人員修改問題時只注意當前這個問題，並不考慮其他關聯的功能，造成某個功能不倫不類。

1.2. 貼近標準，中規中矩

如今軟體項目管理的方法論已經很成熟了，針對個人的認證考試有PMP，針對軟體企業的有CMMI認證，無論從哪方面講軟體項目的流程都已經有非常明確的標準了。目前很多的小銀行的項目開發流程並不是很規範，出於業務快速發展的需要，系統建設往往急於求成，項目組人員水平也參差不齊，會跳過軟體項目標準中的多個步驟。比如，之前有個項目跳過了正式的需求確認發階段，需求是開發和業務人員通過口頭和微信確認的，在業務驗收測試時功能業務不認可這部分功能不得不返工，這又引起一系列的開發測試工作，無形中又會給項目帶來了「延期」的風險。還有就是有些開發人員分配到任務後過於自信急於動手開發，而外包廠商又因為各種原因缺少有效的功能設計和設計評審階段，這樣往往也會等測試人員發現問題後造成「返工」。總之，在項目周期允許的情況下軟體項目的標準步驟是不能省略的，項目的周期是項目經理應該努力爭取的，如果時間爭取不到的話，就一定要想方設法去減少需求和要求增加資源。

1.3. 重視風險，保障質量

項目過程中有太多的風險，而有些風險卻往往是開發測試之外的工作，會發生「黑天鵝」事件。項目過程中就發生過一個外設上生產後突然出問題的情況，本來測試過程很充分沒什麼問題了，結果廠商那邊「掉鏈子」，多虧在正式發放給客戶前做了生產驗證及時發現了問題。另外還有安全的問題，對渠道類系統安全問題也是項目中最大的風險之一，安全問題的特點之一就是問題不出則已，出問題輕則造成信息泄露影響銀行聲譽，重則給客戶帶來財產上的損失。還有就是前期的商務問題和視覺效果確認往往也會給項目帶來較大的延期風險，一是這些內容都需要領導參與，領導比較忙容易造成決策過程會比較慢；二是軟體系統工作量的不透明性和視覺效果的主觀性，也會給各方儘快達成一致造成阻礙。

1.4. 麻雀雖小，五臟俱全

軟體系統的業務功能往往只是全部系統功能的冰山一角，其背後有很多非業務功能的工作，如可用性、安全性等相關的功能。看起來很小的功能的實現或改動對系統的影響並不像看起來那麼簡單。項目過程中有時候會遇到業務覺得功能很小，實現起來應該很簡單，評估這麼多工作簡直「匪夷所思」；有時候開發自己覺得某個改動很簡單，經常聽到「這麼簡單，用不著測試，肯定沒問題」這樣的說法，覺得安排重新測試簡直是多此一舉。項目過程中，有些同事覺得兼容安卓新版本是一件很容易的事，實際上由於國內廠商的定製導致安卓在國內碎片化特別嚴重，兼容不同手機的新版本是一件特別費時費力的事，而再加上這次改動帶來的需要同時支持新老版本的安卓系統的測試相關的工作量，整個項目會比預想周期長很多。另外有個同事需要在原來的邏輯上加個判斷條件，心裡想著這事很簡單，就動手改了，結果測試發現改到另一個分支上了，整改後問題又被測試打回來了，結果是分支寫對了，但判斷條件又寫錯了，就這樣來回折騰好幾次，耽誤了很多時間，這說明無論多簡單的問題都要經過必要的測試，而不能存有僥倖心理。

1.5. 明確標準，相愛相殺

每個項目過程都少不了「就事論事」的爭吵和抱怨，而這些問題的背後多是溝通不到位造成的，除了口頭和溝通之外，標準的制定和邊界的劃分也是減少溝通的一個有效手段。項目前期對需求、對項目組的紀律加以明確和普及是減少後期扯皮問題的有效方式之一。工期緊，需求多，開發人員經驗有限導致對需求理解 不充分，在這樣一個項目里更需要明確標準，加強過程管理，在每個裡程碑階段檢查項目的完成情況，保證項目計劃得以執行。另外在項目工期比較緊張時一定加強對測試人員的需求說明講解，讓測試把問題都準確的提出來推動開發人員修改，做到「測試驅動開發」，在一定程序上可以保證項目質量。

1.6. 降格以求，求同存異

渠道類的系統有兩個特點，一個特點是被調用方太多，被調用方多的就意味著需要協調用的介面實現 方式的多樣性，實現的水平也各不相同。有的介面設計完備，代碼實現也比較理想，對接起來比較方便；而有些介面缺少設計過程，邊設計邊開發，對接起來就特別吃力。另一個特點是對視覺設計和交互設計要求高，這就意味著注意的點特別多，包括顏色、布局、提示語、交互流程等。 開發人員對這方式不注意，設計人員只顧前期設計缺乏後續跟蹤，業務人員只重點關注了幾個典型交易視覺設計和交互設計，這就給後面的項目工作埋下了很大的隱患。這兩特點決定了我們一方面在項目前期要及早溝通好介面實現和UI設計，另一方面在項目後期要抓住重點交易，暫時記錄下來並擱置非重點交易 ，確保項目如期上線，後期在其它版本中進行優化。

1.7. 依靠團隊，取長補短

項目經理的事情是很多的，既要支持生產上版本問題又要管理現在版本的進度還要參與討論未來版本的需求，這都佔用了項目經理的很多精力。當項目遇到問題時，如果無力解決時我們一定要想到依靠團隊的力量來解決，團隊不僅僅指是項目經理所在的PMO組織。部門中的每個人都有自己的長處和短處，當我們遇到生產上的問題時一定要想到求助運維的同事，搜集第一手生產報錯信息；噹噹前開發版本遇到技術難題時我們一定要聽到擅長技術的同事的意見，多方討論；當未來版本的需求遇到疑惑時我們一定要跟業務相關的同事多多溝通，彼此理解。同時我們也要結合自己的長處，為其他的同事解決問題時貢獻自己的一份力量，只有做到這樣當我們自己的項目遇到問題才容易獲得其他同事的幫助。

推薦閱讀：