考虑事项、动机和最佳实践

在了解设计产品变体的需求之后，管理变体的最佳方法对于产品发展的长期成败起着关键作用。变体管理决定着如何组织特性变体、如何将其融入产品。通常情况下，新产品开发项目最初并不会为未来可能出现的变体制定规划。在这篇文章中，Joanne Scouler 和 Marty Bakal 将介绍如何开始设计变体。他们以 Eaton 公司为重型混合动力汽车开发变速箱变体的经历为例，展示了自己的观点。作者还介绍了各种 Rational 软件产品在此过程中起到的协作作用。

简介

为了解何时以及如何设计产品变体，应注意观察产品之间的差异。举例来说，两种不同的卡车型号可能存在十几种或者更多的不同特性。

通常情况下，有时由于企业对新产品的市场经验不足，企业最初并没有设计变体。产品开发团队在最初开发产品时，往往以特定客户或用例为目标。随着逐渐开始收集到关于产品的客户反馈，对初始产品的多种变体的需要也开始出现。如果产品变体未能得到有效开发，那么由于存在重复性的工作，同时维护和改进多个产品版本的任务将会变得低效而又耗时。
与从最初起便考虑到产品变体相比，跨多种产品单独维护类似的软件代码会占用更多的开发资源。如果造成各变体存在不必要的重复性工作，最终您将无法足够迅速地响应客户对于变体的新需求。正因如此，囊括变体管理的新型产品开发流程已成为必然趋势。

识别产品变体需求

变体的设计取决于产品的市场成熟度，以及对于客户使用产品的意愿的认知。在公司推出新技术时，最困难的环节莫过于确定客户将如何利用这种新技术。现有客户并不确定他们需要怎样的更改。由于市场存在不确定性，因此工作重点在于让产品走出企业大门，了解变体的具体表现，而不是构建 “产品组合” 或设计变体。

在一项产品取得成功之后，企业将会获得充分的市场情报，对于市场真正需要哪些产品变体的认知也会逐渐明确。举例来说，Eaton 公司汽车集团的系统工程设计经理 Craig Jacobs 表示，他们利用 “克隆自有产品” 的方式制造出第一款中型混合动力汽车变速箱的变体，如图 1 所示。他们首先制作了第一款产品的副本，然后在此基础上进行了修改。当时，他们尚未意识到公司需要完整的变体管理流程。采用部分新组件和软件的新设计满足了客户的需求。此后，Eaton 公司分别维护这两种产品。

然而，在对其中一款变体产品进行改进时，他们还需要将改进复制到第二款变体产品之中。这种方法并不像真正的重用那样高效，因为重用可以将一种变体中的 bug 补丁等修改自动包含到第二种变体中。随着必要变体数量的增加，克隆自有产品这种方法的效率低下之处也日渐明显。

图 1. Eaton 设计的卡车零部件

同一家企业的基本混合动力变速箱系统架构或许在全球各地都是相同的，但每一位客户都需要获得连接不同发动机的灵活性。这些发动机的电动马达有着不同的额定功率，电池容量也各有不同。不同汽车市场的客户还需要增加或减少辅助电气设备，例如交流电源、加热设备、动力转向装置等。

其他行业在构建变体时的原因也大同小异。开发变体要求确定产品行为、将行为细分为特性，并对特性加以改进。随后，可以根据设计规则开发变体。如果在最初设计系统时便考虑到了变体，那么可以合理地预测变体出现的时机。这种方法可以非常简单，比如构建清晰的界面；也可以非常复杂，比如将工件标记为可能需要变体的潜在位置（变体点）。

开发一个变体管理业务战略

在从开发单一产品过渡到变体管理的过程中，企业要经历一系列可以预见的步骤。典型情况下，如果对变体的要求开始超出企业处理请求的能力，那么就应该转而采用另一种设计管理战略。变体要求的形式多种多样，可能表现为客户的新需求和新行为，也可能表现为新市场的新供应商。在为客户提供支持的同时从一种设计管理战略过渡到另一种战略是一项重大决策。管理层或许会对这样重大的变革产生消极的看法。

为了构建良好的业务用例，请考虑以下因素：

上市时间和资源可用性

如果机会窗口 (opportunity window) 较小，而且可用资源有限，那么您或许根本不希望设计变体。相比之下，如果您能将范围缩小为单独一种变体，控制将会更加容易。

市场认识

您是否确信市场能接纳您的产品？ 如果回答是否定的，则不应在变体设计方面投入更多的资源。

全球化的野心

几乎每一个国家/地区都有着独特的规则和法规。 如果您计划进军本土市场以外的地区，那么您或许需要产品变体。

产品成熟度

如果您的产品多年未有发展，那么或许现在就需要随着产品的成熟进行产品的多样化和改造。

客户行为

您是否属于拥有诸多需要不同最终产品的客户的子系统供应商？如果是，那么设计变体或许对您有益。

通过变体管理提高效率

企业过渡到变体管理方法以加速上市时间，降低维护成本。在系统工程设计工作流中利用 IBM? Rational? Rhapsody? 建模软件设计重用、构想产品线变体有益于提高效率。Rhapsody 可帮助您分析和验证需求，迅速进行设计原型，并利用系统建模语言 (SysML) 和统一建模语言 (UML) 迅速交付更加一致的应用程序。这种方法能帮助您为 OEM 和新组件供应商轻松设计变体集成。举例来说，对于混合动力发动机的供应商，必须在假设物理参数必将有所变化的前提下编写组件连接规范。组件和系统软件的设计具备校准能力，支持高效扩展产品线。系统功能的设计支持轻松启用或禁用。

图 2. 针对特定变体的 Rhapsody 组件图

在 Rhapsody 中，您可以对模型元素应用版型 (stereotype) 和标签，指明该元素如何针对变体而变化。利用这种方法，可以更明确地解释特定产品变体。版型和标签可以控制将要整合到嵌入式设备中的最终软件的代码生成。

工程师选择在 Rhapsody 中显示变体结构的抽象级别。这种设计哲学支持迅速将新的客户需求和行为集成到系统之中。混合设计小组可以更高效地支持数十种不同的客户、应用程序和地区需求。

汽车企业中的常用解决方案就是通过配置文件，在运行时将恰当的变体载入代码。一个主软件文件包含所有必要的代码，但配置文件决定了对各变体使用哪些代码或哪组校准刻度。仅使用一个可执行文件的原因在于减小体积、节约可用内存，简化将文件分发给企业不同办公地点的过程。

与加载时战略相结合，可使用 Rational? ClearCase?配置管理软件将代码变体作为树结构的独立分支签入。利用 ClearCase，您可以轻松合并分支变体。汽车企业可以将地区需求并入全球需求，还可以启用和停用变体，如图 3 所示。他们可以创建变体，随后将变体并入可交付成果中。ClearCase 支持不同软件代码流的视图。工程师可以专注于自己的视图，因此可以集中精力处理他所负责的特定变体。

图 3. ClearCase 视图显示产品分叉随后再次合并的情况

部署软件代码中的变体

可以在开发流程中的多个时间点将软件代码内的变体部署到产品中：

1.在代码生成时。Rational Rhapsody 可以根据为特定产品选择的变体而生成代码。这样的代码特定于产品，不含针对其他变体的代码，因此读取速度更快。

2.在构建时。使用下面这些构建时选项：

a.编译器指令，例如 #ifdef

b.一个构建版本包含另一个构建版本的不同子项的集成

3.在运行时（通常是在初始化的时候）。在初始化时，产品配置文件将载入应用程序，使应用程序仅使用指定的变体。
如果代码数量较多，则应采用构建时部署的方法。然而，构建时变体可能难以管理。举例来说，Eaton 公司过去就采用过这种方法，但他们发现开销过高；尤其在管理大量构建版本时，确保对正确的硬件变体使用正确的构建版本的开销非常之高。高昂的开销与发布软件、发布零部件编号以及在组织范围内转移流程密切相关。Eaton 公司的代码数量较少，没有严格的内存约束，而且需要迅速上市，因此该公司放弃了这种方法。但是，医疗设备制造商和其他行业必须使用构建时部署，以符合法规或处理器内存约束。

避免常见的实现问题

在开发变体时，一种典型的挑战就是克服普遍存在的组织和文化思维定势。很多项目都显现出过渡到变体管理的明确需求，但当前工作负载 “没有足够的时间”。产品经理认同以下观点：从理论上来讲，这确实是一种合理的做法，但他们希望团队能在其手头的项目完成之后再开展变体管理工作。产品经理往往认为，过渡到变体管理周期必然会造成延误，而且他们对失去其个别项目的控制权存在抵触情绪。

在组织最终决定采用变体管理战略后，会存在一段情绪不安和项目延误的时期。无论过渡决策是否正确，过渡开始初期，组织中都会存在不确定和抵触情绪。在过渡到强大的变体管理流程之后，组织可以享有更快的上市时间、更高质量的产品和更高效的工程师。产品线经理将倍感满意，因为他们的计划和资源的可预测性将得到提升。客户满意度也会提升，因为他们能获得更高的品质和更快的响应时间。

在回顾过渡项目时，Craig Jacobs 一直在赞叹他们能在开发流程的早期顺利建立变体设计方法。否则，他们就需要更长的时间将第一款系统推向市场，而且完全可能会错失商机。一种可行的折中方案是在初期对部分设计采用所需工作量极少的变体最佳实践。这种方法能让后续构建多种变体更加轻松。

为确定变体管理业务战略，您应该回答以下几个问题：

1.在初始设计阶段，您能否执行一些 “简单” 的工作，以便在后续产品发生演进时支持产品变体？

2.如何在不增加过多成本的前提下，从最初起便创建灵活的设计？

3.您是否会在初期导致设计 “过于灵活”，从而造成成本过高？这样的错误会妨碍您实现产品组合的收益。

产品变体设计最佳实践

下面给出了产品变体设计的主要最佳实践：

1.从最初起便设计良好、整洁的界面。

2.采用良好的组件化方法。

3.创建数据变量，而非硬编码的常量。

如果从最初起就能遵循这些实践，那么在出现变体需求时就能更轻松地做出调整。如果能遵循这些实践，您就可以在稍后为一个元素添加标签，将该元素映射到特定设计特性。随后，确定使用哪种开发流程后，您就可以轻松地完成实现工作。如果没有良好的设计，这将成为一项无比艰难的工作。

除了 Rational Rhapsody 和 ClearCase 之外，您还可以使用其他 IBM 工具来管理变体。每种工具都支持重用的不同方面，因此需要不同的管理方法。例如，Rational? DOORS? 需求管理软件在一定程度上可通过基准和基准集支持多个版本，但该产品不支持需求变体或需求重用。因此，要在 DOORS 中管理变体，则需要使用克隆自有产品的方法。如果将 IBM? Rational? Engineering Lifecycle Manager 与 DOORS 配合使用，那么可以将变体彼此相连，并链接到相关产品。
Rational Engineering Lifecycle Manager 还能帮助您管理变体。您可以在产品定义中定义产品线和变体，并将这些产品定义链接到您的需求、设计、模型元素、测试用例和其他工程设计工件。

结束语

无论您采用什么样的方式设计变体，都需要付出比设计独立产品更多的努力，但从长远角度来看，变体设计往往是最有效的做法。决定何时、为何以及如何设计变体能帮助您管理产品组合，确保您的产品能够更好地与客户的长期需求协调一致。