www.icesr.com
IT运维工程师的摇篮

某购物网站–大促活动 流程梳理 与 思考总结

在行业组陆陆续续做了几次大促,在各位老司机的熏陶下,在上个月5月10日夏上新活动中,第一次承担起项目pm的角色,在整个流程后得到较好的结果,业务方各位也超出期望满足目标。做活动是一个满坑满谷的流程,面向活动新人梳理一下一些提示点与一些把握原则。

需求控制

需求目标

需求目标

一般来讲,对于活动业务方会有两拨人,一拨是市场部,一拨是行业运营。可以通过他们的需求看出:对于市场部的同学,对活动的要求更多是需要营造活动的氛围,去外界发声;对于行业运营的同学,更多的是会场商品、店铺的利益点是否透出到位,是否有利于成交的达成。

了解你的业务方的目标,对在需求评定是否需要做的时候,会是一个很重要的标准。

接口人

接口人

每次参加一个活动的角色和人员众多,很多时候会遇到一个情况是,有人来找到你说一个需求或者做一件事,没太多问题就直接做了。但是这里会发生一个情况是,如果这样的情况多起来,一方面其他的需求是否能受到影响,还有一个问题是这个事情到底是否应该做。所以每个角色都最好直接找到各方的接口人,统一出口和入口,一方面让你的节奏有条不紊,尽量减少多线作战的情况;另一方面,也让接口人、pm 对当前的进度和出现的问题有较好的把握,方便在需求判断的时候更好把握是否要做,是否来得及做。

需求先行

需求先行

一般来讲,在前端需求评审时,最合适的情况是需求与需求稿都确定下来,大家一起进行评定视觉的完成效果和沟通视觉展现是否合适,进行相关调整。

但是对于活动来讲,会有一个情况是 需求先行

对于这一点的理解是需求提出的速度在活动中一直都是不断快速叠加、迭代的,所以需求和视觉稿无法达到同步输出。因为每个活动牵涉到策划、需求确定、招商、透标、搭建、市场推广等流程,一直是一个组合连环拳的状态,所以作为开发人员也需要转变成一个主动的状态,快速适应这个节奏,利于融入活动流程,从而把控活动流程。

除了理解外,对于变化的需求,这里有一些小贴士:

http://gw.alicdn.com/tfs/TB1J0.zKFXXXXa4XXXXXXXXXXXX-732-461.png

  • 因为前端是交付最终模块的人,很大的可能性是大部分的风险在需求确定后留给了前端同学。避免这种后果,可以采取的操作方式有几个有效的措施

    • 参与和视觉 需求demo->视觉沟通 的环节,也就是在业务方将需求 demo
      图传达给视觉同学展现的时候,去把握模块需求,沟通好即能满足视觉设计目标,又能方便前端复用实现的方案,将风险前置提早屏蔽掉视觉多次调整的风险
    • 参与个性化方案、接口开发的逻辑设定、接口设定,已经与 tce 数据源的绑定的方案设定,为了在数据接口对接展现时的联调交互成本降到最低

  • 对于行业运营同学的需求,大部分是处理 商品店铺海景房 这种固定的模式,更多的是关注商品的 展现 和 成交。这些模块在日常的活动积累中,已有大量可复用的模块,例如之前的整理的 列表 ,以及后续对列表的 扩展 。

    从去年双十一之后直到最近结束的 6.6大促 以及现在造物节的活动,都是复用同样的模块。所以现在的活动开发,基本上行业的需求这部分基本上只需要确定是否有特殊处理,例如每次不一样的时间切换等,直接 复制 模块出来修改调整下处理就好;行业需求完全新做的模块以春、夏上新这样的S级活动为例不超过5个。
  • 对于市场部同学的需求,因为他们的目标是渲染出活动氛围,向用户、市场发声。所以他们的模块都需更多的视觉和交互的支持,但是在会场众多的情况下,如果针对每一个会场都去做特殊的模块肯定无法满足上线时间。所以,需要做的是,不断了解他们的需求目标,同时帮他们梳理他们想要的目标,以需求方的角度来评判,以自身用户的角度来评判。既能满足氛围营造的需求,同时也能保证模块的质量和上线的节奏。

  • 这里有一个实际案例
    • 视觉稿地址
    • 这个模块是作为各个主题会场的入口,最初的想法是需要将每个透出来的商品接入个性化,与主题会场内部做上关联,但是实际的个性化样本的数量不多,出来的商品效果不会很好,所以快速判断后取消这个功能
    • 然后市场部同学需求修改成想让商品在图片上任意数量、任意位置出现,这样的做法本身技术难度不大,看似可以开工。但实际上忽略一个很重要的点,就是 运营搭建成本 很大
      ,这样做无疑每张图片都需要填写坐标值与区域尺寸,再加上关联调优、联系设计师等事务,这样的风险一下变得大起来。
    • 同步到业务方后,最后考虑到主要作为入口,并且视觉调整可以有充分的视觉资源支持,为了保证个性化风格的功能的正常透出和上线,所以将填坐标透出取消,调整为7张大图透出。随之包含的风险点也屏蔽掉了。

需求原则

对于活动来讲,其实主要需要平衡的原则两点

  • 是否满足本次需求本身的目的

这里的例子是,夏上新时有一个边看边买会场,想要达到的目的是通过视频多媒体的展现方式。但是在这个会场里面出现了很多其他的模块,这个在demo评定的时候,询问业务方同学,得到的结果是想找个地方加上,但是具体的业务逻辑其实并不包含,并且现在所有的接口以及其他准备也没有,需求会造成其他重要需求的风险,那大家评估下来,业务方自己觉得需求不该做,就屏蔽掉这个不应该有的需求。

  • 是否能保证平稳上线

这里有个递进的例子是,在最近的春上新活动中,在整个活动确定完需求之后,在需求进行开发的过程中突然加入两个 ifashion 模块的需求,当时面临的情况是需求确定下来,具体怎么做,视觉稿的准备都还没有,对于这种临时需求,如果强加进来是会冒很大风险。但是通过整体评估方案有可行性,到最后都通过加班、提高效率等方式完成这个需求。当时接下来这个需求,其中原因有这几点:

  • 最大的原因是因为夏上新活动在品牌导向上正在逐步转型为 ifashion 品牌活动,那么在转型期需要在会场透出这样的信息来牵引活动的主题和导向,所以这个事该做,从业务方,到视觉和前端开发来讲都表示支持完成
  • 大家都同步运营同学快速联合招商同学、ifashion 开发同学、视觉同学、前端同学进行资料准备和方案打通,保证了最后快速完成这个临时增加的需求。大家都已活动 owner 的态度来面对这个需求,快速响应,完成了新增模块的风险控制和质量保证。

需求要素标准

在大促这样一个较短的时间内,需要对每一个需求有一定的基本要素的把握,特别在一些特殊需求,多方合作需求出现的时候,可以用来进行需求校验,判断需求存在哪些方面的风险。

  • 视觉稿完成度。在视觉评审的时候至少能通过评审版本(一般不会是最终版本)的视觉稿看出需求是否满足,视觉同学想透出的目标是什么以及模块视觉是否需要加强模块复用度;以及模块出现的布局,是否有利于模块展现,和交互方案的设计是否合理,例如吸顶、背景占位等。因为在活动中的视觉稿基本上会有很多片段碎片 例子1例子2 ,所以还需要的考虑是交互和排版会不会出现自相矛盾的情况,或者实际拼接成页面的效果是否满足活动目的。
  • 数据源确定。这一点如果是例如商品、店铺、海景房之类的模块,主要是跟运营接口人确定是否招齐需要透出的字段;如果是一个三方需求,如需要调用个性化接口等,则需要确定接口是否已存在,接口的开发时间计划和方案是否已存在等
  • 埋点需求确定。这一点也是往往容易忽略和出问题的点,了解到四月到五月这个区间,行业市场这边连续3次活动的埋点数据出现问题,在夏上新开始时着重
    check 这方面的内容。这一点对于行业的需求来讲,便捷的办法是可以在上线之前联系 BI 的同学测试校验埋点数据是否正确,在他们的日志系统里面是否能正确的收集;对于一些单独需求,例如个性化埋点需求,最好在开发之前就提出埋点需求是怎样的,在开发时就能关注到,因为在不同 BU 的环境下,往往对需求的理解会有不一致性,多多确定达到真正的信息对称,是降低风险的最简单办法。

合作性需求

从去年下半年逐步开始,个性化,这个词汇在愈来愈多的需求上出现。对与大促活动来讲,对接个性化仿佛成为了标配。类似这样一个多部门合作的需求,把握几个关键点是保质保量在段时间内保质保量完成的保证。

  • 时间点 deadline 明确,对于跨部门的合作,因为是一个多端汇合的情况,那么像木桶原理一样,哪一个方面出问题都不行。所以确定好时间点并加强这个重要性,是保证需求难产的第一步
  • 需求明确,对于这种跨部门的需求,很容易在多人传达的情况下,造成需求细节的忽略,而往往这种细节是需求完成的关键点,在一个多人参与的项目中,项目成员对目标不断清晰是对风险的屏蔽、和避免需求的返工的保证
  • 接口人进度不断更进,这个作为前端来讲,其实是需要 push 业务接口人,去花一定精力在这方面,保证整体进度的正常推进,并在一些技术点对接的时候,主动去找到开发,破除掉障碍,快速完成需求
  • 边界需求点 check , 例如容易忽视的 埋点、数据容灾,对于上线前的校验和整体质量保证很重要

    其实对于多人需求,就是分配一定的精力去正确对待,不断明确和推进,这样才能保证尽快完成,把风险降到最小。

模块开发

实际上在一个活动中,模块开发的技术难度除了一些特殊的玩法场景,一般的主要模块都还是展现性质,所以难度并不会很大,所以对于会场模块开发来讲,更着重的是对于模块的复用与沉淀以及模块值开发效率和质量。

模块复用

在需求制定和开发时,比较 2015双十一通用模块2015双十二模块春上新模块夏上新通用模块,基本上有很多类似的地方,对于这种相似模块,一般直接就采取复用或者基于之前的模块开发,行业组这边也逐渐整理重构出这样的一批模块 模块列表

在开发新模块时,如果判断开发的模块有通用性的部分,那么可以抽离一个通用的版本,录入 到列表中,为了下一次的开发时能快速响应。例如现在很多活动都采取这样方式,逐步形成一个优质模块的生态,这里模糊搜索出来的一些结果:

结果

视觉规范

对于模块的展现,在活动的不同会场里会有不同的情况。在颜色主题和样式展现都会有一些不同,例如 2015双12分分会场导航2016夏上新 这样的视觉稿。

需要注意的点是,因为活动整个项目跑起来之后,视觉同学也会处理大量的事情,所以前端同学在制定了模块的样式方案时,如果涉及到会场比较多,或者是展现形式比较多,是有必要联系设计师整理出一个统一规范,对与颜色来讲,这样有一个需求的根据,既能方便开发,也能方便业务效果的校对,同时也在整理过程中梳理清除展现的逻辑,在哪一种情况下展现哪一种形式。这样能达到业务方、视觉、需求方的三方沟通解耦。

校验标准

对于搭建系统的模块开发出来之后,一般在本地校验基本的展现和交互就可以提交上线。但实际上有一个很大的问题是一个模块在线下完成只是完成了90%,但是剩下的10%也至关重要,基本上每个模块都需要要真实的站点环境中搭建测试校验完成后才算完成模块工作,主要有这些校验点:

  • 对于有在一个页面有多个展现的模块,例如商品、店铺模块,这个模块最好是都放在一个页面中测试,测试不同展现的数据是否满足期望。同时也能测试出是否模块会因为例如选择器的一些错误,导致方法失败的情况。
  • 对于有交互动作的模块,例如导航、电梯的模块,同时也需要在实际页面中搭建满足交互的场景,来测试是否交互效果有正确展现,一起是否对其他模块有影响。例如高亮是否位置正确,跟随是否引起页面抖动,模块触发展现时是否对其他模块有遮挡等问题。
  • 对于有数据绑定的模块,一定要绑真实的数据源数据,例如模仿运营同学在 淘营销 系统 中找到一个进行的活动 id 进行绑定,看数据字段是否透出,是否按照设想的位置展现
  • 对于调用组件的模块,主要校验的标准是页面组件统一,也就是例如 xctrl 、 lazyload 、coundown 这些组件保持所有组件统一。一方面因为页面上的模块很多,这样能尽量减少脚本资源的大小,在一些极端情况下,会将类似的组件调用统一成一个组件,例如页面上纯在 xscroll 和 lib-scroll 的调用,之前全部切换到 xscroll ,这样就直接干掉一个组件的大小;另一方面,xctrl 依赖的的 mtop 依赖,在页面上存在不通版本时,请求其实无法发送出去,版本统一其实也是保证组件调用不发生冲突和保证引起
    bug 的环境统一,降低风险,便利定位bug。

交付搭建

环境准备

主要是准备运营搭建模块所需要的页面环境,主要有几个部分

  • 母版,母版的作用主要是为了提供不同时期、不同性质会场所需的环境而提供的公用页面环境,例如以下场景

    • 根据活动时期:预售、预热、正式
    • 根据活动会场性质: 主题会场、行业会场、淘客会场

    不同场景下对应具体需求可能不同,例如跳转时间、开关控制等,这个时候基本上就是通过母版来统一完成和管理

  • 跳转逻辑,这一点其实与母版相关,在搭建时,根据活动需求尽早在母版中,设置好跳转逻辑,并且进行实际域名跳转测试校验
  • 主题色卡模块,目前来讲,因为在活动中各个会场会有不同的颜色主题展现,而为了避免运营填写错误,一般通过枚举类型来选择,快捷准确完成颜色主题设置
  • 页面模板,因为对于页面搭建来说,如果每个会场页面都需要一个模块一个模块搭建的话,那对于大量相同的会场必定会有时间的浪费,这里的解决方案是将会场数量较多,会场性质相同例如行业分会场、主题会场这种会场在开始搭建之前前端同学完成一个模板,运营基于模板来创建会场页面,在这样页面排版位置已经完成情况下,剩下的就是直接绑定数据,和较小范围内复制相同模块。
  • 标题生成器 ,方便运营同学快速标题模块所需填写的 图片素材,针对各个类目的视觉规范配置对应的生成配置

搭建培训

一般来讲,一次 S 级活动所涉及的运营一般会有10名左右,如果是双十一、双十二的,可能数量会翻几倍。在其中一般会存在已经很熟练招商、搭页面等活动事宜的运营,另一方面,也会存在基本上第一次搭页面的运营。为了让在一个段时间内大家都接受这次活动的搭建所要了解到的东西,通常通过培训的方式来进行快速传递信息。为了在一定的时间内提高效率和达到良好的效果,有几个点需要准备和注意:

  • 前置条件:

    • 权限申请
    • 页面标题规则

      保证哥会场之间的关系清晰和明确,需要同步 PD 或 PM 同学在搭建开始前就定好命名规则,例如:

    预热|正式主会场: 新势力周夏·主会场

    分会场: 新势力周夏∙女鞋男鞋

    分分会场:新势力周夏∙女鞋男鞋∙魅力高跟

    淘客分会场:新势力周夏-女鞋男鞋

    • 页面url

      为了保证页面投放的准确,实践下来最好的颁发就是和同步会场的 PD 或者 PM 同学在搭建开始时就定好每个页面的 url ,并同步到各个入口的位置。
    • 创建淘客页面

      淘客页面 tms 有固定功能,但是在日常工作中一般接触较少,这里需要解释下操作步骤,例如 work地址
    • 模块列表(包含模块说明)
    • 特殊模块说明
    • 页面模块结构

      例如 例1例2 ,对于很多运营,如果只是单独的输出一个模块列表,其实很难对应联想到页面每个位置上该放哪个英文名称代表的模块,虽然在搭建页面开始时会建立页面模板来方便运营复制,但是在多次绑定和更新保存之后,页面难免发成变化和错乱的情况,给予一个既定标准,这样解耦前端模块开发和运营的模块使用的依赖关系,提高搭建效率。

    搭建页面前置条件的准备思路其实是以一个运营的视角来去对待页面搭建过程需要经历的流程。对每个流程都把参与的同学当做第一次的新手,那么所要准备的材料也会复现出来

  • 运营搭建工具

    • 标题生成器地址
    • 视频上传地址
    • 热区工具地址

    这部分内容实际上是对于活动中所用到搭建辅助工具进行一个集合展现,方便运营快速找到工具进行相关素材的制作和生成

搭建培训的目的其实就是赋能运营的过程,在培训之前准备得越充分,培训时梳理传达的越具体,实际上运营得到的收获越大,后期的搭建效率就越高,上线的风险就越早暴露。

运营用户

这里提的 运营用户 的意思是,实际上我们的模块的最先面对的用户是运营同学,那么在搭建过程中,为了使搭建的速度更快、效率更高,作为开发同学,最直接的办法就是通过采取一些技术方案,来简化运营的搭建工作。这里会有一些参考方案:

  • 色卡设置

    一般颜色设置,最简便的方法是通过在模块上挖坑填写色值,但是面临会场如此多的模块,如果每个都让运营同学去填写,会成为一个庞大的工作量,并且出错的情况会大大提高,那么为了提高这个工作产出比,实际上可以在会场上加入一个公共模块,统一完成颜色主题的设置,运营通过选择会场名称即完成色卡设置
  • 电梯设置

    很多电梯模块都是通过让运营填模块的 id 值来完成电梯的锚点定位,但实际上可以约定好标题模块的规范,留下一个 js 的钩子,对标题内容进行抽取,自动生成电梯,那么这部分运营的工作量又去掉了。
  • 提示文案

    对会场中很多繁杂种类的模块,很多时候在数据绑定不完备的情况下,可能就是一片空白,然而对于模块的英文名称,其实不利于运营去理解是什么模块,这个时候可以在模块中判断运行环境输出明显的提示,方便辨析不同的模块
  • 数据模块

    为了提供统一处理,在前面提到的方案是采用母版来完成,但是在粒度更小的情况下,例如某一个类目、某一种特性的会场,需要填写一个数据一致的模块如分分会场导航,这个时候可以才去建立公用数据模块的方式,这样运营可以填写一次同步到所有相同展现的 pc 和 h5 页面,避免重复工作量的发生和提升数据的可维护性。

这些方案主要也是从运营搭建的角度考虑,减少运营的搭建成本,一方面也是提高活动搭建的速度。

上线校验

"行百里路半九十",到页面上线前后需要进行一些检验,保证活动的平稳完成。这里有两个容易出问题的的校验规则

数据绑定(上线前、上线后)

一般针对会场承载会场最多的商品、店铺展示区域,着重校验的问题是:

  1. 是否出现 "空坑",也就是数据缺失,楼层少一个活多个坑位
  2. 页面数据去重问题,页面上同一个商品或店铺出现了不止一次
  3. 数据排序出错,例如按照一些赛马规则,大卖家会首先出现在更靠前更好的位置,有利于成交量的达成,但是出现问题的时候,可能出现在好位置的商家是一些小卖家。

虽然这些概念可能运营和开发更熟悉和关注,在作为参与活动的前端同学,作为页面控制的最后一道关卡,对这些问题有一定的感知,一方面知道具体的问题是属于哪一种情况,方便联系对应的同学解决;另一方面对问题了解的更清晰,也能直接与开发同学同步搭建环节中、模块数据绑定字段设计中可能出现的问题,达到快速解决或者通过前端手段发现屏蔽问题的目的。

时间点切换 (上线前、上线后)

目前大部分活动都会有一个 预热 、 线上 阶段,在一些情况下可能还会有 预售 阶段,那么对于阶段切换需要
check 的问题有哪些:

  • 上线前: 主要通过 tms_date 或者 schedule_date 来模拟时间情况
    • 展示的文案是否切换正切,例如 立即查看 切换为 立即购买,分分会场导航是否隐藏已过时期的会场入口等
    • 域名跳转是否正确,上线前外网屏蔽和下线时的谢幕页跳转
  • 上线后:主要是临界点校验是否在上线前校验的内容是否正确切换。对于未切换的状态立马采取紧急措施。

对于时间点切换,一定尽量模拟真实的环境,不能在某一个条件下看到切换就认为可以切换,还要保证在正确的条件下正确的切换。

在一般最大型的活动(例如双十一、双十二)因为页面上会放置很多开关,可能还需要对开关进行上线前的校验。以及在活动开始之前,整个团队还会组织实际语言,整个项目组来校验会场实现是否有问题。对于一般 S 级活动,把握好一些关键点也是活动平稳上线的重要保证。

应急情况

对于每次活动的应急情况不出现是可遇而不可求的,那么遇到应急的情况,个人现有的经验是

  1. 首先是模块是否能通过删除解决,大部分情况是可以的,那么最坏的保底方案有的话,先有底不慌张;如果无法删除模块,或者无法定位模块,在重要会场,也可以看是否能切换入口来暂时屏蔽。
  2. 先看是否有前端报错,那如果有报错,一般是某个数据活时机触发了 js 中未处理好的地方,找到快速修复屏蔽掉
  3. 如果没有报错,则看数据请求是否正常,如果数据不正常引起,则快速同步运营是否能切换数据源来屏蔽保证模块展现正确,并同步开发定位问题。
  4. 如果数据正常,js 也正常,那么可能是需求没同步正确,作为前端,看是否能修改特定参数来首先保证展现正确,快速发布后,后续重新校准需求。

每一次都会有或多或少的情况,遇事不怕事,冷静缜密思考,和小伙伴一起想办法,才是最好的解决方式。

未经允许不得转载:冰点网络 » 某购物网站–大促活动 流程梳理 与 思考总结

分享到:更多 ()

评论 抢沙发

评论前必须登录!