淘系运营工作台前端体系
作者: 发布于:

背景

   电商发展20余年,给无数消费者带来了全新的购物体验并深深改变了整个商业环境,繁荣的表面下,整个市场已然已进入白热化竞争的阶段。随着互联网大范围普及所带来的用户增长及流量红利逐渐萎缩,各电商平台的规模越来越大,获客成本成倍增长,整个电商行业开始进入平稳、成熟期,现有市场空间很难再有爆发式的增长。当前各大平台消费侧、营销侧等模式及策略也逐渐趋同,竞争愈发激烈。

   由此如何更好提升组织效率,降低协同成本,提升运营效率优化业务流程,提升研发效能以更低成本快速响应市场变化快速试错大大降低边际成本,以更全局的视角创造商业创新土壤撬动供给侧升级,提升精细化运营等带来商业效率提升是未来的关键。

问题

反观内部运营体系,随着淘宝天猫电商体系在市场快速扩张,组织不同各业务及技术团队基于各自业务目标及模式思考不同,新业务为了快速迭代响应新场景,基于原有业务及系统又存在太多技术及业务历史包袱,构建了不少“新”系统,但各自系统割裂、重复建设,产品易用度低。历史系统更多是考虑满足各自业务能力产品化,将链路走通达成各自业务结果,缺乏站在运营实际业务场景及工作动线系统能力、产品的规划及收口。在去年整个淘系(淘宝+天猫)电商体系融合,问题尤为明显。

从运营小二操作上看,完成一个完整运营链路常常需要在割裂的不同系统间跳转,重复申请不同系统权限并且不同系统产品体验不一致,存在较高学习使用成本并且操作效率低下,如为了完成“栏目运营”的“资源投放”就需要通过反复操作“选品”、“点将台”、“审核”及“投放”等4个不同系统。其次在目前阶段,很多最佳实践的运营模式经验大多口口相传,人员依赖强,没有有效的沉淀及传承,业务间难以借鉴/复用,运营新人上手成本高并且运营操作链路的决策及效果缺乏数据沉淀及支撑,难以通过数据化手段更有效的指导运营链路的优化。

从技术侧看,首先同类功能的重复需要投入额外的开发及维护成本。其次无论是前后端,技术实现各异,技术能力没有有效沉淀,需求快速响应及迭代/维护成本高(比如仅针对前端而言之前就存在4套不同的前端技术及工程体系)。最后,系统异构难以集成及复用,协同及开发成本高并存在不少技术和数据孤岛。

从整体上看,组织割裂了人、货、场商业要素及能力,各个域关注点及重心不同,可以根据自身场景能力建设及优化,但均是局部的,缺乏从局部到全局商业要素的统筹及优化。并且需要基于全域能力的视角重塑运营链路以沉淀标准化运营操作流程及带来运营模式的创新。

策略

综上我们核心要解的有如下几个方面的问题:1. 运营操作效率及操作体验,运营模式沉淀 2. 烟囱式系统及技术孤岛,系统能力标准化沉淀及可被集成 3. 运营操作度量及对应业务结果数据化支撑,通过数据化方式指导运营链路优化和模式创新。由此,目标定位基于人、货、场、商全局构建技术及体验一致,标准化、数据化、高效易用运营操作系统的运营工作台应运而生。

我们通过将电商域能力矩阵结构化梳理,将原有各个垂直系统能力去重,整合并抽象沉淀为运营工作台运营视角的最小操作单元PU(Process Unit),它由可以完成运营人员一个基本运营操作/运营内容管理的一个或一组包含数据接口的页面组成。其次运营工作台基于传统行业SOP(Standard Operation Procedure)标准化操作流程概念,将运营操作链路标准化并沉淀从而形成在特定场景下的SOP指导和规范小二的日常工作,提升运营效率;将沉淀的PU能力通过编排方式组合为不同业务场景的SOP,即运营人员在特定的运营场景下完成一件运营任务时,进行的标准的操作流程,相当于运营动线或运营路径。针对不同业务域特点,基于PU核心能力、沉淀的各个运营场景SOP及知识图谱形成各个领域的运营站点解决方案。最终通过统一的运营工作台平台承载不同的站点解决方案,以SOP的方式及一致的体验带来运营效率的提升。同时,平台侧提供了底层基础研发平台以支撑PU能力构建、SOP编排、站点配置及相应的权限管理能力,数据统计及分析能力,以此让业务场景更好的接入运营工作台。

由此,针对上述提到的几个方面,运营工作台通过体验一致,统一入口的平台及SOP体系解决运营操作效率/体验及运营模式沉淀的问题;通过基础研发平台及PU标准解决技术孤岛及系统集成的问题来保障整体架构一致性。

前端体系

体验一致性

历史以来中后台侧由于更偏重于功能属性,面向内部运营人员使用,整体对于设计美观及体验都要求不高,大多都缺乏设计师同学的支持,产品实现各异体检较差。从用户体验一致性原则来看,包含

结构一致性、视觉一致、交互一致、内容/文案一致、提示/反馈一致等部分,由此最大程度降低用户学习使用成本,带来更高的操作效率,给予用户更多确定性,最终带来统一的心智并塑造更好的品牌感;同时在很大程度上也降低了前端研发及与设计的沟通协同成本。

回到运营工作台一致性体验的命题,为了将大量不同的平台/产品能力集成到统一到运营工作台,我们设计同学从平台框架、设计/组件、内容三个维度定义了工作台的设计规范。平台框架层面,定义了工作台整体结构全局整体导航,SOP导航,工具栏,菜单及各业务内容区,由工作台平台侧前端基于规范提供统一的运行外框架,也就是一个微前端主/基座应用以保障不同业务运行在统一外框之下。对于业务侧前端研发,提供了工作台基础主题样式及通过对业务场景梳理、抽象的标准场景物料,以保障不同业务以工作台设计规范进行开发。最后在内容部分定义了相关异常/提示规范,平台侧根据常见异常展示标准错误页及提示,以保障异常情况下给予用户明确及标准的行动建议、操作方式。

由此将之前体验缺失及各异实现的产品体验标准化并集成至运营工作台统一框架中,以统一的入口和心智带来一致性的体验。

SOP体系

针对工作台基于一致性体验,集成淘系全域运营能力,基于SOP体系,需要对PU(一个或一组页面)扩展组合自由编排的诉求。以及对于工作台体验,框架应用于业务应用低耦合、业务应用自制、业务子应用统一管理,配置等诉求,我们采用微前端架构,构建了运营工作台的SOP体系。

页面研发完成后可注册至PU中心沉淀为可被编排的PU能力,PU中心主要管理了PU基本信息(名称、分类、描述等)关联的页面:即,该PU有哪些页面构成,以及,页面的主入口的声明;PU参数:因为PU可能会被复用到不同的场景中,需要将一些业务场景化的变量抽象为参数,在实际使用的时候,再传入具体的值及权限点:即,定义PU具备哪些可以控制权限的点位,在实际配置SOP的时候,可以选择是否需要开启权限。为了避免PU更新直接造成线上影响,PU自身也具体版本化。针对业务层自定义站点首页,需要仅仅定制及更换页面中部分模块的场景,当前我们也在尝试模块编排/配置能力,期望沉淀及抽象更多业务模块,以更便捷的方式更新线上页面。

有了PU后,在站点侧各个业务场景根据需求可视化编排SOP,并配置相应的菜单及权限信息后变可将站点发布上线。SOP编排会保存一份对应PU页面前端静态资源地址及页面路径的关系,在用户访问时,工作台前端运行容器会根据对应的配置加载具体的微应用。整个工作台容器是基于Icestark的,贴合工作台场景增加了SOP,PUC模块获取及解析,插件体系及通用基础能力等扩展来支撑各工作台站点及SOP、PU的渲染和运行。

产研平台/微应用研发

要支撑起场景化工作台和SOP体系,就必须有完整的体系作为研发支撑,保障PU的质量、体验,保障用户的体验一致性,技术层面上,也需要尽可能统一前后端技术架构,提高系统可维护性、兼容性。“产研”,即“产”和“研”,分为两段,一段是产品的管理,一段是研发的管理。

产研整体流程从需求的建立开始,到业务研发与PU生产到需求完结,整体是本身也是一条SOP,其中会有三个角色的参与:

  • 业务PD:主要是需求的提出,对应传统的模式中,各个业务系统PD对各自系统的需求提出。
  • 平台PD/平台运营:主要是对业务PD希望在工作台创建/修改的PU做审核,确保PU在产品层面的合理性。
  • 业务研发:即对应传统模式中,各个系统的前后端研发,只是在工作台体系中,将以PU的形式进行研发和交付。

产品管理部分通过将淘系运营侧业务需求收口,平台PD和产品运营才有抓手,确保PU的抽象和拆解是合理的。

从生产关系上,业务PD和平台PD或者平台产品运营是有协作关系的,且定位不同,在传统生产模式中,业务PD直接对特定系统制定产品方案,并直接交付给该系统研发团队进行需求研发。而在工作台体系中,业务PD需要将产品方案拆解抽象成PU,以PU维度进行功能迭代。业务PD将会实现进行PU的预拆解,并将拆解结果提交给工作台平台方,平台方会将其预拆解的PU进行审核,审核主要的衡量点如下:

  • 唯一性:即,该PU功能是全局唯一的,如有可复用的能力,则会要求整合。
  • 合理性:即,增加或者迭代的功能点与该PU其余功能点是属于运营所操作的最小可操作单元。
  • 准入门槛:即,该产品功能是否适合接入到运营工作台,例如一些纯技术产品的后台,可能其暂时并不适合融入到工作台中。

在工作台页面研发体系中,我们并不限制业务在研发时如何组织页面和仓库,也不限制采用SPA还是MPA的研发方式。由于“多个页面组成一个PU”是业务上的行为,而“多个页面组织在一个仓库”是技术上的决策,两者并不一定是完全对应的。即:页面和PU是一个多对多的关系。

那么,在这种情况下,我们需要考虑如下几个问题:

  1. 页面在存在于多个PU的时候,需要考虑在后续迭代过程中的稳定性和回归成本。
  1. SPA应用在版本迭代的时候,如何控制其影响面。
  1. 如何避免页面版本的碎片化问题。

在产研体系中,设计了如下策略:

  • 页面的版本(静态资源版本)以页面路由为维度进行绑定,SPA和MPA均是如此。
  • PU关联页面的时候,PU的特定版本关联页面的具体版本。

SOP编排及站点配置/微应用编排

基于已有PU,业务侧同学可根据场景可视化编排出具体的运营SOP,主要有四中类型:

  • 弱流程SOP:  PU实例配置中,没有配置前置节点依赖/校验表达式的,可以配置子SOP作为嵌套。
  • 强流程SOP:PU实例配置中,进行了前置节点依赖的配置/设置校验表达式
  • 子SOP:子SOP可以配置产生强弱流程SOP,作为一个模板被嵌套到别的SOP中。
  • 动态SOP:在某个流程节点上,配置函数(根据不同条件过滤不同PU的呈现)

站点运行/微应用运行

运营工作台运行容器架构主要由核心能力,通用扩展能力、业务中间件组成。内核主要控制及调度上层各个能力,扩展能力主要为扩展底层能力如通用水印能力、统一数据埋点能力。中间级机制主要为了将容器能力与业务属性(SOP)解耦并做到可插拔,对于运营工作SOP、PU场景特点包含PU、SOP相关解析及处理能力,对于其他场景便于扩展及定制业务能力。最终页面展示内容通过渲染器中间件将外框架菜单、导航等内容渲染后渲染各自业务子应用。

最后

结果&进展

当前运营工作台按照标准沉淀了人、货、场、商近150+的PU能力,240+SOP及各个行业及业务场景20+站点,覆盖淘系包含商家、商品、营销导购等大量核心运营链路,以体验一致的SOP化方式支持了2000+运营小二的日常工作。

展望&规划

  1. 研发模式升级。运营工作台PU的定义解决了页面级业务能力组合、编排及复用的问题,SOP编排在部分场景很大程度上提升了研发交付效率。但对于中后台场景页面本身研发及整体交付效率的提升也是平台侧关注的重点,对于业务场景梳理沉淀场景物料内聚大部分逻辑暴露少量配置并沉淀场景模型,结合业务域标准化业务模型沉淀,通过更简单低成本的业务字段选择,UI配置来完成研发,解决前端研发,前后端沟通协同成本及前端,产品,设计间的沟通协同效率的问题,提升交付效率是我们目前正在探索的。
  1. 中台化/开放化。随着越来越多业务进入到运营工作台,业务对站点体系、SOP体系、PU产研要求也越来越多,越来越个性化,如何提升整个运营工作台的交付效率,让平台本身不要成为瓶颈越来越重要。从开放的角度来考虑运营工作台,开启了工作台的中台化建设,未来期望通过SaaS模式运营工作台在一些关键路径上提供给到业务定制化的能力,PaaS模式以Open API的形式将工作台核心能力开放给业务。