低代碼平臺如何一步步摧毀開發團隊的效率與創新！

關於低代碼平臺，以前我也推送過兩篇相關的文章，個人觀點很簡單：東西是好的，有它所擅長和適用的領域，但軟件產品不存在銀彈，低代碼平臺同樣如此！

如今在搜索引擎上搜「低代碼」這樣的關鍵詞，你會看到不少誇張的標題，好比：

• 「人人都是產品經理」以後，「人人都是程序員」的時代要來了？
• 阿里、騰訊都在押注的新賽道，能讓程序員告別脫髮和996嗎？
• 還有諸多低代碼平臺的公司拿到各類融資或地區性政府補貼的新聞

甚至我還在福報長的抖音帳號中，看到了程序員下午坐在外面喝咖啡，說有了低代碼，如今大把時間休息的短視頻。。。

低代碼平臺真的這麼神奇？咱們在企業數字化轉型過程當中的開發任務均可以用低代碼平臺來解決嗎？咱們開發者996的宿命就這樣被搞定了？

若是你正對低代碼平臺抱有上面幻想的話，必定要好好看看下面的內容！

先代表觀點：若是你試圖使用低代碼平臺去解決全部開發問題的時候，頗有可能這樣的決定將在2-3年以後帶來巨大的災難！

爲何這樣說呢？下面結合咱們10年前的實踐，給你們說道說道！

僞新技術

你沒看錯，是結合10年前的實踐！因此，低代碼平臺並非什麼新概念，咱們10年前就玩過了！

記得之前在宇宙行的時候，就有一陣推行過一套開發平臺，裏面也是提倡你們用拖拽的方式去實現各項業務功能。

領導們也都很是推崇，但願經過這套平臺的使用，對開發效率帶來革命性的變化。

固然當時的平臺，與現在的低代碼平臺仍是有一些差距，目前所見的平臺會更加完善（界面好看了，控件也多了），但從一名從業十多年的開發人員角度去看，並無質的進步，這樣的程度距離淘汰開發者還有很長的路要走。

效率毒藥

低代碼平臺是效率毒藥！

按照各類產品的宣傳來看，低代碼平臺的目標是要解放咱們，讓咱們更快的開發產品，那爲何說低代碼平臺是效率毒藥呢？宣傳是騙人的嗎？

宣傳並無騙人，當咱們實際去使用的時候，你會發現，開發一些簡單應用的時候，確實會快不少！

同時，在咱們過去的實踐過程當中，開始時候的效率是能夠的！這取決於兩方面的功勞：

1. 小範圍的試錯
2. 簡單應用的先行

但隨着推廣的鋪開，也逐步的會面臨這幾個問題：

1. 平臺支持成了瓶頸：大量使用問題、各類平臺報錯都堆積到低代碼平臺的負責團隊。對於平臺的人員支持，不可能給每一個業務系統都配置一個支持人員吧？因此當應用面一旦擴撒，平臺支持團隊很快會成爲整個系統內的效率瓶頸。
2. 扯皮問題開始增多：當出了線上事故開始定則的時候，本來系統之間可能會存在扯皮，但有了低代碼平臺以後，系統內的實現也多了一個扯皮方向。究竟是組件Bug仍是使用問題？使用問題的話，文檔寫清楚這種特殊狀況不行了嗎？這種新扯皮姿式的出現，阻礙瞭解決問題的效率。

之因此說低代碼平臺是效率毒藥，由於在一開始的時候，你是感受不到的，只有在逐步深化應用，全面推行的時候，它的毒性就開始發做了！

創新毒藥

低代碼平臺是創新毒藥！

關於創新，第一點弊端，你必定會想到，就是固化組件的問題，讓全部的實現都千篇一概。

但這個在現在的低代碼平臺上，其實有好的解決方案，那就是各類自定義實現。

既然用平臺是爲了讓業務開發更專一業務，同時在使用低代碼平臺以後，這樣的組件創新任務，每每又都回到了平臺側的支持上。

因而，最經典的一幕就出現了：

產品經理：這個功能，咱們想這樣...這樣...再這樣...能夠不？
開發人員：平臺沒這個模塊，實現不了
...
產品經理：平臺能作個模塊支持下嗎？
低代碼平臺：這個需求，咱們下個版本能夠考慮下
產品經理：下個版本何時？
低代碼平臺：半年後...要麼你先用xxx組件 + yyy組件這樣...那樣...最後...先湊合一下？
產品經理：...

這是當時很真實且頻繁出現的場景！業務老是變幻無窮的，然而平臺的新功能老是滯後的，做爲業務開發，必須經過平臺實現，不少時候由於缺少靈活性，讓開發失去了原有的創新能力。同時，也成了開發人員拒絕業務需求的神兵利器。

記得在那個時期，基本上全部的項目都是差很少的樣子...毫無新意可言，這怎麼會促進業務創新呢？這樣的平臺幾乎成爲了創新的毒藥！

擺正姿態

爲何效率、創新這些低代碼平臺本來所要追求的願景最終會成爲毒藥，給團隊帶來負面影響呢？

這裏當然有銷售方的過渡吹噓，就如前幾年阿里中臺的亂吹亂用，讓很多買單企業罵娘！但做爲引入這類平臺的管理者來講，也有不可推卸的責任。

根據過去的負面經歷，不妨思考一下：爲何推薦給開發人員會出現那麼多反面的效果？

我認爲形成這個核心問題仍是因爲平臺提供能力與使用人員能力的不匹配所形成的。

回想一下低代碼平臺的目標是什麼？

• 上手速度快
• 開發效率高
• 研發成本低
• 部署時間短
• 維護成本低

綜合起來就是：有效提升團隊效率。但究竟是提升什麼團隊的效率呢？既然推向開發團隊，受到如此多的白眼，那麼推向產品側？運營側？是否可行呢？

試想一下，低代碼平臺的目標是要下降了上手門檻，那麼對於開發人員而言，他好不容易具有了門檻知識，忽然又用低代碼平臺來給他用，而後告訴他，你以前的開發方式不用了，能夠花更多精力專一於業務的思考了。是否是這樣的目標就很奇特呢？從本來更靈活的開發手段，到使用低代碼平臺的限制方式，不是浪費了原有開發人員所具有的更靈活的開發能力？而後還要開發人員專一去學習業務？那麼學習業務的效率和準確度能有保證嗎？是否是有種好不容易招了批練武奇才，學會了九陰白骨爪，而後給發了副手套，去撓癢癢麼？這是否是一種人才的降級使用呢？

再換個角度想一想，若是低代碼平臺推向產品側呢？自己他們有更專業的業務背景，而後依靠低代碼平臺，拖拖拽拽就能完成一套業務系統的開發，這樣的使用方式，彷佛更配得上低代碼平臺下降上手門檻的目標？由於沒有佔用開發人員的資源，所以也爲公司極大的下降了研發成本？大大提升了業務系統的開發效率？而開發團隊更應該去作的是低代碼平臺沒法作到的那些更具備創新意義，或更具有挑戰的開發任務，不是嗎？

彷佛把低代碼平臺推向產品側會獲得很好的效果？願景很美好，但現實也是很骨感的！最近，我就嘗試着給幾位產品經理朋友，搞了一些小合做，由於正好公司運做也須要一些工具，而後推薦了幾個低代碼平臺讓他們去嘗試，但結果並不徹底使人滿意，不過彷佛我也從中獲得了一些新的啓示！

我發現，若是產品經理擁有一些開發背景、學過編程、或是軟件專業畢業的話，在使用低代碼平臺的時候，效果就尤其突出。也許是由於他們的知識背景具有必定軟件開發的思惟模式，結合對業務的理解，因此對於低代碼平臺的應用就更爲友好！

因此，對於低代碼平臺，好東西是無可厚非的，但使用姿式必定要正確！任何東西只有用對了地方，才能成爲神器！放錯位置的神器，有時候連垃圾都不如。

那麼你以爲低代碼平臺如何呢？大家的使用姿式是怎麼樣的？有沒有不舒服的地方呢？留言說說你的想法吧！若是你想與更多有趣的靈魂碰撞，也能夠加入咱們的技術交流羣一塊兒探討咱們的技術人生！

歡迎關注個人公衆號：程序猿DD，分享其餘地方看不到的知識與思考