希望是我们最重要的策略 - 项目经理应该小心的游戏之二

几年前，一个资深经理打电话给我，说道：“我们有个项目出问题了。在启动的时候，我们充满了希望，但是现在看来已经不可能了。”我问了几个问题，发现他们之前从来没有做过类似的项目。相对以前，这个项目的规模更大，使用新的开发语言，基于新的平台，而且日程安排更短。

整个公司的未来都押在这个项目的成功上，问题是它比以前做过的项目都要复杂，而且要求也更高。他们唯一的策略就是“希望”。

他们没有安排任何关于项目所在领域、使用的开发语言或新操作系统的培训。他们对这个项目希望能够达到的时间要求，也是以前从未做到的。

仅有希望，不足以交付一个成功的项目。

讲求实效的项目经理会这样做：

识别风险并记录下来。风险可能来自于技术（新的开发语言、新的平台）、日程安排（时间过短、人太少），很多时候两者皆有。

不到万不得已，不要选择瀑布式生命周期。为什么？因为你没有任何数据足以成功支持瀑布式需要的前期计划过程。要是你从未做过类似的项目，用迭代进行原型化，或者通过迭代开发几个功能，看看会是怎么样一个情况。

可以用“哈德逊湾式启动”看看是不是能做出些什么东西。要使用即将使用的新的开发语言、操作系统、数据库以及类似新技术，这样做效果尤其好。“哈德逊湾式启动”能够让团队了解要做的东西，而且可以揭示一些目前尚未发现的风险。

确保大家具备相关的技术能力，还有解决问题必备的领域知识。有必要的话可以进行培训。让大家学习项目中要用的开发语言，这些投入比起白白浪费时间所付出的成本要低。

考虑所有工作都采取迭代的方式进行，特别是项目规划和日程安排。

由于缺少经验和专业知识，可以寻求相关的帮助和信息。跟团队成员一起商量如何能让别人了解他们的工作进展。

制订里程碑条件（里程碑也可以是迭代的）。在管理层复审会议上审查这些条件。即使管理层或出资人不愿意做复审，项目经理也可以主导这些会议。如果不知道怎么样才能让项目正常运转，可以按里程碑周期性审查项目进度。

不要指望仅凭希望就能得到好的结果。

作为项目经理，你的工作就是要计划、再计划，并努力工作，以得到最好的产出。以下这些实践可以帮你达到目的。

使用有时间盒限制的迭代，这样所有的人都可以看到项目的进度。

使用速度图表展示项目进度。要让大家都能很明白地看到进度（或匮乏的资源）。这样一来，特别是在需要帮助的时候，这些数据可以拿来使用。







译自《Manage It》原书第4章第2节：
~~~~分~界~线~~~~~~~~~

哈德逊湾式启动

设想你所管理的项目对于你和团队来说，完全是从未经历过的。你也不知道所在的环境是不是支持可用的工具，从何入手估算项目工作也毫无头绪。不妨考虑使用短期迭代来开始工作，比如“哈德逊湾式启动（Hudson Bay Start）”。

“
哈德逊湾式启动”方式源自17世纪加拿大东北部的哈德逊湾公司。这家公司配备了运送皮毛的商船。为了确保商船不会忘记需要的东西，他们会在距离哈德逊湾几
英里的地方先临时停留一段时间。由于离海湾并不远，商船可以确保他们不会忘记任何工具和给养——在离开文明世界进入茫茫大海之前。使用这样一种启动旅程的
短时间方式，他们能明确知道自己能否可以安然过冬。

“哈德逊湾式启动”技术可以让项目团队先尝试在项目的实际环境中开展某些工作。项目经理应尽量缩短这个过程。（“Hello World”程序也许就够用了。）关键是要让团队了解到，在当前项目产品所在的领域中实际工作会是怎样的状况。

如
果项目经理和团队对于任何工作都没有头绪，不妨考虑用时间盒来限制“哈德逊湾式启动”。从可以在4个小时之内完成的工作开始。（这不一定是某个真正的功
能。）团队有了一些成果之后，可以分析这次活动。团队会开始了解如何估算要做的工作。如果还是知道得不够，可以使用短期迭代，然后再决定接下来要做什么。

“哈德逊湾式启动”会起到多方面的帮助作用。首先，团队获得自信心，知道自己能够取得成果。在进行估算时，由于完成过一些相关工作，他们可以有更深的理解。此外，团队还能对如何组织某些任务有所概念。“哦，如果想并行开发这些任务，我们得对代码进行分支，之后再合并。啊，这就是说我们要做阶段整合工作。相对仅在主线上开发，这会花更多时间。”

听到这样的谈话，也就说明人们开始发现并明确表达了风险，项目经理就应该把这些风险记录在“停车位”（见附录B）中，并在稍后或是在安排日程时处理。