第2章 规划项目

现在你手里有项目章程了。要是团队成员不能跟你一起编写章程,那就在项目启动会议上跟团队成员一起把它过一遍(请看10.3节)。要是团队成员已经熟悉了章程,那就可以跟他们一起做些有目的的规划和日程安排工作了。

规划和日程安排是两种不同的活动。规划是指制订带有发布条件的项目计划,而日程安排则是对工作项目的有序描述。

2.1 踏上征程

有了项目章程,每个团队成员就可以对自己接下来要干什么做些有明确方向的预先规划——或者,也可能提早知道自己还没有明确的方面。有了项目规划,就可以把团队成员的注意力聚集到预期的项目产出上来。

如果团队的人不多,比如不超过十个人,不妨与他们一起完成项目规划。跟团队成员商量接下来的几天或几周之内要做什么,同时要将项目的产出牢记心间。如果已经收集到一些需求,团队就可以开始原型化的工作,或是展开第一次迭代的开发工作了。要是采取敏捷开发过程,不妨将项目规划看作发布计划。

不过事情不会这么完美,比如人手不够,或者有太多的人参与原型化,甚至你根本不知道接下来该干什么。此时,可以让一些人或全部团队成员去修复上个版本留下的缺陷。请看13.1节。

2.2 使项目足以启动的规划

章程有了,规划是什么?管理层希望知道团队什么时候开发哪些特性。如何测量进度?项目何时完成?

规划不必完美无缺。实际上这也是做不到的。只要这个规划能让项目启动起来,同时能让大家看到成功的希望,就可以了。如果项目面临时间的压力(我接手的项目大多如此),那就要用时间盒来辅助规划活动。即使打算重新规划某个项目,项目经理也不必在一开始担心规划是否完美。

时间盒(timebox)是指特定的时间长度,个人或团队用它来完成某项特定的任务。个人或团队在这段时间内完成的工作量,就是项目接下来的工作的基础。如果有必要,个人或团队可以减少工作范围,以保证在“时间盒”内完成工作。

用时间盒来限制启动规划活动

——史蒂夫,项目组合管理高级总监

一般来说,我们会同时进行2~5个大项目以及15个左右的相关小项目。对于绝大部分项目来说,我们在启动时会先预计到底需要多少人力以及将会耗费多少时间。即使是为一个新项目做初始规划,也要保证耗时不长。

我们最近的一个大项目,预计耗时两年左右,需经历多次发布。我们把制订初始规划的时间盒设定为三天。三天过后,我们有了项目章程、项目规划,并制订出了第一次发布的发布条件,以及前三周的工作日程安排。就是这些,不过已经足够启动项目了。

我们最近的几个小项目(耗时不到半年),制订初始规划的时间盒设定为一天,其中包括安排一个为期两周的工作日程。当项目工作展开后,再根据执行初始规划得到的反馈,指导后续的规划。

有些项目已经完成了某些特定的功能,需要预测这些项目的发展和走向。我们会在项目前几周内进行初步的预测,后续几周内更新这些预测。到了8~12周的时候,对于何时完成哪些功能,我们心里也就有底了。我们没有做到尽善尽美,但是也不会在没有数据的情况下,浪费时间做过多无效规划。做一点规划,收集一些数据,再重新规划。这样做无往而不胜。

即使项目没有面临时间压力,要是为了得到“完美”的规划而花费太多工夫,时间的要求也会使这个项目变得越来越紧迫。

提示:要根据经验而不是预言来规划项目

经验式规划也就是指不妨先做少量规划,再根据实际过程中收集到的信息反馈来影响未来的规划,这样做具有很高的可行性。预言式规划则是试图预测未来,是很难奏效的,除非你有水晶球。应该尽量在项目中使用经验式规划和日程安排。

也许你听过艾森豪威尔那句名言,“规划毫无用处,但是制订规划必不可少。”①项目有太多的风险和不确定性,想在一开始就把一切都想好势比登天。从规划开始,每隔几周再重新规划,就像5.6节所述。无论采取何种生命周期管理项目,都得做好反复规划的准备。不要创建完美的规划,只要这个规划在被(很快)替换之前具备可行性就可以了。

① 1957年11月14日,艾森豪威尔在华盛顿特区国防行政准备会议(National Defense Executive Reserve Conference)上的讲话。


提示:以终为始 [Cov91]

开始规划时,要想清楚有多少内容需要写下来。发布条件(请看2.4节)可以使出资人和项目团队集中注意力。如果想减少制订规划的时间,至少要保证规划出发布条件和风险列表。必要时要反复修订规划。如果使用敏捷生命周期来管理项目,就不要做任何预先规划活动了。[Coh06]

2.3 开发项目规划模板

项目经理要用项目规划来整理想法,最好选择能在组织的更多项目中重用的形式。下面是我的项目规划模板:

  • 产品意图

  • 历史记录

  • 发布条件

  • 目标

  • 项目组织

  • 日程总览

  • 人员配备(人员曲线)

  • 建议日程

  • 风险列表

2.3.1 产品意图

简单描述产品,为什么公司要开发这个产品,它能为公司带来哪些效益,等等。发布版本的价值何在,它是否是后续发布版本(用三四句话)?如果已经在章程中写下了项目的远景,不妨在这里借用一下。

有时候,章程中的远景对于项目来说不够用。或者说,远景是供大的项目工程(一系列或者一组项目,请看14.1节)使用的。这类情况下,要确保当前项目的意图清晰无误。

多年以前,在TCP/IP协议还没有被整合入操作系统之前,我管理了一个工程,其产出是一个软硬件结合产品,其中包含了许多特性,每个特性都是一个单独的项目。我为工程制定了章程,其中的远景描述如下:“及时发布产品,供某某商业展使用。”有六个项目团队,网络团队是其中一个。他们对项目的意图定义是:“确保TCP/IP在第一次集成之前就能正常运作,并在整个项目中一直发挥作用。”他们的意图很清晰,而且与工程的远景相关,同时又非常明确。

基于项目(或工程)的规模和持续时间,每个项目团队(或子项目团队)都有其自己的意图。这个意图应与工程章程的远景在大方向上保持一致,但又不完全相同。

2.3.2 历史记录

如果是在管理某产品的后续版本,比如4.2版本后的4.3版本,就要复查之前或相关版本的历史记录。这个历史记录可以说明之前任何已知的技术债务(见附录B)。要复查的数据包括:发布频率、发布后发现的缺陷数、客户报告的问题,以及会影响到项目经理对质量的定义、对项目管理方式的任何内容。

提示:知道的越少……

对项目情况知道得越少,感到惊讶的几率也就越大。这适用于技术债务、新的架构、开发或测试风险或者制订规划等多个方面。只要在之前的项目中没有积累类似经验,就很容易遇到意外的情况。做一些规划,并做好反复规划的准备,这可以助你一臂之力。

如果客户习惯于每年发布一次产品,并且不会提出更多要求(按照摩尔的说法,他们已经是“大众客户”了,请看图1-2),此时项目经理有多种选择。第一种是拒绝管理层对频繁发布的要求。除此之外,可以使用版本火车(请看14.3节)或敏捷生命周期来进行更频繁的发布。如果需要打开或进入新的市场,在组织项目时,要考虑使用适合产品频繁发布的方式。

复查已发布版本中发现的缺陷的数量和类型,就可以理解即将使用的代码库中技术债务(请看附录B)的严重程度和类型。

如果客户在某个领域中报告了大量的问题,要看看到底是文档还是代码的问题(或是其他类型的问题)。对即将遇到的技术债务了解得越多,尽早掌控它们的几率也就越大。

2.3.3 发布条件

要详细列举出项目产品的关键可交付物。想识别出它们,不妨问一问:“要是不那么做,我们还能发布产品吗?”要将功能、性能和质量要求都涵盖在内。要想了解更多细节,请查看2.4节。

2.3.4 目标

项目经理在撰写项目章程时,也许已经对目标有所了解了。在准备好制订项目计划时,也许对目标已经了解得更多了。如果在制定章程时不知道任何目标,这时应该好好想想了。

已知的目标也许隶属于以下几类。

  • 产品目标也许包括这样一些需求,它们已经被设定好优先级,但是不承诺在当前发布版本中完成。这个列表也许已存在于产品的待办事项中(请看16.6节)。

  • 项目目标也许是诸如性能标准之类的目标,对它们的要求会高于一般需求,或者是“在产品交付时,要将未解决缺陷的数目从50个减少到40个”。尤其是在管理一个工程的情形下,每个子项目的目标要特定于该项目所在的领域。项目团队要解决某些特定的技术债务,也许也可以作为项目的目标。

  • 团队目标可以是“增加产品的自动化冒烟测试所占的百分比”。团队也许希望改进某个特定功能的性能或可靠性。

  • 组织目标可以是“减少项目的耗费时间,以提升组织的敏捷性”。②

② 感谢Bill Ramos提供该示例。

如果目标已经在项目章程中详细列出,在项目规划中就不必再写进去了。二者选其一,将项目目标明确出来即可。

2.3.5 项目组织

要明确说明团队在项目中的职责分配,指明项目经理如何使用生命周期组织项目工作,要采纳哪些关键实践,以及是否有决策人可以影响当前项目。如果你知道(或者怀疑)需要一些原型化的工作,要在这里说明。“史蒂夫和詹妮将会为那个功能集合搭建架构原型。比尔会进行同步的测试工作。因为时间紧迫,项目团队会选择可以让我们持续复查代码的技术。”

要说明项目的一般运作方式。比如,在项目启动时加强整个项目团队意识,招聘新人,开发包括代码和文档在内的完整功能,编写所有的代码,同时检查一下(在那个时间)可以记录些什么,诸如此类的事情。

此处的实际发生细节,取决于项目所采取的生命周期模型和团队的结构。要是有一个产品负责人专门负责做出与产品相关的所有决策,可以考虑是否要给他一个任命。如果有多个人同时决定功能特性以及彼此之间的权衡,就应该把这些决策人和他们负责的领域都列出来。

如果使用的是受时间盒限制的迭代,要说清楚每个时间盒的长度是多久。如果使用版本火车的方式,要说明每列火车持续多久。

2.3.6 日程总览

应该创建一个日程总览,其中标有主要的里程碑,还要说明人们从这些里程碑处可以得到什么。如果使用迭代或增量式开发,要解释迭代(或增量)的持续时间,并说明在每个迭代(或增量)结束后可以预期得到哪些产出。不要把工作分解结构(WBS)放在这里,要是有的话,可以给出指示,让希望了解更多细节的人去自行查看。无论使用何种生命周期模型,如有beta测试或是早期的客户发布版本,要把这些作为里程碑对外说明。

工作分解结构(Work Breakdown Structure,WBS):它是任务的组织形式,展示它们之间的依赖、持续时间和所有者等信息。WBS级别越高(在项目中出现得越早),能得到的信息就越少。WBS是会随着项目进度而演变的。

日程总览让我的领导知道项目的实际进展

——特里,项目经理

目前我正在管理第二个项目。领导们不相信这个项目会比上一个需要更多的客户参与。我编写了带有里程碑的项目总览,向他们说明情况。下面就是它大概的模样。

日期         里程碑

7月1日      项目启动。

7月15日    向露辛达展示Web界面的原型。(待续)

7月30日    向露辛达和厨房职员们展示厨房界面的原型。

8月15日    内部交付Web和厨房界面。

8月30日      向露辛达挑选的5个客户交付早期版本(beta测试)。

9月1日      开始beta测试。

9月30日      结束beta测试。

10月30日    系统上线,包括所有的客户订单和厨房的界面。

当我的领导们看到我在做什么之后,他们就意识到为什么我要提出对时间、人力和客户接触的请求了。

对于复杂的项目来说,如果在开始之间就已经感觉到日程安排上的风险,不妨考虑多准备几个方案,让出资人进行选择。图2-1中提到的组织就是基于矩阵的方式来组建项目团队的。

项目经理要确保自己可以理解项目的价值,而不是只看到不同方案的成本。如果交付的产品不能达到发布条件,其相关的方案也就不能提供足够的价值了。

图2-1 以矩阵方式给出项目团队的不同运作方案

2.3.7 人员配备

很多项目经理不能控制项目团队的人员配备。如果在项目开始的第一天就把所有的人都召集到位了,那么出现人员变动可别吃惊。如果需要从其他组或是团队中调动人手,要在这里说清楚:要在何时需要多少、何种类型的人员。请看第7章,以了解具体措施。

2.3.8 建议日程

项目经理要根据理解程度,列出主要的里程碑。如果有反映最初日程安排的甘特图,要在此处加入访问指示。当然,在重新规划后,要记得更新正在使用中的甘特图,以及时反映项目当前状况。将使用中的甘特图与项目的规划分开,这样更容易更新。

我喜欢使用黄色的即时贴来安排日程,所以在我的项目中很少使用完整的甘特图。我也因为说了下面的话而被大家所知:“要想了解当前最新的WBS,去项目房间的墙上看看吧。”(如果没有项目专用房间供张贴甘特图使用,就要使用公共区域,来让大家都能看到日程安排。这样一来,如果日程有问题,项目团队也可以早点提醒项目经理。

波浪式规划方式(请看5.6节)用得越多,在第一波之后需要加入的细节就越少。

提示:小心过早细化日程

要反复修订项目日程,随项目进程补充细节。请看第4章,以获得更多信息。如果过早地向出资人提供了非常详细的日程,他们就会认为项目中几乎没有风险。他们会注意到日程中的项目结束日期,并以此作为项目真正的结束日期。

2.3.9 制订项目风险列表

在项目规划中,至少要将排名前十的风险记录在案。还要经常监控这些风险,并在适当的时机更新这个列表。如果觉得项目目前的风险不到十个,不妨跟项目团队一起坐下来,进行一次头脑风暴[DL03]。

要尽早开始识别和管理风险。图2-2是我从一个真实项目的启动过程中拿过来的风险列表示例。

图2-2 风险列表

随着项目的进行,要更新风险列表。不妨使用第8章和第9章中的实践,来帮助规避风险。

2.4 制订发布条件

发布条件会告诉你项目中“完成”的含义(见[Rot02a]和[BWe01])。有些项目经理会在下面这些状况下发布软件:某个资深经理说该发布了、测试人员“核准”了,或者是人们觉得时机成熟了。问题是大家对于“完成”的定义各不相同。

制订发布条件不是为了责怪哪个组的人,而是要为产品是否可以发布提供一些客观的评判标准。出资人和客户可以用发布条件作出合理的决策,对产品的质量和风险做出判断。

制订发布条件时,要先判断当前项目的关键因素是什么。例如,为什么公司要做这个项目?为什么客户会买这个产品?

利用发布条件,项目经理可以将整个产品的职责分工贯穿到产品的发布之中。比如,销售人员能够卖出满足这些条件的产品吗?技术支持人员能够为这个产品提供支持吗?培训人员能否制订培训计划并展开相关培训?当项目经理与组织各个职能部门的人共同商讨“成功”的含义时,他们会意识到自己不只是完成了分内的工作,而且也为项目经理指明了成功的方向。

项目经理一旦知道了成功的含义,就可以定义这个项目最重要的因素——发布条件了。

使用下列步骤来制订和使用发布条件。

  1. 确定当前发布最重要的因素,这样可以将监控发布条件的活动贯穿项目始终。

  2. 草拟发布条件。

  3. 让发布条件符合SMART原则:确定的、可测量的、可达成的、相关的和可跟踪的。请看2.4.3节。

  4. 获得项目团队与高层管理人员认可。

2.4.1 确定当前项目最重要的因素

当前项目的关键因素是由组织的需要和客户的需要共同组成的。客户在购买产品时,不会考虑其中有无缺陷或是缺陷数目,而是要看到这个产品解决了困扰客户的某个问题。在制订发布条件时,是应该考虑缺陷或缺陷水平,但是要确保发布条件中不仅仅包括缺陷相关的内容。想想你要为客户解决什么问题——无论是内部客户还是外部客户。

有时,发布日期是最重要的;有时,某个功能或一系列功能决定了项目的成败。通常来说,日程安排、功能特性和低缺陷率共同构成了项目的关键因素。就像1.2节中提到的,这些都取决于客户和他们的期望。

丽塔在一个依赖于现金流转的创业公司工作。公司的资金尚未完全到位,所以非常希望能早日交付产品,这样才能获得足够的现金维持公司生存。在过去的前三次发布中,唯一的发布条件就是发布日期,产品必须要交付给客户,公司才能在法律上确认产生收入。一旦公司成功熬过前几年,并且资金也全部到位后,就会加入其他的发布条件,诸如缺陷数目、测试过程、代码冻结状态(开发人员停止修改发布版本代码的次数)。

丽塔是这样说的:“当我们还处于创业阶段时,必须要保证把头伸出水面,维持生存。最开始的客户非常想要我们的产品,而且愿意一起工作。去年的版本发布后,其效果让我们都觉得非常惊讶。突然之间,客户开始关心缺陷问题了,他们之前从未如此关心过。管理层想知道我负责运转的测试组是什么样的状况,这使我压力倍增。唯一能让我舒心的,就是我已经与整个项目团队和高级管理层事先确认过:早先设定的发布条件可以满足要求。但是我们没有意识到,当初没有完全弄清楚这个产品的需要。现在我们明白了,不能仅仅使用日期或是缺陷、测试数目来判断版本是否能发布。我们需要从大局出发,这样才能知道应该何时发布软件。

2.4.2 草拟发布条件

事先草拟一些发布条件是很有用的,这样就可以以它们为基础展开讨论。(如果有测试经理参与项目,项目经理可以请他完成或是与他一起草拟发布条件。)制订条件时,如果条件许可,要在上市时间和客户需求、缺陷状况、性能和可靠水平之间达成平衡。没有必要第一次就把所有的条件都订正确,只要能给大家一个讨论的基础就行。

在草拟发布条件时,要在纸面上注明“草案”字样。应该使团队成员和出资人知道这些只是供讨论用的条件草稿,而不是已经做出的承诺。

丽塔在开始时写出了一系列发布条件的草稿,供项目经理和团队成员讨论之用。下面就是丽塔的条件草稿:

  • 所有代码必须针对所有运行平台编译并构建。

  • 没有高优先级的bug

  • 所有未解决的bug和临时解决方案都要记录在版本发布说明中。

  • 所有计划好的测试都要运行,要保证通过率至少为98%。

  • 在最后三周内,未解决缺陷的数目要不断下降。

  • 在发布之前,功能X要由开发人员完成单元测试,由测试组完成系统测试,由客户A和客户B完成验证。

  • 准备6月1日发布。

  • 所有未解决的缺陷都要由跨职能团队进行评估。

不过,当她与项目经理(下面简称PM)讨论后,丽塔意识到,她的初始条件并不完全符合客户或公司的要求。没错,客户很关注缺陷问题,但他们还没达到丽塔所关心的这种程度。实际上,只要几个主要客户对发布版本满意,其余的客户也就没什么大问题了。

刚开始的时候,对于丽塔能够从客户的角度出发看待整个发布,并能为整个发布提出一个照顾到各方平衡的方案,她的PM非常惊讶。他原本认为丽塔会更多地从传统测试经理的角度出发,力图提升质量,降低缺陷率。但是,丽塔从之前在公司做项目积累的经验知道:在对某次发布做决策时,低缺陷率只是考虑因素之一。

丽塔与PM和其他团队成员一起,修订了发布条件,并得到如下列表:

  • 所有代码必须针对所有运行平台编译并构建。

  • 没有高优先级的bug

  • 所有未解决的bug和临时解决方案都要记录在版本发布说明中。

  • 所有计划好的测试都要运行,要保证通过率至少为90%。

  • 在最后三周内,未解决缺陷的数目要不断下降。

  • 在发布之前,功能X要由开发人员完成单元测试,由测试组完成系统测试,由客户A和客户B完成验证。

  • 准备6月1日发布。

这些条件没有覆盖丽塔对于发布版本的全部要求,但是它们已经说明了对于当前发布的所有关键因素:发布日期、足够好的软件、一个已经完成测试并由两个客户验证通过的特定功能。测试组计划好的测试只要求通过90%,丽塔对此有些失望。不过在听到其他人的说明之后,她接受了这些发布条件,因为发布日期更重要。对于发布条件中不再要求在临近发布时由跨职能团队评估未解决的缺陷,丽塔也有些担心。不过,产品经理向丽塔保证,他已经跟PM讨论过这个问题,而PM将会把相关意见转达给市场和支持部门。

2.4.3 让发布条件符合SMART原则

在草拟发布条件时,要确保团队每个人对其的理解完全相同。我使用SMART原则——确定的(Specific)、可测量的(Measurable)、可达成的(Attainable)、相关的(Relevant)和可跟踪的(Trackable)——来检查条件是否合理、客观。T表示可跟踪性,这可以让整个团队明白:在创建发布条件时,我们要能够在项目的整个生命周期中评估这些条件。

对于当前项目的产品来说,每个条件都应该是确定的。如果一个条件是可测量的,就可以根据这个条件来评估软件。发布条件并不是那种必须要花些力气才能达成的延展性目标(stretch goal),所以要让每个条件都是可以达成的。通过评估产品是否符合客户和管理层的要求,来确保发布条件的相关性。如果条件是可跟踪的,那就可以在项目进行过程中评估条件的状态,而不只是在项目的最后一周才这样做。

“搜索必须在5s内返回第一组结果”是一个客观而且可测量的条件,可以对它展开测试。“所有未解决的缺陷必须由跨职能团队复查”是另外一个客观而且可测量的条件的例子。跨职能团队是否完成对未解决的缺陷的复查,其结果是确定无误的。

“性能要好”就是一个模棱两可的条件。要把它改成客观而且可测量的条件,应该这样描述:“性能场景A(对应于用例A)要在10s内完成。”要给出特定的场景,这样人们就可以引用它,并为其提供度量方案,团队也可以知道他们是否达成了性能要求。

2.4.4 在发布条件上达成多方共识

得到了合理的发布条件之后,就该取得各方面对它的共识了。如果有人对草拟的条件有负面意见(“不,我们做不到”),要找到他们担心的原因。产生发布条件的过程,也是揭示众人对于产品和项目的假定和忧虑的过程。在就发布条件获得大家共识的过程中,可以提下面这些问题:

  • 在发布日期之前,我们是不是必须满足这个条件?

  • 要是我们不能在发布日期之前满足这个条件,会发生什么?

  • 如果不能满足这个条件,我们的产品或公司是不是会因此而承担风险?人们的安全感是不是会因此被破坏?

通过回答这些问题,整个团队就会更加注意当前发布版本的要求。

可以利用下面这些方式来获得大家的共识:草拟发布条件,针对其展开讨论,并在团队会议上就其达成共识;与整个团队草拟发布条件;与团队中的各个职能经理一起草拟发布条件。有了发布条件草案后,在项目团队会议上将其作为一项讨论议题。我喜欢与整个团队一起讨论并产生发布条件,因为这样一来,整个团队都会对其形成归属感,而不仅仅是我或管理层。不过,要是项目规模很大,或是团队之前从未用过发布条件,而且希望每个成员都能理解工作目标的话,还是先试着在团队会议之前草拟一份发布条件吧。

一旦获得多方共识,就可以用这些条件来监控项目了。

2.5 使用发布条件

到产品发布的时候,发布条件只能有“满足”或“未满足”两种状态。不可能部分满足某项条件——其实就是没有满足。在项目经理与高层管理者讨论软件产品目前的状况时,这种二元的方式是很有用的。如果只是说部分完成了,他们会认为你已经完全搞定了;如果说还没有满足某个条件,他们就会认为你还在努力工作。

在团队会议中,要跟团队一起讨论距离满足发布条件还要多久。整个项目过程中,在进行讨论的同时去看看项目仪表板(见第11章)的状态,整个团队可以评估当前项目的完成度是多少。如果项目有正式的系统测试阶段,可以将发布条件作为测试状态报告的一部分。

发布条件可以作为早期的警告信号,让大家知道团队可能无法准时发布当前版本。曼尼是一个项目经理,他所带领的六个月的项目目前进展到一半。曼尼评估了距离发布日期的进度,担心团队无法按时交付。他打算跟团队一起制订发布条件,让大家更加了解这次发布要达成的目标。

在接下来每周的项目团队会议上,曼尼用发布条件来确认项目在不断取得进展。这样连续做了几周,效果都不错。直到有一周,在评估发布条件时,一个工程师说:“我做不到。我试过很多种方法,看来还是无法在交付日期之前满足这个条件。”曼尼说:“那好,我会去跟上面说说看能做些什么。在去之前,还有人觉得哪些条件不能满足吗?”另一个工程师说:“在发布之前,我无法让性能做到如此优秀。咱们当初讨论发布条件的时候,我觉得是没问题的,但现在我知道那是无法做到的。”

使用发布条件,曼尼可以得到项目进度的一些早期数据。对于这个团队来说,在进行到三分之二的时候知道他们无法达成发布条件,总好过在最后一刻才发现问题。项目经理在了解到项目的真实状况后,可以就此与管理层沟通,看看在哪些方面进行折中,可以产生最现实的结果。在这个例子中,为了让产品满足发布条件,曼尼可以就发布日期进行重新谈判。

理想状况下,项目经理可以随着项目进度评估发布条件,并在项目预期结束时满足这些条件。不过人生不如意十之八九,项目也是如此,发布条件不可能总是能够达成的。发生类似情况时,要坦诚面对现实。

在必要时变更发布条件

使用发布条件,可以让项目关于“完成”的定义保持稳定。不过,在下列情况发生时,项目经理要考虑改变发布条件:进一步了解了这个项目中“完成”的含义时;认识到无法在预定发布日期前满足所有发布条件时。

如果进一步了解了“完成”的含义,不妨问问自己之前关于发布条件的问题:我们是不是必须要满足发布条件?要是没有满足发布条件,会发生什么?请看2.4节。

假设项目经理所在的项目无法满足发布条件。首先,要跟团队确认为什么无法满足条件。接下来,向管理层解释无法满足条件的原因。促使管理层向项目团队解释目前的状况,就像这样:“我们曾经认为这些条件很重要,但是现在知道发布日期是更重要的。我们将会准时发布产品,即使不能满足所有的发布条件。”如果事实如此,项目经理可以让他们补充:“我们会找出这次不能达成发布条件的原因,并在下个项目时注意不再发生同样的问题。”如果不向团队解释,他们会觉得自己正在玩日程排定游戏,请看6.1节。

铭记在心

  • 项目规划是在不断进行的,这只是开始。

  • 为项目团队、出资人和项目经理自己制订发布条件,以明确定义“完成”的含义。

  • 项目规划不必完美无瑕,但是它必须存在。

目录