編輯導語：工作中，難免遇到業務和技術沖突的情況。遇到這種情況，項目應該如何進行呢？筆者用自己前東家的兩種模式舉例，分析了業務技術一體化可能存在的問題和適用模式。有相關困惑的小伙伴不妨來看看，說不定***也適合你。

老讀者應該都讀過我半年前寫過的一篇文章，風險和市場打架了怎么辦，討論的是有利益沖突的職能部門的協作方式。

其實，當時我還對另一個問題非常感興趣，業務部門和技術部門，這組關系究竟應該如何協作。

市場和風險的關鍵點是利益沖突，而業務和技術的關鍵點是***門檻高，但又互相依賴。

之所以對這個話題感興趣，主要是我的前兩個老東家正好選擇了兩種不同的模式，非常有意思，可以和大家聊一聊。

01

前東家A，大型金融集團，他們對技術部門的定位就是：乙方。

開發流程非常規范，從提需求，到評審、排期、開發、交付，完全按照節奏來，部門領導聚在一起，一個季度開一次會，大家在一起排需求，排完定稿，想要中途插隊，對不起，得通過總經理室批準。

這種模式的好處就是規范、嚴謹，因為排期長，逼迫業務想清楚再提需求，一定程度上也擋掉了很多拍腦袋的需求。

缺點就是周期長、不靈活，很多時候系統開發完成，可能項目已經黃了，已經結束了。

這種模式面對簡單的業務模式沒什么問題，比如只要搞清楚人工是怎么做的，程序按照人工的方式做出來就行了。

但是到了數據驅動的階段，面對那些需求并不明確的、需要探索和創新的領域，就步履維艱了。

比如產品的定價究竟定多少？線上流程怎么設計？哪一步跳出率高哪一步跳出率低？哪些人會跳出而哪些人會堅持到底。

這些需要深度洞察客戶需要大量數據驅動，需要業務和技術融合。

公司A做不到，作為內部員工，最大的體會就是，業務條線沒有數據能力，沒辦法真正了解用戶；技術條線有數據，但對業務不了解，不知道有什么用。

簡而言之，A公司的模式就是業務提需求，技術做交付。

02

前東家B，區域領先的金融集團，采用項目制模式，他們對技術的定位就不同了，技術部門時不時會牽頭做一些項目，也就是科技引領，技術主導，業務支持。

為什么會形成這樣的工作模式，根本原因就是大領導希望有一些外部變量能夠對業務推進起到鯰魚效應，而技術領導正好又比較積極。

這種模式的好處就是快速響應，高層牽頭，很多事情當場拍板就能做了，效率很高。技術人員能從技術角度提出創新的想法，再也不是乙方了，翻身做主人了。

但這種模式的缺點也很明顯，主要有兩個：

1.項目制重建設，輕運營

其實很好理解，新建系統可以向上匯報，運營一個系統哪有新建一個系統讓人感到血脈噴張呢？

項目制模式運行久了，作為內部員工，就會發現洋洋灑灑建一大堆的系統，要么沒什么用，沒業務在上面跑，要么明明可以一個系統搞定的問題，偏偏搞多個系統維護，費時費力。

2.***方向不一致

項目制除了技術上的問題外，更大的問題在于主導權的爭奪，項目到底誰主導，聽誰的，說不清楚。

我曾經有幸參與過類似項目，一開始我很迷茫，這么多老總的要求各不相同，有的總喜歡看表格，什么圖都不要，而有的老總就是要看折線圖、餅圖，怎么辦？

但時間長了，我發現，其實直屬領導才是王道，業務部門領導的意見只能是參考，直屬領導的意見是命令。

原因很簡單，直屬領導給我打績效啊，業務部門不咸不淡的表揚又有什么用呢？

我這么想，業務部門同事自然也明白這其中的彎彎繞，隨著項目的推進，每次開會，漸漸出現了業務談業務的，技術談技術的，大家雞同鴨講。

沒辦法，大家的***沒動，自然說不到一塊去。

兩種模式各有弊端，而且還都不小，那究竟技術和業務之間應該怎么協作？

03

最近在聽華為數據轉型課程的時候，受到一定啟發。

華為提出了業務IT一體化模式，就是把技術能力建在業務上，由業務主管擔任責任人，業務人員和技術人員一起成立數字化團隊，技術人員不再是單獨的一個部門，而是成為具體業務部門的一部分，形成長期固定的組織形式。

我一聽，就感覺非常有意思，這種模式有兩個非常明顯的好處：

1.打破部門壁壘，效率更高

技術和業務兩個部門，難免會出現將部門利益凌駕于公司利益之上的選擇。

舉個例子，業務部門年底沖一把業績，提一些上線只用一兩周次的臨時需求，或者需求明明沒想清楚，但就是要提。

原因很簡單，技術資源是公司公共資源，我不搶就被別的部門搶了，我搶到了，不管上了之后到底怎么樣，總比什么都不做強吧。

于是就給技術部門非常多的壓力以達到自己的目的。

再舉個例子，技術部門不甘心做乙方，肯定會想方設法包裝自己。

業務部門的需求可能通過現有的平臺，簡簡單單就完成了，但是技術部門不會這么想，技術部門一看自己年度工作沒什么亮點，就要把一個小小的需求，以各種奇奇怪怪的名稱打造新的所謂一站式解決方案，美其名曰，為了長遠業務發展。

事實上，誰都知道，肉眼可見的未來業務沒辦法達到技術預估的量，那些所謂的場景根本碰不到。

平時公司肯定會從需求評審、后評估機制來解決這種問題，但治標不治本，除了增加一大堆莫名其妙的制度，別的一點用都沒有。

說到底，有的項目是立竿見影，有些東西沒辦法很快看到成果，僵化的制度就有點刻舟求劍，沒什么用。

但隨著業務技術一體化，就能從更高的層次，解決這些問題。

打績效的老總是同一個人，大家都是一個方向，各自的小算盤也該收一收了，很多沒意義的事情也就沒必要折騰了。

2.數據能力將成為業務的核心生產力

長期的融合最明顯的好處就是，技術人員懂業務痛點，業務人員懂技術流程，技術開發過程中，很清楚業務的目的、方向，中間不需要反復確認、了解，而業務人員也不會提出超出技術能力范圍的無理需求。

數據和業務的融合，更關鍵的是，給傳統的業務運行模式中，將數據長在業務部門內部，這樣，技術就再也不是乙方，也不是費用部門。

我們常常說，數據是新時代的石油，只有和業務緊密的結合的數據才是真正的生產要素，才能驅動業務。

業務技術一體化在我看來是解決這個問題最好的辦法，類似“支部建在連上”這一偉大創舉。

04

最后簡單聊聊業務技術一體化可能存在的問題。

我們要清楚地明白，在解決一個復雜問題的過程中，是不可能有一個方案解決所有問題的，業務技術一體化是有優勢的，但肯定不會完全沒有缺點。

回想下我公司A那種建設模式的問題，職能部門各司其職，沒辦法起到1+1>2的效果。

業務技術一體化什么后果？

自己的事情自己都能搞定，那不是部門壁壘更深了嗎？

在技術上的體現就是重復建設。業務和技術都是一個部門了，很容易自產自銷，既不愿意有求于別人，也不愿意把自己的分享出去，大家各掃門前雪，煙囪林立。

這又是另一個話題，如何沉淀各個條線通用能力，也就是這幾年很火的中臺概念，中臺的出現，就是各個部門煙囪太高，壁壘太深，必須把通用的能力沉淀下來，再賦能前端。

當然了，中臺說到底也不是萬能的，中臺的價值如何評估？中臺過重，如何靈活支持前端業務的開展，等等。

問題就是這樣一環扣這一環，所以很多事情只有開始，沒有終點，只有不斷摸索前進。

今天就這里了，希望對大家有所啟發。

本文由@一丁原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議