如果想在金融軟體（銀行軟體）這方面長期發展,發展到後期是需要金融業務知識多些還是計算機技術多些?

12-31

發展到後期，這個要命了，我自己都沒發展到後期。

集合自身說說吧。

銀行軟體很多很雜，通常是一個或幾個核心系統（core banking一個，card一個）帶著無數所謂外圍系統（各種報表，各種財務，各種風險，各種反欺詐，各種信用評級，各種反洗錢，各種數據倉庫等等子系統）。

我是做核心系統的，就拿我自己畢業以後來說吧，一開始的3年是悶頭coding。

其中第一年是看到leader給的TS就扣，一扣就是15個國家的程序一起改，把TS中的需求插進這15個國家的代碼中（TS中一般是偽代碼，並且告訴你需要改的程序名，如果程序很大甚至告訴你需要改的段落）。改完調試，測通以後給出before和after的test result。這個過程中需要搭模擬環境，造case，處理error等等，不斷吸取經驗教訓，提升自身等級。

第二年開始做24*7的生產維護，TS還是照給，代碼還是照扣，額外增加不定時的call，比如深夜2點某critical job abend了，操作員把你從被窩拉出來，問你該咋辦，不跑完明天某國銀行開不了門。你看情況看下是否能繞過，不能的話就要臨時改代碼（如果是代碼邏輯問題的話），然後roll back數據，把改完的程序重跑（通常是由其他人改了某段代碼引起的，用回以前邏輯一般都能解決），然後再issue log上面記上一筆，明天告狀。萬一悲催的找不到問題原因，並且耗時超過30分鐘，你就必須把你老闆從被窩裡面拉出來，告訴他情況，看他有沒有啥辦法，層層上報直到CEO（基本沒發生過）。

通過這兩年地獄式coding，基本上你看一眼代碼和程序所在位置，就能大致估出來這個東東是在幹嘛了，第三年你拿到TS後，可以跟你老闆要一下FS看看了。一般FS是把用戶原始需求轉化的第一層，你可以看看用戶為啥要有這個要求，要達成什麼目的，一般這些就是所謂的業務知識。然後你可以對TS發表一些看法，比如在兩條大路通羅馬的情況下為啥走這條不走那條之類，多和leader討論討論。

第四年我轉到另一個核心系統，卡系統開始重新學習，因為有以前的經驗，第一年基本把我上述3年的東西全部掌握，開始通讀一些卡系統最核心的代碼，通常最核心代碼是常年沒人動的，因為這些是屬於最基本功能，不會減也不會改變，而且長的令人髮指，調試極具難度。

第五年，當你讀完最核心的那些代碼，你的眼光可以放到interface上，也就是核心系統和其他外圍系統的交換文件上，基本上你也能知道為什麼某個文件需要有某個field，某個field為什麼是必須而有些field是可選。Interface了解完，順杆子網外圍系統走，看看界面，看看出錯反應等等，繼續積累技術知識，當然這個需要機遇。

第六年，基本上應該能做上項目經理的位子了，當然是偏向技術的項目經理，不管預算。多接觸用戶，明白他們想要什麼就成了你的當務之急，由於你有深厚的技術積累，你很容易知道某個業務需求該通過何種方式來滿足。同時你要大量關注政策，因為絕大部分業務需求是來自政策變化。多和產品經理聊聊，問問看他們銷售的難度在哪，從中發掘系統的改善點。多和風控聊聊，看下他們顧慮是什麼，監管部門的要求是什麼，防止在給出解決方案的同時，增加了風險。多和操作員用戶聊聊，看下平時他們大量時間花在哪裡了，是否是機械式的工作，能否用程序幫他們減少人工干預。

基本上就這些。。。。我自己還在第七年中。。。。。

首先，直接的答案是都重要也都不重要，勤奮最重要。

多解釋幾句，「後期」的事情並不需要現在就開始擔心，因為你有「前期」和「中期」大把的時間去為「後期」作準備。我猜題主應該還沒有入行，入行之後多學，多看，多問，自然就知道自己的發展方向在哪裡了，然後為那些東西去努力，一切水到渠成。

入行快十年了，一直在做主機的核心系統....

記得剛入行培訓的時候就聽前輩們講過，」在銀行做系統只要會加減乘除就夠了....「。

這句話在某種程度上確實是真理，coding代碼總被要求，

要保證後期程序的可維護性（來個傻子都能隨便看懂）；

不要使用指針（還是因為很多人看不懂）；

不要用goto到處亂跑（看不懂呀，看不懂）；

多寫注釋，增加可讀性；

……

所以，對剛入行的新人，coding是個挺簡單、很容易上手的活。

開始的兩年，基本上就是從簡單的邏輯修改（肯定不會是記賬的邏輯）、寫幾個不重要的批量（寫錯了能重新跑的報表）之類的活開始干起，慢慢的開始接觸生產運維。成長快的新人，到第二年後期的時候，已經可以7*24小時的，當二、三線支持了。

在這個過程中，接觸到的更多的就是各種業務知識（出了諸如死鎖、臟讀之類的bug，基本也輪不到你解決），建議在這幾年中利用各種程序上手的機會以及空餘時間多讀代碼，要搞清楚自己的程序在整個業務流程中和技術架構中的位置，起碼要在這個層面上，來理解自己的交易；在技術層面上，要關心與外部介面的調用關係、內部介面的實現邏輯（不要光知道個功能就完了）。

自己的感受就是你要能在自己的腦子裡，把這個交易跑起來。

經過了兩年的訓練，一般在三、四年的時候，大多數同學在自己負責的交易上，都可以自己寫詳細設計（偽代碼）來修改程序了。相關的項目，都會將你作為聯繫人（干係人、協辦人…）來配合開發。

經過幾個項目的磨練，就可以作為項目經理（實際上應該是技術經理）帶相關項目了。

對於項目經理的要求是，

第一，
是能夠恰當的與業務人員討論需求，最低的要求是能夠識別出系統不能實現的需求，進一步就是要求能否識別出業務需求互相矛盾的地方(真的遇到過直接把行業規範拿過來當需求的不靠譜業務人員……)，再進一步就是能夠識別出真實需求；

第二，
是在開發時能夠預先考慮後續的需求發展，留出下次升級的空間（或者是減少下次升級的風險）；

至於所謂的架構的考量….還離得太遠，小型項目很多都是優化改造類，很少會涉及到架構的變動。

在這個期間內，更多的還是業務知識和系統實現知識的儲備，而且所有的儲備要儘可能的橫向獲取，要儘可能的關心別的項目組的工作內容。

做個人業務的有時間要知道些對公業務的知識、做存款的要知道些貸款的知識.....更主要的原因是，跨條線的組合需求越來越多，起碼在談需求的時候，不能出現雞同鴨講的情況。甚至反過來，可以引導業務部門的需求思路，提出更好地需求建議。長此以往下去，業務部門的同事也會信任你，在這個小圈子內的口碑也會越來越好。

但是慢慢的發展下去，越來越大的項目會壓到你的頭上。會要求你更多的關心各種技術細節。比如運行壓力到底會有多少、是否有額外的監管要求、如何平衡日後的可擴展性、運行效率和運維效率，基於此項目應怎樣設計.....你會越來越多的考慮上述的這些要素，而並非是業務知識。

前幾年技術以後基本靠業務

這行做到最後都是在做業務。可能頭五年偏向技術多一些，之後基本全面偏向業務，因為你的身份在五年後不太可能還是個工程師了，要不項目經理、要不售前、要不諮詢顧問

業務

一半對一半吧。我的身邊有業務出身但現在玩起了技術。