高德拉特似的写作方式，内容充实，美中不足的是少了一点引导读者自己思考的过程。
到底怎样在固定期限内高质量的完成项目？作者通过一个故事阐明了自己的观点。观点涵盖了管理方法、领导方式、项目管理等方面，其中不仅包括一些老生常谈的内容，还包括很多很有突破性的观点。
总结一下，韦伯斯特成功的要素是什么呢？首先找到了合适的人，继而为他们安排了合适的岗位，想办法解决团队中的冲突，找具有催化剂作用的人保持团队团结，为团队付出爱。顶住病态政治的压力。意识到风险控制的重要性，不管项目多急团队规模一开始也不宜过大，设计要放在极其重要的位置，加班无益于项目交付日期的提前，用工具探寻直觉模型并衡量生产效率，用功能点衡量项目规模，关注员工的有效工作时间，减少项目中的浪费，提高开会的效率，提升文档的编写质量。认识到了愤怒的经理是无能的表现。
以下是书中总结的具体内容及备注：
管理方法：
优秀管理四大要素：
* 选择正确的人
* 分配给他们正确的工作
* 保持他们的积极性
* 帮助团队积聚起来并保持团队的凝聚力
* （其他一切都只是“文案”）
管理者必需的身体部位
* 管理涉及到心、肠胃、灵魂和鼻子。
* 因此．．．
*
* 用心来领导， 人们会回应你的心。他们不会因为你聪明或者因为你一贯正确而追随你，他们只会因为爱你而追随你。
* 相信你的肠胃(相信你的预感)，相信你的直觉
* 构筑团队的灵魂， 团队的价值观、梦想，创建和谐的氛围
* 训练一个能嗅出谎言的鼻子。能识别出谎言。
用指挥战争来作为管理的一个比喻
* 在战役开始的时候，管理者真正的工作已经完成了。
面试和招聘
* 招聘涉及到所有与管理相关的身体部位：心、灵魂、鼻子和肠胃(但是主要是肠胃)。
* 不要试图单独去招聘—— 两副肠胃远比一副肠胃的两倍要好。
* 对于新的雇员，让他们承担与以前曾经成功过的同样难度的项目，把有挑战性的目标推迟到下一次。
* 征求提示：你最希望雇的那个人可能还知道其他很好的人选。
* 多听，少说。
* 如果先把材料整理好，那么所有的事情都会进行得更好。
人员安排：
* 在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人有事可做）。
* 如果在设计完成之前，工作先被分给了很多人，那么人与人之间、工作组之间的接口就会很乱套。
* 这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。
* 理想的人员安排是这样：在项目的的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手。
* 可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目比起来，完成的时间反而会更长。
备注：
* 项目刚一开始，就引入全部项目组成员，导致人员超编。设计是不需要那么多人的，人太多了反而影响设计质量。但除了设计的几个人，项目组其他人无事可做，这是管理人员不能容忍的，所以出现把设计认为地分成几个部分，再分别由各小组完成设计。最终导致设计的失败。
冲突:
* 只要在开式过程中有多个参与者，就一定会有冲突存在。
* 创建、安装系统的业务中特别容易出现冲突。
* 绝大多数系统开发团队都缺乏解决冲突的能力。
* 冲突应当引起重视。冲突并不是缺乏职业道德的行为。
* 应当提前声明：所有人的‘赢’都是受重视的。确保每个级别的人都能赢。
* 谈判困难；调解容易。
* 如果两个人的利益是完全或者部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。
* 记住：我们都站在同一边；跟我们对立的，是我们要解决的问题。
备注：
* 不要害怕冲突，冲突是不可避免的，跟变化一样。一早就承认冲突的存在，做好适当的处理工作．情况会比隐匿冲突好得多。
* 团队整体有一个目标，每个个人有自己的目标，这是导致冲突的一个方面。
* 谈判是零和游戏，调解是由第三方使双方达成共识。求同存异解决冲突。
* 解决冲突的人，要对冲突各方体现出”爱“，要发现冲突各方的优点并赞美，求同存异、柔和地处理问题。
催化剂的角色：
* 有这样一种催化剂式的人物，这样的人能帮助团队成型并凝聚，保持团队的健康和生产力，从而对项目做出贡献。就算“催化剂”别的什么事情都不干（其实，通常他们还会干很多别的事），这种催化剂的角色也是重要而有价值的。
* 调解是“催化剂”的一项特殊工作。调解是可以学的，而且只需要很小的投资就能学会。
* 调解应该从一个小小的仪式开始。“我能帮你们调解一下吗？”在解决冲突的时候，这是必要的第一个步骤。
防止失败
* 壮士断腕。
* 控制住失败比优化成功更能提高你全面的成绩。
* 要有闯劲，尽早取消失败的工作。
* 除非必要，否则就不要自己去凝聚一个团队：出去找一个已经成型的团队来用。
* 保持好的团队在一起(只要他们自己愿意)，以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。
* 把凝聚在一起的团队——准备好、并且也愿意接受新的工作——作为项目的收获之一。
* 项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。
* 有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间。
备注：
* 当你做一些有价值的事情的时候，总会有很多相关的风险，总会有让你的努力付诸东流的可能性。而在软件开发的工作中，情况尤其如此。
* 逆向思维，先考虑可能引起失败的事情，然后避免这些事情的发生。——穷查理宝典
领导方式：
负面效应
* 威胁不是提高业绩最好的方法。
* 如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成。
* 更糟糕的是，如果目标没有实现，你就必须兑现你的威胁。
愤怒的经理：
* 管理中的愤怒和耻辱是会传染的。如果高级管理者喜欢骂人，低级管理者也会有样学样（就像经常被骂得小孩很容易变成爱骂人的父母）。
* 管理中的辱骂常被认为是一种刺激，可以让员工提高效率。在“胡萝卜加大棒”的管理策略中，辱骂是最常见“大棒”。但是，哪有人被辱骂之后还能做得更好的?
* 如果经理使用辱骂得方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
项目管理：
生产力的提高
* 没有“短期生产力提高”这样的东西。
* 生产力的提高是来自长期投资的。
* 任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。
备注：
* 避免项目中出现的浪费。时间的、人员的、交流的……浪费
* 关注真正有效的工作时间，应该集中精力去减少无效工作时间所占的比例
风险控制
* 通过控制风险来管理项目。
* 为每个项目创建并维护风险统计表。
* 跟踪根源性的风险，而不只是最后那讨厌的结果。
* 评估每种风险具体化的概率和可能造成的开销。
* 对于每种风险，预测标志其具体化的早期征兆。
* 任命一个风险控制官，这个人不应该维护组织内部“我能行”的态度。
* 建立简单的(可能是匿名的)通道，让坏消息能传递到高层。
备注：
* 在项目中，如果只做一件事，那就是控制风险。
* 关注根源性的风险，小风险
* 列举出所有可能的风险
* 列出每个风险发生的概率以及造成的影响
* 严格监控每个风险项
开发过程的建模和模拟
* 将你关于完成工作过程的直觉建模。
* 在同事的交流中使用这些模型，以便交流、提炼关于项目运转的思想。
* 用模型来模拟项目的结果。
* 根据实际的结果来调整模型。
备注：
* iThink产品-系统思考软件
* 非常小的团队能够产生非常大的物质生产力。
病态的政治
* 每一天，你都必须准备拿自己的工作打赌．．．．．．．
* ．．．．．．但是这也不能保证“病态的政治”影响你。
* “病态的政治”可能在任何地方出现，哪怕是在最健康的组织里面。
* “病态的政治”的特征：对个人权势的渴望超过了组织本身的目标。
* 即使这种不合理的目标与组织目标背道而驰，它也可能出现。
* “病态的政治”最恶劣的副作用：它精简项目变得危险。
* 别想根治一个病态的人
* 不要浪费时间，也不要因为尝试治疗上司的病态而使自己受到威胁。
* 有时候，你唯一的选择就是等待，等问题自己解决，或者等一个让你继续前进的机会。
* 奇迹时有可能发生的（但是千万别去指望它）。
度量
* 度量每个产品的规模
* 不要执着于单位 – 在等待客观度量的时候，先用你自己的主观单位
* 从所有能得到的原始数据（可计算得软件特性）自己构造度量单位
* 从已经完成得项目中收集原始数据，以推导出生产力趋向
* 借助数据库画一条趋势线，把预期工作量作为人造度量值的函数显示出来
* 现在，针对每个要评估的项目，计算出人造度量单位值，并根据这个值在趋势线上找到预期工作量值
* 用生产力趋势周围的干扰水平作为映射的标示
过程和过程改进：
* 好的过程和持续的过程改进是绝好的目标
* 它们也是非常自然的目标：优秀的技术工作者一定会关注它们，不管你是否告诉他们
* 正式的过程改进程序常需要花钱、花时间；特定的过程改进工作拖延项目进度。尽管最终会体现出生产力上的收获，它们也不可能抵消花在过程改进上的时间。
* 但是，项目有希望从单个的、正确选择的方法改进中得到足够的收益，并赢回为这次改变付出的时间和金钱。
* 在项目进行的过程中，不要希望在超过一个方法的范围内实施改进。多种技术的改进程序（比如说提高整整一个CMM等级）很可能让项目比不实施这些程序完成得更晚。
* 标准过程的危险就在于人们可能失去重要的走捷径的机会
* 特别是对于人员超编的项目，标准过程看上去会很严谨，因为它们制造出了足够的工作（有用的和无用的），让所有人都忙碌不停。
改变完成工作的方式：
* 如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成
* 高速完成的项目用在调试上的时间也成比例地少得多
* 高速完成的项目用在设计上的时间也成比例地多得多
* 如果你不关心别人，不照顾别人，就别想让他们为你做一些不同寻常的事情。如果要让他们改变，就必须去了解（并赞赏）他们的过去。
备注：
* 不要用加法，应该用减法。——一个项目不完美，通常做法是做过程改进，加上这种技巧或那种过程，以为结果会更好，实际上效果不是显著。
* 减少调试时间，增加设计时间，应该学会高效地设计。——通常情况下，出一个设计，并做了评审，这个阶段设计知只是文档，而非指引。但编码时没有完全按照设计来做，又重新设计，且没有做评审。这样的话情况就会很糟。
* 错误通常出现在模块之间的接口处，而非模块内部。
压力的效果:
* 压力之下的人无法更快地思考
* 增加加班时间只会降低生产力
* 短期的压力乃至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长期的压力肯定是错误的。
* 经理之所以会施加那么多的压力，也许是因为他们不知道该做什么，或者因为其他办法的困难而感到气馁。
* 最坏的猜测：是用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。
备注：
* 项目的交付时间不会随着加班时间（压力）的增多而变少，事实上二者之间没有必然联系。项目交付时间不会随着加班时间（压力）变化。原因有二：1、如果项目交付时间定得较短，在项目后期，无论如何追项目交付时间（增加压力），由于程序员天生的玩世不恭，他们会对项目采取破罐子破摔的态度。2、一般来说，正常的想法是在项目前期，适度的压力会提高生产率缩短交付时间，但实际情况是“压力下的人不能更快的思考”，同样的工作反而需要更多的时间，而且加班意味着生产率的降低（反正也得加班，就不太会全力利用上班的正常8小时时间）。加班只会起反作用。
* 所以经理们面对这种情况，要选择“一条难走的路：雇人、激励、团队变动、留住优秀的人、排除掉无用的方法、减少会议、减少加班、减少多余的文档。”
含糊的规格文档:
* 规格文档中的含糊隐含着不同的系统参与者之间存在着未解决的冲突。
* 如果一份规格文档不包含完整的输入输出列表，那么它就是毫无希望的，它根本就还没开始说明任何东西。
* 没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己，而不是责备文档。
备注：
* 人们普遍有一个心理，自己比别人差一点，自己不理解的别人会理解，所以对于一份垃圾文档，谁都不好意思直说，这份文档我看不懂，它是垃圾。
* 文档应简单清晰，把事情说清楚，包括输入、输出、转换方式方法等。如果没说清楚，就是存在着没解决的冲突。
项目社会学：
* 让不必与会的人可以放心离开，从而保证会议的精简。有一份公开的议程，并严格执行，这是最简单的办法。
* 项目需要仪式。
* 用小小的仪式来使人们注意项目的目标和理想状态：小规模会议、零缺陷工作等等。
* 采取行动，防止人们随便发怒
* 记住：愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样做的。
* 意见：如果所有人都懂得“愤怒=恐惧”这个道理，就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧，他也就不会再生气了。（这不能解决这些生气的人的问题，但是肯定可以让其他人好受一些。）
备注：
* 会议前，确定会议主题、议程、大概时间安排，下发给各参与者，并严格执行。这样可以节省大家的时间，有选择的参与。
* 仪式分五部分：①告诉大家，哪怕减少一个与会者都是有必要的，让会议更精简。②要其他人表示同意。③根据会议的情况至少请一个没必要参会的人离开。④这个人在离开之前要告诉大家对会议的希望。⑤其他人表示同意他离开。
安全和变化
* 除非感到安全，否则人们就不能去迎接变化。
* 在所有成功的工程中(以及在绝大多数其他有价值的工作中)，变化都是基本的要素之一。
* 安全感的缺乏会让人们反对变化。
* 逃避风险是致命的，因为这会让你也得不到与风险同在的利益。
* 人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。
其他：
精兵简政：
* 精兵简政是失败的公司使用的办法。它让员工负担失败的责任。
* 公司的目标应该正好相反：兴旺而人性化。
* 当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败和恐吓。
人类的错误:
* 将你置于死地的，不是你不知道的的东西…而正是你“知道”绝不会置你于死地的东西。
基本常识:
* 项目既需要目标，也需要计划。
* 而且这两者应该不同。