本文分享的是基于低代码的敏捷式开发和在豫园实践落地的一些成果，分解出来主要讲三点：第一点是为什么需要低代码？第二点是为什么低代码需要配套敏捷式开发？敏捷式开发具体怎么做？第三点是我们做了什么？也就是敏捷开发模式在豫园体系中的一些实践成果分享。

一、寻找一种新的技术框架

现在，我们来看一下为什么要选择这种技术架构。在早期，我们通常使用一些成熟的企业方案，使用传统的开发方式或是直接购买一些套件。但是我们会发现，有两种情况我们无法实现。

第一种情况，某些公司业务非常广泛，在市场上可能会有很多解决方案，但是由于它的专业性，软件价格比较昂贵。而且有些企业有比较特殊、复杂的管理要求，这些软件实际上可能只有20%到30%的功能可以直接使用，仍需要进行大量的开发才能满足我们的需求，公司会认为自己花了很多冤枉钱。举个例子，比如我们成立一家实验室，实验室起初可能只有几个人，我们去购买一套LIMS系统，别人的报价可能是70万，实际上我们暂时不需要那样复杂的流程和功能，公司可能希望初期只花5、6万元去解决这个问题。

第二种情况，在后疫情时代，我们会发现业务变化特别快，数字化变得非常困难，因为内部管理和业务模式都在快速变化中。这种情况下，你无法在市面上找到直接可用的软件，只能自己开发。传统的开发方式起码以季度去计量开发周期，等开发完，业务模式可能又更新了。

二、为什么会选择低代码技术

首先，我们需要一种新的技术架构来应对这些情况，低代码技术在前几年开始崛起。我们发现，一些低代码公司在做专业的系统，如CRM系统，甚至一些公司还在做ERP系统，而ERP系统是可以检验一个平台质量和框架的天花板；其次，低代码可以结合传统开发，突破限制，可以低成本实现小程序、H5、漂亮界面的软件系统；最后也是最重要的一个原因，低代码本身拥有的一些特别优势，我们详细地讲一下。

· 开发周期短、费用低，覆盖范围广

大部分业务数字化，无需编程，少量的代码就可以实现业务复杂逻辑，丰富的开放API 可实现更多功能。

· IT和业务更融合，产出质量更高

早期的开发方式是让产品需求人员进行调研，然后与开发协调沟通，最终产生一个复杂的需求文档，然而，这个需求文档对于业务同学来说并不容易理解，往往需要花费大量的精力去理解和揣摩。相比之下，现在的拖拉式开发方式更加友好，很好地满足了业务需求，在项目的后期，需求变更的次数也明显减少，因为前期IT与业务的融合更加充分。

· 大量减少系统运维成本

一套部署承载多个应用，减少了大量的服务器和运维工作，平台自带高稳定、高并发、高安全属性。低代码平台一个平台可以部署很多应用系统，假设做了20个系统，在传统领域里面至少需要 20 台服务器，如果要做到高可用、高并发，可能还要加倍，这就需要多少运营成本了？如果一个软件是以 5 年作为一个迭代周期，那 5 年中人的成本、服务器的成本，其实是很多经营者们看不到的，但这些成本很高。用了低代码以后，在这块成本可以大幅减少，可以让企业更多的成本投入于产出、项目，而不是运维保障机制。

三、为什么选择明道云

首先，我们并不只是把低代码看做一个简单的表单填报式工具，而是定位为解决业务核心逻辑的工具，按照这个逻辑，有三点非常重要。首先，我们需要中式操作习惯，虽然很多外国软件功能强大，但是其拖拉的界面并不适用于我们的员工，而且我们也不是很理解外国式的思路，因此我们选择国内的平台作为我们的资源。其次，我们必须考虑的两点是其拖拉式能力以及代码的支持度，拖拉拽能力强大，业务人员才能更好的上手，代码的支持度高，平台的适用性才会高，这两个要素缺一不可。

我们对市面上的低代码开发平台进行了比较，总体可以分为3类，一类是平台所有操作完全通过拖拉拽的方式，组件也很多，对业务人员非常友好，但是很多软件都做不了，天花板太低，这类软件肯定不在我们的考虑范围内；而另一个类就是重代码，他设计思路是从原来的脚手架开发起来的，天花板很高，但需要专业技术人员才能掌握，这也不是我们考虑的范围；最后，我们选择的是介于两者之间的明道云，明道云的代码能力稍逊于传统的开发，但在市面上产品的评估中，它是最适合我们的方案，如果明道再稍微向右偏一点点，那么它的适用场景会更广泛，我们希望明道在这方面能够不断扩展。

四、为什么需要敏捷式开发

为什么需要敏捷式开发？我们发现在进行项目开发时，仅靠简单的拖拉无法完成大型项目，除非你只是做一个非常小的项目，否则一定需要敏捷式开发的机制来保障。

就像建工程一样，传统开发方法论中有瀑布式开发、IBM的Scrum开发等，虽然方法论强调需求的重要性，但实际执行时大量资源被倾斜到了开发中，在低代码开发中使用这样的方法论就不合适了，因为低代码开发工作量很小。我们可以看到的是当下低代码缺少一套标准的方法论，最直接的表现就是项目的需求文档该怎么写？传统开发可能还要写设计文档、开发文档，现在都不需要了，以前可能还要设计数据库、画ER图，现在也不用了，那整个项目的实施计划该怎么列？这些都需要一套标准的方法论来支撑。

第二点是容易形成数据孤岛，难以与现有系统深度融合。这个问题源于低代码平台功能过于强大，导致它可独立完成业务系统的开发，无需IT人员参与。但从IT的角度看，由于系统过多，数据不对接，导致缺乏数据连贯性，这是最令IT担心的问题。例如，在公司采购和物流业务中，两个部门各自开发了一套系统，但由于其商品定义不同，数据无法对接导致出现了数据孤岛。在考虑如何将低代码平台融入公司整个体系时，需要解决这些数据孤岛问题。

另外，对企业来说，必须回答老板的投入产出问题，即ROI。我们做第一个项目的时候还是很顺利的，我作为产品经理加上另一个全栈工程师，我们两个花了一个多月的时间就做出了一个很专业的实验室管理系统，当然，只是做了其中的一部分，包材测试环节。然后老板就问我，你采购的新项目准备配多少人？做多少产出？我就可以直接回复老板，我们两个人就可以很完整快速的去做一个项目。

五、如何进行敏捷开发

1.项目管理调整

首先，低代码开发方式没有传统的开发过程，但其他环节仍然存在，我们将所有项目资源集中于最重要的需求方面。以前的需求规格说明书通常只是针对开发人员的，但实际上，为什么需求在后期会发生无法控制、不断变更的情况呢？因为需求规格说明书之前还有东西没有完成。

第一个来自于业务的诉求，这并不是需求，而是老板对业务的期望目标，这是非常重要的一点；第二个是将具体事项拆分开来，以确定先优先实现哪一块，这样我们就可以先去完成20%的目标了，大部分的业务只需要实现20%目标就差不多完成了，剩下的80%只是觉得用户用得少，我们需要对这20%的经验进行分析，但这需要对业务和整个组织之间的关系有深入的了解。因此，我们在想如何通过已有的诉求信息来制定需求，并做业务需求分析和需求规格说明书。在整个项目过程中，我会参加两个会：立项会和复盘会。我们会开两个人多小时的会去确认立项单的内容，核心逻辑就是去确定项目业务诉求和背景目标，这个是在项目里面很重要的事情，然后对业务的流程进行大致定义。并且，会将立项单发给对应的产业高层领导以确保大家对这件事情的重要性认知一致。

· 业务建模

实际上，业务人员常常会提供许多单据或者其它业务场景下需要的数据，因此，我们的数据建模也会偏向于这些业务数据为基础进行建模，这些建模图看起来像是一个ER图，但实际上这只是业务逻辑的体现。在建模的过程中，我们也会邀请业务人员一起参与，以业务为导向，避免涉及技术原则，相信大多数同学都能看得懂。

· 项目计划

项目计划包括需求可行性评估、立项、需求设计、开发、测试和上线，我们把所有的方法论全改了。第一是需求沟通，为了出立项单，第二个是模型确认，第三个步骤是POC制作，我们会先按照我们的理解快速做一版，然后你看一下效果，你说同步我去改，逐步进行优化，不同的业务理解需求的深度不同，因此我们的计划是基本上2个礼拜到一个月就能修改完成，最后是上线试运行和复盘阶段。我们会在一个月后对项目进行复盘，了解客户对我们的态度，我们一年做了将近30个项目，很少遇到客户投诉的。

· 功能/角色职责景图

最终我们需要出一个功能角色的职责图，系统是给人用的，所以要定义出来这个系统到底是给哪些人用的，每个人的角色是什么，每个角色要给他哪些功能。

2.技术架构的适配和调整

实际上，我们在底层就做了豫园股份的数据中台，所有的业务系统数据都要进去。所以我们在部署了明道云私有版本后做的第一件事情，就是打通豫园股份的敏捷中台跟数据中台，敏捷中台里所有的数据全部要推到数据中台去，由我们部门来定义数据规范。除此之外，业务人员不允许在敏捷平台上直接建模，必须要通过 IT 确认一下，以确保你的数据能融在整个体系里。比如说商品数据、门店数据、仓库数据，这些都是主数据，能融进体系是一个前提。

第二点，我们准备将一些核心信息系统之间进行打通，比如职能型公司中的OA系统，业务型公司中的ERP系统，他们之间也可以进行打通，后面开发的时候就会简单很多，因为他的数据、业务都是通的。

最后，我们建立了统一认证、统一入口、钉钉体系这套体系，改善用户访问体验，用户不用记多个账号密码，对于他们来说这就是一个整体的庞大的系统。在此基础上，我们使用了低代码技术和敏捷开发加上传统开发做了一套工作门户，将业务系统倒置进低代码平台中，以确保低代码技术与整个体系兼容。

3.团队架构和团队人员技能的配置

先说一下我们的组织结构，豫园股份是一个集团，下面有很多产业公司，每个公司都有自带的IT，产业公司会做业务和技术协同，包括用户的推进反馈，股份则会做整体的规划、实施，包括沉淀产业公司间相似的东西。

股份的人员配置基本都是产品经理，因为只有产品经理才能更好地驾驭这个平台，我们是有一个偏向UI的，一个偏向数据的，还有三个全栈产品经理。全栈产品经理比较核心，也比较难找，我们都是内部自己培养的。由于产品需求与开发不同人造成的沟通不畅，做出来的产品一直无法达到预期，现在需求和开发合并为一个人，这个问题就解决了，同时，大幅度的减少了协同的工作量。

4.精益数字化管理系统的支持

我们自己开发了一套项目管理系统，因为我们觉得市面上的项目管理软件不够符合我们的需求，特别是像禅道、Teambition这样的产品，对于我们来说太薄了，他还是偏向于做开发的。说实话在有这个敏捷开发之前，我其实很反感使用项目管理系统，做个项目还要填系统，整个项目的管理成本非常高，但是我们发现做了低代码后，项目瓶颈不在项目组，而在用户。

举个例子，之前我们为总部的法务部门制作了一套无形资产管理系统，以控制所有产业公司、产业品牌的无形资产。 这个项目开发用了一个月时间，但要花费半年多时间才上线，因为法务团队一直梳理管控流程，和产业领导确认管控方式是否合适，梳理无形资产的数据。这种情况下，我们的团队都会闲在那里，我们必须为他们安排一些其他任务，因此，每个同事通常同时处理2到5个项目。由于项目跨度很大，所以我们需要一套系统来沉淀所有文档和信息，此外，汇报项目也很重要，我需要告诉我的领导我们目前在做什么项目，为什么项目那么没有上线。所以我们就开发了一个项目管理的系统用于管理、沉淀这些项目数据。

六、实践成果分享

1.建设工作门户体系

我们做了一个门户，后面的逻辑全部用低代码做的，前端用了现在比较流行的一个框架。之前公司用的泛微OA，但我一直觉得它的界面不够美观，操作也有些不够简便，并且泛微没有办法做到将我们所有的系统整合到一个门户里，现在我们用明道云就很好的实现了。

2.集团职能管控领域

接着我们看一下低代码在协同职能层面做了哪些工作单？首先是管理所有产业的核心指标，这些指标在我们内部都是以战役的方式去管理的，所以我们搭建了一套战役管控系统用于报备和管控。同时，为了跟进产业中核心事项的办理情况，我们开发了一个督办管理系统。另外，我们还建立了一个BD生态系统。所谓BD生态系统，就是我们的不同产业之间联合营销的一些活动，例如购买一定金额的酒就可以获得手表等，像这种我们也建立了一个相关的系统去管控。

3.零售业态的业务

在零售业态里我们也做了一些系统，虽然不是很深入，但对业务也有很大帮助。比如我们之前做的库存管理，海外的CRM管理，我们一直想知道我们的就在海外各个国家的销售情况，但那些代理商都不是我们自己的公司，所以他们也不太愿意把数据给我们，所以我们就通过监控他的采购数据来推算，分析他们的销售情况，像这一类特别的需求，市场上是没有符合要求的系统的，我们就用低代码自己搭建；还有我们之前做了化妆品的主数据管理，餐饮门店的内部调拨管理等，通过低代码去一些做非专业的系统，对我们的业务非常有帮助。

4.各端口界面

在我们理解中，低代码更多用于做内部管理系统。但实际上，我们许多创新业务都是对外的，所以，我们与传统式开发合作，创建了一些对外的模式。例如，左侧的“豫园股份投诉”挂在我们的官网上，如果你到老庙去投诉，而老庙没有响应你的意见，你可以到股份来投诉，这个投诉会在这个系统里被处理，并根据匹配关键字推送给老庙，同时，在股份层面也会推进这件事情的处理，它是一个多维多层级的逻辑。

还有消费洞察小程序，背后也是低代码加部分 Python加前端开发，开发成本很低。当我们的化妆品上市时，要必须在真实人体上做过测试才可以，因此，我们创建了这个消费者洞察系统给化妆品体验馆去做相关测试的一些支持。

5.AIGC领域

我也负责豫园股份的AIGC，我们会通过文森图的逻辑去实现一些 AIGC 的场景，帮助设计师获得灵感。因为我们有很多实验室痛点明显，实验室的科学家做的所有东西对消费者一定是有帮助的，基于这个线路推进产业。然而我们发现实验室科学家与用户语言不通，如何将你所做工作表达出来让消费者产生知道呢？我们就通过 AIGC 来弥补这个问题，在低代码上开发并通过自训练和公域模式来尝试去做。这个如果用传统方式开发估计需要几个月时间，等做出来这个风头也过去了，而低代码只需两周。

现在整个低代码行业非常卷，尤其是明道云，我看见他的产品线路图，每季度有大量新功能上线，我相信这些功能上线后对于上层应用开发和业务方面都会有很大帮助。