2B产品别被无代码、低代码、PAAS带偏了！

guozhiwei · 发表于 2022-11-23 08:50:40

　　粗看题目觉得我会驳斥无代码、低代码、PaaS其实不是！我是坚定的支持者而且在这上面还投入了时间、精力、成本；那为什么我还会这样说了？我举个例子，有个成语叫“买椟还珠”意思我就不解释，我认为无代码、低代码、PaaS是“椟”而不是“珠”，当然美轮美奂的包装确实能让盒子里的实物价格倍增，注意是价格而不是价值，实物该有的价值不会因为包装而改变。CRM定制https://www.bnocode.com/crm.html白码低代码平台开发的软件数据和流程都是通过可视化组建的，无需编写代码，只需要通过拖拽平台内的功能组件就能够完成软件的开发。白码提供可持续升级调整、数据中台、原系统对应数据免费导入、定制云服务、安全系统服务、支持多种API对接等技术支持。白码可以实现多种复杂的业务流程，完成ERP、CRM等多种复杂逻辑的软件。白码开发平台可以帮助开发者和企业技术开发团队增加软件开发速度，降低开发成本，达到降本增效的目的。联系电话：020-88520693!

　　我们需要思考的是为什么2B（2大B）产品都在喊这个，那是因为2B这个行业太千变万化了，简直可以说到了魔幻的地步；如果把“hello world”封装成一个产品，到2B来应用的话，你会发现最后交付出去的成品，是千奇百怪的，但是这些都是“hello world”的产品，不信咱们可以看下！

　　这就是一个简单的hello world产品在2B这个领域应用后，被玩出的花样，我可以非常负责任的说，这绝不是为了博眼球，可以去问问对同一个产品交付5个项目的人，他一定会感同身受。

　　这才是2B产品现在为什么都搞无代码、低代码、PaaS的原因，因为2B太庞杂了，一套标准产品根本搞不定客户的需求，去交付的每个项目都或多或少有一些开发，即使产品力强大如SAP，也是在产品里封装了一个ABAP开发平台，甚至还对他所有标准功能的代码都是基于ABAP开源的；即使这样我们也从来没听SAP吹嘘他们ABAP开发平台多么强大，多么NB；人家吹嘘的是我的解决方案多NB，我有“最佳业务实践”等等面向客户应用的东西，而非这种面向IT的，因为他们知道你选择SAP是因为看中他能基于本身的产品帮你解决实际业务基于IT系统的管理问题，而不是那个ABAP开发平台帮你开发出功能，并解决你的问题。

　　所以我们2B产品真正的“珠”或“价值”是产品里蕴含的帮助客户解决问题的产品力，而不是无代码、低代码、PaaS这种东西；一个项目中基本80%的客户需求通过产品本身搞定，剩下的20%采用产品附带的开发平台搞定；如果你还是不信的话，我在举个例子，即使产品力强大如微信之父张小龙，当他想解决2C所有人的需求时也是无能为力的，只能弄一个小程序的开发平台，可是人家弄的小程序开发平台，却没有无代码、低代码、PaaS哦，但是小程序确实解决了基于微信延伸出来的所有的问题，人家要的是解决你在使用微信时另外那20%的需求（相对微信、我们用小程序的时间有20%的占比么？）所以重要的是要搞定那80%的需求，连张小龙在想解决所有问题时都无能为力，而是选择了更low的“写代码模式”的小程序开发平台，而非“无代码、低代码、PaaS”等，他选择的是首先能开发出功能本身的“写代码模式”，其次是维护、管理好开发平台本身；当然他最大精力依然还是掌控好“微信”也就是对他来说的那个“珠”！

　　因此对于我们2B产品来说搞定客户80%的需求，才是必须修炼好自己真真的产品力的那个“珠”；如果一个基于产品的交付项目开发量超过20%，那么你的产品就需要打一个大大的“？”；产品不行肯定是大大增长交付周期的，但是当产品提升到可以搞定80%的需求时，交付周期与产品就没多大关系了，只于交付方法论相关了。

　　我这里提出的是如何搞定属于自己产品的80%的需求，剩下的20%就留给产品附带的“无代码、低代码、PaaS”甚至是“代码开发”开发工具实现。

　　这是我提出的分层模型，2B这个领域需求千变万化，就好像那句“一千个读者心中有一千个哈姆雷特”，因此我们需要构建的是一套可沉淀可积累的2B产品系统架构；

　　比如在HR领域 “薪资计算”在中国是千奇百怪，对于这样一个每个项目都不同的需求，我们产品需要怎么搞到80%需求了？我们需要的是不追求一次性全部搞定，我们需要的是构建一套计算薪资的业务模型，并在此模型上搭建各种计算薪资的解决方案；我就当全中国计算薪资有1万种办法，让你的产品搞定1万种算法，那是完全不可能的事，即使你有那个雄心壮志，你也无法在短时间内收集齐这1万种算薪资的方法，因此对于产品来说，就是首先构建算薪资的业务模型；具体怎么构建算薪资的模型，这个太复杂了（当然还有…..）；我换一个最简单的产品类别一下，还是以“hello world”产品为例：

　　这个客户对hello world的需求有7种情况，你就理解为，客户有7种算薪资的要求，也就是对于算薪资全量来说是1万分之7的量，那么我们要怎么搭建这个模型了？

　　经过无数业务专家、研发专家的研究，于是构建了这样一个产品系统架构：

　　基于这样一个系统架构，我们开始构建上述业务模型：

　　基于这个业务模型，我们就搭建起7种解决方案：

　　搞定了客户的需求，如果换成算工资，那么我们就搞定7种算工资的逻辑，但是可以肯定的是算工资肯定比这复杂百倍，但是我们作为2B的产品，我们需要的不就是把复杂的问题进行归纳建模，最终变成一个简单的IT问题么？

　　因此对于计算工资这样一个有1万种可能的需求，对于我们这个模型来说就搞定了7种，如果后续的某个客户有10种算工资的办法，其中有4种和这7种中的4种一样，那么我们就只需要搞定6种方案了，那么等这个项目做完我们就拥有了之前的7种，加本项目的6种，供13种算工资的方案了；那我们就搞定了1W分子13的量了！

　　SAP在同一套系统架构下沉淀这样的解决方案花费了30多年的时间，到现在还在积累沉淀：

　　而他们在1986年沉淀的产品现在还能使用：

　　因此对于2B产品来说，当构建起这套产品架构后，需要的就是持续的多做项目，积累更多的计算工资的算法方案，当我们真的积累到5千种计算工资算法时，基本在2B算工资这个细分领域你就无敌了，一来别人要积累出5千种算法，或者叫方案，首先的拥有和你一样的可被积累的产品技术体系，如果没有他们永远无法积累起5千种算工资的方案，更别说固化到产品里；如果没有这套可被积累的产品技术体系对他们来说就是项目，无法凝聚成一体的产品，就是单个单个的项目散布在各处，一盘散沙，也就是没有产品，只有项目；好！即使他们研发出这样的产品技术架构，那么他们也的和你一样做那么多的项目，花费那么长的时间才能积累堆积出5千种的工资算法；

　　当你已经有5千种算工资的方案了，其实这些方案对你来说成本都已经付出了，其实对于你来说，当两家公司一起去客户那里展示解决方案时，你就是用5千个方案砸都给友商砸死了，友商根本没有那么多算工资的方案，你却有5千种，根本就不用过多的竞争，最终的结果就是强者恒强、赢家通吃的互联网竞争逻辑了！

　　可能有人说不是算工资有1万种么？还有5千种不是还没搞定么？其实在2B应用中，1万和5千是没有本质的区别的，但是1百和5千是有本质区别的！在交付的时候我们只需要说服客户在5千种中选一种就好，或者你干脆按照他们的需求在5千种中推荐几种最合适的，最靠近他们需求的就好。

　　还是以hello world产品举例，如果客户的需求“我要一个首字母大写的Hello world”，其实你给他推荐下面的任何一种，他们基本上都是认可的。

　　毕竟你推荐的比他那个更好啊，一个是两个字母大写，而且结尾还带有标点符号，还有一个居然还有颜色，那就跟好了。

　　只要产品交付人员稍微有点沟通能力，基本上就可以搞定客户选择如上的方案；因此对于2B来说，其实对于全量的1W种需求，只要搞定5千种并沉淀到产品里，就已经全球通吃了。因此最重要的是搭建起可被积累的产品架构，然后在漫长的时间线上积累解决方案到产品里；最终形成不可逾越的基于时间累积起来的高墙。

　　因此我认为的2B产品应该是这样：

　　2B产品首先需要构建出可被积累可被沉淀的系统架构，在后续做到持久的在时间轴+空间轴（空间轴引入更多的合作方可减少时间轴）进行产品积累覆盖更多领域的各个行业的解决方案；同时再搭载一个产品自带的开发平台解决项目中剩下20%的需求，当然这个开发平台最好是无代码、或者低代码、或者PaaS（好像PaaS范围更大^_^），最差也得搭建一个产品附带类似SAP的ABAP的开发平台，或者微信小程序的代码开发平台，谁叫你是干2B的，而且还想解决这个领域绝大部分的需求了？

　　举报/反馈