最小可行产品（MVP） 不仅需要考虑产品的市场可行性，还需要考虑其技术可行性，以便随着时间的推移满足不断变化的需求。将构建最小可行架构（MVA） 纳入 MVP 开发可以帮助团队评估技术可行性，为产品提供更稳定的基础。MVA 关注的是 MVP 的可持续性和长期可行性，考虑产品开发如何在满足功能需求的同时最大限度地减少技术债务。本文将从MVA的概念定义、MVA的关键决策要素以及如何迭代开发MVA展开阐述。
结合使用现代的敏捷方法，产品必须能够根据反馈和需求的变化逐步迭代。但与很多原型不同，MVP 并不是一个一次性的概念。而这其中，就是 最小可行架构 （MVA）发挥重要作用的地方，帮助 产品开发 团队更高效评估 技术可行性 。
“最小可行产品”（MVP）的概念可以帮助团队专注于快速且高效地交付他们认为对客户最有价值的产品，这样他们就可以在投入大量时间和资源之前用最低的成本快速地评估产品的市场规模。简单地说，MVP 就是：
“产品的一个版本，只为早期的客户提供足够他们使用的功能，为未来的产品开发提出反馈意见。专注于发布 MVP 意味着开发者可以避免冗长和(最终)不必要的工作。相反，他们专注于迭代 MVP 版本并对反馈做出回应，以及挑战和验证有关产品需求的假设。”
MVP 的概念不仅适用于创业公司。每个应用程序都有一个可以被认为是 MVP 的初始版本。几乎每个组织都有这样的故事：他们如何花费数月或数年时间开发一个新系统，然后部署它，却发现它不能满足用户的需求。尽早发布 MVP 有助于避免在错误的需求上投入大量的时间、金钱和精力。
为了更好地理解 MVP 的目标，需要先考虑“可行”的含义。MVP 必须证明它能够以足够的数量为足够多的人提供价值，从而具备经济可行性。简而言之，它必须是有足够多的人去购买的东西，从而提供良好的投资回报。换句话说，你有一个足够大的问题，涉及足够多的人，而且解决这个问题是值得的。但经济可行性还有另一个方面：成本。成本必须是可负担的，而且它总的生命周期成本必须在产品期望的利润范围内。
1 什么是 最小可行架构（MVA）？
当人们使用术语“最小可行架构”(MVA)时，他们通常指的是以下其中之一：
一种包含最小组件集的设计。当团队主要关注于尽可能快实现 MVP 时， MVA 往往主要受功能需求而不是质量属性需求（QAR）的影响，因为后者可能还没有得到很好的理解和定义。他们的设计决策往往是比较偏实操性，比较落地的，因为速度是他们的主要关注点。他们通常认为如果 MVP 在持续迭代的过程中，MVA 需要被重新设计，并最终演变成一个成熟的产品。产品的可持续性并不是优先考虑的问题。构成 MVA 的组件可以来自商业云供应商提供的现成产品、低码或无码产品，或在现有的系统基础上做一些细小的变更。
这种方法的缺陷在于人们认为“解决方案的架构对客户不重要”。但客户确实关心解决方案的可持续性，架构对他们来说很重要。这种方法可能涉及对初始设计的重大重构，导致时间和精力的浪费，并可能产生重大的技术债务。将交付速度置于架构构建之前可能是正确的做法，特别是当团队无法提供有效的反馈闭环时。但是，团队应该愿意接受这样的可能性，即他们交付的大部分东西在以后可能需要进行大量的返工。
开发团队为解决方案所做的一些关于架构层面的决策。这个定义关注的是 MVP 的可持续性和长期可行性，考虑产品如何在满足功能需求的同时最大限度地减少技术债务。软件架构是由 QAR 驱动的，而不是由功能需求驱动的。这种 MVA 由一组最小的技术相关的决策组成，随着时间的推移，这些决策将通过经验来验证，并不断演化迭代。此外，还有一些额外的架构搭建实践帮助团队在开发产品时保持产品的架构可行性。
2 MVA 的关键决策要素
“怎样才算得上是关键”这个问题的答案取决于是否必须为了产品的可行性而做出架构调整的决策。如果做（或不做）出一个决策会影响产品的可行性和可持续性，或者如果改变决定需要付出高昂的金钱或时间成本，导致产品不经济、不切实际或不可能实现，那么这个要素必须作为构建 MVA 过程中的其中一个关键决策点。
这些决策包括产品将如何处理与产品/系统特征相关的 QAR，例如：
-
并发性——与并发的用户、传感器和其他设备的数量相关，产品需要承载对这些事件的响应。
-
吞吐量——产品在给定的时间段内必须处理的事务或数据量。
-
延迟和响应性——产品对事件做出响应的速度。
-
可扩展性——系统通过增加成本的方式来处理增加的工作负载的能力，一般呈近似线性的关系。
-
持续性——与产品必须存储和检索的数据的吞吐量和数据结构相关。通常涉及不同类型的数据存储技术的选型（例如 SQL DBMS, NoSQL DBMS 等）。
-
安全性——产品如何通过实现保密性、完整性和可用性，以此来保护自身免受未经授权的数据访问。
-
监控——对产品进行风险检测预警以及防控，让产品支持人员能够了解产品何时无法满足 QAR 并防止出现关键的系统问题
-
平台——产品如何满足与系统资源约束（如内存、存储、事件信号等）相关的 QAR。例如，实时和嵌入式产品（如电子表或自动制动系统）与基于云的信息系统有着截然不同的约束条件。
-
用户界面——产品为用户提供的交互方式。例如，虚拟现实界面与二维图形用户界面有完全不同的 QAR，而二维图形用户界面与命令行界面也有完全不同的 QAR。这些决策可能会影响上述的其他 QAR（GUI、VR、命令行或其他类型的界面）。
以上这并不是一个完整的清单，开发团队可能需要根据自己的 QAR 对这个清单的内容进行增减。
3 开发团队如何迭代产品的 MVA ？
与最终被丢弃的原型不同，开发团队会将最初的 MVA 纳入 MVP 的一部分，因为它是产品的第一个版本。通过一系列敏捷方法迭代（例如 Scrum 中 Sprint 冲刺）MVP 一样， MVA 也需要迭代。在任何时候，产品都应该满足已知的 QAR，这样就不会基于猜测和假设给产品增加负担，通过后续纳入新的QAR或者需求，以一种可持续的方式实现业务功能的持续交付。
我们可以从概念层面来描述这种方法：
团队最初只提供可以满足已知 QAR 的架构，快速构建出可供真正客户使用的可行产品。
然后，随着团队更多地了解客户的真正需求，他们不断地改进产品以满足额外的需求或需求变更（包括 QAR）。保持架构的灵活性是必要的，应用可持续架构的原则之一——“延迟设计决策，直到绝对有必要”——是实现这个目标的有效方法。
简而言之，随着团队对产品需求的了解越来越多，他们只构建最小可行的产品，只做出满足已知需求的绝对必要的架构决策。产品仍然是 MVP，架构仍然是支持 MVP 的 MVA。这么做的原因很简单：团队可能会花费大量的时间和精力实现产品的特性和 QAR，结果却发现客户并不认同他们的价值。相信什么是有价值的仅仅是一种假设，直到得到客户的验证，而这才是假设和实验发挥作用的地方。
所谓的假设，就是对某些尚未被证实（或被否定）的观察结果提出解释。从需求方面讲，它是一种信念，认为做了一件事将导致另一件事的发生，例如交付特性 X 将导致结果 Y。实验是用来证明或否定某些假设的。
每一个特性和需求（包括 QAR）实际上都代表了一个关于价值的假设。实证的目标之一是让这些假设变得明确，并有意识地设计实验对特性和需求的价值进行明确的测试。实际上团队不需要构建出完整的特性或需求来确定它是否有价值，他们只需要简单地构建最小可行产品和架构，就足以对能够证明其价值与否的关键假设进行验证。
对于 MVA，团队将在每次迭代（Sprint）中验证他们关于解决方案的假设，根据经验对其进行测试，然后根据了解到的东西做出决策。例如，Scrum 团队会通过对产品需求项进行排序来决定他们需要了解什么。产品需求项包括功能需求（比如特性和用户故事）和 QAR。
当团队在计划一个 Sprint 时，选取一些产品需求项作为 Sprint 的目标，这不仅是对产品能够为客户提供的价值的假设，也是对增量产品如何随着时间推移而持续迭代的假设。产品需求项（包括 QAR）的顺序将因此迫使团队聚焦关于价值和产品如何可持续交付价值的假设。
4 结论
MVP 不仅需要考虑产品的市场可行性，还需要考虑其 技术可行性 ，以便随着时间的推移满足不断变化的需求。MVP 并不局限于初创公司，因为每个应用程序都有一个可以被认为是 MVP 的初始版本。MVP 是 产品开发 策略的一个有用的组成部分。将 MVA 作为 MVP 的一部分可以帮助团队评估 技术可行性 ，并为产品提供一个稳定的基础，可以随着产品的演化迭代进行调整。架构决策透明化有助于组织更好地理解为什么做出某些选择，这有助于他们更好地做出关于如何使产品适应不断变化的市场条件和客户需求的决策。
作者简介：
Kurt Bittner 拥有超过 30 年短周期交付软件的经验。他帮助过许多采用敏捷软件交付实践的组织，包括大型银行、保险、制造和零售企业，以及大型政府机构。他曾为大型软件交付企业工作，包括甲骨文、惠普、IBM 和微软，并曾是 Forrester Research 公司的技术行业分析师。他的重点领域是帮助组织建立强大、自组织、高性能的团队，为客户交付受欢迎的解决方案。他撰写了 4 本与软件开发相关的书，包括“The Nexus Framework for Scaling Scrum”。他现居科罗拉多州博尔德市，并担任 Scrum.org 的企业解决方案副总裁。
Pierre Pureur 是一位经验丰富的软件架构师，拥有丰富的创新和应用程序开发背景、广泛的金融服务行业经验、广泛的咨询经验和全面的技术基础设施知识。他曾担任一家大型金融服务公司的首席企业架构师，领导大型架构团队，管理大型并发应用程序开发项目，指导创新计划，以及制定战略和业务计划。他是“Continuous Architecture in Practice: Scalable Software Architecture in the Age of Agility and DevOps”（2021 出版）和“Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”（2015 出版）的合著者，并发表了许多文章，以及在多个软件架构会议上发表相关演讲。
0 thoughts on “创新工具｜如何构建产品的最小可行架构（MVA）”
MVP 和 MVA 的概念相辅相成，都能够有效提升产品开发的效率
在构建 MVA 过程中，必须合理考虑关键决策要素，避免影响产品的可行性和可持续性。
MVP 和 MVA 的概念可以帮助团队尽早发布产品，避免在错误的需求上浪费时间和资源。
在产品开发中，必须要采用敏捷方法，并结合 MVA 来开展产品设计和开发。
MVA 对产品开发过程非常有帮助，能够有效评估技术可行性，减少后期返工和技术债务。
正确的做法是将交付速度置于架构构建之前，但团队也要愿意承担可能需要进行大量返工的风险
MVA 可以从两个方面考虑，一是快速迭代 MVP，一是确保产品的可持续性和长期可行性。
MVA 可以帮助团队更好地理解产品的需求和反馈，提升产品设计的效率。
不仅创业公司，在任何产品开发过程中都应该考虑使用 MVA，避免在错误的需求上浪费时间和资源。
MVA 中关键决策要素的选择需要合理考虑，不能只考虑功能需求而忽略产品的可持续性和长期可行性。
MVA 可以帮助团队减少所需技术和资源的投入，提升产品的市场竞争力。
MVA 的设计决策通常是比较偏实操性和落地的，但产品的可持续性也应该考虑。