不管是軟件產品的用戶、還是軟件公司的老板，或是寫代碼的碼農，都苦軟件開發(fā)這個行當久矣，很難見到一個行業(yè)屬于甲方、乙方、從業(yè)人員都在罵的行業(yè)，軟件開發(fā)行業(yè)就是。

甲方罵我給了那么多費用，為啥還滿足不了我的需求，到處都是bug，交付時間老是延誤。

乙方老板罵甲方，你就這點錢，還三天兩頭改需求，動不動就要我兩天搞完，我又不是超人；乙方老板也罵員工：我一天養(yǎng)你們那么多人，開著高薪，你們怎么連這么簡單的功能都做不好，給我加班！！！

碼農：這些需求你們都沒想好就要我開發(fā)，現在三天兩頭改怪我咯，天天催我上線，我連單元測試都沒時間，就這點工資還每個月都拖。

看吧，三輸局面，沒有哪個行業(yè)有那么多豆腐渣工程，沒有哪個行業(yè)利潤那么薄，沒有哪個行業(yè)員工那么辛苦，996最早哪來的？可不就是軟件開發(fā)行業(yè)傳開的嗎！

看過軟件工程領域圣經《人月神話》的人，都知道銀彈（銀彈就是可以讓強大的狼人被一擊斃命的武器），軟件工程借銀彈來比喻那種一招制敵，解決軟件工程中所有問題的終極武器。

可惜幾十年過去了，軟件開發(fā)領域的從業(yè)者們還是沒有找到銀彈。但最近幾年涌現的低代碼、零代碼，甚至AI大模型、自然語言編程讓人們不既讓大家又看到了一絲曙光。

可現實遠沒那么理想，低代碼被大家批成業(yè)務人員不會用，開發(fā)人員不愿用；零代碼更是被嘲諷成玩具，AI大模型和自然語言編程也是說著很美，但真到工作中又不頂事，很難大規(guī)模工程應用。

難道最終還是沒有辦法嗎？實際上確實不存在銀彈能一勞永逸的解決所有問題，但也許另一條“合縱連橫”的道路能把這些各有優(yōu)勢的技術和產品集中貫通起來，成為真正的銀彈。

不知道我在說啥的，繼續(xù)往下看，我們現在把軟件開發(fā)按照開發(fā)模式劃分為四個層次，分別是：

1、傳統硬編碼的開發(fā)模式：這個無需多說大家都明白；

2、低代碼開發(fā)：大部分常見、簡單開發(fā)通過前端拖拉拽和系統配置開發(fā)完成，復雜和個性化的需求依然能夠采用代碼編寫的方式完成（代表：各種**云）；

3、零代碼拖拉拽式開發(fā)：不需要寫代碼，靠界面上組件的拖拉拽操作以及系統配置即可完成軟件開發(fā)（代表：釘釘宜搭、百度愛速搭）；

4、自然語言開發(fā)：語音也好、文檔也好、文字也好，只要是人類語言說出來的，就能作為需求輸入完成軟件開發(fā)（代表：微軟Copilot，中國電信星辰大模型·軟件工廠）。

現在大部分軟件公司還停留在第一個傳統模式開發(fā)的層次上，啥項目都是硬編碼，好點的積累了很多可復用的庫或功能模塊，再有個好的研發(fā)管理流程就已經算不錯的公司了。

另外，部分頭部軟件公司或有想法的公司在保留部分傳統硬編碼的開發(fā)方式下，大部分產品的開發(fā)和項目實施已經轉到低代碼開發(fā)模式中，比如像金蝶、用友、致遠、泛微以及一眾saas軟件企業(yè)，在長期的業(yè)務實踐中，他們總結積累了自己的研發(fā)基座，這些研發(fā)基座基本就是低代碼平臺，這些基座讓他們提高了開發(fā)效率，增強了研發(fā)的過程管理。

我拿我所在的小公司舉例，因為憂患意識比較強，所以也很早自研了自己的低代碼平臺用以項目和產品的研發(fā)，現在除了20%的歷史遺留項目外，公司80%的項目都已轉入低代碼開發(fā)模式，在此模式下已跑了兩年，也未出現很多人詬病的復雜項目無法開發(fā)的情況。

當然低代碼最大的客戶并不是軟件公司，而是信息化經費充足，組織規(guī)模較大的企業(yè)，但低代碼在這些大型組織內還是一種嘗試性的應用，并未大規(guī)模的采用后用以替代原有系統和開發(fā)模式。

零代碼在軟件公司中較為罕見，更多的是在一些非專業(yè)軟件公司，如系統集成商，個人工作室和一些甲方用戶里在小規(guī)模的使用。

而自然語言編程更是處于早期，微軟公布（不是發(fā)布）類似產品的demo也才過去幾個月的時間，所以現實中并未見到實踐案例。

那這些軟件開發(fā)平臺類產品到底什么才是最好的呢？

以我個人淺見，提供給用戶的軟件開發(fā)平臺最好的肯定是自然語言開發(fā)，簡單易學、受眾面廣，但是以現有的技術和模式來說，自然語言開發(fā)在可以預見的很長時間內，局限性還很強，搞不定很多用戶需求。

那怎么辦呢？我的看法就是“合縱連橫”，何謂“合縱連橫”，我們先來看看這幾類產品對應的用戶類型劃分。

1、傳統硬編碼：軟件公司開發(fā)工程師；

2、低代碼：懂技術的入門級開發(fā)人員，如：軟件公司的初級開發(fā)工程師、甲方客戶的開發(fā)人員；

3、零代碼：略懂技術的甲方IT人員或軟件公司里的產品經理；

4、自然語言開發(fā)：完全不懂開發(fā)技術的用戶，如甲方的市場、銷售、老板等人員。

從用戶面來說，從上向下兼容容易，能用硬編碼開發(fā)軟件的碼農自然也能用自然語言開發(fā)（雖說現在很多開發(fā)人員不愿意這么干）。但從下向上兼容就不可以了，一步都不可以，不懂技術的人甚至連零代碼用起來都別扭，更別說低代碼。

很多人會說那么多年下來，搞軟件開發(fā)都是碼農主力，為啥你非要去糾結普通業(yè)務人員來參與軟件開發(fā)，原因如下：

1、普通人員比軟件工程師人力成本低；

2、甲方的業(yè)務人員比乙方的軟件工程師懂業(yè)務；

3、產品經理比軟件工程師更懂需求和產品設計；

所以“合縱連橫”下有沒有可能出現一種新的軟件開發(fā)協作模式，把多種軟件開發(fā)平臺集成在一起，讓各類項目相關人員一起協作來完成軟件開發(fā)。比如：

先由甲方的業(yè)務人員用自然語言開發(fā)模式搭建出系統的基本功能框架，這個框架能夠表達出用戶的基本需求、數據組成、展現形式。甲方業(yè)務人員在軟件開發(fā)方面的能力極限也就到此為止，整個項目的完成度可達到20%-50%；

下一步，在此基礎上，由甲方的IT人員或乙方的產品經理進一步用零代碼把這個“毛胚房”開發(fā)成“簡裝房”，這一步的成品已經達到產品原型的地步，但相比傳統的產品原型，這個成品里一些沒有復雜業(yè)務邏輯的簡單功能已經能夠直接運行，產品經理的天花板也就到這里，整個項目的完成度可達到40%-70%；

第三步就可以由乙方的初級研發(fā)工程師使用低代碼平臺完成簡單代碼的編寫和復雜產品的配置，到這一步時，整個項目的完成度可達到60%-90%，進入“精裝房”階段；

到第四步只剩下少數技術難度較高的特殊需求，或是要對平臺進行底層代碼編寫才能滿足的需求，但也只需要乙方少量的高級工程師或系統架構師就能完成。

以上已經是一個較復雜項目“合縱連橫”各步的完成情況。但實際很多項目并未這么復雜，甚至有10%的項目在第一步就能完成，20%的項目在第二步就能完成，30%的項目第三步可以完成，只有40%的項目才會走到最后一步（以上數據依據本公司項目實踐所得，不代表行業(yè)整體情況）。

“合縱連橫”帶來的好處就是，甲方業(yè)務人員深度參與，業(yè)務需求在第一步就能得到充分的梳理和“釋放”，減輕了業(yè)務需求不明給后期帶來的眾多問題，同時甲方人員的深度參與，也會使其獲得成就感和參與感，進而對項目提供更多的支持和配合。

對乙方來說，因為甲方的加入，自身的工程量減輕，清晰的需求也避免了后期的反復，同時只需人力成本較低初級工程師就能完成絕大部分工作，也大大減輕了項目的實施成本。實施成本的降低也會反哺甲方的信息化建設，使其用較少的經費就能完成更多的項目建設。

這樣的項目模式在業(yè)內極少見，很多同行肯定也要說，你這個太復雜了，甲方爸爸不光出錢，還得陪你一起搞研發(fā)，哪個甲方爸爸愿意這么受累？

確實有這個邏輯存在，但就我的感受，我們服務的客戶，特別是大型客戶、企業(yè)客戶，越來越希望能夠深度參與到項目建設過程中，而不是僅僅當個項目經理等著驗收成果，現在很多項目甲方甚至派遣產品經理、開發(fā)人員隨同乙方的項目團隊一起開發(fā)，就是為了自己的項目過程不走偏，同時在項目結束后能夠從乙方手里全盤接手項目。

“合縱連橫”這種模式有其很大的優(yōu)勢，但現在鮮有這方面的實施案例，造成這種情況并不是甲方不接受，而是乙方沒有集自然語言開發(fā)、零代碼、低代碼、原生代碼于一體的軟件開發(fā)平臺，自然無法實施。但從邏輯和理論以及我司這些年的實踐經驗看，確實不乏是一顆能夠解決軟件工程問題的“銀彈”。

這樣的軟件開發(fā)平臺集四種開發(fā)模式為一身，當高維度開發(fā)模式不能滿足項目需求時，可降維使用低一維度的模式繼續(xù)項目開發(fā)，同時這樣的軟件開發(fā)平臺要能集成研發(fā)過程管理系統就更加能使項目開發(fā)如虎添翼，方便甲乙雙方項目人員的工作協同進而提高研發(fā)效率和質量。

以上過程本人已部分實踐，歡迎同行探討。