之前没有接触过项目管理，借这本书入门。

比较难啃的一本书，有一些收获，了解了项目管理的传统流程。然而结合到实际工作的时候，会发现书里的内容有些偏理论，这本书对于 IT 行业的项目管理帮助不大，但作为入门，还是可以了解项目管理的一些基础知识。

以下是读的过程中随手摘的一些片段：

1. 太多的项目经理不明白，项目管理几乎都是在处理与人的关系。
2. 项目管理不仅仅是排进度表 。
3. 定义一个项目 ，重要的是要明确项目的各项要求 。我认为 ，要求不明确是导致项目失败的最常见原因 。
4. 作为一名项目经理 ，你必须善于处理这些事情 ：沟通 ，冲突 ，激励 ，领导力 ，决策 ，政治 ，等等 ，当然 ，还不限于这些 。
5. 权力有两种。一种是可以吩咐人们去做事的权力 （叫做法定职权 ） ，即对人的权力 ，这是项目经理们通常所没有的 ，他们只能通过发挥自己个人的影响力来解决问题 。第二种权力是独立做决定的权力 ，即无需事先得到批准就可以做决定的权力 。这主要体现在支出管理上。
6. 项目管理其实就是风险管理 。
7. 归根结底你需要成为一名项目领导者 ，而不仅仅是一名项目经理 。领导力让人们愿意跟随你 。我喜欢的领导力定义是 ，领导力是一门艺术 ——让他人想做你认为应该做的事 。在这个定义中起关键作用的词是 “想 ” ，当然你可以通过强迫或报酬让别人做你想完成的事 ，但是 ，使他们想去做某事 ——却是门艺术 ！
8. 自由对 C E O也只是一种空想 ，因为他们的老板比任何人都多 ——股东 、董事会还有公司里的每一名员工 。
9. 如果你是一名真正的项目经理 ，你应当是积极主动的 ，而不是消极被动的 。不管你是否喜欢 ，一名项目经理必须积极主动地采取行动开展项目 。如果你不是这样 ，就需要改变 。
10. 积极主动实际上意味着坚决果断 ，并掌握着主动权 。我们需要区分果断与武断 ，果断意味着坚持自己的权利 ，同时又尊重别人的权利 ；武断只是一味地要求别人服从他的利益 。
11. 当我需要对某事做决定时 ，老板总是不在 。我有幸在什么地方读到过一段话 ：当你没有被赋予权力时 ，最好的方法就是去主动承担权力的抉择 。此后 ，当我找不到老板时 ，我就自行作出决定 ，然后告诉他我做了什么 。我相信 ，正因如此 ，才使我在大约 7年的时间里 ，从一个最初级的职位提升到工程师主管的位置 。我的经验是 ：想有多少权力 ，才能有多少权力 。如果你总是在等待别人赋予你权力 ，你永远都不会拥有它 ，因为你还没来得及证明你能够运用它 。
12. 先斩后奏获得谅解总是比事先获得批准容易 。如果有的组织因过于僵化而使这句话不再适用 ，我就要自问这个地方是否真的适合我 。
13. 许多人只想成为管理者而不是想真正做管理 ！一部分原因是因为经理人拥有地位 、权力 ，并且通常比非管理者领更多的薪水 。
14. 管理的一个常见定义是 ：管理就是通过其他人来完成某项工作 。显然 ，这个定义是不完整的 ，被许多人视为 “现代管理学之父 ”的彼得 ·德鲁克说过 ，管理就是自主地为组织做贡献。他的意思是 ，一个经理人要在问题出现之前提前采取行动 ；或者说 ，一个经理人是积极主动的 ；抑或 ，一个经理人总是设法提高组织的运作效率 ，他必须有前瞻性 。
15. 一个经理人心中也有一个目标 ，他需要制定出实现目标的计划 ，然后采取步骤去实现它 。他也要对比实施进度与计划 ，并在实施情况偏离计划时采取纠正行动 。这就是所谓的控制 ，是管理的一项基本职能 。现在请记住 ，如果你没有计划 ，你就不会知道你要去的地方 ，控制就是一句空话 。同样 ，经理也常常需要改变原定的目标 ，因为环境的变化常常使原定目标变得不合时宜 。
16. 长期计划应当是试探性的 、粗略的 ；每日的计划则能做到 、也应当做到详细而具体。
17. 你还是很容易掉进事必躬亲的 “做事的陷阱 ”中 ，尤其当你的团队里某人有一个技术难题 ，你闭着眼睛就能解决时 ；或者是遇到了某种技术挑战时 （这是最危险的情况 ） 。你必须要明白的是 ，如果你花大量时间做那些技术工作 ，你无法顾及你的本职工作 ——管理 。
18. 多任务并行造成一种很多事可以被完成的错觉 ，是的 ，但是这时的生产率很低 。
19. 几乎所有的奖励系统随着时间的推移都会失败 ，员工总是试图增加他们的奖励 ，而且他们会以牺牲合作甚至实际工作表现来达到目的 。最合情合理的奖励系统是让人们因为真正的成就和他们所作工作的亮点而获得奖赏 ，所有 “胡萝卜加大棒式 ”的奖励系统都会产生问题 。
20. 一般来说 ，他们最重要的事情是尽量将团队成员安排到他们喜欢并觉得有挑战的工作上去 ，并且 ，他们应该积极地创造一个互相尊重和合作的风气 。
21. 内德发现全脑团队 、男女平均的团队比同类人或者同性别人组成的团队能产生更好的结果 。
22. 我们的危险在于 ，我们太容易就一件事情达成一致 ，而缺乏审慎的思考 。正如贝斯对他的团队所讲的 ，我们需要听取不同的声音 ，才能获得比较全面的认识 。
23. 每个项目都是为组织解决问题 ，但是我们经常误认为我们已经解决了问题 ，但实际上并没有 。例如 ，假设你感到头痛 ，你觉得可能是因为压力的关系 ，所以你吃了一些止疼片 ，头痛消失了 ；可是第二天又疼了 ，你又吃了一些止疼片 。这样不断反复 ，直到你认识到问题很严重而去看医生 。经过一番烦琐的检查 ，医生告诉你脑子里有一个肿块 ，必须通过手术才能切除 。
24. 要想让我们的项目不是去解决表面的问题 ，我们就必须在项目定义阶段花更多的时间 。进一步讲 ，我们需要对这里的问题做更清楚 、详细的描述 ，因为如果描述的太模糊往往会表述不清 ，而隐含了更多的事情 。
25. 当你被分配管理一个项目时 ，你应该首先检查待解决的问题 ，并判断你要做的项目是否真的可以得到预期想要的结果 。如果不能解决 ，你需要和项目发起人讨论这件事情
26. 最能激发创造性的因素便是时间底线 （截止日期 ） 。世界创造性思维研究的领袖之一爱德华 ·德 ·博诺曾经提到 ，在他教小孩子创造性思维时 ，如果给他们一个时间底线 ，他们往往会表现出惊人的创造力 。反之 ，如果没有时间底线 ，他们就会无所事事 。
27. 他们相信 ，一天的时间总是可以补上的 ，毕竟他们还有 2 6个星期六可以利用 。第二天 ，依然很忙 ，他们便认为 ，两天的时间也是可以补上来的 。然后就是三天 ，这样一直拖下去 ，直到他们耽误掉一周的工作 ，这时再去弥补已经非常困难了 。
28. 计划的规则 ： ●每项任务的存续期都不应超过 4 ～ 6周 。 ●设计或软件工作的存续期不应超过 1 ～ 3周 。●所有的任务都必须有一个用来表示任务完成的标志 。
29. 所谓拖到最后的意思就是说他们不断推迟工作 ，直到任务快要结束 ，这时如果再碰上技术问题题 ，项目肯定失败无疑 。有一个词叫验收标准 ，也是用来表示相关工作都已完成 。
30. 弥补失去的时间是非常困难的。
31. 一条基本的原则是 ，你计划的细节应当在你可控范围之内 。对设计与软件项目来说 ，这意味着时间应以天来计算 ，比天还精确的事你根本无法控制 。
32. 忽视潜在的风险并不等于“没问题”，相反，它是鲁莽的项目管理方法。
33. W B S有什么用呢 ？首先 ，项目失败的一个主要原因是 ，直到项目要完结时才发现忘记了某些工作 。工作被遗漏会对项目产生重大的影响 ——无论在进度上还是在成本上 。 W B S可以提醒我们不要忘记那些重要的事情 。事实上 ，我还认为 ， W B S是项目管理中最有价值的工具 ，因为它把整个项目连接在一起 ，而人们通常所认为的安排进度表是项目管理中最重要的部分 。有的项目太小了 ，安排进度表简直是在浪费时间 ，但是 W B S却永远不能省略。
34. 项目估时的几种方法：
    1. 一致估计法。让几个对这个任务有些了解的人分别估计完成任务的时间 ——他们之间是相互隔离的。
    2. 日历表估计。
35. 项目预算通常有正负 1 0 % ～ 2 0 %的允差 ，所以期望预算一成不变是很滑稽的事情 。
36. 把工作细节具体到了超出自己管理能力 ，是人们常常容易掉进的陷阱 ，在使用进度表软件时尤其如此 。
37. 结果是 ，我把所有的时间都用在管理进度表上了 ，而不是让它帮助我管理项目 。
38. 首要的原则就是永远不要把工作细节安排到你无法控制的程度 。
39. 把进度表安排到每一天 ，是他们能够控制的 ，但有时安排到星期就够了 。对于要花好几年时间的非常大的项目 ，你会发现 ，工作仅仅安排到了每个月就行了 。
40. 第二条原则适用于工程设计 、程序设计以及其他知识型工作 ，这些工作通常不会产生有形交付物 。对这样的工作 ，原则是任务工期最多不超过 1 ～ 3周 。
41. 两周后 ，他们分析这些时间记录时 ，惊奇地发现 ，原来人们用在项目上的时间只有 2 5 % ，而不是他们假定的 8 0 % ！他们的进度表因为错误的配置水平假定而与现实相差甚远 。
42. 在项目管理中常常犯这样的错误 ，也常常导致各种问题的出现 。只有你把人们 “拴 ”在工作岗位上的时候 ，才可能获得 8 0 %的时间配置水平 ，这一般只适合于工厂工人 。但对知识型工作者来说 ——他们不会被 “拴 ”工作岗位上 ，你也不可能获得这样高的配置水平 ，通常可能只有 5 0 %或 6 0 %左右 。
43. 导致时间分配不足有两个主要原因 。一是人们同时做着太多的项目 ；二是给做项目的人安排了太多工作 。可用时间少的第二个原因是给工作配置过多的人员 ，理解这一点需要了解排队等候理论 。
44. 更重要的一点 ，沟通中的接收方如何知道自己误读了信息 ？显然她并不知道 。因此 ，作为项目经理我们必须要记住一个基本前提 ，就是防止误解是信息发送者而不是接收者沟通职责 。
45. 如果你正在做一项建筑工作 ，你知道天气可能会使项目延期 ，作为项目经理 ，不考虑这种延期是不负责任的 。于是 ，你要把项目时间定得比天气良好时所用的时间稍长一些 ，这就叫做保守的进度表 ，是一种正确的建筑项目风险管理 。
46. 与其管理风险 ，不如规避风险 。
47. 当某个关键人员生病或受伤时 ，应当有临时的备用人员来接替其职能 ；当任务需要的时间比预定要长时 ，可以使用加班时间 。正因为如此 ，才尽量不要在项目计划中考虑用加班来完成预定目标 ，加班只能用做备用的应急手段 。
48. 挣值分析法通过对三个方面的测量说明一个项目运行的状态 。这些测量指标分别是 ：应该做什么 ，即计划价值 （ P V ） ；已经做了什么 ，即挣值 （ E V ） ；投入的精力或成本 （ A C ） 。
49. 关键比率是一个绩效指数 ，它实际是两个指数的乘积 ，一个是计划绩效指数 （ S P I ） ，另一个是成本绩效指数 （ C P I ） ，这两个指数如下 ： S P I = E V / P V，C P I = E V / A C，在深入分析之前 ，我们先来看一下这些等式的含义 。首先 ， E V是挣值 ，用来衡量你得到的东西 ，你原计划要得到的工作量是 P V ，所以 S P I就是指工作效率 ，或者已完成的工作效率 。 A C是指已完成工作的实际成本 ，所以 C P I可以被视为成本效率 。把这两个比率相乘 ，就得到了一个组合指数 ，称为关键比率 （ C R ） ，如下式所示 ： C R = S P I × C P I
50. 唯一合理的办法是每天都做记录 ，这不会花很长时间 ，如果花的时间超过 5分钟 ，你就是过分认真了 。
51. 在项目进行的每一步都应该增加最终产品的给消费者带来的价值 。根据这个观点 ，我们得出的结论就是淘汰任何没有增加价值的行为 。
52. 领导者具体的责任如下 ： ●规定会议议程和时间限制 ； ●保持会议主题不偏离 ； ●保障想法 ； ●启发沉默的成员 ； ●制止喋喋不休者 ； ●控制窃窃私语者 ； ●阻止无关的评论 ； ●像一个指挥家 。
53. 我本人也主持过会议 ，那些实验室技工不愿意发言 ，因为他们被工程师排挤了 ，他们觉得他们的想法将不会受到欢迎 。在这种情况下 ，我特意说 ， “我想听听技工们的想法 。你们对这个有什么想法呢 ？ ”或者 “你有什么想法 ？ ”最后发现 ，工程师们从技工们的好想法里面学到了很多东西 ，他们开始在会后征求这些想法 。因此 ，我们得到了那些经常被忽视的人们所做出的贡献 。
54. 会议领导者必须坚持让善于说话的成员保持沉默 ，而其他人拥有机会表述 。
55. 我当然建议你试着影响你的老板 ，试着用理性面对现实 。但是如果你发现你正在面对一个对你的任何合理的方式都没有反应的领导 ，那么你只能保护你自己 ，调离你所在的部门或者如果必要的话重找一份工作 。人生苦短 ，不能承受持续的压力 。布鲁斯 ·利普顿 （ B r u c e L i p t o n ）说过压力引起疾病甚至导致死亡 ，你一定要听命于你自己而不是让工作压力扼杀你 （ L i p t o n ， 2 0 0 8 ） 。
56. 最后 ，多读管理方面的畅销书 ，找出高级管理者们正在读的书来读 ，你将会到达和他们一样的高度 。
57. 如果不喜欢管理项目中的政治方面的工作 ，可以在项目中寻找在政治之外的工作或者直接寻找另一份职业 。这不是我的草率之言 ——人生若短 ，不能将时间花费在做你完全厌恶的事情上 。如同我的朋友道格 ·德卡罗说的那样 （我在前面提到过 ） ，不要指望花的时间多就能把自己不喜欢的事做好 ，不要抱着如果做好了就会喜欢的想法 ，很遗憾 ，从来都不会这样 。
58. 神经语言程序的创始人之一约翰 ·葛瑞德在他的研讨会上曾告诉我们小组成员 ，如果想成为好的经理就要学习一门课 ——表演 。我坚信他是对的 。祝你好运 ，愿你因项目管理的表演赢得奥斯卡奖 。