第一章 流的原理 （1）

并不是你不知道的让你惹麻烦，而是你确信知道的，却并不是那么回事最终让我们陷入困境。

---马克.吐温

为什么写这本书？在30年的产品研发咨询的过程中，我很幸运和很多聪明而富有经验的开发者一起工作。我有机会看到他们做什么，结果怎样。同时，我也被各种如何做产品开发管理的“标准化”的建议包围。非常有意思的是，真正有效的方法和大部分人认为的标准化建议大相径庭，为什么呢？

我相信现在的主流的管理产品研发的方法，根本上是错误的。不是错了一点，是在核心根本上就完全错误。这种错误和在日本人发现了精益生产的秘密之前，我们对工厂生产犯的错误是一样的。我相信，在与传统的错误方法不断挑战和演化中，一种新的范式正在出现。而我想加速这种新的产品开发管理范式的应用，帮助人们理解它，这就是这本书的目的。

我所描述的方法可能在有些软件开发流程中已经以某种方式存在。毕竟，产品开发人员经常愿意重复一种行为，这种行为是有效的，虽然理论上也许并不相信它有效。但是，仅仅靠发现和重复这些行为，还是不足以大规模的部署使用。产品开发人员和管理人员需要抽象出这些行为背后的机制，需要把这些原则更抽象化，然后能够把这些从个别案例，推广到一个通用的方法，从而使整个产品开发流程发生转变。

让我们从一个实例开始。很多产品开发都有正式的阶段——检查门的流程。工作被分成互不关联的各个阶段，用检查门分割开来。一个阶段必须结束，然后下一个阶段开始。比如，这些流程经常要求所有的产品需求在开始设计之前定义好。开发团队看起来也是这么工作的——在检查门评审前，把产品需求尽量完整地呈现给管理人员。然后管理人员批准了需求定义阶段结束，进入了产品设计阶段。表面上看，一切看起来完美，很合理，也很有效。

不过事实上发生的有很大不同。当我在产品开发课程中调查产品开发人员的时候，95%会承认他们在知道所有的需求之前，已经开始了设计工作。事实上，一般的开发人员在50%需求了解之后就开始了设计工作。他们仅仅是不对管理人员公开而已。检查门审批对他们只是在完成一个确定已久的仪式——请求管理层允许开始设计。这是一个典型的技巧—— “不问，就不要说，做就行了”。管理人员礼貌地避免去问是不是下一个阶段工作是否已经开始，而产品开发人员也小心谨慎地避免提及他们已经继续了。实际操作中，合理的行为已经发生，哪怕有一个不那么工作的正式的流程在。

这种地下的的设计和需求活动的重复，只是传统产品开发的替代方案中一个很简单的例子。另外的还有，比如说新的方法强调小批量，快速反馈，限制在制品等等。这三个方法其实在产品开发过程中广泛地使用。如果我们能够理解他们为什么有效，我们就可以把他们调整并适用到其他很多的场景中。

新产品开发范式的核心问题，就是强调实现流。这种方法和精益生产有很多相似点，也许可以归类到精益产品开发（LPD）。但是，精益生产对工程生产做了很多地优化，而产品开发和它又有很多不同的特性。

例如，工厂生产处理的是可预计和重复的任务，具有相同的延迟成本，相同的任务周期。所以工厂生产的处理是很简单的先进先出（FIFO）的模型。但是FIFO在产品研发中从来都不是优化的方案，因为产品开发处理的是变化幅度很大，不重复，异质的任务流。不同的项目几乎都有不同的延迟成本，也对我们的资源有不同的需求。

就像你理解的一样，这些挑战强迫我们要比精益生产走的更远。假如我们保持对其他领域的研究方法的开放心态，我们可以学习和超越。为了跟精益生产做审慎的区别，我们把这种新的产品开发方法叫做“基于流的产品开发”