Ragic 部落格
企業電子化的專家 Ragic 教你如何利用各種軟體、
雲端服務讓公司快速升級!
加入 Ragic 企業電子化的行列!
雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
Facebook Twitter YouTube
雲端資料庫
部落格
關於Ragic
雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic

No Code:「不用寫程式就能打造應用」的新型態工具,會怎麼影響你的生活?

作者:Lillian Huang

如果你對數位趨勢的議題很感興趣、你不是工程師但喜歡四處找數位工具提升自己的工作效率,或是因為接觸了 Ragic、Zapier 等服務,對「不用寫程式,就能做出 XXXX 應用」的軟體有些好奇的話,「No Code」是一個你可以認識、探究一下的新名詞。

「No Code」是什麼?

不用寫程式,就可以透過特定工具做到傳統需要寫程式才能做到的事情,例如建立表單系統、ERP,因為這個「No Code」工具已經幫你把底層的程式寫好了。這個詞目前沒有很嚴謹一致的定義,所以大家想像中 No Code 工具的範圍可能不大一樣。不過比較沒爭議的是,Ragic 就是一種 No Code 工具。

和 No Code 類似的另一個名詞是「Low Code」(低代碼工具)——就是只要寫少量的程式,就可以達到傳統要寫一堆程式才能做到的事情。

(我們針對 No Code 概念的詳細說明可另外參考這篇

來聽聽跟這個議題有關的 podcast

最近, Ragic 的 Jeff 受邀到一個 podcast (線上廣播)節目——三創育成基金會的《星箭廣播》當來賓,就是以「 No Code」這個議題為主題。50 分鐘的節目裡,聊到了「趨勢觀察者口中的 No Code 新趨勢是什麼」、「No Code 到底是不是一個趨勢」、「No Code 的定義要畫在哪裡」、「工程師對 No Code 的矛盾情感」、 「No Code 到底對一般人生活 / 工作產生了什麼影響」,裡面也提到了許多 Ragic 的經驗。你可以直接點下面的播放器收聽:

或者另外點擊節目收聽連結:請點這裡。想看文字版的,我們下面提供了完整的開場後的逐字稿,這裡逐字稿的分段目錄跟《星箭廣播》的章節目錄是一組的,有需要的話可以搭配著聽 / 看。

來賓介紹:郭家甫(Jeff)

Titan: 今天很高興邀請到一位來賓,他是我們國內新創公司 Ragic 的創辦人,他自己本身也是工程師——郭家甫 Jeff 。Ragic 是一個讓使用者可以不用寫程式,也可以在類似 Excel 這樣的介面去建立資料庫軟體的一個線上工具。Jeff 你好,我們先請你跟我們的觀眾自我介紹。

Jeff: 哈囉大家好,我是 Ragic 的 Jeff ,我們是做企業雲端資料庫的一間公司。

Titan: 就...就這麼短?

Jeff:對對 ^__^

說明

Titan: 我們之所以要邀請 Jeff 來上我們的節目,是因為他的背景和他們的公司,跟我們今天要聊的主題「 No Code」——不用寫程式也可以達到一些我們要做的軟體功能,這樣產品的概念有高度相關,所以我們邀請他上節目聊 No Code 這個主題。他們的 Ragic 這個產品就是有 No Code 的概念在裡面。

為什麼我們今天想要跟大家聊這個議題,其實是因為我們不約而同在今年年初在不同的地方都看到在討論 No Code 這個主題的文章,甚至 Maxine 本身自己已經寫過介紹 No Code 工具的網站,(網站名字)就叫做「NoCode」,No 和 Code 中間沒有空格。(註:可點此查看網站大家可以去我們 StarRocket Medium 看這篇文章,或者如果你有訂閱我們的科技創業週報,第 191 期的週報也有介紹這篇文章。

「Devsumer」

我一開始注意到 No Code,是因為今年 1 月多的時候看到一篇文章,是 High Growth Handbook 這本書的作者,叫做 Eliad Gil 寫的。 High Growth Handbook 這本書的副標題叫做 Scaling Startups from 10 to 10,000 People ,就是說一家公司從十個人成長到一萬人的時候,這個過程應該怎麼應對。

這個人( Eliad Gil )他的背景是,他以前有在 Google 工作過,後來變成連續創業家,他創辦的公司後來被 Twitter 收購,剛好他就經歷了 Twitter 從 90 個人成長到 1500 人的過程。我讀的那篇文章的標題叫做 Interesting Markets: 2019 Edition ,就是 2019 年他覺得有趣的市場。

其中一個吸引我注意的是他講「 devsumer 」的這一段。 devsumer 其實就是「 developer」加上「 consumer 」——以前我們可能聽眾有聽過的一個詞叫做「 prosumer 」,就是「 professional 」跟「 consumer 」(的結合)。這個詞其實是滿老的詞,應該是 1980 年的詞,「專業的消費者」,或早期有一個比較艱澀的說法叫做「生產消費合一者」。這個詞已經太久了。(當時)他只是在講說,有一種人,他是會消費他自己生產出來的東西,然後是專業的。

今天的話,這個概念比較像是:有一群人,因為自己的喜好或是因為自己的背景,他對一般消費的事物比一般人更了解,所以比如說一台電腦(買)回來,他可以自己組裝,按照他自己的喜好去組裝 PC 。另外一個,我自己個人的理解是,現在有很多電子產品,一般消費者在市面上可以買到的東西,基本上就是專業級的。一些 YouTube 用來剪接五分鐘短片的工具例如 Final Cut Pro ,跟一般業界導演拍片時用來剪接的工具,很有可能跟本是一樣的,我們也可以拿來講這就是「 prosumer」。

回到 Eliad Gil 那篇文章講到的 devsumer ,他在講的是,如果今天你是一個不會寫程式的人,你也在一家不是科技公司的公司工作的話,以前如果這家公司想要提升員工的生產力,比如說建置一個 ERP 系統或是會計系統,他就必須找導入顧問公司、找ERP公司來協助他們導入;要開一系列的教育課程,去教育他們的員工去使用這些工具,或者這些公司就必須有一個部門去協助開發這些產品。

可是 devsumer 這個東西或是這個市場的產品,可以讓本來根本不會寫程式的人,可以用他們的方式,打造出符合他們需求,例如業務需求的 CRM 工具、或是企業內部要做 ERP 系統的,他們很有可能都可以在不懂程式的狀況下,先打造出一個大概可以用的產品。

這是 Eliad Gil 觀察到的趨勢。這件事情會讓本來不是科技公司的公司,或是所謂的中小企業,本來需要大量仰賴外部的人,或是有一筆專門的支出找顧問公司幫他們協助導入,現在可以比較有能力去 access 到本來需要寫程式才能做到的事情。

他在文章中間有提到一些案例,比如說把 SQL 資料庫或者 Excel 報表變成一個應用程式平台,比方說 Airtable 或者是Retool 這種工具。

他也有提到 Notion 或 Coda 這種新型態的文件產品,或者更簡單講, Zapier 跟 IFTTT 這種串接 API 的工具,尤其是 IFTTT ,大家可能已經聽我們星箭廣播講過 N 遍了,它就是讓使用者用圖形化的介面,去串接不同的 API。

這兩股力量結合在一起,熟悉操作電腦或網路的工作者——就是我們這一代,可能也許 50 歲或 40 歲以下,成長過程中已經很熟悉使用電腦了,加上這種新型態軟體出現之後,Eliad Gil 就認為中小企業跟員工個人可以取得過去沒有的程式化的能力,達到(過去沒有的)成果。他在文章最後有估計,他覺得這個市場——因為文章就是講說他認為 2019 有趣的市場,他以投資人的角度來看,市場估計規模有 50 億美元那麼大。

他舉例說, Airtable 的估值——當時是一月底, Airtable 有經過一輪募資,估值超過十億美元,就是大家俗稱的獨角獸。當然我們在講市場規模的時候,不能把新創公司估值加一加告訴你說,市場規模就這麼大不是這樣,但我想 Eliad Gil 就是要跟大家說,業界是滿嚴肅在看待 Airtable 這樣的公司。

「No Code」正在崛起?

Maxine: 剛剛 Titan 分享的這篇文章比較是以公司、市場來看待的,我自己第一次接觸到 No Code 的話,就像 Titan 一開始講的,是我 2018 年底寫過一篇文章介紹一個就叫做「NoCode」的網站,這個網站還滿實用的,它就像是一個導覽或是一個工具箱的概念。它上面會依照你的需求是什麼,比如說你想要做數據分析、你想要製作一個 app ,或你想找繪圖軟體,或最簡單製作表單問卷功能,依照這些屬性來分類,把網上可以用的資源整理起來。

創造這個網站的人叫做 Sam Dickie ,他自己本身就不是工程師。他其實有一個完全專業的領域,是環境科學,可是因為他自己很喜歡自己手作某些東西,像是 3D 列印,所以他也喜歡做一些小型的專案。他其實有分享過建立「NoCode」這個網站的目的,希望很多像他這樣不是資工背景出來,不會寫程式的人,但也想要手作或實際做一些東西出來的人,有一個地方,可以協助他實現某些想法的地方,或找到這樣的資源。

這個網站跟 Sam Dickie 的故事,算是我首次比較淺層接觸到 No Code 這個概念。後來又在今年 2019 年初,Product Hunt 的創辦人 Ryan Hoover 在 Medium 上發表的一篇文章,那篇文章的標題其實很明白就直接寫了:「The Rise of No Code」,他把 No Code 這件事情當成一個趨勢來看待。

大致上,那篇文章概念就比較呼應我剛剛前面講的 Nocode 這個網站的概念,他是比較以個體消費者、沒有技術背景的一般人,透過 No Code 這樣的工具,有種被賦能 empower 的感覺感覺,每個人都可以當 Maker 這樣。當然,那篇文章也有提到一點可能是工程師吧、或是某些(族群)對於No Code 現象的質疑:一間科技公司也好、或者是明明有龐大的技術資源或是技術能力團隊的公司,為什麼在技術決策上,有時候會去選擇一些 No Code 的方案?

當然他那篇文章是很簡短地講到,可能企業考量到可以快速搭建某些東西,方便後續的維護。我想這一塊可能是我們今天邀請 Jeff 跟我們聊他作為一個工程師、或以經營一家 No Code 這樣服務的公司,可以提供我們多一點的想法。

工程師對 No Code 的矛盾情感

Titan: 我跟 Maxine ,我們各自讀到的文章,可能是比較以「投資人角度」,或「個人使用者」的角度來看待 No Code 這件事情。那我們今天要請 Jeff 跟我們分享「工程師的角度」,尤其是他的公司就是以 No Code 為主打,以他的角度解釋一下怎麼看待 No Code 。

Jeff: OK。剛剛 Maxine 有提到的一點說,很多新創公司決定用 No Code 來提高內部組織效率,第一個提到的就是開發起來會比較快,不用找資訊人員。大家很常忽略最大的好處(其實)是「維護成本比較低」。

(只要)有 code 寫出來,你需要的維護成本往往遠高於你的想像,因為你 code 寫出來之後,一定會想要改,不可能寫出來百分之百 perfect 不會改,維護成本往往是意想不到的高。你可能花一小時寫的 code ,可能之後維護的時間是三四個小時,這種事情是常常有的。

如果是有這樣 No Code 的工具,就不會需要重新找開發人員來開發、或花比原本意想不到的成本來維護這個東西,所以我覺得「維護成本」比較是沒有系統開發經驗的人比較沒有想到的好處。

Titan: 能不能請 Jeff 先聊聊什麼是你心目中的 No Code?對 No Code 的趨勢有什麼觀察嗎?

Jeff: 剛剛聽 Titan 跟 Maxine 講,我覺得對於技術人員跟非技術人員(來說),對 No Code 、Low Code 這部分的看法是完全兩件事情。

本身我是開發人員,No Code 對我個人來說是「工程師的浪漫」:我一開始接觸了很多資料庫系統開發,所以我想說,漸漸發現資料庫系統其實要做的事情還蠻重複的,大部分都要資料庫讀、寫、刪除、修改,固定要做的事情其實非常多,要寫的程式也很像。身為工程師最討厭的就是重複的 code ,就想說能不能做出工具,用很快的方式完成原本一樣要達成的效果。

這是我自己一開始踏入這領域的一個想法。可是其實「把程式碼越來越高階」的想法——所謂低階就是 assembly (組合語言),寫一些越來越貼近機器講的話的話就是低階;所謂高階,就是越來越接近人類講的話。

程式語言的發展,一直以來都是從低階往高階發展,從一開始的 assembly 到 C、C++ 到Java,甚至比較圖像式的語言,這個趨勢其實幾十年來一直存在的。你程式語言越低階,可以控制到的東西越多;程式語言越高階,能夠控制的東西就越少,可是越低階就越難開發,越高階就越容易開發。

對開發人員來說,有一個情感上的特色:多半程式人員都覺得,以前的人寫 assembly 寫 machine code 可以控制到那麼低階的東西,好厲害!以前的人,是拿一張卡片在上面打洞,變成程式去發射火箭,那樣子感覺是「真正的工程師」該做的事情。在圖形介面上拖拉,比較像小朋友在寫程式。

所以對工程人員來說,寫程式的人常常會覺得低階的比較厲害,高階的像玩具一樣不那麼厲害,變成 No Code、Low Code 這些工具比較常使用的人,往往是非技術人員。而在原本一般來說要來開發這些程式的人,反而沒有那麼喜歡 No Code、Low Code 的一些工具。這是我們一開始在推Ragic 的工具比較沒有想到的事情。

我們原本是想說,這種東西,開發人員一定超愛的!我們可以節省他多少時間,一下子就可以把它做出來。後來發現,開發人員有他的尊嚴,覺得這不是把我原本辛辛苦苦寫的東西變得好像兒戲嗎?就開始展現他們的東西可以做到多細(No Code 不行),就會有這樣子的掙扎。

所以誰最喜歡 No Code?

可是對於非開發人員,就完全不是這樣。非開發人員原本就不會寫程式,所以今天你給了他這樣的工具,可以做 CRM 、訂單管理,他覺得非常開心啊!可以幫他打開整個的門:原來我自己就可以把我的對於產業的知識,灌注到資訊系統中!我可以做出各種很神奇的東西!對於他,是非常開心、非常興奮的事情。(這個工具)開發人員和非開發人員的看法是非常不一樣的。

所以說,其實 No Code、Low Code 這些工具,其實對於非技術人員、原本不會寫程式的人來說,是非常有吸引力的,因為他們可能其實懂的是其他東西,他們可能對於房地產、對於營造業、對於晶圓製造非常熟,他們只是不會寫程式而已,可是對於系統該有的邏輯,他們都非常清楚。當這樣的工具給了他們一個魔法棒,突然變成會寫程式、能夠變出資訊系統之後,他們反而變成最熱情擁抱 No Code、Low Code 技術的人。

Maxine: Jeff 說的對我而言很有感,因為我今年二月就是嘗試著去寫 Python。其實 Jeff 剛剛講的,你本身對這個領域技術了解的位置在哪裡,對工程師來講的話,其實 No Code 沒有那麼強大吸引力,(沒有)開啟一扇門的感覺;但是對沒有技術的人來說,我突然覺得我可以寫一串程式碼的時候,會覺得自己很厲害。

Titan: 對於我來說,我覺得我們找 Jeff 來應該是滿對的,因為我沒有想到工程師不是很喜歡、或者說對於 No Code 這個概念這件事情是有矛盾心理在裡面的。的確他就是有效率、節省時間,但是掌控度又不在自己手上,對工程師就是比較不能接受,或覺得比較奇怪的事情。

Jeff: 對,這件事我原本我就會做啦!而且我原本會做到百分之百,它(No Code 工具)讓我只能做 80% 。雖然它也讓我原本要花 100 的時間變成只要 20 ,可是(工程師)他就覺得我剩下那 20 要怎麼辦呢?開始掙扎,而且覺得缺少展現他工程師才華的地方。

Titan: 補充解釋一下,剛才有聽到 Jeff 在講 No Code 跟 Low Code ,其實跟字面上有點像。No Code 就是不用寫程式,Low Code 就是你在使用這個工具時,你還是要會寫一些程式才行(但只需要寫少量的程式)。

到底怎樣算是 No Code?原來跟我們想的不一樣

回到剛剛 Jeff 講的,我們發現一般人像我跟 Maxine ,我們對 No Code 這件事情跟工程師看法似乎有一些不太一樣的地方,我們想請 Jeff 再深入去談對這件事情的想法。

Jeff: 一開始在談的時候我們會發現,突然開始討論 No Code、Low Code 大家就會很高興,覺得過去的各種東西好像都是 No Code。

比如說,我過去不會架網站,現在有 website builder 讓我們可以架網站了,這是不是一種 No Code?原本我要寫程式才能做一個購物車、購物網站,現在我讓不會寫程式的人也可以勾勾勾設定之後,就變成一個購物網站,這樣是不是一種 No Code 的方式?

(但這樣討論下來)絕大多數的雲端服務都變成 No Code 了。我開始覺得,界線必須畫在某個地方。這就回到一開始討論雲端運算、 big data 的時候,所有程式都是 cloud computing 只要在伺服器上、只要有資料就是 big data 資料,這樣界線會不知道切在哪裡。

所以我仔細想了一下,我自己分類了一下——這是我自己的分類不是官方的分類,我大概把它分成三類:

第一個是原本有一個趨勢叫做「 Bring your own device 」,BYOD,後來(這趨勢)漸漸變成「BYOA」, Bring your own application,大家把個人常用習慣的帶到工作上來用。

比如我習慣用 Google Drive 管理我的檔案,我拿到辦公室跟大家分享我的檔案;或我習慣用 Evernote、OneNote、Notion 來做 Note taking (做筆記),我把這樣的工具拿到辦公室跟大家使用,我認為這就比較是個人的 Bring your own application 的方式來做到由非資訊部門幫部門導入一些生產力工具的一件事情。

再往進一步走,是我們剛剛講到 website builder 或是 e-commerse 的購物車工具,這就不只是個人,是整間公司整個團隊要一起維護的。像是 Wix、Shopify 甚至 Zapier、 IFTTT 這些整合工具,這是一整間公司或一個團隊要一起使用的。

最後,再進一步,才是我心目中的 No Code 。前面兩種做的事情都有一個特色,就是雖然是說你不用寫程式,可是你能夠做的事情是很有限制性的。比如說, website builder 你就只能做網站、購物車就只能做電子商務的東西,你拿一個 Dropbox 就只能管理檔案,你拿 Evernote 就只能做筆記,其實產品設計就是只能做某件事情。

再進一步說,我們其實有另一種工具,例如 form builder、Google Form 或是 Survey Monkey、Typeform,他們這種東西能夠做的應用可以稍微可以再廣一點,可以搜集各種資料。再進一步說,可能是一種 database builder ,可以涵蓋的範圍就更廣了。比如說 CRM、ERP 系統、 HR 系統,或是公司內的 KM (知識庫)系統這種資料庫系統,都有可能藉由一些 database builder 的工具來做出來,我就認為這個比較接近我心目中 No Code 的方式,因為一般人或許可以藉著這個工具,做到傳統來說一定要由資料庫系統開發人員做的事情。

Maxine: 我這邊提一個問題好了。看起來這三個分類, Jeff 心目中的 No Code 工具好像都跟「資料」比較有關係?

Jeff: 對對對。

Maxine: 因為我剛看像您說 form builder ,像 Typeform ,對我這種非技術的人,對我來說,他們就是「做表單」。我可能沒想過他們就可以搜集資料、可以做更進一步運用,對我來說他們就像 Evernote 做筆記、 Typefotm 做表單,這樣而已。

Jeff: 對,嚴格說來他也是一種「應用」,只是,一個 form 就是資料庫應用裡面最基本的「輸入資料」或「維護資料」的元素,他可以長成的東西的可能性就會多很多了。

Maxine: 這果然就是工程師與非工程師看到的世界就不一樣!

Titan: 不知道Maxine 有沒有聽過一個其實也是今年才有的一個新創公司,強調的就是用 Google Sheet 可以做成一個 iOS 或者 Android app 叫做 Glide 也是微軟工程師的創業。還有一個叫做 Sheet2Site ,就是用 Sheet 可以做成一個 Site ——大家可能沒想過 Excel 表單可以做成一個網站,他的概念有點不是那麼直覺。我們看到表單覺得可以做問卷調查,但其實用表單可以做出一個訂單系統或部落格,都是有可能的。

我們聽完 Jeff 剛才解釋他把應用層級分成三種,只有所謂的 form builder 或是 database builder 比較是他所謂的 No Code ,我們可以發現他的看法跟我們一開始聊的......有非常大的落差(囧),像我們講的 IFTTT ,對他來講可能就沒有在這個範圍裡。我想這是我們的聽眾,不管是工程師或是對這個領域沒有那麼熟的人來說,可以多了解一下真正工程師的看法,跟我們在網路上讀到的趨勢文章的看法、出發點是不一樣的。

企業、組織喜歡用 No Code 工具的理由

剛剛 Jeff 有提到程式語言的發展從組合語言到後來的 Fortran 或者是 C 語言、現在更高階一點的像是 Python 這種的,或是還有那種圖象化像 MIT 做的那種 Scratch ...

Jeff: 對啊,越往高階,大家都是希望走到一個程度就是,你不需要去學語言。只是到目前為止,大部分情況都還是:有一個語言可以跟電腦溝通,還是比較方便一點。

*****

Titan: 那想請問的是, No Code 這件事情,個人在組織裡...像 Eliad Gil 有講到,非科技業的員工可以因為 devsumer 的產品或是 No Code 類型的工具,讓他對組織有一些影響。我想問 Jeff 這樣的問題;另外是像 No Code 這樣的產品,對工程師有什麼影響?

正面反面可能都有,那我們想請 Jeff 先從可能比較正面的影響來講。

Jeff: 正面影響,除了一開始有稍微提到維護成本低很多之外,有很大一個好處在於說,通常透過這個方式做出來的應用,會比較實用。這個東西是由 End User 自己做出來,解決他們每天實際遇到的問題,這個東西是他會很想要用,而且是真正能解決他的問題的。

因為傳統來說,通常 IT 部門在推資訊系統的時候,都滿痛苦的。例如要導 ERP ,要導 CRM ,這種東西通常底下行政部門都會一片哀嚎,覺得原本好好的為什麼要做新的事情,要學新的東西,而且上線以後通常還是會哀嚎很久說,為什麼要帶來那麼多麻煩。原本他們可能覺得很簡單的事情,要變成用很複雜的方式去做。

其實這是有它的原因。導套裝軟體 Package software 這種東西,通常是很龐大、對一般的使用者而言很痛苦的。一套系統例如 SAP ,幾萬間公司都是用像這樣的軟體,同一套東西,要去給石油業、要去給晶圓業、要去給補習班用,都要用同一套,這個功能絕對是包羅萬象、什麼都有,而你用到的只會是其中一點點的部分,變成為了要去解決你的一小部分的問題,你要去學很龐大的軟體,要去維護很龐大的軟體,過程其實是非常痛苦的。

而且就算這個軟體很龐大,通常也還是沒辦法涵蓋你的需求,通常只能夠涵蓋非常核心、每間公司都還比較類似的部分才會涵蓋,所以用起來都滿痛苦的。

Titan: 聽眾可能看不到我們的表情,但是我跟 Maxine 都在點頭。

Jeff: 對,因為其實我們以前也做過 ERP 導入,使用者真的會用到哭。從另一個方向,你不用套裝軟體,你有另外一個方式就,是我們找 SI 、外包廠商、系統整合商來做一個好了。像我們政府標案,都是這種東西客製化的,你說什麼,我們就做什麼,這種東西......其實還是很痛苦。

因為第一個,我們提出需求的最好狀況是,(由)最終端使用者(來提)。終端使用者一開始就要很完整描述,要什麼東西做成資訊系統。如果有做過,就會發現,這是是非常困難的東西,你常常會說我要做這樣、那樣,等工程師說,好!我這樣把它做出來之後,你會發現不對,這不是我要的,我意思是另外一個。這樣就會改來改去,專案會延宕做不出來,工程師會生氣說,你當初不是要這樣嗎?其實我不是這個意思。這會造成我們一般客製化專案很痛苦的原因,而且這已經是比較好的狀況了。

比較糟糕的情況是:公司高層說,他們( 軟體公司)業務說我們可以做什麼東西,可以做出怎樣的報表,聽起來很棒,那我們就來做吧!但這是高層要用的東西,對基層沒有明顯好處的東西,變成讓他們日常工作,更麻煩。這種情況原本已經是很困難,要開發出這樣資訊系統的情況,如果不是 bottom up ,而是 top down 的方式從高層來的話,對實際上要使用系統的人造成的痛苦就會更多。

那我們透過 No Code 或 Low Code 或是我們叫做公民開發,讓實際使用者可以設計出自己的系統的時候,他們一定會設計出可以解決平常最嚴重問題的工具,沒有人會拿石頭砸自己的腳。我自己設計的話,我一定會調出我平常工作最順的方式,所以會確保這個工具比較實用,比較不會好高騖遠,一定是最基本解決他們平常每個行政人員、每個客服人員、業務人員,或是在做 Marketing 的人平常會碰到的問題,這是第一個很明顯很正面的部分,做出來的東西真的會比較實用。

再來就是維護調整。因為系統很少有做出來上線之後就是一百分的,一個真正好的系統往往是慢慢調出來的,所以一個系統上線一個月之後,我們自己實際使用的人就會知道,哪裡不太順?我們可以哪邊的欄位加一下、哪邊加一張表單,會讓整個流程更順,不用再找到開發人員來寫 code ,我們自己就可以來修改這個東西,既會減少維護的成本,也會縮短改善的時間,很快的系統就會漸漸進入方便好用的狀態。這是我觀察到 No Code 或 Low Code 在公司應用上很實際會看到的好處。

No Code 的政治問題

Maxine: 但如果我們今天回頭講...因為今天 Jeff 講的是使用者,想要使用這樣工具的人,他等於自己有很大的彈性對自己客製化的狀況。可是以一個企業組織來看,如果每個人、每個部門都可以自己決定的話,會不會對老闆或管理部門會有疑慮?

Jeff: 會,絕對會,以 No Code 或 Bring your own application 來說,其實碰到公司第一個問的問題就是:資訊安全怎麼辦?你們又不是資訊安全的專業的人員,你們做出來的東西真的安全嗎?這些都是公司這麼珍貴的資產,我放在你們這些外行人做出來的系統裡面,是不是有真的符合我們的安全規範,跟我們用的套裝軟體或是請專業的程式人員開發出來的(相比),資料是不是真的有安全性?這是公司一定會問的問題。

不過這個問題其實是比較可以解決的。 No code 設定上其實可以做很多考量,很多這都比較是可以解決的。大家最常問的反而相對比較好解決。

第二個常常碰到的是政治問題。資訊系統絕對不只有資料在裡面,牽扯到流程和人的問題,最常見的資訊的政治問題,就是資訊部門很難看、被打臉,資訊部門說這個 CRM 系統很難做啦,這個至少要兩年、要多少預算,結果我們的 Sales 部門覺得兩年後才有哦,那用別的東西、用 Ragic ,一個月兜一個系統,覺得欸、不錯,上線吧!問一下資訊部門行不行?我們要用系統。

這時候他們就很難看了,給老闆看,會覺得你們專業資訊部門,有那麼多資源,說要兩年才能做出來,要多少錢;可是人家 Sales 部門自己很快就做出來了,而且他們覺得很好用,怎麼辦?這時候資訊部門就會很反抗,會想辦法刁難。

這時候資訊部門也滿無辜的,他們是啞巴吃黃蓮,有苦說不出。看起來類似、功能也類似,不代表他們做的工是白費的。資訊部門用 code 寫出來的東西,掌控度、精細度,還是優於 No Code 的部分,只是對公司而言,你為了最後 10%、20% 的掌控度,要花十倍時間成本來完成這件事情,這就是公司高層自己會有考量。

尤其是高層又不是很清楚技術或需求細節的話,就會覺得資訊部門很難看,就會產生一些政治問題,造成 No Code 在推的時候遇到資訊部門的刁難。

一開始推產品的時候,(我們)覺得資訊部門是我們的好朋友,因為我們會讓他們效率變得超高啊!但結果反而有點相反,我們主要使用者其實反而是從一般使用單位、行政部門、會計、財務等等,他們反而會覺得找到一個救星的感覺。

No Code 工具並不會搶工程師飯碗

Titan: 對工程師呢?工程師會覺得影響工作嗎?我前面講到 Eliad Gil 講的,他有講到,比較淺層的工程師可以做的事情可能被取代了,這會對工程師的工作造成影響嗎?

Jeff: 我覺得不會耶!開發人員實在全世界來說都太缺了,每間公司想要找到工程師都有它的難度,大家都在搶人。現階段能夠取代掉的仍然只有資料庫系統的開發,如果能夠取代也只是一小部分的人。而且我實際觀察,有些人導入 Ragic 之後,還會找一個人來管理 Ragic ,做更多應用,只是差別是用他更熟悉的工具去涵蓋更多組織的資訊需求。

因為其實組織的資訊需求實在是做不完。全球前五百大公司有多少資源去做企業電子化?還是做不完!台灣最大的台積電,每天還是有多少人不斷在開發維護他們各式各樣的資訊系統。我們只希望有更好的工具,把看似海樣做不完的事情,更有一點希望,讓我們的每間組織能夠更加真正電子化一點。因為現在大多數組織電子化程度仍然非常低,非常多資料仍然在 Excel 、在紙上面這樣。

Titan: 不知道大家記不記得我跟 Maxine 在講未來地圖那一集說到,雖然新科技會取代一些工作,但他也會創造工作。剛 Jeff 也有講,用 No Code 產品的公司後來反而會專門請一兩個人來使用 NoCode 工具做現在的應用,不管是維護或是開發,而不一定是「我們不用再找人來開發了」這樣。

另外Jeff 剛剛有講到 IT 人員在面對 No Code的「威脅」,可能 IT 部門的工程師常常要面臨各方外行人的挑戰,不知道對工程師或 IT 部門來說,會不會有一種恐懼,這個東西都可以做到七八成我要的功能了,難道就不用工程師了嗎?或者非 IT 部門的人會有這種想法說,我們不用工程師了吧?大多數我都可以搞定,其他部分就交給 No Code 工具的廠商就好了。你覺得這種狀態是有可能的嗎?

Jeff: 其實像 No Code 只是把寫程式這部分拿掉了,在程式以外,在建構企業的電子化、建立資料庫系統時需要的一些能力(來說),寫程式只是裡面的一小部分而已。寫程式以外,我們看到這樣的工具,什麼樣的使用者比較適合把這樣的資訊系統做得好呢?通常是他的邏輯能力比較好的,基本的資訊能力也是有的,有辦法把「非結構」的問題變成「結構化」的、變成表單和一筆一筆的資料,有能力解決非結構問題的人。通常有這種能力的人,可以把這件事情做得比較好。

另外還有一個很重要的能力,是溝通能力。他能夠去召集不同部門,討論清楚彙整成大家都能接受的版本把它做成資料庫系統。這其實也是傳統資訊部門要做的事情,他需要開會研究大家的需求、了解各部門真正要做的事情是什麼、最後才是回到辦公室去把它寫成程式。

討論需求、彙整需求、解決非結構性的問題,其實本來就是他們工作很重要的一部分,只是在 No Code 的未來,這件事情不一定需要會寫程式的人才能做。你如果溝通能力更好、更能夠解決非結構性問題、更能夠讓大家取得共識,知道資訊系統和組織的資料要怎麼管理,那你可能更適合做這件事情。

(不過)傳統的資訊能力在這裡還是有相當重要的角色:一般來說,比較有資訊背景的人設計出來的資料還是比較好維護。我舉個最簡單的例子。我們常看到客戶用我們的工具,有人會把一月的資料變成一個 table,二月的資料變成一個 table,或者是台灣的客戶做成一個資料表、中國的客戶做成一個資料表。

但以資訊人員來說,就會覺得你們這些資料表的欄位基本上大同小異,是不是你們可以把他們彙整成同一張?你會發現,這樣好像比較有道理,有時候資訊人員跟非資訊人員有一些小差異,資訊人員設計出來的資料架構,一張表單可以化簡為繁、涵蓋這麼多張表單的需求,就會讓資料比較好維護、不會有不必要的複雜。資訊人員有資訊背景還是有這方面的好處。

另外,處理資料的時候還是需要注意一些資訊安全的問題,通常資訊人員會稍微比較有一些資訊安全的敏感度,會知道哪些東西要隱藏,密碼不能放在表單裡,有一些基本概念,或者他們對個資的隱私、資訊系統常面對到的法律問題,基本觀念會比較具備。

總而言之, No Code 就是把寫程式的部分拿掉,可是剩下來就資訊系統開發,其實還有非常多部分的能力是要累積的,未來就是看誰最具有這部分的能力來做,而不一定是程式設計師。程式設計師有他的優勢,只是未來可能會變成另外一種職缺。

Titan: 剛剛我們聊的大概都是一般工作者,企業組織的部分。我們接著想要聊的部分是, No Code 這樣的工具對我們一般人的生活、乃至於社會的影響。

大家可能有一些經驗,就是你的親朋好友要結婚宴客,現在可能有些人會收到喜帖之外其他形式的通知,比如有人在 Facebook 直接成立一個 Event page ,邀請大家參加婚禮;另外也很常見的是你會收到一個 Google 表單的網址,看你那天能不能去、要不要攜伴,幾個人,甚至會問你要不要停車位,其實以前可能都是喜帖或電話聯繫,或可能就沒辦法確切知道多少人要來參加婚禮。我想有了這樣的工具靈感,或大家可能不管是學校或工作場合學到了這樣的工具,你可能會發現日常生活也可以套用這種東西。

想問 Jeff 你覺得 No Code 這樣的工具真的可以在某種程度讓技術更民主化一點嗎?或說對我們社會上的影響,你同意這種說法嗎?還是你會覺得這種東西講歸講,但實際上還是會有障礙?

Jeff: 不會,其實我覺得剛才講的很多障礙都是針對企業。對個人來說,這些工具能夠帶來的好處都滿明顯的,對個人來說,他能帶來的好處不少,而且比較沒有剛剛提到的後遺症。

有了 No Code 工具,一般人還需要學寫程式嗎?

Titan: 剛有聽到你講到、我們自己也一直提到「未來」這個詞。我們知道台灣現在教育的狀況,我們想要讓義務教育的課程也涵蓋寫程式,我們認為這是對於培養未來人才很重要的一件事,教育部就把這件事納入義務教育要學的東西。但有人質疑說,讓我的小孩多了功課、多了學業負擔、未來做的工作不一定跟工程師有關;另外也有人會覺得,對家長是負擔、家裡的小孩能不能學好這個科目沒有把握,是不是增加一個麻煩?

另一邊看法是,程式教育重點不一定是學寫程式,而是透過程式教育教會小朋友邏輯概念,知道運算的基本原則...

Maxine: 我這邊有一個比較直白的提問,就是:我第一次接觸 No Code 概念的時候,我比較把重點放在:「No Code 已經可以取代掉寫程式」。 同時我又接觸到「全民寫程式」這個概念,那時我是想說:「有 No Code 啦!為什麼還要那麼小就提倡寫程式的概念?這兩個概念是不是有點矛盾或衝突?」

Jeff: 從小寫程式有一個比較大的好處是,對於電腦怎麼運作,程式怎麼運作,比較有基本的概念。我自己有兩個小孩,我有給他們買寫程式的機器人「dash & dot」,他可以用類似 Scratch 的方式來讓機器人移動。

我的小孩一個才五歲、一個才七歲,教他們寫程式還是會遇到瓶頸啦,我還沒有特別看到什麼成果。我的確同意說,如果能透過寫程式,讓他們對於邏輯性能夠訓練出來,是很好的,但不太確定他們是不是能做到這一點。

不過,透過寫程式的經驗,至少對於程式能做什麼、什麼是程式容易做的、什麼是程式不容易做的,會有一點概念的話,對於工作會很有幫助,例如你未來擔任 PM ,在跟工程師溝通的時候,會比較知道自己要求的事情,是不是天馬行空、根本做不到的,或者這對工程師來說是非常困難、還是非常簡單的。

因為對非技術人員來說,常常很困擾的是:我不知道這個要求是他花十秒還是十天才做得到的。當你稍微寫過一些程式,你至少會有一些概念,不會瞎子摸象。職場上會有比較立即明顯的優勢是在這邊。

No Code 不是趨勢?

Titan: 再請問 Jeff 一下,我們很喜歡看趨勢的文章,一開始我們講的也是兩個在科技領域打滾很久的人寫的文章,讓我們想到這個主題。不免俗想問你的觀察:像 No Code 這樣的趨勢,他後面催生的應用,哪部分比較有機會有取得比較爆發性的成長?我們常常會喊說今年 IOT (物聯網)會很紅、或是雲端對企業的生產力有很大的升級,或是你剛剛講的電子化。那 No Code 這個趨勢你覺得會有這方面的影響,或讓哪個領域的產品冒出來嗎?

Jeff: 我覺得......雖然我自己公司也算是 No Code 的領域,我還是覺得這個領域一定會有一些產品出來,真正解決問題、變成很流行、變成大公司的產品,但能夠成功的重點,還是在於他有沒有解決企業或消費者的問題,而不在於它是不是 No Code。 No Code 我覺得他只是一個結果,只是解決問題的方式。

到頭來,還是要看這個產品到底解決了什麼非常多公司會有的問題。它們一定是透過解決這些問題,成長為非常茁壯的產品,而 No Code 是一個結果。透過 No Code 的方式,產品有 No Code 的特性,突破了過去需要透過開發人員才能夠做某件事情的一個困境,讓一般人也可以更快達到我們要的事情。

No Code 會是一個產品的特性,而不是最後的結果,我們不是為了 No Code 而 No Code ,是為了解決某種商務上某些問題。因為實際上我們做出來的東西,仍然是各式各樣的資料庫系統,去管理資料、或是其他應用,No Code 是過程,不是結果。

Titan: 我必須說 Jeff 的答案跟我預料的......並不相同。但剛剛聽他回答的過程中,讓我有一個靈感。剛剛問問題的時候,有提到 IOT 這件事情,產業界或是商業趨勢的人已經喊了很多年,但各位觀察你的親朋好友,真正使用 IOT 的多不多?我覺得 Jeff 的答案某一部份可以解釋這個現象:它是不是真的有解決大家的需求?才可以變成這個產品普遍的特性。

例如智慧型手機解決了很多以前發現自己沒有這個需要的,所以現在變得很普遍,大家都想要用這種隨身型的電腦,可以用來溝通、拍照,大家應該很有感,用 LINE。可是 IOT 就是我們想把他當成趨勢來喊、來催生,但市場或者終端使用者並不覺得有解決到他們這樣的問題,所以大家常討論說,這個東西什麼時候要起飛呀?好像沒有真正很明確的分界點,有點像以前智慧型手機在 iPhone 之前以定義來說也有很多智慧型手機,但從某個時間點Android 也加入進來之後,智慧型手機這個產品的類別就這樣爆發出來。是不是我們可以從 Jeff 的回答看 IOT 的趨勢?我覺得說不定可以。

Jeff: 趨勢都缺「殺手級應用」。趨勢在有能夠落實的殺手級應用之前,就只是個趨勢。等到有能夠真正解決問題的應用,它就真的是能夠產生商業價值的地方。

Titan: 今天跟大家聊 No Code,先跟大家解釋,我們覺得是趨勢的這個東西,延伸出我們想要討論的主題。

後來我們跟 Jeff ,從工程師還有 Ragic 從新創公司產業的角度來看,他跟我們解釋了自己的三層的分類,讓我們知道我們原本對No Code 的解釋,對工程師來說不是那麼容易接受;另外就是,在企業和個人組織對 No Code 趨勢會帶來可能的影響是什麼。

最後我們還有跟大家聊到 No Code 這個東西,一開始我們原本會用到趨勢這個詞,但後來覺得比較像是當我們發現這些好用的工具之後,它有一個共通點,就是有 No Code 的元素在裡面,好比 Maxine 在最前面講到的,他之前介紹的 NoCode 網站。為什麼會有 NoCode這個網站,上面列出來的產品並不是為了我們要產出 No Code 的產品而開發出來的,只是為了要解決某一個問題,剛好這些結果被建置 NoCode 這個網站的人察覺,這些工具,我其實不用寫程式我就可以使用,把這些工具放在我的網站,把他列出來,對這些跟我有相同需求、但不會寫程式的人來說,是有幫助的,所以最終還是要回到是不是能解決這個問題,最後還是要回到 Jeff 所說的:所有趨勢都缺殺手級應用,這才是比較關鍵的部分。

標籤: No Code

分類: 雲端工作術, 數位新鮮事

部落格背後使用 Ragic! : 最強大的無程式碼企業電子化工具
把資料放在Excel上不只是拖累團隊的行政效率,他也很容易出錯並且無法進行任何內控。
當您的團隊成長時,使用Excel管理資料就會越來越痛苦。
建立你們的第一個雲端資料庫!
瞭解更多:
我們為什麼要開發Ragic?
免費課程
使用說明
Ragic定價
Ragic應用
最新訊息:
部落格
Facebook
YouTube
立即科技 Ragic, Inc.
02-7728-8692
台北市中正區南昌路二段81號9樓
info@ragic.com