聊聊中后台产研一体化:引子

欧雷 发表于

0 条评论

「降本增效」是人们在生产过程中永恒不变的话题、永远的追求——于公,长久看可以让企业减少开销并提供更为稳定、优质的产品;于私,能够使自己减少重复无营养的劳动,将精力投入到更为「高精尖」的地方,有助于自我成长,为自己为企业创造更大更多的价值。

提效的方式

现在想一下,在纯 Web 开发或大前端结合 Web 服务的领域中,提效的方式都有什么?

单点提效

从前端角度看,绝大部分前端团队都在不遗余力地去封装自己的工具库、UI 组件库、脚手架与构建工具,有些能力强点的团队还会封装应用开发框架、可视化源码搭建工具等。

从设计角度看,每个部门都会搞自己的设计规范/设计语言/设计体系,整理出一份设计侧的 UI 组件库,并制定一套 Design Token 用于与其他设计及前端沟通交流和设计与研发之间的联动。

从后端角度看,貌似没有什么可提效的空间——后端语言大多公司用的是 Java,相关生态体系已经很健全,顶多做些业务层面的封装。

从产品角度看,产品经理的工作就是接收/提出需求,做一些产品层面创收和改进相关的事情,这类思维活动为主的基本只能通过提升思维能力去提效了,如果有个业务向的知识图谱也许会好些。

链路提效

同工种或者说分工内提效的天花板清晰可见,很容易就会到达瓶颈。要想更进一步,自然而然也必须要跳出自己所处角色的视角,横向寻求上下游间的打通,共同提效。

以前端为中心与其他环节进行打通的话,大概是这么几种手段:与设计之间是设计稿与前端代码互转,即 D2C、C2D;与产品之间是需求文档转代码,即 P2C;与后端之间是采用 FaaS,即常规意义的「前后端一体化」。

产研一体化

上述几种链路提效方式的思考角度,一般都比较表层,仍是以自己或他人的职能为出发点,而不是从问题的本质开始探求解决方案——虽然每个分工角色的交付物不同,但它们都应是同一样事物的体现。

那么,那个「同一样事物」是什么呢?是模型与流程,或是业务概念、概念之间的关系以及相互间的作用,又或是业务知识。

所以,链路级的提效最关键的一点就是领域驱动的统一建模,其产物作为全链路的唯一可信来源(Single Source of Truth)。这意味着,从需求/产品、设计到开发、测试,都要基于同一份「数据」进行。

简要作业流程

产品整理各类需求,划分出各种业务概念,明确它们之间的关系和作用规则,这一过程就是在建模,最终会产出模型和流程。

建模结束后,产品可以在沉淀了 UI 组件、逻辑函数等物料的应用搭建平台上结合建模的产物制作「原型」,「原型」即最终页面。

若已有物料中没有想要的 UI 组件和逻辑函数等,可以用占位符之类的方式标注下,让设计和开发去补上。而 UI 组件和逻辑函数等的研发,既可以走线下又能够走线上。

协作模式变革

从上面的简要作业流程可以看出,从需求到研发最重要的角色基本只有产品和后端——产品负责领域建模和「原型」搭建,后端负责代码及数据连接,设计和前端被「踢」了出去,业务研发流程得到了精简。

从另一方面来看,也应该去尽可能减员——

软件开发过程就是从接到需求到产出符合需求的可用软件的过程。在这一整个链条中,源头是需求提出方,然后经过产品、设计、开发、测试等不同岗位的人处理。

虽说源头是需求方,但更实际的源头是需求方的意愿。这个「意愿」是不是「真(true)」的,首先要打个问号。然后信息在传递过程中肯定会有所损失,每个传递的节点能力越差损失得越多。

信息在每个人那里输入、输出时,因为知识、理解力、表达力等因素,多多少少都会发生变形,为了尽可能「保真」,必然的选择就是减少传递环节,也就是减少参与人数,尽最大可能让需求方的意愿直接变成符合需求的可用软件。

那设计和前端干嘛?要被裁了吗?!当然不是!虽然他们离业务比较远,业务研发流程基本不需要他们,但应用搭建体系的物料开发和维护需要他们啊!在这里,他们对团队的价值能够最大化。

总结

本文简单梳理了在纯 Web 开发或大前端结合 Web 服务的领域中一直以来大家为提效所做的各种尝试,并描绘了「产研一体化」在我脑中的轮廓。

目前主要是几个大厂以提效为目的在「产研一体化」方向进行探索,我在这个方向上也有了比较具体的有待尝试落地的想法,待日后慢慢道来。「反混沌」体系下的「Fxxk Design」和「Future.js」就是「产研一体化」这盘棋上的棋子。

「产研一体化」是中后台应用低代码化进程的一部分,也是前端工业化进程的一部分。