总结不在于回顾与记录，而在于在复盘中可以得到经验教训，得到更快速的成长。总结虽然很费脑力，但作为一项工作中最具收获的环节，怎么可以放弃呢，所以我拖到今天，还是把总结奉上了。
一、项目介绍
我们的产品是微信活动营销工具，商家可以在管理后台创建诸如大转盘、投票的互动活动。此次部门准备拓展商业促销类活动类型，也就是电商常见的砍价、秒杀活动，便于有卖货需求的商家做促销活动。我负责拼团的项目。拼团的玩法由来已久，但在拼多多的影响下，在微信又刮起了一股浪潮，借助微信的强大社交属性，开展拼团活动的确是做促销的不二选择。
项目成员包括4人，一个喜欢用PS开车的设计师，一个爱提需求的后端，一个顶着全部门最快称号的前端，一个鸡蛋里挑骨头的测试，以及一个对改需求乐此不疲的产品经理。拼团从今年6月份立项，花了3周半的时间才完成需求文档第一版，文档经过多次修改，7月底进入开发阶段，10月中正式上线。
二、需求分析
（一）前期调研
一开始只是确定了要做带支付的拼团，但拼团的玩法很多，需要先确定拼团的底层玩法是什么。因此我对比了相关竞品的拼团玩法，包括嵌入在商城的拼团，拼团app，还有提供拼团活动的工具型产品。在这一步，只是查看这些竞品的底层玩法，而在后期进行业务流程设计时我又再度查看。
（二）定位
经过对主流拼团玩法的调研，结合自身产品的情况，确定了拼团的底层玩法采用当前主流的“达到参团人数后全员都能以拼团价购买的形式”，主打的特色在于能快速创建一款可变现的拼团活动。并将该活动取名为“天天拼团”，那时是想着像腾讯的天天游戏系列那样，如果做出多个该类型的活动，那一致性的前缀，其实是有助于增强产品关联和用户认知的（虽然很土）。销售对外也能说“做电商促销就用我们的天天系列”，想想觉得还挺爽。
三、业务流程
（一）业务板块
确定好对拼团的定位后，我开始考虑一个带支付的拼团，都需要哪些底部板块，才能维持活动的自运转。可以分为营销设置，支付设置，商品管理，发货设置，退款退货，以及拼团最重要的分享逻辑。
营销设置，第一版只挑选最为核心的功能，后面的功能再迭代。
支付设置有两种，成团前付费有利于商家快速变现，但不利于推广，尤其是缺乏背书的中小商家，利用第三方的拼团工具，其实较难取得粉丝信任。因此我们推出另一种支付模式“成团后付费”，即满团后再进行支付，但由于不限制每个人都付费，所以可能会造成客户流失和收入损失。前者更适合变现，后者更适合推广。双管齐下，由商家来选择。虽然增加了开发难度，但我们认为是值得的。
底部模块
（二）用户流程
在确定底层板块后，梳理用户流程就很轻松了。从用户进入首页到完成支付，过程基本与一般电商的购物路径无异，但由于我们定位为快速创建，所以缩减了许多设置与路径。
用户流程图节选
四、页面交互设计
节选首页，订单页和商品详情。
交互稿节选
五、推广策略
在10月中旬已经上线，但并没有大力推广，等到宣传双十一新活动时再一起推广，因为拼团+双十一带来的效果是翻倍的。包括在官网和商家后台增加banner位，在活动类型新增类别“商业促销类”，提前两周发布拼团的宣传推文。
六、经验总结
根据以上的复盘，我发现有以下的不足和改进方案。
1．调研耗时太长
竞品分析当时做的比较乱，因为我不了解项目，也并不清楚需要调研哪些方面，所以花了很多时间去调研，效率不高，效果也不好。现在回头看调研的资料，发现可分为梳理拼团的玩法，不同玩法的优劣势，营销设置，用户流程等。现在回顾，其实面对一个陌生的领域，不应该马上进入细节，而要先思考框架，如果无法找到框架，也可以列出所有信息，用自下而上提炼的方法找到框架，然后再开始细节。这样做，一方面可以提高调研的效率，一方面也可以使调研资料更有条理，便于后期回看。
2．做产品定位主观因素强
做产品定位时虽然有思考，但主观因素较强，对实际的环境缺乏了解。现在看来，其实拼团产品更大的意义是在于丰富了我们的商业促销类活动，带动高级版本的销售。而对用户而言，由于我们产品的定位本身就是轻量级，所以也无法提供一个带有完整设置（物流、商品管理等）的拼团产品。因为这个限制是无法改变的，所以更应该思考，在这种限制下去做此项目，用户是否买单。
这给我的一个启发是，做产品定位需要做环境分析（比如SWOT分析法，适用于宏观环境分析），作为一个子产品，它相对母产品的战略定位是什么。战略定位其实就限制了很多东西了。以下是我后来利用swot做的分析。
swot分析
3．技术无法实现导致屡次修改方案
支付环节是调整次数最多的。由于是调用微信支付接口，微信的支付逻辑是到了开发阶段才发现某些地方走不通，而且不是一次性发现，是开发过程中才不断曝光，因此屡次调整文档。耗费了较多时间。但这个也是只有在开发过程中才能发现，无法完全避免。
4．商家场景多样化甚至互为矛盾，无法全部满足
举例子说明。当商家的剩余库存小于开团要求人数时，是否允许粉丝开团？如果不允许，会造成库存浪费。如果允许，则要求商家必须及时补充库存。后来我们采用后者，因为考虑到商家的诉求应该是尽量清空库存，所以我们的逻辑做成只要有库存，就能开团，但是当最后一个粉丝提交订单时，需要判断库存是否够全组人扣，如果不够，则提交订单失败，并提醒其通知商家添加库存。
后来有一个商家因为这个逻辑找过来，说我的库存的确就这么点了，你们还让人能开团，这不合理。
当时设计时的确没考虑到这种情况，我当时认为大多数商家应该都是供过于求的，并且是可以快速补货的。现在我已经想到了两全其美的办法，但仍不能掩盖我没有真实了解电商行业的事实。我在第一次考虑时，自认为那应该是大多数人的场景，然而那只是我的一厢情愿，没有现实依据。准确的判断来源于充分的依据，在于你对用户的了解程度。
这个给我的启发是，在遇到多样化的场景时，应该考虑主要场景并去满足，而次要的场景，应该衡量交互成本、开发成本后再看是否要满足，但如果是与主要场景矛盾，那就应该重新斟酌是否要兼容了。当然，对于场景的考量，必须建立在准确判断上，否则做出的都是错误决策。
原文作者：白夜不行
相关阅读
