编辑导语：一场营销勾当从筹谋到落地，往往需要颠末许多的环节，需要必然的人力物力。本文作者通过复盘本身经验的一场营销勾当，为我们分享了勾当的进程，以及在进程中踩到了哪些坑，但愿可以或许辅佐到各人，在今后的营销勾当中，少走弯路。

PV20w，更高并发2w，勾当流水420万，粉丝互动超百万条，这是一场营销勾当留下的数据。在诸位看来或者已经司空见惯，可是对付我来说照旧大女人坐花轿头一遭，详细进程不再详述，个中踩到的一些坑与列位分享作前车之鉴。

一、项目启动时间赶

勾当直接由公司老板提出，给出的时间为1个月，涉及多个原有产物的成果改革，浩瀚的产物法则校验，新增的b/c端需求，之一步就导致了我这个产物狗的加班。

从其时的角度看来，实在是江郎才尽，能想到的方面文档中都写完了，功效进入开拓及上线后才不绝发明本身当初遗漏的问题，实属不应，最终由测试给我提了一堆产物上的问题，提出一些问题。

在筹划新成果的时候，应该在文档中细致的描写出每一个新增字段的来历、状态，及差异状态之间的切换法则（很是重要的步调，必然要仔细思考清楚）；

成果层面的交互，需要和开拓确认完整，每一个按钮，用户操纵的结果（因为较量忙，文档丢已往就没管了，功效开拓在交互领略上发生歧义挥霍了大量时间，纵然不足时间做完善的交互原型，也需要和和开拓相同好交互的细节）。

总结下来就是在写营销勾当的需求文档时，要做到大而全，涉及多个产物线多个系统之间的对接，细节粒度要思量到每一个字段、按钮和交互。

二、业务变革多

由于时间的紧要就导致了一个很搞笑的现象：我一边搞完善需求，开拓一边撸代码，业务还在一边更新业务法则，于是我的需求文档也随之2天一小改3天一大改，开拓最多的一句话就是“又改了？”，到达了真正意义上的摸着石头过河，很是朋克！

虽然这并不是什么好工作，也并不推荐各人仿照，除了业务法则上的重复横跳，在产物设计的层面，依然长短常“友好”的提出了人家的观点与意见，（一天改2版界面那种）。

所以这个坑够大了吧，也提出一些办理 *** 。

业务/市场部分在出具勾当的筹划文档时，作为技能方面的产物，需要逐字逐句的去读，调出问题来，对付暗昧不清的日期、数量，必然要有清晰的数值权衡，日期需要从天精确到秒，数量要精确到更大、最小值。

假如需要在业务法则不确定的环境下举办开拓，则让业务先确定好整体的法则，从大的法则，再到小的细节，一步一步的类型，确定下来，开拓也可以凭据由大框架至细节的 *** 来实行。

“用心听，但不要照做，深挖背后的需求”，这一点各人或者都听过，可是做起来很难，要求自身权限够硬+对产物足够认真，我自问今朝还没到达这一点，

三、上线后的问题袒露

忙了快2个月产物终于在筹备上线了，没想到接下来才是焦头烂额，勾当“很乐成”各类数据表白勾当热度都远超预期，可是这远超预期的勾当，我们并没有做好如此量级的筹备。

1. 上线后之一个严重的问题就是勾当商品超售

简朴的描写下之前的订单生意业务设计，用户端点击付出了后，系统就生成一个订单，占用一个商品名额。假如10分钟内用户没有举办付出，则该订单生意业务封锁，名额释放，不知道列位老爷看出来这里的问题没有。

由于庞大的并发量，导致了一个问题，数据库处理惩罚订单的时间高出了10分钟，即（用户付出了订单，可是用户的付出回调处理惩罚，在系统的列队时间高出了10分钟）用户给钱了。

可是我们充公到给钱的动静（动静列队中），于是又将商品卖了出去，如此来去导致了严重的超售行为，本应该卖2000套的商品 卖出了5000套（商品根基上是赔本卖名声的）。

如此的算是重大出产变乱了吧，陈诉给老板后，老板暗示问题不大顶的住，于是厥后公关部分微博发文“由于各人购置意愿强烈，业务部分多次加售”，如此处理惩罚也是妙哉。

2. 第二个问题是由于新来了大量用户，导致了账号体系的问题显现

在我们原有的账号体系中 一条用户数据对应的是一个手机号/邮箱+实名用户身份信息  当用户用了新手机号后，系统就会注册为新用户。

而且该用户无法举办实名，因为身份信息已经绑定在旧的账号上，可是旧的账号手机号又没用了，如此即是一个死结，以及之前邮箱注册的用户，用了手机号后被判定为新用户等等一系列问题。

焦点点就是 本来的账号体系设计就有一堆问题，可是在面临老用户时问题不大，在接管大量新用户检验时，原有的设计缺陷纤毫毕露。