解读跨境电商网站完整的需求制作流程(3)

在这个需求中，我们的购物车无法同时存在两条相同的商品数据，并且无法存在多个免费商品数据，这些购物车规则牵扯到的方面较多，优化成本很高，这就导致了我们必须想出一些折中方案，尽量让用户体验不那么糟糕或者造成相当大的困惑，(事实证明在对国外同事做体验测试的时候在极端情况下是存在一些困惑问题，不过这些问题出现频次较少，可以交代客服人员在客户询问的时候进行解释。)

后台原型出图

后台制作中首先要注意在活动功能管理板块下预留其他活动的扩展空间，并且注意前后端的数据交互标注清晰，提前设计好表结构和字段方便开发建表，理清楚业务操作逻辑后，便可出图啦,这里我就贴操作逻辑以及最后的成品展示，后台操作逻辑以及关键节点解释如下：

表单部分截图如下：(部分字段)

添加加购商品如下：(部分字段)

如何判断我们的功能达到目的？

我们回过头看看我们之前的需求分析，运营希望加快清仓产品的清仓速度，提高清仓产品的曝光，那这只是业务场景，对于我们这个功能来说，清仓产品只是一种产品类型，那么如何判断我们这个功能是否有效？我们根据实际条件下(我们无法拿到页面点击数据)可以取到的数据制订以下实验：

我们采取独立样本T检验对功能效果进行评测，总共10个清仓产品，产品转化率近似，20个热销产品，转化率同样近似。

分三组制作三个专题：

第一个专题为普通专题，将10个清仓产品与20个热销产品混合放置即可；第二个专题为加价购专属专题，设定活动方式为满减，将10个清仓产品作为20个热销产品的加购商品；第三个专题也为加价购专属专题，设定活动方式为满赠，将10个清仓产品作为20个热销产品的赠品；

然后针对三个专题每一个专题抽取30个独立用户分组，用户群的用户基数近似相等，用户群转化率相似，采用相同的推广渠道，由于无法精确确定用户数量，我们只需告知推广保证每日每个专题划分的每一个群组的流量保证在一个特定数量XXXX左右，持续两周，最终得出每个用户分组的以下数据：从这个专题页落地的用户所下的订单中，同时包含清仓产品与热销产品的订单数/所有订单数，我们给它起个名字叫近似加购率（因为即使在加价购专题里清仓产品和热销产品在一起也不一定就是参加加购活动加购的）。用图表展现就是这样：

得出数据后做两两独立样本T检验，最终判断实验结果，这个网站可以根据你的数据样本辅助你完成此类实验：http://www.evanmiller.org/ab-testing/t-test.html

（对于T检验的方法和适用范围感兴趣的读者可以回顾下大学知识或者谷歌一下，这里笔者就暂不列出实验具体步骤了，后期笔者会计划专门写一篇这类实验的完整过程，这篇文章就只讲一下笔者的实验思路。）

需求评审

这一环节其实并不一定只在这一阶段做一次，就像我上面说的，笔者出了第一版方案后拉几个团队成员进行初稿评审，理出许多问题，然后再进行修改，针对一些短期无法实现或者成本较高的功能点进行排期或者删减，有时候也可能会出现二审，三审的可能性咯~如果到三审还有很多问题那就相当的揪心了，所以一般都是团队中过两遍，然后拉上BOSS们再终审一遍基本就OK了。终审是最需要用心的时候，一定要注意自己的表达能力和情绪感染力，让Boss能明白并且认同你们的方案。在会议上面对别人的提问要及时给出有理有据的答复，这一点在终审上是要尤其注意的，良好的演说能力也能为你的需求过审少很多麻烦。

设计开发

设计开发中要随时与团队成员保持联系，尤其是与设计沟通更加频繁，你们要商议具体的交互细节以及页面细节，切记不可用特定的言语干扰设计思路。

比如说，有些产品会要求设计某个按钮用什么什么颜色，某个元素大一点，小一点，这都是不可取的。你只需要确定好信息层级，告知设计师由于业务需求，哪些元素需要强调，哪些需要弱化即可，设计师会根据设计规范以及自己的设计思路进行设计，否则就会和设计师怼的没完没了了；至于与开发的沟通，主要是在逻辑层面的交流会更多些，而且笔者认为最好能懂些技术知识，即使一点不懂你也要分清楚哪个开发是做哪一块的，遇到问题找谁，跟他应该怎样沟通，如果存在沟通障碍，那么程序员一般的反应都是—>生闷气，不理你，哈哈，你要知道，大部分程序员还是很可爱的。当你的需求提上去后，什么时候测试，什么时候上线，这块的进度一般都由项目经理掌控，当然，自己的心里也要有谱，有自己的项目进度表。

测试

测试确实是个心累的活儿，如果你们公司的测试人员较为专业，会为你省下不少麻烦和时间，你只需要负责上线前每一个阶段的验收即可。否则，你就得自己写测试用例，测试反馈，直到上线，这里每个公司的流程不一样，这里也就不过多阐述，免得产生误导。

上线观察，数据反馈

在此之前需要跟运营人员以及推广人员打好招呼按照事先设计的实验方案进行实验，在上线之后每日监控数据变动情况，每组数据的流量是否有异常，专题商品库存情况，下架情况，等等，总之需要控制变量，确保实验按照时间顺利完成，最后拉取实验数据进行数据分析，根据分析结果确定此功能的可用性，得出分析报告反馈给团队成员和BOSS。

版本迭代

这一部我并没有写到最开始的那个流程图当中，对于一个完整的产品有大的版本迭代，对于一个功能同样也会有相应的版本迭代。在这个需求中，我们前面根据一二期需求评审之后以及后续根据运营人员的实际情况进行功能扩展，针对此功能大致得出以下迭代计划：

当然，这个迭代计划只是作为产品人员自己的计划。具体每一阶段是否上线还需要根据每一阶段的数据反馈以及公司具体的运营需求和运营策略的变化（在一个运营主导的公司就是这样咯~）进行调整，总之，用心对待自己做出来的东西，不仅仅是生孩子，养孩子的责任你同样也逃不了。

至此，这个需求从初始到上线的一个流程就基本结束了。虽然仅仅只是通过一个需求来回顾了一下需求从开始到结束的整个框架，不知不觉也有了近7000字，对于里面的细节部分请原谅我没有在本文中全部写出来，文中还有许多的不足请各位读者给予指正，私信评论都可，哈哈，欢迎拍砖。

文章作者系 @白子 未经许可，禁止转载。

注：相关网站建设技巧阅读请移步到频道。

编辑：未知