引言#

前面一直在讨论产品经理如何把判断落到真实工作里：问题要定义清楚，方案要回到用户任务，数据要成为证据，技术代价要被看见，组织也要能够围绕一个选择持续行动。一个需求可能只需要解决一个局部问题，但一块业务持续发展以后，会逐渐牵涉更多角色、更多流程、更多规则，原来彼此独立的功能也会开始发生关系。这个时候，我们面对的事情往往会开始变得复杂，产品经理就不能只考虑眼前这个需求怎么实现，还要开始考虑这些东西应该怎样被组织起来。

很多人会把这个阶段理解成「做架构」，于是很自然地开始画模块、分系统、拆前台后台，把业务整理成一张看起来完整的架构图。这些工作当然有价值，但产品架构最难的地方不是把系统分成几块，而是判断这些结构为什么应该存在。如果对业务本身理解得不够深，模块划分得再漂亮，也可能只是把当前的功能重新摆了一遍位置；反过来，如果能够看清业务里稳定的角色、动作、关系和变化，有些架构会自己浮出来。所以先不急着讨论中台怎么搭，也不讨论一个能力应该怎样抽象和复用。我们回到架构出现之前：面对一块逐渐复杂起来的业务，产品经理应该先看见什么，才能知道系统接下来应该往哪里长。

12.1 回到现场——先看见业务是怎么发生的#

2019 年我们在做一款社交电商 App，业务早期采用拼团模式，后来逐步转向会员制。伴随业务模式变化，平台的用户规模开始明显上升，商品品类也不断扩充。早期团队更关注用户增长和交易规模，但当越来越多用户进入平台以后，业务关注的问题也开始发生变化：用户来了以后能不能留下，新用户能不能尽快完成第一次购买，已经消费过的用户能不能继续复购，不同类型的用户又应该用什么方式去承接。用户运营和活动运营团队因此进入了一个非常忙碌的阶段，每天都在围绕新人转化、老客复购、会员经营和品类营销设计各种活动。

其中有一次让我印象比较深的，是用户运营针对新注册用户做的一次转化分析。当时他们在日常留存数据里发现，新注册用户的留存曲线在第 7 到第 8 天附近会出现一次比较明显的下滑，之后才逐渐进入相对平稳的状态¹。单看这个数据还不能说明太多，但继续对不同用户行为做分层以后，另一个差异开始变得明显：注册后发生过下单行为的用户，后续留存明显高于一直没有下单的用户。再把已下单用户按照首次下单时间拆开，注册 7 天内完成首单的用户，又是其中一批留存表现相对更好的用户¹。

这些数据放在一起以后，用户运营形成了一个很自然的判断：新用户注册后的前 7 天可能是一个比较重要的转化窗口，如果能够让更多用户在这个阶段完成第一次下单，就有可能提高他们后续留下来的概率。用增长黑客领域的说法，我们当时把「7 天内完成首单」看成了一个值得重点验证的 Aha 时刻候选：用户完成注册，未必就感受到了平台价值，第一次真实交易可能才是其中一个更关键的节点。于是「7 日内未转化新客」被单独拿了出来，用户运营希望针对这批注册时间还不长、但始终没有完成首单的用户做一次专门的转化承接。希望通过一些更有针对性的活动，让更多人尽早跨过第一次购买这道门槛。

到这里，业务目标其实已经比较明确了，但麻烦的事情才刚刚开始。数据只能告诉我们，7 天内完成首单和后续留存之间存在明显差异，却没有告诉运营应该用什么办法把用户推到这一步。到底应该给新人更直接的价格优惠，还是发一张新人券；应该推荐低价、决策成本更低的商品，还是根据用户浏览偏好推荐更匹配的品类；页面应该强调「新人专享」，还是强调优惠即将过期的紧迫感；甚至不同类型的新用户，会不会本来就应该看到不同的商品和利益点，这些都没有一个现成答案。

所以当时用户运营提出的，并不是「帮我开发一个新人活动页」这么简单，他们更想验证的是：面对一批注册 7 天内还没有完成首单的新用户，到底用什么内容、商品和营销方式承接，才更有可能推动他们完成第一次交易。用户最后看到的，只是首页上的一个弹窗和点击跳转的一张活动页，但这样一个看起来很简单的前台动作，要出现在正确的人面前，并且最后还能判断它有没有效果，背后需要很多角色一起把这件事做出来。

12.2 拆开链路——看见角色、动作和交接物#

用户运营虽然已经把目标锁定在「7 日内未转化新客」，但准备活动时，很快就碰到第一个现实问题：这批用户到底是谁？今天看起来，这似乎只是一个简单的人群条件，注册时间小于等于 7 天，同时没有下单记录，在后台勾选几个标签就可以完成。但当时系统还没有成熟的标签和人群圈选能力，用户的基础信息、访问行为、交易记录虽然已经沉淀在数仓里，运营却无法直接使用。

每次要找一批特定用户，都需要先找到数分同学，把业务语言重新翻译成数据口径。「7 日内」到底按照自然日计算，还是按照注册时间计算；「未转化」以创建订单、支付成功还是交易完成为准；用户下单以后又退款，要不要重新回到这批人里；这批人群一天更新一次，还是需要随着用户行为实时变化。运营最初提出的只是一句「找到 7 天内还没有下单的新人」，但要让数据跑出来，中间这些边界都必须先被定义清楚。数分确认口径以后，再由数仓按照规则加工数据，每天跑出一批满足条件的用户 ID，交给后续活动使用。到了这里，一个业务上的「目标用户」，暂时变成了一份可以被研发识别和使用的用户 ID 名单。

但找到用户以后，关键的问题仍然没有答案：到底给他们看什么，才更容易推动第一次下单。因为答案并不确定，用户运营通常会准备几种不同思路：有时调整的是利益点，比如新人券、直接降价或者限时优惠；有时调整的是商品，比较低价尝鲜商品和不同品类的转化差异；有时商品基本不变，只调整「新人专享」「限时福利」等活动氛围和表达方式。运营把这些想法交给 UED，设计同学再把它们变成一张张可以上线的活动页面。页面本身并不复杂，大部分还是由活动氛围、营销利益点和商品信息组成。麻烦的地方在于，我们一开始并不知道哪个组合有效，所以经常需要同时准备多个版本。为了让后面的结果尽量可比较，有时会固定页面和利益点，只替换商品；下一轮再固定商品，继续调整其他因素。

目标用户有了，活动页面也有了，接下来需要解决的，是怎么让不同用户按照运营预设的方式看到不同内容。到了产品和研发这里，业务的想法会变成一套更加具体的实现要求：识别数仓给出的那批用户，在他们进入 App 时展示首页弹窗，点击以后跳转到指定活动页面；如果同时存在多个方案，还要按照提前约定好的比例进行分流，比如 50% 的用户进入 A 方案，30% 进入 B 方案，20% 进入 C 方案，并且保证同一个用户后续再次进入时仍然落在原来的分组里¹。当时这类需求基本依赖定制开发，研发需要根据设计稿开发不同活动页面，再把用户 ID、页面和分流逻辑写进当前活动的代码里，几个页面即使只是商品不同或者局部样式不同，也经常还是几套独立实现。

目标用户换了、页面换了、比例换了，产品和研发就要重新调整一次。开发完成以后，测试也要跟着进入这条链路：符合条件的用户能不能正常看到弹窗，不属于这批人的用户会不会被误触达，不同分组最终拿到的页面和商品是不是正确，点击活动页以后，加购、下单和支付有没有受到影响，这些都需要逐一验证。

从用户视角看，只是打开 App，看见一个弹窗，点进去浏览商品，最后下单或者离开。但对用户运营来说，活动上线并不是结束，验证才刚刚开始，因为最初那个问题还没有答案：到底哪一种商品、利益点和页面方式更有效？当时我们同样没有成熟的实验和效果评估能力。某个用户属于哪一组、最终看到了哪一个页面、有没有完成首单，这些信息并不会自动汇集成一份实验结果。数分同学还需要重新把用户 ID、分流标识、活动页面和最终的订单数据关联起来，再临时搭建 BI 报表，由运营、产品和数据一起观察不同方案之间的差异。至于应该观察多久，样本量多少才足够，两个方案之间的差异达到什么程度才值得相信，当时也没有形成很稳定的标准。更多时候，还是由活动负责人结合短期转化表现做判断：哪个版本继续保留，哪个版本暂停，或者再换一组商品和利益点继续尝试。

这样回头看，一场看起来并不复杂的新人活动，在组织里经过了一条很长的链路：

表 12-1　一场新人活动在组织里经过的链路

如果只看流程，我们看到的是很多角色在共同完成一次活动，把链路拆得更细以后，会发现另一件更值得注意的事情：不同角色之间始终在传递一些具体的东西。业务目标、数据口径、用户 ID、商品信息、设计稿、页面地址、分流比例、用户分组、转化结果……这些材料散落在 Excel、PRD、设计稿、代码和临时报表里。每一种看起来都只是当前活动的一份材料，但它们并不是用完就消失。换一个活动，类似的东西还会重新出现；换一批用户，它们又会按照差不多的方式再流转一次。

产品经理拆业务链路时，不能只看「谁做了什么」，还要看「做完以后留下了什么，又把什么交给了下一个人」。角色和动作会让我们看见业务是怎么运行的，交接物则让我们开始看见：哪些东西正在业务里被反复定义、反复传递，只是还没有被系统真正接住。但在当时，只要活动还能上线，这些问题并不会显得特别严重，让我们开始意识到这套方式已经出现问题的，是后来几次业务变化。

12.3 追问异常——正常流程看不见架构问题#

前面的新人活动虽然做起来麻烦，但只要各个角色继续靠人工协作把链路接起来，最后总能上线。很多系统问题也正因为如此，很长时间不会被看见：流程能跑，需求能交付，页面也能正常使用，大家最多觉得效率低一点、协作累一点，还不至于认为系统本身出了什么问题。让问题得以暴露出来的，往往不是正常流程，而是业务开始变化以后。后来负责新人转化的用户运营同学发生了调整，提出了另一种思路：与其继续通过普通新人活动页刺激首单，不如直接引导用户购买会员礼包，让第一次交易和会员转化同时发生。这个方案本身并不复杂，前台只需要在首页增加一个弹窗，点击以后进入会员礼包页面，后面的交易链路也已经存在。

但进入需求评审以后，前端和测试同学很快给出了一个提醒：这批用户不是已经有一个新人弹窗了吗？这个提醒让大家重新翻出了之前那条「7 日内未转化新客」的活动链路，老活动一直还在运行，只是最初负责它的人已经发生变化。为什么当时这么设计、测试过哪些方案、最后为什么留下当前版本，这些信息已经没有多少人能完整说清楚。代码还在，页面还在，目标用户也还是同一批人，只是业务记忆已经逐渐消失了。

问题很快从「再加一个弹窗」变成了另一件事：同一个新人进入 App 时，到底应该先看到旧的新人活动，还是新的会员礼包？两个弹窗能不能同时出现？如果不能，谁的优先级更高？旧活动要不要直接下掉？如果新方案效果不好，还要不要恢复？技术上，这只是一个优先级和互斥关系的问题；但站在业务角度，它其实是在追问：同一批用户到底应该走哪条转化路径？新的方案是在替代旧方案，还是只是叠加一个新的尝试？

最后用户运营的判断是：老活动虽然一直在跑，但新人转化仍然有提升空间，如果新路径上线以后还让旧活动同时干扰，就很难判断会员礼包本身有没有效果，所以这次先把旧活动隐藏，让新链路单独运行一段时间。产品重新调整需求，研发增加了相应的判断逻辑，旧页面没有删除，只是暂时不再触发，因为大家也担心新方案效果不好以后还要重新切回来。这次额外改动本身并不算大，但让我在意的是另一个问题：一条活动链路上线以后，并不会因为最初的需求结束就自动消失，它可能继续存在几个月，甚至更久。最初负责它的人会换，业务目标会变，新方案会不断出现，但旧逻辑仍然留在系统里。业务已经忘记它为什么存在，系统却还在继续执行它。

另一次问题出现在一个更普通的活动需求里，活动运营希望在商品列表上增加优惠券使用倒计时。逻辑很简单，用户领券以后，在商品卡片附近展示「还剩 XX 小时可使用」，希望通过时间感加强优惠感知，推动用户尽快完成购买。平台当时大部分常规频道和活动页已经使用相对统一的商品列表样式，所以最初评估下来，这只是一个不大的公共能力调整。

进入开发以后，研发同学提醒我们：以前那些定制活动页怎么办？包括那场新人活动在内，历史上为了不同业务需求做过不少独立页面。这些页面虽然看起来也在展示商品列表，但很多并没有使用现在统一的组件，而是当时单独开发的一套实现。如果只改公共页面，就会出现同一张优惠券在普通频道里有倒计时，进入历史活动页以后却没有；如果要保证平台体验一致，这些旧页面就必须一起改。我们只能重新把过去还在线上的定制页面找出来，一个个确认哪些仍然有流量、哪些还在被业务使用、哪些虽然已经没有人运营但代码仍然存在。原本一个不到一周可以完成的需求，因为要兼容这些历史页面，研发需要逐个补逻辑，测试也要重新回归，最后整体排期被拉到了 2 周以上。

活动运营对此很难理解，在他们看来，需求只是「优惠券增加倒计时」，这些历史页面为什么还存在、为什么没有复用公共能力、为什么现在修改一个公共样式还要额外投入这么多研发资源，并不是这次业务需求造成的。站在他们的角度，这个判断也没有错，但站在产品和研发角度，这些成本又真实存在。过去每一次「先把活动做出来」的定制开发，都在系统里留下了一点差异。当时看，每一个差异都不大；若干个月以后再看，它们已经变成了任何一次公共变化都必须重新考虑的兼容范围。

这两件事表面上看似并不相同：第一件事里，旧活动和新活动争夺的是同一批用户、同一个首页入口，问题暴露在业务变化以后，老方案为什么还在，新方案和旧方案是什么关系，谁决定哪条链路应该继续；第二件事里，没有业务策略冲突，只是一个普通的公共能力变化，却因为历史定制页面太多，把原本很轻的需求变得越来越重，问题暴露在系统变化以后：过去那些为了单次活动留下来的实现，开始持续向未来收取维护成本。但它们背后有一个共同点：正常流程只能告诉我们一件事有没有做完，异常和变化才会告诉我们，过去那些东西之间到底存在什么关系。同一个用户同时命中两条活动链路，我们才开始追问活动之间有没有优先级和互斥关系；一个公共能力要修改，却被历史页面拖住，我们才开始追问这些页面到底是不是同一种东西，为什么不能统一变化；旧活动已经没有人说得清最初的判断，却还在系统里继续运行，我们才开始追问一项业务配置什么时候应该结束，谁应该知道它还存在。

正常流程最容易让系统看起来合理，因为每一个步骤都有人接，每一个需求最终也都能完成。真正值得继续追问的，反而是那些「不顺」的地方：两个方案为什么会撞在一起，一次普通变化为什么要改这么多地方，一个已经失去业务记忆的东西为什么还在继续运行。正常流程让团队把需求做完，异常让团队看见旧方案怎样拖住新的变化。如果一个产品架构只能表达「正常情况下业务怎么跑」，却解释不了业务变化以后为什么会冲突、为什么会被旧方案拖住，那么所谓的架构，很可能只是正常流程的美化版。

12.4 抽出对象——从不同需求里找到不变的东西#

让我开始重新看这类需求，是一次产品和研发的季度复盘，当时我负责电商产品团队，我们把一个季度做过的需求重新拉出来，想看看研发资源主要消耗在了哪里。结果发现，仅仅围绕「给特定用户做一场活动」这一类事情，一个季度就做了不下 7 次¹。有的是新人转化，有的是老客复购，有的是会员运营，也有的是品类活动。每一次业务目标不同，页面不同，商品和利益点也不同，所以平时看起来都是独立需求，但放在一起以后，会发现团队一直在重复相似的动作：先找到一批用户，再准备活动内容，确定从哪里触达；需要比较方案时再增加分流，活动结束以后，数据团队再把用户、页面和最终结果重新关联起来。

最直接的问题是资源消耗，一场活动从提出到上线，少则 3～5 个工作日，如果同时准备几个页面做比较，前后花掉一两周也很常见。数分和数仓反复加工用户，设计反复制作结构相近的页面，产品和研发反复把用户、页面和展示逻辑连起来，测试再重新走一遍验证。更麻烦的是，活动结束并不意味着这些投入就结束了，定制页面和代码会继续留在系统里，下一次公共能力调整时还可能重新产生兼容成本。一次两次看起来只是效率低一点，但当一个季度里类似需求反复出现时，这已经不是单个项目的问题了。

当时团队最容易想到的解决办法，是把重复开发变成复用。页面总在重复，就想办法做成可配置；每次圈人都要找数仓，就把常用条件沉淀下来。这个方向当然没错，但更值得继续往下看的，是另一个问题：这些需求明明解决的是不同业务问题，为什么每次都会经过这么相似的过程？如果只是页面长得像，那可能只是实现方式重复；但如果换了业务目标、换了运营负责人、换了商品和利益点以后，有些东西仍然一遍又一遍出现，那它们可能本来就是业务里相对稳定的部分。

「7 日内未转化新客」是一批人，30 天没有再次购买的老用户也是一批人，某个会员等级、某类消费特征、某种行为状态的用户，本质上还是在回答同一个问题：这次业务到底想影响谁。过去每一次需求里，这个答案最终都会变成一份用户 ID 名单，看起来只是数据团队交出来的一份结果，但真正稳定存在的并不是这张名单，而是业务始终需要定义一批目标用户。名单会每天变化，筛选条件也会变化，但「这批人是谁」这件事一直都在。于是我们开始把它从一次离线数据结果里拿出来，理解成一个相对独立的业务对象，也就是「人群」。

过去产品和研发最容易看到的是活动页，因为运营最后交过来的是设计稿，研发最终做出来的也是页面。但需求做多以后会发现，同一场活动里还包含商品、利益点、活动时间和具体内容，有时候同一个活动甚至会同时准备几个不同版本。页面会换，商品会换，视觉表达也会调整，但业务始终需要有一个相对独立的东西，把这次运营意图组织起来，回答「这一次到底要给用户什么」。所以后来再看时，我们不再把活动简单等同于一张页面，页面只是它最终呈现出来的一种形式，「活动」本身开始成为另一个可以被单独理解和管理的东西。

类似的变化也发生在首页弹窗、Banner、频道入口这些位置上。过去它们通常只出现在 PRD 的一句话里：在首页弹窗展示，在频道页增加入口。研发按照需求把逻辑加进去，大家很少单独考虑这些位置本身。但当越来越多业务都要使用它们以后，「在哪里展示」就不再只是页面实现的一部分。一个首页弹窗可能同时被新人运营、活动运营和会员运营需要，一个 Banner 位置也会在不同时间承接不同业务。它们数量有限，会被反复使用，也会发生争夺，于是这些入口开始从具体需求里被单独看见，成为业务需要持续管理的「资源位」。

到了这里，一场过去被完整写进 PRD 里的活动需求，开始可以被拆开来看。运营说「给 7 日内未转化新客展示新人活动」，里面包含了几个不同的东西：谁，是人群；给他什么，是活动；从哪里让他看到，是资源位。过去它们被一次性写进同一个需求，再由产品和研发临时拼在一起，所以团队看到的是一条完整的活动链路。把不同需求放在一起以后才会发现，变化的是每一次装进去的业务内容，而这些基本角色一直没有消失。

产品经理不是只去找两个页面是不是长得一样，也不是看到两段代码类似就马上考虑复用，而是要继续往业务里问：什么只是这一次需求的内容，什么却在不同场景里反复出现。新人可以换成老客，商品和利益点可以不断调整，活动入口也会变化，但「谁、给他什么、从哪里触达」始终需要被表达。过去这些东西分别散落在数仓、Excel、设计稿、PRD 和代码里，每来一个新需求，团队都重新定义一次、重新组合一次。它们并不是后来为了做架构才被创造出来的，只是以前一直没有被系统看见，当这些不变的东西被逐渐识别出来以后，产品架构才开始有了轮廓。我们不再只看到一条条具体需求，而是开始看到需求背后那些持续存在的业务对象。

图 12-1　三个位置各自换过什么　换掉的是这一次装进去的内容，三个位置自己一直没有被换掉。

12.5 建立秩序——让对象、关系和规则进入系统#

人群、活动和资源位被逐渐拆出来以后，原来写在一条需求里的东西开始可以被分别理解，但这还不是架构，因为真实业务不是把几个对象摆在那里，而是让它们发生关系。运营要表达的始终是一件完整的事情：在某个时间，把某个活动，通过某个位置，展示给某一批用户。过去这句话直接写进 PRD，再由研发翻译成代码；现在对象被拆开以后，就需要一种新的方式把它们重新组织起来。

我们最后逐渐形成了一套更清楚的表达：用户运营先定义「谁」，比如注册 7 天内且没有完成首单的用户，系统根据条件持续更新这批人，并形成一个人群；活动运营再定义「给他什么」，把页面、商品、利益点和活动时间组织在一起；首页弹窗、Banner、频道入口这些位置，也不再只属于某一次需求，而是成为可以被不同业务共同使用的资源位。最后再建立一条投放关系，把人群、活动和资源位关联起来，同时定义什么时候生效、在哪个渠道生效、发生冲突时谁优先。

这样一来，过去一句「给 7 日内未转化新客在首页弹新人活动」，开始可以被系统拆成几个部分来表达：谁，是人群；给什么，是活动；在哪里，是资源位；什么时候、在什么条件下发生，是投放规则。过去每来一次活动，产品和研发都要把这些信息重新拼进代码；现在人群可以被其他活动继续使用，活动可以投放到不同位置，资源位也不再随着某一次需求结束而消失。变化的仍然是每一次业务内容，但那些稳定的东西开始有了自己的生命周期。

当时最先需要解决的，仍然是已经很明显的效率问题。其中页面的变化频率最高，一场活动往往要准备几个不同版本，不同活动之间又存在大量相似结构，所以我们先推动了 CMS 的组件化建设。过去要一两周才能做完的一批页面，组件化以后一天以内就能完成，熟练之后一两个小时就够。同时人群能力也在逐步推进，「7 日内未转化新客」不再是一份某天导出的用户 ID 表，而是一批会随着用户注册、下单等行为持续变化的人，运营操作的，也从「帮我导一批人」慢慢变成了「我要定义一批什么样的人」。

页面和人群都能够被独立管理以后，过去藏在 PRD 和代码里的关系也必须进入系统。因为同一个用户可能同时属于多个人群，一场活动可能出现在多个位置，同一个首页弹窗更不可能无限承接所有业务。于是投放开始有了更完整的条件：渠道、平台、人群、时间、资源位、优先级，有些场景还会加入权重和流量比例。同一个用户在同一次访问里，如果同时满足多个活动条件，系统需要根据资源位和优先级决定最终展示哪一个，而不是等到需求评审时再由产品和研发临时讨论怎么兼容。

图 12-2　一个资源位上的优先级裁决　同一个用户同时命中三条投放关系，资源位决定在哪展示，优先级决定谁先展示。

这时候，精准营销才开始有了比较完整的形态。它不是简单给用户打几个标签，也不是单独做一个活动后台，而是把人群、活动和资源位之间的关系组织起来，让业务能够明确表达：什么人，在什么时间、通过什么位置，看到什么内容。过去这些判断散落在 Excel、PRD 和代码里，现在开始成为系统可以配置、执行和追踪的业务规则。

规则进入系统以后，责任也逐渐变得清楚。以前一个运营团队只知道自己需要首页弹窗，却未必知道这个位置上还有哪些活动；产品和研发很多时候也要翻历史需求、查代码，才能确认哪些逻辑仍然存在。资源位被统一管理以后，哪些活动正在运行、分别服务哪些人群、什么时候结束、发生冲突时谁优先，第一次可以被相对完整地看见。用户运营和活动运营仍然负责自己的业务策略，但涉及核心资源位和多个活动之间的冲突时，需要有人从更全局的视角判断有限资源应该给谁。后来平台运营也逐渐承担起这部分管理责任，系统解决的不只是配置效率，还把过去模糊的业务边界和责任显露了出来。

不过，执行效率提升以后，最初那个问题并没有自动消失：哪一种商品、利益点和页面方式真的更有效？页面可以更快搭出来，人群也可以更快圈出来，并不意味着业务就更容易知道「哪个方案更好」。如果只是让试错变快，却没有让试错结果更可靠，团队仍然可能反复做出无法复用的判断，所以后来又逐渐补上了 A/B 实验能力。到这里，系统解决的已经不仅是「更快把活动做出来」，还开始解决另一件更长期的事情：让一次业务尝试能够留下相对可信的结论，让下一次决策不必重新从头猜一遍。这几条能力不是同时做出来的，但并排放到一起，能看出一个共同的变化¹：

表 12-2　四条能力在过去与后来的对照

它们解决的是同一批问题，只是落进了不同的系统：

表 12-3　反复出现的业务问题与接住它的系统

把这些变化放在一起看，最后形成的就是这五组对应关系。如果只看后来形成的系统，很容易把它们画成几个熟悉的方框：标签和人群平台、CMS、精准营销平台、A/B 实验平台。站在最终架构图上，这几个名字没有什么特别，很多成熟业务都会有类似能力。但它们并不是在某一天开会时一次性设计出来的，页面反复定制，才让 CMS 变得必要；运营反复依赖数仓圈人，才让标签/人群需要被独立管理；人群、活动和资源位越来越多，冲突越来越频繁，才让投放关系和规则逐渐成型；当执行效率提升以后，实验结果仍然不够可靠，A/B 实验平台才顺势提上日程。

所以这一章真正想留下来的，并不是一张「标签平台+CMS+精准营销+A/B 实验」的架构图，而是一条产品经理看见架构的路径：从业务现场里看见角色和动作，从交接物里发现反复出现的东西，从异常和变化里看见对象之间隐藏的关系，再从不同需求里找到那些不会随着一次项目结束而消失的业务对象，最后让对象、关系、规则和责任进入系统。产品架构不是从系统模块开始的，它先回答业务里有什么，这些东西怎样发生关系，又应该按照什么规则一起运转，系统只是这些业务秩序最终留下来的形状。

图 12-3　看见架构的五个动作　从现场看见的东西，一步步变成系统要接住的对象。

闲言碎语#

做产品时间长了以后，人很容易对一些系统答案变得熟悉：看到活动反复定制，会想到配置化；看到运营总找数仓圈人，会想到标签和人群；看到不同业务争夺同一个入口，会想到投放和资源管理。经验当然能让判断更快，但它也有一个很隐蔽的风险：我们会越来越容易直接看见答案，却忘了答案为什么成立。

架构真正难的地方，不是会不会画一张完整的系统图，而是在业务还很具体、甚至有些混乱的时候，能不能看见其中正在形成的秩序。哪些东西只是这一次需求里的变化，哪些东西会在不同场景里反复出现；哪些关系过去还能靠人记着、靠代码写死，哪些一旦业务继续增长，就必须被系统表达出来。

架构的价值，不在于系统被分出了多少层，而在于业务是否因此变得更容易理解。它让一场活动不再只是代码里的几个页面，让一批用户不再只是离线表里的 ID，让一个首页弹窗不再只是前端里的一个入口，也让一次分流不再只是研发临时写下的一段判断逻辑。这些东西被看见、被说清楚以后，架构才开始有意义。因为产品经理真正要做的，从来不是给系统取几个漂亮的名字，而是让那些原本散落在业务现场里的东西，逐渐变得可理解、可管理，也能够继续生长。