产品开发流程管理的原则有哪些？

了解产品开发流程的原则可以为理解如何最大化产品开发过程的效率提供客观基础。关于产品开发方法，特别是敏捷与瀑布，有很多“信仰热情”。敏捷只是一种工具——它不是一种信仰。

方法的选择应基于使方法适合问题的性质。敏捷在许多情况下都有意义，当然有很多充分的理由，但有些人似乎只是机械地这样做。人们像信仰一样致力于敏捷，敏捷本身就成为一个目标，但没有真正理解为什么它在特定情况下有意义。我们需要一个客观的、不基于信仰狂热的基础来比较敏捷和其他方法。

如果您客观、系统地审视整个产品开发流程，那么您真正想做的就是最大化整个流程的流动性。

产品开发流程的原则

Don Reinertsen写了一本非常好的书，名为《产品开发流程的原则》，这本书为理解敏捷有意义的基本原则提供了一些有价值的见解。由于这些原则足够通用，可以适用于任何产品开发工作（敏捷开发或瀑布开发），因此它还为比较敏捷和替代计划驱动方法提供了客观基础，以便人们可以对这两种方法如何进行智能和客观的评估看似竞争的方法。

这本书在为书中基于统计学的原则建立定量和数学上合理的基础方面有点太严格了。现实生活中没有多少人会真正应用这种严格性来分析这些原则。但尽管如此，对这些原则的高层次理解是非常有价值的。而且，它确实为更深层次地理解敏捷的意义提供了客观的基础。我在这里总结了产品开发流程的八项原则：

1.经济学——从经济角度看

我们为什么要改变产品开发流程？答案是：增加利润。尽管这看起来很明显，但这种产品开发的经济观点却出奇地罕见。相反，产品开发人员制定了大量的其他目标：增加创新、提高质量、遵守计划、缩短开发周期、消除浪费等。不幸的是，他们很少了解这些目标如何影响利润。

有很多公司在没有真正了解经济影响的情况下盲目追求这些目标（例如“增加创新”）。增加创新本身不应该是目的，它在某个时候会达到收益递减的点，并且可能开始影响其他代理变量，例如质量。出于这个原因，最好将事情放在经济背景下。经济背景提供了一个框架，用于做出明智的决策，决定在多大程度上关注这些变量。

这是经济环境如何为决策提供良好框架的另一个例子：通常最好尽可能推迟有关产品功能的决策。然而，一些决定应该尽早做出，并且不应大幅推迟，因为它们可能会产生重大的经济影响。

2.队列——主动管理队列

队列很重要，因为它们在经济上很重要，但管理不善，而且有可能得到更好的管理。队列深刻地影响产品开发的经济性。它们导致有价值的工作被闲置，等待访问繁忙的资源……队列会损害周期时间、质量和效率。

提前开发等待中的需求可能效率低下且浪费，因为需求在进入开发之前可能会发生变化，并且开发需求所涉及的大部分精力可能被浪费了，对未来的需求进行推测可能会导致错误的假设，这些假设会在没有受到质疑的情况下进入开发阶段。

但是，另一方面，我们不应该盲目地接受“提前开发需求永远没有意义”的观念。有很多原因可以解释为什么至少尽早开发高级需求对于指导项目的总体方向和架构是有意义的，并且我确信甚至在某些情况下预先开发更详细的需求也是有意义的（您必须使用经济影响作为做出决定的指南）。

3.可变性——理解并利用可变性

产品开发中可能没有什么比可变性更容易被误解的了。由于可变性有时会导致不良结果，因此一些观察者不可避免地会错误地概括为可变性总是会导致不良结果。

减少开发流程中的变更会有利于提高效率，但情况并非总是如此。例如，将大需求分解为尺寸更均匀的小需求可以减少可变性并可以改善流程，但是，在某些时候，进一步尝试减少可变性并不具有经济价值。

例如，如果一个用户需求大于13个故事点，则需要将其分解，但将小于13个故事点的需求分解为更小的需求可能没有什么价值。故事点只是为了减少可变性。

4.批量大小——减小批量大小

如果询问典型的产品开发人员，他们的批量大小是多少，以及为什么，您会得到一脸困惑的表情……产品开发人员根本不会考虑批量大小。结果，他们没有充分利用改善流程的最重要工具之一。产品开发中的许多重要的改进，例如并行工程、快速原型设计和敏捷软件方法，都可以被认为是批量大小的减小。然而，由于开发人员未能认识到这些改进背后的潜在作用机制，他们失去了在整个开发过程中更广泛地应用这一原则的机会。

批量大小效率低下的例子包括：

• 项目范围——在单个项目中承担超出真正需要的内容

• 项目资助——整个项目作为一个大批量提案进行构思和资助

• 需求定义——倾向于在项目开始之前定义 100% 的需求

5.WIP 约束 – 应用进行中工作 (WIP) 约束

使用进行中工作 (WIP) 约束来管理整体流程。例如，控制同一时间承接的项目数量，避免开发资源过度饱。明智地使用专业资源，最大限度地发挥其对整体流程的影响。

产品开发流程的原则

6.不确定性下的控制流——节奏和同步

节奏是在流程中使用有规律的可预测节奏。这种节奏将不可预测的事件转变为可预测的事件。它在防止连续过程中累积变异性方面发挥着重要作用。

节奏的例子是使用固定长度的冲刺来确定开发工作的节奏。使用同步的示例包括：

• 多路径同时并发开发

• 多个子系统的并发测试

7.快速反馈——尽快获得反馈

快速反馈可以通过更快地截断无效路径来降低预期损失，或者提高预期收益，因为我们可以通过快速重新调整资源来解决问题。快速反馈与选择适当的绩效衡量标准相结合，可以实现快速学习和持续改进。

8.分散控制

复杂的组织可以提供非常先进的集中协调、分散控制模型。人们的印象是，组织寻求机械地服从下级上级的命令。事实上，现代组织的重点是应对瞬息万变的市场，而不是执行预定的计划。它将市场视为一个固有不确定性的领域，最能利用不确定性的一方将会获胜。

总结

你是否遇到过我所说的盲目刻板地追求方法论的人？他们的特点是，人们认为有一种特定的方法（无论它是什么，敏捷、瀑布或其他方法）对于您可能拥有的任何类型的项目来说都是通用的解决方案。

这种“一刀切”的方法很多时候会导致人们强迫项目适应一种方法，无论它是否适合，并严格地实践该方法，而不必根据具体情况进行调整。实际上更好的方法是使方法适合项目，有时可能需要将不同方法的元素混合在一起以适应情况。

为什么会存在这个问题呢？

有时人们只知道一种方法。例如，多年来，项目经理接受了瀑布方法的大量培训，无需学习任何其他方法。

了解如何定制方法和/或混合搭配不同方法的元素以适应情况需要更多的技能。它需要更广泛的方法论知识，并更深入地理解方法论背后的原理，而不仅仅是其实施机制。

有时，人们对某种特定的方法过于热心，以至于失去了客观性，忘记了任何方法都有局限性，需要明智地应用，并根据需要进行调整以适应具体情况。例如，有些敏捷主义者对Scrum如此热衷，以至于他们完全拒绝任何更传统的计划驱动方法，因为它们已经过时且不再相关。

许多人沉浸在Scrum的机制中，而忘记了敏捷的价值观和原则。本文和大家深入地探讨了产品开发的原则，为更深入地理解敏捷（自适应）方法和瀑布（计划驱动）方法提供了良好的基础。