在IT行業隨波逐流了多年以後，我發現了一個共性的問題，那就是無論是在傳統行業還是互聯網行業，無論是做那種業務的公司，那麼對於做業務的人和做系統研發的人來說，他們之間就會存在巨大的鴻溝，有的時候大到難以互相理解。因爲本人現在在金融科技領域，所以試圖從這個行業來進行解釋。
對於業務人員，常見疑問：
- 需要這麼長時間的開發？我需要一個月之後上線，給你加人行不行？
- 業務系統都已經在線上運行了，爲什麼還需要投入研發？
- 爲什麼有些大到不可思議的改動很快就可以實現，而有些很小的改動卻需要很長時間？
- “系統什麼都能做”到底是不是忽悠？
對於開發人員，常見疑問：
- 爲什麼需求老是變化？
- 爲什麼不找到一個最好的產品/模式，這樣系統只用開發一次就行？
- 爲什麼系統優化這麼重要的事情，都沒有人關注？
這種鴻溝無論是從認知層面還是從溝通層面都有體現，以至於他們之間的矛盾長期不可調和，那麼這到底是怎麼回事呢，又是怎麼解決呢？且看下圖：
這個圖中藍色的線表示需求的數量，綠色的線表示IT產出量，它描述了一個核心的矛盾，那就是業務訴求的變化劇烈程度遠遠超過IT產出能力的變化程度。而IT產出能力的提升有其自身的變化規律，可以描述爲：
1、在短期內，IT產出能力無法大幅提升，也就是說它有個“上限”。
IT類型的工作有一個特點，那就是短期之內不容易被替換，這種特點可以用另外一種工作來類比，那就是繪畫。對於一副畫到一半的半成品，如果換一個人來繼續畫，那麼要麼就是畫出來的畫嚴重偏離了原作者的意圖，要麼就是需要比原作者更長的時間來完成。研發類的工作有類似的規律，一個設計都是有很多的意圖或者潛在的設計思路在其中的，換了一個人很難快速以及完整的理解這些意圖和思路，以至於時間反而會花的更加長。
還可以引用另外一個段子，說一個女人花九個月就可以生一個孩子，那麼加大人力投入，九個女人是不是能夠在一個月就生出一個孩子？這種荒謬的想法卻被換了一種形式在IT行業經常發生，例如常見的人月算法，一項1個人月的事情，是否可以用5個人在6天完成？很遺憾的是大部分情況是不行的，因爲可以這樣計算的前提是系統的細分模塊互相之間關聯度很小，可以“並行開發”，但是細分到一定層次就不能再細分了，就像懷孕只能由一個女人來完成一樣，這個事情不能接力了。短期之內加人的結果就是投入產出嚴重不成正比，整體上影響其他項目的進度。
2、IT產出能力也有一個“下限”，即使沒有業務需求，研發也需要持續投入。
這是怎麼回事呢？IT系統的這個特徵也可以用另外一個東西來類比，那就是汽車。汽車買完了之後不是說就可以一直開下去，它每年是要進行維護的，換個機油，換個濾芯，噴個漆打個蠟什麼的，只不過IT系統的維護需要更加頻繁。常見的情況有：
- 依賴的第三方系統升級
- 配合安全部門、合規部門、數據統計部門、財務部門進行系統、數據改造
- 現有系統組件被檢測出安全漏洞
- 基礎網絡設施變化
- 數據量累積定期遷移
- 系統在大促期間的擴容和縮容
- 升級的客訴工單的處理
而通常這些變化和業務本身並沒有直接關係，但是又不能不投入，用一句俗話來說，管生不管養是不行的，對於C端的業務來說，一個業務系統一旦上線並正常開展了業務，那麼把業務和系統下掉就是一個漫長的過程，而無論它上面的業務是否發展的很好。當業務發展不好的系統越來越多的時候IT能力將會嚴重受制於這個“下限”，可以說是積重難返，應對業務變化的能力越來越小，速度越來越慢，整體效率越來越低。
這些特徵應該可以解答上面提到的一些問題。對於系統改動大小的問題，對於業務人員來說一般難以辨別什麼改動算是大的改動，什麼改動算是小的改動，因爲有時候覺得很難的不可思議的改動居然很快就改了，而一些看起來很小的改動卻被告知需要很長時間，這個問題其實也可以用蓋房子進行類比，開始的訴求是一個人居住，所以蓋了一間平房，然而過了五年因爲人丁興旺，需要蓋一個樓房，但是平房的地基不深，無法承載一個樓房的重量，必須重新從打地基開始建起。對於不懂建築的人來說，很難判斷什麼情況需要重新打地基，什麼情況不需要，就像不瞭解系統的人看系統一樣，很難判斷什麼是巨大的改動，什麼是很小的改動。
而對於IT系統能力的問題，可以說，IT系統的能力非常強大。從大的時間跨度來講，信息技術已經對人類生活產生了翻天覆地的變化，而且這種變化還在無時無刻的進行之中；從小的範圍來講，餘額寶這些寶寶類產品已經把人們的消費理財觀念和習慣提升了一個檔次；從一個公司的業務的角度來講，IT能力還有巨大的潛力可以挖掘。這通常會給人一種錯覺，認爲技術什麼都能實現，那麼真的是這樣的嗎？其實不然，可以分兩個層面來說：
- 原理上無法實現的東西不能實現。例如開發一個可以準確預測股市走向的系統，一個可以在短時間內破解高強度加密信息的系統。
- 原理上能實現的都能實現，但是通常會有人力物力財力的投入作爲前提條件。然而業務人員一般只是喜歡聽肯定的結論，忽視或者不願意提起隱含的前提，使得實際操作上來說不可實現。即使強行推進，也會很容易陷入無休無止的成本泥潭，進入一種進退兩難的境況，同時也錯失了業務發展的良好時機。
所以，“技術什麼都能實現”要麼是業務人員的一廂情願，要麼是技術人員剛拿完獎金的酒後豪言壯語，再要麼是一個無知少年對技術的盲目崇拜。
反過來看，對於技術人員來說，業務也是難以理解的，最大的問題恐怕就是：
需求爲什麼老是變化？
今天提的需求，過兩個星期就變了，舊的項目剛做完又要開始新的模式的新項目…爲什麼不能穩定呢？解釋這個問題其實也是很簡單，因爲業務系統是人們真實的生產生活的映射，交易類系統是人們現實交易在計算機上的一種表示，所以系統的複雜性來源於業務的複雜性，業務複雜系統就複雜，業務簡單系統就簡單，業務變化快系統就變化快，業務變化慢系統就變化慢。
對於互聯網金融交易系統來說，業務系統複雜性取決於金融業務的複雜性，其他行業也適用於這個結論。舉個例子，資管機構在控制資金端流動性風險的時候，通常會採用很多控制策略，例如每個月固定時間開放一天（月固定定開）、每個月開放一天（月開）、每個月相對某天開放（月對開）、每日開放、每週開放等，對於研發人員來說眼花繚亂毫無頭緒，系統設計的模式根本趕不上變化，隔三差五需要修改，但是對於業務人員來說，都很簡單啊，控制流動性嘛。所以對業務本質理解的深入程度直接決定了對系統進行架構的優良程度。
另外一個問題，爲什麼不能找到一個收益最高的產品，一直賣就好了？就像華爲蘋果小米的手機，長期賣的很好，爲什麼不能採用這樣的模式呢，系統也可以少開發幾套？這個問題其實也是好解釋，那就是實物商品的好壞很好判斷，但是金融產品的好壞是很難判斷的，而且實物商品品質很穩定，但是金融產品的“品質”卻很不穩定。所以無法找到一個“好”的金融產品並且一直賣下去。
還有，研發人員會對系統優化有持續的熱情，但是對系統優化的強調卻基本得不到業務人員的認同，這是爲什麼？很簡單，角度不一樣，業務關注的是交易的交易量，收入，業務的利潤等，系統優化是什麼，具體能夠對業務指標提升多少呢？如果無法明確，那麼還是算了吧。那麼這種說法到底有沒有道理呢，其實是不矛盾的，業務人員關注的是短期目標，研發人員關注的是長期目標，只是通常需要在這些目標之間進行權衡。系統優化對業務的提升通常是緩慢溫和的，但是長期來講是巨大和根本的，行業領先的金融機構例如招商銀行，二十年來一直在系統方面大力投入，積累起來的綜合實力已經使其遠遠領先於其他金融機構，並且競爭壁壘極高，難以複製。
綜上所述，業務人員和研發人員的分歧往往來源於自己的認知領域的不同，對於同一件事情在不同的角度觀察的不同，對於短期目標和長期目標的認知不同。但是IT產出能力與業務需求的變化之間的矛盾卻是一個長期和固有的矛盾，這個矛盾恐怕不能消除，但是可以不斷的緩解：
1 提升IT產能
通過多種方式可以將IT提升業務的“上限”持續提升，例如：
- 增加人員。當然遠水不解近渴，加人可以在中長期提升產能，但是短期不能。
- 增加時間。對於大部分互聯網公司來說，這點上面已經做得“很好了”，但是這種方式最嚴重的問題就是不可持續，而且有天花板，就是到了一定程度再怎麼增加時間也不能繼續提升產能。
- 優化流程。同樣幾件事情，如果換一種方式做就會更加高效，舉個例子，研發和測試的邊界點，在目前的實踐中普遍採用了研發面對面交付測試的模式，雖然對研發帶來更多的工作量，但是整體效率卻提升了。
- 優化架構。同樣一個目標，如果換一種實現方式或者思路，就能更快更好的完成，例如非業務功能儘量中臺化，可以稱之爲“拿來主義”，使用第三方提供的公用平臺可以加快系統建設速度。
- 需求排序和分期。在短期產能無法快速提升以及架構無法短期優化的情況之下，怎麼緩解需求矛盾呢，這個時候就需要仔細評估需求的投入產出比，或者依據項目的重要程度進行一定的排序了，實際情況是每個項目都很重要，每個項目都很緊急，但是再緊急也需要排序，從中找到當下最需要做的事情，這個當然是需要業務人員和研發人員密切配合才能進行。
2 降低系統維護難度
其實是降低IT產能的“下限”，使得最低投入越來越小，例如：
- 業務下線。通常一個業務上線了之後會運行很長的時間，出於合法合規的要求，一般的業務一旦有了存量，那麼除非用戶主動同意，否則是無法對用戶進行清倉的，從而導致即使業務發展較差甚至虧損也不能將業務下線。這個情況直接導致各種各樣的系統一直存續，按照上面的分析，IT能力的下限將會變得很高，也就是固定投入將會是長期和持續的，所以需要把業務下線也作爲一個重要的事項來推進，簡單來說，業務人員不能只是關注上線一個又一個的業務，也需要關注下線一個又一個的業務。下線的過程仍然是需要業務、運營、系統研發各方的密切配合，其結果將有效降低固定IT投入，同時還能提升IT能力上限。
- 系統優化。俗話說，磨刀不誤砍柴工，系統優化和升級是個長期和不斷需要進行的事項，因爲它會長期和有效的提升IT產能，這個是業務人員通常會忽視的事情。拿跑步來說，穿一雙不太舒服的鞋子一樣能夠跑，那麼是否需要換一雙好點的鞋子？這個問題，通常在短期很難看到效果，長期來講會得到很好的收益，但是業務人員通常迫於眼前的壓力，會選擇不是很好的方案，並在壓力解除的時候也不會主動推動系統優化。
簡單來說，業務人員和技術人員需要真正深入的互相理解和互相配合才能解決效率問題，因爲從業務盈利的目標上來講，兩者是密不可分的。
本文轉載自公衆號京東數科技術說（ID：JDDTechTalk）。
原文鏈接：