类目管控项目复盘
最近做了个类目管控项目，要做的事情：只有签在合同上白纸黑字的类目才能在平台内销售。这也可以理解，合同上写着卖衣服，你却卖手机，这有点超过经营范围了。在线下实体店如此操作，被相关部门发现了也不好办。线上化其实也是如此，最后买到消费者那里，最后也不好解释。
项目初期时，涉及到历史数据清洗，就是怎么把已经录入系统的商家数据梳理正确，但这肯定需要时间，捞取数据，业务梳理，清洗数据，新数据通过系统管控起来，不允许在合同范围外售卖商品。
当然，系统化管控和历史数据清洗肯定是不冲突的，快速通过系统管控起来，避免新数据产生，这本来就是一条不错的路。二者有依赖，但不是强依赖，并行思维，一边开发系统，一边梳理历史数据，最后时间点一匹配就完美了。
一开始，并非所有人都这么认为，毕竟先有鸡还是先有蛋的问题，已经困扰了人类几千年了仍然没有答案。有不少同事认为先有干净的历史数据，再系统化，系统化时所使用的数据就是可验证的，对系统所有数据都有效，这样说本身没有问题，但二者不是“结束－开始”的关系。最终在业务方的力挺下，大家最终坐在一起达成共识，系统化和业务数据梳理齐头并进，系统化好的时候，有部分数据可以用来做灰度验证，这样鱼与熊掌其实兼得了。
项目中实践过程中的一些心得体会：
1. 灰度方案要尽早确定好，但灰度方案不一定是产品单方面能决定的，拉上技术甚至架构一起确认比较靠谱。这个项目一开始产品对齐了灰度方案，在上游服务层做灰度；后面上游技术不同意，建议在下游入口处做灰度，比较灰度是业务相关的，作为底层服务做灰度其实不太好控制。定不下来，只有拉架构师、双方产品技术一起聊，看看哪边做更好些，虽说哪里做都可以，架构师按照系统边界和业务变化决定了下游系统做，那这样就定下来。技术架构都觉得可以，产品也就没有争议了。
这里想说的是，每条产品线有自己的风格，技术还是产品主导，产品是否足够资深，技术和架构会怎样想，建议项目经理仍保持中立，当然可以有自己的看法，但可能理解得不全，这也可以说出来。是否需要产品技术架构拉住一起聊，这个自己还是蛮清楚的，分开聊很多时候都解决不了问题，最后还是需要一起聊，可能的话也拉上资深测试，这一点需要经验和人员熟悉度，下次可以按自己的想法推进。
2. 各产品线的评审还是要追查得严格些。有时候听一家之言还是容易出问题的，毕竟产品负责吹水，落地的还是开发和测试，因为很多技术架构方案都是直接上下游对接，测试同学比较容易被遗漏，有效的外企的三方会谈需要保持对需求的理解一致（产品、开发、测试对齐需求理解、开发完成时间和上线间），得到开发测试负责人确认可以不评审才可以，不让就会比较被动。需求评审测试的一些问题还是非常有效，包括系统间交互的异常场景，性能问题，白名单考虑都非常重要。
3. 项目排期要有些缓冲，知道有缓冲，也试探各线的执行力，有时候也挺好的。一旦确定方向就全力推进，这也是非常不错的。定负责人，技术对接，接口输出，开发完成，主测联调，安全审查，要求和试运营准备，这些都是必须要的，千万不要等最后一刻，可以输出完善一份各个阶段的检查列表，这样每个项目，不管大小，都可以随时提醒自己不遗漏，比如催产品提前准备验收计划和场景，上线前几天提安全评审，上线提醒产品验收，提前跟业务对齐试运营时间，报表数据输出，诸如此类，省些脑力。
这就是为期三周的小项目的小结，涉及团队不多，但也值得自己复盘改进提升，感谢小伙伴们的大力支持，期望接下来业务可以快速用起来！
网友评论