产品严选的原则急求答案，帮忙回答下

产品严选的原则-教育精选-简单网

1. 系统要有明确的边界，服务要有明确的归属

当产品矩阵有限时，系统边界通常是明确的。但是，在业务领域多形态及交互复杂的情况下，往往会伴随很多边界和协同的问题，相同或类似的功能没有归属，就会导致重复开发并且推高维护的成本。

比如供应链系统中需要记录商品与仓库之间的绑仓关系，指定一个商品只能放在哪个仓库里（由于存储和配送条件的限制，商品无法任意放）。起初，绑仓关系只用于采购送货，入口开放在商品中心。随着业务复杂度提高，出现了仓间调拨和履约等场景，继而出现了五花八门的绑仓用法，长在了仓配工作台，库存中控台等各个业务系统上。

系统缺乏边界感，对“绑仓关系”缺乏明确的定义和归属，导致了采购、调拨和发货环节，对这份信息反复存储迭代修改，引起了很多不必要的误会。“绑仓”到底归属于哪一个系统边界，这是在设计系统和增加服务之初就应该严格确定好的内容。

2. 交互的系统达到一定数量问题频发时，就要警觉秩序的重要性

系统建设的初期，我们常常会以“走通”和“够用”为前提，不做过多设计。但随着业务体量和复杂度的升级，单点的问题会被放大或衍生出新问题，这个时候，建立一套通用规则来约束系统间的交互，并且，针对不同程度的“违约”，配合不同等级的管控措施就非常必要。

一个典型的例子就是库存系统，消费者在严选主站的购物行为会触发一系列的库存状态，最简单的场景是消费者对某商品下了一个订单，随着订单的状态从下单，到支付，再到出库，对应商品库存也会经历连续性的状态变化。可是当场景变复杂了呢？考虑逆向取消和售后场景呢，商品在主站外的其他渠道售卖的场景呢当上游一堆服务同时对同一个商品库存状态发起密集的调用指令，但是这些调用指令又没有很好的规范（如单状态重复调用，连续状态跳跃式调用，调用未完结等等），就会引起一连串的库存“事故”。

此时，在上游与库存状态的交互中建立一套完整的调用规范就非常有必要。如何定义调用是合规的，如何确定调用动作的完结？针对不同的异常，如何建立违规等级，不同的等级给予不同的防御规范，这些问题又可以衍生成如何监控，帮助用户快速定位问题的工具，自动修复等等，都是产品功能设计需要考虑的内容。

中后台系统，特别是符合中台属性的底层服务，跟其他产品交互的概率很大，都需要认真思考规范和秩序的问题。

3. 基于对象抽象规则，远比端到端的流程线上化重要

前文提到 toB 相对于 toC，有一个显著的特点就是，通常都有比较明确的用户需求，把明确的客户流程搬到线上是重要的一环。那么问题来了，是不是条理或逻辑清晰就是一个优秀的产品了呢？答案当然不是，这是个必要而非充分条件。

许多情况下，仅仅对流程做清晰的梳理，然后一步一步搬到线上，做到了搬砖，但并不是个好的实现方式。对于一条比较通用的功能，在设计时，对规则和能力做必要的抽象，能将一个单点的功能转化成一个拓展性良好的通用能力。

再来看一个案例，比如疫情期间武汉封城，除了医疗物资外其他所有日用商品一律不能配送，业务提前知道了这个风险，就希望严选系统针对武汉地区把除了防疫物资以外的商品订单卡住，不要下发给仓库和快递公司，只把防疫物资正常下发。听起来是个非常简单的功能，按既定规则订单打标并卡住即可。

但仔细想想，卡单是一个特殊还是通用功能呢？其实是比较通用的，仓库或者快递承运商出了故障，前台配置错误导致订单需紧急召回，直播等等情景都可能触发“系统卡单”这个功能。想到了这一层，产品设计就不应该简单的只针对单一场景做线上化，而是将系统卡单抽象成，第一条件设置（订单、用户、商品、地址等等维度）、第二规则引擎（条件组合及优先级的拼装）、第三业务决策（是否拆包、卡单、定时推单），这三个通用步骤来组装以满足更多的场景。