入门指南 | 通过减小批量降低产品失败风险

这一原则在精益创业、行动手册风险管理、基于知识的产品开发以及敏捷和看板软件开发方法中很常见。剧透警告——它与批次息息相关……

Don Reinertsen 1997年左右在《管理设计工厂》中向我们展示了设计批次的含义以及将需求和测试批量化相关的成本。

他指出，在测试产品之前就设计其完成X，Y和Z，通常会比先专注于X，再Y，最后Z花费更多的时间。通过批量处理这些功能（需求）能够延迟学习，避免项目变长或某些需求无法满足。

回到精益创业的例子，柯达的Mark Cook在之前的文章中提到，一个盈利性产品诞生之前必须满足四个高级需求。

• 1. 客户意识到自己有问题
• 2. 客户将为解决方案付费
• 3. 客户会从我方购买解决方案
• 4. 我们能够创建一个解决方案

我们等待第四个需求满足之后再来测试需求1-3，这样可以创建大量需要测试的需求并延迟了反馈。关于前三个需求的反馈会影响我们如何满足第四个需求以及是否花时间和金钱去尝试。收到需求1-3的延迟信息很容易导致代价很高的延迟和利润损失。

看看答案的影响

我们对这种情况的可视化学习地图简化如下：

在学习地图中，我们捕获了回答问题的对象、降低风险的对象和在绿色低水平节点中满足需求的对象（它们几乎都是相同）。问题1-3的答案通常会影响我们的解决方案以及如何达到问题4。

例如，客户只会为解决方案支付固定金额。他们的支付往往会很大程度上改变我们的解决方案。这些问题长时间得不到解答的话，我们面临的风险将越来越大。这种不断增加的风险最终会使我们付出代价。反之，看每个答案的影响，我们可以确定要先回答哪些问题，更快地降低风险。通过这种方式，我们实现经济目标的机会要大得多。

精益与最大化风险降低率有关

风险越早降低，我们能越早完成，质量和业绩也会越好，利润就会越高。 这是精益产品开发的精髓所在。

产品开发的产物是知识和信息。（我们将在后续文章中探讨知识和信息之间的关系。）我们开发产品时本质上是在生成、转化和传递知识和信息，这些是对我们事先就知道或者没有意识到的问题的解答。在精益产品开发中我们看到的几乎每一种方法都试图更快地生成、转化或传递信息和知识。

例如，我们可以开发应急原型来做测试或给客户做展示。有时我们的原型只是艺术再现，或者是PowerPoint中的模型，虽然原型很简单，但是至少能让我们更快地获得一些认识。相比于等待数月或数年的时间来消除所有风险，制作简单原型能让我们只花费数天或数周的时间来消除大部分风险。每一条信息（答案）都有潜在的影响，每个答案的影响和概率的组合就相应暴露了未回答问题所带来的风险。风险暴露是对信息价值的衡量。

产品开发的成功来自于更早地产生更有价值的信息。

精益就是根据答案的影响，尽可能快地以最佳顺序得到正确问题的正确答案。精益意味着更快地降低风险。

精益赛跑是在相似赛道上进行的

在产品开发中，不管是精益快速学习还是非精益缓慢学习，我们都要遵循一个标准，其步骤是一样的：设计、构建、测试——重复。在精益新产品开发（NPD）中，我们只设计、构建和测试必要的部分，生成至少一部分答案。以我硬件开发的背景来看是这样做的，但我也看到好的精益设计→构建→测试循环与Eric Ries的构建→测量→学习循环是一致的。

Eric Ries在他的构建步骤中加入了设计。有时设计仅仅意味着设计测试——我们将测试什么以及如何度量结果。有时我们需要设计一些基本的测试项目、一个快速的原型，或者一个测试设置。其他时候，在测试之前有更传统的设计和构建，但都至少有一个小的设计步骤。我们的目标是快速地通过这个循环，同时获得对设计的重大学习和验证。

需要注意的是并不是所有的测试都能产生好的学习效果。对于采用精益创业方法的循环，通过下游的测量（也称有效学习）可以实现更正确的学习。不仅是我们自己认为，这实际上也降低了风险，而且在每次迭代中获得更高的价值。

我们试图最大化的是速度和每个循环中有效学习数量的组合——风险降低率，即每周减少的风险暴露或实现的答案价值。

以更轻更快的迭代赢得产品开发比赛

想象在一场赛跑中，你在每圈一开始就拿到需求和风险，然后绕着跑道跑，走，或者拖着它们，如下图所示。

每跑完一圈，如果你学到或验证了一些有价值的东西，你就可以把在那一圈所带的部分东西存入银行。每个需求（其价值由美元符号的数量表示）都带有风险（由问号的数量表示），我们必须兼顾两者。问号的数量决定了每项要求必须跑多少圈才能达到其全部价值。如果我们承担更少的风险和需求，就可以跑得更快。

大部分情况下，携带两倍要求的话完成一圈就需要两倍的时间。在某些情况下，增加一些需求只会增加一点时间。我们在每一圈携带的风险和需求就是设计→测试→学习批次。我们的设计批量越小，完成周期就越快。

比赛的目标是在给定的时间内将最大的价值存入银行。我们的选择是要么跑快一点，带少量存多次；要么走慢一点，每次试着多带一些。

这个赛跑的类比满足有氧条件，我们可以尽情按需呼吸，跑得更快并不意味着需要更多休息或更快倒下。事实上，我们携带的东西越多，就越有可能需要休息或因疲惫而崩溃，或者被路上的东西绊倒。因此，东西越有可能从我们的包里掉出来。

这个类比的最后一个重点是，我们每圈带的问号越多，就会留越多的问号到下一圈。换句话说，如果只有几个问题需要学习答案，我们就可以在同一圈内回答所有问题。如果有很多问题，有些就会被隐藏起来，我们最终带要着这些问题和相关的风险暴露，至少再跑一圈。

拆分、拆分、拆分

精益中的每一圈都非常关注一些特定的需求和风险，我们在能力范围内尽可能装满背包，绕着跑道快速地跑。而在传统的非精益产品开发中，我们在构建和测试之前会做更多的设计，然后一起批量处理，并试图在每一个设计→构建→测试循环中满足大量的要求。

在传统的产品开发中，我们通常会尝试在三到四圈内完成比赛。我们在第一圈就承担了80%以上的需求和风险——包括产品所有应该完成的和大部分外观和感觉上应该达到的。我们留下的唯一需求就是那些预期会大大降低速度的，比如“从生产厂商那里得到零件”、“让生产人员组装”等等。

我们试图同时移动许多需求，因此不可能以任何实际的速度移动它们。相反，我们几乎将整个堆向前移动了一点，并创建一个新的堆，然后重复这一过程，直到环绕整个轨道。这个过程很慢，而且我们只有在把所有的钱都存入银行后才能得到存款。

它关乎工作量，以及我们在每个设计、构建、测试迭代中放入的需求和问题的数量，因此它是到达测试所花费的时间，影响着我们精益与否。

更快得到答案对降低风险至关重要

在新产品开发比赛中，学习是有价值的并且会成为银行中的存款。大多数学习都发生在测试阶段。在硬件开发公司中，少量学习发生在构建阶段。然而在构建硬件开发过程中，我们实际上是在测试供应商是否合格以及部件是否合适并易于组装，只有在测试失败时才能学到东西，所以在设计过程中很少有学习发生。但现实中恰恰相反。在设计阶段我们做出错误的假设，在测试时就能学习。我们设计的越多，建立的错误假设就越多，以后需要学习的东西就越多。

在Mark Cook和精益创业的例子中，通过在测试/回答需求/问题1-3之前设计和构建解决方案，我们将一些高影响的不确定性保留了很长一段时间。我们为学习创造了一大批量，在很长一段时间里承担着很大的风险（很大的不确定性及其巨大影响）。通过拆分需求和问题（将它们分解成更小的迭代），并独立进行设计→构建→测试，我们可以更早地得到答案并获得确定性。这将带来更快、更成功的项目和更高的利润。

尽早发现未知的未知事件

将需求和问题分批并更早地进行测试还有一个更大的好处是，我们会发现更多未知的未知事件——那些我们之前不知道需要问的问题。

我们可以在哪里找到隐藏在产品以及“难以想象其为错误”的假设中的漏洞？我们总能在同样的地方发现这些未知的未知事件——下游，例如我们将产品送到验证和确认（V&V）测试、注册审批、制造、客户、服务以及任何处于开发下游的人员时。我们通过更早地抵达下游发现这些未知，而这可以部分通过事先较少的设计和建造实现。我们构建了一个非100%完成的产品放置在下游，能够比其他方式更早地发现许多问题。

 “批次，我们不需要让人头疼的批次！”

精益创业、敏捷、看板、流、基于知识的产品开发、行动手册需求和学习管理之间共同的基本原则是分解一些让人头疼的批次，以更快地消除风险并实现价值。

在每种情况下，我们将设计→构建→测试批次分解成更小的部分，以便更快地学习并完成项目。对于精益创业、敏捷、看板和行动手册需求和学习管理来说，要具体认识到存在未知的未知事件，我们将通过尽早构建下游的不完整设计将其识别出来。

硬件开发是不同的

在制造业和硬件开发领域，有许多人认为其中一部分纯粹只是愚蠢行为。我们怎么可能通过在添加Y和Z之前就设计和测试X达到提前完成呢？我们怎么可能把部分产品下游放到验证和确认，或者放到监管机构的审批过程中，以便更早地找出未知的未知因素？我的回答——这在某种程度上是对的。

硬件在许多方面与软件不同。当提前期和部件成本在设计→构建→测试循环中占很大比例时，我们在每次批处理中投入的最优设计量确实会变大。为了以尽可能快的速度实现项目交付，我们需要了解批处理的设计何时过小以及何时过大。幸运的是，大多数硬件公司可以安全地减少它们当前批量的大小，并且进行改进。