【实习复盘】记录我在小红书的需求与成长

编辑导读：需求，在互联网行业工作的每个人都耳熟能详的词。不管是在哪个岗位，都会面对五花八门的需求。本文作者根据他在小红书的工作经历，总结了自己关于需求的收获和成长，希望对你有帮助。

本文记录我在小红书电商产品部营销组的主要工作与收获，三个月实习期间我承接了来自3个模块的6个需求，每个需求的耗费时间并不长，但我的收获和成长都比较多。

商家后台的体验性需求：商家后台服务于自营店铺和第三方商家，里面的板块众多，我只承接来自促销板块的需求，这里的两个体验性需求是我在刚入职时做的，难度不高，主要用于熟悉产品流程，但后来复盘时发现也有较多值得思考与改进的点。

促销场景的调研与拓展性需求：这个模块是在制定平台促销的底层规则、拓展新的促销场景和营销工具，由于平台已经有一套较为成熟的规则，并且一次变动带来的影响范围较广，所以这边的需求没有太多的迭代，我主要通过调研了解了电商促销的体系，并支持C端沉淀了一个新的券场景搭建工具。

价格中台的迭代性需求：价格中台主要为小红书C端各个业务场景提供价格计算能力，有长期业务价值、需求复杂度也较高，但我所承接的需求的实际方案并不复杂，在这个需求中比较困难的点在两个方面：沟通与协调各个C端业务场景；梳理现存的规则找出不合理性。

一、商家后台的体验性需求

商家后台主要服务于自营店铺和第三方商家，后台包含了诸多商家日常管理的模块，比如店铺、商品、订单、物流等，我所在的业务仅承接其中的促销模块。我在这部分业务中主要做了两个需求，一个是惊喜盒子活动报名流程的优化，一个是预售管理的体验优化。

1. 惊喜盒子活动报名流程优化

1）需求背景

惊喜盒子是小红书内给用户发优惠券的场景之一，用户在逛社区笔记的过程中，会掉落惊喜盒子券，促进用户从社区转化到商城购物。这个需求来源于负责收集与审核惊喜盒子券的运营同学，商家每月会提报一定数量的券，整个流程为：

整个流程出现了以下问题：

商家提报的券和主图不符合要求的比例较高，尤其是主图不合格数量占比80%

运营审核不通过后，重新报名比例较低

2）需求分析

分析后发现，出现这两个问题的原因在于：

商家在报名过程中无法感知到运营设定的券和主图的要求

商家无法收到报名审核不通过的通知

商家看到审核不通过的列表后找不到重新报名的入口，只能重新走一遍报名流程

3）需求复盘

需求的背景很清晰，方案也不复杂，在整个需求过程中，我遇到的问题主要集中在评审与开发阶段：

需求评审时被质疑有实现复杂度更低的方案；

评审过程中开发提出当前方案会影响系统中的其他部分，影响商家的判断；

在通知商家不通过的方案中，我的提示话术是“您有一条活动报名不通过”，这会让商家误认为这里的提示是针对所有类型的活动报名，但我们本次的需求仅针对惊喜盒子类型。

开发过程中研发需要相关的提报情况数据，作为开发成本的判断

通过这个需求遇到的问题给我带来的思考：

业务价值的判断：这是我前期在做需求时感悟最深的点，需求的实现最终是为了推动业务发展的，因而在接到一个需求前首先需要明确的就是这个业务的价值有多高；

提前思考方案的实现复杂度：当前是最优方案吗？有没有替代性方案？这个方案与替代性方案相比有什么优点和不足？这里的优点是否值得去做更高成本的投入？

方案设计时考虑对相关模块的影响：由于B端的需求之间联系密切，往往牵一发而动全身，因而去改动系统中一个逻辑时需要更全面的思考它的影响范围，这里的影响范围不仅是其他板块，也可能是其他业务方；

产品文案打磨：在设计产品的过程中避不开一些文案撰写，比如功能名称、提示语、页面引导语等。

2. 预售管理体验优化

1）需求背景

预售是电商促销中非常常见的玩法，用户通过提前支付定金预定商品，并在尾款期支付尾款完成下单。而在此之前，商家需要在后台提前配置好预售商品，包括商品的预售时间（分为定金期和尾款期）、预售价格（分为定金价格、尾款价格、膨胀价格）等。

在使用过程中，商家遇到了一些体验问题，并提出了如下需求：

可以支持多选预售状态导出预售数据

已终止的预售ID，支持查看详情

商品价格落入“真空价格区间”（报关商品会出现的价格校验区间）报错提示更详细

可批量配置定金预售

2）需求分析