下面是小编帮大家整理的屁股着火――项目经理应该小心的游戏之六，本文共10篇，希望对大家有所帮助。本文原稿由网友“neiyx”提供。
篇1：屁股着火――项目经理应该小心的游戏之六
一天，一封来自公司大人物的紧急邮件把你招呼到公司，邮件里说：“别弄那个项目了，赶紧开始做这个吧！”
可以确定，如果此事发生一次，它就还将多次重演。项目经理和团队都会周旋于几个项目之中，或是在两个项目之间不停切换。不管是哪种状况，项目经理都陷入多项目、多任务切换的泥潭，而且整个团队亦是如此。项目经理知道自己无法取得任何成果，所有项目的紧急程度却在不断攀升、攀升、攀升……
当管理层害怕或无法一次将精力集中在一件事情之上时，就会发生屁股着火的状况。有以下几种形成原因：技术人员过去就曾延迟交付，公司没有战略规划，或者公司的战略规划没有分解成足够详细的具体工作规划。
项目经理可以采取下面这些行动。
按小时间盒迭代进行规划，在每个迭代边界都开始新的工作。要达到该目的，迭代必须足够短，比如一周或两周，这样才有机会开始新工作。
如果无法管理迭代，就按功能逐个实现，使用按阶段式的交付。
将采取这种策略的成本告诉管理层，让他们选择是要解决时间上的危机，还是要付出额外的成本，
参见16.7.1节，了解如何帮助管理层计算成本和收益。
策略确定后，帮助公司检查相应的具体措施。可以这样问：“根据该策略，我们会得到这样的结果。这真的是我们想要的么？”
项目经理可以调整估算方法，让团队更容易达到最初的估算日期。如果团队无法满足估算日期，管理层可能会别无选择，只能让他们去做别的事情了。保证大家都用“小石子”式的方式（见5.8节），而且尝试使用持续集成（见9.1节），这样团队就可能完成一些工作。
有时，如果客户觉得还不需要目前的产品，也会发生“屁股着火”的状况。管理层觉得团队没有完成这个产品的必要，他们想让所有的人或者绝大部分人去参与别的项目。既然如此，要让大家以短期迭代方式工作，而且在项目启动时就要知道是否存在会导致项目推迟的原因。还要确保管理层已经制订出了项目组合方案，而且目前也在管理该组合方案。请参见第16章。
“屁股着火”会浪费所有人的时间。不过，管理层有时就是无法改变他们的管理风格，或者就是不相信同时进行多个项目会浪费时间。如果你陷入此类状况，不妨考虑如何创建一个单一项目的工作环境，这样你和团队都可以成功取得进展。
本文出自：blog.csdn.net/MagBryan/archive//01/05/3715138.aspx
篇2：拒绝女王――项目经理应该小心的游戏之三
有些老板就是不愿意面对现实，你告诉他们：“我们无法达到你对时间上的要求。”他们就好像根本没听见，看着你，然后告诉你：“我相信只要你上心，就一定能按时搞定。”你坐在那里哑口无言，他们却高高兴兴地走了，好像项目在他们给出的日期前一定可以交付。出现这样的状况，你就是碰见“拒绝女王”了。
有不少原因会引发“拒绝”。我所见过最常见的原因，就像上面提到的经理，他希望鼓励项目团队。有时，人们拒绝是因为他们害怕项目无法在截止日期之前完成，他们不会管你说什么，这就是鸵鸟效应。有时，公司高层相信：如果设定模糊或是不可能的日期，项目团队就可以早于他们自己预想的时间完成项目。
可以用下面的方式应对“拒绝”。
找出为什么你的经理表示拒绝。尝试用一些与上下文无关的问题（见1.5节），以此来理解项目背后的原因。比如，你可以问：“对这个项目来说，要怎么样才算成功？”
写下项目的风险及其潜在影响。用高、中、低来讨论严重程度和暴露程度，不要用数字。不拿你制订的日程当回事的人，对这些风险数字也不会认真。
展示你所能做到的事情，并测量团队在项目中的实际开发速度。没错，这里用迭代是非常方便的，而且速度图表可以告诉别人项目的真实现状。
保证参与项目工作的每个人都有相关领域的专业知识。
如果管理层认为“拒绝”是鼓励团队的方式，建议他采取其他的鼓励技巧。通常，这意味着让他去干点儿其他对团队有益的事情（比如通过谈判去缩小需求的范围），或者将他的注意力吸引到别的项目上去，
管理层可能认为拒绝现存问题或潜在问题可以鼓励团队，其实这反而会对团队形成障碍。将他们的注意力转移到其他项目上是一种很有用的技巧，可以让他们不再总盯着你的项目。
只要项目经理能够接受现实，“拒绝女王”就不一定能造成灾难。
有个团队试图说服项目经理接受项目的现实。失败几次后，他们放弃了，并且决定自己组织起来，忽略项目经理的存在。他们不再参加项目团队会议，并且将项目经理的话抛在脑后。他们开发了项目的部分功能，并且产生了一些数据（不过不是速度图表）。几个月之后，大家都看出来项目经理根本不了解目前的状况，此人也因此被炒了鱿鱼。可这时，项目团队也已经损失了很多时间，他们很难再控制什么时候交付哪些功能了。
现实总是会在某个时候跟“拒绝”面对面，这不可避免，而且这就是“拒绝女王”为什么只是规划游戏，而不会总是造成灾难的原因。当管理层看到了真正的现实之后，项目经理要确保自己有部分可以工作的产品、可以展示的数据，让管理层可以跟你讨论接下来能够做些什么。此时也是讨论“有哪些事情可以不做”的好时机，这样你就可以完成当前的项目，并且为后续项目做更好的规划。
如果项目经理总是遇到“拒绝女王”，那么在进行管理的时候，可以把下面的方法集成进去，大家也就可以看到实际进展了。
使用有时间盒限制的迭代，这样所有的人都可以看到项目的进度。
制订排定优先级的产品待办事项。团队可以按照功能的业务价值，从高到低逐个实现。等到出资人如梦初醒，终于意识到项目无法按他给出的日期交付时，团队也已经开发完成了若干高优先级的功能，这样项目经理也会得到一些有价值的东西。
本文出自：blog.csdn.net/MagBryan/archive//12/28/3629557.aspx
篇3：日程等于承诺――项目经理应该小心的游戏之八
我们都知道，日程安排只是估计而已，不过是大概猜测罢了，项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测。日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺。
如果面对上述困境，可以问问如下两个问题：
你是否关心团队交付的东西？
你是否关心产品的质量如何？
要想让有关项目日程的谈话富有成效，就得讨论项目后面的驱动因素、约束和浮动因素；应该商量在截止日期之前，至少有哪些功能是必须要交付的，这些功能应该达到什么样的质量标准。如果相关人员还没有准备好讨论项目日程、功能集合和缺陷水平，那么任何关于日程应该作为承诺的讨论都显得为时过早。
当资深管理层希望得到承诺时，我喜欢用信心水平与他们沟通：“我有90%的信心在8月1日发布。如果允许在10月1日交付，我有100%的信心。”我会告诉他们这两个信心日期之间我们必须要做的事情，也因此而深入理解了将日程作为承诺对我来说意味着什么。
我还喜欢使用“逐步逼近的日期（date-for-a-date）”，
“我可以告诉你，下半年发布没问题。现在我可以把时间限制在某个季度（给出一个日期），然后可以限制在某个月（另一个日期），接下来（给出另一个日期）就是我们要发布最终版本的日期。”
不过我最喜欢的技巧还是使用有时间盒限制的迭代（持续两到四周，不能更长了），同时使用按优先级排好顺序的待办事项列表。这样的话，就可以应对任何时间的发布要求。项目经理明白，每个迭代的成果都可以投入正常使用。项目经理也知道，最重要的需求已经先实现了。如果管理层想发布，没有问题，因为产品已经整装待发。开发人员不必再做出任何承诺，反而是项目经理需要从提供需求的人那里得到承诺，因为他们要说明哪个需求在何时需要。
如果有人要项目经理承诺一个日期，那就考虑如何组织项目吧。试试用迭代，或者尝试用“逐步逼近的日期”，要不就用带有日期估算的信心水平吧。但是不要只承诺一个日期。这简直就等于是为墨菲敞开大门了[1]。你可以承诺一个日期，但是总会发生一些意外，让你的承诺变为水月镜花。
[1] 作者此处是指墨菲定律（Murphy’s Law）会发生作用。——译者注
本文出自：blog.csdn.net/MagBryan/archive//02/03/3859780.aspx
篇4：分散注意力――项目经理应该小心的游戏之七
我曾遇到这样一个经理，他的原话如下：“我希望你能在项目A上花50%的时间，在项目B上花30%的时间，在项目C上花20%的时间，在空闲的时候，你能看看给老大的报告么？”我答道：“什么空闲时间？”
“分散注意力”就是与多项目、多任务相关的游戏。如果管理层无法把精力投入到一个项目或是工程的策略之中，就会引发此游戏。他们不会对每个项目说“是”或“否”，也不会问“什么时候？”，而是对所有的项目点头称是。
项目经理可以采取下面这些行动。
与工程团队一起尝试16.7.1节中的解决方案，特别是有助于工程团队或管理层团队判定先做什么、后做什么的方法。
如果管理层坚持要你和你的团队同时进行多个项目，可为每个项目设定一周的迭代，并确保在每个迭代结束时有可发布的产品，
我使用一周的迭代，人们就能在这一周内将注意力集中在一个项目上。一周结束时，到了周末，人们就可以改变关注点了，大家可以不再考虑眼前的项目，而是开始思考下一个项目。
如果无法管理迭代，那就按功能逐个实现吧，使用按阶段交付方式。要保证每个项目都有发布条件，这样就能完成每个项目最低限度的工作量。
就像在“屁股着火”中提到的一样，将这样做的成本告诉管理层，让他们知道在时间上的危机和付出额外的成本之间进行权衡。参见16.7.1节，以了解如何帮助管理层计算成本和收益。
确保已经对需求进行过优先级的排定，而且可以赶紧完成一些工作。“分散注意力”游戏的发生，有时是因为一些项目干系人不相信团队能够按时交付。他们想让项目经理和团队同时做几个项目的工作，这样能让他们更快看到成果，并由此产生安全感。他们错了，但是却没有认识到这一点。
如果项目经理所在的组织经常“分散注意力”，那就准备采用一周一次的迭代吧。没错，这样做很困难。你必须跟团队成员一起，将需求打散成足够小的部分，他们就可以在一周内取得工作进展。如果不能帮助团队转向在短期内开发小批量任务的方式，你们就永远无法取得成果。正如15.3.2节的文本框中所提到的，团队会经常产生延迟。作为项目经理，你有责任帮助大家完成工作，同时帮助管理层不要陷入“分散注意力”的泥潭。
本文出自：blog.csdn.net/MagBryan/archive/2009/01/07/3728939.aspx
篇5：幸福日期――项目经理应该小心的游戏之五
我遇到有些组织，他们有个不成文的规定：绝不讨论项目日程，这种情况我见得太多了。管理层想要一个日期，项目团队就会说：“当然，没问题，就圣诞节吧！”但他们不会明说是哪个圣诞节。
最后，当某个圣诞节到来之时，已经过了不少日子了，人们开始讨论日程安排。而这时项目已经错过不少里程碑的交付日期，甚至有可能几个早先期望的项目结束日期都已经过去了。
我曾跟这样一个项目团队共事，他们在5年之内没有达成项目日程中任何一个里程碑或其他任何要求。他们总是在反复制定优化的项目日程，却没有信心范围。最后，在资深管理层变动之后，整个团队被叫去参加高层管理会议，解释日程为什么会如此糟糕。
有一个经理说：“你们看，我想知道什么时候才能有所成果。咱们找个出发点吧。”此时，项目团队就知道他们必须要做出改变了。
我必须要承认，长久以来，我很难理解人们怎么会陷入到这种日程安排游戏中。不过，我确实见过善于口舌的管理层，他们或威逼，或利诱，或用权力来“说服”项目经理以及团队，让他们相信可以满足管理层对“幸福日期”的要求。这种所谓的“说服力”加上逃避困难话题的文化，足以让项目经理适宜进行“梦想时间”或“幸福日期”日程安排游戏，
“幸福日期”与“拒绝女王”有点儿联系，但是又不完全相同。有了“幸福日期”，组织中有些人（项目团队或项目经理）就可以让另外一些人（项目干系人）感到心安。从某种意义上来说，大家都不认为日程有讨论的必要。项目团队想抚慰项目干系人，项目干系人也愿意得到安抚。而在“拒绝女王”游戏中，项目干系人也希望得到安抚，可项目团队会坚持告诉他们现实。
要阻止这个游戏的发生，你必须与组织一起在项目层面上工作。对于项目，可以采取下列措施。
说明日程安排范围（见5.1.6节），特别是在没有使用迭代生命周期的情况下。使用迭代式生命周期，并说明将会通过信心范围实现哪些功能，参见5.1.5节。（“到下个月为止，我们可以完成这十个功能，也许还能再多完成三个。我们会在本月底之前告诉你。”）
使用敏捷生命周期和经过排序的待办事项列表，参见16.6.1节。
即便采取按阶段交付的生命周期，也要使用短小的时间盒，这有助于人们不断取得进展，而且要让大家了解这些进展。
不要仅仅以里程碑日期作为项目的衡量标准。要想了解项目的真实状况，如果只使用单一的衡量标准（如11.1节所述）无异于饮鸩止渴。可使用速度图表，让每个人都能了解进度。
不过，上述只是项目经理仅凭一己之力所能做到的。这个游戏揭示了组织的不一致性——大家只想彼此安慰，避免冲突。建设性的讨论（又名建设性的冲突）可以让组织更坚强。避免冲突和必要的讨论只会让组织变得更孱弱。
本文出自：blog.csdn.net/MagBryan/archive//01/04/3701274.aspx
篇6：我们不能说“不”――项目经理应该小心的游戏之十二
作为项目经理，管理层想让你再向当前版本中塞进来一个功能，他们在玩“我们必须拥有这个功能”的游戏。作为一个负责任的项目经理，你告诉了团队成员新的功能要求。你已经跟管理层说团队会评估请求，而且会告诉他们新的发布日期，或是加入新功能带来的成本。
可是当你开始跟团队成员讨论这个功能及其带来的影响时，大家都不愿意说“不”、“还不行”，或是“这样做会带来新的成本”。大家两眼一闭，就把新的工作接下来了，而不去讨论时间和资金上的成本，还有对当前工作的影响（见图6.12）。团队这么做，有时是处于内疚，有时是因为没有估计到额外的工作真正需要多少时间。
如果项目经理管理的团队不愿意说“不”，你就得帮他们学会表达不同意见。不过只对高层（或市场部，或是其他希望加入新功能的人）说“不”还不够。项目经理可以对任何事情表达不同意见。如果人们试图处理额外的工作，为了帮助他们管理这些额外的工作，可以考虑下列方式。
l 询问团队成员，看他们能否针对添加额外的功能制订了计划。可以使用黄色即时贴式日程安排和相对大小方式，看看能不能做得到。如果可以提供一个大家都满意的计划，项目经理就要尽量实现这个计划了。
l 项目团队成员有时会说：“我们会加入这个功能，并且加班完成，
”如果他们想加班，要建议他们用时间盒限制加班时间，并衡量加班的结果。项目经理可以说：“好吧，我们把工作按为时一周的迭代分开。可以加班一周，再看看我们的工作效率怎么样，疲劳程度又如何。过了第一周之后，我们再以正常的方式工作，再衡量下工作效率。然后我们可以对比下这两个工作效率，看看有没有引发诸如额外的变更或是缺陷的新问题。如果觉得加班没有效果，我们还可以按正常时间工作，到时候再看看是不是还能有其他方式做得更好。”
l 项目经理有时可以加入额外的人力来做更多工作。（不一定总好使。）如果组织中有人具备领域专业知识，而且可以融入到团队之中，团队也希望有这些人加入，项目经理就可以把这些人加入到团队中。不要加入对产品或团队不了解的人——想想布鲁克斯（Brooks）法则，参见7.5节。
图：我们不能说“不
如果上面这些方法都不起作用，项目经理就要帮助团队说“不”了。你可以用数据来抵消团队的内疚或是反驳完成公司要求的渴望。速度图表和迭代内容图表在这里特别有用。如果项目经理不能帮助团队学会说“不”，那大家就踏上死亡征途［You99］了。没有人希望这样。
请参见：www.stickyminds.com/s.asp?F=S11829_COL_2。
弗雷德里克.布鲁克斯（FrederickP.Brooks,Jr）在《人件》中提出一个重要的法则：向进度落后的项目中增加人手，只会使进度更加落后。——译者注。
本文来自：blog.csdn.net/MagBryan/archive/2009/04/28/4131742.aspx
篇7：令人恍惚的日程――项目经理应该小心的游戏之十六
下星期二，来自总部的大人物就要来视察了，或者你可能要在十个星期后做上市演示。不管怎么样，你要面对一个不可改变的日期、一系列充满野心或是不可能实现的功能集合，而且这些功能必须要在那个日期之前完成。无论是否已经测量过团队的开发速度，你知道团队是无法在截止日期来临之时完成所有的功能了。看起来团队面对着日程，都已经处于恍惚的状态了。有时，这就是团队对于“幸福日期”的回应。
图6.16 令人恍惚的日程
首先，要创建项目的仪表板（dashboard，见第11章），再测量进度，从测量开发速度开始。然后考虑采取如下行动。
如果还没有用迭代式开发，赶紧把剩下的项目分解成迭代吧，迭代时间越短越好。如果在不可改变的截止日期前有10个星期的时间，项目最少要分解成5个迭代，最好是10个。每周一个迭代，这可以帮你不断调整工作的优先级。迭代的目标是要完成某个功能或一组功能，这包括功能的开发、文档、测试，以及其他产品对于“完成”的要求。如果上市演示需要在线帮助，除非一个功能具备了在线帮助，否则它就不算完成。
在一个迭代中要集中精力，每日站立会议对此会有所帮助。项目团队的目标必须放在要完成的工作上。当完成足够多的细分任务之后，就可以得到一个完整的功能或是产品了。不要让团队中的人们受其他项目、未来工作或是技术债务（见附录B）的干扰，除非技术债务使得当前迭代的工作无法完成。
如果还没有准备好，就按功能逐个实现吧。这样可能会产生不完整的系统架构，不过不必担心，
如果一个功能需要架构提供某些方面的支持，团队会实现的。如果功能上不需要，那就没有人会用它。
通过使用“游击队式敏捷”（guerilla-agile） ，可以消除很多上述的日程安排游戏。如果能够以不超过四周的时间盒来组织项目，按功能逐个实现，随进度集成，并测量进展速度，项目经理就可以中止这些游戏。如果总是能以这样的方式管理，那就可以完全避免绝大多数的日程安排游戏。
Guerilla agile 是作者Johanna Rothman在Agile 大会上的演讲题目，指的是非正式的敏捷实施方式，演讲提纲下载地址：www.agile2007.org/downloads/handouts/Rothman_383.pdf。——译注
至此，《Manage It》第六章中的十六个日程游戏已经全部发布完成了，在本章结尾处，作者指出项目经理应该铭记在心的几个要点（这也是本书的一个特点，每章结束时，作者都会针对本章内容提出几个要点）：
日程安排游戏总是会发生的。项目经理的工作就是要识别它们，然后管理项目，让项目仍然可以取得成功。
绝大多数情况下，人们玩这些游戏都不是出于恶意。
即使没有恶意，日程安排游戏还是会拖项目后腿，使其停滞不前
本文来自：blog.csdn.net/MagBryan/archive//05/06/4154069.aspx
篇8：我们马上会变得更快――项目经理应该小心的游戏之十五
假定项目经理正在管理一个敏捷项目，或是按阶段交付的项目，或是其他生命周期类型的项目，总之这个项目可以用增量式的方式来构建系统，项目经理一直在测量团队的开发速度（或是实现的功能），可是进展速度没有达到预期效果。由于某些原因，团队成员对于如期交付很乐观（见图6.15）。
图6.15我们马上会变得更快
讲求实效的项目经理不愿意发出悲观论调或是冷嘲热讽，他希望让大家认识到现实，帮助团队成员看清真正的进度。说到底，也许他们还是可以赶上进度的。可以采取下面这些措施来管理信马由缰的乐观情绪。
与项目团队成员讨论进展速度，
收集数据：是什么样的所见所闻，让他们觉得接下来可以比之前工作效率更高？
测量估算质量因子（见11.2.4节）。有些因素会让人们觉得自己一直在按进度计划开发，甚至超越了进度计划。要特别注意这些因素。
测量团队所做的每一件事情。确定每个人都全力投入到项目中，而且都为了按规定日期交付而开发必要的任务。如果有人在为其他项目工作，或是开发某个后续版本需要的任务，要马上中止这种状况。
如果项目中涉及硬件组件，要测量其挣值（参见11.2.3节），看看它是否能按进度计划进行。如果做不到（现有挣值低于应有挣值），重新规划整个项目吧。
在测量开发速度时，在团队完成第三个迭代之前，对于项目出现的任何整体速度数值都不要感到惊讶。因为只有到那个时候，团队的速度才有可能稳定下来。
本文来自：blog.csdn.net/MagBryan/archive/2009/05/04/4148493.aspx
篇9：把灰扫到地毯下面――项目经理应该小心的游戏之四
几年前，我接到一个项目的求助电话，等我参与的时候，项目正处于发布周期的中期。我跟团队成员一起识别出他们可以交付什么、应该交付什么、还有哪些应该推迟。项目团队后来也按可交付物列表完成了交付。
发布之后，我建议团队召开回顾会议，看看有哪些工作是在下一次可以改进的。副总裁却认为没有人能从回顾中学到东西。
他忘了我为什么要来帮忙，光注意到了大家的成功。他说：“不过大家这次干得很不错。他们满足了我们对这个版本的所有要求。”
他的话把所有的问题一扫而光——特别是优先级的变更——灰都被扫到地毯下面了。团队里可没人觉得自己做得有多好。副总裁的话不再可靠了。项目团队成员感到疲惫不堪。这个版本一开始要求的有些功能不做也是可以的，如果项目团队一开始就能知道这一点，开发人员就可以集中开发最需要的功能了。
下面这些主意可以避免这个游戏。
把某个版本需要的功能先按优先级进行排序，再实现。（排序意味着1、2、3、4、5、6，诸如此类，
）参见8.3节。
逐个实现各功能。如果按照架构进行开发，就会形成很多部分完成的功能，没有哪个是完全开发完成的。而且架构会随着项目进展演化，很多管理层也认识不到这一点。参见9.3节。
制订发布条件，项目经理在项目开始时就可以讨论当前版本需要的东西。参见2.3节。
如果总是遇到“把灰扫到地毯下面”的问题，可以试试下面的方法。
使用产品待办事项列表，功能按业务价值进行排序。这样，你就总是在完成最有价值（也就是最重要）的工作。
使用有时间盒限制的迭代，并逐个实现各功能。项目经理和团队成员可以看到进展，并且总是最先提供最有价值的功能。
要想利用上述规避策略，就得在项目开始时与项目干系人对话，而且这些对话很难进行。不过其有益之处在于：如果没有交付任何东西，没人会假装项目是成功的。相反，团队可以把精力放在为了成功交付必须要做的事情上，而且只做这些。
本文出自：blog.csdn.net/MagBryan/archive//12/29/3639701.aspx
篇10：日程安排工具总是对的（梦幻时间日程）――项目经理应该小心的游戏之十
巴尼是一个项目经理，组织的高层只知道瀑布式生命周期，他们觉得迭代式的做法就是浪费时间。他们希望在项目的第一周就看到甘特图，这样项目经理就可以按照甘特图管理，一切都能按部就班进行。如此一来，无可避免的是：要是巴尼报告说项目没有按计划进行，有些高层就会这么说：“哎，按照日程安排，你的进度应该到这儿。没能按照计划进行，你是怎么回事啊？”
决策层对于项目的了解并不深入，他们不知道，人们在项目中是根据经验来思考和行动的。他们相信，关键路径会永远保持不变，任务安排顺序也一直大体相同。
发生如此状况，原因在于：一直以来，决策层看到的报表是由已经完成的工作、销售数字或其他数据构成的，这些数字反应的是在过去发生的事情。然而，项目日程是对于工作未来进展的猜测。该日程游戏也被叫做“梦幻时间日程”，可以参见图。
漂亮的甘特图会掩盖这样一个事实：日程安排只是猜测（见5.1.11节），
甘特图会让人们安心于日程安排，从而忽略对现实的检查。
如果项目经理面对这样的管理层，可以参考下面的建议。
制订波浪式的日程（见5.6节），你只需规划出前几周的详细工作，还有主要的里程碑。过了头几周，要是你还不能提供详细的日程，人们就会觉得你无法预测未来。可以再制订一个新的日程，其中带有已经完成的任务、下一个波浪的工作、每个月更新后的里程碑。这样就可以告诉别人做完了哪些工作，而且不必束缚于一个无法实现的庞大计划之中。
使用低技术含量的日程安排技术，比如黄色即时贴式日程安排（见4.3.1节）或是墙上的卡片。还可以邀请决策层复查项目日程。
提供带有信心水平的估算（见5.1.5节），而不是用甘特图。
使用有时间盒限制的迭代，而且每次只规划一个迭代能做的工作。测量团队的开发速度。过了三个迭代之后，项目经理也许可以知道足够多有关速度的数据，这就可以预测项目剩余的日程了。
人们之所以坚信日程安排工具的正确性，是因为它假定估计出来的日程可以很准确。而问题在于很少有日程是准确的。很多可以很精确，比如“我们会在周三下午3.32分发布产品”，但是却不准确。因为日程只是估算而已，让它看起来很漂亮，并不能改变这个现实，而且日程总是会有些误差。
发生这个游戏，日程安排工具并没有错，关键是使用工具的人对其过于相信。作为项目经理，你必须选定最有效的技巧安排日程，而且要跟别人说明这个日程安排。如果确实有作用的话，用日程安排工具也是可以的。但是不要只因为它能做出漂亮的图表，就对其坚信不疑。
本文来自：blog.csdn.net/MagBryan/archive/2009/03/20/4007395.aspx
