两周前的MoonshotMafia我们邀请了Zion创始人陆继恒聊了聊他当初创业的一些故事与对创业的一些见解。
本期MoonshotMafia嘉宾
01
奇绩创坛的经历
Moonshot伙伴：
作为奇绩创坛的优秀校友，能不能分享一下参与奇绩创坛时有哪些收获？
陆继恒：
我觉得在奇绩创坛的收获主要分为两个点：
第一是他们所推崇的有效的创业理念：
在奇绩创坛中，陆博士和合伙人会在专门与创业者交流指导的Officehour里强调两件事情：首先不管什么样的产品，都需要尽快地把MVP做出来去面向市场。如果是长期研发的项目，例如做生物基因编辑的公司，可以在长线中寻找一个短的点去做，以尽快在市场获得反馈。这个是奇绩一直在传输的理念，“Makesomethingpeoplewant”，只有推向市场之后，你才可以知道这东西是不是用户要的，再进一步迭代它。
另外一件是理清楚你自己做的东西到底是什么。奇绩创坛有一个模板，会从What，How，Why，Whynot和Whyus这几个问题出发，协助你理清这个项目的基本脉络。这个脉络最终会变成我们在Demoday分享的主轴。这个东西理清楚了，你就会想清楚自己的业务是什么。在面向市场的时候，你也知道做的东西到底是什么。他们还会把项目每个阶段需要做的东西分为锅里的，碗里的、和田里的。锅里的是现在正在做的东西，碗里的是短期会做的东西，田里的是最终会面向的大的市场是什么。
奇绩创业营一直强调的这两点理念，使我在早期不仅能更快地获得反馈迭代，又能有相对长远的计划。
第二点是奇绩创坛提供的交流社群：
他们希望搭建一个正向积极的社区，围绕这个社区可以学到很多创业的东西，为之后的创业项目做准备。奇绩这边也在做像国外YC的HackerNews类似的线上论坛，做一些科技创业上的分享。我们之前也和奇绩一起合作搭建这个平台，现在正在内测当中。
“Makesomethingpeoplewant”
02
创业经验分享
Moonshot伙伴：
我比较好奇您是什么时候开始想创业的？能不能分享一下您如何为面临的创业压力做准备？
陆继恒：
在本科的时候，我就对创业这件事有比较强烈的兴趣。所以后面的研究生的选择、职业的选择、工作地址的选择都是为创业做准备的。
我觉得创业是永远不可能准备好的。唯一准备好的方式就是开始行动，只有开始了才会知道这个想法有没有价值。你每次的失败也是在为下次做准备，所以当你有很多想法的时候，挑一个最让你兴奋的开始做起。很大概率它会失败，但这不重要，这种旅程和学习经历对你来说是更宝贵的。
ElonMusk说他有个朋友做比喻，创业相当于是在玻璃前凝望深渊。YC的比喻是从悬崖上跳下来的当中，一边在下坠，一边在造飞机，让自己飞出去。你不经历一遍这种过程，你永远不会知道将会面临的挑战与压力。
而面对这些挑战，你最好的应对方法就是坚持。我认为在创业这条道路上是否能成功，很大程度上取决于个人与生俱来的意志力。你能不能坚持下去，是取决于你愿意为这个项目牺牲多少，对于绝大多数人来说他们愿意放弃的是很少的。如果对你来说创业不是最重要的东西，你就不会为此放弃掉生活当中的其他东西。
我觉得我和我的合伙人目前还是比较享受这个状态的，主要是因为这两点：
第一，我觉得是要对创业要有正确的期待。很多创业的压力和无助感，其实都是来自于你的期待和你的现实的落差。开创一个公司永远是从一个满是漏洞的桶开始，然后一点点再往上搭。所以要认识到这一点，在从无到有的时期抱足够耐心是很重要的。要学会把抽象的期待打散，变成一个个可实现的小目标。当你的目标距离现实没有那么远的时候，你就会有朝着这方向去奋斗的动力。
第二，以我个人的体验来说，很多成长都是阶梯性的。比如说我们在今年的2月份融资之前，公司的发展其实也比较僵滞。但其实当你的产品发展到了某一个阶段，当你面向了一些真正的客户，可以真正的交付了之后，你会突然发现融资变容易了。这些都是一个阶梯式的，由量变带来质变的一个过程，质变往往是在瞬间发生的。这些是我的体验。
对创业要有正确的期待，从量变到质变
03
Zion与无代码工具：
Moonshot伙伴：
为什么选择无代码工具作为创业项目？
陆继恒：
这个项目的出发点其实是解决我自己的需求。
我和我合伙人在年的时候就认识，在硅谷工作同时兼职做一些创业的项目。我们都是后端工程师，但是对于一个早期的Startup来说，你的MVP面临的挑战通常都是前端上的。你需要思考如何对用户群体呈现这个应用。对后端来说，在应用量增大之后，才会有更大的挑战。
在我们做早期Startup的时候，需要做很多的网页、应用。于是我们当时会学习一些前端的架构，例如React和应用的整合。我们在这个过程中发现，很多人力都用在了重复繁琐的事情上，比如把PRD（产品需求文档）和设计稿翻译成机器可以理解、运行的代码，而这些流程的在技术上的要求并不高。于是我们想到可以有一个更好的工具，把整个端对端的应用开发、制作和上线变得完全自动化。
这个工具其实在年左右存在过，像早期Dreamweaver和Frontpage这类网页开发工具。后来技术变了，所有的应用都变成了前后端分离的架构，这些工具就被淘汰了。在这个新的模式下，我觉得留给新工具的机会很多。
另外我个人认为特别早期的创业者也非常需要这样的工具来更快的去开发面向市场的MVP。刚才提到在奇绩创坛中，包括硅谷精益创业的理念都是这样的：要想“Makesomethingpeoplewant”，更快的迭代是必要的前提。我非常希望能提供一个可以帮助到早期创业者快速上线产品的工具。
在早期Startup做前端时发现，创业者很多精力会投入在一些可替代的流程上
Moonshot伙伴：
在现环境下，无代码工具会遇到哪些挑战？它的技术卡点在哪里？
陆继恒：
首先，无代码这类的工具目前有这几个大的类型。
第一个类型是像Airtable这样表格类的产品，它其实挑战更多是如何把Excel的模式搬到云上，要提供协同的能力，这个相对更偏产品的调整。
第二类是BPM（业务流程建模）的引擎，他们会给企业内部提供很多工具。会给预制好的模块和一个流程的引擎，让企业自己可以进行自动化的编排。它更像是一个预制好的SaaS的工具，但通过一个可视化拖拽的方式，进行更灵活的编排。它的挑战主要是业务逻辑的封装上面。
我们Zion属于第三类。它属于一个全新的软件基础设施的工具，我们面临的挑战其实更多是软件工程方面的。
我们做的其实是三个事情：首先要基于无代码的交互方式重新设计一个通用型的IDE（集成开发环境）交给用户。其次用户进行IDE编排后，这个代码要被自动化地产生出来。这其实相当于开发了一个新的编译器，这个环节也有非常强的工程难度。第三个部分的话是我们产出源代码之后怎么样进行自动化的部署。部署的流程，和整个运营原生平台的搭建，这又是比较大的一个技术挑战。
所以本质上我们做的是一个开发环境加一个编程语言加一个自动化的流程，我们面临的挑战也主要在这三方面。
Zion本质上为开发者提供了一套开发环境，编程语言和自动化流程
Moonshot伙伴：
我个人也觉得无代码在这个信息化时代意义非凡，能为没有代码经验的人提供创造的能力，很想请教一下您对无代码工具行业发展的最终愿景是怎么看的？
陆继恒：
我们希望把全球有软件开发能力的人口比例从0.33%提升到8%，让比之前多25倍的人来做开发。我们非常相信一句话叫“Softwareiseatingtheworld”，软件最终会由内而外地改变整个世界的架构，无代码工具就是其中必不可缺的一环。
无代码的最终的形态其实是一种交互方式的改变。像八九十年代的时候，电脑操作系统从Linux这种命令行的方式逐渐演变成了GUI（图形用户界面）再到MacOS和Windows，直接让更多人可以使用原来只有小范围专业人士才能使用的电脑。
我们认为同样的过程也会在软件开发中发生。现在软件开发其实就像做填空题一样，你的自由度太大了，里面可能会有各种各样的错误。早期的创业者们其实不需要那么大的灵活性。
Zion希望把软件开发中的填空题变成选择题，让用户的精力投入显著降低。缩小了学习成本以后，更多人就可以参与进来了。这个就是我们对可视化编程或者说无代码这种交互方式的最终的愿景。
尽管现在付费用户大多是大公司，我们希望我们的产品最终使用方都是个人。最终像MicrosoftOffice一样变成一个生活中必备的工具，纳入日常工作流之中。
无代码工具把软件开发中的填空题变成选择题
04
公司的建立与运营Moonshot伙伴：
如何找到适合的公司合伙人？如何做好与合伙人的交流和对团队的管理？
陆继恒：
我和我的合伙人是在湾区认识的。我当时刚到湾区，寄住在我一个学长家。我的合伙人和我那个学长正好在一起做一个兼职的项目。一个周末听到他们在楼下争论一些产品功能的开发，我觉得还挺有意思的。因为我当时去湾区的一个非常重要的目的，就是要接触一些创业机会，所以我就下去跟他们交流，最后就加入他们的团队，认识了我的联创。虽然那个项目没有成功，但是发现我和我的合伙人还比较合得来，所以我们之后是一直不断的在做新的项目。
在工作上，我们都属于能比较好地分割主观情绪和理性判断的人。我们也经常会有比较激烈的争论，但是我们会就事论事，而不是带有很强的个人情绪。所以如果在战略层面产生分歧，我们也会直接说出来。这个也是我们公司文化的一部分，叫“BrutalHonesty”。因为我们相信当一个人足够理性、足够聪明，人与人之间绝大多数的分歧，都是每个人看到的东西不一样造成的。当你的信息足够同步的话，最好的决定还是相对明了的。
有一本书叫《闪电式扩张》，作者RayHoffman是Linkedin的创始人。他在里面提到按照员工数量分，公司有五个阶段，从家庭到部落、到村庄、到城市、再到国家，每个阶段的管理是不一样。
目前阶段我们团队还比较小，也就在30~50人的阶段，处于部落阶段，我可以提供的分享，也就只能到这里为止。
我觉得在早期其实不需要过多的管理，有时候管理会给团队不必要的压力。在PreA轮进来之前，我们团队也只有十几个人。那时我更会把我们的整个机制想象成是像学校里面在做项目那样，一个Hackathon的小队，大家一起在做这个东西。
当然当规模到了30多个人的时候，我也会体会到一些管理上的挑战。人多了之后，交流的复杂度会呈几何倍的增长。大家的想法越多，就越需要管理这些预期和观点的碰撞。我们的解决方法会更倾向于通过直接点对点、自下而上的沟通来解决问题，期待每个团队成员间直接联系。
举个例子，比如我们不希望我和合伙人告诉团队要做一个怎样的功能，而是员工在做在用的过程当中、在和客户沟通的过程当中，发现问题，然后去自己提出一个可行的改进方案。这样让公司自发性地运转，让每个人自我管理自己部分的推进，比从管理层下达指令少很多流程上的消耗。
每个团队成员间直接联系，点对点、自下而上的沟通
Moonshot伙伴：
很多时候一开始我们想做一个简单易用的产品，随着客户逐渐复杂的要求，又希望它有更强大的功能，在这个过程中往往会降低应用性。如何平衡产品在应用性与功能性上的冲突以满足不同客户的需求？
陆继恒：
这个问题其实我们也在面临。因为我们相当于在做一个新的开发平台，用户如果用这个平台开发不出来一些他要的功能的话，你的价值就明显的会大打折扣，然后他会选择你的可能性就显著降低。所以我们当时的选择是先