一、前言

2021开年“低代码”接力“中台”燃起了熊熊之火，引发了众多业内人士论战。其中有两种极端的观念，一种是“低端炒作”、“无用玩具”，另外一种是“颠覆行业”、“取代码农”。

若说“颠覆”、“取代”，事实上，低代码、图形化的开发模式存在至少已有20年历史了，又岂能在今天突然颠覆？

若说“低端”、“玩具”，事实上，国外低代码平台OutSystems估值超10亿美元，Mendix被7亿美元收购；Amazon、微软、阿里、腾讯等国内外IT巨头，以及大量传统软件厂商、新兴SaaS厂商纷纷押注，如此估值与劲头，又岂能以“无意义”一言概之？

所以，先别急着下定义，我们多角度来看一看。本文将分两篇，上篇主要从行业角度聊，偏BRD/MRD，主要话题是低代码火爆的背景、优势、劣势，主要用户、客户，企业选择及行业竞争等；下篇主要从产品角度聊，偏PRD，主要话题是低代码平台技术模式、产品架构、核心引擎、配套能力等。

二、低代码火爆背景

低代码是一种软件开发模式，简单“拖、拉、拽”即可快速搭建软件。本文默认无代码是低代码的一种形态，两者具体定义此处不再赘述。

低代码的形式是“可视化编程”，核心是“复用”。像中台一样，提高复用率是低代码的关键。但单单“复用”不足以解释今年低代码平台的火爆，低代码突然火爆的原因是什么？

1、社会、经济因素

2020年的疫情冲击不容忽视，它挑战了很多企业原有的商业模式、协作模式，数字化经济的繁荣、信息化需求的激增，造成程序员供需失衡。

2、技术因素

云计算技术的成熟、移动化的趋势等，为低代码2.0提供了技术基础。万维网出现前夕，计算机网络是一座座孤岛，互联网打破了这些孤岛。同样，如今的信息孤岛、云端孤岛屡见不鲜，曾经的低代码作为开发工具也只是在构建孤岛。但“低代码+云”的想象力将不止于此，如果能形成“互联、共生的生态”，它有可能会打破当前应用与应用，企业与企业，开发者与开发者之间的孤岛，大大提高代码复用率，进而引发一次效率的飞跃。

3、环境因素

国外低代码平台成功商业化，国内“互联网+”、“数智化转型”风口等都是催化因子。

三、低代码的劣势

鉴于当下不冷静的态势，先聊聊劣势，泼盆冷水清醒一下。

1、能力弱

低代码平台本身是一个开发框架，能在平台上造出什么很大程度依赖于框架本身的能力。在当前阶段，诸多低代码玩家凭着BPM（业务流程管理）、BI（数据分析）等厮杀于企业协同领域，无怪乎很多看客视低代码为“玩具”。

但同时也应该看到，一方面，即使“玩具”也能为许多企业信息化转型提供很大助力；另一方面，已经有玩家开始向APP、游戏甚至更高的层面探索，承载核心业务、复杂应用、多变的C端未来可期。

2、灵活性低

虽然很多低代码平台标榜自身灵活性强、解决企业个性化需求，但其前提是在框架能力范围内。如果个性化需求刚好不在框架能力范围内，二次开发实现成本、时间都不容小觑。若企业所选的低代码平台刚好又不够开放，对平台支持和升级的强依赖性会让企业有苦难言，这便是所谓“锁定”。

但同时灵活性高，又可能造成易用性下降，灵活性与易用性的平衡对低代码平台来说是个挑战。

3、开发者不友好

很多低代码平台框架对开发者是黑盒，这给开发者带来两大问题，一是活难干，二是没前途。

1）活难干是在开发时一旦遇到Bug、性能等问题，由于不清楚内部实现逻辑，问题排查无从下手，代码调试要反复切换界面，只能浪费时间干瞪眼等平台支持时。

2）没前途是专业程序员高度依赖低代码平台，而疏于Coding会造成能力蜕化，这长期来看意味着失业和放弃未来。

专业开发者是低代码生态中极重要的参与者，如何让专业开发者自愿入局对低代码平台来说也是个挑战。

4、业务方观念扭转难

普通业务人员是低代码平台关键用户，但让业务部门把低代码平台用起来，至少要跨过3个门槛：技术门槛、心理门槛、动机门槛。

1）技术门槛，稍有技术含量、需要一定学习成本，就可以拦下很多人；

2）心理门槛，很多人会出于畏惧新事物和学习而拒绝接受；

3）动机门槛，以往业务方动下嘴就能拿到软件，现在让他动手自己干？很多人的懒惰是赤裸裸的现实。

这3个门槛并非不可跨越，但却需要耗费心思。

1）跨越技术门槛，可以采用无代码，但需要平衡灵活性的妥协；

2）跨越心理门槛，需要产品讲好故事、做好交互设计，调整如“BPMN图、ER图、外键、函数、脚本”等专业词汇，尽量避免触发用户畏惧心态；

3）跨越动机门槛，需要找到足够痛的场景，通过行业模板、业务模板、交互设计等打造足够简单的操作方式。

5、应用治理、平台性能等

低代码平台降低了应用开发成本，如果应用爆发式增长，出现大量无人或较少人使用的应用，则对业务价值不大，却会带来额外的认知、管理成本。同时，应用数和使用人数的增长，也会给平台性能带来挑战。另外，用户追求个性化前端呈现与平台固化的前端呈现也是一种需要应对的矛盾。

总之，低代码是个好东西，框架本身可以大大提升效率，但同时，它也存在着一些问题。莫要“成也框架，败也框架”。

四、低代码的优势

看了很多低代码平台的劣势，也莫要灰心，先让克里斯坦森为我们打打气。他在《创新者的窘境》中定义了“颠覆式创新”，即比市场上现有产品更为便宜、更为方便的替代品，它服务于低端消费者或新消费群体，步步蚕食传统产品的市场份额，最终取代传统产品的统治地位。低代码平台是否是颠覆式创新，我们拭目以待。

1、降本

主要包括3方面，学习成本、开发成本和其他成本。

1）学习成本降低是普通业务人员即可操作，为IT研发资源不足的企业降低人力成本。

2）开发成本降低是对于开发者而言，可以复用既有能力，减少低价值代码耗费时间，同时，很多需求变更可通过配置方式实现，缩短了开发、运维等时间。

3）其他成本如沟通成本、测试成本，甚至云架构方式降低硬件成本等。

2、增效

主要包括2方面，交付效率和协作效率。

1）交付效率

通过配置即可满足一批新增或变更需求，直接避免了低价值代码开发时间，开发效率提升10倍并不夸张，同时，也意味着客户响应效率的极大改善，这是比开发效率更重要的事！
通过配置无法完全满足的需求，虽然仍有开发工作量，但由于可以复用平台能力，也节省了相当一部分开发工作量，提效数据要看具体场景，但总体而言，复用带来的效率提升不容置疑！
由于平台能力复用，会大大缩短端到端交付时长，如测试时长、集成发布时长等都被大大缩短，工程效率的提升，让低代码有超越DevOps进化至NoOps的可能性。

2）协作效率

沟通效率。一个需求交付要涉及到很多人，如业务人员、产品经理、开发人员、测试人员等。而借助低代码，很多需求可能在业务部门内容就能实现了。需要沟通的人数少了，沟通效率自然就提高了。
天生敏捷精益。敏捷追求的核心关键字，如“尽早交付”、“快速反馈”、“响应变化”等低代码平台生而有之，通过配置快速交付，让程序尽早接受业务校验，迅速得到反馈，并及时调整。精益追求的核心关键字，如“价值”、“消除浪费”、“内建质量”等低代码平台同样生而有之，低成本快速验证，聚焦业务设计而非程序设计，通过业务聚焦、标准化、复用、少人化等消除不产生价值增值的活动，通过平台本身内建质量保障所有应用质量等。

3、提质

Bug界有个绝对真理，“代码越少，Bug越少”，低代码平台开发应用所需的代码量决定了其Bug量极少，甚至，“No Code，No Bug”。

低代码平台与“中台”也有类似之处，由专家级开发团队打造便于进化的高质量代码。采用“复用”、“统一”的理念，降本增效、打破孤岛。同样，低代码平台也需要警惕“中台陷阱”，本欲“赋能”业务，不料变成瓶颈，以至业务“无能”。

4、价值

主要包括3方面，高度贴合业务、缓解低价值需求资源困境、提升程序员价值。

1）高度贴合业务。一个好的B端产品不是功能牛X，而是恰好能解决客户当下的问题。这就需要产品可以适应不同成熟度的客户，而不是一个标准方案走天下。笔者曾持此理念帮多省、多家运营商落地研发协同平台，针对不同客户成熟度给不同解决方案。传统的标准化产品无法支持此理念，但低代码平台却具备这个能力，笔者对低代码平台的信念之一也源于这种经历。

2）缓解低价值需求资源困境。IT团队总会面对做不完的需求，纵有人把控ROI，也难免频繁出现一种怪相“业务方叫的急，上线后却不用”，这种低价值需求对开发资源的占用是极大浪费。对于低价值需求，先用低代码平台满足基础需求可以改善这种困境。另外，也需要思考一个问题，“低价值需求真的价值低吗”，这些被判定低价值的需求很难拿到开发资源，只能永远在等排期，而低代码平台却能给这些“死刑需求”生存空间，这些低价值需求有可能会是组织创新的一个源泉。

3）提升程序员价值。低代码可以帮程序员减少在低级重复性工作上浪费时间，从而可以有更多时间专注于高价值的代码，可以更深入业务，以更匹配的方式满足业务需求。

5、互联网效应

“低代码平台+云”的生态，让程序开发这门生意，上升到了互联网的层面，兼具了互联网四大效应，梅特卡夫效应、双边市场效应、规模经济效应、协同效应。这才是低代码2.0的想象力真正所在！打破信息孤岛，让应用与应用、企业与企业，开发者与开发者互联共通，给“复用率”一次质变！

五、目标用户分析

低代码的终端用户可以分为3类，完全不懂编程的业务人员、专业编程的开发人员、拉通业务与技术的运管人员。不同的终端用户定位，决定了低代码平台不同的演进方向，其重要性不言而喻。

1、业务人员

业务人员的常见痛点之一是“做不对”，开发交付的软件跟预期有偏差，低代码平台给了他们亲手打造高度匹配业务需求应用的机会，无需再骂IT能力弱了。此处祭出一个比喻，“低代码将像PPT一样普及”。PPT给了很多人表达自我的机会，然而，却没多少人能用好PPT，这是PPT这个工具的问题吗？

我们（低代码平台）如何帮业务人员写好PPT（用好低代码）？提供以下4种策略。

1）培训。通过培训让业务人员理解工具的逻辑，能解决的问题，常用的方法等。让业务人员在遇到问题时有意愿尝试用工具解决，培训方法如帮助中心、视频教程等。

2）模板。懒得想、懒得动、想不清这些现象司空见惯，教一个人快速提升PPT水平的最佳方式就是直接给他一个写好的模板，让他简单改改就成。所以，很多低代码平台走的也是这条路线，把行业内的最佳实践编辑成模板，最大限度为用户提供便利。

3）教育。这是培训的进阶状态，不只是教人用PPT了，也教人写PPT的思路。低代码平台深耕细分行业、细分业务领域，结合工具输出专家在该领域的最佳成功实践，让用户在使用工具时也能有业务认知成长。另外，培训业务也是一项收入，一个护城河。

4）外包。有些人不愿意浪费宝贵的时间自己写PPT，此时，花点钱让别人代写也是种方法。低代码平台提供或与此类代搭应用的人合作，也可以为用户提供价值，此类人与后面要聊的“运管人员”多有重合。

2、开发人员

开发人员的常见痛点是“干不完，没前途”，时间总能被无尽的需求、Bug、变更、重构等塞满。然后，辛苦数年，35岁被扫地出门。纯靠低代码平台难以满足用户的全部需求，而且在满足用户的基本需求后，个性化是必然的趋势，“福特T型车的兴衰”是历史之镜。想服务好客户，必然要与专业开发人员共生。

如何打造开发人员愿意参与的低代码共生生态？提供以下3种策略。

1）插件市场。低代码平台专注最通用、简单的业务，保障平台基础的易用性。一部分具有通用性的复杂业务，通过插件的方式由用户自主选择，以提供一定的灵活性。采用类似AppStore的思路，引入独立开发者开发插件，这样既能满足用户的个性化需求，又能为独立开发者提供赚钱门路。

2）开放对接。改善低代码平台“黑盒”属性对开发者的不友好，为开发者做故障排查定位提供帮助。另外，平台通过API等方式支持与第三方服务之间灵活对接，为开发者提供自由选择的空间。

3）产品层次。通过产品架构设计让产品具备层次性，即给一线业务人员、二线运管人员、三线开发人员提供不一样的产品能力。对于业务人员，采用“无代码”，以绝对的易用性解决最急迫的业务需求；对于运管人员，采用“无代码+插件”，解决一部分个性化需求；对于开发人员，采用“纯代码+API”，迎合开发人员使用体验，明明可以几行代码搞定的事，就不要让开发者蹩脚的在界面里“拖拉拽”了。

3、运管人员

运管人员的常见痛点是“等不及”，面对客户、领导的直接压力，恨不得撸起袖子下手干。只恨接不下开发兄弟的绝招，“You can you up,no can no BB”。此处，运管人员泛指那些介于业务和开发之间的角色，如产品经理、项目经理、运营人员、咨询师、售前等。这些中间角色既能站在业务角度思考问题，又具备一定的软件思维和技术功底，是低代码平台的理想用户。他们可能是最有意愿花时间研究产品使用方法的群体了，满足他们的需求需要低代码平台的UI设计、产品交互和配置能力强大，以迎合不愿将就、略有挑剔的他们。

六、目标客户分析

低代码的消费客户可以分为2类，企业和软件厂商。客户是收入的直接来源，关乎低代码平台的生存。但客户画像这个话题很难聊，一方面它需要细化，泛泛而谈没有意义；另一方面，平台在生存探索中，可能会不断调整。

1、企业

企业又可按行业、规模等细分，不同类型企业需求不同，甚至审美风格也有独特偏好。如中小企业相对价格敏感，IT人员匮乏，能满足需求即可，追求简单、易用、速度，偏好整套打包方案；大中型企业通常已建成部分系统，可能涉及系统对接、二次开发等，注重安全，相对强势，个性化要求多，讲究产品专业性、先进性等。不同类型企业，需要的方案不尽相同，有些仅需要低代码平台的自由流程定制能力，作为信息化能力补充满足边缘需求；有些需要在特定业务领域先进价值主张，解决企业特定的问题；而有些则需要完整解决方案，并通过简单配置作为主要协同工具。

2、软件厂商

包括传统软件厂商和ISV，很多传统软件厂商仍在基于流程引擎帮客户做定制开发，低代码工具可以作为搅局者杀入这一领域，帮软件厂商压缩团队规模，以更低成本、更快速度完成项目交付。而定位ISV则需要平台本身具有巨大的客户量，这是巨头们厮杀的领域。

七、企业如何选低代码平台

企业面对这个问题通常有2个选择，选择自建低代码平台，或选择购买第三方低代码平台。

1、自建低代码平台

在决策是否自建之前至少要考虑清楚3个问题，引入低代码的目的是什么？比购买第三方软件ROI更高吗？公司是否有足够的实力折腾？有些中型企业可能会认为低代码技术门槛并不高，拼装流程引擎、表单设计器、报表设计器等即可，但事实并非如此简单。低代码平台看似简单，但建设成功率并不高。除了要面对本文所讲的低代码的劣势，还至少会面对3个问题：

1）成本高，低代码平台是个持续建设的过程，对架构师能力要求极强，还需要解决可能的性能瓶颈问题，而性能问题解决不易。

2）缺人才，作为一个不通用的内部开发框架，几乎没有开发人员会傻到为此葬送前程，公司会因此面临极高的开发人员离职率，频繁的人力更换不仅成本高，而且会影响业务发展。

3）速度慢，一旦有个性化或超出平台能力之外的需求产生，就需要对平台框架进行升级，而框架升级通常速度缓慢，此时，业务只能等待；同时，如果没有平滑的升级策略，整个开发团队会反复深陷在应用重构之中。

2、选购低代码平台

选购低代码平台也需要谨慎，选平台容易，换平台难。不同的企业场景不同，无法推荐某家平台绝对适合所有企业，本文仅提供5个通用因素以供参考。

1）自身需求。这是最核心的考量因素，不应该对比产品的功能数量、技术亮点等，而应该先明确自身的需求，寻找一个与自身需求相匹配的平台，是需要一个全套平台？还是需要灵活的流程自定义功能？

2）公司实力。如果低代码平台公司抗风险能力弱，一旦倒闭，数据、时间损失极大。

3）产品开放性。选择低代码平台是一个长期的事，势必会有个性化需求，若平台对二次开发不友好，API不够开放，自家程序员无能为力，企业会面临尴尬的处境。

4）产品生态。如果低代码平台生态能力强，可以吸引到ISV，甚至独立开发者，意味着企业未来的个性化需求不仅可实现，而且成本较低。

5）产品性价比。低代码平台本身功能多样性、价格等可能是最后考量的因素，对企业来说，选择、使用所花费的时间成本可能比花的钱更重要。对大企业来说，需要考虑的因素更多，如多端适配、多租户权限体系、运维可扩展性等。

八、低代码平台竞争策略

笔者对低代码的未来乐观，但对很多做低代码的公司持悲观态度，尤其资本力量不足的小公司。小公司缺资源、缺技术，不敢犯错，产品规划又容易屈服于客户，生存和成长都不容易。阿里有钉钉的客户群体，腾讯有企业微信的杀器，其他互联网巨头背后也都有足够的人力、财力支撑，小平台该如何竞争？笔者姑且臆测3种竞争策略。

1、抢滩登陆打细分市场

杰弗里·摩尔在《跨越鸿沟》中提到产品诺曼底登陆策略，既先牢牢占据一小块市场和用户，然后逐步积累优势。做通用平台无法跟巨头竞争，应该规避劣势积累优势，在起步阶段，先垂直深耕一个领域，逐步完善产品，让产品更匹配客户的业务、审美、交互等，对比巨头形成差异化优势，待成熟之后开始拓展服务领域。

2、开源免费打开发者生态

虽说把低代码仅当工具略显低端，但如果能借开源聚集足够多的开发者人气也能形成一定的竞争力。借助开源促成活跃的开发者社区，形成类似Python的强大类库或AppStore的市场。简单需求让客户通过工具本身设置快速实现，中复杂需求让客户通过插件配置化实现，高复杂需求让客户可以快速找到开发者定制实现。平台提供插件市场和开发者定制市场，让客户、开发者和自身三方得利。以此，低端打高端，农村包围城市。

而当下很多低代码平台对小微企业云资源免费的策略，笔者并不看好。这并不是好的双赢策略，一方面增加了平台本身的成本；另一方面，在乎这点钱的客户本身付费能力、存活率都不高，陪他们玩吃力不讨好。况且，客户的选择成本远远大于金钱成本。不如，直接开源，客户想在自己服务器上玩就让他玩好了，但平台本身也提供优惠的甚至限期免费的云资源，以此吸引客户。

最后，关于架构，尽量解耦，低代码不只是适用于流程类场景，如表单自主设计、列表页自主设计、工作台、数据可视化等均可以成为独立的服务，以此为开发者提供足够的选择空间。

3、深入项目打行业生态

小公司的低代码平台谈产品规划有些奢侈，先拿下客户项目，一方面可以活下来，另外能跟随客户一同进化。尤其是行业大客户，虽然有时候他们的需求有些个性化，但这些个性化需求背后可能隐藏着行业痛点。通过行业深耕，打造“行业基础应用+低代码能力”以形成行业竞争力，而后逐步向企业上下游探索。

【往期推荐】

深入B端SaaS产品设计核心理念

用“系统思考”看破产品开发团队与项目实施团队的相爱相杀

看破皇帝的新装：OKR不一样的视角

B端大客户项目交付中棘手的8个需求问题

作者：李晓杰；微信ID：ecdoer；微信公众号：产品晓说（ID：pmxiaosi）。10年以上产品、项目管理实战经验，近7年服务大B端客户，核心产品为企业信息化与协同，包括低代码平台、DevOps研发协同、项目及财务管理、OA协同、企业门户、数据可视化等。喜欢读书、分享，希望与同路人共同探索产品经理成长之路。

深入看透低代码——阿里、腾讯等巨头火拼的下个风口