一家中型银行有三款核心应用：贷款发放系统、账户服务平台和分行运营系统，它们为国内市场服务了十多年——通过多年的逐步修复，不断打补丁、扩展和勉强维持，它们能运行，但只是勉强维持。
这里有一个更深层次的问题，却无人提及：业务领导层看到的是三款应用，但他们没有看到的是，每款应用中都隐藏着独特的产品功能，而这些功能从未被视为独立的产品。贷款发放系统不仅仅处理贷款业务——信用决策、定价、文件生成、合规流程和客户身份验证都紧密耦合在其中。账户服务平台将交易处理、费用管理、纠纷处理、对账单和监管报告等功能纠缠在一起。分行系统将客户入职、关系管理和产品交叉销售逻辑作为功能嵌入其中，而非将其视为独立的产品。
从来没有人划分过这些功能之间的界限，因为他们不需要这么做。对于单一国家来说，这些功能都运行得足够好。
然后，领导层宣布：“我们要走向全球。”
于是，最初设计中所有预设的前提——单一货币、单一监管制度、单一支付体系——都需要重新思考。现有产品必须继续运行并针对国内客户进行改进，同时平台要为新市场进行迭代。有些功能是基础性的，必须首先实现，因为其他一切都依赖于它们——比如多币种分类账、支持特定司法管辖区“了解你的客户”(KYC)和反洗钱(AML)规则的合规引擎。其他功能，如本地化国内客户体验或为新市场设计监管报告框架，可以并行构建。还有一些功能，如在新市场开设账户或与当地支付网络集成，则要等到基础层准备好后才能进行。
顺序至关重要，搞错了顺序就意味着数月的工程努力付诸东流——团队构建的功能无法运行，因为其依赖的基础功能尚未实现。
如果这听起来似曾相识，那就对了。把“银行”换成“保险公司”“医疗平台”或“物流供应商”，模式依然成立。一款为特定场景开发的产品，经过多次修补，现在被要求扩展到超出其最初设计范围。技术有所不同，但组织面临的挑战却如出一辙。
这时，四个不同的领域必须明确分工——产品管理、技术架构、项目管理和发布管理，每个领域回答的是根本不同的问题，每个领域都需要不同的专业知识。根据我在企业环境中的经验，这正是大多数组织陷入困境的地方。不是因为他们缺乏人才，而是因为这些领域被混淆了，没有明确定义，或者被那些本不应负责的人默默承担了。
4个领域，4个不同的问题
当组织将这些领域视为可相互替代时——或者更糟的是，认为一个人或一个团队可以同时负责所有领域时，混乱就开始了，他们做不到，每个领域的存在都是因为它回答了一个其他领域无法回答的问题。
• 产品管理回答：我们在为谁构建什么，以及为什么构建?在我们的银行案例中，这意味着决定首先进入哪些市场，从整体系统中提取哪些产品功能进行重建或扩展，以及德国客户与美国客户的需求有何不同。产品管理负责制定愿景、指导决策的原则以及将愿景转化为优先事项的战略。没有它，其他所有领域都在猜测。
• 技术架构回答：我们如何构建，以满足业务所需的质量属性?这就是将可扩展性、合规性、性能和可维护性转化为结构决策的地方。在我们的例子中，架构师确定多币种分类账是基础性的，必须首先构建，数据驻留限制要求进行特定区域的部署，整体系统需要沿着产品边界而非应用边界进行分解。架构定义了技术上可行的是什么，存在哪些限制，以及技术依赖关系要求什么顺序。
• 项目管理回答：我们如何协调团队、依赖关系和限制条件以实现交付?项目经理根据产品优先事项和架构限制，规划关键路径。在银行场景中，这意味着确定合规引擎团队和分类账团队处于关键路径上，其他三个团队在这些基础功能落地前无法开展工作，而两个工作流可以并行进行。项目管理负责协调——安排工作顺序、管理跨团队依赖关系、揭示风险并确保所有人都按照同一时间表工作。
• 发布管理回答：每个功能何时以及如何安全地投入生产?这与项目管理不同。在全球扩张中，发布管理规划分阶段的市场推广，管理因司法管辖区而异的监管审批关卡，定义当某个版本在一个地区运行但在另一个地区不符合合规要求时的回滚策略，并协调多个部署目标的环境策略。发布管理是确保构建的内容能够到达客户手中，同时不会破坏现有功能的领域。
这四个领域形成了一条链，产品管理定义了“是什么”和“为什么”，架构将其转化为“如何做”，项目管理协调“何时”以及“以什么顺序”，发布管理执行交付，去掉任何一个环节，链条就会断裂。
当界限模糊时会发生什么
回到我们的银行案例。领导层已经宣布了全球扩张。愿景在最高层很明确——走向全球，但产品管理没有定义首先进入哪些市场——是因为市场规模而选择德国，还是因为监管准入容易而选择新加坡?它没有明确哪些产品功能应优先处理——银行是应该以具有最高收入潜力的贷款业务为先导，还是以其他一切业务的前提——账户开设为先导?而且没有人解决国内体验如何随着扩张而演变的问题——现有的美国客户是获得一个共享新全球架构的重新设计平台，还是国内产品保持不变，而所有投资都投向新市场?
大家充满干劲和雄心，但没有产品战略来引导。
这就是混乱的开始。
技术架构师在缺乏产品方向的情况下，开始做出不属于他们职责范围的决策。在不知道首先进入哪些市场的情况下，团队构建了一个完全抽象的集成层，能够连接到全球任何支付网络，而第一波扩张只需要支持两个欧洲市场。在不知道哪些产品功能应优先处理的情况下，架构师开始同时分解三个整体系统——贷款、发放和服务，将团队分散在并行的工作中，而明确的产品优先事项本可以让他们一次专注于一个分解任务。在不知道国内体验是否会与新的全球平台融合还是保持独立的情况下，他们通过设计一个多租户架构来应对，该架构可以支持两种模式——在明确的产品方向本可以完全消除一种路径的情况下，使每个设计决策的复杂性加倍。
这些并不是孤立的糟糕工程决策——它们是对缺乏产品明确性的合理反应，但它们导致了一个过度工程化的基础，交付时间延长了一倍，并延误了下游的所有工作。
当产品管理确实存在但却碎片化时，问题会进一步加深。银行有多个产品经理——一个负责贷款，一个负责账户开设，一个负责服务，一个负责支付，每个人都坚信他们的产品功能是优先事项。贷款产品经理推动首先进行贷款业务，因为其对收入有影响。账户开设产品经理争辩说，没有账户开设，贷款业务就无法运行。服务产品经理坚持认为，在没有服务到位的情况下推出发放业务，意味着引入银行无法支持的客户。每个人在自己的范围内都是正确的——但没有人拥有决定顺序的跨产品视角，而且，还有一个没有人愿意承担的限制条件：这些产品功能目前正在为国内客户运行，任何重构或分解都必须在不破坏现有功能的情况下进行，这些依赖关系不仅仅是技术性的——它们是涉及真实客户的实时业务运营。
与此同时，项目管理在还没有编写一行代码之前就看到时间表在拖延。由于缺乏明确的产品优先事项，项目经理通过根据他们可以控制的因素来做出市场顺序决策来填补空白——团队可用性、现有供应商关系、哪些团队有能力。第一个市场变成了最容易配备人员的市场，而不是具有最高战略价值的市场。顺序现在由运营便利性而非产品战略驱动。本意是好的，但视角错了。
另一方面，当领导层推动速度时，架构被完全绕过。“只要让它在德国运行”成为了指令。团队没有等待架构师正在设计的分解平台，而是克隆了国内代码库，将德国特定的费用结构和服务规则直接硬编码到应用逻辑中，并建立了一个单独的数据库实例，在原始模式上添加了特定地区的列，这在德国可行，但当第二个市场推出时，没有任何东西可以重用——费用逻辑无法替换，服务规则无法重新配置，模式无法扩展，组织现在有两个分叉的代码库需要维护，而不是一个可扩展的平台。
那么发布管理呢?它被简化为部署，没有人考虑到欧盟的监管审批周期比国内发布周期长数周，没有人定义如果一个版本在一个市场通过验证但在另一个市场失败会发生什么。新市场的第一次生产事故让所有人都措手不及——不是因为团队无能，而是因为本应预见这一问题的领域从未被赋予发言权。
这些失败都不是由于缺乏人才，在这个场景中的每个人都在其实际角色中表现出色，架构师是一位出色的架构师，项目经理是一位经验丰富的协调员。问题是，每个人都被拉入了他们本不应扮演的角色，用他们最好的判断填补空白，但却没有该角色所需的专业知识。架构师做出产品优先事项决策时，会优化技术优雅性而非市场适应性。项目经理做出市场顺序决策时，会优化执行效率而非战略价值。决策做出了，但存在盲点，随着时间的推移会不断累积。
功能失调和沉默的代价
上面描述的混乱不仅仅是一种组织不便，它对业务和内部人员都有可衡量的代价。
当缺乏产品方向而架构师过度工程化以补偿时，代价表现为上市时间延迟。银行的竞争对手进入新市场，而工程团队仍在为可能永远不会出现的市场构建抽象。当项目管理根据团队可用性而非战略价值安排工作时，代价表现为浪费的努力——整个团队交付的功能无法使用，因为它们所依赖的基础功能被降低了优先级。当以速度的名义绕过架构时，代价会在数月后显现为返工。那个让第一个市场上线的克隆代码库?现在需要在第二个市场推出之前进行解耦和重新构建，捷径并没有节省时间，它只是借用了时间。
这些代价会累积，在错误的领域做出的每一个决策都会产生下游后果，而正确的领域本可以预见这些后果，架构师本会知道克隆代码库无法扩展，产品经理本会知道第三个市场比第一个市场具有更高的战略价值，项目经理本会指出没有人计划到的依赖关系，发布经理本会将监管审批时间纳入时间表，组织中存在这些知识——只是在做出决策时它不在现场。
然后是沉默的代价。
在许多组织中，最深刻地感受到这些领域缺失的人往往是最没有权力要求它们的人。一位需要产品方向但未得到的工程师会默默地做出假设，而不是升级问题——因为升级问题感觉像是在承认自己无法胜任工作。一位看到基础性问题但保持沉默的架构师，因为“那是产品决策，不是我来做”。一位围绕未定义的范围构建时间表并希望后来能澄清的项目经理，因为提出模糊性感觉像是在减缓团队速度。
随着时间的推移，这种沉默成为了一种文化。人们不再要求他们需要的东西，而是开始围绕其缺失开展工作。他们自己填补空白——不是因为他们想这么做，而是因为工作必须向前推进。于是，架构师成为了兼职的产品战略家，项目经理成为了兼职的架构师，工程师成为了兼职的万事通。空白被填补了，但由在其专业知识之外操作的人填补，每次决策都会累积盲点。
对人的影响是真实的，填补这些空白的人往往是组织中最有能力、最投入的人，他们因为关心而努力，但随着时间的推移，不断的填补空白会导致疲劳、沮丧，并最终导致脱离。有些人会筋疲力尽，其他人则停止努力，开始按部就班地工作——因反复解决本不应由他们解决的问题而产生的习得性无助，还有些人则简单地授权并离开，不是出于冷漠，而是出于承担责任却没有权力的疲惫。
这不是一个关于坏人或不良意图的故事，这是一个关于结构性问题表现为个人痛苦的故事。
正确做法：明确责任分工的协作
解决办法不是增加更多流程，而是消除对谁负责什么的混淆——然后养成要求你需要的东西的习惯，而不是默默地填补空白。
这从产品管理开始，在我们的银行案例中，这意味着有人明确负责回答以下问题：首先进入哪些市场以及为什么?从整体系统中提取哪些产品功能以及以什么优先级?德国客户需要什么而国内客户不需要?每个市场的最小可行产品是什么?这些问题不能推迟或委托给架构或工程，它们是产品决策，在做出这些决策之前，其他所有下游领域都在使用不完整的信息工作。当多个产品经理各自负责产品组合的一部分——贷款、发放、服务、支付时，必须有人负责跨产品优先事项。这意味着解决依赖关系：发放先于贷款，服务与发放并行，支付在适当的时候集成。如果没有产品层面的这种顺序安排，项目管理将试图协调尚未确定优先级的工作，而架构将针对一个没有人界定范围进行设计。
但产品管理设定方向只是等式的一半，该方向必须转化为工程团队可以构建的工作。在大多数组织中，这种转化是产品负责人的责任——他们接受产品战略，并将其分解为精炼的待办事项列表、史诗任务和用户故事，并附有明确的验收标准。当这种转化没有发生时，工程团队只能盯着一个高水平的产品愿景，没有可行的前进路径。他们无法估算，无法安排自己的工作顺序，无法尽早识别技术风险以减轻风险。从外部看，结果看起来像是无所作为，但从内部看，则是瘫痪——团队想要交付，但没有足够的定义来开始。产品管理可以设定正确的方向，架构可以定义正确的结构，但如果产品负责人没有按照工程所需的水平来细化和定义工作，交付管道在开始之前就会停滞。
一旦产品方向存在并被转化为可行的工作，架构就可以做它该做的事——将该方向转化为技术决策。如果产品管理说：“首先进入德国和法国，将账户开设和服务作为优先功能”，架构师现在可以做出有界的决策：必须到位哪些基础组件，如何分解整体系统的相关部分，哪些可以重用，哪些需要重建。架构停止猜测，开始变得有目的性。架构师还向产品反馈——揭示影响可行性的技术限制，识别影响顺序的依赖关系，并指出产品假设在与现有代码库接触时无法成立的地方，这个反馈循环至关重要，没有架构现实检查的产品方向会导致在幻灯片上看起来很好的路线图，但在执行时却分崩离析。
项目管理根据产品优先事项和架构限制构建执行计划，项目经理绘制哪些团队处于关键路径上，哪些工作流可以并行进行，跨团队交接在哪里产生风险，以及哪些决策阻碍了进展。在我们的例子中，项目经理确定分类账团队和集成层团队是账户开设的顺序依赖项——而服务团队可以开始并行设计其分解，项目管理不做产品决策或架构决策，它协调已经做出的决策，安排工作顺序，并尽早揭示风险以便采取行动。
发布管理根据执行计划确保安全交付，在全球扩张中，这意味着规划分阶段的市场推广——不仅仅是部署代码，还要在到达客户之前验证每个发布满足市场特定要求，它意味着定义当一个发布在一个市场有效但在另一个市场遇到问题时会发生什么，它意味着协调环境策略，按地区管理功能切换，并制定考虑到在一个市场回滚不会破坏另一个市场的回滚计划。发布管理是弥合“它在我们环境中有效”和“它对我们客户有效”之间差距的领域。
关键在于，这些领域是协作的，而不是孤立的。架构向产品提供关于技术可行性的信息，项目管理向产品和架构反馈风险，发布管理将生产中的学习反馈给上游，信息是双向流动的，但责任不是。产品管理负责“是什么”和“为什么”，架构负责“如何做”，项目管理负责协调，发布管理负责交付，当这些责任明确时，人们停止填补他们不应该填补的空白，并开始要求他们需要做好自己工作的输入。
这种转变不是关于层级或指责，它是关于给每个领域提供清晰度以使其发挥最佳作用——并在缺乏这种清晰度时给予他们拒绝的权力。
目标？让不可见的变得可见
产品管理、技术架构、项目管理和发布管理不是可相互替代的，它们不是同一工作的不同标签，它们是独特的领域，每个领域都有自己的专业知识、自己的责任和自己在构建和交付复杂产品中的贡献。
本文中的银行案例是具体的，但模式是普遍的。任何将产品扩展到超出其最初设计范围的组织——无论是全球扩张、现代化遗留平台还是将整体系统分解为产品——都会达到同一个转折点。这里描述的领域要么明确出现，要么不出现。当它们出现时，团队会带着目的前进。当它们不出现时，有才能的人会消耗精力来补偿结构性混乱。
目标不是增加官僚主义，而是让不可见的变得可见。命名这些领域，定义谁负责每个领域。让人们可以安全地说：“在做出这个架构决策之前，我需要产品方向”或“在构建这个时间表之前，我需要架构限制”。当人们停止默默地填补空白并开始公开要求他们需要的东西时，系统就会开始自我纠正。
这四个领域不是开销，它们是交付的操作系统，而且就像任何操作系统一样，当每个组件都做好自己的工作并远离其他组件时，它们才能发挥最佳作用。
