plm管理系統

導讀

今天讓我們繼續 《三品軟件——看圖說話系列》，本次討論主題與項目中【需求】的無限增長相關。
標題借用了美國科研體現中作用最大的一個法案的名稱，《科學：無盡的前沿》。這份法案曾經領導美國科技雄霸天下，控制全球產業。盡管他們是科學，我們是產業，有較大的差異，但我們在這篇文章中主要關注其共性，那就是：如何在資源有限的情況下，安排研發經費，如何調動人力資源，才能逼近最優解，并在有限的時間條件下，讓我們獲得的價值最大化。

為節省您的閱讀時間，這里做個全文概述：

需求是沒有邊界的，項目中不變的規律就是一直在變（不變的項目通常是死了），然而人力資源（特別是程序員、工程師資源）是有限的，如何解決 【需求無限】 和 【人力有限】 之間的矛盾，這是每一個物聯網企業、IT企業所需要面對的永恒的話題。

本文提出了一個觀點，即：我們通過基于云原生編輯器，可以極大的解決無限需求的問題。

換個角度說：我們可以創建出一個平臺，對外培訓，賦予合作伙伴快速進行高級編輯的能力，對內提升平臺自動化程度，用來替換大部分程序員的時間，將項目效率提升數倍。上述內容可能有些費腦，下面我們會慢慢解釋，關于效率提升數倍（至少三倍），您一定心存質疑，下面讓我們來看看具體的論證過程。

一、現狀

目前的現狀，程序員、工程師所處的位置，位于【連接中樞】（如圖）：

上圖中，我們可以看到：

在項目中，需求的流向，集中在程序員身上，程序員負擔了極大連接的職能，已經超負荷，成為了整個系統的瓶頸。

整個系統是串行的，很多流程必須等待程序員，這近似于全程交通擁堵，沒辦法多線程全開。只能雇傭更多程序員，但這樣人力成本又上去了，陷入進退兩難的局面。

策劃經理、客戶，無法直接接觸產品，中間被程序員隔斷了，然而系統設計的 idea 的傳達，需要耗費極大的溝通時間成本，不管是寫策劃文檔也好，又或者是來來回回、高密度的溝通會議也好，都在極大的消耗企業的人力資源、時間和金錢。

二、啟發

前面說了，現有模式類似【串行等待模式】，效率無法提升，遇到瓶頸。讓我們再來看看另外一種，【并行模式】，應該會有一些啟發（如圖）：

上圖中，我們可以看到：

Photoshop 充當了中間節點，承接了所有連接和交互。

畫家（對應于企業經理和策劃），節省了和程序員溝通的時間，溝通時間等于零。

畫家直接接觸自己的產品，可以讓自己的需求通過 Photoshop 這個編輯器進行【無限】的變換，想改就改，改后立即可見，可以實現立即反饋、立即改進、立即部署。

以此類推，其他諸如此類的編輯器，如Word、3ds Max、CAD、SolidWorks等，在創作時，創作者同樣無需向程序員提需求便可直接創作。

那么，我們現在得到一些疑問：

為什么 IT 行業，沒有一個強大的編輯器，可以滿足【創作者】的需求？

為什么我們要重度依賴【程序員】？

三、困難、挑戰和機遇

在給出下一幅圖之前，我們先用文字來描述面臨的困境。阻礙一款強大的 App/網站 編輯器誕生誕生主要有以下這些原因：

1.長期以來【網絡帶寬】一直是個大問題，由于網速太慢，無法支撐云編輯器（多人同時在線編輯一個文檔或項目），而網站、App 則重度依賴 網速，所以很難出現好的在線云原生編輯器。

2.由于歷史遺留問題，傳統的編程是在沒有鼠標交互，而只有鍵盤的環境下，這種傳統如此牢固，以至于大家都不相信拖拽能得到好的編程體驗。

3.人們對 “高級編程” 過于崇拜，不相信積木式拖拽編輯器可以完成邏輯編程。

4.人們對 “拖拽編輯” 有誤解，認為但凡是編輯器就必須且必然是 “傻瓜化” ，并且拖拽和點擊都是給 “小孩子” 用的，實際我們反思一下就知道，很多編輯器都不是給小孩子使用的，如上面提到的 Word、CAD、3ds Max 等等。而且我們的下一代，大部分都是 iPad 原住民。這個方向值得我們去開拓。然而，市面上的編輯器，特別是 h5 編輯器，都過于傻瓜化，沒有走向高培訓高技巧的編輯器之路。

5.由于前面提到的對鍵盤編程的崇拜（源于 C++、Linux ），大家認為編程就是鍵盤編程、邏輯就是鍵盤邏輯，布局就是代碼布局，美術就是美術設計完了給程序切圖和組裝。實際上，這些操作都可以由策劃和美術自己完成，只要我們提供良好的拖拽界面和少量的培訓。目前還沒有一家公司想到把UI界面布局和邏輯拖拽合二為一，這說明這件事情很困難，也說明這極有可能是一片藍海。

6.瀏覽器早期的競爭，使得網絡編程環境不穩定，特別是 IE 系列瀏覽器，用戶無法在不同的瀏覽器中獲得一致的視覺和交互體驗。

7.傳統的編程環境中存在很多【人力斷層】，在這些斷層中，您會看到大量的程序員在做【非自動化】的工作，如：書寫各種包含符號和括號的腳本，這些腳本不提供智能化提示，難以維護。還有其它場景：手工對接接口、手工解析信號（get 和 post 協議）、手工編譯、手工部署、遠程登錄和調試。而要做出完美的編輯平臺，這些步驟都必須全部自動化。這又帶來 “性能” 問題，下面一點會講到。

8.人們迷信只有 “程序員親手寫出的代碼” 才是高性能的代碼，實際上大部分程序員是調包程序員或者膠水程序員，他們產生的代碼，不但性能不高，而且有可能性能很差，經常報錯。

9.優秀程序員不是不存在，而是被大廠壟斷，中小企業難以承擔優秀程序員過高的成本。

10.并沒有任何一個平臺能夠將優秀程序員輸出的組件以人性化的方式提供給廣大的產品經理或策劃，即便是 github 和 npm 社區，也沒有做到，這不是能力問題，而是習慣問題，由于慣性思維，人們傾向于雇傭程序員團隊 ，然后間接實現產品，而不是提供編輯器給產品經理，讓產品經理有能力去直接構建產品。

11.跨界程序員太少，以致于很少有程序員能想到【合并界面編輯器和邏輯編輯器】。

12程序員即便是想到這條路徑，但令人遺憾的是，程序員表達能力通常不足，而大部分企業負責人也只愿意嘗試現有模式，不愿意承擔風險和代價。但是，我們都知道，越是有風險的事情，越有機會，因為大部分人都不敢踏入雷池，只有膽大者可以搶占先機，實際投資的時候，也不需要  ALL  IN  所有資源。

13.實際實現過程中，還有很多斷層，包含但不限于這些：數據庫、Linux/Windows部署環境設置、域名設置、緩存配置、連接斷層、權限斷層、底層瀏覽器生態斷層......要合并這些斷層，沒有極強的架構能力和預見能力，是無法達成的。因為困難，所以很多拖拽式編輯器的企業，放棄了合并這些斷層，放棄了邏輯編輯器，最后只能做簡單定制。話又說回來，有時候難，恰恰代表了機遇，因為無人競爭。

反過來看，我們認準的方向，也并不是盲目和毫無根據的，可以觀察到，目前各種條件已經接近成熟，筆者認為是時候做一款界面布局和邏輯拖拽合為一體的產品了，理由如下：

1.5G 來臨，未來不管我們身在何處，網速將不再是問題。

2.設備越來越輕量化，特別是今年，VR 設備解決了很多暈眩和分辨率的問題，正在重新火起來，拖拽式編輯將迎來新的藍海。將來，用戶隨時隨地都可以使用大屏幕拖拽編輯+語音輔助控制+VR空間編輯。

3.FaceBook 正在研發新的手環，一旦完成，可以支持在 3D 虛擬空間中，輕易拿捏 和抓取物品，編輯物品，編輯的效率將迎來巨大的飛躍。

4.語音控制越來越智能化，可以用來輔助編輯器，提高編輯效率。

5.React 、 Vue 等項目，也間接地證明了，模塊化是未來的趨勢，一個邏輯文件上千行的歷史，將一去不復返，而積木式編輯器，正好可以在少量代碼的環境下流暢工作。

6.Flash 、Weex、Flutter 等項目，都在試圖統一當年瀏覽器沒有做到的一致化環境，而 WebAssembly 技術，也在不斷的進行統一規劃，未來的環境會越來越好。

7.由于摩爾定律的指引，CPU 、內存等資源的成本逐年下降，我們現在可以用自動化批處理程序來替代很多程序員的手工操作，這實際是用算力換時間，容量換時間。

8.人工智能的發展，也給平臺智能化運作帶來了曙光。

9.網絡的評價模式，用戶內容的產出模式以及分享模式，已經在現有的大量 App 上得到了驗證，我們只需要把這種模式推廣到 組件編輯器云平臺上。

10.蘋果的 AppStore 模式，也證明了軟件市場的潛在價值，而我們可以參照此模式，產生出一個全新的，更低顆粒度的積木市場。用戶可以用積木搭建自己的 App。

11.天使投資家的眼界也越來越豐富，以此為目標的團隊，只要能獲得對應的驗證數據，相信能通過風險投資進行快速擴張，并最終形成具有網絡優勢的組件市場，如此，資金便不再是問題。

12.Chrome 以及 Flutter 、 Kraken 等平臺的性能，已經接近原生，是時候考慮跨平臺編輯器了。

13.我們在企業內部已經獲得共識，即：一切都是輸入、處理、輸出，包括產品策劃的文檔以及編程的代碼，本質上都是在編輯函數，也就是說，文檔、組件、積木、封裝、函數、邏輯，可以等價，既然如此，何不嘗試做一個統一編輯界面，產品經理和策劃，直接操作編輯器，而程序員只需遠程提供積木式組件支持。

四、最終架構

總結起來，編輯器獲得的，就一個字，快。為什么快呢？請看下圖：

由上圖，我們可以看到，用戶通過編輯器，直接編輯自己的產品，無需等待，可以獲得即時反饋，三方是并行狀態，互不阻塞。這本身就代表了效率的極大提升（至少三倍）。這當中，有沒有漏洞和難題呢 ？有的，但也不是沒有規避的路徑：

1.一開始組件會非常少（這個可以通過合作的方式解決，開源社區和企業伙伴都可以貢獻組件，我們內部也積累了一些組件，而且目前平臺可以快速封裝現有組件，這方面幾乎沒有實施風險）

2.一開始的培訓過程需要反復斟酌（還好我們內部有程序員曾經做過培訓教師）

3.社區的分享和付費機制、以及規章制度，有一個完善的過程（需要磨合）。

4.拖拽式交互體驗需要不斷迭代。（需要時間打磨）

5.平臺不夠自動化。（需要我們補全和編寫自動化編譯和部署邏輯）

一旦解決以上問題，將會產生飛輪效應：組件越多 → 用戶越多 → 慕名來平臺賺取收入的程序員也就越多 → 能篩選出的優質組件也就越多 → 用戶也就越多。這是一個正循環。

三品軟件目前正在努力達成這一平臺，設立了一個專門運營此項目的部門，我們希望在不久的將來能通過這個平臺賦能給我們的企業客戶，讓他們獲得如下能力：

1、 像現有的H5編輯平臺那樣，快速生成App和 網站，但依然保有強大細致的像素級定制和更新能力。

2、通過云平臺編輯器， 快速生成企業自身的編輯器 ，不必依賴程序員。

3、企業之間，可以自由的共享和售賣自己編寫的組件，不必再拖延到完成整個項目，將來的企業，可以只專注于單個組件，而沒有必要完成整個項目（這是一種社會資源浪費，也是內卷）。

4、 快速對接其它企業的能力。

5、 自動部署的能力。

6、 像Word或CAD一樣，最大限度剝離程序員，節省大量溝通成本。

7、 企業則由此降低了人力成本，有更多的經費應對經濟危機，有更多的資金進行其它的投資。

筆者認為這樣的平臺建立起來后，可能會淘汰一批技術落后的程序員。物競天擇，優勝劣汰，革自己的命，讓天下程序員無路可走，在競爭激烈的大環境下，存活下來的程序員都是最優秀的。而在組件式平臺上，也只有最好的那幾家可以通過提供良好的拖拽式體驗，以及穩定的組件存活。
拖拽式雖然有很多項目在嘗試，但真正并入邏輯拖拽的廠商，少之又少，而我們認為，即便是編寫邏輯，人腦也更愿意用手指拖拽的方式來操作，人腦是惰性的，自然會選擇更貼近手指的操作。并且隨著基礎設施的完善（網絡、VR、硬件智能等），拖拽的編輯效率最終會超過鍵盤編程，而且您可以在家中，就可以享用全世界最好的程序員寫出來的最穩定的組件，也可以享用最優秀的美術，提供的最精致的界面裝飾。為什么不呢？三品軟件正在路上，目前我們已完成了很多基礎工作，比如布局管理器和表單管理器，正在完成最后一塊拼圖：邏輯組件編輯器以及相關的推薦、評論、分享付費型社區。

期待有更多合作伙伴加入我們，共同建設下一個擁有良好編輯體驗的組件化全球市場。如果您有更好的建議或意見，歡迎與我們聯系探討。