读《最后期限》体会

来源:互联网 发布:div边框颜色js 编辑:程序博客网 时间:2024/04/29 02:25

读《最后期限》体会

        这是一本非常有趣且引人深思的科普作品,该书体裁借鉴在二十世纪三十年代,科罗拉多大学的物理学家乔治.伽莫夫撰写的关于"汤普金斯先生"--一位中年银行职员--的系列小故事,我非常幸运的曾经阅读过该书并被里面有趣的物理故事所吸引,因此当看到同样风格的《最后期限》时,该书便深深吸引了我。作者Tom Demarco所推崇的伽莫夫独创性的教育方法也非常有借鉴意义。

        本书的核心就是主人公汤普金森在自己日记中的总结,记录如下,对此针对该日记写下自己的一些体会。


1、优质管理的四大要素

选择正确的人

为他们分配正确的工作

保持他们的积极性

帮助团队凝聚起来并保持团队的凝聚力

(其它一切都只是“文案”)

体会:

2、安全和变化

除非感到安全,否则人们就不能去迎接变化

在所有成功的工程中(以及在绝大多数其它有价值的工作中),变化都是基本的要素之一。

安全感的缺乏会让人们反对变化。

逃避风险是致命的,因为这会让你也得不到与风险同在的利益。

人们可能会因为来自客观世界的直接恐吓而觉的没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉的没有安全感。

体会:

3、负面效应

威胁不是提高业绩最好的方法

如果分配的时间一开始就不够,不管威胁有多吓人,工作也无法按时完成。

更糟糕的是,如果目标没有实现,你就必须兑现你的威胁。

体会:

4、管理者必需的身体部位

管理涉及到心、肠胃、灵魂和鼻子

用心来领导

相信你的肠胃(相信你的预感)

构筑团队的灵魂

训练一个能嗅出谎言的鼻子

体会:

5、用指挥战争来作为管理的一个比喻

在战争开始的时候,管理者真正的工作已经完成了。

体会:

6、面试和招聘

招聘涉及到所有与管理相关的身体部位:心、灵魂、鼻子和肠胃(但主要是肠胃)

不要试图单独去招聘――两副肠胃远比一副肠胃的两倍要好。

对于新的雇员,让他们承担与以前曾经成功过的同样难度的项目,把有挑战性的目标推迟到下一步。

征求提示:你最希望雇的那个人可能还知道其他很好的人选。

多听、少说。

如果先把材料整理好,那么所有的事情都会进行的更好。

体会:

7、生产力的提高

没有“短期生产力提高”这样的东西。

生产力提高是来自长期投资的。

任何承诺立刻见效的东西都很可能是江湖游医所卖的万金油。

体会:

8、风险控制

通过控制风险来管理项目

为每个项目创建并维护风险统计表

跟踪根源性的风险,而不只是最后那讨厌的结果。

评估每种风险具体化的概率和可能造成的开销。

对于每种风险,预测标志其具体化的早期征兆。

任命一个风险控制官,这个人不应该维护组织内部“我能行”的态度。

建立简单(可能是匿名的)通道,让坏消息传递到高层。

体会:

9、防止失败

壮士断腕

控制住失败比优化成功更能提高你的全面成绩。

要有闯劲,尽早取消失败的工作。

除非必要,否则就不要自己去凝聚一个团队:出去找一个已经成型的团队来用。

保持好的团队在一起(只要他们自己愿意),以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。

把凝聚在一起的团队――准备充分、并且愿意接受新的工作――作为项目的收获之一。

体会:

10、项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同样的

有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间。

体会:

11、开发过程的建模和模拟

将你关于完成工作的过程建模

在同事的交流中使用这些模型,以便交流、提炼关于项目运转的思维。

用模型来模拟项目的结果。

根据实际的结果来调整模型。

体会:

12、度量

度量每个产品的规模

不要执著于单位――在等待客观度量的时候,先用你自己的主观单位。

从所有能得到的原始数据(可计算的软件特性)自己构造度量单位。

从已经完成的项目中收集原始数据,以推导出生产力趋向。

不断完善你的度量方程式,直到它的计算结果与原始数据库中的项目工作量有最好的对应关系。

借助数据库画一条趋势线,把预期工作量作为人造度量单位值的函数显示出来。

现在,针对每个要评估的项目,计算出人造度量单位值,并根据这个值在趋势线上找到预期工作量值。

用生产力趋势周围的干扰水平作为映射的公差指示。

体会:

13、过程和过程改进

好的过程和持续的过程改进是绝好的目标

它们也是非常自然的目标:优秀的技术工作者一定会关注它们,不管你是否告诉他们。

正式的过程改进程序需要化钱、花时间;特定的过程改进工作还会延缓项目的进度。尽管最终会体现出生产力上的收获,它们也不可能抵消花在过程改进上的时间。

但是,项目有希望从单个的、正确选择的方法改进中得到足够的收益,并赢回为这次改变付出的时间和金钱。

在项目进行的过程中,不要希望在超过一个方法的范围内实施改进。多种技术的改进程序(比如提高整整一个CMM等级)很可能让项目比不实施这些程序完成的更晚。

标准过程的危险就在于人们可能失去的重要的走捷径的机会。

特别对于人员超编的项目,标准过程看上去会很严谨,因为它们制造了足够的工作(有用的和无用的),让所有人都忙碌不停。

体会:

14、改变完成工作的方式

如果不大幅度减少调试的时间,就没办法让项目大幅度提前完成。

高速完成的项目用在调试上的时间也成比例的少得多。

高速完成的项目用在设计上的时间也成比例多得多。

体会:

15、如果你不关心别人、不照顾别人,就别想让他们为为你做一些不同寻常的事情。如果要让他们改变,就必须去了解并赞赏他们的过去

体会:

16、压力的效果

压力之下的人无法更快地思考。

增加加班时间只会降低生产力。

短期的压力乃至于加班可能是有用的策略,因为它们能使员工集中精力,并且让他们感到工作的重要性。但是长期的压力肯定是错的。

经理之所以会施加那么多的压力,也许是因为他们不直到该做什么,或者因为其它办法的困难而感到气馁。

最坏的猜测:使用压力和加班的真正原因是为了项目失败的时候让所有人看上去能好一点。

体会:

17、愤怒的经理

管理中的愤怒和羞辱是会传染的。如果高级管理者喜欢骂人,低级管理者也会有样学样(就像经常被骂的小孩很容易变成爱骂人的父母)。

如果经理使用辱骂的方法来刺激员工,这就表现出经理的无能,而不是员工的无能。

体会:

18、含糊的规格文档

规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。

如果一份规格文档不包含完整的输入输出列表,那么它就是毫无希望的:它根本就还没有开始说明任何东西。

没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己,而不是责备文档。

体会:

19、冲突

只要在开发过程中有多个参与者,就一定会有冲突存在。

创建、安装系统的业务中特别容易出现冲突。

决大多数系统开发团队都缺乏解决冲突的能力。

冲突应当引起重视。冲突并不是缺乏职业道德的行为。

应当提前声明:所有人的“赢”都是受重视的。确保每个级别的人都能赢。

谈判困难;调解容易。

如果两个人的利益是完全或部分相斥的,预先做好安排,准备好请双方通过调解来解决冲突。

记住:我们都站在同一边;跟我们对立的,是我们要解决的问题。

体会:

20、催化剂的角色

有这样一种催化剂式的人格。这样的人会帮助团队成型并凝聚,保持团队的健康和生产力,从而对项目作出贡献。就算催化剂别的什么事情都不干(其实,通常他们还会干很多别的事),这种催化剂的角色也是重要而有价值的。

调解是“催化剂”的一项特出工作。调解是可以学的,而且只需要很小的投资就能学会。

调解应该从一个小小的仪式开始。“我能帮你们调解一下吗?”在解决冲突的时候,这是必要的第一个步骤。

体会:

21、人类的错误

将你置于死地的,不是你不知道的东西……而正是你“知道”绝不会置你死地的东西。

体会:

22、人员安排

在早期,人员超编会迫使项目跨过关键的设计阶段(这是为了让所有的人都有事可做)。

如果在设计完成之前,工作先被分给了许多人,那么人与人之间、工作组之间的接口就会很复杂。这会使团队内部耦合度提高,会议时间、重复劳动和无效工作都会增加。

理想的人员安排是这样:在项目的大部分时间里由小型核心团队来做设计工作,在开发的最后阶段(时间安排的最后1/6)加入大量的人手。

可怕的猜想:时间安排紧迫的项目,于时间安排比较合理的项目比起来,完成的时间反而会更长。

体会:

23、项目社会学

让不必与会的人可以放心的离开,从而保持会议的精简。有一份公开的议程,并严格执行,这是最简单的方法。

项目需要仪式。

用小小的仪式来使人们注意项目的目标和理想状态:小规模会议、零缺陷工作等等。

采取行动,防止人们随便发怒。

记住:愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样做的。

意见:如果所有人都懂的“愤怒=恐惧”这个道理,就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧,他也就不会再生气了。(这不能解决这些生气的人的问题,但是肯定可以让其他人好受一些。)

体会:

24、基本常识

项目既需要目标也需要计划。

而且这两者应该不同。

体会:

总结:


原创粉丝点击