第一次独立负责设计的活动模块，也是平台产品的四大核心功能之一，在此进行一次项目的复盘。
本次复盘分成以下几部分：
一. 项目目的
二. 模块设计
三. 开发问题及原因
四. 总结经验
一、项目目的
我们从以下流程来进行阐述：
需求产生过程.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
网友评论