業務和技術融合的突破口：幫助業務人員了解軟體開發

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

早在 1987 年，從 Zachman 先生提出企業架構的開端——“Zachman 架構”開始，B 端軟體開發就開始關注企業的全景資訊，而非僅僅是瑣碎的需求，這也意味着，隻有開發人員更好地了解了企業整體，才有可能讓 B 端軟體成為提升企業整體管理能力、創新能力的武器。

但是，企業架構一路起起伏伏的發展讓人反思一個問題：開發人員如何才能更好地了解企業整體？顯然資訊隻能從業務人員那裡來。如何更有效地獲得這些資訊？除了筆者經常談的企業級業務架構外，另一個答案很可能會出乎意料——應該先努力讓業務人員了解開發。

獲得資訊的有效途徑當然是交流和溝通，業務制度、流程圖這些都是“死”的，“活”的資訊隻能來自于不同層級的業務人員，而有效的交流溝通并非單向的，不是業務人員單純向技術人員“傾述”，如同兩個人交往一樣，越是互相深入了解，溝通才能越有效率。面對日益膨脹的軟體需求，技術人員需要向業務人員普及下到底什麼是軟體開發，軟體開發關注什麼，也許隻有業務人員了解了軟體開發關注什麼，才能更好地解釋業務關注的點和技術關注的點是什麼關系。

“技術的歸技術，業務的歸業務”，這種泾渭分明的思想要不得。時代在發展，數字化時代需要勞動者技能發生改變，結構化思維是數字化時代很重要的業務思維方式，而數字化産品也是數字化時代最主流的産品，軟體将是最主要的生産工具，無論從以上那個角度講，技術人員都有義務幫助業務人員更好地了解軟體開發，以提升溝通效率，業務人員也應當更加積極主動地了解這些知識，進而推動業務思維的轉變。打破了解的鴻溝，業務與技術才有深度的融合，而兩者之間的差距也許沒有大家想想的那麼大。

一、軟體也是一種“業務”

（一）軟體過程與業務過程的相似性

軟體開發關注的核心問題主要是過程與設計，也就是軟體工程和軟體設計，前者關注的是軟體的生産過程，後者關注的是軟體的設計方法，其實這兩個核心問題在思維模式、工作套路上與業務人員的工作也是很相似的，完全可以很好地解釋給業務人員聽。軟體開發關注的主要問題如下圖所示：

軟體過程主要是從工程管理的角度研究軟體生産過程的工序、标準，按什麼樣的方式和順序組織生産，每個生産環節該達到什麼樣的标準，這樣做的核心目的是為了提高軟體的品質，減少 BUG，也是為了盡可能通過科學地安排工序，縮短軟體開發時間，進而提高産量。

技術人員對軟體過程的關注其實與業務人員對業務過程的關注沒有什麼本質差別。業務人員推出一個新業務産品時，也要關注産品的全生命周期管理，從需求收集、市場調研到産品設計、内部審批，再到試運作或者上市，之後關注營運、客服，這也是一個基于工序和标準的管理；業務人員也經常研究如何優化内部流程加速産品上市，如同技術人員研究工程模型一樣；業務人員對業務的關注也集中在産品品質上，不違規、不給客戶帶來困擾；最後，業務人員對産品流程的優化也包含着讓客戶在更短的時間、更好的體驗中快速獲得産品，也就是對産量的關注。并非由于技術人員生産的是軟體，二者就搞出了多大的底層思維的差别。

（二）軟體設計與業務産品設計的相似性

軟體開發中關注的另一個問題是軟體設計，設計中最重要的部分是架構設計，架構設計關注的核心是結構和關系，如何劃分子產品、元件、服務，各部分之間又是一種什麼樣的關系。

清晰架構的目的一是為了更好地複現，目前大部分軟體開發的需求還是來自業務，是對業務需求的複現，無論你寫沒寫需求文檔，這個本質是不變的。是以，理清了業務的結構、應用的結構，才能保證複現的正确性，也就是確定軟體的品質。目的之二是為了更好地實作複用，清晰、統一的架構定義，有助于識别已有的業務能力、軟體資産是否可以被複用，複用有助于解決産量問題，也就是縮短開發周期，而已經被使用過的軟體資産往往經曆過檢驗，也有助于保證新應用的品質。

其實軟體設計與業務人員搞産品設計關注的東西也沒有很大差異，業務人員做産品設計時一樣要考慮産品的構成，産品中包含什麼内容，比如銀行産品中申請的環節、審批的環節、放款的環節，不同的環節之間是什麼關系；如何更好地複現、迎合客戶需求；以往的業務經驗、業務規則能不能用在新産品設計上，如果能用那自然産品設計的效率也會提高。是以，二者思維模式接近，如何更好地幫助業務人員在設計産品時進行結構化的思考，就會讓業務和技術的關系更近一步。

（三）“樂高積木”的局怎麼破？

随着軟體需求量的激增，現在到了需要需求側能力提升的時候了，技術端無論如何改進自身，如果需求端沒有相應的改進，那麼，軟體開發效能的上升始終是有限的。比如，談論近 30 餘年的“樂高積木”式構件化設計遲遲未見好的實作，是不是與需求側的結構化程度嚴重不足有關呢？需求側的結構化思維中，是不是也需要對軟體開發的關注點多了解一些呢？

“樂高積木”問題其實也就是服務的顆粒度問題，服務的顆粒度與業務管理上經常處理的分工問題是不是高度相似呢？給小張同學安排 1 件事情好還是 5 件事情好？如果有 100 件不同的事情，是安排給 100 個小張同學好還是安排給 20 個小張同學好？這個問題對業務人員和技術人員的困擾是一樣的，并非是一個有着極大專業界限的問題。

“樂高積木”最終是要支援業務人員的需求變化，那服務的切分到底是技術人員自己的事情，還是也需要業務人員的參與呢？我們目前在 B 端軟體上經常會以雙方關注點的分離來解釋現有的軟體研發分工，但是，面向數字化轉型，這個分工該适當改進一下了，新的時代需要新的生産方式，不然，“樂高積木”這個局可能就無解了。

二、軟體過程是業務人員學習技術知識的基礎

現在科技發展速度越來越快、應用越來越普及，用技術改變業務模式的呼籲也越來越強烈，是以很多業務人員也對技術發生了濃厚的興趣，人工智能、區塊鍊、大資料、雲計算也都成了業務人員的案前書。但是很多業務人員都忽略了對軟體工程、系統設計、業務架構這些基礎性内容的了解，經常直接撞上了技術領域中“不講人話”的部分。

這些“不講人話”的内容，比如人工智能中的各種算法、區塊鍊中的哈希與共識等等，這裡邊的内容很多是技術人員自己都說不太清楚，靠封裝好的函數、子產品進行調用的，業務人員在此花費精力很不值當。而再“牛”的新技術，也是要經過軟體工程中的辛苦勞動才能轉化為應用，是以，在關注這些新技術之前，先了解軟體工程和系統設計原理，反倒可以更好地思考這些新技術的落地方式。

軟體設計的架構知識中确實有不适合業務人員學習的技術理論部分，但是就整體子產品的設計與劃分而言，是業務和技術可以溝通的部分，也是必須要溝通的部分，通過雙方對軟體工程、業務架構、應用架構的共同了解，可以打破雙方在理念上人為設定的“鴻溝”，更好地促進雙方融合，隻有強化了這些底層的融合，才可能讓戰略層面、企業層面的業技融合真正得以實作。

作者簡介：

付曉岩，新書《銀行數字化轉型》剛剛面市，受到熱議。另著有《企業級業務架構設計：方法論與實踐》一書，對企業級業務架構設計、企業數字化轉型、金融科技發展有持續的研究和深厚的實踐積累，現就職于建信金融科技有限責任公司。公衆号：曉談岩說。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-06-30

本文作者：钰湚

本文來自：“

InfoQ

”，了解相關資訊可以關注“[InfoQ](

https://www.infoq.cn/article/uB7I7iE0HN3TAvmYZJYo

）