活动模块--复盘（上）

第一次独立负责设计的活动模块，也是平台产品的四大核心功能之一，在此进行一次项目的复盘。

本次复盘分成以下几部分：
一. 项目目的
二. 模块设计
三. 开发问题及原因
四. 总结经验

一、项目目的
我们从以下流程来进行阐述：

需求产生过程.png

一般产品需求的产生都可以按照这个流程来进行分析。
1.业务场景
首先简单介绍大部门的业务：面向政府部门，统一输出集团的优势资源以及自身的云计算资源。所以大部门下面会对此进行分工，比如负责推广的部门，负责招商的部门，等等。这些业务线通常都会有举办活动的需求：

业务场景.png

2.业务需求
从上述的业务场景中，提炼出一些共性的东西，进而归纳出业务需求：

业务需求.png

3.产品需求
将业务需求落地，可以拆分成对应的功能：

产品需求.png

4.优势
在平台产品没有做活动模块之前，业务部门一般采用【易企秀】或者【活动行】来发布活动。那么相对而言，采用自家产品的活动模块优势是什么呢？如下：

优势点.png

5.以后可以优化的点

待优化点.png

二、模块设计
模块设计部分主要是从产品设计的流程来进行简单说明。
1.需求分析
项目目的部分已经介绍了各业务方的需求及对应的产品需求。

需求分析.png

2.具体功能设计
具体的功能，本来是打算放一张脑图，但是脑图上内容过多，看起来体验不是很好，就挑几个注意的点讲一下。
（1）前端涉及的功能

前端功能.png

• 展示。按照举办时间倒序排列，同时可以展示最热及推荐。推荐部分可以由后台设置权重来展现。

• 详情。分享功能，用于活动的传播

• 报名。web端当网页向下滑动时，报名、分享按钮会悬浮在顶部，方便用户在浏览详情过程中进行报名。同时报名表单填写会在所填项失去鼠标焦点时进行校验，如果出错会进行提示。当手机号重复填写时会进行提示。

• 签到。移动端采用微信的插件完成。
  【签到】这部分的逻辑从开始做到最后完成，中间经历了一些变化，具体如下：

• 开始，产品设想用户的登录方式有两种：手机号+验证码；微信 第三方登录方式。所以最开始可能的报名方式及签到逻辑如下：

  
  活动报名+签到.png

• 后来，在接入微信登录时，出现问题，啊.....具体问题我好像不太记得了，不是我负责弄的这部分，只记得结果了。然后就把接入微信第三方登录的事情delay，所以最终的活动报名+签到的逻辑就变成下面这样，简单了许多：

  
  活动报名+签到-0904.png

（2）后端涉及的功能

活动管理-后端.png

• 新增活动。这部分主要是一些基本信息的填写，但是要注意不同的字段需要设定相应的边界值，或者说规则。比如封面图部分，建议尺寸多大、格式如何；活动名称部分，建议的字符范围。
• 活动列表。这里涉及到运营人员的审核权限，可能会涉及到多个节点的审批流程，但目前系统只做了一级节点的审核设置。
• 名单管理。活动分两种，需要对报名人员进行审核的，不需对报名人员进行审核的。名单管理一方面可以展示所有已经报名的人员，另一方面能够对报名人员进行审核操作。
• 活动分析。目前功能还做的比较简单，因为是1.0版本。但当后续该模块用的多，会增加新的分析项。

3.注意的情况
简单说一下几种需要注意情况的考虑
（1）活动在前端展示时有如下几种情况：

• 未举办，可报名
• 活动已报名
• 报名时间已结束
• 报名人数已满
• 活动已举办
• 活动已下架
  这几种情况都需要在前端对【报名表单】及【报名按钮】进行不同的设置
  （2）后端在设置报名表单的时候采用了自定义项，运营人员可以根据自己需要进行字段的设置
  （3）后端进行审核的活动，状态有如下几种：
• 草稿
• 待审核
• 已通过
• 已发布
• 已结束
• 已下架
• 已拒绝
  （4）异常情况

• 已发布的活动，取消发布时。
  对应的场景：活动发布内容有误、报名人数过多、主办方取消等
  对应的逻辑是什么：（这部分自己在设计的时候没有考虑到，是需要后面迭代优化的点）分两种情况来看：已举办、未举办
  首先取消活动发布，需要设置一个审核节点。（考虑到 不能随便什么权限都能取消发布的活动，那就乱套了~）

  
  取消-已发布活动.png