从用户端到后台系统，严选分销教会我这些事

本文由做者朱梦珺受权网易云社区发布。

从5月份接手严选分销系统到如今，被坑过无数次

因此不能我一我的被坑，被坑过的那些事要告诉大家

1. 从用户端到后台系统，最大的区别就是业务自己

以前作邮箱大师的时候，产品需求多数来源于市场调研和用户需求分析，咱们能够用数据来讲明功能的重要性，用使用率来决定功能的优化方向。而严选现有的后台系统多数是基于现有流程的设计，现有的流程存在即颗粒。它不须要有发现需求的眼睛，而是须要深入理解业务的能力。只有正确的梳理现有流程及其问题，才能合理的流程线上化。若是没有深刻的理解，直接的结果就是只解决了表层的问题，根本的问题会一直存在于业务中。

好比一直以来困扰渠道运营不少的库存问题。原有的库存分配采用的人工划拨的方式，即划拨多少销售多少。直接致使的问题就是每次库存耗尽都须要运营人工增长库存，而主站即将售罄时有须要运营回拨剩余库存，会消耗大量的人工。因此在第一次设计解决方案设计时，重点关注人工消耗的问题了，打算采用自动划拨代替了人工划拨，以图达到节省人工的目的。而实际上线后发现，人工划拨的请求并无变少，一者是发现系统调度的规则还有优化的空间，两者是发现库存回拨操做实际上商品快速销售和渠道库存占用的矛盾，这才是真正核心须要解决的问题。

2. 后台的产品再也不仅仅是功能的设计

以前作邮箱大师的时候，功能设计的过程当中关心功能流程如何？用户体验如何？UI展现如何？在接触后台系统后发现，不是全部的产品设计，都是完整的方案呈现，也不都是设计功能自己。

先说完整方案呈现这件事，在分销系统的迭代过程当中，完全的体验了把小步快跑的快感。以商品为例，原策划中，完整的设计了从信息录入、分级断定、到分级使用的完整业务场景，开发时间评估须要1个月以上。而商品分级在渠道中推广的核心数据只有分级数据自己，其余步骤能够暂时经过人工计算录入来完成，这部分的系统开发会大大影响了功能上线推广的速度，不该该放在同等的开发优先级上。

再来讲设计功能这件事，后台系统和用户端相比，数据的重要性大大凸显。对于分销系统来讲，数据能够是商品、能够是库存、也能够是订单。对于我来讲，在设计功能的方面，也须要深刻了解我所拥有的数据，才能提供更多的功能。好比分销以前的商品数据间接从商品中心获取，咱们直接简单的将信息传递给第三方。而随着商品数据的扩充，简单的信息提供已经不能知足需求。我须要详细了解商品的每一个信息字段，阅读每个接口的信息，才能针对分销的场景，对商品字段二次包装，在提供给渠道方。简单的停留在功能设计，只能成为过去式。

3 复盘很重要，多忙都不能忘

曾经的我最惧怕复盘，我单纯的认为，我本身内心知道就行了，复盘什么不重要。如今的我，不管工做多忙，都要对功能进行复盘。写策划的时候我更多的关注功能细节，而复盘的时候可以让我更加完整的审视整个方案，认真思考是否正确的解决了问题。尤为是对于线上已有的功能，BUG的发现和修复终究只是打补丁，按期的复盘才可以发现真正问题的核心。

以订单结算为例，始终是内控和财务对帐的心病。每次对帐都会发现有很多的订单计算错误，错误的缘由也是五花八门，没有必定的规律。虽然有针对发现的问题，修正系统，可是始终没有解决核心的问题。因而我决定从原有系统每一个计算步骤入手，发现核心的问题在于原有产品不清楚业务逻辑，混淆了销售流水和结算流水，须要针对实际的使用场景进行拆分，才能正确的计算金额。至此以后的修改，才真的起到了做用。

到如今，我还依稀记得接手分销系统时的一脸懵逼。同时，我也感谢分销系统，虽然无数次掉进坑里再爬出来，可是我也真正得到了成长。如今的我，对于分销业务的认识更加的深入，对于它的发展也有更多的想法。2018，我和严选分销一块儿继续成长

更多网易技术、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 Structure Streaming和spark streaming原生API访问HDFS文件数据对比
【推荐】 【重磅发布】最风骚的走位，最撩人的峰会，裂变！变！变！变！变！变！抢！