最后期限
*安全和变化
除非感到安全感，否则人们不能去迎接变化
在所有的工程中，变化都是最基本的要素之一
安全感的缺乏会让人们反对变化
逃避风险是致命的，因为这会得不到与风险同在的利益
人们可能因为来自客观世界的直接的恐吓而没有安全感，但是觉察到管理者可能滥用权力来惩罚自己，它们也会觉得没有安全感
*负面效应
威胁不是提高业绩最好的方法
如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成
更糟糕的是，如果目标没有实现，你就必须兑现你的威胁
*管理者必需的身体部位
管理涉及到心，肠胃，灵魂和鼻子
因此。。。
用心来领导，
相信你的肠胃(相信你的预感)
构筑团队的灵魂，
训练一个能嗅出谎言的鼻子
*用指挥战争来作为管理者的一个比喻
在战役开始的时候，管理者真正的工作就已经完成了
*面试和招聘
招聘涉及到所有与管理相关的省体部位:心，灵魂，鼻子和肠胃
不要试图单独去招聘
对于新的雇员，让他们承担与以前曾经成功过的同样难度的项目，把有挑战性的目标推迟到下一次
征求提示:你最可能雇的那个人可能还知道其他很好的人选
多听，少说
如果先把材料整理好，那么所有的事情会进行得更好
*成产力的提高
没有短期生产力提高 这样东西
生产力的提高是来自长期投资的
任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵药
*风险控制
通过控制风险来控制项目
为每个项目创建并维护风险统计表
跟踪根源性的风险，而不只是最后讨厌的结果
评估每种风险具体化的概率和可能造成的开销
对于每种风险，预测标志其具体化的早期征兆
任命一个风险控制官，这个人不应该维护组织内部“我能行”的态度
建立简单的通道，让坏消息传递到高层
*防止失败
壮士断腕
控制住失败比优化成功更能提高你全面的成绩
要有闯进，尽早取消失败的工作
除非必要，否则就不要去凝聚一个团队:找出一个已经成型的团队来用
保持好的团队在一起，以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题
把凝聚在一起的团队-- 准备好，并且也愿意接受新的工作--作为项目收获之一
项目开始时浪费的一天喝最后一天对项目造成的伤害是同等的
有无数种方法可以浪费一天的时间。。。但是没有任何一种方法可以拿回一天的时间
*开发过程中的建模和模拟
将你关于完成工作的直觉建模
在同事的交流中使用这些模型，以便交流，提炼关于项目运转的思想
用模型来模拟项目的结果
根据实际的结果来调整模拟
*病态的政治
每一天，你都必须拿自己的工作打赌
但是这也不能保证 病态政治 影响你
病态政治 可能出现在任何地方，哪怕是在最健康的组织里面
病态政治的特征：对个人权势的渴望超过了组织本身的过程
即使这种不合理的目标与组织目标背道而驰，它可能出现
病态政治最恶劣的副作用 它精简项目变得危险
*度量
度量每个产品的规模
不要执着于单位，在等待客观度量的时候，先用你自己的主观单位
从所有能得到的原始数据自己构造度量单位
从已经完成的项目中收集原始数据，以推导出生产趋势向
借助数据库画一条辅助线，把预期工作量作为人造度量值的函数显示出来
现在，针对每个评估的项目，计算出人造度量单位值，并根据这个值在趋势线上找到预期工作量
用生产力趋势周围的干扰水平作为映射的标示
*过程和过程改进
好的过程改进和持续的过程改进是绝好的目标
它们也是非常自然的目标：优秀的技术工作者一定会关注它们，不管你是否告诉他们
正式的过程改进程序需要花钱，花时间；特定的改进过程拖延项目进度。尽管最终会体现生产力的收获，它们也不可能抵消花在过程改进上的时间
但是，项目有希望从单个的，正确选择的方法改进中得到足够的收益，并赢回为这次改进付出的时间和金钱
在项目的进行过程中，不要希望在超过一个方法的范围内实施改进。多种技术的改进程序(比如说提高整整一个CMM等级)很可能让项目比不上实施这些程序完成更晚
标准过程的危险在于人们可能失去重要的走捷径的机会
特别是对于人员超编的项目，标准过程看山去很严谨，因为它们制造出了足够的工作，让所有人忙碌不停
*改变完成工作的方式
如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成
高速完成的项目用在调试的时间也成比例地少得多
高速完成的项目用在设计上的时间也成比例地多得多
如果你不关心别人，不照顾别人，就想让他们为你做一些不平常的事情。如果让他们改变，就必须去了解他们的过去
*压力的效果
压力之下无法更快地思考
增加加班时间只会降低生产力
短期的压力哪至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长期压力肯定是错误的
经理之所以会施加压力，也许是因为他们不知道该做什么，或者因为其他办法的困难而感到气馁
最坏的猜测：是用压力和加班的真正原因是为了在项目失败的时候让所有人好看一点
*含糊的规格文档
规格文档中的含糊隐含着不同系统参与者之间未解决的冲突
如果一份规格文档不包含完整的输入输出列表，那么它是毫无希望的，它根本就还没开始说明任何东西
没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己，而不是文档
*冲突
在要在开发过程中有多个参与者，就一定会有冲突存在
创建，安装系统的业务中特别容易出现冲突
绝大多数系统开发团队缺乏解决冲突的能力
冲突应当引起重视。冲突并不是缺乏职业道德的行为
应当提升声明:所有人的赢都应该受到重视。确保每个人在每个级别上都能赢
谈判容易；调解困难
如果两个人的利益是完全或者部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突
记住：我们都站在同一边；跟我们对立的，是我们要解决的问题
*人类的错误
将你置于死地的，不是你不知道的东西。。。而正是你 知道 绝不会置你于死地的东西
*人员安排
在早期，人员超编迫使项目跨过关键的设计阶段
如果在设计完成之前，工作被分给了很多人，那么人与人之间，工作组之间的接口就会很乱
这会迫使团队内部耦合度提高，会议时间，重复劳动和无效工作都会增加
理想的人员安排是这样的:在项目的大部分时间里由小型核心团队来做设计安排，在开发的最后阶段加入大量的人手
可拍的猜想：时间安排紧迫的项目，与时间安排比较合理的项目比起来，完成的时间反而更长
*项目社会学
让不必与会的人放心离开，从而保证会议的精简。有一份公开的议程，并严格执行，这是最简单的方法
项目需要仪式
用小小的仪式来使人们注意项目的目标和理想状态：小规模会议，零缺陷工作等等
采取行动，防止人们随便发怒
记住：愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才这样做的
意见：如果所有人懂得 愤怒=恐惧 这个道理，就能明显地看出发怒的人是在害怕。由于无法再隐藏自己的恐惧，他也就不会再生气了
*病态的政治
别想根治一个病态的人
不要浪费时间，也不要因为尝试治疗上司的病态而使自己受到威胁
有时候，你唯一的选择就是等待，等待问题的解决，或者等待一个让你继续前进的机会
奇迹时有可能发生，但是不要指望它
*精兵简政
精兵简政是失败的公司使用的办法。它让员工负担失败的责任
公司的目标应该正好相反：兴旺而人性化
当你听到精兵简政这个词的时候，请记住它的弦外之音：失败和恐吓
