栖息谷-管理人的网上家园

标题: 《最后期限》读书笔记 [打印本页]

作者: 人月神话    时间: 2006-5-4 22:56
标题: 《最后期限》读书笔记


第四章 优质管理的四大要素
 
    1.选择正确的人 (人力资源管理)
    2.为他们分配正确的工作 (计划,WBS,估算,时间管理)
    3.保持他们的积极性 (人力资源管理和沟通管理)
    4.帮助团队凝聚起来并保持团队的凝聚力 (人力资源管理和沟通管理)
 
    软件开发项目以人为本,人是软件项目管理第一要素。如何选择到合适的开发成员,激发他们和整个团队的热情是项目成功的重要保障。项目不是需要全牛的人,是需要胜任的成员,能够人尽其用的成员,成员的积极主动心态,热情,责任感和团队归属感更为重要。
    第二点强调项目中尽量每个人都能够发挥自己的专长,让正确的人的做正确的事情需要考虑个人特点,资源分配约束,项目沟通等多方面的努力。
 
第五章 负面效应
 
    1.威胁和高负荷工作不是提高业绩的方法
    2.如果一开始分配的时间就不够,不管威胁有多么吓人,任务也无法完成。
    3.更糟糕的是你要兑现你的威胁而影响团队
 
    一开始要做好估算和计划的安排并考虑留适当的余量。项目应该保持一定的紧迫感和压力。但持续的紧张和压力会给项目带来噩运。
    项目管理中应该强调执行力,项目中的奖惩应该分明,但不是通过威胁手段。
 
第八章 风险管理
    
    1.管理项目的过程就是控制风险的过程。
    2.你如果没有识别出风险的根源,那你也无法给出具体有针对性的应对措施。
    3.评估每个风险发生的概率,严重性和可能的开销。
    4.为每个项目维护一个风险跟踪和统计表。
    5.你不是不想控制风险,而是你无法通过早期的征兆去识别出风险。
 
第九章 马可夫准将
 
    1.找一个已经成型的团队而不是自己去凝聚一个团队。(要形成一个有很强战斗力的团队绝非一朝一夕的事情)
    2.控制住失败往往比优化成功更重要 (风险管理,问题处理机制,沟通和协调)
    3.项目一开始浪费一天和项目结束浪费一天对项目伤害是相同的。(危机意识)

第十章 开发过程建模
 
    1.对你完成工作过程的直觉进行建模
    2.在与同事的交流中使用这些模型
    3.用模型来模拟项目的运行结果
    4.根据项目的实际结果来调整模型
 
    资源和进度不能完全互换,人月神话一书有明确的描述。20人一年的项目进度压缩到半年时候究竟要增加多少人员,或者说增加再多的人员都无法压缩到1年,往往我们更多的是主观上的推测和判断,而没有通过适当的模型去模拟和验证我们的想法。如果我们无法给出明确的分析证据,很难去说服我们的用户和领导,去争取相应的时间和资源。在这种增加资源压缩工期的软件项目中我们需要重点考虑的问题有:
 
    A.人员增加后沟通成本的增加,5个人沟通路径是10,10个人沟通路径是45,而20个人的沟通路径是190.这显然已经不是线性关系。
    B.项目生命周期模型的选择和关键路径:前期需求没有搞清楚之前投入再多的人力资源都没有意义。如果需要就要做3个月,那半年完成项目基本就属于不可能的任务了。
    C.由于存在B因素项目各阶段不可避免存在闲置人力资源,很难充分利用。
 
第十二章 项目度量
 
    1.项目运行过程中要注意度量数据的收集
    2.项目结束的时候要进行复盘,要对收集的数据进行分析&整理,形成项目历史经验数据库。
    3.要形成项目自己的度量方程式,并根据各版本的输出历史数据对公式进行验证&调整。最终为下个项目或版本提供参考。
    4.要剔除项目中的异常数据,保证收集的度量数据的准确性。
 
第十五章 压力效果
 
    1.压力之下的人无法跟快速的思考问题
    2.增加加班时间只会降低生产力
    3.短期的压力乃至于加班是有用的策略,因为这能够使员工集中精力并感觉到工作的重要性。但是长期的压力肯定是错误的。
    4.使用压力&加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。
 
第十九章 人员安排
 
    1.早期的人员超编会使项目过早进入设计阶段
    2.设计完成之前进入开发会使人&人之间,工作组之间接口复杂化。
    3.项目理想情况使早期由核心小团队进行需求&设计,后期投入大量人手
   
    我们考虑下一个规模在60-100个用例的项目,实际的工作量在150人周。项目在一开始就投入到15个人花10周时间完成。而往往更合理的方法是前6周只保留2个需求人员和4个设计人员进行工作。在6周以后投入16个编码人员进行编码,2个需求人员退出。这样的工作量为116人周。这样的效果是肯定比第一种资源分配好的。

 


作者: cycy    时间: 2006-5-25 09:58

顶,我也做了一些摘录,并发给了好朋友.

我觉得这本书中对我们最重要的就是这些总结了.


作者: 南华仙童    时间: 2007-4-21 00:59
想必楼主的课一定讲得不错,有机会能听听则更好,条理清楚,又具备实用性。
作者: swordliang    时间: 2007-9-25 11:02

[推荐]《最后期限》完整版(23章)-中国第一本项目管理通俗读物

图片点击可在新窗口打开查看点击免费下载该资料

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

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

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

第1章 新的机会
第2章 对抗卡布福斯
第3章 “硅谷”
第4章 CD-ROM工厂
第5章 元首
第6章 世界上最伟大的项目经理
第7章 雇人
第8章 大名鼎鼎的尼佐利博士
第9章 马可夫准将
第10章 阿布杜尔.贾米德
第11章 可恶的贝洛克部长
第12章 数字人
第13章 QUICKERSTILL,再快一些
第14章 摩罗维亚的第一个程序员
第15章 快点思考!
第16章 筹备夏季运动会
第17章 解决冲突的专家
第18章 麦斯特罗.迪耶尼亚尔
第19章 部分和整体
第20章 在典礼上
第21章 决战开始
第22章 年度最热的首募日
第23章 经过里加回家
[此贴子已经被作者于2007-9-25 11:04:45编辑过]

作者: swordliang    时间: 2007-9-25 11:26

"这本关于管理的书读起来明白有趣。《最后期限》是一个创新性与趣味性并重的故事,每章结尾都有基于团队的项目管理方面的原则。"
                               --John Aculley

"……这是一部技术力作。它涵盖了大量主题,从项目评估到度量标准,从相冲突的决定到处理含糊不清的说明每章结尾的要点已经足以让您这本书成为超值之选了……《最后期限》像Dilbert的漫画书一样有趣,却没有那么讽刺。更重要的是,书中包括一些深刻的智慧,以及一些帮助您实现最后期限的实用积极的建议。我强烈推荐这本书。"
                               --Ed Yourdon

内容与特色:

  汤普金斯先生是一位经验丰富的项目经理,却也难免被炒鱿鱼的命运。这时有人出双倍的价钱将他""到一个海上的小国管理六个软件项目,资金、人员、设备等所有外部条件都万事俱备,可以放手去做,还可以将自己的奇思妙想付诸实践。本以为因祸得福,却逐渐发现事情并没有那么简单,最后期限似乎变得不可能,但他已骑虎难下……
  书中用一个虚构的故事阐述了真实世界中关于项目管理的一些原则,虽然它并不能解决任何软件问题,但它绝对会让你对项目管理的重要原则终生难忘。它将看似高深莫测的项目管理理论以浅显易懂的方式展现出来,改变了项目管理书籍一贯枯燥乏味的形象,让你在轻松阅读小说的同时受益非浅。书中每章都以汤普金斯先生的日记结尾,是他逐渐收集的经验,有了这些,你也可以成为一个优秀的项目b经理。

本书前言
  在二十世纪三十年代,科罗拉多大学的物理学家乔治.伽莫夫开始撰写一系列关于"汤普金斯先生"--一位中年银行职员--的小故事。故事中讲述的汤普金斯先生对现代科学很感兴趣。他总是去听当地一位大学物理教授在晚上的演讲,然后在中途他必定会睡着。当他醒来的时候,他会发现自己身在另一个宇宙之中,在那里某个物理常量发生了明显的变化。
  比如说,在这个系列中的一个故事里面,汤普金斯先生醒来所在的宇宙中,光速只有每小时15英里。这意味着他可以骑在自行车上观察到相对论的效果:当他加速时,城市的街区在他前进的方向上变短了,而且邮局的时钟也变慢了。在另一个故事里,汤普金斯先生旅行到了一个普朗克常量为1.0的世界,在那里他可以在一张台球桌上看到量子力学所起的作用:台球拒绝直线穿过球桌,而是随机地出现在各个离散的位置上。
  第一次读到伽莫夫的故事时,我还是一个少年。就象汤普金斯先生一样,我对现代科学非常感兴趣。当时我已经看过很多关于相对论和量子力学的资料,但是,直到我看了《汤普金斯先生在奇境》之后,我才真正对这些理论有了自己的理解。
  我一直都推崇伽莫夫独创性的教育方法。这让我决定用相似的方法来阐述一些关于项目管理的原则。我需要做的就是描绘这样一个故事:一个经验丰富的项目经理被送到一?quot;奇境",那里项目管理的规则发生了有趣的变化。这就是《最后期限》最初的灵感来源--我应该感谢伽莫夫,因为我借用了他的灵感。这个故事介绍了一个名叫汤普金斯的经理和他在摩罗维亚共和国的软件项目中得到的不寻常的经验。
    

译者前言
  "早该出这么一本书了!"如果您对项目管理感兴趣或者经常阅读那些枯燥乏味的理论书籍,您一定会这样说,起码我是这样想的。而且我认为它来得太迟了--项目管理学习者长期处于一个尴尬处境:在高深的科学和渴求知识的人们之间缺少一本科普读物。
  你手上的这本《最后期限》就是一部有趣的科普作品,它用一个完全虚构的故事讲述项目管理的若干原理。虽然故事有轻微的夸张,甚至不乏荒谬之处,然而却不时让你觉得似曾相识,好象就是昨天发生在你身边的故事,字里行间闪烁着智慧的光芒。读过之后你将知道哪些东西更重要、应该去学习哪些东西、应该将哪些东西抛在脑后--这正是一本科普读物的作用,不是吗?
  什么人有资格写科普作品?只有真正的大师、真正对一门科学了如指掌的人才能用浅显的语言来介绍深奥的理论。本书的作者汤姆·迪马可是软件科学界的一代宗师。他是"结构化程序设计"概念最早的提出者之一,而且直到现在,他仍然在关注软件开发技术的新发展。由他来写这本科普小说,自然是众望所归。此外,他优美的文笔和渊博的学识也使本书更加精彩。
  值得一提的是,迪马可先生为人极其谦和,做事极其认真。从接到本书的翻译工作开始,我就与迪马可先生取得了联系。在此后将近一年的时间里,对于我的问题,无论是关于本书的内容还是其他的技术问题,他都会耐心解答。而且,他还一直关注本书的翻译和出版进程。正是在迪马可先生的督促和帮助之下,我才能顺利地完成本书的翻译工作。在此,谨向迪马可先生遥表谢意。
  由于UMLChina站长潘加宇的信任,我才能有机会翻译这本书;在我最困难的时候,是潘加宇给我鼓励和支持。另外,本书的责任编辑熊妍妍一直鞭策我,并指出我翻译中的诸多不当之处,她是本书质量的保证。在此,向他们两人致以诚挚的感谢。
  我更要感谢本书的合译者,我亲爱的女友马姗姗。她深厚的文学底蕴弥补了我在文字上的苍白,使得这个译本不至流于枯燥生硬。如果本书的内容有可取之处,那是因为迪马可先生;如果本书的语言有可读之处,那就是因为马姗姗。如果没有她,我的翻译工作注定将半途而废。
  最后,我应该对读者说什么呢?……请享受这个有趣的故事吧。
  译者
   
熊节(透明) UMLChina翻译组
  200210
  于北京

[此贴子已经被作者于2007-9-25 11:29:11编辑过]





欢迎光临 栖息谷-管理人的网上家园 (http://bbs.21manager.com.cn/) Powered by Discuz! X3.2