云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
如果你对数码趋势的议题很感兴趣、你不是工程师但喜欢四处找数码工具提升自己的工作效率，或是因为接触了 Ragic、Zapier 等服务，对“不用写程序，就能做出 XXXX 应用”的软件有些好奇的话，“No Code”是一个你可以认识、探究一下的新名词。
不用写程序，就可以透过特定工具做到传统需要写程序才能做到的事情，例如创建表单系统、ERP，因为这个“No Code”工具已经帮你把底层的程序写好了。这个词目前没有很严谨一致的定义，所以大家想像中 No Code 工具的范围可能不大一样。不过比较没争议的是，Ragic 就是一种 No Code 工具。
和 No Code 类似的另一个名词是“Low Code”（低代码工具）——就是只要写少量的程序，就可以达到传统要写一堆程序才能做到的事情。
（我们针对 No Code 概念的详细说明可另外参阅这篇）
最近， Ragic 的 Jeff 受邀到一个 podcast （在线广播）节目——三创育成基金会的《星箭广播》当来宾，就是以“ No Code”这个议题为主题。50 分钟的节目里，聊到了“趋势观察者口中的 No Code 新趋势是什么”、“No Code 到底是不是一个趋势”、“No Code 的定义要画在哪里”、“工程师对 No Code 的矛盾情感”、 “No Code 到底对一般人生活 / 工作生成了什么影响”，里面也提到了许多 Ragic 的经验。你可以直接点下面的播放器收听：
或者另外点击节目收听链接：请点这里。想看字版的，我们下面提供了完整的开场后的逐字稿，这里逐字稿的分段目录跟《星箭广播》的章节目录是一组的，有需要的话可以搭配着听 / 看。
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 期的周报也有介绍这篇文章。
我一开始注意到 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 这样的公司。
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 这样服务的公司，可以提供我们多一点的想法。
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 不行），就会有这样子的挣扎。
可是对于非开发人员，就完全不是这样。非开发人员原本就不会写程序，所以今天你给了他这样的工具，可以做 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 就是你在使用这个工具时，你还是要会写一些程序才行（但只需要写少量的程序）。
回到刚刚 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 ，对他来讲可能就没有在这个范围里。我想这是我们的听众，不管是工程师或是对这个领域没有那么熟的人来说，可以多了解一下真正工程师的看法，跟我们在网络上读到的趋势文章的看法、出发点是不一样的。
刚刚 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 在公司应用上很实际会看到的好处。
Maxine: 但如果我们今天回头讲...因为今天 Jeff 讲的是用户，想要使用这样工具的人，他等于自己有很大的弹性对自己客制化的状况。可是以一个企业组织来看，如果每个人、每个部门都可以自己决定的话，会不会对老板或管理部门会有疑虑？
Jeff: 会，绝对会，以 No Code 或 Bring your own application 来说，其实碰到公司第一个问的问题就是：信息安全怎么办？你们又不是信息安全的专业的人员，你们做出来的东西真的安全吗？这些都是公司这么珍贵的资产，我放在你们这些外行人做出来的系统里面，是不是有真的符合我们的安全规范，跟我们用的套装软件或是请专业的程序人员开发出来的（相比），数据是不是真的有安全性？这是公司一定会问的问题。
不过这个问题其实是比较可以解决的。 No code 设置上其实可以做很多考量，很多这都比较是可以解决的。大家最常问的反而相对比较好解决。
第二个常常碰到的是政治问题。信息系统绝对不只有数据在里面，牵扯到流程和人的问题，最常见的信息的政治问题，就是信息部门很难看、被打脸，信息部门说这个 CRM 系统很难做啦，这个至少要两年、要多少预算，结果我们的 Sales 部门觉得两年后才有哦，那用别的东西、用 Ragic ，一个月兜一个系统，觉得欸、不错，上线吧！问一下信息部门行不行？我们要用系统。
这时候他们就很难看了，给老板看，会觉得你们专业信息部门，有那么多资源，说要两年才能做出来，要多少钱；可是人家 Sales 部门自己很快就做出来了，而且他们觉得很好用，怎么办？这时候信息部门就会很反抗，会想办法刁难。
这时候信息部门也满无辜的，他们是哑巴吃黄莲，有苦说不出。看起来类似、功能也类似，不代表他们做的工是白费的。信息部门用 code 写出来的东西，掌控度、精细度，还是优于 No Code 的部分，只是对公司而言，你为了最后 10%、20% 的掌控度，要花十倍时间成本来完成这件事情，这就是公司高层自己会有考量。
尤其是高层又不是很清楚技术或需求细节的话，就会觉得信息部门很难看，就会生成一些政治问题，造成 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: 不会，其实我觉得刚才讲的很多障碍都是针对企业。对个人来说，这些工具能够带来的好处都满明显的，对个人来说，他能带来的好处不少，而且比较没有刚刚提到的后遗症。
Titan: 刚有听到你讲到、我们自己也一直提到“未来”这个词。我们知道台湾现在教育的状况，我们想要让义务教育的课程也涵盖写程序，我们认为这是对于培养未来人才很重要的一件事，教育部就把这件事纳入义务教育要学的东西。但有人质疑说，让我的小孩多了功课、多了学业负担、未来做的工作不一定跟工程师有关；另外也有人会觉得，对家长是负担、家里的小孩能不能学好这个科目没有把握，是不是增加一个麻烦？
另一边看法是，程序教育重点不一定是学写程序，而是透过程序教育教会小朋友逻辑概念，知道运算的基本原则...
Maxine: 我这边有一个比较直白的提问，就是：我第一次接触 No Code 概念的时候，我比较把重点放在：“No Code 已经可以替换掉写程序”。 同时我又接触到“全民写程序”这个概念，那时我是想说：“有 No Code 啦！为什么还要那么小就提倡写程序的概念？这两个概念是不是有点矛盾或冲突？”
Jeff: 从小写程序有一个比较大的好处是，对于计算机怎么运作，程序怎么运作，比较有基本的概念。我自己有两个小孩，我有给他们买写程序的机器人“dash & dot”，他可以用类似 Scratch 的方式来让机器人移动。
我的小孩一个才五岁、一个才七岁，教他们写程序还是会遇到瓶颈啦，我还没有特别看到什么成果。我的确同意说，如果能透过写程序，让他们对于逻辑性能够训练出来，是很好的，但不太确定他们是不是能做到这一点。
不过，透过写程序的经验，至少对于程序能做什么、什么是程序容易做的、什么是程序不容易做的，会有一点概念的话，对于工作会很有帮助，例如你未来担任 PM ，在跟工程师沟通的时候，会比较知道自己要求的事情，是不是天马行空、根本做不到的，或者这对工程师来说是非常困难、还是非常简单的。
因为对非技术人员来说，常常很困扰的是：我不知道这个要求是他花十秒还是十天才做得到的。当你稍微写过一些程序，你至少会有一些概念，不会瞎子摸象。职场上会有比较立即明显的优势是在这边。
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 所说的：所有趋势都缺杀手级应用，这才是比较关键的部分。
