最后期限

出版社:清华大学出版社
出版日期:2002-12-1
ISBN:9787302060864
作者:汤姆・迪马可
页数:314页

作者简介

汤普金斯先生是一位经验丰富的项目经理,却也不幸遭遇了被“炒鱿鱼”的命运。这时,有人出数倍的薪俸将他“请”到一个海上的小国同时管理六个软件项目。资金、人员、设备等所有外部条件都万事俱备,汤普金斯先生可以放手去做,并将自己的奇思妙想付诸实践。本以为会因祸得福,汤普金斯先生却逐渐发现事情并没有那么简单,项目根本无法在最后期限内完成,但他已经骑虎难下……

书籍目录

第一章 新的机会
第二章 对抗卡布福斯
第三章 “硅谷”
第四章 CD-ROM工厂
第五章 元首
第六章 世界上最伟大的项目经理
第七章 雇人
第八章 大名鼎鼎的尼佐利博士
第九章 马可夫准将
第十章 阿布杜尔・贾米德
第十一章 可恶的贝洛克部长
第十二章 数字人
第十三章 QUICKERSTILL,再快一些
第十四章 摩罗维亚的第一个程序员
第十五章 快点思考!
……

内容概要

  汤姆·迪马可是世界著名期刊《Cutter IT》杂志的编委,著名计算机系统思想库Atlantic Systems Guild的负责人之一,他在1986年荣获Warnier计算领域终身贡献奖,他也是经典巨著《人件》的作者。

媒体关注与评论

  本书用一个虚构的故事阐述了真实世界中关于项目管理的一般问题,以鲜活的文字和曲折的情节项目管理书籍枯燥乏味的一贯形象,让你享受阅读快乐的同时受益匪浅,对项目管理的重要原则终生难忘。书中很多章节都以汤普金斯先生的日记作为结尾,其中记录了日常收集的经验,掌握了这些经验,你一定也可以成为一名优秀的项目经理。

图书封面


 最后期限下载 精选章节试读 更多精彩书评



发布书评

 
 


精彩书评 (总计21条)

  •     本文为转载,原文出处http://book.douban.com/subject/discussion/1032073/优质管理的四大要素:选择正确的人、为他们分配正确的工作、保持他们的积极性、帮助团队凝聚起来并保持团队的凝聚力。一、安全和变化   01除非感到安全,否则人们就不能去迎接变化。   02在所有成功的工程中(以及在绝大多数其他有价值的工作中),变化都是基本的要素之一。   03安全感的缺乏会让人们反对变化。   04逃避风险是致命的,因为这会让你也得不到与风险同在的利益。   05人们可能会因为来自客观世界的直接恐吓而觉得没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉得没有安全感。  二、负面效应   06威胁不是提高业绩最好的方法。   07如果分配的时间一开始就不够,不管威胁有多么吓人,工作也无法按时完成。   08更糟糕的是,如果目标没有实现,你就必须兑现你的威胁。  三、管理者必需的身体部位   09管理涉及到心、肠胃、灵魂和鼻子。   10因此……用心来领导,相信你的肠胃(相信你的预感),构筑团队的灵魂,训练一个能嗅出谎言的鼻子。  四、用指挥战争来作为管理的一个比喻   11在战役开始的时候,管理者真正的工作已经完成了。  五、面试和招聘   12招聘涉及到所有与管理相关的身体部位:心、灵魂、鼻子和肠胃(但是主要是肠胃)。   13不要试图单独去招聘——两副肠胃远比一副肠胃的两倍要好。   14对于新的雇员,让他们承担与以前曾经成功过的同样难度的项目,把有挑战性的目标推迟到下一次。   15征求提示:你最希望雇的那个人可能还知道其他很好的人选。   16多听,少说。   17如果先把材料整理好,那么所有的事情会进行得更好。  六、生产力的提高   18没有“短期生产力提高”这样的东西。   19生产力的提高是来自长期投资的。   20任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。  七、风险控制   21通过控制风险来管理项目。   22为每个项目创建并维护风险统计表。   23跟踪根源性的风险,而不只是最后那讨厌的结果。   24评估每种风险具体化的概率和可能造成的开销。   25对于每种风险,预测标志其具体化的早期征兆。   26任命一个风险控制官,这个人不应该维护组织内部“我能行”的态度。   27建立简单的(可能是匿名的)通道,让坏消息能传递到高层。  八、防止失败   28壮士断腕。   29控制失败比优化成功更能提高你的全面成绩。   30要有闯劲,尽早取消失败的工作。   31除非必要,否则就不要自己去凝聚一个团队:出去找一个已经成型的团队来用。   32保持好的团队在一起(只要他们自己愿意),以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。   33把凝聚在一起的团队——准备充分、并且也愿意接受新的工作——作为项目的收获之一。   34项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。   35有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间。  九、开发过程的建模和模拟   36将你关于完成工作过程的知觉建模。   37在同事的交流中使用这些模型,以便交流、提炼关于项目运转的思维。   38用模型来模拟项目的结果。   39根据实际的结果来调整模型。  十、“病态的政治”   40每一天,你都必须准备拿自己的工作去打赌……   41……但是这也不能保证“病态的政治”不会影响你。   42“病态的政治”可能在任何地方出现,哪怕是在最健康的组织里面。   43“病态的政治”的特征:对个人权势的渴望超过了组织本身的目标。   44即使这种不合理的目标与组织的目标背道而驰,它也可能出现。   45“病态的政治”最恶劣的副作用:它使精简项目变得危险。  十一:度量   46度量每个产品的规模。   47不要执着于单位——在等待客观度量的时候,先用你自己的主观单位。   48从所有能得到的原始数据(可计算的软件特性)自己构造度量单位。   49从已完成的项目中收集原始数据,以推导出生产力趋向。   50不断完善你的度量方程式,直到它的计算结果与原始数据库中的项目工作量有最好的对应关系。   51借助数据库画一条趋势线,把预期工作量作为人造度量单位值的函数显示出来。   52现在,针对每个要评估的项目,计算出人造度量单位值,并根据这个值在趋势线上找到预期工作量值。   53用生产力趋势周围的干扰水平作为映射的公差指示。  十二、过程和过程改进   54好的过程和持续的过程改进是绝好的目标。   55它们也是非常自然的目标:优秀的技术工作者一定会关注它们,不管你是否告诉他们。   56正式的过程改进程序需要花钱、花时间;特定的过程改进工作还会延缓项目进度。尽管最终会体现出生产力上的收获,它们也不可能抵消花在过程改进上的时间。   57但是,项目有希望从单个的、正确选择的方法改进中得到足够的收益,并赢回为这个改变付出的时间和金钱。   58在项目进行的过程中,不要希望在超过一个方法的范围内实施改进。多种技术的改进程序(比如说提高整整一个CMM等级)很可能让项目比不实施这些程序完成得更晚。   59标准过程的危险就在于人们可能失去重要的走捷径的机会。   60特别是对于人员超编的项目,标准过程看上去会很严肃,因为它们制造出了足够的工作(有用的和无用的),让所有人都忙碌不停。  十三、改变完成工作的方式   61如果不大幅度减少调试的时间,就没办法让项目大幅度提前完成。   62高速完成的项目用在调试上的时间也成比例地少得多。   63高速完成的项目用在设计上的时间也成比例的多得多。   64如果你不关心别人,不照顾别人,就别想让他们为你做一些不同寻常的事情。如果要让他们改变,就必须去了解(并赞赏)他们的过去。  十四、压力的效果   65压力之下的人无法更快地思考。   66增加加班时间只会降低生产力。   67短期的压力乃至于加班可能是有用的策略,因为它们能使员工集中精力,并且让他们感到工作的重要性。但是长期压力肯定是错误的。   68经理之所以会施加那么多的压力,也许是因为他们不知道该做什么,或者因为其他办法的困难而感到气馁。   69最坏的猜测:使用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。  十五、愤怒的经理   70管理中的愤怒和羞辱是会传染的。如果高级管理者喜欢骂人,低级管理者也会有样学样(就像经常被骂的小孩很容易变成爱骂人的父母)。   71管理中的辱骂经常被认为是一种刺激,可以让员工提高效率。在“胡萝卜加大棒”的管理策略中,辱骂是最常见的“大棒”。但是,哪有人被辱骂之后还能做得更好的?   72如果经理使用辱骂的方法来刺激员工,这就表现出经理的无能,而不是员工的无能。  十六、含糊的规格文档   73规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。   74如果一份规格文档不包含完整的输入输出列表,那么它就是毫无希望的;它根本就还没开始说明任何东西。   75没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己,而不是责备文档。  十七、冲突   76只要在开发过程中有多个参与者,就一定会有冲突存在。   77创建、安装系统的业务中特别容易出现冲突。   78绝大多数系统开发团体都缺乏解决冲突的能力。   79冲突应当引起重视。冲突并不是缺乏职业道德的行为。   80应当提前声明:所有人的“赢”都是受重视的。确保每个级别的人都能赢。   81谈判困难;调节容易。   82如果两个人的利益是完全或者部分相斥的,预先做好安排,准备好请双方通过调解来解决冲突。   83记住:我们都站在同一边;跟我们对立的,是我们要解决的问题。  十八、催化剂的角色   84有这样一种催化剂式的人格。这样的人会帮助团队成型并凝聚,保持团队的健康和生产力,从而对项目作出贡献。就算“催化剂”别的什么事情都不干(其实,通常他们还会干很多别的事),这种催化剂的角色也是重要而有价值的。   85调解是“催化剂”的一项特殊工作。调解是可以学的,而且只需要很小的投资就能学会。   86调解应该从一个小小的仪式开始。“我能帮你们调解一下吗?”在解决冲突的时候,这是必要的第一个步骤。  十九、人类的错误   87将你置于死地的,不是你不知道的东西……而正是你“知道”绝不会置你于死地的东西。  二十、人员安排   88在早期,人员超编会迫使项目跨过关键的设计阶段(这是为了让所有的人都有事可做)。   89如果在设计完成之前,工作先被分给了许多人,那么人与人之间、工作组之间的接口就会很复杂。   90这会使团队内部耦合度提高,会议时间、重复劳动和无数工作都会增加。   91理想的人员安排是这样:在项目的大部分时间里由小型核心团队来做设计工作,在开发的最后阶段(时间安排的最后1/6)加入大量的人手。   92可怕的猜想:时间安排紧迫的项目,与时间安排比较合理的项目比起来,完成的时间反而会更长。  二十一、项目社会学   93让不必与会的人可以放心离开,从而保持会议的精简。有一份公开的议程,并严格执行,这是最简单的办法。   94项目需要仪式。   95用小小的仪式来使人们注意项目的目标和理想状态:小规模会议、零缺陷工作等等。   96采取行动,防止人们随便发怒。   97记住:愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样做的。   98意见:如果所有人都懂得“愤怒=恐惧”这个道理,就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧,他也就不会再生气了。(这不能解决这些生气的人的问题,但是肯定可以让其他人好受一些。)  二十二、“病态的政治”(旧话重提)   99别想根治一个病态的人。   100不要浪费时间,也不要因为尝试治疗上司的病态而使自己受到威胁。   101有时候,你惟一的选择就是等待,等问题自己解决,或者等一个让你继续前进的机会。   102奇迹是有可能发生的(但是千万别去指望它)。  二十三、精兵简政   103精兵简政是失败公司使用的办法,它让员工负担失败的责任。   104公司的目标应该正好相反:兴旺而人性化。   105当你听到“精兵简政”这个词的时候,请记住它的选弦外之音:失败和恐吓。  二十四、基本常识   106项目既需要目标,也需要计划。   107而且这两者应该不同。原文出处:
  •     这本书的主旨是不错,值5星。但要小心这本书也是小说,只是强调了人的作用,不能简单照搬到实际工作中。
  •     屌丝程序员打怪升级的经典意淫小说尤其是结尾部分。。。“说你答应,韦伯斯特,请答应吧。我会非常高兴的。”他停了一会儿,盯着她说:“请等一分钟。”这一次,如果得不到他想要的。他绝不再让步。他换上最严厉的表情:“告诉我。莱克莎,你给自己选择的角色是什么?”第一次,她显得不自信了。她咬着嘴唇:“我……”“告诉我。菜克莎。”她低头看着地板。“我还没想过。”她轻声说道。“好吧,那就让我来告诉你。我给你准备了一个角色,你必须接受——否则我转身就走。”她还是不看他:“你给我什么角色,韦伯斯特?”他让自己平静一下,然后说道:“元首助理和夫人。”“噢,韦伯斯特,我还以为你永远不会问呢。”“嗯?”“我同意,我愿意,我接受。”“好。”他四下看看,“那么,我们现在该去哪儿?”“王室套间。”她说逋,朝着一扇华美的门点头示意,“就在那边。”他把她抱起来,朝他们的新生活走去。

精彩短评 (总计50条)

  •     通俗易懂的软件工程小说
  •     这本书其实不错的,读起来颇有收获。
  •     一本用叙事方式讲述软件工程项目管理中的一些理论,并加事例来说明。不错的一本书。
  •     虽然狗血的结尾暴露了作者的屌丝心理,但是瑕不掩瑜,是非常值得一读的项目管理类的书籍,并且,强烈建议要碰到困难后再来读,当作放松。一定会有所收获。
  •     读本书的最大收获。 优质管理的四个要素: 1、选择正确的人 2、为他们分配正确的工作 3、保持他们的积极性 4、帮助团队凝聚起来并保持团队的凝聚力
  •     在EPFL最有收获的课就是Software Engineering
  •     小说形式,浅显易懂,但是国内实施起来的确太难,没有环境
  •     20130105,评分4/5,阅读时间:75分钟,关键词:项目管理。通过完整的虚构故事,告知项目最重要的4个要素:找对人,分配正确的任务,激励,团队建设。每一章,故事主角通过日记形式,记录项目学习心得,这些心得必须是自己经历过项目管理后才能更深有体会。
  •     隔行,所以还没有入门的感觉,需要换个时间再来读一读。
  •     通过故事的方式讲解软件工程,比较容易读
  •     项目管理的书,软件开发管理,看的象童话。
  •     对软件开发的复杂性有些忽视了。
  •     一次理想化的管理,但其中的收获值得每个人学习一二。
  •     看完
  •     软件工程的启蒙书之一。
  •     当时颠覆性软件工程观点,随着时间变迁,不再正确
  •     这本书不仅仅是一个讲项目管理和团队管理的书,更像是一本小说,还是爱情小说,故事的结局是王子与公主打败了“项目失败大魔王”,一起过上了幸福的生活。
  •     一本讲项目管理的书,对我帮助不大。
  •     只觉得一般吧。。。
  •     doesn't deserve serious reading hehe
  •     2小时30分钟。快速地进行了一次项目管理的旅行,我从这本书里获得了超出我期望的东西。管理中最困难的问题,是人的问题。让正确的人去做正确的事情,这正是优秀的管理者和平庸的管理者之间的区别。
  •     将软件项目管理的方方面面的经验,借助一个故事来娓娓道来
  •     一本项目管理方面的小说,这本书还是上家单位的领导推荐的,虽然过了这么久还是把它读完了,讲到了项目管理中很多细节,如人力资源分配、上层领导的阻力等等
  •     翻译过来后读着不顺畅。
  •     童话般的科普。功不可没
  •     最讨厌的外文书的感觉,可读性太差,坚持到60%放弃了
  •     项目管理的好书,值得反复看
  •     科幻小说
  •     : F224.5-49/3371
  •     我不知道我为啥会读这个
  •     里面的很多想法很赞同,不过把管理写成故事还写成这种故事的书还蛮特别的。
  •     原谅我对项目真的一无所知
  •     很愉悦的阅读体验
  •     人员超编,让多余的人做并无实际意义的mission,保持活力。
  •     有价值的意淫小说
  •     会心一笑,感触良深
  •     小说
  •     好故事
  •     包工头一样的人只能管理码农,管理不了真正有才华的程序员;而且你改变不了变态上司,有时候能做的只有等待或者离开,这个书里面金句挺多
  •     读过,不知道是不是翻译的问题,读起来不顺畅。
  •     最近思考敏捷,所以在读以前的存货。如果你想知道以前我们都是怎么糟糕的开发软件的,读这本书吧。
  •     不喜欢这样的文风,以小说的方式大量的笔墨写了少量的内容。
  •     大名鼎鼎的小说形式的管理读物。然而并不感到有趣。
  •     项目管理的旅程故事。
  •     通过生动有趣的故事来讲述项目管理,强烈推荐
  •     项目管理,人的管理。1-选择正确的人,2-为他们分配正确的工作,3-保持他们的积极性,4-帮助团队凝聚起来并保持他们的凝聚力。
  •     软件界的理想国
  •     豆瓣上评价挺高的,但我觉得过高了。略读了每章总结,发现对提高项目管理水平帮助不是很大……
  •     有趣
  •     项目管理类小说 读的是笔记
 

农业基础科学,时尚,美术/书法,绘画,软件工程/开发项目管理,研究生/本专科,爱情/情感,动漫学堂PDF下载,。 PDF下载网 

PDF下载网 @ 2024