我所說的開發(fā)人員并不是指會(huì)編碼的人。我認(rèn)為，不一定非要會(huì)編碼才能成為一名開發(fā)人員。更重要的是像工程師一樣思考。當(dāng)一家企業(yè)的 CRM、HCM、ERP、LMS、MAP 以及幾十甚至幾百個(gè)第三方應(yīng)用程序，被那些沒有接受過訓(xùn)練、不會(huì)像開發(fā)人員那樣思考的人修改、構(gòu)建和管理時(shí)，他們所追求的短期結(jié)果會(huì)導(dǎo)致長期的災(zāi)難。  

 

在這篇文章中，我將說明一下，為什么我認(rèn)為 2022 年適合這些公司迎頭趕上，開始培訓(xùn)并推動(dòng)人們轉(zhuǎn)型為商業(yè)應(yīng)用無代碼開發(fā)人員。  

 

1、沒有工程師會(huì)導(dǎo)致技術(shù)債務(wù)癱瘓  

 

我所接觸的很多中大型公司都會(huì)遇到一個(gè)簡單的問題：管理員想取消商業(yè)應(yīng)用程序中的一個(gè)字段，那可能是 Salesforce、NetSuite 或 Zendesk。他們懷疑沒有什么地方使用這個(gè)字段。他們沒有看到任何活動(dòng)，如果能把它清理掉就好了。但是，他們無法確定。他們以前試過，這個(gè)字段對(duì)他們的一個(gè)公式來說至關(guān)重要，這個(gè)公式出問題會(huì)導(dǎo)致業(yè)務(wù)部門的部分儀表板失效，因?yàn)閾?dān)心這個(gè)，所以他們沒有采取任何行動(dòng)。Salto 首席執(zhí)行官 Rami Tamir 稱這是技術(shù)債務(wù)癱瘓。放大到企業(yè)范圍，這是一個(gè)嚴(yán)重的問題。  

 

比如說，銷售團(tuán)隊(duì)想改變選單上的選項(xiàng)，但 CRM 團(tuán)隊(duì)花了一個(gè)季度的時(shí)間才弄明白，而在這一個(gè)季度里，有不少交易被誤導(dǎo)了。或者，董事會(huì)決定進(jìn)行 IPO，但卻意識(shí)到，無法使他們混亂的 NetSuite 實(shí)例及時(shí)符合 SOX 標(biāo)準(zhǔn)。或者，營銷團(tuán)隊(duì)想要加強(qiáng)電子郵件活動(dòng)來解決潛在客戶短缺的問題，但商業(yè)應(yīng)用程序團(tuán)隊(duì)卻需要 6 個(gè)月的時(shí)間來移植這些部分。  

 

這些問題會(huì)以各種方式表現(xiàn)出來。考慮下我從客戶那里聽到的這三個(gè)真實(shí)的例子。  

 

一家國際化 SaaS 公司使用了 NetSuite ERP。在他們財(cái)年的最后一天，許多關(guān)鍵的報(bào)表突然停止了工作，他們無法結(jié)束這個(gè)季度。整個(gè)團(tuán)隊(duì)爭分奪秒，但直到深夜才發(fā)現(xiàn)，有人在生產(chǎn)中改變了一些“保存的搜索”，卻不知道他們的實(shí)現(xiàn)中有其他關(guān)鍵的部分在使用。  

 

一家大型零售商使用 Zendesk 作為客戶支持系統(tǒng)。一名管理員直接在生產(chǎn)環(huán)境中定義觸發(fā)器時(shí)犯了一個(gè)小錯(cuò)誤，向幾十萬不知情的客戶發(fā)了一封令人困惑的電子郵件，然后變成了大量新的工單。  

 

一家大型的公共 SaaS 公司無法弄清楚為什么它的銷售線索轉(zhuǎn)化率出現(xiàn)大幅下降。經(jīng)過幾個(gè)月的分析，該公司終于發(fā)現(xiàn)，由于 Salesforce 中有一個(gè)工作流卡住了但未被檢測到，所以就沒有把某項(xiàng)活動(dòng)的線索分配給銷售代表。這些線索就這樣擱置在那里，無人問津。  

 

所有這些問題都會(huì)對(duì)資產(chǎn)負(fù)債表產(chǎn)生實(shí)實(shí)在在的影響。它們使企業(yè)的競爭力下降。隨著這些問題的復(fù)雜化，企業(yè)的發(fā)展速度會(huì)越來越慢，而那些規(guī)模相對(duì)較小的、靈活的競爭對(duì)手將悄悄地趕超他們。無論企業(yè)在允許每個(gè)業(yè)務(wù)部門選擇自己的系統(tǒng)以快速行動(dòng)方面做了什么權(quán)衡，最終都會(huì)為錯(cuò)誤和失誤所扼殺。而這一切主要都是因?yàn)檫@些系統(tǒng)不是在受過培訓(xùn)的開發(fā)人員的指導(dǎo)下開發(fā)的。  

 

2、開發(fā)人員是汲取了六十年智慧的人  

 

如果公司希望他們的商業(yè)系統(tǒng)在其發(fā)展過程中保持正常運(yùn)行，就需要解決兩個(gè)問題。第一個(gè)是關(guān)注軟件開發(fā)領(lǐng)域，并以良好的實(shí)踐為指導(dǎo)，比如組織中使用的 DevOps 和敏捷開發(fā)方法。  

 

近 60 年來，軟件開發(fā)人員一直在處理與如今的商業(yè)應(yīng)用經(jīng)理類似的問題：他們需要一種方法，讓許多遠(yuǎn)程團(tuán)隊(duì)協(xié)同構(gòu)建一個(gè)高度分布式的系統(tǒng)。這需要通過質(zhì)量檢查來確保沒有漏洞，需要預(yù)生產(chǎn)環(huán)境來確保測試不會(huì)導(dǎo)致什么后果，需要版本控制來維護(hù)應(yīng)用程序的多個(gè)版本，以防出現(xiàn)問題。  

 

如果開發(fā)人員專門負(fù)責(zé)商業(yè)應(yīng)用，他們就會(huì)把這些習(xí)慣和工具帶入這個(gè)過程。他們會(huì)從可重用性、關(guān)注點(diǎn)分離和彈性的角度來思考問題，會(huì)使用類似于 Git 這樣的工具來管理分叉、分支、合并和提交修改，允許多人協(xié)作并減少人為錯(cuò)誤。也許最重要的是有整體思維。  

 

如今，大多數(shù)管理商業(yè)應(yīng)用的團(tuán)隊(duì)都處于孤島之中。你有 CRM 團(tuán)隊(duì)，財(cái)務(wù)應(yīng)用團(tuán)隊(duì)，還有各種形式的“公民開發(fā)者”購買和管理的 SaaS，每個(gè)人都在努力減輕自己團(tuán)隊(duì)的工作。這些系統(tǒng)中的大多數(shù)都大到足以成為自己的生態(tài)系統(tǒng)，并包含許多產(chǎn)品。它們也會(huì)集成并分享數(shù)據(jù)。深諳軟件開發(fā)方法和原則的人，對(duì)這個(gè)問題的看法與如今大多數(shù)人的看法大不相同：這不是將 800 多個(gè)產(chǎn)品集成在一起。它們是一個(gè)產(chǎn)品——公司的操作系統(tǒng)——新增的任何產(chǎn)品在構(gòu)建和管理時(shí)都需要考慮整體的完整性。  

 

而這只是第一個(gè)問題。第二個(gè)問題是：許多商業(yè)應(yīng)用的構(gòu)建也不是為了讓那些具有開發(fā)思維的人去管理。  

 

也就是說，大多數(shù)商業(yè)系統(tǒng)的構(gòu)建都考慮到了用戶的成長。構(gòu)建的系統(tǒng)界面是為了讓終端用戶能夠完成工作，而不是讓管理員把一切都安排好。此外，如果從應(yīng)用程序生命周期發(fā)展的角度考慮，構(gòu)建只是為了解決第一步的問題。  

 

  

 

也就是說，它們沒有提供原生功能，讓你可以做開發(fā)人員可能會(huì)想做的事，如版本管理、搜索整個(gè)代碼庫的能力、管理多個(gè)環(huán)境的能力，以及在某些情況下，將變更從沙盒推送到生產(chǎn)環(huán)境的基本能力。現(xiàn)在，有些應(yīng)用提供“開發(fā)”環(huán)境，但很少能提供你所需要的一切。  

 

值得慶幸的是，第二個(gè)問題的解決方法就是第一個(gè)問題的解決方法：把軟件開發(fā)人員的知識(shí)教給更多的商業(yè)系統(tǒng)管理員。經(jīng)常，開發(fā)人員并沒有他們需要的所有系統(tǒng)，因此，他們會(huì)構(gòu)建或借用他們需要的東西來完成工作，使用 Git 工具將他們正在構(gòu)建的東西抽象成可管理的塊，使用工單系統(tǒng)來記錄和排定優(yōu)先級(jí)，并在需要時(shí)構(gòu)建自己的工具。  

 

如果商業(yè)系統(tǒng)管理員經(jīng)過培訓(xùn)后開始像開發(fā)人員一樣思考，那么他們就會(huì)開始爭取更多這樣的功能，我敢打賭，更多的商業(yè)系統(tǒng)供應(yīng)商會(huì)構(gòu)建這些功能。如果他們不這樣做，那些新科“開發(fā)人員”將像工程師一樣，希望能自己構(gòu)建。  

 

3、無代碼，沒問題  

 

還記得之前的那三個(gè)真實(shí)的案例嗎？那些在使用 NetSuite、Zendesk 和 Salesforce 時(shí)遇到問題的公司？其中每一家都采用了無代碼 DevOps 工具和方法，構(gòu)建系統(tǒng)防護(hù)欄。  

 

這家使用 NetSuite 的國際化 SaaS 公司已經(jīng)為其最重要的配置實(shí)現(xiàn)了告警。如果有人對(duì)保存的搜索所做的修改會(huì)影響結(jié)束本季度工作，那么管理員就會(huì)收到告警。  

 

使用 Zendesk 的大型零售商現(xiàn)在禁止管理員直接修改生產(chǎn)環(huán)境。相反，他們從 DevOps 中借鑒了“版本管理”和沙盒的做法——每個(gè)管理員在自己的沙盒中開發(fā)配置，然后將其移到另一個(gè)沙盒中進(jìn)行整合，再移到另一個(gè)沙盒中進(jìn)行測試，然后才在生產(chǎn)環(huán)境中實(shí)施。  

 

這家錯(cuò)失銷售機(jī)會(huì)的大型公共 SaaS 公司現(xiàn)在使用了一個(gè) DevOps 工具，讓它可以查看每個(gè) Salesforce 組織的完整“藍(lán)圖”，并能夠進(jìn)行檢查和修改。當(dāng)有重要的工作流不工作時(shí)，他們就可以發(fā)現(xiàn)并測試，然后在幾天而不是幾個(gè)月內(nèi)修復(fù)它。  

 

4、是時(shí)候培養(yǎng)無代碼開發(fā)人員了  

 

如果商業(yè)應(yīng)用世界從過去 60 年的軟件開發(fā)思維、框架和方法中吸取了經(jīng)驗(yàn)，那么你看到的技術(shù)債務(wù)癱瘓就會(huì)少很多。銷售和營銷團(tuán)隊(duì)因運(yùn)營受阻的情況會(huì)更少。公司發(fā)展受商業(yè)系統(tǒng)阻礙的情況也會(huì)更少。  

 

我相信，系統(tǒng)應(yīng)該和業(yè)務(wù)同步發(fā)展，并支持業(yè)務(wù)的增長。實(shí)現(xiàn)這一目標(biāo)的唯一途徑是增加無代碼開發(fā)人員。  

 

作者簡介：
 

Gil Hoffer 是 Salto 首席技術(shù)官和聯(lián)合創(chuàng)始人。這是一家軟件即服務(wù)（SaaS）應(yīng)用集中式管理工具供應(yīng)商，幫助業(yè)務(wù)團(tuán)隊(duì)獲得商業(yè)應(yīng)用的控制和可見性，其方式類似于 DevOps 對(duì) IT 的改革。他曾任甲骨文公司軟件開發(fā)副總裁和以色列國防軍首席技術(shù)官。  

 

譯者 | InfoQ 平川  

原文鏈接：
 

https://www.infoq.com/articles/growing-nocode-developers/  

繼續(xù)閱讀：

未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動(dòng)力 | RPA新聞 | 推動(dòng)中國RPA生態(tài)發(fā)展 | 流 > 是時(shí)候開始培養(yǎng)無代碼開發(fā)人員了