04｜演进策略：先发展通用能力还是先满足业务需求？

总结得真好。 我13年创业想打造的产品，当时想做的最终形态就是作者上一节描述的那个天花板模型。作者说的每一点都打到我心里。 这一节描述的通用性和业务定制化也是我们当初矛盾过的两难问题，当时mvp阶段，不知道到底是运气好还是运气不好，拿下了一个百万级的客户项目。甲方it负责人由于认可低代码理念（当时是2013年，我们都不知道自己做的东西叫做low code），给了我们充分的耐心。但再多的耐心始终敌不过需求部门的压力。由于我们担心自己变成“毒瘤”，担心项目黄了，担心现金流断了（当时拿了预付款之后立即做了人员扩招），最终妥协了，放弃一开始定下的通用化策略，投入许多人力做定制化。 慢慢的，产品被带偏了，我们花了许多人力去满足业务需求，但由于mvp阶段底座的不不牢固，以及核心开发人员的分心参与，我们做出来的“定制化”功能反而没有很好的体验，沦为彻彻底底的四不像。 后来，项目黄了。再后来，我们花了很多精力，把定制化的那些功能解藕，抛弃，重新坚持走通用能力的路线。 再再再后来的2017年，我们没等来低代码的春天，把团队解散掉，公司结业掉了。截止目前为止，任然有小几十个客户项目在使用我们的平台，尽管已经超过四年没有功能迭代。尽管包括我在内的团队人员已经天各一方。 王婆卖瓜一下我们当初做出来的东西，底座包括了一套傻瓜化能过在线建标做ddl的“动态数据库表”引擎，包括了一套bpmn标准的，可视化拖拽的工作流引擎（内置了activiti），包括了可以在界面做ux和自定义表单的“视图”管理模块，包括了一套支持groove和el脚本语言的执行引擎，包括了开放api，可以引入标准化的外部数据源，包括了企业微信的配置化绑定和对接。 非广告。有感而发，仅缅怀一下已逝去的一段青春。

MVP：最小价值产品或最小可视化产品，这在精益创业是中很重要的概念。也就是先臆想一款产品，他有什么功能，要解决用户什么需求。但是，没有经过用户验证的功能是很危险的！！！所以在开发运营之前，先去验证该产品要解决的用户需求确实是存在的。 这个是我在知乎搜到的答案，请问此处的MVP阶段是否是这个含义

成熟期，优先发展低代码平台的通用能力，非常赞同这个观点。 不管是对低代码公司的老板、投资人，还是购买低代码平台的客户，最优先关注的肯定是收益。产生收益的是业务能力，这是一个公司保持竞争力的直观体现。 技术能力是支撑业务能力实现的一种手段，不是唯一手段。只有技术能力不断积累了，对业务的支撑才有更大的想象空间。卡脖子的问题不解决，就会受制于人。低代码平台的通用能力就是其“卡脖子”的问题，不提升这个能力，最后这个平台只会在一片谩骂嫌弃声中消失。 这对以低代码平台为卖点的创业公司是“性命攸关”的问题。

请问有交流群么？

请问老师内秉性知识是什么意思？搜了一下没有看到相关结果

去年搞过一个简单的低代码项目（当时是两个人），开创性地基于 TypeScript define type + reflect-meta 替代了 JSON Schema 的协议方案。但是使用场景非常狭窄（只解决了小程序首页） 今年换了领导；要我们对着钉钉宜搭 & 简道云抄，两个月上线（4个人）；诶。。。

讲的不错，就是有点啰嗦，希望以后能精简一些。

低代码平台，需要时间成本，这对于大部分公司来说可能都是一个巨大的问题。18年以来先后接触过两个低代码平台的开发，都不疾而终，公司最多给你两个月时间。

打卡

受资源限制，LCDP的实现需要采用逐步迭代的思路。优先满足通用能力，在紧急情况下定制需求。跟客户的关系，抗压能力都影响