敏捷实施中应该避免的陷阱

敏捷 管理部门 角色

摘要

从传统项目管理转型到敏捷是一种模式的转换。从推式系统到拉式系统，从控制-命令文化到实现分权的信任文化。良好的组织加上一些控制机制可以最大可能地帮助你更快地获得想要的结果。本文将主要讨论，在已经决定采用敏捷的组织中，管理部门扮演什么角色。

正文

本文将主要讨论，在已经决定采用敏捷的组织中，管理部门扮演什么角色。我认为，在得到来自管理层和组织的支持之前，自下而上的敏捷实施方法无法发挥敏捷的全部潜能。如果希望敏捷项目真正地成功，那么管理人员需要认识到他们在敏捷执行和支持方面需要付出什么。

我的背景是项目经理，我对项目的观察具有整体性。我希望交付极妙的解决方案，但我也希望确保我们实现了预期的企业利益。我根据环境计划项目。比如，项目的复杂度如何，风险多大？组织的成熟度如何，我有一个怎样的团队？我是在一个敏捷还是非敏捷组织中工作？换句话说，我不相信有一种通用的项目实施和项目管理方法。

我有多个PM认证，但我也是一个忠诚的“敏捷主义者”。根据我的经验，敏捷项目常常会在还没有完全实现敏捷的组织中开展。因此，我建议，如果我们在项目实施方法方面不要那么教条，开始综合运用传统方法和敏捷方法的最佳实践，那么我们就有更大的机会取得成功。顺应这个想法，我已经发起成立了一个独立于方法的新组织：APMA——敏捷项目管理联盟。

如果可以今天开始，为什么要等到明天？

几个月前，当我在一个大会上演讲时，一名与会者说了这样的话。他是一名业务经理，他说：“我们想要更好的项目，因此，我们公司的管理部门已经决定，每个人都将于2015年1月开始敏捷地工作。”

我很困惑，非常困惑。他真得认为，在2015年1月某个星期一的早上醒来时，整个公司就可以开启一个全新的时代，每个人都抛弃了旧有的习惯、态度和方法，并开始了敏捷吗？

这让我产生了疑问，具体有几件事：

如果已经做出决定，为什么不今天就开始他们的敏捷之旅？

人们真得认为一家企业从传统项目实施方法转变到敏捷项目实施方法就是这样发生在一夜之间吗？

他们是否认识到，采用敏捷方法开展工作的决策意味着管理部门也必须改变工作方式？

他们是否知道，实施敏捷并不就是实现了敏捷？

使企业转型为敏捷企业需要付出巨大的努力，不会因为高层管理部门的命令而在一夜之间发生。有许多旧有的习惯需要打破，与传统的项目、人员和团队管理方法相比，许多敏捷原则都是违反直觉的。

一旦做出决定，就：

• 需要决心；
• 需要培训；
• 需要在所有层面上作出改变的意愿。

管理人员对敏捷成功实施的贡献

无论如何，有一件事是确定的——如果可以持续地获得管理部门的大力支持，那么敏捷转型才有可能成功。要实现健壮的敏捷，还有一个先决条件，就是管理层也要以敏捷原则作为行为依据，而不只是项目团队。

此外，这意味着：

1. 在需要的时候，可以提供及时的战略决策
2. 提供一个框架，真正地将执行决策权下放给执行层
3. 接受错误将会出现（并认识到错误总会出现）的事实
4. 在组织的所有层面培养一个信任环境

只有四项——能有多难？

如果（敏捷）项目管理人员是在一个践行这四项的环境中管理项目，那么这将极大的增加项目成功的可能性。那么，为什么不这样做呢？

这主要是因为那并不简单。组织文化是一个强大的东西，不容易改变。实施敏捷需要对组织进行重大变革，而组织遵循传统原则做事可能已经长达10到20年，甚至更长。所以，看上去可能简单，但实际上并非如此。

实施敏捷的成本

有许多原因让人们希望组织可以变得更加敏捷。首先是有说服力的数据。请看下敏捷社区或者美国项目管理协会的年度调查报告“行业脉搏（Pulse of the Profession）”。调查显示，敏捷项目的成功率更高。

谁会不喜欢那样呢？

然而，任何东西都是有成本的。

在这种情况下，对于一个健壮的敏捷实现而言，其成本是要在整个组织范围内变革一切与项目相关的行为。当管理人员迈出第一步，改变他们自己的行为，组织行为变革就很可能发生了：

• 管理人员必须承认，供给和需求必须保持平衡，他们启动的项目应该只能同他们能够处理的项目一样多。
• 将关键资源（瓶颈）分摊到太多项目只会让情况变得糟糕。停止开始新项目，开始完成已开始的项目，而不会因为资源不足导致项目延期。停止多任务，那会产生大量的浪费。
• 让每个人都清楚组织的优先事项。当项目需要组织其它部分的帮助时，这比他们“真正的”工作更重要吗？项目工作时间都分配好了吗？那样员工才能专注于项目而免受其它任务带来的痛苦。
• 将执行决策权下放给（敏捷）项目管理人员、产品经理等等。等待决策会浪费大量的时间，而且，每天都直接参与到项目中的人所作出的决策会更好。
• 准备好根据“需求”做出战略决策，但要知道，为了做出可能最好的决策，需要对项目有更深入的了解。不能浅尝辄止，不能只当个名义上的项目发起人。
• 要知道，项目的性质和复杂度不会仅仅因为它们受敏捷技术管理而改变。因此，要接受现实，项目团队很有可能犯错，但是要知道，犯错、纠正、吸取教训并获得进步要好于不犯错但静止不前。

一旦上述各项都做到了，信任将在组织中自动增长。

上述大部分都是关于组织敏捷，而与Scrum、看板、PRINCE2或PMI等用在项目上的敏捷方法无关。可以在任何时候开始转型，但要进行投资。回报是更健康的项目，更少的失败，而且，由于项目是组织所做工作的很大一部分，所以为什么不从今天开始就获取收益呢？

管理人员对敏捷成功实施的四项首要贡献

就像前面提到的那样，如果得到了高层管理部门的大力支持，那么敏捷转型才有可能获得成功，而管理部门本身以敏捷原则作为行为依据是实现健壮的敏捷的先决条件。

下面将讨论，为什么上面提到的那四项是说起来容易做起来难：

第一项——及时的战略决策：

高层管理人员经常看不到他们自己持续地参与到项目中去的必要性。他们是对项目投入了大笔的资金，他们是会在项目超支或延期时生气，但他们却常常仅仅把自己看作是项目管理人员的问题升级对象。

一旦遭到损害，他们可能会处理变更请求，但他们没有意识到，他们原本可以通过更直接地参与到那些他们已经决定投资的项目中，帮助项目管理人员防止损害发生。他们仅仅提供“按需”决策。

一些敏捷方法试图引入“产品经理（PO）”这样一个角色来解决业务人员参与少的问题，他（她）们被授予了所有的决策权，可以代表业务人员。然而，我从来没有看到过这个角色真正地按预期方式工作。下面是一些原因：

1. 因为政治。不是所有的管理人员都根据相同的日程工作。
2. 因为组织不相信产品经理能够做出正确的决策。
3. 因为产品经理不了解这个角色的目的和性质。
4. 因为产品经理没有为履行这个角色接受过教育、训练和指导。

管理层没有意愿或能力参与到项目中去帮助及时决策的结果是，敏捷项目让人备受煎熬。

第二项——真正的下放执行决策权：

大约50%的项目都失败了。这可能就是为什么要反对将决策权下放给项目团队、项目经理（PM）或产品经理，因为“那些项目的结果证明，他们不具备承担那种职责的能力”。

不过，要是项目经理没有经验、没有接受过足够的培训，就被要求去管理对他们而言过于复杂而难以应付的项目，以及管理没有经验或缺乏恰当技能组合的团队，项目失败就不足为怪了。下面的原因解释了为什么管理人员会将项目委派给没有准备好承担那种职责的项目经理和项目团队：

1. 管理人员没有认识到（IT）项目天生复杂。
2. 没有合适的团队具备恰当的能力，但他们又想启动项目。
3. 许多人认为，只要“敏捷地工作”，一切都会好起来。
4. 涉及项目管理，有一种“它能有多难”的态度。

然而，项目复杂性通常不是来自于系统，而是来自人、政治和组织行为。任何方法都没有解释应该如何应对这些复杂性。

不出意外，不了解项目的复杂本性会导致糟糕的项目结果。而如果组织在开始时就考虑了以下几个方面的内容，那么会有很多收获：

• 他们如何根据技能和项目复杂性为项目分派项目团队。很多时候，项目团队分派是根据可用性，而不是技能。例如，“不管是哪个团队，哪个坐在板凳上就用哪个”。
• 他们的项目方法是否与目的匹配（通常，它要么太复杂，要么不够敏捷）。
• 他们培养组织的方式（光有证书是不够的）。

第三项——培养信任环境

在看过许多项目的失败后，管理人员可能不再相信他们的项目经理、团队和产品经理可以做正确的事。因此，他们坚持在项目事务上拥有最终决策权，虽然管理人员通常是参与最少的人，而且也因此无法做出最佳决策。除了糟糕的决策（那已经够糟糕了）外，这还会导致停工、资源浪费和延期。

组织支持敏捷方法，但他们经常没有意识到那会对组织行为产生多大的影响。如果是工作在一个控制-命令型的组织中，那么向敏捷转型（信任是一个先决条件）可能是个太大的飞跃，并不会奏效。

另一方面，组织确实想要获得敏捷所能带来的好处，他们必须在组织中不断地自上向下分析哪里需要变革以及如何变革。敏捷伴随行为方面的成本。下面列出了一些原因，说明人们为什么不愿意付出这种成本：

1. 管理人员不想离开他们可能已经使用多年的系统。
2. 已知的安全错觉和糟糕结果比尝试“未知”更让人觉得舒服。
3. 公司文化和政治阻碍了信任环境的形成。转型非常困难。
4. 管理人员没有看到他们在促进敏捷转型及言行一致方面的作用。

第四项——接受现实，错误会出现，而且总会出现

项目会将组织带到它们以前没到过的地方。不管你多缜密，不管你计划的多好，你都无法预测未来——尤其是多年后的未来。因此，项目团队会犯错，估计会出错，合同可能糟糕，等等。

而且，项目团队过于乐观，使得他们常常不得不在范围、成本或时间等众所周期的条件约束下交付。这样一来，你从开始就制定防止失败的计划，为了保证预算、最后期限等，你开始找捷径。你降低品质，缩减测试活动等等。这会导致错误，而这些错误原本是可以通过制定现实的项目目标来避免的。

没有错误的项目就不存在，也从来没有。借助敏捷技术，你可以避免将许多错误传递给客户或终端用户，但要做到这一点，管理人员必须认识到，他们必须：

1. 通过帮助整个组织变得更加敏捷来支持敏捷团队。认识到组织的所有层面都需要教育，旧有的习惯必须改变，比如，相关的会议、报告等。
2. 不再将不切实际的项目最后期限强加给项目团队。现实无法改变。
3. 不期待不可能事。没有错误的系统或项目是不存在的。

敏捷实施中应该避免的三大陷阱

关于管理人员如何帮助敏捷实施取得成功，我已经提到一些要点。另外，还有一些非常重要但在组织决定向敏捷转型时却经常忽视但可以导致敏捷实施失败的方面：

1. 没有认识到敏捷转型的组织阻力。
2. 没能确保有组织地使用敏捷，而采用了“它能有多难”的方法。
3. 忽视了项目管理最佳实践。

1.组织阻力

你会发现，在组织所有层面进行变革会受到阻力。在团队层面，大多数团队成员可能都深知敏捷的价值，但通常，部分团队成员会不买敏捷概念的帐：

• 他们不适应可视化。他们不喜欢或不想每天讨论他们正在做什么、他们已经完成了什么，等等。
• 他们不是很喜欢共享信息，而更乐于作为不可替代的专家。
• 部分团队成员只是喜欢接受命令。他们不喜欢为自己的工作负责，也不愿意承担责任。

在管理层面，向敏捷转型时也有一些障碍：

• 部分管理人员更适应命令-控制方法。针对如何从A到B的问题，他们对团队能够做出最佳决策缺乏信心。
• 管理人员不喜欢将决策权下放（给产品经理），他们忙于维护自己的职位，在部门层面进行着次一级的优化。
• 他们并不是十分清楚如何为敏捷团队提供支持，继续“像以前一样开展业务”，瀑布式思维因此继续存在。

2.有组织地使用敏捷

项目管理在20世纪60年代就已经出现了，从此以后就一直在发展，但由于敏捷方法看上去如此简单，关于如何在整个组织内使用Scrum或看板等方法，组织常常会忘了设定一些基本规则。

如果公司天生就是敏捷的，那么这可能就不是个问题——每个人从一开始就敏捷地工作，知道游戏规则。不过，大部分公司都使用传统PM方法多年了，如PMI、PRINCE2或IPMA。于是，当出台举措追求更高的敏捷性时，部分或所有项目团队就开始使用Scrum或看板，但每个团队都有自己的做法。

从一开始就有个方法，最主要的是为了有一个公用的词汇表，那样，项目的每位参与者都会对使用的语言、团队的协作方式、如何记录进展以及如何测量KPI等有相同的理解。

取得Scrum Master证书及了解事件、角色、工件处于什么地位轻而易举。但是，如何完成不是证书的一部分。有一件非常重要的事需要了解，就是敏捷不直观！因此，应该尽力说明所选的敏捷方法在组织中的使用方式，也就是如何。

此外，正如你需要控制传统项目组合，对于敏捷项目组合而言，这同样重要。通常，你投资的项目组合有数量限制，即你仍然只能开展一定数量的项目。因此，你需要排定优先级，并跟踪项目进展，一直使用同一组KPI，那样才有可比性。

3.忽视了项目管理最佳实践

有件事怎么强调都不过分，就是项目性质不会因为你开始使用敏捷方法和技术而改变：

• 项目愿景不变
• 项目复杂度和风险不变
• 预算不变
• 团队不变

许多人都以为，如果他们使用敏捷方法管理项目，那么项目会更容易做。这是不正确的。敏捷不会降低复杂度或风险，但具有透明度，因此，在问题/“障碍（impediment）”/“用户故事中的障碍（blocker）”/挑战出现时就可以看到，你和你的组织就可以及时应对了。

在敏捷项目中，针对障碍采取行动是一种控制和管理风险的敏捷方法。风险管理也是传统项目管理不可分割的一部分，但它只是你在项目中必须掌握的几个知识领域中的一个。

大多数传统方法从头到尾覆盖了整个项目，而应用最广泛的敏捷方法（如Scrum）则关注开发阶段需要实现的内容。在项目构思出现之后开发开始之前发生了什么？开发阶段结束之后发生了什么？如何交付给日常运维团队？最终用户怎么样了？实现了怎样的收益？所有这一切都没有包含在Scrum中，但应该包含，因此，为什么不好好利用传统的、已经证明有效的最佳实践的相关元素呢？

我建议对不同的方法保持开放的态度，避免教条式思维。最终，我们可能全都会因为喜欢而参与到项目中。我们喜欢挑战，我们喜欢在团队中工作，当我们成功时会获得很大的乐趣。

从企业的角度看，如果考虑了下面几项，那么可以最大可能地提高项目成功率：

1. 如果成立了项目管理办公室，那么请确定敏捷项目的KPI。如果没有成立，那么也要考虑敏捷KPI。此外，还要确定如何进行状态报告。
2. 在组织内开展自下而上的敏捷培训。需要高层及中层领导如何在行为上支持敏捷？需要团队成员承担什么义务以及敏捷团队有哪些职责？需要产品经理做什么？如果希望敏捷可以有效地发挥作用，那么只培训几名Scrum Master是不够的。
3. 实施敏捷需要文化变革，因为文化会不断地蚕食策略，所以要清楚你希望看到什么样的变革，要有一些目标，评估结果并根据结果采取行动。

敏捷之旅

敏捷不会在一夜之间实现。从传统项目管理转型到敏捷是一种模式的转换。从推式系统到拉式系统，从控制-命令文化到实现分权的信任文化。这需要时间，但良好的组织加上一些控制机制可以最大可能地帮助你更快地获得想要的结果。

当开始旅程的时候，要有生产力最初会下降的心理准备，但是要相信，这种投资很快就会收到效果。对组织进行培训、“辅导（coach）”和“指导（mentor）”。当每个人都知道别人对自己的期望是什么，你才更可能获得想要的结果。

最后但同样重要：即使敏捷项目的结果平均好于传统项目的结果，也仍然存在改进的空间。通过将传统方法的最佳实践应用于敏捷，从而根据环境将两种方法相融合，你可能已经部分地找到了提高项目成功率的方法。这里列举几个非常有用的传统做法：敏捷项目状态报告、收益实现、敏捷KPI、涉众管理、敏捷项目中的沟通、合同管理等。

关于作者

Annette Vendelbo热衷于项目以及什么能够让项目管理和方法有效运转。她有25年的项目管理经验，并通过Xvoto提供项目管理、PM及敏捷培训，并提供与（敏捷）方法实现相关的咨询服务，主要是基于环境的项目管理®。2014年，她创立了APMA——敏捷项目管理联盟。她在博客上发表有关现实生活中项目管理的文章。你可以查看她的Facebook页面以及在Twitter(@AnnetteVendelbo)上关注她。