避免对 MVA 过度投资：MVA 必须对 MVP 当前面临的挑战作出回应，同时预测（但不是实际解决）MVP 未来将要面对的挑战。

　　如果 MVP 不成功，MVA 就是白费力气，但如果 MVP 成功，MVA 对产品的良性进化就非常重要了。

　　MVP 和 MVA 就像两个绑在一根绳子上的登山者一样。MVP 带头前进，但不能领先太多，否则 MVA 会拖它的后腿。

　　MVA 领先 MVP 太远也是没有意义的，因为与 MVP 价值相关的反馈可能会让创建 MVA 的决策失去意义。

　　在初始版本的开发过程中，MVA 需要基于一些可能不正确的假设，因此可能会发生一些过度投资，但一旦反馈循环发挥作用，这种情况就会得到纠正。

　　当 MVP 根据反馈而演变时必须重新审视与之对应的 MVA，为一个应用程序创建的架构被另一个应用程序复用时更要这样做。不同的应用程序支持不同的 MVP，因此可以满足不同的要求。

　　在之前的一系列文章中，我们介绍了一个称为最小可行架构（MVA）的概念。MVA 是对最小可行产品（MVP）的架构补充。MVA 的目的是确保 MVP 在技术上可行、可持续且可随着时间的推移而扩展，是 MVP 的平衡产物；它让 MVP 不至于沦为一次性的概念验证，使得 MVP 成为新产品的种子。

　　我们在敏捷环境中扩展了 MVP 的概念，将每个新产品版本都视为一个新的 MVP，其通过新增的，为客户服务的成果扩展了之前的 MVP。与 MVP 对应的 MVA 的发展应当足以支持 MVP 的增量改进。通过这种方式，产品及其相关的软件架构都能通过一系列增量改进的方式发展下去。这种共同进化过程如图 1 所示。

　　所有这一切听起来都很不错，但我们也得提出一些基础性的问题，例如什么是“最小值”，以及我们如何知道什么状态是最小？类似地，什么才是“可行”的？

　　很多时候我们并不会花费大量时间或精力来寻找上述答案。团队被要求快速交付“新”产品（也称为 MVP），旨在刺激更多客户需求，并且他们会做一些技术架构工作（MVA）以将 MVP 发展为可发布的版本。

　　在这里，MVP 及其对应的 MVA 都是根据时间和资源限制来定义的，而不是基于对尚不能满足客户需求的产品成果的审慎分析来定义。

　　产品是向客户交付成果的工具。产品的最小增量提供了单一的改进成果。每个版本都必须向产品的某些用户组提供至少一个改进成果。如果它不能改善至少一个成果，那么就不值得发布。如果它提供了不止一种改进成果，那么它可能就不是“最小的”。因此，最小的 MVP 应该恰好为一组用户提供了一种改进成果。

　　如果一个产品版本为产品的不同用户组改进了多个成果，那么产品开发组织就失去了更频繁地发布较小增量，以收集有关产品版本有效性反馈的机会。

　　在考虑某个产品增量是否是最小时，我们要牢记作者 Antoine de Saint-Exupéry 的一个观察结果：

　　很多团队都倾向于在版本中“再加一点就好”，但如果尊重“单一成果原则”，相比为了加这一点而延迟发布时间的做法，团队可以更快地交付价值并更快地获得反馈。

　　这里我们强调的是使用成果而不是产品功能的价值来明确讨论范围。如果你的 MVP 不是用成果来衡量的，那么想要明确范围就会更困难，因为我们很难看出哪些功能需要改善产出，哪些功能只是无用功。

　　组织很少有自信说某个 MVP 肯定会改善其客户成果，因此他们往往会用精益用户体验中的说法，以实验性的口吻来评价 MVP，例如：

　　“我们相信，让人们能够 [执行某些任务] 将改善 [某些期望的结果]。当我们观察 [对该结果的一些指标] 时，我们将证明这一点。”

　　如果一个 MVP 所提供的价值前提被证明是正确的，并且开发和维护与其对应的 MVA 的成本不超过其财务收益，则这个 MVP 就是可行的。只有一种方法可以证明其可行性：让实际用户 / 客户使用该产品并提供反馈。“真正的用户 / 客户”很重要；内部利益相关者的能力不够，并且可能会存在认知偏见，因为正是他们的意见塑造了关于这个 MVP 的原始想法。手工选择的焦点小组可能无法代表广大客户群的需求，因为小组成员是由塑造 MVP 概念的人们选择的，而且他们也会存在认知偏见。

　　对于某些产品，可能需要很长一段时间才能确定其 MVP 的可行性，可能需要数周，有时甚至数月。早期反馈就算不能准确衡量 MVP 的价值大小，也许也能快速确定 MVP 是否有价值。在考虑你的 MVP 应该做成什么样的时候，你首先应该问问自己你将要如何判断它是有价值的，以及你需要多长时间才能知道这一点。

　　对可行性的评估还包括了对财务可行性的估计。我们不用深入研究财务决策过程，只需记住开发产品的成本净现值不能超过产品将产生的未来收益的净现值即可。开发 MVP 和 MVA 能够帮助组织确定这个等式中成本净现值的水平，但他们还需要找到评估收益净现值的方法。

　　为了让一个 MVP 可行，它还必须在产品的整个生命周期内得到支持。如果由于某种原因，产品在客户需要时却停止运行，那么该产品对客户就没有价值。这就是产品的 MVA 的用武之地：当一家公司向客户提供 MVP 时，他们就提出了支持该 MVP 的隐含承诺，直到他们告诉客户他们将不再提供支持为止。MVA 的目的是确保 MVP 交付的成果是受到支持的。

　　MVP 和 MVA 加在一起，就能一点一点回答清楚“我们的产品（及其相关软件架构）是否可行，在产品的整个生命周期内是否一直获得支持且可靠？”这样的问题。每个 MVA 都尝试满足与 MVP 相关的质量属性要求（QAR）。如果它还满足与自己对应的 MVP 无关的其他 QAR，则 这个 MVA 就不是最小的。换句话说，MVA 仅支持与之对应的 MVP 中包含的成果，并且必须在产品的预期生命周期内提供支持，并预测那些应该在 QAR 中表达的未来需求。

　　MVA 必须对 MVP 当前面临的挑战作出回应，同时预测（但不是实际解决）MVP 未来将要面对的挑战。换句话说，我们不能让 MVA 进行代价巨大的返工来解决这些未来才会遇到的问题。一些返工是可以接受的，也是意料之中的，但“完全重写”这个词意味着架构已经失败，所有关于可行性的赌注都将落空。

　　因此，MVA 在“解决可能永远不存在的未来问题”和“让技术债务累积到导致架构破产的程度”之间保持着动态平衡。能够平衡这两种力量的正是我们的经验。

　　典型的问题是，开发团队认为他们非常了解 MVP 中隐含的，在未来会遇到的架构挑战。这种观念可能会导致团队对 MVA 投资过度，然后他们不得不频繁返工。例如，他们可能会说：

　　“我们知道我们以后需要一个消息传递机制，所以让我们现在就开发它吧，然后等企业用户来决定他们到底需要什么。”

　　他们是否需要消息传递机制取决于 QAR。如果无法在产品的预期生命周期内满足 MVP 的要求，他们可能是对的，但他们应该问的问题是“我们现在就需要它吗？”

　　如果 MVP 没能成功，他们花费大量时间和精力来开发的就会是一些没用的东西。但如果他们不开发这个组件，将来这个 MVP 可能会有一天没法继续用下去了，这意味着他们也会承担大量的技术债务。所以做好这个决策是非常重要的，并且它需要团队有丰富的权衡利弊的经验。一些能证明这个 MVP 将实现其目标的早期证据也很有用，能让团队了解他们在 MVA 上的工作是不是有用的。

　　在规划 MVA 的内容时，开发团队会问“我们需要满足哪些 QAR 才能长期可靠地交付 MVP，以及我们需要开展哪些技术工作？”。这里的架构不需要为了满足这些未来的需求而做到尽善尽美，但设计架构时确实需要预测为满足未来需求而可能做哪些更改。

　　开发团队创建第一个 MVA 时，所依据的是对这个 MVA 需要解决的问题的理解，而且这种理解往往是不成熟、不够充分的。他们一般也不会有什么 QAR，也许只有宽泛的组织“标准”可遵循，这些标准更偏理想化，不够精确。初始描述往往非常模糊，毫无帮助，例如“系统必须支持大量并发用户”“系统必须易于支持和维护”“系统必须能够抵御外部威胁”等。

　　开发团队还会收到利益相关者的一些早期声明，阐述他们对系统目标的一些想法。项目 / 产品赞助商经常会对 MVP 的成功做出不切实际的预测，这可能会导致开发团队在获得用户反馈之前对 MVA 的构建工作过度投入。

　　但是……有时项目发起人的预测是正确的，即使是过度建设的 MVA 也会在用户的高需求下陷入困境。即使对于简单的 MVA 来说，也有一些一定要遵循的原则。例如，大多数组织都无法承担一个安全性较差产品的后果，即便这个产品非常简单。

　　现实情况是，早期 MVA 与 MVP 一样，都是基于经验指导下的有根据的猜测做出来的。你可能不得不构建一些自己都怀疑可能没什么用的东西。初始版本的 MVA 多半会在某些领域过度构建，而在其他领域构建不足，你只能通过构建、发布和收集反馈这样的流程来了解到底哪里该补足，哪里可以砍掉。MVA 应该设计成足够获得用户反馈的架构，而不应该：

　　撤销那些被证明是错误的最初假设 / 决定的成本是应当关注的要素。技术债务是初始 MVA 不可避免的后果，就像大多数 MVP 至少会在某些方面出现部分错误一样。所以我们需要快速获得反馈。

　　开发团队有时会试图从成功的系统中复制它们的架构来起步，使用供应商解决方案也是一个办法。如果你发现这种解决方案的某些方面不起作用时也不至于陷入供应商锁定的困境，那么这可能就是个好方法。但不要复制那些超出你们需求的架构，否则可能会产生你们无法承受的技术债务。另外，当 MVP 逐渐演变时，请不要在早期版本的 MVA 上流连忘返。

　　在你发布产品增量改进之前，你是没法知道答案的。因为你并没有收集到关于这个 MVP 是否有用的反馈，如果没有反馈，你就不知道对应的 MVA 是否只是浪费时间，或者它是否可能需要在产品的生命周期内支持某一组产品功能。所以 MVA 必须通过的第一道关卡就是对 MVP 价值的评估。

　　我们相信每一个产品增量改进本质上都是一个新的 MVP。让 MVP 尽可能小巧的原因很简单：MVP 越大，它包含无价值内容的可能性就越大。如果 MVA 的目标是确保 MVP 的长期生存能力，那么让 MVP 保持较小的规模也能帮助避免 MVA 膨胀。

　　MVP 及其对应的 MVA 很像是两个用绳子绑在一起的登山者（参见图 2）。MVP 走在前面，MVA 不能落后太多，否则会伤害 MVP。因为 MVP 就像领头的攀登者，所以 MVA 领先于 MVP 也是没有意义的。有一个例外：系统初始版本的 MVA 必须有一个起点，而开发团队用于初始 MVA 的假设可能会导致对初始版本的一些过度投资。一旦反馈循环发挥作用，这种情况就会自行纠正。

　　就像登山者探索无人攀登的山峰一样，MVP 可能会根据反馈改变他们的路线。两名登山者可以串联移动，但这不是最好的解决方案；你将在构建 MVP 过程中学到一些东。