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