严选供应商系统边界治理实践
1 边界治理在做什么
团队层面，边界治理是明确版块定位并让团队的职责聚焦版块定位。 从产品技术层面，边界治理是规划领域能力并内聚散落在其他版块的领域能力。
2 为什么要做边界治理
2.1 历史背景
一方面，【供应商版块】承担了许多非供应商领域的职责，包括外仓相关，采购履约相关，售后相关等等。 另一方面，应归属到供应商版块的“寻源”&“报价”散落在了【商品中心版块】和【采购版块】。
2.2 降低研发效能
评估难：逻辑分散带来了“完整性”的挑战，依赖其他团队评估结果又要面临“效率”问题。 排期难：跨团队排期需要解决“优先级匹配”以及“研发节奏同步”。 改动难：核心难点在于烟囱式建设带来的“领域逻辑一致性”的问题，特定情况下需要先解决“历史逻辑不一致”的问题，才能开始后续工作。 测试难：测试往往需要进行跨系统造数，有一定的跨系统熟悉成本。
2.3 缺少整体性规划
外仓相比于内仓，产品上缺少“库存管理”功能。 外仓相比于内仓，技术上采用的“物流轨迹查询”方案比较滞后，其的一些物流轨迹停滞问题。 ……
外仓每年会因为线下手动管理库存，导致外仓次品数量统计出错。 外仓平均每月会有一些物流轨迹停滞问题。
2.4 偏离团队目标
3 如何做边界治理
3.1 表达边界
表达语言：语言的粒度要能足够支撑边界描述的丰富性，同时理解成本低。 统一：边界表达后是要用于沟通的，显然语言要统一。 准出：一方面，所有版块的边界要独立不重合，且整体要完整覆盖超域。另一方面，要解决版块间的职责冲突。因此需要有个“准出”环节要把控。
供应商版块核心用户：供应商、采购 供应商版块核心问题域：供应商管理、供应商与严选线上协同的基础能力建设 场景&产品&能力设计如下：
3.2 识别边界问题
3.3 解决边界问题
3.3.1 三大特点
偏产技驱动 跨版块技术重构：能力迁移涉及代码迁移以及相关的内外部依赖改造。 迁入方学习成本高：迁入方要学习业务、产品、技术等等系列细节，包括历史业务产品规则和代码本身，尤其在文档缺失的情况下。
3.3.2 三大难点
价值共识：偏产技驱动的需求，往往在与“业务”、“PMO”等角色就价值共识的达成商，会有一定的难点，因为他们无法直观感受到痛点与收益。 研发资源空闲度匹配 ：跨版块的协同，需要保障“研发资源在时间上的空限度匹配”，尤其在”迁入方面临高学习成本“时，加剧了对空闲研发资源的要求。 稳定性保障：能力迁移涉及代码迁移以及相关的内外部依赖改造（包括DB、MPS等等基建依赖），改动范围的完整性、改动正确性、生产环境依赖切换的平滑性等方面，均对系统稳定性有巨大影响。而且随着工程量提升到一定程度，难度会指数级提高。例如【供应商版块】【采购版块】的能力迁移，单后端涉及10w+代码，60+张表，150+接口，单纯生产环境切换后的接口验证，就需要耗费大量工作。
3.3.3 三大策略
业务导向
提高需求分析效率：逻辑割裂会提高“分析完整性”的成本，进而导致“业务产品研发“等职能的分析低效性； 提高稳定性&减少运维成本：逻辑割裂会增加“分析改动点不完整”的概率，进而，一方面直接导致线上功能无法使用，另一方面，往往“业务”、“产品”、“技术”等职能要进行数据捞取&订正&验证，经历过的都知道痛（“怎么又漏场景了！”）； 加快业务响应：只要涉及外部联动，那么即使是半天的改动量，也会因为优先级不一致而导致交付周期延长xx周，经历过的都知道痛（“要不是不懂，好想直接进依赖方的代码库敲代码”）； 减少学习成本：能力分散的情况下，“概念重复”的问题会难以避免，进而引入重复学习的问题（尤其涉及指标时，重复学习的成本更高）。
频率：可以通过“相关领域是否有重点业务项目”来进行简单的推算，一方面重点业务项目本身蕴含着迭代和运维收益，另一方面，相关领域在“重点业务项目”之后会伴随一定的高频迭代。 收益：对相关类型问题耗时提前做好耗时的采集，进而后续支持分析和推算，这是比较容易被忽视的，同时也较难进行弥补的。
前瞻性&精细治理
可以让迁入方先接手增量迭代运维任务，然后再接手历史存在的功能。 可以先交接产品职责，再交接技术职责（包括扩展与维护）。 迁入方可以先在迁出方的代码库里进行代码开发，再择机进行能力迁移（包括代码迁移和DB库迁移）。
采购团队先负责新增需求，后熟悉存量需求。 采购团队先进行产品交接，再进行技术交接。 采购团队于2020.h2接手运维，2021 全年分两次进行能力迁移。
复杂度降解
确保改动完整性 可以基于数据流进行改动逻辑梳理盘点。在技术层面实操时，可以通过DAO层代码从底下上梳理链路。 进行数据迁移时，不要忘了与数仓对齐相关数据源的改动。 迁出方删除所有已迁移的代码并进行回归，进而进行完整性兜底。在进行【供应商版块】【采购版块】间的边界治理时，靠此方式解决了多处“能力迁移遗漏点”。 后置非必要的改动 减少外部依赖改造：对于“迁出方”提供给外部的api，暂时由迁出方作为迁入方的反向代理，进而减少外部依赖的改造。后续择机进行外部依赖的改造。 减少不必要的模型升级：很多时候会想借助能力迁移，对迁入的模型进行升级和整合，但这必然增加改造和验证复杂度，如果不是必须项，可以后续择机升级。
前置验证“数据清洗逻辑”
4 成果
研发效能提升：【供应商版块】通过“供应商报价”边界治理，促使了能力内聚和改动自治，整体达成了易评估、易改动、易排期、易测试的效果，在后续的产品迭代中，最快能单天优化与发布。 提高领域规划完整性：通过【供应商版块】【仓配版块】的边界治理，不仅解决了背景中提到的问题，【仓配版块】还在后续绘制了外仓建设蓝图。 聚焦团队目标：供应商团队完成版块定位，并且后续专注于版块核心领域的建设。
5 小结
除了“能力迁移”本身外，边界治理的核心和挑战在于“认知版块定位”，“表达版块边界”，“对齐版块边界”等事情。 边界治理绝对不仅是技术的事，这个过程是需要产品与技术紧密协作，脱离产品的边界治理会在实践时更容易遇到“边界划分不合理”、“边界腐化”等问题，最终使得边界治理变成闭门造车或不具有可持续性。 边界治理是个常态化的事情，随着业务、技术、组织与人的认知的不断变化，板块的定义与边界仍然需要不断的演进才能适应业务的发展。