时间进行到2023年的3月，又要开始下个季度的画大饼产品规划。一般来说想法都会受制于环境，一些事情不是想做就能做成的。但是从自己的价值观来说，还是觉的要以一种对的起自己专业性的立场去认真思考，把一些东西讲明白、说清楚。
在设计下个Q规划的时候，因为只考虑功能性设计，所以落脚点还是放在平台能力的增强上。而去年我solo了一套web搭建的系统，这套东西在Q1已经拿去接客交付了，Q2急需在此基础上强化能力，所以这部分单独拿出来写规划。在写TODO前，先写WHY，写WHY的同时，需要想明白这部分局部工作与整体平台的关系；这是搬砖时写了点想法，整理了一下放在这里。
搭建系统与低代码平台
关于低代码能力的强弱是如何决定的，很久之前聊过这个话题，这里再拿出来简单聊聊。考察低代码的平台级应用的能力强弱，要从一个立体多维度的视角去看：纵向的自下而上来看，低代码平台有数据层、ORM层、PaaS层、标准SaaS层和租户虚拟应用层（或者说是租户隔离的表现层），这里面每一层的能力强弱，都会对最终整体的能力产生影响；而横向来看，低代码平台又是以多种不同的应用形态输出其能力的，虽然各家厂商产品设计和提供的功能有所差异，但大多包含这几种能力形态：表单（form）、模型定义（model）、Web/APP（自定义网页/app）、数据视图（BI、大屏、报表）、服务（服务编排、流程定义、webhook以及开放接口等），这些能力都横向的在PaaS层进行输出，提供给用户交互，去创造SaaS，因此这些服务在平台视角里，可以算是横向的“豆腐块”。可以参考如下的示意图。
上面的讨论是为了让参与这件事情的人，能有一个更宽广的视角和更充分的知识背景去讨论接下来的问题。那回到这一小节的主题“提升搭建能力”，我们就很自然的可以理解，这种能力是位于PaaS层（平台服务层）的。PaaS层的功能又分为很多模块，有提供表单服务的，有提供流程服务的，有提供APP服务的，有提供Web服务的，所以再细化一点的说，我们是在强化低代码平台的PaaS层里某种服务的搭建能力。
搭建系统的两个time
位于平台服务层的功能，基本都分为两个time，一个是开发时（或者说叫搭建时/development-time） ，一个是 运行时（runtime），下面我们统一称为搭建时和运行时。因为给PaaS层加功能，这个功能的使用者是两拨人，一波是搭建者，来定义SaaS业务的人，另一波是使用者，使用这些被搭建的SaaS的人。所以提升某种搭建能力要同时考虑 1. 这种能力在搭建时如何被定义。2. 这种能力在运行时如何表现。
构建搭建类系统，我之前YY了一个土味公式：搭建系统 = 产物全局配置 + 组件 + 组件 + 组件+..., 这里的 组件是一个狭义的表述，广义的来说应该是物料，比如在服务编排、流程编排类的搭建系统里，这种物料指的就是服务，或者节点。建设搭建类系统，大部分工作最终都落脚在组件上，结合前面提到的，组件设计要兼顾两个time，这就是做搭建系统产品设计的一个大概框架，或者套路，具体执行的产品经理和研发，大部分开发精力也是围绕着组件去投入的，起码在前期是如此。搭建类系统的能力强弱，在很大程度上是由组件的丰富程度和能力强度决定的。组件丰富且规划合理的系统，强于组件匮乏规划失调的系统；同样的一个组件，做的功能表达丰富且功能坚固的，强于功能浅薄且不稳定的。至于全局配置，指的是产物级别的配置，比如Web搭建的页面级别配置，服务编排的服务级别配置，视图的单个报表级别的设置，这些很重要，但他们不太能限制决定产物本身的能力。
前面提到的两个time，根据平台的定位不同, 在功能设计和资源分配上也应该有不同考虑。如果平台是对外的，则搭建时和运行时同等重要，搭建时过于薄弱和难用，会限制业务生产的能力；运行时过于薄弱，终端用户会获得糟糕的使用体验。如果平台是对内的，则运行时的重要性大于搭建时，因为对内的低代码系统，其搭建时主要服务的是公司内部人员（产品、业务架构师、解决方案工程师），运行时主要服务的是公司外部的客户，他们是买SaaS系统去解决企业问题的使用者。功能设计和资源分配，应该与重要性相匹配：平台对外，搭建时与运行时的资源分配应该是均衡的；平台对内，运行时的需求应该不小于搭建时的需求。否则就会陷入高射炮打蚊子的窘境，比如我来这家公司之前和前期，绝大部分的资源都在做搭建时，加各种限制、搭建器里组件各种细致、运行时里组件就是个纯文本，甚至链接跳转都用不了，造成的结果就是搭建器被吐槽难用，运行时效果又被客户吐槽。站稳脚跟后我提了一波运行时需求，起了个头，之后才有所好转，两个月左右，在用户满意度和交付能力上就有了跃进式的提升。拿一个数据管理页面感受下：
再一次说明了什么道理？方向错了，越努力结果越可怕。
重“搭建”而轻“运行”现象的透视
对搭建时投入大精力，而忽略运行时的质量，这基本是做低代码平台中搭建类系统的通病，几乎所有的研发团队都会掉入这个陷阱。有多种因素造成了这种现象，一是研发人员过于侧重技术思维，二是研发团队里汇报关系的利益驱动，三是产品经理的方向有问题。
研发人员默认会站在技术实现的角度考虑问题，侧重技术思维，或者说是狭隘的技术世界观。首先不能指望所有的产品和研发，在对低代码的理解上都达到salesforce的设计水平，如果不是在头部厂商那能接触的研发大概率也是草根出身，这是市场所决定的。在这个等级的研发还不能有一个更全局更宏大的视角去看待技术需求，反而是一种“难点驱动”的方式去决定哪些工作重要，哪些工作不重要，而最终他们认为的难点，又往往不是什么重点。比如绝大多数的前端低代码的理解就是“低代码 === 搭建”，所以对前台工程师来说，他们实现了某个页面搭建器或者表达搭建器，在后台存一个json，上层包装点业务，然后就认为自己完成了一套低代码平台，这就是典型的前端自嗨，而这些仅是低代码平台最上层功能的一小部分，并不是全貌。再比如后台，认为实现一个元数据库就已经很牛了，然后在上层对接某种表单搭建系统，这就是他们对低代码的全部理解，然而所谓的元数据库设计，为了应付元数据的可拓展性，运行时数据选择放在非关系型数据库里。因为他们对电商的那种并发强度可能缺乏理解，也没有考虑过salesforce的真实业务体量，不可能从需求和场景问题出发去设计系统和投入精力，只能从他们所谓的“难点驱动”。低代码、IoT和电商，其实都算典型的高并发场景，选择用 OLTP 关系型数据库 ，因为 T 是 Transaction，能保证事务的一致性。在salesforce内部是用Oracel数据库，性能更好。国内想山寨，只能用 MySQL 这种开源的数据库，mongodb 这些都不在考虑的范围内，因为事务支持得不好。
还有一种可能性是，对他们来说仅仅处理他们所谓的“难点”就已经占据了所有的有效精力。
利益驱动是导致“重搭建轻运行”的另一个原因。研发的汇报体系与产品的汇报体系是不同的，由这种汇报体系决定了研发更倾向于朝着“搭建”使劲儿。研发的汇报是由考核决定的，研发的绩效指标里会有对技术难点的考察，或者说是技术创新。头部互联网厂商，每年S1和S2定KPI目标时，团队也会建议从技术和业务两个维度去思考建设方向。考核标准决定了需要在工作中体现技术的难度和产出；汇报体系决定了研发只向研发负责，而不是从整体系统的功能利益视角去思考问题。所以写代码做技术的利益是每年都要给自己找点“难点”和技术闪光点，但他们认为的难点，就像前面说的，和全局产品功能的重点相比，是不匹配的，就会产生不对称的风险。难点有很多种：显而易见的、市场公认的、表面的难点，难以发现的、专业性的、经验性的、基于问题全貌和大量信息调研后确定的难点。很显然，低代码平台里的搭建类系统中的搭建部分（这个有点绕）就是一个上佳的选择，技术上这是一个在普遍认知里“毋庸置疑”的技术闪光点，业务上也有投入的价值，可是这个方向的产出对搭建产物的终端用户来说并没有直接的感受。
利益驱动还有一个理解的角度是“市场利益”。程序员倾向于美化简历，这直接体现在他们对任务分配的反应里，每个人都想做那种看起来“有技术难度”的，本质上是想做那些“能在简历中体现价值”的。什么能体现价值呢？如果简历中突出自己做过某些搭建系统，或者低代码系统，面试官也是开发，与上一段里说的不会有太大差别，一定会好好问问你“毋庸置疑”的难点。这仿佛就是一种默契或者共识，在行动中就潜意识的一顿写搭建器，对运行时、终端用户和搭建产物的体验都漠不关心，轻“运行”。
最后一个原因是产品经理的决策方向出了问题。比如在目前的产品团队里，我粗略统计了过去1年的需求，按照搭建还是运行进行分类，落地在搭建时的需求占据了一大半，虽然一定程度上与短期追赶竞品的整体战略有关，但在战略下的团队执行方面去看，这个状态是不健康的，这个不打算展开聊了，因为一个混子不应该在一个自己不擅长的领域说过多具体的东西。
