谁说敏捷无法用于项目管理的？

热爱敏捷的人通常对项目该词没有太多好感。这就像公牛对红布的反应一样。这一点从那些充满激情的敏捷实践者的坚定言辞中便可见一斑，比如“敏捷关注的是产品，而非项目”或“在敏捷中，项目没有立足之地”之类的言论。

然而，许多组织是以“项目”为工作单位。大家对于“项目”这个词的含义理解也有着极大的分歧，通常来说，是认为它是指为实现某个目标而进行的某段时间内的一系列活动。而企业的运营却是长期存在的（排除企业倒闭等原因不考虑），正是因为这样的特性，使得我们在应用“项目”来管理企业的事务时，引发了许多短期上满足项目目标，但长期上有损企业利益的问题。

热爱敏捷的人通常对项目该词没有太多好感。这就像公牛对红布的反应一样。这一点从那些充满激情的敏捷实践者的坚定言辞中便可见一斑，比如“敏捷关注的是产品，而非项目”或“在敏捷中，项目没有立足之地”之类的言论。

然而，许多组织是以“项目”为工作单位。大家对于“项目”这个词的含义理解也有着极大的分歧，通常来说，是认为它是指为实现某个目标而进行的某段时间内的一系列活动。而企业的运营却是长期存在的（排除企业倒闭等原因不考虑），正是因为这样的特性，使得我们在应用“项目”来管理企业的事务时，引发了许多短期上满足项目目标，但长期上有损企业利益的问题。

本期，我们将探讨长期以来都有争议的话题。“产品”还是“项目”，也许有人认为这只是概念名字的定义讨论，没有实际意义。但我们认为，用词本身是具有意义的，因为它总是在更广泛的上下文语境中被使用，我们真正需要讨论的是那些上下文前提的区别。这比单纯讨论敏捷到底是“产品”还是“项目”更具备现实意义。

什么是项目

在深入探讨这个讨论之前，我们首先需要明确“项目”的定义。在我们的工作中，我们注意到人们往往将项目定义为具备以下特征的长期的活动：

1）需要交付的范围

2）实现这一目标的预算

3）需要交付的日期都是固定的

4）项目只在结束时交付

5）可以永远持续下去。

美国项目管理学会（PMI）将项目定义为“为创造独特的产品、服务或成果而进行的临时性努力”。维基百科将其定义为“任何单独或协作进行的，可能涉及研究或设计，经过精心策划以实现特定目标的活动“。这两个定义都没有明确指出项目的范围、预算和截止日期，也没有明确指出项目仅在结束时交付或永久持续。因此从不同来源方来看，我们似乎在讨论不同的事物。

抛开正式的定义不谈，即便是最热衷项目管理的项目经理也会承认，对于项目所代表的复杂性，仅靠确定项目的预算、范围和交付日期来进行管理保障，未免过于乐观，甚至是天真的。事实证明，无论是PRINCE2还是PMI协会，都基于这样一个假设：项目代表了复杂的工作，具有不可预测性和风险性。因此，许多敏捷主义者对“项目”的定义似乎比通常意义上的更为极端，认为复杂工作根本不可预测，这使敏捷主义成为容易被”项目管理“攻击的假想对手。

项目和项目管理

因此，尽管项目与敏捷框架并不相互排斥，但它们的不确定性和风险的管理方式却往往不同。像PRINCE2和PMI这样的基于计划的方法更依赖于预先规划和治理来控制风险。而敏捷框架遵循的原则是，无论预先规划多少，都无法控制风险或以小而有价值的增量发布产品。敏捷将每个发布视为一个反馈循环来调整过程。敏捷框架更依赖于经验主义（从经验中学习），而像PRINCE2这样的基于计划的方法则更依赖于理性主义（通过推理学习）——这是两种根本不同的管理风险方法。

打破敏捷无法适用于项目管理的谬论

为了更好地讨论“产品”与“项目“的对比，我们还是从源头开始。再浏览一遍《Scrum Guide》，就能为我们在敏捷Scrum框架内理解项目提供一个有益的视角：

“每个Sprint都可以被视为一个不超过一个月的项目。与项目一样，Sprint也是用来完成某项任务的。”

《Scrum Guide》也明确提到了产品而非项目。其中提到的是产品负责人和产品待办事项列表，而不是项目负责人和项目待办事项列表。这样做有几个很好的理由：

• 产品更加有形。这使它们与向用户提供有价值的东西这一理念联系得更加紧密。
• 产品都有生命周期。没有人知道产品何时会达到成熟期，或者何时会被停产。这个周期可能很短，也可能很长。无论哪种情况，在产品生命周期中都需要进行很多调整。这就要求我们将长期思考与短期思考结合起来。如果我们现在走捷径，以后就得为此而付出代价。但同样地，我们也必须尽快交付一些东西以获取短期收益。

我们并不是说项目不会给用户带来价值，也不是鼓励走捷径。我们只是指出，“产品”这个词能引发更具长期建设性的讨论，因为它必然与用户、持续变化和价值等是息息相关的。

使用敏捷推进项目的技巧

所以，假设你发现自己身处一个充分应用”项目“的组织。其中一种策略是坚决主张从组织词典中剔除”项目“这个词。但一个更有效的策略是从现有资源出发，以支持实证主义的方式使其发挥作用。以下是我们喜欢采取的做法：

• 在产品待办事项列表上明确项目的范围，并在出现新见解时进行调整。
• 思考确保“项目”取得有价值且高质量成果所必需的条件，并将其纳入你的“必需完成”的事项中。
• 项目预算决定了产品待办事项列表中可以完成的工作量。当预算用尽，但继续推进可以带来更多价值时，可以在必要时适当地扩展待办列表的内容。
• 每个Sprint带来的成果增量都会作为里程碑交付给利益干系人，并实现一个关键的业务目标。如果需要，可以根据反馈来调整产品待办事项列表的内容。
• 产品负责人、Scrum Master和开发团队，对所有关于他们正在进行的“项目”（或项目的一部分）的决策拥有完全的授权。
• 将产品待办事项列表放在旁边，为你的项目创建一个路线图。这会有利于告诉我们事情发生的顺序和进展。
• 如果有项目管理办公室或指导委员会，与他们合作，来促进上述目标成为可能。
• 只要项目经理尊重产品负责人和Scrum Master的职责，他们可以成为敏捷团队的重要资产，可以帮助协调与利益干系人的关系，处理组织内部的政治问题，并消除障碍。

“作为敏捷团队的一员，项目经理可以成为一笔宝贵的财富。”

在进行上述工作时，你所进行的以上思考，将比反对使用“项目”一词更有成效。或者声称每个人都“需要采用产品思维，而不是项目思维”这种言论更有成效。如果你从现有情况出发，并以实证的方式开展工作，你会发现所有这些情况都会开始发生变化。

咬文嚼字很少能有效地促使人们切实地改变他们的行为

过去我们常犯一个错误，那就是开始纠正人们谈论工作的方式。每当有人提到“项目”时，我们就会纠正为“产品”。我们会用一种迂腐的口吻解释说，“我们在这里建造的是产品，而不是做项目”。但这真值得我们纠结不已吗？在我们看来，还有更多关键的对话、思考、讨论需要展开，比如：

• 我们如何确保利益干系人参与到项目中来？
• 我们如何利用每个Sprint来交付一个有形的成果——即增量——以便与利益干系人一起检查？
• 我们该如何开始消除那些阻碍我们前进的问题？

这些话题都很重要，并可能间接推动向更以产品为导向的方法转变。与其在强迫让他们出现在我们强调的地方（显然当前找不到有他们的身影），不如在他们目前所在的地方创造条件与他们相见。

咬文嚼字很少能有效地促使人们改变他们的行为，并对事物运作方式产生正确理解的。相反，过分纠结于人们已经习惯的表达方式，更有可能引发抵触情绪。这样做只会让对话陷入僵局，而非开启新的对话。

归根结底，持续进行透明、检视、调整的目的就在于此。