产品和项目是相辅相成的关系，产品的规范、成熟，为项目的快速落地提供支撑，项目的落地反哺产品，促进产品的成长成熟。
软件工程的初期是，我们需要什么，就立项项目，通过项目实现需要。
随着项目的增多，发现项目的相似度很大，甚至于有一些部分能够直接重用。则逐渐将能够重用的部分整合在一起，形成一个新的产品。
产品和项目需求越贴合，项目实现的效率就越高，项目落地的代价就越低。
随着项目的变多，类型的扩展，产品本身的复杂度就会提升，乃至于成为一个专门的课题。这也是当前低代码平台兴起、火爆的原因之一。
产品或工具的本质，都是为了降本增效。
产品的规范、成熟，为项目的快速落地提供支撑；项目的落地反哺产品，促进产品的成长成熟。
一、低代码平台产品
低代码产品要解决两个问题：一是常见系统所必备且相似的模块复用；二是降低系统开发的难度。
基于模块复用，几乎所有系统都需要的权限、组织、用户，就成为了低代码平台的基础部分；
基于降低开发难度，通过页面及元素的拖拉拽完成系统搭建成为设计指导方案，表单、工作流、报表就成为了低代码平台的核心模块。
整体的梳理过程，构建了低代码平台各功能模块的相互联系，厘清了各模块的优先级，从而形成低代码平台成长蓝图：
第一版本：搭建基础：
权限、组织、用户为系统的基础模块；
应用开发工作台，为应用开发提供基础环境；
第二版本：核心模块搭建：
表单、流程、报表为系统的核心模块，作为低代码搭建系统的核心工具；
集成应用，补全应用开发及发布的整体流程，实现应用开发的完整生命流程；
第三版本：补全更多业务场景：
APIX 支持接口编排，实现更多的业务流，丰富实现路径；
图表，提供更为丰富的展示方式，为大屏效果奠定基础；
数据模型，打通另一种低代码搭建的指导方案，通过模型复原页面交互；
第N版本：完善业务场景，提升用户体验：
通用数据处理平台，提供数据同步、数据清洗、数据应用的能力，实现数据再利用；
消息，支持平台消息，提高复用率……
二、项目实现及管理
在产品还未建立起来的时候，兄弟们就只能亲身上场，真枪实干，去把项目一个个抢出来。
产品出来了，针对新的项目，那必须带着产品上阵。这是产品得到验证的第一步，也是关键且很难的一步。毕竟这是产品的初次露面，想象的很美好，实际上可能并不是那么肥四？
涉及到的问题大致包含：
- 产品在项目中使用并不完全贴合，需要基于项目需要改造；
- 除开产品已有部分，其他需求都需要新做，那高低代码如何融合，以及融合的效率如何；
- 在项目执行过程中，产品完成升级，是否将最新产品合并到项目中来；
针对项目来说，赚钱才是根本，所有项目过程中的决策都应该以成本是否最低来考量。
当然，在具有代表意义的项目上，就有可能需要背着产品扛过去。产品在初始项目中使用，总是会存在各种各样的问题。若是完全用成本来考量，可能产品上前线的机会就会很渺茫。
在项目具有典型场景的情况下，需要用项目验证并打磨产品，这时候就不得不上了。用这一个项目的打磨，让产品某一个模块成为标准产品，在未来相似的项目上，就能够获得直观的回馈。这算是成本考量，只是这个成本是长远、多个项目下的综合考量。
随着产品的发展，各个版本产品都会有开发出来的项目，从而形成一个复杂的树，乃至于网。确保良好的溯源记录，在代码树的管理上，需要应用好tag，做好各个上线版本的封版。同时，配合文档等记录，可以进行产品、项目各自的溯源。
若每个项目完结不再有后续，那么溯源实际上并没有那么重要。毕竟，新的项目基本都会基于最新产品去开发。
项目嘛，软件嘛，要的是啥，要的是升级呀，要的是扩展呐，要的是更智能啊？这是啥，这是机会呀？也就是钱啊？
我们的产品升级了，有更好的应用，有更好的能力，你们要不要升级一下？
你们的操作要优化？业务数据要调整？人员结构要调整？
可以的，我们可以这么做这么做，这不需求就来了嘛。
在线下，卷起来的现在，每个人怎么可能只有一个项目呢？那作为项目经理，需要项目中面面俱到、无微不至嘛？有时间有精力，可以的哇！但一个人哪有这么多精力呢？！
项目管理，需要抓大放小。
项目要去详细、精细管理的话，五大过程组，十大知识领域，足够让人沉溺其中。
进行中的项目区分为“正常”或“异常”，直接就可以把项目的很大部分精力节省下来。针对异常项目，抓住关键部分，需求框架、技术框架、最小验证，这些没有问题，其它问题有也是小一点的问题，多加一个人、多给一点时间，也就搞定了。
再配合项目管理列表，周期性进行更新，通常性项目管理就没有大问题的。为啥是通常性的，那种本来就很难、很乱的项目，通常管理肯定是不够的！而通常性项目高效管理才能结余更多精力，应付那些非通常性的项目。
三、产品和项目相辅相成
在操作系统基础上，用产品构建解决方案，实现一个个项目。
产品模块越来越丰富，就会在广度、深度上平衡。每个模块要解决更为广泛的问题，通用性就要很强，而在指定方向的实现上，就会没有那么便捷。
在产品上就会逐渐细分：SaaS型应用，实施型应用，产品应用。
- SaaS型应用：此种应用只需要录入客户的基础信息，简单配置就可以使用；甚至于通用基础数据、字典数据，都可以系统内置；培训和咨询也都可以相对固定下来，落地的效率最高。
- 实施型应用：此种应用需要按照一定流程搭建应用，配合实施流程的培训，学习成本比较低，适用该流程的业务实现效率高，在框架内灵活度高。相比SaaS型应用，落地要缓慢一些，灵活度高一些。
- 产品型应用：此种应用需要了解各个产品的能力，配合产品培训，再梳理客户需求，梳理出实施通路，然后落地实现。整体学习成本较高，实现效率较低，但整体灵活度高，适用范围广。
SaaS型应用，如班组管理，就是指定了用户群体及管理的具体事项。在具体实施时，也无非就是明确使用人员账号及使用模块。整体的理念培训、使用培训都是一致的。
实施型应用，如设备集成，在了解产品设计基础上，了解设备协议，新建设备类型，完成设备接入；实施流程相似，只是不同协议需要深入了解，以及客户所拥有设备不同。
产品应用，如低代码平台，就需要了解各个模块的功能，然后梳理用低代码搭建什么系统，梳理完整通路的基础上，逐渐落地。这种方式前期的学习成本很高，但是应用面足够宽。
进行深度拆解后，要实现低代码平台的深度、快速成长，就需要使用各个层级的产品来搭建项目，从而进行更为深入的锤炼，使得产品各模块更加合理。也在搭建过程中，实现业务的深入理解，从而制作模板，让其他客户基于模板开发，再次极大提升效率。
要实现低代码平台，就是需要其完整解决方案的能力，在少编码的情况下实现系统搭建。而在项目落地上，需要更高的效率，用低代码平台本身产品应用，搭建实施应用则实现对产品本身的校验，还提升了项目实施的效率。这是良性循环的开启，至关重要！
在基于搭建的实施应用，搭建出来SaaS应用，就能够成为各个细分方向的解决方案，在深度上进行深远的拓展。
在产品实现上是有捷径的。
捷径不是偏门，而是少走、不走弯路！
在如下图所示，产品领域内，构建“产品应用”；通过“产品应用”搭建“实施应用”，实现“产品应用”的检核，尤其是各个“产品应用”使用在不同的“实施应用”上，他是否仍旧能够担起自己的责任。
通过“实施应用”搭建“SaaS应用”，本质就是打造解决方案，可以深入业务的深度部分，也反向验证、检核“实施应用”、“产品应用”。
低代码平台实现的捷径是：标杆客户的关键项目。
产品设计按照自身的设计原则，进行产品蓝图建设，然后进行“实施应用”、“SaaS应用”搭建模拟，验证设计的合理性。
在产品落地上，可通过标杆客户梳理解决方案，由解决方案梳理实施方案，由实施方案梳理产品模块，最终通过低代码产品搭建实现出来，实现整个通路的落地验证。
完成标杆客户的建设，是产品落地的实例，为推广、演示提供高可信的资料。且标杆客户本身在行业的地位，也会促进推广，形成自传播效应。
抓住标杆客户，实现客户需求落地。过程中，不自觉就完成低代码平台0-1的界线跨越。
人生也是有捷径的，少走弯路就是捷径。
