文丨产品晓说（ID：pmxiaosi）
2021开年“低代码”接力“中台”燃起了熊熊之火，引发了众多业内人士论战。其中有两种极端的观念，一种是“低端炒作”、“无用玩具”，另外一种是“颠覆行业”、“取代码农”。
若说“低端”、“玩具”，事实上，国外低代码平台OutSystems估值超10亿美元，Mendix被7亿美元收购；Amazon、微软、阿里、腾讯等国内外IT巨头，以及大量传统软件厂商、新兴SaaS厂商纷纷押注，如此估值与劲头，又岂能以“无意义”一言概之？
二、低代码火爆背景
低代码的形式是“可视化编程”，核心是“复用”。像中台一样，提高复用率是低代码的关键。但单单“复用”不足以解释今年低代码平台的火爆，低代码突然火爆的原因是什么？
2020年的疫情冲击不容忽视，它挑战了很多企业原有的商业模式、协作模式，数字化经济的繁荣、信息化需求的激增，造成程序员供需失衡。
云计算技术的成熟、移动化的趋势等，为低代码2.0提供了技术基础。万维网出现前夕，计算机网络是一座座孤岛，互联网打破了这些孤岛。同样，如今的信息孤岛、云端孤岛屡见不鲜，曾经的低代码作为开发工具也只是在构建孤岛。但“低代码+云”的想象力将不止于此，如果能形成“互联、共生的生态”，它有可能会打破当前应用与应用，企业与企业，开发者与开发者之间的孤岛，大大提高代码复用率，进而引发一次效率的飞跃。
国外低代码平台成功商业化，国内“互联网+”、“数智化转型”风口等都是催化因子。
鉴于当下不冷静的态势，先聊聊劣势，泼盆冷水清醒一下。
低代码平台本身是一个开发框架，能在平台上造出什么很大程度依赖于框架本身的能力。在当前阶段，诸多低代码玩家凭着BPM（业务流程管理）、BI（数据分析）等厮杀于企业协同领域，无怪乎很多看客视低代码为“玩具”。
2、灵活性低
但同时灵活性高，又可能造成易用性下降，灵活性与易用性的平衡对低代码平台来说是个挑战。
很多低代码平台框架对开发者是黑盒，这给开发者带来两大问题，一是活难干，二是没前途。
2）没前途是专业程序员高度依赖低代码平台，而疏于Coding会造成能力蜕化，这长期来看意味着失业和放弃未来。
4、业务方观念扭转难
1）技术门槛，稍有技术含量、需要一定学习成本，就可以拦下很多人；
3）动机门槛，以往业务方动下嘴就能拿到软件，现在让他动手自己干？很多人的懒惰是赤裸裸的现实。
1）跨越技术门槛，可以采用无代码，但需要平衡灵活性的妥协；
3）跨越动机门槛，需要找到足够痛的场景，通过行业模板、业务模板、交互设计等打造足够简单的操作方式。
低代码平台降低了应用开发成本，如果应用爆发式增长，出现大量无人或较少人使用的应用，则对业务价值不大，却会带来额外的认知、管理成本。同时，应用数和使用人数的增长，也会给平台性能带来挑战。另外，用户追求个性化前端呈现与平台固化的前端呈现也是一种需要应对的矛盾。
四、低代码的优势
1、降本
1）学习成本降低是普通业务人员即可操作，为IT研发资源不足的企业降低人力成本。
3）其他成本如沟通成本、测试成本，甚至云架构方式降低硬件成本等。
主要包括2方面，交付效率和协作效率。
通过配置即可满足一批新增或变更需求，直接避免了低价值代码开发时间，开发效率提升10倍并不夸张，同时，也意味着客户响应效率的极大改善，这是比开发效率更重要的事！
由于平台能力复用，会大大缩短端到端交付时长，如测试时长、集成发布时长等都被大大缩短，工程效率的提升，让低代码有超越DevOps进化至NoOps的可能性。
沟通效率。一个需求交付要涉及到很多人，如业务人员、产品经理、开发人员、测试人员等。而借助低代码，很多需求可能在业务部门内容就能实现了。需要沟通的人数少了，沟通效率自然就提高了。
3、提质
低代码平台与“中台”也有类似之处，由专家级开发团队打造便于进化的高质量代码。采用“复用”、“统一”的理念，降本增效、打破孤岛。同样，低代码平台也需要警惕“中台陷阱”，本欲“赋能”业务，不料变成瓶颈，以至业务“无能”。
主要包括3方面，高度贴合业务、缓解低价值需求资源困境、提升程序员价值。
2）缓解低价值需求资源困境。IT团队总会面对做不完的需求，纵有人把控ROI，也难免频繁出现一种怪相“业务方叫的急，上线后却不用”，这种低价值需求对开发资源的占用是极大浪费。对于低价值需求，先用低代码平台满足基础需求可以改善这种困境。另外，也需要思考一个问题，“低价值需求真的价值低吗”，这些被判定低价值的需求很难拿到开发资源，只能永远在等排期，而低代码平台却能给这些“死刑需求”生存空间，这些低价值需求有可能会是组织创新的一个源泉。
5、互联网效应
五、目标用户分析
1、业务人员
我们（低代码平台）如何帮业务人员写好PPT（用好低代码）？提供以下4种策略。
2）模板。懒得想、懒得动、想不清这些现象司空见惯，教一个人快速提升PPT水平的最佳方式就是直接给他一个写好的模板，让他简单改改就成。所以，很多低代码平台走的也是这条路线，把行业内的最佳实践编辑成模板，最大限度为用户提供便利。
4）外包。有些人不愿意浪费宝贵的时间自己写PPT，此时，花点钱让别人代写也是种方法。低代码平台提供或与此类代搭应用的人合作，也可以为用户提供价值，此类人与后面要聊的“运管人员”多有重合。
开发人员的常见痛点是“干不完，没前途”，时间总能被无尽的需求、Bug、变更、重构等塞满。然后，辛苦数年，35岁被扫地出门。纯靠低代码平台难以满足用户的全部需求，而且在满足用户的基本需求后，个性化是必然的趋势，“福特T型车的兴衰”是历史之镜。想服务好客户，必然要与专业开发人员共生。
1）插件市场。低代码平台专注最通用、简单的业务，保障平台基础的易用性。一部分具有通用性的复杂业务，通过插件的方式由用户自主选择，以提供一定的灵活性。采用类似AppStore的思路，引入独立开发者开发插件，这样既能满足用户的个性化需求，又能为独立开发者提供赚钱门路。
3）产品层次。通过产品架构设计让产品具备层次性，即给一线业务人员、二线运管人员、三线开发人员提供不一样的产品能力。对于业务人员，采用“无代码”，以绝对的易用性解决最急迫的业务需求；对于运管人员，采用“无代码+插件”，解决一部分个性化需求；对于开发人员，采用“纯代码+API”，迎合开发人员使用体验，明明可以几行代码搞定的事，就不要让开发者蹩脚的在界面里“拖拉拽”了。
运管人员的常见痛点是“等不及”，面对客户、领导的直接压力，恨不得撸起袖子下手干。只恨接不下开发兄弟的绝招，“You can you up,no can no BB”。此处，运管人员泛指那些介于业务和开发之间的角色，如产品经理、项目经理、运营人员、咨询师、售前等。这些中间角色既能站在业务角度思考问题，又具备一定的软件思维和技术功底，是低代码平台的理想用户。他们可能是最有意愿花时间研究产品使用方法的群体了，满足他们的需求需要低代码平台的UI设计、产品交互和配置能力强大，以迎合不愿将就、略有挑剔的他们。
低代码的消费客户可以分为2类，企业和软件厂商。客户是收入的直接来源，关乎低代码平台的生存。但客户画像这个话题很难聊，一方面它需要细化，泛泛而谈没有意义；另一方面，平台在生存探索中，可能会不断调整。
企业又可按行业、规模等细分，不同类型企业需求不同，甚至审美风格也有独特偏好。如中小企业相对价格敏感，IT人员匮乏，能满足需求即可，追求简单、易用、速度，偏好整套打包方案；大中型企业通常已建成部分系统，可能涉及系统对接、二次开发等，注重安全，相对强势，个性化要求多，讲究产品专业性、先进性等。不同类型企业，需要的方案不尽相同，有些仅需要低代码平台的自由流程定制能力，作为信息化能力补充满足边缘需求；有些需要在特定业务领域先进价值主张，解决企业特定的问题；而有些则需要完整解决方案，并通过简单配置作为主要协同工具。
包括传统软件厂商和ISV，很多传统软件厂商仍在基于流程引擎帮客户做定制开发，低代码工具可以作为搅局者杀入这一领域，帮软件厂商压缩团队规模，以更低成本、更快速度完成项目交付。而定位ISV则需要平台本身具有巨大的客户量，这是巨头们厮杀的领域。
企业面对这个问题通常有2个选择，选择自建低代码平台，或选择购买第三方低代码平台。
在决策是否自建之前至少要考虑清楚3个问题，引入低代码的目的是什么？比购买第三方软件ROI更高吗？公司是否有足够的实力折腾？有些中型企业可能会认为低代码技术门槛并不高，拼装流程引擎、表单设计器、报表设计器等即可，但事实并非如此简单。低代码平台看似简单，但建设成功率并不高。除了要面对本文所讲的低代码的劣势，还至少会面对3个问题：
2）缺人才，作为一个不通用的内部开发框架，几乎没有开发人员会傻到为此葬送前程，公司会因此面临极高的开发人员离职率，频繁的人力更换不仅成本高，而且会影响业务发展。
2、选购低代码平台
1）自身需求。这是最核心的考量因素，不应该对比产品的功能数量、技术亮点等，而应该先明确自身的需求，寻找一个与自身需求相匹配的平台，是需要一个全套平台？还是需要灵活的流程自定义功能？
3）产品开放性。选择低代码平台是一个长期的事，势必会有个性化需求，若平台对二次开发不友好，API不够开放，自家程序员无能为力，企业会面临尴尬的处境。
5）产品性价比。低代码平台本身功能多样性、价格等可能是最后考量的因素，对企业来说，选择、使用所花费的时间成本可能比花的钱更重要。对大企业来说，需要考虑的因素更多，如多端适配、多租户权限体系、运维可扩展性等。
笔者对低代码的未来乐观，但对很多做低代码的公司持悲观态度，尤其资本力量不足的小公司。小公司缺资源、缺技术，不敢犯错，产品规划又容易屈服于客户，生存和成长都不容易。阿里有钉钉的客户群体，腾讯有企业微信的杀器，其他互联网巨头背后也都有足够的人力、财力支撑，小平台该如何竞争？笔者姑且臆测3种竞争策略。
杰弗里·摩尔在《跨越鸿沟》中提到产品诺曼底登陆策略，既先牢牢占据一小块市场和用户，然后逐步积累优势。做通用平台无法跟巨头竞争，应该规避劣势积累优势，在起步阶段，先垂直深耕一个领域，逐步完善产品，让产品更匹配客户的业务、审美、交互等，对比巨头形成差异化优势，待成熟之后开始拓展服务领域。
虽说把低代码仅当工具略显低端，但如果能借开源聚集足够多的开发者人气也能形成一定的竞争力。借助开源促成活跃的开发者社区，形成类似Python的强大类库或AppStore的市场。简单需求让客户通过工具本身设置快速实现，中复杂需求让客户通过插件配置化实现，高复杂需求让客户可以快速找到开发者定制实现。平台提供插件市场和开发者定制市场，让客户、开发者和自身三方得利。以此，低端打高端，农村包围城市。
最后，关于架构，尽量解耦，低代码不只是适用于流程类场景，如表单自主设计、列表页自主设计、工作台、数据可视化等均可以成为独立的服务，以此为开发者提供足够的选择空间。
小公司的低代码平台谈产品规划有些奢侈，先拿下客户项目，一方面可以活下来，另外能跟随客户一同进化。尤其是行业大客户，虽然有时候他们的需求有些个性化，但这些个性化需求背后可能隐藏着行业痛点。通过行业深耕，打造“行业基础应用+低代码能力”以形成行业竞争力，而后逐步向企业上下游探索。
【钛媒体作者介绍：李晓杰；微信ID：ecdoer；微信公众号：产品晓说（ID：pmxiaosi）。10年以上产品、项目管理实战经验，近7年服务大B端客户运营商（移动、联通），核心产品为企业信息化与协同，包括低代码平台、DevOps研发协同、项目及财务管理、OA协同、企业门户、数据可视化等，希望与同路人共同探索产品经理成长之路。】
