共计 3343 个字符，预计需要花费 9 分钟才能阅读完成。
明天由我代表作业帮来介绍公司在低代码平台利用的一些教训和心得。我明天分享的内容蕴含两局部，一个是作业帮硬件的介绍，另一个是基于明道云的零碎能力建设，也是咱们本人总结的教训，心愿能给大家带来一些启发。
一、对于作业帮
作业帮成立于 2014 年，在整个业务周期至今，其实曾经做了很多业务线。其中两个点是波及到硬件局部：第一个是 2018 年，作业帮收买了喵喵机。喵喵机是一个以热敏打印机产品为切入点，切入到错题打印，也就是学生这个场景下的硬件产品。第二个是 2021 年，作业帮本人做了一套硬件产品生态。在 2021 年双减政策出台之后，作业帮更多地歪斜到硬件产品上。目前，作业帮以作业帮硬件和喵喵机作为硬件的双品牌战略。
二、需要背景
咱们理论业务线是在 2021 年底才正式上线，面临两个比拟大的问题。右边是咱们的业务量，左边是咱们的业务场景。大家能看到业务量是一个爆发式增长的状态。随着业务增长，咱们须要做的零碎反对的内容也会越来越多。所以就面临了这两个外围的业务问题，一个是高速增长，一个是场景收缩。
三、基于明道云的业务零碎能力建设
1. 建设计划
基于这两个问题，咱们其实始终在思考到底如何疾速反对业务的倒退，以及如何满足简单的业务需要。在应用明道云低代码平台之前，咱们次要有两种产品状态，一种是自研，另一种是 SaaS 服务。
然而低代码引入之后，咱们面临了三个业务点。咱们基于这三个业务场景做了一些剖析：咱们认为低代码更实用于产品的复杂程度不是特地高，并且须要有一个十分大的灵便属性的这种产品方向。而后 SaaS 的话，因为是行业内的比拟规范的产品服务，通过了很多年的验证，咱们认为可能更多地去满足简单的业务场景。当初这个阶段，自研是一个十分高老本，然而能满足比拟个性化需要的开发方式。
2. 建设框架
咱们画了一个四象限，把业务复杂度以及行业服务规范这两个坐标作为评估根据。基于复杂度低、无行业标准的这种场景，以及复杂度低、有行业标准，这两个场景下，还有一部分复杂度高、无行业标准的场景，用低代码建设，保障低代码的产品个性能充分发挥起来，解决高效、低成本做零碎建设的能力。
剩下的是业务复杂度高，然而无行业标准的这部分，咱们抉择了自研。另一部分就是绝对比较复杂的，比如说 ERP、仓库管理系统，咱们可能更多地用 SaaS 服务。这是咱们大略的选品规范。
3. 合作形式
咱们总结了 3 种自研形式，一种是自研 + 网关 + 低代码，其实网关代表自研的一种连接形式，第二种是低代码 + 网关 + 低代码，第三种是低代码 + 网关 +SaaS。
第一种链路的话，咱们认为它能满足非凡场景，对产品交互要求比拟高。剩下两种，咱们认为依赖 SaaS 服务以及自研能力，能疾速反对业务定制化的场景。所以这三种链路其实在咱们的开发过程中是并行的。
4. 流程提炼
基于方才的三个场景，我提炼了一个流程给大家简略介绍一下。因为咱们是做硬件的，所以会波及到一个售后的过程，它和传统电商的售后过程不一样。传统电商可能依赖于客服能力就做了，但咱们有一些硬件产品，须要理论做售后服务。
在这套链路外面其实曾经拆解进去了：用户售后服务发动之后，咱们的客服人员以及售后人员进行服务受理，坏品会在售后仓进行治理，有可能会报废掉，有可能会进行这个工厂的翻新，也有可能会进行仓内的翻新。
这套流程外面有 3 个点，第一局部的话是用户端，这个是映射到之前体验的场景上；第二局部是服务端，就是咱们本人外部流程的一个转化；另外一个是仓储作业，也是外部的操作作业的一个工作。
以售后服务端发动这个动作来说，它的场景用了“自研 + 网关 + 低代码”这种能力。用户须要在手机端发动售后服务，而后由咱们的客服人员以及服务工程师去进行后续的服务受理。在这个场景下，用户侧对于体验的要求十分高，目前低代码平台其实无奈齐全达到咱们对于用户场景下的应用诉求，所以咱们是通过自研的形式，而后用自研的内容去和网关连接传递到电话平台上，通过传递的后果去获取到用户诉求。在服务过程中会通过服务公式的解决返回给用户，从而买通这套链路的执行流程。
在这种执行形式下，咱们能在保障用户体验的前提下，把零碎落地的时效进步 70%。失常搭一个售后零碎的话，没有两到三个月的工夫其实是很难实现的，而咱们大略用了 20 个工作日左右。所以，整个我的项目下来，咱们对于低代码是有肯定感触的，而且我的项目成绩在前面也间接帮忙咱们更好地在公司外部推广低代码平台。
下一部分是服务受理，这部分其实是用低代码 + 网关 + 低代码的这种形式解决了数据获取的问题。明道云提供了在流程以及页面中通过 API 形式获取数据的能力。咱们自身有一些自研的表控能力，以及作业帮外部的零碎，这些都须要通过 API 或者网关的模式连贯到明道云。
第三种形式是低代码 + 网关 +SaaS。对于咱们来说，其实 WMS 服务绝对简单，除了商品自身的治理以及出入库以外，还波及到调拨、盘点、库位以及失常销售场景下的链路买通。在这个场景下，咱们将 WMS 的 SaaS 服务与低代码连接，实现了这套链路的执行。
咱们在理论应用过程中发现，这三种形式能帮忙咱们更快地建设零碎，也保障咱们能绝对灵便地进行业务迭代。
接下来我会基于售后零碎，介绍一下咱们的产品构造。咱们目前业务场景是退、换、修，基于这三个业务场景，波及到销售平台的信息引入，OMS 订单零碎的一些信息引入。除了内部的 OMS 以及咱们自研的 OMS 以外，还有一些 CRM 的 SaaS，这些场景都会由明道云承接，来保障咱们外部的工作流的流转。
标绿的局部是咱们当初曾经在应用明道云做售后业务场景的反对模块，标黄的局部是咱们在尝试根据明道云能力去建设的服务能力。其余局部间接复用了作业帮自研的能力模块。
5. 产品建设思路
其实咱们是有肯定产品建设思路的。明道云自身是以利用表单和工作流为载体的开发工具，然而对于咱们一个绝对传统的互联网公司来说，咱们心愿通过让系统结构、零碎边界足够清晰的形式，来保障后续数据应用过程的稳固高效，防止反复迭代，反复地做重置动作。所以，咱们用零碎去对应利用场景、表单，业务流对应工作流。
举个简略的例子，还是以售后场景举例，因为咱们有客服人员在做服务受理，有售后的工程师在做后续的执行动作，所以对于客服零碎和售后零碎来说的话，其实是绝对解耦的一套零碎，然而工作流又是互相串联的。
在这种状况下，咱们通过工作流保障两边零碎的数据一致性。各个角色在本人的零碎下闭环，使得利用不会因为工作流外部的串联，导致各个岗位的工作内容解耦了。
6. 产品构造
咱们尽管是互联网公司，但也是一个制作型企业，蕴含产品设计、生产制作、服务履约和用户服务。在这个业务场景下，咱们蕴含前、中、后盾。前台可能更偏差于用户体验，会有很多的用户通过前台的端口来去获取硬件的一些服务内容；中台会有一些散发逻辑；后盾是外部员工用的一套零碎流程。
在整个流程过程中，咱们用明道云进行很大部分的中后盾零碎建设，还有一些咱们在验证中的计划，也是心愿未来通过明道云来实现。
7. 研发架构
明道云在咱们的研发体系中，更偏差于底层的一些服务能力。它会通过网关的模式，和前中后盾的零碎做连接。这种设计构造保障了咱们的业务动作都能进行高速迭代。
8. 建设倡议
最初，咱们心愿给大家一些倡议。咱们认为：绝对体验性的内容更适宜自研或者应用 SaaS 服务，中后盾的模块里，如果没有特地好的内部 SaaS 能满足的，以及绝对简单、变动较大的业务线，就很适宜应用低代码建设。当然，咱们对于低代码平台抱有很高的冀望，心愿后边能进行一直拓展它的利用边界。
四、从提供零碎工具到提供工作模式
明道云曾经能把用户的实质诉求，提炼成一套低代码能力。咱们十分认可“人人都是开发者”这种观点，然而前提是做到了“人人都是产品经理”。
至于赋能，我感觉不只是工具层面的赋能。低代码平台其实是一个革命者，它颠覆了传统的开发逻辑，咱们心愿从整个公司的经营环境上来思考低代码对公司的倒退或者迭代有什么样的助力。
我例举了四个点，当然必定不止这些：
- 在传统互联网公司环境下，咱们如何配置团队来应用低代码能力？
- 零碎建设的规范是什么样的？
- 如何实现一套低代码的履约过程，以及后续的运维计划？
- 在传统的运维根底上，咱们怎么进行转化？
本文来自作业帮高级产品经理翟宇，在明道云北京开放日的分享，经校对编辑后整顿为演讲精髓。
