phphot

function StorePage(){d=document;t=d.selection?(d.selection.type!=None?d.selection.createRange().text:):(d.getSelection?d.getSelection():);void(keyit=window.open(http://www.365key.com/storei

非常非常多的知识工作者，特别是技术人员，都从未学习过如何估算。就算是尝试过估算的人，他们也过于乐观了，总是会过低估计一项任务需要的工作量。要么得不到任何对估算的反馈，所以他们不会知道自己的估算是不准确的；要么他们预测不到一个任务中会牵涉多少子任务，比如准备测试环境或是签入代码这样的任务。在任何情况下，当有团队成员以为自己完成了90%的任务，而实际上还有90%工作尚未完成的时候，“90%完成状态”就

在逐个报告进度的项目进度会议上最容易发生“日程小鸡（Schedule Chicken）”的情况。项目经理会问大家的进展情况如何。每个人都说自己在按日程安排进行。而实际情况却是，没有一个人做到。每个人都在等别人眨眼睛并承认自己没能跟上进度。而且除非已经太晚了，没有人会承认自己错过了项目进度安排。日程小鸡一个讲求实效的项目经理会有如下选择。避免逐个进行的进度报告会议（见10.1.2

下星期二，来自总部的大人物就要来视察了。或者你可能要在十个星期后做上市演示。不管怎么样，你要面对一个不可改变的日期、一系列充满野心或是不可能实现的功能集合，而且这些功能必须要在那个日期之前完成。无论是否已经测量过团队的开发速度，你知道团队是无法在截止日期来临之时完成所有的功能了。看起来团队面对着日程，都已经处于恍惚的状态了。有时，这就是团队对于“幸福日期”的回应。图6.16 令人恍惚的日程

作为项目经理，管理层想让你再向当前版本中塞进来一个功能。他们在玩“我们必须拥有这个功能”的游戏。作为一个负责任的项目经理，你告诉了团队成员新的功能要求。你已经跟管理层说团队会评估请求，而且会告诉他们新的发布日期，或是加入新功能带来的成本。可是当你开始跟团队成员讨论这个功能及其带来的影响时，大家都不愿意说“不”、“还不行”，或是“这样做会带来新的成本”。大家两眼一闭，就把新的工作接下来了，而不去

巴尼是一个项目经理，组织的高层只知道瀑布式生命周期。他们觉得迭代式的做法就是浪费时间。他们希望在项目的第一周就看到甘特图，这样项目经理就可以按照甘特图管理，一切都能按部就班进行。如此一来，无可避免的是：要是巴尼报告说项目没有按计划进行，有些高层就会这么说：“哎，按照日程安排，你的进度应该到这儿。没能按照计划进行，你是怎么回事啊？”决策层对于项目的了解并不深入，他们不知道，人们在项目中是

老板给项目经理曼尼打电话说道：“曼尼，我们得聊聊你的项目了。”曼尼答道：“当然，有什么问题？”“嗯，如果这次不加入这个功能，我们就完蛋了。大客户们不会买这个版本的。”曼尼叹了口气，说道：“我跟大家说一下吧，回头告诉你结果。”曼尼转头跟项目团队解释了这个情况，大家同意在当前版本中加入这个额外的新功能。不过大家已经对按日程及时交付不抱希望了，顺便说一句，项目日程从来都没有改过。在这个例子中，每

几年前，一个资深经理打电话给我，说道：“我们有个项目出问题了。在启动的时候，我们充满了希望，但是现在看来已经不可能了。”我问了几个问题，发现他们之前从来没有做过类似的项目。相对以前，这个项目的规模更大，使用新的开发语言，基于新的平台，而且日程安排更短。整个公司的未来都押在这个项目的成功上，问题是它比以前做过的项目都要复杂，而且要求也更高。他们唯一的策略就是“希望”。他们没有安排任何关于

译自《Manage It！》第六章~~~~我~是~漂~亮~的~分~界~线~~~~~~~~~我~是~漂~亮~的~分~界~线~~~~~~~~~我~是~漂~亮~的~分~界~线~~~~~  克里夫与团队一起，用一周时间制订出了项目日程。他们完成了"哈德逊湾式启动"，并且确定已经识别出了主要的技术风险。他将风险和日程安排告诉了他的上司诺姆。"你就不能再早点完成项目了么？"诺姆的一句话将克里夫

有一个副总声称自己有“多动症”（Attention DeficitDisorder）。他不会要求不同的日期，实际上，他在不停改变项目的目标。一开始，目标是一个特定的功能集合。而从开发速度图表中可以看到，团队无法按时交付。这位副总就改变了目标，要提升某些功能的性能。但是性能提升在技术实现上很有难度。几周之后，他又决定把重点放在提高可靠性上了。让我觉得有意思的是：他在做项目经理时没有这个问

我们都知道，日程安排只是估计而已，不过是大概猜测罢了。项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测。日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺。 如果面对上述困境，可以问问如下两个问题：你是否关心团队交付的东西？ 你是否关心产品的质量如何？   要想让有关项目日程的谈话富有成效，就得讨论项目后面的驱动因

我曾遇到这样一个经理，他的原话如下：“我希望你能在项目A上花50%的时间，在项目B上花30%的时间，在项目C上花20%的时间。在空闲的时候，你能看看给老大的报告么？”我答道：“什么空闲时间？”“分散注意力”就是与多项目、多任务相关的游戏。如果管理层无法把精力投入到一个项目或是工程的策略之中，就会引发此游戏。他们不会对每个项目说“是”或“否”，也不会问“什么时候？”，而是对所有的项目点头称是。

一天，一封来自公司大人物的紧急邮件把你招呼到公司。邮件里说：“别弄那个项目了，赶紧开始做这个吧！”可以确定，如果此事发生一次，它就还将多次重演。项目经理和团队都会周旋于几个项目之中，或是在两个项目之间不停切换。不管是哪种状况，项目经理都陷入多项目、多任务切换的泥潭，而且整个团队亦是如此。项目经理知道自己无法取得任何成果，所有项目的紧急程度却在不断攀升、攀升、攀升……当管理层害怕

我遇到有些组织，他们有个不成文的规定：绝不讨论项目日程。这种情况我见得太多了。管理层想要一个日期，项目团队就会说：“当然，没问题，就圣诞节吧！”但他们不会明说是哪个圣诞节。最后，当某个圣诞节到来之时，已经过了不少日子了，人们开始讨论日程安排。而这时项目已经错过不少里程碑的交付日期，甚至有可能几个早先期望的项目结束日期都已经过去了。我曾跟这样一个项目团队共事，他们在5年之内没有达成项目日

  几年前，我接到一个项目的求助电话。等我参与的时候，项目正处于发布周期的中期。我跟团队成员一起识别出他们可以交付什么、应该交付什么、还有哪些应该推迟。项目团队后来也按可交付物列表完成了交付。发布之后，我建议团队召开回顾会议，看看有哪些工作是在下一次可以改进的。副总裁却认为没有人能从回顾中学到东西。他忘了我为什么要来帮忙，光注意到了大家的成功。他说：“不过大家这次干得很不错。他

假定项目经理正在管理一个敏捷项目，或是按阶段交付的项目，或是其他生命周期类型的项目，总之这个项目可以用增量式的方式来构建系统。项目经理一直在测量团队的开发速度（或是实现的功能），可是进展速度没有达到预期效果。由于某些原因，团队成员对于如期交付很乐观（见图6.15）。图6.15 我们马上会变得更快讲求实效的项目经理不愿意发出悲观论调或是冷嘲热讽，他希望让大家认识到现实，帮助团队成员看清真