理念冲突：在旧产品上构建新产品
编者按：业务增长的一个常见模式是从单一产品扩展到多个产品。有时，这可以在相对较小的干扰下实现，例如当产品高度不同并且可以完全并行开发时。然而，通常情况并非如此。本文总结和探索如何围绕企业最重要的目标协同好新旧产品和新旧团队。
随着一些公司同时提供多种产品，新产品和现有产品之间存在高度重叠。一种类型的重叠是新产品建立在现有产品提供的能力之上。当不同团队正在针对不同目标进行优化时，事情会变得十分微妙，最常见的矛盾是「速度」与「可靠性」。
负责开发新产品的团队通常希望能够快速行动，在寻求问题解决方案时尝试新产品和功能创意。他们几乎没有付费客户。因此，如果产品出现问题或不够完美，也不会有失去市场份额的风险。
相反，成熟的产品团队拥有一个成功的产品，拥有付费客户群。不断更换产品和实施半生不熟的功能对收入是有风险的。系统需要高度可靠，因为即使只是很短的平台停机时间也会冒犯忠诚的客户..
当开发新产品的团队想要快速行动，但他们依赖于对风险偏好更为谨慎的团队所拥有的现有产品进行定期更改时，如果没有发现这个微妙关系，其中一个或两个产品都可能会受到影响。
进化的本质
创新产品往往能催化未来新的创新产品。谷歌地图始于 2005 年，作为从 A 点到 B 点的桌面应用程序。从那时起，谷歌地图通过 API 向开发人员开放后成为许多其它创新产品的基础。
Uber 最初是一个叫车产品，但如今，Uber 的（订单）履行平台已被单独剥离出来运营并成为许多其它创新产品的基础，包括食品供应、杂货销售、包裹递送，甚至是第三方出租车公司。另外一面是，这些依赖 Uber 订单履行平台的新产品公司如果独立开发自己的（订单）履行平台，它们的效益将变低。
「标准组件的简单设计支持更高级别的复杂性。」
—— 西蒙·沃德利
在 Wardley Mapping Universe 中，Simon Wardley 使用气候模式描述了进化现象。两个特别相关的模式是：效率驱动进化、高层级系统创造新价值来源。
用 Wardley 的术语来说，谷歌地图非常高效，它可以作为高层级系统（例如基于地图的房产搜索）的基础组件，并提供新的服务价值，例如在地图上查看实时房产搜索结果。
（随着谷歌地图产品化和标准化，它同时也创造着新的价值。）
Wardley Mapping 还指出，当新旧产品之间存在依赖关系时会出现社会挑战的原因。在他的 Pioneers、Settlers, and Town Planners 模型中，Simon Wardley 解释了每个群体的不同心态。创新者们「让你感到惊奇，但他们失败的地方很多，他们造的东西过半不能正常使用，你不会相信他们建造的东西」，而拓荒者「可以把半成品变成对更多用户有用的东西」。
不是每个产品或创新将来都会成为催化更多创新的平台 , 但有一些产品是可以成为平台的。因此，每个企业为产品迭代并同时为其上游依赖平台做好充分准备是合乎逻辑的。
开发速度和可靠性工程
当新旧产品之间存在依赖关系时团队就会发生冲突不应该视为一种规律，即使他们理念上存在很大差异。造成紧张的主要原因之一是两个团队想要以不同的速度开发产品，他们也有不同的风险偏好。
如果两个团队都可以在不损害现有产品的可靠性的情况下以最大速度前进，那么风险就会小得多。想要两全其美（速度和可靠性）似乎是不现实的，但在过去十年中发展起来的软件工程行业能够保障「速度」和「可靠性」都可实现。
一个好的工程组织是可以可靠而快速迭代产品的，并不需要二选一。使团队快速开发产品的许多方法论与实现高可靠性系统的方法论相同：自动化、可观察性、测试和设计。
我曾与小型初创公司和大型企业合作过，他们的团队每天多次将公司最关键的系统部署到生产中。如果对工程能力和文化进行充分投资，任何组织都可以同时实现开发速度和可靠性。
对于想要在不损害现有产品可靠性的情况下快速开发新产品的多产品公司来说，投资在现代工程化实践是有巨大好处的。
重新思考领域、软件和团队边界
随着组织的发展，当初帮助过一个产品发展到某个规模的有效方法论可能成为发展到下一个目标规模的障碍。从单一产品到多个产品的转变中，产品和技术旧架构开始成为阻碍之一。
当新产品依赖现有产品时，通常可以通过重新思考领域、团队和软件边界来消除引起摩擦的依赖关系。一个典型的例子是，属于每个产品领域的某些组件集合在逻辑彼此紧密耦合，首先应该从逻辑上拆分它们。
使用从现有产品中提取的共享业务领域，两个团队可能能够以最佳速度协同前进。但事实并非总是如此，他们可能都需要改变共享业务领域，其中一些冲突会依然存在。
（两个产品，每个产品都拥有一个逻辑域，导致高协同变化）
当多个团队都在构建逻辑上属于同一领域的功能时，这并不总是很明显。通常需要一段时间才能出现。当新产品团队有充分的自由来构建他们需要的所有功能时，就会发生这种情况。
起初他们可能会构建不需要他们与其他团队交流协同的所有功能，从而隐藏着问题。如果再往前走一点，彼此的依赖关系开始呈现，并且更改通常需要同时更改两个产品的代码库。
我建议定期进行业务领域发现研讨会，以便识别隐藏的业务领域依赖或强耦合。
促进合作而不是竞争
当多个团队围绕不同的业务目标和成果而工作时，这对我来说总是一个警告信号，但产品之间积压的强依赖和强耦合意味着他们都不能 100% 控制自己未来需要输出的成果。
例如，如果 A 团队需要 B 团队做出改变，而 B 团队已经承担着各自独立的发展目标，那么 B 团队为什么要为了帮助 A 团队而牺牲自己的目标呢（并以某种方式受到惩罚）？
这是一个重要的领导力和战略问题。首先，必须清楚地阐明优先事项是什么。当时间和资源发生冲突时，新产品是否优先于现有产品？
领导者不能只是将过于雄心勃勃的目标推给多个团队，并在出现彼此依赖等困难时继续施加压力让团队继续交付。领导者需要明确优先级，并确保鼓励和奖励团队之间的协作，即使这意味着一个团队因为负责帮助其他团队而自己团队的目标没有达成。
优化目前或未来收入？
此外，根据我的经验，企业一般对现有正创造现金流的产品会存在有很强的偏爱。每当新旧产品团队之间竞争资源时间时，现有产品通常会赢，因为「他们正在给公司赚钱」。当新旧产品团队为争取资源投入而竞争时，这是人们自然默认的选择。
我认为这个默认的选择往往是短视的。一个颠覆性的新产品可以使你公司的总收入增加 5 倍，甚至比现在的确定的收入更重要。
如果领导层真正重视新产品，那么他们需要非常清楚他们准备在多大程度上平衡对新产品和现有产品的投资，尤其是当新旧产品存在彼此依赖或其他冲突、意味着你不能同时拥有两者的时候，你需要做出取舍。
更多产品，更多问题
成为一家多产品公司是令人兴奋的。它既是成功的标志，也是雄心壮志的标志。当然，商业模式、运营模式和战略都会变得更加复杂，尤其是在出现依赖和争夺有限资源的情况下。
为了让自己做最好的准备，我想不出比学习 Wardley Mapping 更好的方法了。了解产品发展框架和概念如何随着不同创新阶段而演变，以及一个组件的演变将如何影响其它组件，是帮助预测问题的有用技能。
我们要意识到，使小型单一产品公司成功的产品架构对于大型、多产品公司可能不是最佳的架构，这一点也很关键。「Event Storming / 事件风暴」和「Team Topologies / 团队拓扑图」能帮助您在这个领域重新思考它们彼此的界限。
即使拥有最好的战略和组织结构，也总会存在依赖关系。如果你将多个团队推向不同的方向并迫使他们相互竞争，那么领导层需要更清楚地确定优先事项，并围绕对企业发展而言最重要的事项来安排团队协作并做好激励。
