7年前在一次做生命周期模块化开发的一次方案架构会议上，当时项目团队提出了一个问题：

在确定需求输入的条件下，如何展开并行设计？如何评估不同方案的差异和针对细分市场的需求？

我感觉这是一个很好的话题，当时刚好我们在参考构型的管理思路，融入到常规装备产品开发中，因此这个问题又带给我们更多的启发，衍生另外相关的问题：

是否必须在确定构型项CI的情况下，才能展开DS的分析和重用？

两种类似的平台产品中，若出现部分系统一致，是否可以直接从构型顶层、构型项一块重用？

探索这些问题的IT落地方案其实是很有挑战的，当时我们团队请教了航空的构型专家，得到的结论是航空产品都是按照型号设计的，每一个型号都存在特性差异，几乎不会存在这种问题，因此不同型号的航空产品落地的系统都是独立的；但是老师给我们推荐了很多论文和图书，也鼓励我们自己去探索更符合行业诉求的解决方案。

既然依托于构型的管理诉求无法直接在我们的方案中重用，我们就来进行融合，当时就参考了MBSE针对产品开发实现的描述，细化在企业落地设计时的规范，推论如下：

产品设计其实是一个面向不同市场、不同用户市场，持续探索最优解决方案的过程，只要业务需求存在差异，一定就会出现差异的方案，针对任何需求的方案一定不止一种形式

当总体设计工程师或者系统工程师完成产品的顶层策划时，也仅仅是将需求收敛在特定的范围内，确保可通过固定的成本、时间、质量范围内交付的一组变量中的相对确定变量中，因此输出到功能设计任务书也是框架的约束和接口特性指标，并非完全定型的设计样式

若同一功能满足不同市场群体的需求，肯定存在差异，例如高成本高质量与降本的常规质量，例如针对某一特性增强输出和常规输出的需求，按照TRIZ中针对不同差异指标探索需求，可以使用裁剪法、功能导向搜索等工具进行差异化设计和创新，一定会出现解决方案的差异

我们组织了一次头脑风暴，例如输出条件是从北京到达上海，那么我们可以想象20+方法，但是若约束条件增加到1天，那么我们仍然有8种方法，若是继续限制成本必须在1000以下，那么仍有6种方法

所以实现方案是基于约束条件下的一种合理的解，必须在输入约束的情况下，解决方案采用价值；也就是说CI承载的就是设计约束和条件，DS就是针对CI要求的解决方案；重用是一种巧合而并非必然

从模块化隔离变更范围蔓延的思路出发，若两个相似的平台产品结构重用时，若直接从策划层进行重用，那么变更时范围肯定会蔓延；既然策划两个不同的平台产品，那么肯定从产品上下文的需求、功能和环境是存在比较大差异的，此时重用就会造成后期变更的复杂性

企业应该鼓励针对特性约束下更多可行方案的探索而不是求唯一值，这样就从单一产品开发演变成为面向平台的产品开发，也会面向更多市场需求有更多游刃有余的方案和能力(所有的实现方案都是功能输入的可选择项)

基于上述推论，和企业项目团队进行了多轮次的深入研讨和产品的推演，最终定义了可行的产品开发规范，也推动了企业单一产品开发与平台产品开发的兼容和融合，不仅在这个项目，也在后续的项目中，我们将这种思维模型应用在企业的超级BOM规划和选项设计的实现，丰富了超级配置BOM在选项规划的支撑的知识沉淀。

今年一次偶然的机会，和一位老师分享交流针对BOM架构规划和面向平台的设计经验时，老师感觉这种思路在产品开发中的应用场景很新颖，和老师目前擅长的规模化敏捷SAFe的一些理念有很多相似之处，给我推荐了一个名词“基于集合的设计，Set-Based Design”，当时使用百度搜索结果很不理想，当切换到bing.com时，突然感觉换了一片天地，搜索到了很对资料，并且发现了很多新颖的内容，可惜英文比较烂，阅读和学习非常慢，不过还是收获很多，有柳暗花明又一村的感觉，原来自己漫漫探索的，已经有这么成熟的成体系的理论。

Set-Based Design，多个场合的官方翻译是基于集合的设计（SBD），是一种面向复杂场景的支持冗余的设计方法，SBD建议针对输入的场景和约束，分析多组替代方案，而不是单个解决方案，通过以下方式实现稳健的系统设计(这部分参考SEBOK)：

考虑大量备选方案，探索更多可能的空间

在做出最终决策之前，确定更多可行性

使用从自己的角度进行设计并利用各自集合之间的交集来优化设计

使用SBD的设计方法，并不是每种情况下的最佳设计方法；但在SEBOK的建议中，如果项目包含以下属性，SBD在早期设计中尤其有用：

大量设计变量

设计变量之间的紧密耦合

冲突的要求

允许交易的需求灵活性

技术和设计问题未被充分理解–解决方案需要学习

我分析了SEBOK的资料，建议采用SBD作为系统设计和分析的概念，如上图所示包含5个不同的特征(优势)：

首先确定业务/任务需求和系统需求

在系统生命周期的探索、概念和开发阶段，始终使用业务/任务需求和系统需求执行设计和分析技术

尽可能同时进行设计和分析

利用可行性、性能和成本数据进行需求分析

通过使用集合考虑大量备选方案，并缓慢收敛到单点解

当然这部分理解起来很抽象，即使我翻译了不少对应的资料，其实也在不断理解到底在讲些什么内容，对企业产品开发到底有什么用途？我翻阅了SAFe的官方手册说明，也概览了《SAFe 4.0参考指南》这本书，期待有更完善的构思，但是看完SAFe的介绍后，倒是有一些不认同的看法——SAFe中基于集合的设计是一种在开发周期中的较长时间内，维持多种需求和设计可选项的实践；随着截止日期的临近，它使用经验数据聚焦于最终的设计选项上；通过这种方法，系统构建者可以假定可变性，并且保留可选项到开发的后期，从而为设计提供最大的灵活性，而不是早早就绑定一个最终的方案，如图示

但在参考一些案例时，一个团队可能正在开发一台新的数控机床，它有远高于现有模型的性能需求；提高操作速度的需求，对特定的组件是非常有现实意义的，所以，设计者可能选择模拟伺服电动机或步进电动机，步进电动机可以降低制造成本，但可能无法满足性能要求，在设计过程中将两个选项保持一段时间，有助于正确的经济权衡——这个可能是软件开发和硬件产品开发的差异吧，我推荐的方案是这种架构和方法支持企业面对特定功能和接口进行更多方案探索、面向不同细分市场的差异进行更多可选项增量开发，这样不就是一个可配置的超级BOM吗？至于是不是所有的可选择方案都保留，我的建议是留给市场去评判，通过对可选项的制造成本和市场收益的持续监控和分析，会留下更多更优秀的设计(后续计划安排BOM专题，说明设计选项模块如何在应用中持续监控)

在SEBOK中针对这种设计方法有比较多的篇幅说明，我认为是值得更深读一下的，因此保留了部分翻译内容，以下仅供参考。

SBD是一个社会技术过程，应该涉及多个团队的输入和交互，但下图为系统分析师提供了SBD交易空间探索过程。这八步过程对于执行早期设计特别有用

系统分析员首先分析业务/任务需求和系统需求，系统工程师使用这些信息以及他们自己开发的或系统和子系统团队提供的模型和仿真来开发综合模型；系统工程师包括使用该集成模型评估可行和不可行备选方案的需求；他们通过将每个设计决策视为一个统一（离散或连续）的随机变量来探索贸易空间；备选方案由每个设计决策中的一个选项组成，然后，系统工程师使用集成模型评估每个备选方案并创建可行的权衡空间

蒙特卡罗模拟是一种能够及时创建和评估备选方案的方法，所创建的权衡空间将由基于需求的不可行和可行的替代方案以及任何基于物理的性能模型和仿真组成，系统工程师应与适当的利益相关者合作，以便在交易空间产生数量极少或没有可行的替代方案时通知需求

除可行性外，系统工程师还应使用描述性统计、其他分析和数据分析技术分析每个设计决策，这些信息提供了对每个设计因素如何影响可行贸易空间的见解。一旦交易空间包含可接受数量的备选方案，就可以按集合对其进行分类。这是SBD的重要组成部分，如果设置驱动因素或设计因素未知，系统工程师应查看每个设计决策的权衡空间以获得见解

系统工程师应使用优势分析和其他优化方法，根据有效性度量，找到最佳或接近最佳的备选方案，系统工程师应探索剩余的集合，以获得关于可行贸易空间和需求的更多见解

此过程的最后一部分是选择一个或多个集合移至下一个设计阶段，应注意，该过程包含循环

在这个过程的任何部分，系统工程师都应该使用可用的信息，例如来自贸易空间探索或集合评估的信息，以通知需求分析或更新集成模型。此外，系统工程师应在可用时使用更高保真度的模型和仿真更新集成模型。关键是在“正确”的时间从“正确”人那里获得“正确”信息。