压力的效果
压力之下的人无法更快地思考。
增加加班时间只会降低生产力。
短期的压力乃至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长时间的压力肯定是错误的。
经理之所以会施加那么多的压力，也许是因为他们不知道该做什么，或者因为其它办法的困难而感到气馁。
最坏的猜测：使用压力和加班的真正原因是为在项目失败的时候让所有人看上去能好一点。
愤怒的经理
管理中的愤怒和羞辱是会传递的。如果高级管理者喜欢骂人，低级管理者也会有样学样(就像经常被骂的小孩很容易变成骂人的父母)。
管理中的辱骂被认为是一种刺激，可以让员工提高效率。在“胡萝卜加大棒”的管理策略中，辱骂是最常见的“大棒”。但是，哪有人被辱骂之后还能做得更好呢？
如果经理使用辱骂的方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
含糊的规格文档
规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。
如果一份规格文档不包含完整的输入输出列表，那么它就是毫无希望的：它根本就还没开始说明任何东西。
没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己，而不是责备文档。
冲突
只要在开发过程中有多个参与者，就一定会有冲突存在。
创建、安装系统的业务中特别容易出现冲突。
绝大多数系统开发团队都缺乏解决冲突的能力。
冲突应当引起重视。冲突并不是缺乏职业道德的行为。
应当提前声明：所有人的‘赢’都是受重视的。确保每个级别的人都能赢。
谈判困难；调解容易。
如果两个人的利益是完成或者部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。
记住：我们都站在同一边；跟我们对立的，是我们要解决的问题。
催化剂的角色
有这样一种催化剂式的人格。这样的人会帮助团队成型并凝聚，保持团队的健康和生产力，从而对项目作出贡献。就算“催化剂”别的什么事情都不干（其实，通常他们还会干很多别的事），这种催化剂的角色也是重要和有价值的。
调解是“催化剂”的一项特殊工作。调解是可以学的，而且只需要很小的投资就能学会。
调解应该从一个小小仪式开始。“我能帮你们调解一下吗？”在解决冲突的时候，这是必要的第一个步骤。
人类的错误
将你置于死地的，不是你不知道的东西……而正是你“知道”他不会置你于死地的东西。
人员安排
在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人都有事可做）。
如果在设计完成之前，工作先被分给许多人，那么人与人之间、工作组之间的接口就会很复杂。
这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。
理想的人员安排是这样：在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手。
可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目比起来，完成的时间反而会更长。
项目社会学
让不必与会的人可以放心的离开，从而保持会议的精简。有一份公开的议程，并严格的执行，这是最简单的办法。
项目需要仪式。
用小小的仪式来使人们注意项目的目标和理想状态：小规模会议、零缺陷工作等等。
采取行动，防止人们随便发怒。
记住：愤怒＝恐惧。随便对下级发怒的人经理一定是因为恐惧才会这样做的。
意见：如果所有人都懂得“愤怒＝恐惧”这个道理，就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧，他也就不会再生气了。（这不是能解决这些生气的人的问题，但是肯定可以让其他人好受一些。）
精兵简政
精兵简政是失败的公司使用的办法，它让员工负担失败的责任。
公司的目标应该正好相反：兴旺而人性化。
当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败和恐吓。
基本常识
项目既需要目标，也需要计划。
而且这两者应该不同。
终于把它看完了，这次收获比第一次大多了，大概是第一次的200%。如果看第三次的话，效果可能只有第一次的50%。因为第三次看的话，只要看看这些准则就OK了。
这本书的学习次数和效果图：
项目管理也是一门哲学，关于人的哲学。现在我可以放下心去看看PMI了。
……
