项目管理方法论：混合项目管理模式是什么？

我经常看到关于“项目的最佳管理方法是什么？”的讨论。或“你最喜欢哪种项目管理方法？” 其实这根本不是看待方法论或框架的正确方式。

没有一种项目管理方法论或框架本质上比所有其他方法论或框架更好，我们不应该仅仅因为自己更喜欢某种方法或框架而选择它。根据项目团队所处的实际项目场景，每种方法都有各自的优点和缺点。

项目管理方法论的赛场

有很多人陷入了所谓的“项目管理方法论的赛场”，他们专注于自己的立场：“我的方法比你的方法更好”。并且，无论他们提倡什么方法，都比任何其他方法更能解决您可能想象到的任何问题。

您可以在许多“敏捷与瀑布”讨论和其他讨论中看到这一点，其中SAFe、Scrum、看板或其他一些方法或框架被定位为解决您可能遇到的任何问题的“灵丹妙药”。他们还倾向于忽视所有其他方法论，认为它们已经过时或无关紧要。

真相是什么？

事实是，所有方法论和框架都有其各自的优点和缺点，具体取决于实际场景，正确的方法是使方法适合具体场景，而不是强制将问题适应某些预定义的方法。有时这可能需要定制适合问题的方法，或使用来自不同方法的元素的组合。例如，在敏捷环境中，使用混合方法可能是有意义的，该方法将敏捷和传统的、计划驱动的项目管理以适当的比例混合以适应情况。

事实上，做到这一点要困难得多，但终归是可以做到的。它需要了解更众多的方法和框架，能够客观地看待这些方法的优点和缺点，以及更深入地了解这些方法背后的原理，以了解如何将它们组合起来以适应给定的情况。

为什么没有更多的人这样做？

许多人都在寻找简单的解决方案，他们可以机械地按照分步过程进行操作。例如，有一些简单的项目管理方法，主要是围绕遵循定义的清单和使用填空文档模板构建的。这是一个简单、机械的过程，不需要太多的智慧和判断力。不幸的是，这种过程在如今项目管理领域并不是很有效。

举一个精益软件开发的例子。精益并没有作为一种独立的方法被广泛使用，而且它显然没有赢得“方法论之战”，但精益背后的原则是包括Scrum在内的所有敏捷方法的基础。如果您查看精益背后的原则，它们可能看起来与其他敏捷方法论不一致：

精益强调消除流程中的浪费以提高效率，同时，敏捷更注重采取灵活和适应性的方法来满足客户需求，而不是仅仅关注消除浪费。如果你孤立地、极端地追求每一个目标，它们可能会相互冲突，但如果它们以适当的比例混合在一起以适应特定的情况，它们可以是互补而不是竞争的关系。

混合项目管理模式的示例

敏捷与瀑布

有时可能需要结合两种看似相互冲突的不同方法或框架。敏捷和瀑布就是一个完美的例子。许多人错误地认为所有形式的传统项目管理都已经过时且无关紧要，并且已完全被敏捷所取代，或者在这些极端之间存在二元且互斥的选择，并且无法将两者融合在一起。

事实并非如此。在表面上; 如果你看看传统的、计划驱动的项目管理和敏捷，它们可能看起来相互矛盾；如果每种方法都孤立地、极端地推行，它们可能会发生冲突，但这并不妨碍将两种方法背后的原则以适当的比例混合在一起，以适应特定的情况。

精益和敏捷

精益和敏捷之间也有类似的关系。如果你将这些方法中的每一种都追求到极致，并尝试最大限度地独立地从每种方法中获得收益，它们往往会将你拉向不同的方向。精益强调减少“浪费”，敏捷强调灵活性和适应性以满足客户需求。

这两种方法并不完全兼容，然而，它们也不一定不兼容。只需要一些技巧即可将它们以正确的比例混合在一起以适应特定的情况。“精益思维”是敏捷的固有组成部分，当以正确的比例使用时，它们可以完美互补。

Scrum 和看板

有些人比较 Scrum 和看板，并试图证明看板比 Scrum 更好（反之亦然）。任何试图提出这种论点的人都只是偏向其中之一，并且不理解它们有何不同，以及为什么使用其中一种而不是另一种更有意义。它们的用途截然不同，并且根据使用方式各有优缺点。当它们以正确的比例一起使用时，它们可以非常互补。例如，看板多次用于管理Scrum冲刺中的工作流程，它非常适合此目的。

总结

我们如今生活在一个复杂的世界，简单的、固定的的解决方案可能不再有效，我们需要学会使方法或框架适应问题的本质，而不是强行将问题适应某种问题。有效地做到这一点需要一种通常被称为“系统思维”的思维模式——它需要在整体背景下看待问题并在更深层次上理解问题的动态，而不是机械地对给定问题强加预定义的解决方案。