汤普金斯先生的日记
汤普金斯先生的日记
《最后期限》（The Dead Line）
[美]汤姆.迪马可（Tom Demarco）/著
UMLChina 翻译组/译
Harli阅读笔记 + 心得
1 （第二章P10）
阅读摘要：
雇佣人是经理所做的惟一重要的事。
如何建设一个团队、如何保持团队的健康、如何带领团队起步、如何给他们凝聚在一起的机会。
管理中最根本的四个要素：人员的选择、任务的分配、激励或者团队构建。
2 （第三章P14）
阅读摘要：
如果你的人分散在不同的地方，你就什么都干不成。把他们集合起来。
3 优质管理的四大要素（第四章）
选择正确的人 —— 人员的选择。
为他们分配正确的工作 —— 任务的分配。
保持他们的积极性 —— 激励。
帮助团队凝聚起来并保持团队的凝聚力 —— 团队构建。
(其他一切都只是“文案”。)
4 安全和变化（第四章）
除非感到安全，否则人们就不能去迎接变化。
Harli： 温伯格《理解专业程序员》：变化的第二惯性定律。 Harli。
在所有成功的工程中(以及在绝大多数其他有价值的工作中)，变化都是基本的要素之一。
安全感的缺乏会让人们反对变化。
逃避风险是致命的，因为这会让你也得不到与风险同在的利益。
人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。
5 负面效应（第五章）
威胁不是提高业绩最好的方法。
如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成。
更糟糕的是，如果目标没有实现，你就必须兑现你的威胁。
6 管理者必需的身体部位（第六章）
管理涉及到心、肠胃、灵魂和鼻子。因此．．．
用心来领导，
相信你的肠胃(相信你的预感)，
构筑团队的灵魂，
训练一个能嗅出谎言的鼻子。
7 用指挥战争来作为管理的一个比喻（第七章）
在战役开始的时候，管理者真正的工作已经完成了。
Harli：注意后面的说明 —— 巴顿将军。Harli。
8 面试和招聘（第七章）
招聘涉及到所有与管理相关的身体部位：心、灵魂、鼻子和肠胃(但是主要是肠胃)。
不要试图单独去招聘—— 两副肠胃远比一副肠胃的两倍要好。
对于新的雇员，让他们承担与以前曾经成功过的同样难度的项目，把有挑战性的目标推迟到下一次。
征求提示：你最希望雇的那个人可能还知道其他很好的人选。
多听，少说。
如果先把材料整理好，那么所有的事情都会进行得更好。
9 生产力的提高（第八章）
没有“短期生产力提高”这样的东西。
生产力的提高是来自长期投资的。
任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。
10 风险控制（第八章）
通过控制风险来管理项目。
为每个项目创建并维护风险统计表。
跟踪根源性的风险，而不只是最后那讨厌的结果。
评估每种风险具体化的概率和可能造成的开销。
对于每种风险，预测标志其具体化的早期征兆。
任命一个风险控制官，这个人不应该维护组织内部“我能行”的态度。
建立简单的(可能是匿名的)通道，让坏消息能传递到高层。
11 防止失败（第九章）
壮士断腕。
控制住失败比优化成功更能提高你全面的成绩。
要有闯劲，尽早取消失败的工作。
除非必要，否则就不要自己去凝聚一个团队：出去找一个已经成型的团队来用。
保持好的团队在一起(只要他们自己愿意)，以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。
把凝聚在一起的团队——准备好、并且也愿意接受新的工作——作为项目的收获之一。
项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。
有无数种方法可以浪费一天的时间．．．但是没有任何一种方法可以拿回一天的时间。
12 开发过程的建模和模拟（第十章）
将你关于完成工作过程的直觉建模。
在同事的交流中使用这些模型，以便交流、提炼关于项目运转的思想。
用模型来模拟项目的结果。
根据实际的结果来调整模型。
Harli： 温伯格《质量-软件-管理：1-系统思维》：反馈控制模型。 Harli。
13 病态的政治（第十一章）
每一天，你都必须准备拿自己的工作打赌．．．．．．．
．．．．．．但是这也不能保证“病态的政治”影响你。
“病态的政治”可能在任何地方出现，哪怕是在最健康的组织里面。
“病态的政治”的特征：对个人权势的渴望超过了组织本身的目标。
即使这种不合理的目标与组织目标背道而驰，它也可能出现。
“病态的政治”最恶劣的副作用：它精简项目变得危险。
内容摘要：
非常小的团队能够产生非常大的物质生产力。
14 度量（第十二章P96）
度量每个产品的规模
不要执着于单位 – 在等待客观度量的时候，先用你自己的主观单位
从所有能得到的原始数据（可计算得软件特性）自己构造度量单位
从已经完成的项目中收集原始数据，以推导出生产力趋向
借助数据库画一条趋势线，把预期工作量作为人造度量值的函数显示出来
现在，针对每个要评估的项目，计算出人造度量单位值，并根据这个值在趋势线上找到预期工作量值
用生产力趋势周围的干扰水平作为映射的标示
内容摘要：
让一个人发挥自己的能力和才干，他就会发光。这正是管理的全部精髓。
寻找思考的催化剂。
可以从原始度量单位构造出某种人造单位。
每个人都必须找到自己的平衡点。
15 过程和过程改进（第十三章P108）
好的过程和持续的过程改进是绝好的目标
它们也是非常自然的目标：优秀的技术工作者一定会关注它们，不管你是否告诉他们
正式的过程改进程序常需要花钱、花时间；特定的过程改进工作拖延项目进度。尽管最终会体现出生产力上的收获，它们也不可能抵消花在过程改进上的时间。
但是，项目有希望从单个的、正确选择的方法改进中得到足够的收益，并赢回为这次改变付出的时间和金钱。
在项目进行的过程中，不要希望在超过一个方法的范围内实施改进。多种技术的改进程序（比如说提高整整一个CMM等级）很可能让项目比不实施这些程序完成得更晚。
标准过程的危险就在于人们可能失去重要的走捷径的机会
特别是对于人员超编的项目，标准过程看上去会很严谨，因为它们制造出了足够的工作（有用的和无用的），让所有人都忙碌不停。
内容摘要：
CMM水平提高一级，你的生产力就可以提高24％。
如果能从商业厂家那里得到完整的用户文档，那么在相似的项日中使用这些需求文档是非常自然的管理决策。
非功能规格和用户手册一起，就构成了完整的需求文挡。
16 改变完成工作的方式（第十四章P116）：
如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成
高速完成的项目用在调试上的时间也成比例地少得多
高速完成的项目用在设计上的时间也成比例地多得多
如果你不关心别人，不照顾别人，就别想让他们为你做一些不同寻常的事情。如果要让他们改变，就必须去了解（并赞赏）他们的过去。
内容摘要：
“如果你不喜欢一个人，又怎么能说服他呢？”
从长期来看，过程改进可能会有正面的作用；但是在短期内，它会造成损失。
我的理论是：千万不要想用加法．而要用减法。
真正的错误，是会浪费你大量时间的错误，是那些与模块和系统其他部分之间的接口有关的错误。”
最后一分钟实现的技术。
在调试阶段寻找错误时看的是模块内部，因此所看的东西是错的。
低级设计才是惟一真实的东西。其他的东西，所谓的概念性设计，完全是用来看的。
17 压力的效果(第十五章)
先哲：压力之下的人无法更快地思考
增加加班时间只会降低生产力
短期的压力乃至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长期的压力肯定是错误的。
经理之所以会施加那么多的压力，也许是因为他们不知道该做什么，或者因为其他办法的困难而感到气馁。
最坏的猜测：是用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。
内容摘要：
加班来得太早了，就无法长期坚持。
程序员天生就是玩世不恭的。
压力下的人不能更快地思考。
增加加班时间只会降低生产力。
一条难走的路：雇人、激励、团队变动、留住优秀的人、排除掉无用的方法、减少会议、减少加班、减少多余的文档。”
18 愤怒的经理（第十六章）
管理中的愤怒和耻辱是会传染的。如果高级管理者喜欢骂人，低级管理者也会有样学样（就像经常被骂得小孩很容易变成爱骂人的父母）。
管理中的辱骂常被认为是一种刺激，可以让员工提高效率。在“胡萝卜加大棒”的管理策略中，辱骂是最常见的“大棒”。但是，哪有人被辱骂之后还能做得更好的?
如果经理使用辱骂得方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
19 含糊的规格文档（第十六章）
规格文档中的含糊隐含着不同的系统参与者之间存在着未解决的冲突。
如果一份规格文档不包含完整的输入输出列表，那么它就是毫无希望的，它根本就还没开始说明任何东西。
没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己，而不是责备文档。
内容摘要：
即使是完全崩溃了的项目，也有可能制造出相当好的规范文档。
“我们做得太多，”他说道，“因为我们担心自己做得太少。”
一份毫无希望的、含糊不清的规格文档，这是一个失败项目的标志。
需要提高的不是我们的表达能力，而是解决冲突的能力。
Harli：规格：条条大道通罗马 —— 关键是起点和终点。Harli。
20 催化剂的角色（第十七章）
有这样一种催化剂式的人物，这样的人能帮助团队成型并凝聚，保持团队的健康和生产力，从而对项目做出贡献。就算“催化剂”别的什么事情都不干（其实，通常他们还会干很多别的事），这种催化剂的角色也是重要而有价值的。
调解是“催化剂”的一项特殊工作。调解是可以学的，而且只需要很小的投资就能学会。
调解应该从一个小小的仪式开始。“我能帮你们调解一下吗？”在解决冲突的时候，这是必要的第一个步骤。
内容摘要：
总会有冲突，不是在这儿就是在那儿。对于一个话题，两个人可能在大多数问题上都能达成共识，但却只看到意见不一致的那部分。
通往智慧的路啊，明白而简单，
我们一错再错，一错再错,
但会越来越好，越来越好。
——派特·海恩
21 冲突（第十七章）
只要在形式过程中有多个参与者，就一定会有冲突存在。
创建、安装系统的业务中特别容易出现冲突。
绝大多数系统开发团队都缺乏解决冲突的能力。
冲突应当引起重视。冲突并不是缺乏职业道德的行为。
应当提前声明：所有人的‘赢’都是受重视的。确保每个级别的人都能赢。
谈判困难；调解容易。
如果两个人的利益是完全或者部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。
记住：我们都站在同一边；跟我们对立的，是我们要解决的问题。
内容摘要：
业务中到处都是冲突。
如果不面对一些严重的冲突，就根本无法建立任何规模的系统。
‘全赢’循环方法学
每当面对冲突的时候，我要你重复这句小咒语：‘谈判困难；调解容易’。
绝大多数时候，冲突双方之间的谈判通常都是零和游戏
所谓调解，就是由一个不涉及冲突的第三方来帮助我们达成共识。
我们怎么让敌对的双方同意调解呢：不要在冲突的时候才去调解，这就是关键。
我们需要在冲突完全形成之前就去调解，这正是‘全赢’的根本。
首先：需要重视组织中的冲突，其次需要建立调解冲突的机制。
Harli：博弈学。 Harli。
22 人类的错误（第十八章）
将你置于死地的，不是你不知道的东西…而正是你“知道”绝不会置你于死地的东西。
23 人员安排（第十九章）：
在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人有事可做）。
如果在设计完成之前，工作先被分给了很多人，那么人与人之间、工作组之间的接口就会很乱套。
这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。
理想的人员安排是这样：在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手。
可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目比起来，完成的时间反而会更长。
内容摘要：
一个低层的设计，能够起到蓝图的作用——能够确定所有的代码模块和接口。
项目制造出了行政性的文档，并把它叫做设计 —— 不是真正的设计。
最后一分钟实现
早期的超编妨碍了明智的设计。
新的管理就是不断的妥协折中，一件需要折中的事就是设计。
接口越多，系统就越复杂，划分就越差。
团队中人与人之间的接口跟系统各部分间的接口是同型的，如果模块划分的工作在设计之前完成．人与人之问的接口肯定比真实的需要复杂得多。
如果项目开始时的时间安排不那么紧迫，反而能提前一两个月乃至一年时间完成。
而你得到的答案肯定是：首先满足项目的要求，尽量帮助他们把工作做好，让他们尽快完成任务。
硬币的另一面！
24 项目社会学（第二十章）
让不必与会的人可以放心离开，从而保证会议的精简。有一份公开的议程，并严格执行，这是最简单的办法。
项目需要仪式。
用小小的仪式来使人们注意项目的目标和理想状态：小规模会议、零缺陷工作等等。
采取行动，防止人们随便发怒
记住：愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样做的。
意见：如果所有人都懂得“愤怒=恐惧”这个道理，就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧，他也就不会再生气了。（这不能解决这些生气的人的问题，但是肯定可以让其他人好受一些。）
内容摘要：
人的问题，这是最常见的。
Harli：《Are your light on？》Harli。
我认为，全世界所有的项目中，大概有10％都可能是行尸。
挫折是金，你可以从中找到更多成功的契机，不管是单独的个人还是像我们这样的工作组。
如果人们觉得没有把握，而会议又没有明确的议程，他们就必须参加。
早期会议的隐藏议程就是找出所有的关键人物，所以，就算你准备了议程，也可能会召集过多的人。
每个会议都要有公开的议程；每个会议都要尽量短，让他们可以根据需要选择参加其中的一部分：会议要严格按照议程进行，这样人们就不必担心自己不参加的会上有与其相关的主题。
在工作中．恐惧是不可容忍的情绪，你绝对不会允许自己害怕。但是，你总会表现出些什么。你总得另外选择一种情绪，不然你会爆炸的。由于某些原因．愤怒是可以接受的情绪，所以人们总是选择发怒，于是愤怒就成了恐惧的代名词。
25 病态的政治（旧话重提）（第二十一章）
别想根治一个病态的人
不要浪费时间，也不要因为尝试治疗上司的病态而使自己受到威胁。
有时候，你唯一的选择就是等待，等问题自己解决，或者等一个让你继续前进的机会。
奇迹时有可能发生的（但是千万别去指望它）。
内容摘要：
应该把这次解散表现成对有价值资源的拯救。我们把他们从绝境中拯救出来，让他们回到关键路径的工作中来。
贝琳达：项目理想的结束方式。
真正的管理：你静静地看着，只是确保它按照计划发展。但是，如果情况有一点点偏差，你就应该插手。 —— 前面战争作为比喻的补充。
建构计划给我们一种一切尽在掌握中的感觉。
别去看那些你不知道的东西，注意那些已经知道的。置你于死地的不是那些你不知道的东西，而是那些你知道不会置你于死地的东西。
检查时避免错误最简便的方法。
保证产品质量最简便的方法就是代码检查。
但是，如果检查根本没有查出错误，我们就不该把它当成减少错误的灵丹妙药。
绝大多数的错误都是接口缺陷。
在世界其他地方被人们迷恋的代码检查，其实只是对设计的一种补充。如果在编码之前做了正规而完善的设计，并对设计做了检查，那么我们就不应该需要代码检查。
26 精兵简政（第二十二章）
精兵简政是失败的公司使用的办法。它让员工负担失败的责任。
公司的目标应该正好相反：兴旺而人性化。
当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败和恐吓。
27 基本常识（第二十三章P208）
项目既需要目标，也需要计划。
而且这两者应该不同。
内容摘要：
一个好的目标应该正好踩在‘可能’的边缘上，所以作为计划它就是很糟糕的；
一个好的计划应该是可以达到的，所以它也不适合作为目标。
我做对了什么。做错了什么，学到了什么？
Harli： 吾日三省吾身。Harli。
28 参考文献
1. Tom DeMacro, Timothy Lister.《与熊共舞——软件项目风险管理》
2. Tom DeMacro, Timothy Lister.《人件》
3. Fred Brooks《人月管理》