《极简项目管理》：3步复制成功，告别项目烂尾！
你是不是总在项目启动时信心满满，却在执行中频频踩坑？团队沟通混乱、需求反复变更、进度严重拖延？这本书就是你的救星！
郭致星教授用20年实战经验，提炼出极简项目管理方法论：结构化思维+5大过程组+19个关键步骤。教你将复杂项目拆解为可执行模块，用WBS实现”隐性工作显性化，显性工作结构化”。更重磅的是：书中揭秘如何拥抱变更（不是接受！）、用业务视角替代技术思维、通过阶段化管控降低不确定性。
真正让项目管理变得可复制、可预测！华为、腾讯都在用的科学创业指南，帮你把事办成、让目标落地！
3: 前言 创业公司也适用的极简项目管理法
- 我们处在一个VUCA的时代，易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）给我们的工作带来了很多困扰。变化是VUCA的根源，VUCA时代唯一不变的就是变化。
- 项目管理本质上是一种基于战略方向，组织开拓创新和应对变化的学问，其目的在于调配各方资源，让它们在短时间内形成合力，完成突破性的商业目标。
- 卓越的项目管理能力已成为企业的竞争力，而且是一种核心竞争力。
- 在创业公司，项目管理的糟糕状况更令人触目惊心！
- 过去几年靠运气挣到的钱，今年靠实力基本赔光了！
- 经验仅代表过去，依托于传统要素和经验的管理方法越来越难以适应当下的行业发展需求。
- 切记不要过分迷信自己的经验，经过众人验证的科学方法不同于个人经验，无论个人经验怎样有效，都无法代替被众人验证过的科学方法。
- 未来几十年，经济发展速度很可能会下降，机会也不再遍地都是，这就更需要企业用科学的方法把成本做低、把速度做快、把质量做好。
- 极简项目管理法是一套系统的方法，侧重于实践，注重解决实践中的常见问题。
- 本书中并不包含这些方面的所有知识，而是只给出中小企业和创业团队实施项目的关键步骤和行动策略。
- 本书延续我所钟情的朴实、真实、务实的表达方式。
- 项目管理者可以说是项目的灵魂人物，一方面要选择合适的人管理项目，另一方面要把合适的人培养好，二者都很重要。
- 本书其实是很多人智慧和经历的结晶。
4: 第1章 极简项目管理基础
用户根本不知道自己需要什么，直到你把它摆在他面前。 ——史蒂夫·乔布斯
客户调研后给出的建议方案与客户期望差距很大，导致反复修改和汇报。
“我确实说不清我想要的东西是什么样子的，但我能说清的是你给我的东西不是我想要的。” ——客户经典需求描述
项目因需求不明确而陷入反复修改的困境，最终导致团队不满和项目失败。
5
如果你从不犯错，这意味着你从来没有尝试过任何新事物。 ——阿尔伯特·爱因斯坦
组织的经营活动可以分为两大类：以重复性劳动为主要特征和以非重复性劳动为主要特征。
重复性劳动追求高度一致性（稳定性），例如生产线上的工作，要求每一件产品都一模一样。
非重复性劳动的工作则不同，客户的要求可能不清晰，需要反复修改和调整，例如竺琳的经历。
通过开展持续的活动来生产同样的产品或提供重复的服务的工作就是运营。
为创造独特的产品、服务或成果而进行的临时性的工作则是项目。
6
- 项目开始时总存在说不清的成分
- 人总是用之前见过的东西，来描述一个未曾出现过的东西
- 客户基于他们的阅历与认知，习惯于把自己的需求套到现实中可实现的方法或物质中
- 客户想要的东西和他看到的是一样的，因此在没看到成果之前，客户也提不出具体要求
- 成果呈现给客户后，会刺激客户进行思考，导致不断提出修改意见
- 频繁的变更是由项目工作本身的性质决定的
- 逼着客户在项目开始时把所有问题都说清楚是不合理的，就像“孩子没出生之前，你能把孩子长什么样说清吗？”
7
- 项目是一个业务过程，而非技术过程 - 这是重要的项目思维
- 工程师容易陷入技术指标较劲，反而使问题得不到解决
- 遇到问题后不要试图仅仅解决问题本身，还要去解决问题所在环境的问题
- 正确方法是要求客户说明提出这些要求的原因，通过不断提问找到问题根源
- 围绕使用的背景、环境、目的等业务问题进行提问，而不是围绕技术细节
- 系统工程的基本原理：N维系统产生的问题只有在N+1维系统中才能解决
- 项目管理者应该是业务层面的管理者，需要具备业务建模能力
- 要能把需求确认落地，实施者必须有很好的业务建模能力，并以咨询方式展开
- 必须给客户看到”样板房”（样品、模型、照片等），否则很可能会出问题
- 通过逆向反馈推动客户确认需求，可以较大程度避免理解上的偏差
8
- 客户每一次提出新的要求，都是在帮我们逐步逼近事实真相
- 人喜欢改变但又害怕被改变，面对变更总感觉之前的工作被否定了
- 很多人在遇到变更时，首先想到的是客户多么不可理喻
- 在没有看到最终结果之前，客户怎么知道这是不是最后一次呢？
- “客户虐我千百遍，我待客户如初恋”的说法足以说明问题
- 张口就说负面词汇，是很多职场人焦虑的重要原因之一
- 有的人在面对变更时，不是去消灭新需求，而是去消灭提出新需求的人
- 绝大多数变更不是人的问题，而是项目属性所决定的
- 变更来源于项目属性，与人无关
- “客户在帮我们逐步逼近事实真相”这个结论是积极向上的
- 在项目中拥抱变更（注意是”拥抱”而非”接受”）
- 与人沟通变更时应说：”谢谢你让我离真相又近了一步”
- 关于变更，请务必记住：无关人品，项目使然！
9
- 项目在本质上是独特的、临时的非重复性工作，要求使用有限的资源，在有限的时间内为特定的人（或组织）完成某种特定目标（产品、服务或成果）
- 项目的目的是给出产品、服务或成果，强调结果的独特性和时限的临时性
- 独特性说明项目所创造的成果存在与众不同的地方，即成果的不重复性
- 为创造独特成果而开展的工作过程具有临时性和不重复性
- 这种“不重复性”带来很多不确定因素，这就是项目的风险来源
- 认识“复杂、不确定”的项目的方法是渐进明细
- 独特性、临时性和渐进明细性是项目最显著的三大特性
- 其中独特性和临时性是最基本的特性，渐进明细性是在这个基础上衍生出来的
10
- 每个项目创造的可交付成果（产品、服务或成果）都是独特的
- 项目成果具有“不重复性”，与以往项目存在差异
- 不能认知和掌握的事物会显得比较复杂，对于复杂的事物，人们无法一开始就掌握完备的认识
- 创新性项目完全没有可参考的以往项目，意味着有新的知识有待认知
- 知识仅是对现实世界的近似描述，人不可能掌握任何事物的全部知识
- 已经发生的错误称作问题，可能发生的错误称作风险
- 应该通过完善的程序来管理错误（问题和风险）
- 独特性是相对的，项目与以前项目会存在某些相似性
- 如果每个项目完全独特，就不存在适用于大多数项目的知识
- 独特性使得项目成果具备了某种竞争力
- 独特性提升了项目工作的挑战性
- 项目工作的重要部分是化解复杂性，使之更明确、更可控
11
- 临时性是指项目有明确的起点与终点，商业机会稍纵即逝，未及时交付的项目成果将失去商业价值。
- 临时性是变化的结果，项目为满足新需求而启动，当需求得到满足或不再存在时，项目就会结束。
- 临时性与项目持续时间的长短没有关系，历时一个月或十年的项目都是临时的。
- 临时性可能导致项目经理权限不足，职能经理决定成员的工资、奖金和晋升，而非项目经理。
- 项目团队的临时性是项目带来的挑战之一，团队通常随项目完成而解散，成员需重新找工作。
- 临时性的项目不意味着成果的临时性，项目成果往往具有可持续的长期生命力，例如都江堰水利工程至今还在发挥作用。
- 项目可因多种原因结束，包括达成目标、无法达到目标、资金缺乏、需求不复存在、资源无法获得或法律原因终止。
12
- 渐进明细性是指逐渐细化，意味着项目是在连续积累中分步骤实现的，即逐步明确项目的细节特征
- 应该在整个项目生命周期中反复开展计划工作，对工作进行逐步修正
- 需要渐进明细的方面包括：项目目标、项目范围、项目计划
- 项目目标：从方向性大目标逐渐细化出具体的、可测量的、可实现的小目标
- 项目范围：从粗略的范围说明书细化出工作分解结构（WBS）和WBS词典
- 项目计划：从控制性计划逐渐明细为具体实施计划
- 渐进明细不同于范围蔓延：前者是必须做的，后者是必须避免的
- 渐进明细要在项目边界内进行，以避免演变成范围蔓延
- 渐进明细是正常的，范围蔓延是不正常的、危险的、失控的
- 实现渐进明细的两种方式：
- 化大为小，逐步推进：划分阶段执行不同活动
- 剥洋葱式，逐层深入：先解决当前问题，再逐层深入
- 任何一项工作，如果你更看重它的临时性、独特性和渐进明细性，它就是项目
13
- 战略更多强调的是对于长期目标定位的准确性以及实现目标的方法
- 战略至少应包括两个方面：一是现状（我们现在在哪儿），二是愿景（我们去哪儿）
- 从现状到愿景的路径规划就是所谓的战略规划
- 战略一般要通过开展两种类型的工作得以实现：运营（重复性工作）和项目（非重复性工作）
- 运营以追求效率为目的，赚钱的事要好好干
- 项目的本质是改变业务类工作，以非重复性劳动为主要特征
- 流程和制度本质上是组织的最佳实践，是把自己或前人的经验教训总结到文档上，固化下来
- 项目的价值在于驱动变革
- 运营能够维持组织在一定水平上持续运行，而项目可以实现组织运营水平的提升
- 运营实现组织的持续稳定，项目实现组织的持续发展
- 一静一动，共同支撑起组织的战略落地工作
14
- 作为支撑组织战略落地的半边天，项目管理类工作又可以分为三个层次：项目组合管理、项目集管理和项目管理。
- 项目组合管理位于最上面的第一层，衔接战略规划和项目管理。
- 对于组织来说，做项目是一个投资行为。
- 组织必须认真考虑、评估各项目的特点和价值，以判断它们的投资优先级。
- 项目组合管理首先解决的是投资导向问题，根据战略规划，决定资源分配，确保组织的投资组合收益最大化。
- 项目集管理在项目组合管理的下面一层。
- 战略规划的落地依赖于每个员工都能完成他们的任务。
- 如何能够投入更少的资源去实现既定目标，是企业要解决的第二个问题。
- 把一些有相关性的项目打包在一起，形成项目集，就能够实现节约资源的目标。
- 项目管理类工作的最下面一层是项目管理。
- 项目目标定下来以后，工作重点就是在一定的约束（范围、进度、成本、质量等）下完成既定工作。
- 项目、项目集、项目组合处在项目管理的不同层面，管理的侧重点是不同的。
- 以后在谈项目管理时，建议读者要先判断所谈论的项目管理属于哪一层，因为在不同的层面，思考的角度是不一样的。
15
- 华为目前的项目管理水平还很低，浪费较大，这是过去以功能部门为中心带来的弊病
- 华为将试点以项目部门为中心的管理模式，逐渐使作战团队拥有更多的权利，监管前移，配合授权体系的产生
- “在21世纪的社会中，一切都是项目，一切也必将成为项目” ——保罗·格雷斯
- 项目管理已逐渐成为在当今急剧变化的时代中，企业求生存谋发展的利器
- 项目管理从军事工业逐步进入民用工业领域，到20世纪90年代进入普及阶段
- IBM、微软、惠普和宝洁等跨国公司将项目管理视作一项基本的管理技能
- 华为、腾讯、阿里等中国本土企业也大规模引入项目管理
- 项目按期、按预算和范围完成的比率不足40%，具有很高价值的项目仅为8%
- 项目很少由于技术和”硬”实力方面的不足而失败，却常常因为组织、人力等管理方面的”软”实力不足而失败
- 管理是否有效对于项目的成败十分重要
16
- 任何事物都不及“伟大”那样简单；事实上，能够简单便是伟大。
- 许多常见问题（如“如何提高沟通能力”、“如何管理好项目”）只是表象，不是真正的问题。
- 结构化思维是指一个人在面对工作任务或难题时能从多个角度进行思考，深刻分析问题原因，系统地制订行动方案，并高效执行。
- 拥有结构化思维的项目管理者能更从容应对项目中的困难，对职业生涯有巨大帮助。
17
领导甲指出了问题——沟通能力不行，还要求下属提高沟通能力，这话对不对？对，但这是一句正确的废话！ 下属对于如何提高沟通能力还是一头雾水、不明所以，只能提高悟性（这也是一句正确的废话）。
领导乙的话比较明确，符合结构化思维，相对就比较容易掌握，下属下一次就可以试着改进了。
将同样的内容用不同的结构传递给对方的时候，每个人的记忆黏性是完全不同的。 这也是为什么在日常工作中经常看到同样的一件事情，有的人三句话就能说清楚，而有的人说一下午也说不到核心上。
大脑不能同时处理很多信息。心理学研究发现，我们的大脑同时处理的信息不能太多，否则会让大脑觉得负荷过大。
大脑偏好有规律的信息。 这是大脑赋予人类最重要的技能，也是知识产生的源泉，正是因为有这样的技能，人类才创造了如此非凡的文明成就。
天才和普通人的区别不是在脑容量的多少，而是在处理能力方面，天才往往能够透过纷繁复杂的现象发现本质，也就是核心的规律。
如何将200毫升的水装进100毫升的杯子里？ 这不是一个脑筋急转弯，而是一个真正需要解决的问题。
水之所以会流出来无外乎有三类原因：第一类是杯子的问题，如杯子太小；第二类是水的问题，如它是液体，会流动；第三类是外部环境，如地球引力。
以后遇到问题一定要运用结构化思维，试着从三个方面去解决问题：问题本身、问题的所在环境、问题解决的主体。
问题本身、环境、解决主体这三个维度组成了理解和分析问题的空间结构。掌握了这个结构就能很容易找到问题的多种解决方案，把问题想全面，并且还能分得很清。
结构化思维是人类思维领域的基本规律，内化为思考、外化为表达，所以通过训练结构化思维，可以让我们轻松地找到问题的解决方法。
结构化思维方法对每个人的帮助都很大，建议读者最好能把这种方法变成一种本能的反射。 如果你真的练成此种“神功”，它将在你克服工作上的压力时产生很大的帮助。
18
- 复杂性是项目的固有特点，VUCA时代进一步加剧了项目工作的困扰
- 项目管理的过程就是将复杂问题简单化并予以解决的过程，降低复杂度的核心方法是结构化
极简项目管理采用结构化思维解决问题，具体分为：
- 5个过程组：启动、规划、执行、监控、收尾
- 10个知识领域（如来十掌）
- 19个步骤（三字经）
五大过程组：
- 启动：确立项目合法地位和总体要求，宣布项目正式立项
- 规划：编制项目计划，把目标具体化，制订实现路线图
- 执行：按计划开展活动，把纸面成果变为实际成果
- 监控：比较实际与计划，发现偏差并必要时进行变更
- 收尾：有序开展收尾工作，正式关闭项目
过程组之间的关系不是纯直线式的，会以各种方式相互重叠、交叉、循环
5大过程组实质上是一个PDCA循环，因项目有始有终而增加了启动和收尾
“如来十掌”（10个知识领域）：
- 范围管理：确定工作内容
- 进度管理：确定完成时间
- 成本管理：确定完成代价
- 质量管理：确定可接受程度
- 资源管理：弄清需要谁和哪些资源
- 采购管理：资源不足时的外包需求
- 沟通管理：内外部人员有效协调
- 相关方管理：实现有效参与和期望控制
- 风险管理：识别并管理不确定性因素
- 整合管理：在相互竞争的目标下实现最优
特别说明：请务必熟记”如来十掌”
以五个过程组和”如来十掌”为框架，进一步展开为19个步骤（三字经），形成极简项目管理地图
19: 第2章 启动：师出有名，名正言顺
- 项目不是在结束时失败，而是在开始时失败。 ——项目管理谚语
- 《易经》中的“初难知，上易知”比喻事物初始阶段意义微而未显，难以明确；发展到终末，成败已定，意义则容易明确。
- 项目初期的不确定性最高，后期随着信息的明确，成功与失败都会变得逐渐清晰。
20
- 生命周期模型是项目管理的工具，为项目从启动到收尾提供基本框架
- 项目生命周期通常由一系列顺序排列、有时相互交叉的阶段组成
- 阶段的名称和数量取决于组织的管理需求、项目特征及应用领域
- 读者可以根据组织、行业或技术特性来确定或调整项目生命周期
21
- 所有项目都呈现生命周期结构：启动项目、组织与准备、执行项目工作、结束项目
- 通用生命周期结构为项目间的比较提供宏观视角
- 成本与人力投入在开始时较低，执行期间最高，结束时迅速回落
- 利益相关方的影响力、风险与不确定性在项目开始时最大，随时间递减
- 项目变更的代价包括成本、时间和质量
- 改变产品最终特性的能力在项目开始时最大，随进展而减弱
- 变更和纠正错误的成本在项目接近完成时显著增高
- 项目早期变更应倾向于接受（“让怎么干就怎么干”）
- 项目中期变更需先分析影响，尽可能沟通取消（“要变更，先谈谈”）
- 项目后期变更成本太高，原则上不变更，优先验收收尾（“生米已成熟饭”）
- 项目过程对乙方是“绑架客户上贼船的过程”，对甲方是“逐步移交主动权的过程”
- 在立项和方案阶段花的时间越长，项目周期越短
- 当项目使用10%预算时，已锁定90%最终成本
- 人们总是没有时间把事情做对，却总是有时间返工
- 前期有效选择和策划至关重要，但很多人急于开始而放弃过程
22
当存在不确定性因素时，人们往往会感觉痛苦、煎熬，而不确定性恰恰是项目管理的痛苦来源之一
山田本一通过阶段管控，在长距离田径运动中不受别人影响，完全按照自己的步调进行，是”阶段化管理控制”应用的楷模
项目如同人一样，有出生（启动）和死亡（收尾），每个人的一生虽然不可重来，但生老病死的一般规律大体上总是相似的
通过划分阶段对工作按照时间进行分类，也更容易搞清楚每个时期的主要矛盾是什么
项目阶段化可以减轻痛苦、降低不确定性，从而增强项目经理成功的信心
阶段评审有助于进行项目决策，在每个阶段末，通过将项目的绩效与项目的目标进行比较，可以做出业务上的决策
在实践中，主要会用到两种生命周期模型：瀑布型和敏捷型，不同的生命周期有不同的风险处理方式
瀑布型生命周期：项目管理者及其团队需要完整地预测项目未来
敏捷型生命周期是通过一系列重复的循环活动来完成项目，通常有两种实现方式：迭代和增量
敏捷型生命周期正在成为项目管理的新趋势，因为它可以用于应对快速变化的环境
人们经常采用非此即彼的割裂方式来看待敏捷型生命周期与瀑布型生命周期，实际上两者各有适用场景
23
- 管理优秀的项目败在方向（项目选择）上，管理拙劣的项目败在执行上
- 商业论证需从技术、经济、运行环境、法律、社会可行性等方面评估项目
- 商业论证必须回答三个核心问题：
- 能不能赚钱（机会、市场、财务）
- 能不能搞得定（技术、产能、专利限制）
- 对大家有没有好处（风险、环境、社会效益）
- “磨刀不误砍柴工”对项目的商业论证同样适用，低质量的选择会导致更多“意外”
- 随便开始一个项目是最大的错误
- 国内项目管理乱象可总结为：六拍、四没、三边、只谈
六拍： - 拍脑袋——立项：领导凭感觉决策，缺乏严格论证 - 拍肩膀——任命项目经理：空头激励，缺乏实质支持 - 拍胸脯——承诺：盲目自信，忽视风险 - 拍桌子——相互攻击：问题出现时推诿责任 - 拍屁股——走人：项目经理承受不住压力离职 - 拍大腿——后悔：项目失败后追悔莫及
四没： - 没问题：盲目乐观，风险意识缺失 - 没关系：忽视小问题，积累大隐患 - 没办法：失败后找借口推脱 - 没资源：归咎于资源不足，回避管理责任
三边： - 边设计：目标不清，盲目行动 - 边实施：无序混乱，缺乏计划 - 边修改（边返工）：随意调整，结果失控
只谈： - 项目初期：只谈成本，忽视其他约束 - 项目中期：只谈进度，激化矛盾 - 项目后期：只谈质量，忘记过程痛苦与限制
24
- 如果你不知道要到哪里去，给你张地图也没有用！ ——项目管理谚语
- 计划本身非常有用，但现实的企业环境让它失去了作用。
- 不能只顾低头拉车而不抬头看路，最终忘了自己的主要目标。 ——彼得·德鲁克
- 目标管理是项目管理者变被动工作为主动工作的有效手段。
- 无法对目标实行管理的项目注定会失败。
25
- 自我欣赏的是艺术，他人接受的才是商品：项目必须被客户接受并愿意买单，才能实现商业价值。
- 很多人常犯“以己度人”的错误（投射效应），用自己的标准去推测客户需求，而不是真正理解客户想要什么。
- 项目是以业务为导向的，本质是实现商业价值，过程是基于业务、面向人的过程。
- 设计者常陷入“我以为”的陷阱，以为自己喜欢的产品客户也喜欢，导致产品缺乏市场。
- 一旦给出答案，人们往往努力维护自己的答案，而不是关注客户是否接受。如果客户不接受，产品就无法实现商业价值。
26
西方人总结出了一个法则——SMART法则，即目标必须是明确的（Specific）、可以测量的（Measurable）、可以实现的（Attainable）、相关的（Relevant）、有明确的时限的（Time-based）
“本月要完成人事审批模块的开发”就是典型的不符合SMART法则的目标。既没说明工作究竟是什么，也没说清楚工作的量有多少、怎么测量、如何实现、何时完成
常见的不符合SMART法则的目标有：客户满意（怎样算满意）、快速响应（多长时间算快速）、稳定运行（稳定包含哪些指标）、有效控制（如何算有效）
SMART法则具体含义：
- 明确的：用具体的语言清楚地说明要达成的标准。拥有明确的目标几乎是所有成功项目的共同特点
- 可测量的：应该有一组明确的数据作为测量项目是否达成目标的依据。应从数量、质量、成本、时间、客户的满意程度5个方面进行表述
- 可实现的：相关人员应参与到项目目标的设置过程中，确保目标能在组织及团队之间达成一致。目标既要使项目工作内容饱满，也要具有可实现性
- 相关的：项目目标要与组织目标达成一致，更要考虑达成目标所需要的条件（人力资源、硬件条件、技术条件、环境因素等）。制定目标要兼顾成本和效益
- 有时限的：项目目标是有时间限制的，没有时间限制的目标没有办法考核，或考核容易不公
改进后的目标示例：“本月30日前，在公司已有开发框架的基础上，依据客户确认的人事审批模块需求，完成模块设计文档撰写、代码编写、联调自测并通过评审。时间以上传配置服务器的时间为依据，质量以测试报告及评审报告为依据”
项目是一个复杂的系统过程，项目目标可从需求、进度、成本、质量等互相关联的维度进行定义，”如来十掌”为定义目标提供了框架
27
过高的目标无法实现，不切合实际的目标不仅会失去激励作用，还会让人倍感挫折
目标常常不是基于能力，而是基于愿望。一些介绍项目管理的文章中有关项目成功的光鲜故事使得经理们认为只要他们的团队足够努力，就会非常卓越
在基于愿望的文化中，愿望总是凌驾于评估之上，因此评估再科学也不会被认可
目标建立在愿望大大超过能力的基础上，团队成员只能被迫接受。但是，他们不是发自内心地认可这个目标，于是在后续工作中他们不会努力去实现这个目标，而是用行动来证明你们定的目标是错的
如果目标不切实际，人们就必然会忽视进度和功能等因素，然而，不能按时交付被认为是“绩效”问题而不是目标问题
组织会尝试通过产生问题的方法来修复问题。最常见的解决方法是提高估计和目标技能，因为基于愿望定目标和激励方法是管理文化的一部分
基于愿望的、不切实际的项目目标时常会导致团队功能失调，更是滋生消极组织文化的罪魁祸首
项目团队总是喊“狼来了”，结果导致更低的信用度。他们不停地说“不可能”，从而将自己置于不利境地
如果有人不断地让你做不可能的事，你不断地说“不”，你就会被贴上消极的标签
人们总是将这句话挂在嘴边——“我不知道是否能做到，但我会尽力”。实际上，只盯着项目目标，而不关注实现这样的目标有多困难，这从一开始就注定不可能取得成功
最好的激励方式是激发内部动力，而不是外部强加。把不现实的目标强加给项目团队，不但起不到激励作用，反而会适得其反
那些没提意见，只是毫无怨言地执行不切实际目标的人，经常会因为他们的辛勤工作而最终获得奖励，而那些在一开始就试图反对不现实目标的人会被认为是“阻挠者”
奖励错误的行为会导致下一轮的不切实际。能力与期望的不平衡会使得组织深陷于功能失调的泥淖中
洛克定律：当目标能够达成、指向未来又富有挑战性时是最有效的
“跳一跳，够得着”才是最好的目标，就像篮球架一样，这样才能激发人们的积极性
28
有效地进行需求收集既是一门科学，又是一门艺术 - 这句话反映了需求管理的复杂性，尽管相关书籍很多，实践中仍难以有效执行
东方文化中的含蓄表达增加了目标设置的难度
- 汉语的多义性导致理解不一致，人们常通过描述性语言表达目标，造成普遍问题
- 人们对项目的期望包含多个方面，既有对项目成果特性的要求，又有感情等方面的要求
- 案例：太太三次问“老公，你口渴吗？”却不明说，最终导致误解——简单、直接，又能解决问题
客户话语的可信度问题
- 案例：客户声称喜欢青春靓丽的音箱颜色，但最终都选择了黑色
- 我们能相信客户的判断吗？ 客户调研手段多样，但面对矛盾建议时易混乱
- 重要观点：
- 客户愿意付钱的是其真正需要的，否则就不是
- 少关注客户说什么，多关注客户的行为 - 客户常未认真思考自己说的话，更不用付出代价
- 项目是一个业务过程，而不是技术过程 - 案例：客户要电钻实为挂画，可用粘钩解决；应解决问题所在环境
切忌“鸵鸟心态”
- 案例：H公司回避讨论培训需求，留待后期处理
- 这是一种逃避现实的懦弱行为，其结果只会使问题更趋复杂、更难处理
- 如确实有问题存在而且躲不掉，早吵也会比晚吵好 - 早期解决成本低，尽早暴露问题可安心做事
目标和需求是要确认的
- 案例：筱钧未能获得客户签字，客户要求先做起来再看
- 拿不到签字，下一阶段就不能开始 - 真正目的是让客户认真考虑项目问题
- 你需要“强势”一些，用各种办法“逼迫”客户把目标或需求考虑清楚
- 原则：对事要硬、对人要软
- 项目开始前，主要相关人员必须对项目目标、需求达成一致
29
- 正确识别并合理引导所有相关方参与项目，决定着项目的成败。
- 投其所好，给其所要。人有欲则无刚，爱财则给物，爱书则送书。
- 想要做好一个项目并获得人们的认可，首先要知道与项目有关的人有哪些。
- 项目面临的内外部人员非常繁多、复杂，包括客户、团队成员、各级管理者、供应商、合作伙伴、竞争对手、政府、社区等。
- 项目管理者必须具备系统思考项目全局的能力。
30
- 人们既可能看到项目的积极结果，也可能看到项目的消极结果
- 忽视消极人员，会提高项目失败的可能性
- 项目管理者的重要职责之一就是管理人的期望
- 项目管理者的另一项重要职责就是平衡人们的不同利益
- 客户坚持复杂技术方案的原因：担心因选用新方案出现意外而陷入公司”问责制”的麻烦
- 技术背景越深厚，项目管理者越容易把自己的想法、思路强加给对方
- 很多项目上的问题本身并不是技术层面的
- 一定不要试图仅从技术层面与客户讨论问题
31
- 使用权力–利益方格进行相关方分析，编制相关方登记册并制定相关方管理策略，是项目管理者必须掌握的基本技能
- 编写相关方登记册的步骤包括：收集个人资料、评估期望和态度、确定权力和利益分值、使用权力–利益方格分析影响、基于位置制定管理策略
- 在整个项目生命周期中，必须实时更新相关方登记册和权力–利益方格，确保管理策略是有效的
- 项目的相关方登记册与权力–利益方格的内容可能比较敏感，不宜纳入公开文件
- 在权力–利益方格中，应针对处于不同象限的人采用不同的应对策略
- 不间断地管理第一象限的人，尽可能使其成为项目的支持者，促使项目成功
- 务必小心地管理第二象限的人，管理的重点是不要使他们成为项目的反对者
- 尽可能花费较少的时间管理第三象限的人，监督其对项目的影响即可
- 倾听第四象限的人，他们对项目非常感兴趣，能够提供有用信息
- 在任何情况下，应时刻保持对每个人地位和态度的关注，根据实际情况及时调整和更新
32
- 为什么团队中每个人的智商都高达120，而团队的智商只有62？ ——彼得·圣吉
- 项目管理是一个平衡各方利益、融合各方观点、实现项目目标的过程，几乎每一个环节和步骤都不轻松。
- 人是宝贵的资源，也是最难以把握的资源。
- 整合团队以取得高绩效是一个挑战。
33
- 项目经理是指由执行组织委派，领导团队实现项目目标的个人。
- 项目管理本质上是一种基于战略方向、组织开拓创新的学问，其目的在于组织各方资源在短时间内形成合力，完成突破性的商业目标。
- 本位思考是人的天性，市场人员更多会从市场分类和市场趋势的角度看问题，工程师则会从实用性和功能规格角度看问题。
- 各部门的人员总把“我们部门怎么样”“其他部门怎么样”挂在嘴边，导致“各人自扫门前雪，莫管他家瓦上霜”。
- 计划部门强调进度“要快”，财务部门要求“省钱”，质量部门挥舞“质量第一”的大棒，市场部门高举“客户至上”的大旗。
- 项目管理的本质就是整合，为了做到这一点，你应该站在全局角度来思考和解决问题，找到各相关方之间的平衡点。
- 在绝大多数国内企业里，项目经理都是在有责无权的条件下实施项目的。
- 项目经理既不给团队成员发钱，也决定不了团队成员的升迁，却要安排团队成员干活。
- 高管见到项目经理时，听到的总是一堆坏消息：不是进度拖期了，就是成本超支了；不是质量变坏了，就是客户不满了。
- 项目经理的压力是全方位的，简直就是一个被组织上下所有人“讨厌”的人！
- 如果你喜欢一个人，就让他去当项目经理，因为这使他有机会驱动组织变革；如果你恨一个人，也让他去当项目经理，因为十有八九他会被失败的项目“毁”了。
34
- 旁观者效应导致在群体中每个人的责任被稀释：人越多，每个人越会感到这件事与自己无关。正所谓“鸡多不下蛋，人多瞎胡乱”。
- 在项目团队中，如果管理者没有为团队成员规定明确的责任，很多成员都会产生“我不做，有人做”的想法，导致团队绩效远不如单个成员工作绩效的累加值。
- 为了确保每个人承担起各自对项目的责任，降低“旁观者效应”的影响，必须落实每个人的具体职责。
- 任务落实：每项任务必须有且只能有一个人对其负责。如果一项工作必须由两个人负责，则应该对该任务进一步分解落实。
- 人员落实：必须确保将每个具体工作责任落实到具体个人，而不是一个组织、一个部门、一个小组。不能让任何一个人对项目只享有权利而不承担义务。
- 组织落实：确保在项目组织和实施中，人员、流程、使用管理平台、技术、工具之间协调一致，并建立相应的激励措施等。
- 如何使非下属甚至非公司员工的人员承担起对项目的责任是项目经理面临的挑战。
35
- 使用责任分配矩阵（RAM）有助于实现”三落实”，明确项目活动负责人，降低无人负责的风险
- RAM是一个二维表格，包含相关人员名单、项目活动及对应关系
- 在大型项目中，可在多个层次上建立RAM：高层次定义小组责任，低层次分配具体角色和职责
- RACI是RAM的一种具体形式，代表Responsible（负责）、Accountable（批准）、Consulted（咨询）、Informed（知悉）
- 编写RACI的步骤：填写活动代码和描述→填写项目责任→讨论和审批
- 每项活动有且只能有一个R（负责人），如果不能划分责任，则需要进一步细分活动
- 所有责任必须落实在项目管理团队范围内，如果外部人员负责活动，项目经理需承担管理责任和接口协调责任
- 责任分配完成后，项目负责人还需：确保工作优先级与客户需求一致、向管理层展示团队工作、协调技术解释工作
- 责任不仅是技术性责任，也包括管理责任，涉及对时间、成本、风险等的保证
36
- 企业工作的依据是公司章程，部门工作的依据是部门职责，个人工作的依据是岗位说明书。
- 作为临时性的项目，其工作的依据是项目章程。
- 项目章程是建立项目团队与组织之间契约的核心文件。
37
- 契约精神是文明社会的主流精神之一，在民主法治的形成过程中有着极为重要的作用
- 契约精神实际很简单，就是说话算数，一旦做出了承诺就必须要执行，而且是不打任何折扣的执行
- 契约精神恰恰是一个商业社会最基本的文化，是基因，是维持任何一个社会中人们进行理性判断、预测以及比较的基础
- 项目章程是项目团队与组织的契约，表明项目及其团队已经得到了管理层的支持
- 项目章程是一个内容简单、功能却很强大的文件，作为一个公告性文件，它像一部宪法
- 项目章程是把项目与组织的战略及日常运营工作联系起来的纽带
- 创建项目章程的另一个目的是向项目团队中的每个人告知项目的存在，明确他们对项目的职责和权利
- 契约精神的缺失在项目中也不可避免地体现了出来——国内的项目很少有正式的项目章程
38
- 项目任务书作为项目的一个指导性文件，发挥着类似项目章程的作用
- 项目任务书应该是一个简短的文件（理想情况是一页），简要说明项目要做什么、如何做，和当项目结束时能给企业提供什么样的商业价值
- 项目启动阶段最重要的成果并不是项目任务书本身，而是在编写项目任务书的过程中所获得的洞察力和达成的共识
- 编写项目任务书的过程使得项目发起人、关键相关方和未来的团队成员有机会第一次共同合作，勾勒出项目的意图、远景和方向
- 编制项目任务书的关键是对需求达成早期概念层次的共识，并对需求做出回应
- 批准了项目任务书，就意味着管理层基于对项目及其商业价值的了解，认为有必要正式开始项目
- 项目任务书包含可测量的项目目标和相关的成功标准、项目的总体要求、概括性的项目描述、项目的主要风险等核心内容
- 项目任务书是非常重要、具有约束力的文件，相当于项目的宪法，项目任务书的发布标志着项目的正式启动
- 项目任务书必须指定一位项目经理，并且明确其责任和权力
- 项目任务书不是一成不变的，如果发生重大变更使得原项目任务书不再可行，就应该签发新的任务书
39
- 造成很多项目失败的重要原因之一就是它开始和结束的时候都悄无声息
- 悄无声息地开始意味着项目不重要，不需要太多人知道，导致配合度差
- 悄无声息地结束意味着结果不理想，不希望太多人知道，大家也就不关心
- 如果你的项目需要组织里的其他人共同配合，但没有明确告知“开始”和“结束”节点，就很难让大家名正言顺地配合
- 重要的节点必须要举行仪式，引起领导和相关部门的重视，让项目团队更有凝聚力
- 项目经理首先要自己重视，并积极游说其他人配合，促成项目的启动和总结仪式，为顺利开展打下基础
40
项目不是在结束时失败，而是在开始时失败
一首歌的第一句决定了歌曲的基调，唱好第一句是项目启动所要关注的
初始阶段的交往风格对后期的交往模式产生了长期的影响。而且，这种风格一旦建立，后期难以改变
项目启动会可以通知人们项目已经开始，大家应该慢慢找到工作状态
尽量营造项目的工作氛围，例如张贴项目总体进度图，制作项目的标志图，或者有意识地更换一下项目成员的工位
暗示的最佳方式还是每个人都进行自我暗示
许多沟通的障碍就像某种依靠其神秘性吓人的妖怪，你说出它的名字它就会被消灭
提前制订好可预见问题的处理规则，当事人在面对实际问题时的配合程度将大大提高
先说出对方实际中会遇到的情况，尤其是那些不愉快的情况，同时说出他们在遇到这些不愉快的情况时可能要做出的心理反应
当事情真实发生的时候，对方的固有”程序”便会失去原有效用（免疫效应）
气儿顺了一切都会好起来！
在启动阶段必须明白这些规则的重要性：
- 沟通方式、频率、内容及格式
- 项目管理者的权力
- 甲方责任、需求提供、调研配合和业务指导
- 变更处理的流程、文档、权力
- 团队合作模式、风格、出勤、考核标准、争议解决
- 项目开发方的各个部门的义务及责任
不在项目开始时订好规则，后面的路只会越来越难走
在启动阶段确立规则会让人觉得项目管理者比较教条、刻板，但你要顶住压力
41
- 重要的事儿，得有个仪式，得让大家有个仪式感，这样才能引起大家的重视。
- 省略了项目启动会的项目，其过程往往很混乱，很多人对项目的配合不够，协同性很差，项目目标也就无法按计划实现。
- 名正言顺地正式启动项目极为关键，将项目的相关人员召集到一起举行一次启动会议是非常有必要的。
- 项目启动会是项目实施方法论中的重要一环，会上可能会对项目有关概念的内涵进行解释，以确保大家取得理解上的一致。
- 项目启动阶段出现的很多问题都会是项目后期问题的隐患，特别是从高级管理层及客户那里获得的承诺不足，将为项目后续工作带来重大隐患。
- 在项目早期，高层领导就应当及时提供必要的支持，并将这种支持贯彻到整个项目过程中。
- 务必避免相关领导没请到的情况出现，领导的参与就是告诉所有人这个项目很重要。
- 启动会议为明确项目经理角色、授权项目经理动用组织资源提供恰当的时机。
- 务必请这些重要的人参加启动会，否则在项目实施时，他们对项目的认识还远远不够，积极性可能会大打折扣。
- 会上还需要说清楚项目的职责结构，如果没有明确责任分工，就容易出现相互推诿的情况。
- 实践中，为了完美地启动项目，建议用结构化方法实施项目启动会。
42: 第3章 规划：运筹帷幄，决胜千里
- 毫无规划的唯一好处是，失败于你而言纯粹是个意外，而此前你全然不会为此感到惴惴不安。
- 计划不如变化快，还做计划干什么？这是技术大佬们经常提到的问题。
- 技术人员普遍不太喜欢做计划，而技术专家成为管理者时常会成为项目管理中的一派——哥伦布派。
- 该派的典型特征是“出发前不知道去哪儿，到了地方不知道是哪儿，回来后也不知道去过哪儿”。
- 总之，走到哪儿就是哪儿。
43
- 计划是花费最少、影响最大的工作
- 阿蒙森团队于1911年12月15日率先到达南极点，永载史册；斯科特团队晚到一个月，全军覆没
- 没有几个人会记住第二名，大家只知道第一名
- 阿蒙森团队准备3吨物资，预留富余量；斯科特团队仅1吨物资，勉强够用
- 计划订得太紧，其实是很危险的
- 阿蒙森团队1912年1月25日返回，与三年前计划日期一天不差
- 阿蒙森经验谈：“最重要的因素是探险的准备如何，你必须要预见可能出现的困难”
- 斯科特团队随心所欲：天气好就猛进，天气不好就停滞抱怨
- “毫无规划的唯一好处是，失败于你而言纯粹是个意外，而此前你全然不会为此感到惴惴不安”
44
- 用较多的时间为一次工作做计划，做这项工作所用的总时间就会减少，这就是布利斯定理。
- 做好一件事情的先决条件是事先做好规划，做计划远比盲目行动有价值。
- 在前期规划上投入时间是非常值得的，而且规划的时间越久、越缜密，真正做事时的效率就越高。
- 认真做好计划与项目的成功密切相关。
- 成功的人善于规划，他们知道自己要达到哪些目标，排好优先顺序，并且制订一个详细的计划，按计划行事。
- 计划会为你提供做事的优先顺序，这样会事半功倍。
- 认真做过计划的人，当问题真发生时就能做到沉着、镇静，而不是急于采取行动。
- 越忙就越容易出差错。如果事先没有考虑好，路子没走对，反而会耽误时间。
45
- 魔鬼藏在细节中，阿蒙森团队的详细策划为成功探险奠定了基础
- 阿蒙森团队用爱斯基摩犬拉雪橇，斯科特团队用矮种马：马虽强壮但不耐寒，最终需人力拉橇；爱斯基摩犬能在极寒中生存，保证了行进韧性
- 阿蒙森为极地探险与因纽特人生活一年多，学习冰天雪地中的生活与求生技能
- 阿蒙森使用新型保温瓶装热饭菜，午餐可随时吃，节约燃料和时间；斯科特团队需扎营生火，每顿午餐多花1小时
- 阿蒙森团队甚至每周给一天假期，星期天再适于行路也放假
- 计划是项目过程的地图，必须足够详细，使项目经理能据此决定下一步行动，保证工作在时间、预算和范围内保质完成
- 有计划、有组织地开展项目工作，即正确分解目标为工作安排，通过适当步骤方法实现目标
- 计划要可视化，可采取网络图、甘特图等形式
46
“如来十掌”为制订计划提供了抓手，通过系统化提问框架解决实际问题
做什么（范围、需求）：工作能否取消？如果必须做，进入下一问题
什么时候做（时间、进度）：能否提前或推后？若不可行则继续追问
花多大的代价做（成本、费用）：从购买→租赁→低成本方案逐级考量
做到什么程度（质量）：明确可接受的质量标准
需要什么资源（团队、采购或外包）：考虑外部资源解决内部限制
签字意味着牵制：签字代表承诺而非保证，是责任认定的重要依据
计划审查会议签署比邮件签署更有效：鼓励现场指出漏洞，避免事后补救
只要求负责任的人签署：消除组织惰性，避免无效多人签字
对有效计划的7条建议：
- 对计划进行计划：避免制订过程混乱无序
- 计划执行者参与制订：提高主人翁意识和团队建设
- 随时准备重新做计划：预料不可控障碍，控制变更
- 进行风险分析并制订备用计划：预测障碍，准备预案
- 定义问题比解决问题更重要：从目的定义入手，避免解决错误问题
- 重点关注工作分解结构（WBS）
- 分阶段编制计划（滚动式计划）
关于项目计划的四句核心观点：
- 计划是用来改的：正因变化快才更需要计划
- 领导应该管计划而非直接管人管事
- 项目应该被计划管着而非被领导管着
- 员工应该按计划做事而非按领导指示做事
47
- 好的篱笆产生好的邻居。 ——罗伯特·弗罗斯特
- 只要不要求立即完成，任何人都可以做任意量的工作，而不会关心做的工作有没有用，跟项目成果有没有关系。
- 任何复杂工作，从认识、管理和控制的角度而言，总是应该从技术和专业角度将其分解成较小的、更易于管理的组成部分。
- 这就是复杂事物的实现逻辑。
48
- 隐性工作显性化，显性工作结构化，结构工作标准化：这是提高组织效率的必由之路，确保工作可重复和可管理。
- 靠人完成工作往往有较大风险，因为人是容易出问题的：组织需要将工作显性化、结构化和标准化，以降低依赖个人的风险。
- 对细节的把握程度反映了一个企业的项目管理水平：魔鬼藏在细节中，必须展示项目细节中的含糊和不确定成分。
- 创建工作分解结构（WBS）就是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程：WBS有助于隐性工作显性化、建立整体认知、界定范围、安排进度和制定预算。
- WBS及其词典是组织的重要无形资产：新成员可以迅速上手，提高项目速度、可靠性和降低风险。
- 要提高项目的执行效率，必须提高项目的构件化（标准化）程度：创建WBS的过程就是对项目进行显性化、结构化、标准化的过程。
- 4种常见的WBS类型：按组成分解、按功能用途分解、按生命周期分解、按地域/组织分解；没有最佳方法，合适的就是最好的。
- WBS可以用树形的层次结构图或者阶梯缩进的表格来展示：树形结构适合高层沟通，表格形式适合团队协作和添加细节。
- WBS是以可交付成果（deliverables）为导向的分解，而不是以活动（activity）为导向的分解：最底层为工作包，包括必需的计划活动。
- WBS是由逻辑推演而成的，结构非常严谨：逻辑结构错误可能导致项目实施错误甚至失败。
49
- 项目的WBS具有重要的作用，因此必须使用科学的方法、遵守必要的原则进行分解
创建WBS的两种主要方法：自上而下法和自下而上法
- 最重要的是让熟悉创建WBS的人完成这个工作
- 自上而下法：从WBS顶部开始分解可交付成果，从大局持续分解工作
- 自下而上法：从底层工作包开始，向WBS顶层汇总项目工作
分解项目工作的两个视角：”怎么完成”（时间维度）和”交付什么”（空间维度）
- WBS的最底层组件一定是”交付什么”，即都是具体的交付成果
- 确定分解正确与否的标准：交付了较低层级的所有WBS组件恰好能够交付较高层级的相应可交付成果
工作包命名原则：应该是名词、形容词+名词或名词+动词，不应该是一个单纯的动词
判断WBS好坏的标准：
- MECE法则：相互独立，完全穷尽（既不重复，也无遗漏）
- 信息透明原则：最底层工作包应该分解到可以估算工作量、时间、成本和验收标准的层次
- 80小时原则：单个工作包的完成时间不应超过80个小时（约10个工作日）
- 独立责任原则：单个工作包应该只分配给一个责任人
- 滚动式规划原则：近细远粗，近多远少
- 不同层次原则：不同可交付成果可以分解到不同的层次
- 一个上级原则：每个下一级组件有且只有一个上级组件
应该由项目经理来决定WBS的结构和细节水平，因为项目经理要对项目是否成功负责
50
- WBS是有效项目管理的基础，许多项目失败源于对项目范围和工作缺乏清晰理解
- WBS是揭开项目细节的神器，解决”做正确的事”的问题，是现代项目管理的重要基石
- WBS能清晰表示工作间联系，结构化界定项目工作，帮助新成员建立整体认识
- 从WBS最低层可估计工时、成本和资源需求，编制过程也是团队建设过程
- WBS为评价变更提供基准，向高层展示项目进展状况的工具
- 看见即降伏：通过可视化工具（如任务墙）对项目过程进行管控
- 任务墙使用不同色块标明工作包状态：白色（未开始）、黑色（已完成）、绿色（进展顺利）、黄色（有问题需关注）、红色（严重问题需立即解决）
- 可视化工具抓住人性核心——人总是把自己最好的一面展示给别人
51
- 在瞬息万变的时代，商业机会稍纵即逝，如何在限定时间内完成预期的项目成果，是每个项目面临的挑战
- 项目的进度通常并不乐观
- 开发者对自己工作的估算通常比现实要乐观
- 大多数项目实际完成时间超过估算进度的25%～100%
- 少数的进度估算精确度达到了90%，误差能控制在5%之内的项目十分罕见
- 为管理这尴尬的项目进度，制订一个良好的进度计划非常重要
- 进度计划是对项目进行有效管理和控制的基础
52
其结果是，下属的奉献和上司的恩赐导致了一个“精确”项目时间的诞生，然而这种时间限制往往被视而不见，项目完工时间取决于团队努力和外部因素
这是一种典型的工期谈判场景，双方陷入挤水分的游戏：上司认为“你多报我才砍”，下属认为“你砍我才多报”，最终以受害者自居
深层次原因可能是社会中存在的“信任缺失”，在这种社会现状下，每个人都难逃困境
问题的另一面也值得思考：项目的工作量并不会因为谈判而减少，但“挤水分”游戏本身却需要时间
可见，实事求是、说真话是多么重要！
基于经验的类比估算本质是经验估算，但存在三个问题：项目相似度存疑、历史数据可信度低、可能注入水分
类比估算技术是一种粗略的估算，建议仅在项目早期阶段使用，并与其他方法联合使用
基于分解的参数估算本质是基于分解的方法，通过WBS分解和各工作包估算得出总进度
参数估算的准确性取决于参数模型的成熟度、基础数据的准确性和人的可靠性
三点估算考虑了最可能、最乐观和最悲观的情况，是基于风险的判断，沟通中更有效
从实践角度建议：在项目早期使用类比估算启动项目，进入规划和实施阶段后应用参数估算
53
- “因为最后期限不是认真分析出来的，而是拍脑袋拍出来的。” — 项目延期的常见原因
- 关键路径法（CPM）在不考虑资源限制的情况下，通过顺推和逆推分析计算活动的最早/最晚开始与完成时间
- “在任何网络路径中，进度安排的弹性大小由最晚完成时间与最早完成时间之间的差值决定，该差值称为’浮动时间’。”
- “正常情况下，关键路径的浮动时间为零，关键路径上的活动称为’关键活动’。”
- “关键路径的时长意味着项目的最短耗时，如果想让项目的时间更短，只能压缩项目的关键路径。”
- CPM中描述项目活动的七个属性：活动代号、持续时间、最早开始时间、最早完成时间、最迟完成时间、最迟开始时间、浮动时间
- 项目进度计划的三种表达形式：
- 项目进度网络图（适合详细分析但较复杂）
- 甘特图（易读，适合向管理层汇报）
- 里程碑图（仅标示主要可交付成果和关键外部接口的计划日期）
- “速度即王道，如何在限定时间内完成预期的项目成果，是每个项目面临的挑战。”
- 进度压缩的三种常见方法：
- 并行（快速跟进）：存在返工和成本增加的风险
- 增加资源：受资源可用性限制
- 加班：常见但需优先安排关键路径上费用增加最少的人员
- “如果一个公司管理水平比较差，项目进度一旦吃紧，所有人都得加班；如果管理水平比较高，只需少数人加班即可。”
54
- 顺推可以清楚项目的最短周期，逆推（按照活动的最迟开始时间安排工作）可以找到节省成本的方案。
- 关键路径法中，通过调整活动的最迟开始时间，可以在不影响总工期的前提下优化资源使用，降低成本。
- 安排施工大地牢的工作延迟到第4周开始，施工建造师从第4周进场，工作持续到第19周，既不影响周期，又降低了成本支出。
- 如果担心按最迟开始时间安排工作存在工期风险，可以预留适当的裕量。
- 人工成本之外，设备、设施的使用费用往往是项目成本的大头，每一天的增加都可能显著影响总成本。
- 改进方案应避免“磨洋工”或盲目加班，而是通过合理调度资源实现成本与工期的平衡。
55
- 项目管理需要解决的问题包括范围、进度、成本、质量、人力资源、沟通、采购、风险、整合等9个知识领域，以及启动、计划、执行、控制、收尾等5个过程组。
- 不要指望别人和你思考的角度一样。这就是基于职能和职权的、组织中常见的所谓“屁股决定脑袋”。
- 现实中常见的情况是，国内的项目参与者都不直接参与项目成本的管理，甚至项目经理们也常常不是项目成本管理的主体。不让具体做事的经理管理成本，成本控制效果可想而知。
- 项目管理不仅仅是“快一点儿完成”，而是涉及多个维度的平衡。
- 项目成本管理常被忽视，但却是项目成功的关键要素之一。
- 组织中的职能和职权差异导致对项目管理的理解存在偏差，进而影响决策。
56
- 预算的真正含义是“完成对应费用的工作量”，即“计划应完成工作量的价值”
- 将预算与实际完成工作量比较，表明项目的进度状况
- 将实际成本与实际完成工作量比较，表明项目的成本花费状况
- 项目成本管理的核心在于花多少钱对应完成多少工作量
- 将实际花费与预算比较，只能得出花钱速度的快慢，对项目并无实际价值
- 很多财务人员关注“进了多少钱、出了多少钱”，而与工作进展无关
- 很多财务指标背后都存在严重的表外风险
57
- 项目的成本预算是一项非常重要的工作，是项目成本管理的重要决策过程
- 成本预算是通过把成本目标层层分解，调动项目团队的积极性，进行有效成本控制
- 大中型项目一般采用分级编制的方法，即先由各部门提出部门成本计划，再由项目管理团队汇总编制项目预算
- 小型项目可以由项目经理组织团队成员集中编制
- 项目成本预算包括两个关键步骤：分摊总预算成本和制定累计预算
- 分摊总预算成本就是将项目总预算分摊到项目各项工作中，并为每一个工作建立成本预算
- 项目组采用了自上而下与自下而上相结合的方法进行成本分摊
- 按照各阶段工作范围结合项目总成本的分摊比例将资金分配到各阶段
- 经批准后成为绩效测量基准（performance measurement baseline，PMB）
- 制定累计预算成本：为每一阶段建立预算基准，把预算成本分配到各阶段具体工作中
- 根据组成该阶段的各活动进度按月列支
- 不仅要控制项目的总预算，更要控制阶段预算、每个月的预算
- 时间–成本累计图给出了控制的可视化工具
58
- 项目中可能出错的事通常要比可能变好的事更多，这就是无情的事实。
- 真正有“经验”的项目管理者，一定不会让这种所谓的“严重问题”发生！
- 凡是可能出错的地方，就一定会出错！
- 风险是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标造成积极或消极的影响。
- 项目风险就是可能影响项目成功完成的任何潜在事件。
- 风险的发生既可能产生有利影响，也可能产生不利影响。前者称为机会，后者称为风险。
59
- 优秀的管理者不是善于冒险，而是善于控制风险
- 每个项目都是独特的，在某种程度上都具有创新性，因而它们充满不确定因素，都包含风险
- 在做项目计划时，人们倾向于乐观，而实际过程却是曲折的
- 若在项目推进的过程中出现了意外的差错，项目就会失去平衡，甚至出现危机
- 相对发生前计划好的问题，处理一个毫无预兆的问题，要困难得多
- 工程师们倾注全力于某个设计，而这个设计是完全不能发挥作用的。他们从来没有考虑过该设计不能发挥作用的可能性
- 完美主义者是不敢承认自己会犯错的。既然他们“把鸡蛋都放在了同一个篮子里”，遇到问题时便会陷入恐慌
- 文学家可以追求浪漫，但管理者强调的是可控而不是惊喜
- 对企业来说，追求惊喜的结果常常是惊讶甚至是惊吓
- 采用忽视风险的“能行”式管理方法，就是项目误管理
60
- 风险管理是一个被忽视的领域，国内更甚
- 风险管理者常被贴上负面标签，被视为“牢骚者”或“有问题的人”
- 不重视风险是最大的风险
- 风险管理的悖论：如果风险管理很好，风险就不会发生，可是风险不发生怎么证明是因为风险管理得好呢？
- 对风险管理的价值缺乏清晰认知会导致“以成败论英雄”式的极端管理方式
- 企业领导人应像重视健康管理一样重视风险管理，在风险出现前就投入时间和资源
61
- 过去已经发生的事件叫作问题，还没有发生的事件分为确定级事件和风险
- 确定级事件（如明天太阳升起）不需要特别管理，只需顺应进展
- 风险有两个基本属性：发生的概率和发生后产生的影响
- 风险三要素：风险事件本身、发生的概率、产生的影响
- 风险分为已知风险（事件已识别，需分析概率和影响）和未知风险（事件本身未知）
- 人类只能对已知风险进行事先管理；未知风险只能事后补救
- 风险分析需要的数据：
- 风险事件发生的概率
- 风险发生后可能产生的后果范围与影响
- 每个结果的可能性
- 组织需提前制订风险评级规则，纳入组织过程资产
- 使用风险影响评级表和概率影响矩阵评估风险重要性和优先级
- 概率影响矩阵根据概率和影响组合将风险划分为低、中、高风险
- 可针对每个目标（成本、时间、范围）评定风险等级，或制订总体风险等级方案
- 高风险（矩阵右上角）需优先采取积极应对策略
- 中等风险可列入观察清单或增加应急储备，不需积极管理
- 低风险可等发生时再处理
62: 第4章 执行：依计而行，行必结果
- 今天的组织需要的是由一群平凡的人，做出不平凡的事。
- 怎样才能保证项目成功？计划，计划，再计划。
- 只有一份周密、漂亮的计划是不够的，还需要切实执行计划。
- 人们都知道减肥的根本手段是“管住嘴、迈开腿”，可是很多人并不这么做。
- 再完美的计划，也仅仅是计划。有计划、有组织地去执行才是根本。
- 经过4年的努力，健康回来了，另一个意外的收获是体重减去近20斤。
63
- 无关人品，系统使然：职位变化导致行为改变，并非个人品质问题
- 老猫升职后态度突变：从称兄道弟到严肃疏远，尤其对昔日好友更甚
- 突如其来的变化令所有人惊愕：系统角色对人的行为产生决定性影响
64
- 系统的意志决定了粒子做事情的阻力系数，按系统的意志做事是阻力最小的方式
- 在稳定系统中，每个粒子都被赋予有利于系统更长久、更稳定存在的属性
- 元素会继承系统的意志，社会系统中系统意志决定人的潜意识和价值观
- 进行相关方分析时，应从结构位置和自身属性（如学历、组织位置、年龄、责权利）分析公共特征，再结合个性化分析
- 项目管理者易为满足底线烦恼，团队成员常认为需求方未认真研究需求，管理者倾向于怀疑项目组努力程度
- 符合系统意志的元素获益最大，系统对个体行为有利则给予正反馈
- 人类社会系统意志是：让满足整体需求的个体获益最大，对有害个体获益最小
- 系统奖励有利个体通过扩大影响、延长存活、增加收益，附加奖励是他人更愿意交往
- 系统惩罚不利个体使其压抑消极，附加惩罚是他人更倾向于远离
65
结构决定行为：津巴多的斯坦福监狱实验表明，角色变了，人也跟着改变，人们会积极调整自己以适应所处地位或角色。
现实与错觉的混淆：津巴多指出，实验中 “现实和错觉之间产生了混淆，角色扮演与自我认同也产生了错位”，大多数人无法区分角色与真实自我。
角色带来的压力：当人置身于某个角色时，原本“应该这样”的事情变成了“不这样不行”，为了获得他人认可，人可能改变原则和价值观，甚至变成另一种人。
组织结构的系统性影响：在“谁偷了我们的效率”项目中，组织的结构对成员产生一致影响，导致相似的行为和抱怨，与个人品质无关，而是系统结构性矛盾的结果。
角色抱怨的一致性：
- 上级主管（A）抱怨执行力差、沟通不及时；
- 团队领导（B）感到 “压力山大”，受上下夹击；
- 团队成员（C-F）抱怨目标不清、意见不受尊重、压抑感强。
系统使然，无关人品：这种状态的出现完全是因为系统的结构性矛盾，而非个人能力或性格问题。
66
- “蝴蝶效应”是人们经常谈论的一个科学典故，但遗憾的是，当人们谈论蝴蝶效应的时候，基本上都说错了。
- 洛伦茨发现，非线性系统对初始值非常敏感——初始值差一点儿，结果就相差很大，这是“混沌”概念的起源。
- 现实中，人们经常用蝴蝶效应形容小事导致了大事，但这个认识是错误的！
- 真正的问题不是最小的柱子，而是柱子的排列方式——这是一个极其危险的系统。
- 应该怪罪的是设计系统结构的人，而不是系统中的元素。
- 我们需要的不是什么意识，而是安全的系统结构。
- “天天讲”也不是好的教育方法，重复的信息会被人脑自动忽略。
- “××无小事”也是一个问题——无小事也就等于无大事。
- 做事要分清轻重缓急，敢于忽略小事才能做好大事。
- 把系统结构搞好了，我们就可以安心专注于正常的工作。
- 凡夫畏果，菩萨畏因，佛畏系统。
67
- 在决定员工绩效的因素中，有94%以上是他们自己所不能决定的。
- 三种常见的项目组织结构：职能型、矩阵型和项目型
68
- 职能型组织是一种层级结构，每名雇员都只有一位明确的上级
- 人员按专业分组，各部门相互独立地开展项目工作
- 职能部门经理临时调动人员或资源完成任务，完成后人员回归原有职能工作
- 优点：相同专业员工集中有利于技术进步，单一上司简化汇报关系
- 缺点：无明确项目经理，各部门只对分配任务负责而非项目最终成果
- 难以获得资源对项目最终成果的承诺
- 适合项目界面和技术相对独立的简单项目
- 跨部门复杂项目易出现冲突，处理复杂
- 冲突上报时信息被过滤和片面化，导致高层信息不对称
- 高层在信息不对称下决策，决策不完美且脱离实际
- 基层执行决策时产生不满，认为领导不了解情况
- 跨部门协调需多次信息传递，效率低下
- 常见现象：掩盖事实、下属质疑领导、会议繁多
- 糟糕决策被执行后问责基层，形成”背锅”文化
- 员工为避免责任，将问题逐级上报
- 恶性循环：高层替中层思考，中层替基层思考，基层替高层思考
- 结果：管理错位，基层员工过度关注战略而非执行
69
- 矩阵型组织是一种既有人对项目负责，又能有效利用组织资源的项目组织方式
- 优点：
- 把职能分工与组织合作结合起来，从专项任务的全局出发，促进组织职能和专业协作
- 把常设机构和非常设机构结合起来，既保持了稳定性，又具有适应性和灵活性
- 有利于专业知识与组织职权相结合
- 项目团队成员可以在同一时间段承担多个项目，使组织资源能够得到充分利用
- 缺点：
- 各项目团队与各职能部门关系多头，协调困难
- 项目经理的权力与责任不相称，缺乏有力支持时工作难以开展
- 项目团队成员缺乏归属感和安全感
- 项目需要的是“贤人”，但部门提供的常是“闲人”
- 部门和项目常常为了抢夺资源而起冲突
- 矩阵型组织的三种类型：
- 弱矩阵：项目经理的权力小于职能经理，角色更像是协调员
- 平衡矩阵：项目经理与职能经理权力相当，但未授权全权管理项目
- 强矩阵：项目经理的权力大于职能经理，具有项目型组织的许多特征
70
- 项目型组织是以项目组作为独立运行的单位，拥有专用的项目资源，团队成员通常集中办公
- 大部分资源都用于项目工作，项目经理拥有很大的自主性和职权
- 部门要么直接向项目经理报告，要么为各个项目提供支持服务
- 优点：有明确的项目经理对项目结果的实现承担责任，可以充分利用项目组的专用资源
- 缺点：对企业的资源利用程度不够，项目资源被各项目组独占
- 当项目不需要资源时很难从项目组释放，遇到技术难题时调用组织力量不便
- 适用于进度或产品性能极为重要、技术和质量要求较高而开发成本相对不重要的项目
- 适合企业资源相对充裕的情况
71
- 企业的组织结构演化历程：从牛人出现→职能化→规范化→项目化
- 牛人阶段： 企业初创时依赖全能型创始人，执行力强但难以复制
- 职能化阶段： 规模扩大后设置分管副总，按专业领域分工，形成职能型组织雏形
- 规范化阶段： 从靠人管理转变为靠流程、制度管理，目标分解为部门目标
- 项目化阶段： 为打破部门墙而引入，需根据发展阶段、项目特点等因素动态选择结构
- 关键矛盾： 职能型组织容易产生本位主义和部门墙，阻碍跨部门创新
- 核心观点： 组织结构选择需与组织发展阶段相适应，没有统一最优解
- 重要结论： 成功企业的组织结构演化没有捷径，需经历完整的发展阶段
72
- 没有完美的个人，只有完美的团队。人无完人，但团队却可以是完美的团队！
- 项目团队由来自不同组织/部门的成员组成，还时常涉及外部的合作方（如咨询商或供应商）
- 没有人能保证所需的人力资源应有尽有，你必须充分利用团队的力量，达到事半功倍的效果
- 不管项目团队由多少人员组成，也不管他们是谁，都需要以高效的团队模式运营
- 高效的团队模式能够既满足工期要求又能提供令客户满意的项目交付成果
73
- 选择合适的团队成员对建设高效的项目团队而言至关重要，找到合适的人就等于成功了一半。
- 组织中的人可分为四类：基于价值观认同与能力匹配程度
- 对待第①类和第③类人：重用或辞退
- 第②类人（如“空降兵”）：有能力但未必与组织同心，重用可能“引来女婿，气走儿子”
- 第④类人（如老职工）：忠诚负责但能力渐趋老化，简单辞退会“寒了众人之心”
- 对这两类人的使用，也是一门“艺术”！
- 对于项目来说，应该只选择第①类人，即对项目有责任感又有完成项目所需能力的人。
- 现实中往往选择机会不多，不得不面对和接受组织的事业环境因素
74
项目团队的组织方式可以归为外科手术式、交响乐队式、爵士乐队式和足球队式四种
外科手术式项目团队：
- 典型场景是所有人都围绕着主刀医生，主刀医生就是整个团队的核心
- 优点：关键任务由团队核心负责人亲自动手完成，成功率较高
- 缺点：团队核心负责人事必躬亲、较为劳累，也不利于人才培养
- 适用于：关键工作必须由资深专业人员亲自操作的项目；一个资深的项目经理带领着一批新手的项目团队
- 大多数固守外科手术式团队运作的项目经理，其潜意识里都认为项目团队成员能力不足、积极性不够、责任心不强
交响乐队式项目团队：
- 项目经理假定项目团队成员都是勤奋的、能干的、积极的，团队成员会负责任地将事情做好
- 项目经理大胆使用团队成员，给他们压担子、强化工作授权
- 项目经理要做的事情主要是指导和鼓励团队成员
- 对组织及团队成员的要求：
- 组织有明确的工作任务分工体系，团队成员对整个组织及其他成员了如指掌
- 团队领导有大胆用人的气度，敢于授权；团队成员训练有素、自我指导、勇于承担责任
- 在交响乐队式项目团队中，项目经理是”脱产的”“不干活的”，非常潇洒
爵士乐队式项目团队：
- 没有”脱产”的指挥，所有人都做事，但有一个灵魂人物——项目协调人
- 要求：
- 团队各成员都是专业的，能够熟练演奏自己的乐器
- 团队各成员熟悉项目情况，具备总体和系统意识，能够保持协调
足球队式项目团队：
- 成员有相对明确的分工，但不规定在何时、由谁、在何位置、做什么，一切要随时进行调整
- 优秀团队需要具备：
- 团队成员之间有基本分工，但要求大家积极和灵活跑动去完成工作
- 团队成员有十分明确且共同的目标，具有互相补位的意识，不计较个人得失
- 团队成员能够根据场上形势迅速达成一致共识
- 容易出现的问题：
- 输球后常问责出现在现场的人
- 带球跑容易被抢断，一旦被抢断自己又要承担责任
最适合的就是最好的：
- 采用什么样的项目团队组织形式，要根据项目的特点、规模以及团队成员对项目工作任务的熟悉程度等多个因素进行选择
- 不能简单地判定某种组织形式就一定比另一种好
- 项目团队的组织结构没有一个普遍适用的模式，需要用权变的观点来考虑其结构的选择
- 四种组织形式在一定条件下可以相互转变
75
- 让每个来到你身边的人都带着微笑离开。
团队发展的五个阶段：形成期、震荡期、规范期、成熟期（表现期）和解散期（休整期）
形成期特点：激动、困惑、矜持、观望；缺乏清晰目标、明确职责和顺畅流程
形成期主要工作：明确方向、确定职责、制定规范与标准、进行员工培训
团队负责人需说明工作目标、范围、质量标准及进度计划，建立互信关系
震荡期特点：观念竞争碰撞，人际冲突与分化，对目标/角色不满显现
震荡期首要任务：安抚人心，处理矛盾和冲突，不允许个人权力压制他人贡献
领导者要适时化解权威和权力，鼓励发表争议看法，不能置之不理或权力压制
需建立工作规范，领导者以身作则
规范期特点：规则、流程、价值观建立，成员互谅互助，关注目标与任务
最关键的是形成团队文化和氛围，建立团队精神、凝聚力、合作意识
拿破仑说：“在管理下属的问题上，荣誉比鞭子重要得多。”
激励手段：鼓励提建议、实行参与制、工作授权、表扬奖赏
激励贯穿工作过程，规章制度约束和惩罚作为辅助
成熟期特点：开放、坦诚、及时沟通，具备多种技能，高效解决问题
“领导者要干自己的事，不干别人能干的事”
负责人应掌舵而不是划桨，关注进度、成本、质量等全局事务
更新方法流程，推动经验交流，营造高绩效文化，集体追求团队绩效
休整期三种结果：解散、组建新团队、勒令整顿
需做好思想引导，说明调整必要性，让员工认同决定
团队建设需分析所处阶段，采用恰当领导方式减少内耗，提高绩效
团队可能停滞或退回前一阶段，曾共事过的团队可跳过某些阶段
76
- 如果说有成功秘诀的话，它在于拥有收集其他人观点的能力，以及同时从对方的角度和你自己的角度看事情的能力。
- 一旦出现问题就容易引发争吵，因为针对问题的解释都会有一个共同点——都是其他人的错，导致相互攻击。
- 越是底层的员工越能发现公司内部的问题，越是高层领导越是容易忽略公司内部的问题。
- 如果领导不认为管理上有问题，就没有解决这些问题的原动力，只会把问题归咎于员工，形成恶性循环。
- 矩阵型结构占到了项目组织的绝大多数，故矩阵型组织通常被当作项目组织的同义词。
77
- 矩阵型组织结构试图在稳定性的职能型组织与临时性的项目型组织之间取得平衡，常见矛盾是职能部门工作和项目工作间的矛盾
- 项目经理能对来自职能部门的团队成员产生较强的影响力，是矩阵型组织下项目取得成功的关键点
- 职能经理对团队成员的绩效考核和职位升迁影响更大，因此成员更倾向于服从职能经理
- 项目的团队成员在关键时刻会选择“出卖”项目，但绝对不会“出卖”组织——铁打的组织流水的项目
- 宁要一个平庸的将军带领一支军队，绝不要两个天才率领同一军队——必须为项目团队设置统一的目标和尺度，进行一元化管理
- 矩阵型组织结构中，项目人力资源管理的问题中85%以上来自这种结构，大多数问题与项目经理认为自身权力不足有关
- 项目经理需要提升领导力，有效方法包括：
- 明确目标，并让每个人知悉——人做任何事都需要一个理由
- 设定一个可以短期实现的里程碑，建立项目节奏
- 不要让团队成员闲下来——闲下来的成员会把注意力放在其他方面，影响项目进度
78
- 做任何一件事都没有人能够投入100%的时间。
- 资源约束是项目管控中不可忽视的问题，项目管理者都希望项目组成员是一些“牛人”，这些“牛人”确实能对项目的效率产生重要的作用。
- 在一个企业中，牛人的数量是有限的，他们很难完全服务于某个项目。他们经常被迫在多个项目中充当救火队员或清洁工的角色。
- 如果每个人的工作都可以互相替代那是最理想的，但这并不容易实现。
- 由PMO依据组织战略基于可“明示”的标准进行优先级排序是相对合理的安排。
- 由某个高管确定项目优先级的方式，就是常见的“一把手工程”。
- “一把手工程”强调了高管的重要性和他们的责任，但也会因为缺乏管理程序而造成“无事不需一把手”的情况。
- “会哭的孩子有奶吃”。
- 牛人的时间分散使用，会造成多个项目工期均拖延。
- 管理总是在“可行”与“合理”之间做选择。
- 管理者追求的是“可行”而不是“合理”，管理者说的话应该是以有效与否来区分，而不是以真假来区分。
- 先戴好自己的呼吸面具再帮助他人。
- 这都是组织架构和组织级项目管理的缺陷在项目上的反映。
79
- 复杂的资源问题、组织治理结构与人际因素对项目的影响不可忽视
- 各部门对项目工作的安排理由可分为可明示的和隐晦的（与组织政治或人际因素相关）
- 组织政治与项目管理者的关系是隐晦的，却发挥着重要作用
- 选择什么样的项目管理者极为重要
- 良好的组织因素和建设性的组织政治是项目成功的有力保证
- 项目经理拥有的权限和资源很少，项目成功需要胜任的高管进行有效治理
- 项目经理必须保持一定的政治敏感
- 政治敏感是对各方利益的深刻理解
- 与项目工作效率关系最密切的人往往不是项目组成员，而是来自其他工作领域的人
- 资源掌握在职能部门经理和高层手上，要学会同掌握资源的人打交道
- 项目经理的一个重要工作是做好时间管理，包括对自身时间的管理
- 成功的经理人花48%的时间在社会交往上，只有13%在传统管理活动上
- 搞好项目=搞好人脉+搞好关系+搞好资源+搞好工作
- 平时不烧香，佛会在关键的时候帮你吗？
80: 第5章 监控：审时度势，沉着应变
- 当你要对你所说的话进行测量并将它们以数据的形式表达出来时，说明你清楚了一些事情；但是如果你不能以数据的形式将其表达出来，说明你对它的了解还很少。
- 在开始一个新项目之前，没有人能预见到项目执行过程中的所有情况。
- 尽管确定了明确的项目目标，并制订了尽可能周密的项目计划，仍需要对项目计划的执行情况进行严密的监控。
- 监控的目的是尽可能地保证项目顺利执行，最大限度地减少计划的变更，使项目达到预期的进度、成本、质量等目标。
- 控制是全部管理职能（计划、组织、领导和控制）中的一个重要职能。
81
- 无法评估，就无法管理。
- 用数据而不是用感觉管理项目，这可以让信息透明。
- 信息不畅人就容易往坏处想，这是人性。
- 管理者尽量不要说“你好好干，我不会亏待你”这样的话，因为员工和你想的不一样。
- 尽量不要采用“不要相互打听工资收入”这样的策略，因为人们越好奇越要打听，打听不到往坏处想的情况会多于往好处想的情况。
- 很多人靠感觉做项目，自然问题就很多。
- 过于乐观地低估工作量；预测不到工作会受制于其他人、其他工作；对自己已经完成的工作给出过高的评估结果。
- “90%完成效应”：当有团队成员以为自己完成了90%的任务时，实际上还有很多工作尚未完成。
- 避免“90%完成效应”的方法：
- 给团队成员定义更细致的工作目标和计划。时常提问：“要完成这项任务，需要多久？这周要处理的细分任务都有哪些？”
- 要让团队成员把自己的工作进度用数据展示出来，每一次展示都是对工作的澄清，有助于识别项目中隐含的问题。
- 为管好项目，需要收集的常见数据有：
- 技术绩效测量结果；
- 进度活动的实际开始日期和完成日期；
- 已完成的任务数量；
- 可交付成果状态；
- 进度进展情况；
- 变更请求的数量；
- 缺陷的数量；
- 实际发生的成本；
- 实际持续时间。
82
- 直方图是一种统计报告图，由一系列高度不等的纵向条纹或线段表示数据分布的情况
- 直方图可以解析数据的规则，直观展示项目特性的分布状态，便于判断总体情况
直方图的作用：显示特性波动状态、传递特性状态信息、掌握过程状态以确定改进方向
确定组数和组宽是设计直方图最重要的工作
分组太多会导致条形很低且高度相近，分组太少会导致条形很高且高度相近，都会给分析带来困难
合适的分组数量通常是取数据总量的平方根
直方图的绘制步骤：
- 选择分析对象（时间、成本、质量等）
- 收集数据
- 确定组数和组宽
- 绘制直方图
直方图反映了数据所代表的项目实施过程的分布
通过观察直方图形状可以判断过程稳定性
正常型直方图：左右对称的山峰形状，符合正态分布，表明仅存在随机误差
异常型直方图：
- 偏峰型：顶峰偏向一侧，通常由于单侧控制导致
- 双峰型：出现两个顶峰，通常由于两种不同分布混合造成
- 平峰型：数据大小差距不大，通常由于缓慢变化的因素造成
- 孤岛型：远离主分布中心出现孤立小直方，表明受到异常因素影响
- 锯齿型：通常由于分组不当所致
实例分析：项目实施周期直方图近似呈现正态分布，像钟形曲线
数据可能暗示不同项目性质或合同额导致了项目周期的差异
可能需要进一步分析项目周期和相关参数的关系
83
- 散点图可识别出两个变量之间可能存在的关系
- 理解数据之间的关系对于理解整体数据来说至关重要
创建散点图的步骤：
- 定义理论关系
- 收集样本数据（必须基于充足的数据）
- 在直角坐标系中绘制散点图
- 分析数据，寻找规律
所有数据点的分布越靠近某条斜线，两个变量之间的关系就越密切
所有数据点的分布越分散，两个变量之间的关系就越弱
项目实施周期与合同额之间存在很强的相关性：实施周期随着合同额的增长而延长
项目实施周期与项目启动月份体现不出任何规律性
84
- 帕累托法则（80/20法则）：80%的结果是由20%的原因导致的
- 影响结果的要素有两种类型：
- 多数：只能造成次要的影响
- 少数：造成主要的、重大的影响
- 帕累托图有助于识别最大改进机会或影响最大的关键原因
- 帕累托图应显示三个重要信息：
- 数据由左至右按降序排列的条形
- 各要素按百分比比例累计的曲线
- 占比80%的水平线
- 80%水平线与累计曲线交叉点的左侧要素是需要重点解决的问题
- 帕累托图解读要点：
- 排在最左边的条形代表最大的改进机会
- 识别“关键的少数原因”——导致大多数缺陷或错误的少数原因
- 当问题的成本远比数量更重要时，绘制帕累托图应基于问题的成本，而不是数量
85
- 随机因素引起的共同因偏差是一种波动，在一个稳定过程中是由各种未知因素引起的，其导致的结果是围绕平均值随机分布的一种波动。
- 共同因偏差可以用来测量过程的潜在能力，或者把该过程的特殊因素清除后过程的性能将是什么样。
- 特殊因偏差是由于特定因素（比如环境条件）的改变导致的结果，这些偏差的因素是可以直接加以确定的，也是可以消除的。
- 控制图是随时间的推移用于监督、控制和改进过程的强大工具，能够显示出过程的绩效，因此也被称为“过程的声音”。
- 控制图可以揭示过程中偏差的本质，指出什么情况是正常的，什么情况是不正常的。
- 判断过程是否失控的标准：
- 单点规则：任何一个数据点超出控制界限，表示过程已经失控。
- 7点规则：连续7个点落在均值上方或下方，表示过程已经失控。
- 控制图用于：
- 希望对过程输出的变化范围进行预测时。
- 判断一个过程是否稳定（处于受控状态）。
- 分析过程变异来源是随机的还是非随机的。
- 红珠实验说明系统的绩效和输出是稳定和可预测的，在系统维持不变的情况下，系统的输出水平及其变异是可预测的。
- 奖惩个体的考核评价体系不是问题解决之道，所有的变异均完全来自过程本身，没有任何证据显示哪一位工人比其他工人更高明。
- 改进系统而非问责个体，员工的绩效绝大部分是由系统决定的，只有极少部分由个人努力决定。
86
- 不做该做之事，你总能找到借口。
- 项目质量管理人员只是帮助项目团队解决问题的。
- 项目质量管理人员其实就是项目路上的交通警察，职责是引导、监督、制止违规行为。
- 质量管理的范畴很大，涉及组织和项目的诸多方面，贯穿于项目的全过程。
- 质量管理的5个等级：
- 靠客户逼：代价最大，可能导致担保问题、召回、商誉受损和返工成本。
- 靠检查控：带来评估成本和内部失败成本。
- 靠过程保：纠正过程本身，而不仅是特殊缺陷。
- 靠设计防：将质量融入项目和产品的规划和设计中。
- 靠文化治：创建一种关注并致力实现过程和产品质量的文化。
- 靠客户逼：代价最大，可能导致担保问题、召回、商誉受损和返工成本。
- 大多数组织还未达到第3级，更谈不上“设计防”和“文化治”。
- 质量管理在项目中常处于不被看重、受人责难、工作难开展、成效不明显的尴尬境地。
- 确保质量管理过程的高效（效率、效果）既是重点也是难点。
87
客户可以要求好的质量，组织可以承诺实现好的质量，但项目团队才是真正对质量负责的部门
质量不达标会给项目团队和组织带来直接和长期的灾难性后果
项目一直为含混不清的质量目标和晦涩难懂的质量检测方法所困扰
质量工具和技术已经成为科学而非艺术，但直接应用于项目管理却存在问题
很多企业一方面花钱通过ISO 9000认证，另一方面又不信任它，甚至编造文档和证据
质量管理的价值已得到认可，但质量管理过程的重要性却时常被忽视
名义上的质量管理部门实际上只是质量检验部，甚至被形容为”鸡肋部门”
质量管理人员常成为众矢之的：影响进度得罪项目组，退货得罪采购，追责得罪研发
出不出质量问题是个问题：出问题被指责工作没做好，没问题又被认为没做事
项目质量好时，大家归功于研发和生产部门，与质量管理部门似乎无关
质量认证越来越像形式主义，CMMI、ISO 9000等实施就走样，变成形式化的一套东西
质量管理部门的尴尬是国内许多企业在质量管理方面的缩影
许多企业没有把质量管理放在应有的位置，有的质量管理部还从属于公司某个部门
88
质量管理是企业的生命线，企业理应建立一个组织级的质量管理部，统抓企业的产品质量和过程质量
质量管理部应该直接由企业最高领导负责，职能包括：开展有效的质量控制活动，建立健全质量保证体系，树立优秀的质量文化
质量管理部千万不要成为高高在上的部门，必须把工作中心下移，深入各项业务工作中
向研发、制造、采购等与项目质量直接相关的部门派驻质量管理人员，目标政策归质量管理部统一管理，日常工作由项目经理安排
质量控制不应局限于检验和检查上，大量的质量控制活动是由业务部门实施的
质量保证既是事前的预防和事后的总结提升，又是对项目质量形成全过程中所涉及要素的全面管控
不要被头衔愚弄 - 含混不清的职位名称，时常让人迷惑
QA指质量保证，是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程
流程改进是管理活动，应该由一个QA经理负责流程度量并管理过程改进
QA与测试人员的关键区别在于：QA团队人员能够进行过程改进
名副其实的QA小组或QA经理需要：有权有钱提供培训；有权处理客户投诉；有能力制订过程改进计划；有能力通过多个项目度量过程改进效果
国内的情况是公司常愿意提供拥有这些头衔的职位，而不愿意赋予这些名称应有的权力
矩阵组织下的QA人员只有直接参与项目工作，了解过程运行情况，才更容易发现过程改进的”短板”
QA工作对人的要求非常高，熟悉质量体系仅仅是基本条件，更需要很高的综合素质、业务能力和项目经验
合格项目QA的3种角色：警察、教师和医生
扮演警察角色：以业务流程为依据，及时发现和报告项目中的问题
扮演教师角色：辅助项目团队制订项目计划，对项目成员进行过程和规范的培训
扮演医生角色：收集、统计、分析度量数据，对项目过程进行诊断，帮助分析原因
一种既不合理也不合法的事，因为没有被严格并有效管控竟被当成一种习以为常的事 - 这与项目质量管理中的常见场景如出一辙
89
- 制度是来遵守的，不是用来迁就某个人的
- 出了问题你负得了责吗？ 这不是你的权责，也不需要你来签字负责，即使有再大的争议，也需经过相关人员综合评审而做决定
- 当真正造成巨大损失时，除了老板，怕是任何人都负不起那个责
- 项目事故导致被客户索赔1 000多万元，虽然老板要处罚负责人十几万元，但该大客户的订单量锐减了七成
- 人们一次次对现行的项目管理办法失望，一次次承受着管理失败造成的损失，一次次求助新管理方法，而忘记了我们早已知道的有效方法
- 追求管理时尚不一定能提升管理水平，很多的公司在做CMMI、ISO 9000时的目的其实也就只有一个：应付客户
- 全员参与、过程方法、持续改进在一声又一声如雷般的响亮口号下，也正在一些人身上、心里渐渐麻木
- 我们已不再需要更多的高明理论，只需要用心把已推行的简单方法，认真地坚持落实下去
- 就算99%的人没有长期坚持对质量标准的认可和维持，那么项目质量管理人员也必须坚持到最后
- 管理项目质量就如减肥，决心比技巧更重要
- 质量管理之路，有起点、无终点
- 项目质量管理人，应该是项目路上的交警，用尽一切办法引导大家遵守交通规则才是天职
- 关键就是看能否把原则坚持到底
- 很多公司之所以推行不成功，就是因为做一段时间后失去信心，难以坚持下去
90
- 项目监控是根据项目进展的情况，对比原计划（或既定目标），找出偏差、分析成因、研究纠偏对策，并实施纠偏措施的全过程
- 监控需要定期或不定期发布项目状态报告，内容可简可繁
- 状态报告可能包括：
- 对过去绩效的分析
- 当前的风险和问题状态
- 本期完成的工作
- 下期计划完成的工作
- 本期批准的变更汇总
- 偏差分析的结果
- 预测的项目完成情况（包括时间和成本）
- 其他必须审查和讨论的相关信息
91
- PDCA循环是项目监控的基础，按照Plan（计划）、Do（实施）、Check（检查）、Action（改善）的顺序循环不止
- P（Plan）：调查分析、确认问题，分析影响，找出原因，拟定对策并制订计划
- D（Do）：实施计划，执行具体任务
- C（Check）：根据实施情况，对比原计划或目标，找出偏差
- A（Action）：分析偏差成因、研究纠偏对策，评估改善
以上4个过程不是运行一次就结束，而是周而复始地进行，螺旋式上升
解决问题的“万能公式”口诀：行动之前要计划，计划之前要分析，分析之前要信息
很多人完全是在信息不充分的情况下直接采取了行动，拿着自己唯一的一生试错
选择学校和专业之前，应该收集各种信息，在此基础上做分析，然后根据分析结果做好计划，最后才是行动
很多人工作中没有信息、不分析，也不做计划就直接采取行动，结果一做就错，付出成本代价并浪费不可逆转的时间
很多人选专业、选工作的标准是“哪个专业容易找工作，什么专业钱挣得多”，个人的目标与专长完全淹没在物质利益中
看得见的好处，阻挡了人们去完整地思考工作的价值、人性的尊严以及生命的意义
92
- 很多的加班现象都是项目管理不当造成的，管理者计划性差，强加不切实际的工作计划
- 你可以哄骗一个傻子来接受一个不合理的期限，但你不能逼迫他满足该期限的要求
- 团队成员明知计划不可行却不敢提出，大家不是按可行的方案去做，而是通过做来证明这种方案的不可行
管理者与团队沟通少，关心少，导致团队意见大，想离职
结果要靠过程来保证，没有好的过程就很难有好的结果
里程碑是最有效的过程监控手段，组织应提升到”有好过程，持续产生好的结果”的层次
忽视内部里程碑是压力积累、风险做实的过程
眼睛盯住细节的，是工程师；眼睛盯住结果的，是老板；眼睛盯住过程的，是项目管理者
5分钟站立会议是项目管控的好办法：固定时间地点，站着围在一起，回答三个问题
- 昨天我做了什么？
- 现在我遇到了什么困难？
- 今天我计划做什么？
在项目团队中引入行动跟踪计划，管理活动进度和预期结果
分配任务时切忌留下无人负责的”灰色区域”
根据实际情况每天监控更新记录，使用优先矩阵确定准确截止日期和优先级
93
- 对项目管理而言，沟通的重要性不言而喻，跨专业背景的团队成员更容易出现沟通障碍
- 项目的成败取决于项目利益相关方之间沟通的有效性
- 项目经理是组织专家做事而不是自己亲自做事的人，是项目中沟通的核心，应花75%~90%的时间用于沟通
- 向上沟通要有“胆”：克服惧怕心理，多出选择题、少出问答题，主动及时汇报
- 平级沟通要有“肺”：流程制度是框架，人际关系是润滑剂，平心静气、互惠互利
- 向下沟通要有“心”：团队成员是实现业务的人，成功基于团队，必须懂得倾听
94
- 变更是导致项目失败的主要原因，也是项目管理的最大难点之一（很多人认为没有“之一”）
- 如果你允许变更随意发生，那么它变化的速度将超过你的想象
- 客户会告诉你所问的任何问题，但仅限于此，没有问到的那些问题往往是更关键的因素
- 今天的问题来自昨天的解
95
- 唯一不变的就是变化，而且变化的速度越来越快
- 数字信息速度的增加，使企业在未来10年中的变化，将超过过去50年变化的总和（比尔·盖茨，1999）
- 10年来，柯达、诺基亚、摩托罗拉等明星企业衰落，华为、谷歌等企业崛起，“商场代有人才出，各领风骚能几年”
- 在VUCA时代，变化是根源，新思想、新方法层出不穷，反而使人更焦虑
- 项目实施过程中进行变更并不总是坏事，很多时候还是一件好事
- 客户通常不能确定解决方案的功能和特性，商业环境也会随时间变化
- 额外功能可以让产品胜出竞争对手，但发布时间推迟会导致优势丧失
- 变更不可避免，唯一能做的就是如何面对和管理变更
96
- 项目过程就是”绑架客户上咱们贼船的过程”（乙方视角），或是”逐步移交主动权的过程”（甲方视角）
- 发生变更不是问题，问题是许多变更处于”非管理状态”
- 变更管理需要明确：能做什么/不能做什么、统一的变更评估方法、批准变更所需的时间费用
尤其要评审变更会引起哪些连锁变更，以及变更后是否需要更改管理标准
变更管理”九阴真经”九步法：
- 第一步：评估变更信息准确性，定义问题比解决问题难
- 第二步：提供变更申请的书面记录，即使客户不愿写也要主动起草请客户确认
- 第三步：分析变更对范围、进度、成本、质量等各方面的影响
- 第四步：沟通变更影响，通过详细说明时间/成本/技术/风险等影响让客户知难而退
- 第五步：提出相应解决方案，让管理层做选择题，不要让他们做问答题
- 第六步：查阅审批权限，确保合法授权
- 第七步：召开变更控制会议做出决策
- 第八步：根据审批结果进行沟通
- 第九步：指导执行并跟踪变更状态，确保变更被正确实施
在没有解决方案之前，请不要向高层汇报，否则”他们会问：’我要你干什么！’”
最佳汇报方式：提供上中下三策，让管理层选择
保证变更都被登记、评估、批准、跟踪和正确实施，确保功能要求实现
97
- 变更不可避免，处理不当常会导致冲突。冲突可以暴露项目不足，但处理不好就会产生矛盾
变更矛盾来源：甲乙双方（变更范围、时间成本）、项目组内部（抵触增加工作量）、部门之间（管理层底线与部门调整）
话在出口之前你是它的主人，一旦出口你就成了它的奴隶！ 情绪化争论会演变成更大矛盾
范围蔓延——不受控制的范围改变，对项目有致命性破坏
范围蔓延原因：客户提出细小需求积累、项目组自身技术心态追求成就感
与你的承诺有关的条件可能会被忘记，但你的承诺本身却不会被忘记
人的欲望是无穷的，不管你的项目增加多少功能，用户总是会提出更多的需求
不管产品特性多么耀眼，过一段时间人们就会将其视为正常的功能
避免范围蔓延原则：决不让步，除非交换，任何变更需通过正规变更控制程序
变更机制要”烦琐”——增加变更摩擦系数，降低变更频率
系统变量设计：把可能的变化作为可选项处理，提高项目灵活性
今天的问题来自昨天的解——过去解决问题的措施可能产生新问题
谨慎对待第一次变更，用正式理由拒绝第一次至关重要
规矩先行，营造按规矩行事的文化
框架效应：通过不同描述改变心理参照点影响选择
忠告不如警告，以损失为导向的沟通更加有效
化解变更矛盾：重述问题，强调不变更的收益与变更的风险
98: 第6章 收尾：慎终如始，好戏杀青
- 经验是最坏的老师。它经常先考试，然后再给出指导。
- 每个人都喜欢用“我能做什么”来评价自己，但别人只会用“你做过什么”来评价你！
- 在写总结时一定要注意写明你做过什么，取得过哪些业绩。
- 优秀人才普遍擅长总结，建议用项目管理思维进行结构化的总结，不仅“高大上”，而且显得逻辑清晰，格局大。
- 面试就是讲故事，通过讲述自己的过去来推销自己，放平心态、把故事讲好，面试就成功了一半。
- 当你用独特而丰富的语言给面试官表述自己的优点时，那必定是一个精彩的故事，而你自己，也成了用自己魅力来影响他人的人！
- 开头简单、结局不易，项目亦如此。
- 在快速变化的商业环境下，项目收尾的好坏，不仅影响组织利润，也影响人们对项目的评价，甚至会成为获取新商业机会的关键。
99
- 项目管理是对工作的一种严谨的思维方式，适用于所有的项目，无论其内容、规模或复杂性如何。
- 项目收尾是项目生命周期的最后一个重要过程，一旦满足了项目目标，且顾客能够对交付成果进行验收，就进入了项目收尾过程。
- 尽管项目收尾是项目生命周期的最后部分，但并不意味着项目收尾的各项活动就要拖延到此时才开始进行。
100
项目是临时性的，但项目成果却往往是长期的。项目收尾必须做好，不留后遗症，以免造成长期的不利影响。
项目管理者必须在开始新项目前，请相关人员验收项目、接收项目成果并确认本项目已经圆满完成。
项目文件应存档，为未来类似项目的定义和规划提供必要信息。
作为项目管理者，激励和感谢是加强其自身影响力的最好方法。
通过庆祝所取得的成就，认可并奖励团队成员做出的贡献，以加强成员间的关系。
开展项目后评估，把良好做法标准化，并改进不足，为后续项目改进提升做积累。
外包工作收尾需核实所有可交付成果、文件、报告及其他成果已交付，并确保合同义务全部履行。
评价供应商的整体绩效，如合同提前终止需详细记录情况，特别是因绩效问题终止的合同。
感谢从来不会带来伤害，它只会带来帮助。 即便不再合作，表示感谢也是很好的做法。
项目管理者应安排庆祝活动，即使项目结果不理想，也要找出一些引以为豪的成就。
项目团队成员在项目完成时会有复杂的心情，工作效率可能会下降，需提前做好沟通和后续工作安排。
101
- 客户从总体上可以分为两大类：幼稚（目光短浅）客户和成熟（见多识广）客户
- 成熟客户能够意识到他们在决定项目能否成功中的作用，会详细说明预期成果并提出关键问题
- 优先级高的项目比优先级低的项目不可避免地会有更好的结果，因为在对资源的竞争中占有明显优势
- 目标明确、稳定是项目成功的必要条件，将目标写下来帮助树立牢固印象，只有在必要时才修改
- 一位合格的、有领导力的项目管理者至关重要，特别是面对不同专业背景的团队时
- 工作安排的技巧只有一个，就是”最小化可执行” - 确保指令中的每个细节都是团队成员力所能及的
- 当你发现他无法达到时，就必须学会将这个环节进行细节分解，一直分解到他力所能及
- 当你能熟练运用”最小化可执行”原则时，能够保障指令完整执行，同时不会被笑话”婆婆妈妈”
- 重新计划是项目管理的一项持续的要求，对计划的有效管控可以保证项目在正确方向上前行
102
- 很多个人层面看似没有意义的工作，在组织层面非常有价值，文档工作是在为组织积累过程资产
- 写文档是一种必须掌握的核心技能，也是体现个人价值的重要方式和机会
- 项目收尾报告应包含五个核心部分：
- 原项目基本方面（范围、进度、成本、质量）
- 与原计划的偏差说明
- 项目生命周期中的客户关系分析
- 风险管理总结（主要威胁和机会的应对及结果）
- 经验教训（包含经过、措施和受益者）
- 应该以客观、透明的方式跟踪项目的历史记录，营造轻松、合作的氛围以消除负面影响
103
- 衡量项目是否成功的一个重要方面就是客户对于项目成果的验收情况
- 通过获得客户认可的签收可以说明，完成的项目符合客户要求
- 在项目全过程中始终进行有效管控很重要，而成功地结束项目也许更重要
104
- 理解客户“真实的”问题是顺利验收的关键
- 项目一开始就确认清晰的、简单的标准，并保持到项目收尾
- 项目管理的一个重要责任在于管理好期望值
- 必须确保拥有一套确实有效的要求，即客户的真实需要
- 明确不同要求之间的边界条件，才能设计出满足客户要求的方案
- 急于“先干起来”的项目会随时改变要求，导致最终产品不符合需求
- 错误在于客户指定产品设计，却没用“可理解的业务”描述要求
- 遇到问题不要仅仅解决问题本身，还要去解决问题所在环境
- 有效要求是以“可理解的业务”表达客户需求的要求
- 验收时要确保交付成果满足客户对产品的要求
- 当客户只进行产品设计时，必须修改为“可理解的业务”要求
105
- 可交付成果移交后，项目控制力大大减小。对于已经交付的产品在离开生产场所之后的责任归属，也是一个在项目开始时就应考虑的问题。
- 继续服务和支持可以收费，也可以是一种义务。必须明确由谁来支付费用，何时付费。不建议将这个问题留在项目完成后才来商讨。
- 应该将继续服务和支持视为一种机会，而不仅仅是一种义务。员工与客户一起工作会通过非正式的机会发掘想法，倾听客户所面临的真正问题，为未来的商业机会奠定基础。
- 如果项目在一个或几个方面不符合要求，应该进行书面记录，并通过以下方式处理：
- （1）扩展项目，以完成必需的额外工作。
- （2）重新协商项目范围，使之符合已交付的成果。
- （3）获得有条件的接受，并承诺在未来某个日期解决问题。
- 即使还有尚未解决的缺陷，也要获得对已经完成的成果的书面确认。验收测试的结果应在下一期项目状态报告中概述并归档。
106
- 我们从历史中吸取的唯一教训是人们从未吸取教训。 ——黑格尔
- 项目普遍拖期严重，团队自嘲：“没有我们完不成的项目，但也没有我们能按时完成的项目。”
- 各部门互相推诿责任：项目经理指责工程师调试迟，工程师抱怨采购迟，采购经理称设计周期长，工程师反问市场部门合同周期短，市场经理则称竞争对手周期更短。
- 那些所谓的‘新技术’有大部分在另外的项目组使用过，只是没有在组织内分享！以致同一个错误，在组织内的不同项目上复现。
- 总结经验教训的目的是了解哪些工作做得好，哪些工作需要改进；在自己和他人的错误中学习、不重复犯错是成功的捷径。
- 然而，这个过程经常被忽视。
107
- 问题出现一次，是可以理解的；同样的问题出现两次，是很不幸的；同样的问题出现三次，就是不可理喻的。
- 机会错过一次，是可以理解的；机会错过两次，是很不幸的；机会错过三次，就是不可理喻的。
- 人类的错误可以分为两大类：无知之错和无能之错。
- 无知之错也被称为“必然的谬误”，也就是人们所做的事情完全超出了自己的能力范围，从而导致的错误。
- 无能之错是指人们并非因为没有掌握相关知识，而是没有正确使用这些知识而导致的错误。
- “无知之错”可以原谅，“无能之错”不可原谅。
- 如果解决某类问题的最佳方法还没有找到，那么只要尽力了，无论结果如何，我们都能接受。
- 如果明明知道该怎么做，却没有做到，那么这类错误很难让人接受。
- 原来倾向于“无知之错”的天平现在越来越倾向于“无能之错”了。
108
文档的悲剧：领导可能忘记你的贡献，但会记得你写的文档。痛苦在于明知内容无意义却要写，还要追求格式完美，甚至写不出来。
经验主义的矛盾：我们做得多但总结得少，同一个错误反复发生。不知道历史的人注定会犯相同的错误，这简直是一个悲剧。
忽视总结的原因：
- 人们忙于眼前工作，视总结为次要，因为它是“以后”的事。
- 缺乏经费支持，客户不愿支付总结费用，组织也不愿承担。
- “贤人”不屑于写文档，常由水平有限的“闲人”代笔，导致质量低下。
总结质量低劣：
- 依赖口口相传，不形成文字记录，像中餐馆依赖大厨而非系统。
- 总结不实在，需要“悟”，如菜谱中的“盐少许”，缺乏可操作性。
- 文档务必简洁、可视化，以图表简化复杂内容，让人迅速了解真相。
机制缺失导致留一手：
- 员工担心知识分享后自己吃亏，如“教会徒弟，饿死师父”。
- 引入内部专利机制：文档被查阅或使用后，撰写人获得报酬，激励高质量总结。
自我服务偏见：
- 人们归功于自己，归咎于外界，导致成功经验说得多，失败教训说得少。
- 学习如何避免重复别人的失败，而非模仿成功，因为失败只需一个条件就能重现。
- 总结时：多说教训、少谈经验，多找自身责任，少归因外部。
109
- 不知道历史的人注定会犯相同的错误
- 项目经验教训总结不足会造成两个严重的后果：重复应对相同问题，以及质疑项目管理的价值
- 缺失项目后评估这个环节导致组织和项目团队经常忘记先前的问题经历
- 建议使用结构化过程保证经验教训总结的质量
- 有关决策和假设、合作方法、风险识别、团队结构、沟通、会议程序、相关方管理、冲突管理等方面的经验更有价值
- 管理经验的适用面远远大于技术经验
- 使用“递增式文档”方法：准备文档提纲，在项目过程中逐步收集内容片段
- “递增式文档”操作起来相对不那么“痛苦”，为最终文档的完成提供了好方法
110
- 最危险的常用语就是“我们一直是这样做的” ——葛丽丝·霍普
- 俄罗斯航天局因编程人员输入错误坐标（拜科努尔而非东方港）导致19颗卫星发射失败，造成重大损失
- 编程人员认为对其进行检查纯属浪费时间，因为以往发射坐标总是位于拜科努尔
- 在许多复杂过程中，某些步骤看起来并不重要，但忽视它们可能带来严重后果
- 我经常听到有人说“以前从来就没出过这类问题”，等真的产生了严重后果就不会这样说了
- 虽然许多组织都开展经验教训总结，但很少有团队真正将之前团队所总结的经验付诸实践
111
让经验教训发挥作用不是一件容易的事
故障原因清楚，证据确凿，开发部门对此负主要责任
该类问题前年在另一个产品上也发生过，怎么没有引起重视呢？
经验教训总结是W公司每个项目团队面临的考核指标，提交不合格文档的人会面临薪水上的处罚
大家并没有认真对待经验教训总结：只是应付考核而已
处理项目问题已经忙得焦头烂额，还要写这种文档！这简直是”吃二遍苦、受二茬罪”！
案例复杂、不容易记忆和使用：问题描述缺乏逻辑性和系统性，多而杂，让人想记也记不住
失败案例总结没有人认真研究和学习：对于别人的案例基本上没有人在意
多数案例的指导意义不大：很多案例都是些鸡毛蒜皮的事，没有什么价值
112
- 建立内部专利制度，采用正向激励让提供经验教训的人获得实际好处
- 追加案例前查重，项目团队必须提交经验教训检查表确保措施落实
- 将经验教训使用作为质量控制（QC）的检查项，按总结表对方案进行检查
- 案例库瘦身：硬件案例减至不足一半，软件案例减至不足1/3
- 简化案例描述，用最简练语言描述案例及应对措施
- 对案例按逻辑分类（安全保证/生产工艺/原理设计/元器件性能等）
- 不重复犯错的基础是拥有机制良好的经验教训系统，其核心是内部专利方法
- 保证经验教训发挥作用的不是聪明才智，而是看似刻板却实实在在的方法
113: 第7章 好的项目管理者为何如此稀缺
- 选错了人，且试图把他们培养成为他们所不擅长的人，这就是一个悲剧！
- 一个项目经理死后被打入地狱，却激活了地狱的小鬼们，天天开站立会、谈WBS、画甘特图、做团队建设、搞满意度调查，甚至要求改组织架构、做变更流程、目标设定。
- 上帝大怒后说：“你犯了三个错误，第一，你应该先说这个月的交付成果！第二，这个世界根本就没有上帝，只有客户才是上帝！第三，我没有时间和你闲谈，我要去更新项目计划。”
- 导致项目团队工作不理想的原因很多，其中一项重要的原因就是团队管理者不称职。不称职的项目管理者是项目的杀手，而且是职业杀手。
- 介绍一种思考并实践多年的工具，虽然解释和理解起来比较容易，但修炼过程可能是漫长且不易的。
114
每个人都是一个智商（IQ）和情商（EQ）的综合体，通过IQ、EQ的高低组合形成智商–情商矩阵（IE矩阵）
第1象限的人（智商高、情商高）很少见，属于异类，适合成为团队的精神领袖
- 具有卓越的领导力和神奇的人格魅力
- 不给你发钱，也不能决定你是否升迁，但是你却愿意给他干活儿
第2象限的人（智商低、情商高）很容易成为领导
- 组织需要协调和整合不同专业的人，这就要求情商必须高
- 追求合作而非共识，为了达成合作他们时常自嘲
第3象限的人（智商低、情商低）最典型的表现是特别快乐
- 一个人懂得越少，就越简单，也更快乐
- 知道得越多，人越复杂，也往往更容易焦虑
第4象限的人（智商高、情商低）大多数是专业人才
- 往往过于关注局部而非整体，只见树木、不见森林
- 喜欢跟人讲理、期望共识，却时常藐视人情世故
- 更适合专业工作，不适合跨专业协调的管理工作
对IE矩阵的总结：
- 第1象限人稀少
- 第2象限出领导
- 第3象限快乐多
- 第4象限被人管
115
人刚出生时，不可能有高智商，也谈不上高情商，起点都在第3象限
一旦到了第4象限，所做的工作就具备了一个属性：在某个领域里做出一点儿跟之前不一样的东西，也就是要实现或多或少的创新
跨专业协作越来越不容易，需要学管理学、沟通学、领导力、心理学、逻辑学、哲学，提升情商
最应该追求合作而非共识，为了达成合作，第2象限的人时常自嘲
在第4象限的人，最喜欢和别人讲理，讲不通了还喜欢跟人拍桌子，这种行为让后面的工作更难干
让所有人达成共识几无可能，所以难得糊涂，只要能合作就行
一旦成为专家，你说的话别人越来越听不懂，别人说的话你也越来越听不进去
你要学会享受孤独，不要指望别人理解你
从第3象限到第4象限，从第4象限到第2象限，再从第2象限到第1象限，这是卓越管理者的三个阶段，也是一个螺旋式上升的过程
在东方文化下，我们更相信管理者应该是干出来的，”技而优则仕”
技术专家们经常从内心里就不服，如果一个没有做过软件的人去管理一群软件工程师，他们一句”You can you up”就足以噎死你
很多时候，只有你干出来我们才相信
国内的管理者们也应该成为T形人才，具备较好的技术背景
从第3、4象限到第1象限，也许只有圣人能走通了，普通人不必追求
116
- 从第③象限到第④象限，再到第②象限是成为卓越管理者的成长路径；从第③象限到第④象限，然后沿着专业一直深入是成为专家的成长路径。
- 成为合格的管理者一般需要10年，管理学、沟通学、领导力、心理学、逻辑学、哲学等，都是对人的修炼，不可能在短时间产生明显的变化。
- 成为专家需要一万小时（一万小时定律），如果每天有五小时花在专业上，大约也需要5年多。
- 很多第4象限的人感觉管理很虚，技术比较实在，一旦远离了技术便没有安全感，所以他们不屑于成为管理者。
- 成为专家需要静下心来花很长时间深入研究自己的专业，这个过程很孤独，而他们又没有能力成为专家，所以他们只能回到了第3象限。
117
- 不在其位却显得能胜任其职，是件容易事；而在其位又确实能胜任其职，则是件难事。
- 选错了人且试图把他们培养成为他们所不擅长的样子，因此浪费了大把时间、精力和各种资源。
- 这种状况对于各方而言，恐怕结局都是一个悲剧！
118
- 技术优秀与具有管理才能相关度不大
- 技术专家型管理者常沉迷于技术细节，把大量时间花在学习新技术或解决技术难题上
- “告诉你怎么干，还不如我自己干更容易” - 技术专家型管理者的典型心态
- 管理者因对结果不满意就亲自动手，很快就把”猴子背到了自己背上”
- 判断管理工作是否有效的标准是团队的绩效而不是自己做了哪些工作
- 团队的业绩就是管理者的业绩，团队的过错也就是管理者的过错
- 管理者应侧重于”做对的事情”，而不是像技术人员那样侧重于”把事情做对”
- 技术专家成为管理者的重要原因是他们具备高水平的技术能力
- 技术专家管理者的优势：熟悉专业技术、能指导下属、易于沟通和树立威信
- 懂得某种专业技术性工作并不一定是他们最大的优点，相反有可能会是他们最大的弱点
- 技术专家型管理者常以技术人员心态处理团队管理问题
- 将技术优秀的专家提拔为管理者，时常会导致：公司少了一位特别能干的技术专家，公司多了一位糟糕的管理者
- 技术专家转型管理者面临的九大问题：
- 角色定位错误，过于关注技术
- 只见树木、不见森林，关注局部而非整体
- 刻舟求剑，静态看待技术外的事
- 不愿低下高贵的头，排斥非正式沟通
- 过于依赖正式权力，缺乏政治敏感性
- 黑白分明、绝对的对错，一元论
- 缺少权衡、妥协、忍让，理想主义/完美主义
- 藐视人情世故，忽视社会学范畴中常理高于一切的现实
- 缺乏领导艺术
- 能走向管理岗位是因为技术很棒，但能稳定拥有管理职位（甚至升迁）绝不是因为技术很棒，而是管理能力很强
- 被从管理岗位上换下来绝不是因为技术水平不够，而是管理能力达不到要求
119
- 项目管理者应了解足够的技术，这样在决策时就能进行权衡，做出更优的决策
- 需要知道如何收集和分析需求、设计和确认设计完成、识别和管控风险、使用配置管理系统、理解质量测试
- 并非要求项目管理者必须清楚完成这些细节、成为技术专家，而是要求他们知道如何组织项目各项工作并促成工作的完成
- 需要具备专业域知识和方法域方法论
- 需要了解所应用技术的特点、难点，解决技术问题的流程及相应风险
- 必须理解要解决的问题，以及如何利用解决方案来解决问题
- 如果不知道要解决什么问题，就无法明确项目工作何时完成、花多大代价，也无法验证完成质量
- 如果不了解系统原理和架构，就不能识别其中蕴藏的风险，也就无法真正把项目管起来
- 不要求亲自编写代码、设计PCB或编制工艺
- 好的技术背景有助于了解项目状况，但优秀的技术专家不一定能成为优秀的项目管理者
- 两种不称职的项目管理者：对项目一无所知的和想成为架构师的
- 架构师虽然了解流程和技术，但常会置项目管理工作于脑后，专注于开发而非管理会导致项目挫折
120
- 非技术背景管理者需要提升技术素养：容易被技术专家忽悠，需要多修炼技术硬功夫，加强技术逻辑能力，运用技术术语和概念进行思考推理
- 管理者应该两手抓，两手都要硬：技术背景管理者补软技能短板，非技术背景管理者补技术短板
- 掌握核心概念和原理而非技术细节：学习行业知识体系的最大好处是便于与技术人员沟通，获得技术判断能力
- 知识体系分为三个层次：
- 核心概念层：用一两句话讲清知识体系
- 原理逻辑层：进行逻辑推理和思考，能够创新
- 工程应用层：涉及数学、工艺和流程步骤
- 非技术出身管理者需要掌握道和术的层次：核心概念层是道，原理逻辑层是术，掌握后可以高屋建瓴地指导工作
- 推荐WWH学习模型：
- What：搞清楚基本概念和基本逻辑，用作者逻辑验证观点
- Why：通过问为什么实现知识归一化，挖掘知识背后的知识
- How：思考技术对人的作用和影响，以人为中心思考应用
- 不要试图展现比工程师更专业：应该展现更有逻辑，用引导和提问的方式让工程师自己发现逻辑问题
- 技术是工程师成就感的源泉：直接指出技术问题会伤害工程师尊严，不利于工作开展
- 清晰的技术逻辑和业务管理逻辑相结合：能稳定军心，解决表面是技术问题实则是业务问题的跨专业难题
121
- 并不是所有人都擅长项目管理工作，能把项目管理做好的人比较少
- 项目管理本质上是一种基于战略方向、组织开拓创新的学问，目的在于组织资源完成突破性的商业目标
- 擅长项目管理的人往往也擅长组织力量进攻
- PMI人才三角提出项目管理者的三大能力维度：技术项目管理、战略与商务管理、领导力
- 优秀项目管理者需要掌握项目全生命周期管理（启动、规划、执行、监控、收尾）
- 需要具备多领域知识：财务、质量、生产、市场、营销、信息技术等
- 需要理解项目环境、适应事业环境因素，具备想象力和决策能力
- 最核心的是需要具备正确的价值观和人生观
- 优秀项目管理者需要兼具专业知识、性格态度和价值观素养
- 做一个优秀的项目管理者极其困难，近乎要求”超人”般的综合素质
122
- 项目管理者的什么技能是最重要的，我会毫不犹豫地回答“人际关系技能”
- 不会与人打交道的项目管理者，会遇到很多麻烦
- 人际关系技能在大多数组织中都被低估了
- 几乎没有见到因为项目管理者不会制作甘特图而失败的项目，倒是常见到很多项目因人际关系问题而陷入严重危机
- 从技术专家到优秀项目管理者，需要6个转变：
- 由专注技术转向关注拥有技术的人
- 由理性转向感性和理性相结合
- 由追求完美转向追求满意
- 由做自己感兴趣的事转向做自己该做的事
- 由着眼于项目工作转向着眼于项目的商业价值
- 由技术权威转向管理能手
123
- 项目是一个体现人们矛盾和冲突的载体，项目管理者必须要通过自己的努力，协调项目中各方利益，化解矛盾、获取共识、达成目标。
- 在沟通中，达成共识的关键是“换位思考”，至少要有一方会主动站到对方的角度去考虑问题，才有机会促成双方的共识。
- 如果大家都仅仅站在自己的角度来思考问题，而不替对方着想，则这个共识势必是很难达成的，其结果就是沟通效果不好。
- 技术专家们没有经历过对方的工作环境历练，难以想到对方的困难，理解不了对方诉求背后的真实原因，因此很难做到站在对方的角度思考问题，这时常造成误会和矛盾。
- 你必须帮助他们化解矛盾、达成共识。因此，你要站在不同人的角度思考问题，理解他们各自的苦衷和期望，先与他们各自达成共识，再尝试帮助他们进行沟通，促成他们之间达成共识。
- 项目涉及的人越多，你就越需要换位思考，沟通的难度也越大。
124
现实中的项目经理们，位置是尴尬的，尤其在中国的人文环境下，“官本位”和“层级权力”根植在人们的骨子里
真正的职能经理才是长期的“官”，而项目经理充其量只是个临时的“官”而已
项目管理者更多的是建立在个人影响力和专家权力以及模范作用的基础上
要管好项目，你最需要的是“说不清道不明”的领导力
领导者必然会有部下或追随者，拥有影响追随者的能力，目的是通过影响团队成员来达成项目的目标
一个人可能既是项目管理者也是领导者，但并不是所有的项目管理者都能领导别人
合格的项目管理者运用的是领导的方式，不合格的项目管理者则是运用管理的方式
你有能力管理的没有任何人，只有自己
只有做到管理自己、影响别人，这才是合格的项目领导者
只有被领导者（项目团队成员）成功，领导者才能成功
125: 第8章 打造面向业务的系统化思维
- 我们鼓励讲究实绩、注重实效，却往往奖励了那些专会做表面文章、投机取巧的人。
- 系统化思维是良好项目管理的基础，需要开阔的思路和视野。
- 项目管理是一套系统的方法，强调系统化的思维方式。
126
- 自工业革命以来，人类解决问题的思维模式主要是“还原论”，也就是机械性思维。
- 还原论思维包括三个步骤：
- 将整体分解成若干元素
- 对这些元素进行研究并理解它们的属性或行为
- 将对这些元素的理解进行组合，从而达到理解整体的目的
127
- 机械性思维对人类社会的进步起到了极大的推动作用，但也严重限制了人类解决问题的能力
- 布鲁克斯定律：“为一个延误的项目增加人员，将导致更多的延误”
- 机械性思维的本质是试图通过修复小的部件来解决大的问题，具有两大特征：
- 关注事物内部、构成元素及其关联关系，认为分解元素可以充分解释整体
- 认为系统整体的最优来源于各个局部的最优
- 机械性思维在技术性问题中有效，但在社会系统中并不总是奏效
- 复杂社会系统中，因与果不是线性的，而是存在相互联系、相互作用与反馈回路，甚至是互为因果
- 案例说明：即使各分系统技术指标达标，系统整体性能仍可能无法实现（如电磁兼容性问题）
- 加班和增加人力可能适得其反，导致更多错误和延误
128
- 长兄善治未病之病，于病情发作之前就能事先铲除病因
- 最好的方式是善于调理、养生，根本不生病
- 神莫大于化道，福莫长于无祸 - 将”道”融化于自己的言行之中是最高明的，没灾没祸是最持久的幸福
- 精通系统之道，顺势而为，游刃有余 - 需要具备系统思考的智慧，洞悉系统内在结构
- 在现实中多数组织总是提拔了解决问题的人。实际上，真正高水平的是让问题不发生的人
- 一个人把部门管得特别好，部门井井有条、高效运转，但不出事反而被认为工作简单
- 部门常出事，人们反而会觉得这个部门的工作真难干，开始重视它的工作
- 组织部门的领导们往往没有能力判断谁好谁坏——以致好心做了坏事
- 圣人能够做出正确判断，但普通人却只能看到表象
- 为了遵从民意也必须提拔表面表现突出的乙乡长，而非真正防患于未然的甲乡长
129
- 系统的关键在于相互作用 - 系统是由相互作用、相互依赖的若干组成部分结合而成的有机整体
- 系统具有四个基本要素：输入、输出、转换过程、控制转换过程的调解机制
- 组织就是一个环环相扣的复杂系统 - 任何一个部门或成员的举措都可能在不同时间对系统中不同主体产生影响
- 美国90年代犯罪率居高不下，专家预测青少年杀人案将上升15%-100%
- 出人意料的是，犯罪率非但没有攀升，反而开始全面持续下降 - 青少年杀人案发率在5年内下降了50%
- 传统解决方案：惩奸除恶、政府干预管控、潜在罪犯教育 - 但实施难度大且成本高
- 堕胎合法化意外降低了犯罪率 - 数百万贫困未婚未成年女性选择堕胎，减少了潜在罪犯数量
- 很多系统问题正如犯罪问题被意外解决一样 - 诺尔玛·麦科维在无意中扭转了历史进程
130
从系统思维角度出发，我把认识世界定义为四个层次：反应层、模式层、系统结构层、共同愿景层
反应层（事件层）：关注每天发生的事情，遇到问题解决问题，关注事件本身，即“见招拆招”，只是对事件做出反应，而没有控制事件的发生
模式层：关注事件的模式、寻找事件发生的规律，例如通过培训提高应对能力
系统结构层：关注导致事件模式（规律性）的根源，找到预防事件的方法，开始面向未来，例如建立专门团队分工负责
共同愿景层：关注创建一种新的模式以替代低效的旧模式，建立新的系统取代旧系统，它是真正面向未来的，例如优化流程、提升经验使用、合理分配资源
131
文凭不代表水平，学历代替不了能力，知识也不一定能转化为生产力 - 网友评论观点
农民工方案：用大电风扇吹走空盒，解决了问题的表象，属于反应层解决方案
- 只能解决单一问题（空盒）
- 无法处理半块香皂或异物盒子
- 导致出现永远解决不完的问题
博士方案：自动分拣系统属于面向未来的系统结构层
- 解决了一类问题（可扩展处理空盒、半块香皂、异物）
- 需要系统功能扩充即可应对更多情况
更高层次方案：改造生产线降低空盒概率，属于共同愿景层
农民工可以解决一个问题，而博士就必须解决一类问题 - 不同教育背景承担不同责任
- 农民工方案值得欣赏（未受高等教育却能解决问题）
- 博士若用电风扇方案应被批评（应具备系统解决问题的能力）
系统性问题得不到解决，真正的高效就无法实现
关键结论：博士和农民工的解决方案层次不同，不具备可比性
- 网友比较具有误导性
- 读书还是很有用的
132
- 对具体问题概念化、程式化，将这个具体问题升级为一个普通问题，找到问题背后的模式。
- 找到这个普通问题的通用解决方案。
- 根据具体问题的边界条件，将通用解决方案具体化，得到该具体问题的解。
- 头脑风暴方式求解（不断代入答案试错）具有很大的不确定性，效率往往比较低下。
- 博士将其升级为一个普通问题（存在与正常香皂盒不同的异物），然后面对这个普通问题建立通解（自动分拣系统），从而形成了系统解决方案。
- 农民工则对具体问题进行了头脑风暴式的解决。
133
- 个体牲畜主想：“我拥有的奶牛越多，就会越富裕，因为放牧是免费的，我要尽快扩大牧群。”
- 每个牲畜主都以同样的方式思考，牧群快速增长，导致牛吃草的速度大于草生长的速度
- 无私的行为除了会让自己变得越来越穷，对阻止灾难没有丝毫作用，这就是牧场效应
- 在福特汽车案例中，每个设计师反而都在他们自己设计的零件上增添了更多的功能，为的是争取从公共利益中分配到更多的电能
- 几乎每个系统都存在成长上限，组织增长一段时间后即达到上限、停止增长
- 江峰试图通过延长工作时间来解决进度滞后的问题，但是压力和疲劳导致工作速度减缓、工作质量下降、效益降低
- 由于囚徒无法信任对方，因此倾向于互相揭发，而不是同守沉默
- 系统中如果每个人都以对自己最有利的方式决策，每个人都在促使事情走向更糟
- 项目管理中一个常见的冲突就是对稀缺资源的争夺
- 如果组织中的成员都能认识达到整体利益最佳的关键在于合作而不在于竞争，项目团队会运行得更好
- 如果每个人都像一个“囚徒”，最终必然皆输
134
- 每一个复杂系统都包括两个基本元素，即正反馈回路（放大）和负反馈回路（缩小）
- 两个具有相同回路结构的系统，会以非常相似的方式运行
- 整个系统的情况取决于哪个回路更强或更具优势
- 人们时常会干涉一个系统，消除自己不喜欢的负反馈回路，结果却产生了另一个更坏的反馈回路
- 大多数系统在不受干扰的情况下会自我保持平衡，即使受到干扰也仍能回到平衡点上
- 通过了解正反馈和负反馈回路的性质，我们可以区分哪些事情只是暂时影响系统，哪些事情对系统会产生持久影响
- 任何变化，只要不改变系统重要的正反馈回路或负反馈回路，都是暂时的
- 任何变化，只要影响了系统正反馈回路和负反馈回路之间的关系，都将改变系统的长期行为
- 如果我们想要改变一个复杂系统，必须找到一种途径来改变保持系统平衡的不同回路之间的关系
- 否则，对系统所做的任何改变都将遇到阻力，系统最终又会回到最初的状态
135
- 提升效率的关键在于综合优化，社会技术系统中人员与技术组件相互作用，任何变化都可能影响其他组件
- 过度追求”和谐化”的人际关系反而导致组织系统衰退，试图建立”乌托邦”并不能提高组织绩效
- 只优化技术系统而忽视社会系统会导致冲突激化，用技术解决非技术问题往往使组织误入歧途
- “跌倒老人扶不扶”问题引发社会信任体系瓦解，人员组件被破坏的恶果无法单纯通过技术手段解决
- 设备升级案例显示：技术变革未及时沟通社会系统，导致员工产生自我实现的预言式离职
- 只有通过社会与技术系统的综合最优化，组织才能取得最优绩效
136
- 系统工程的一个基本原理是超越系统本身解决问题，即N维系统产生的问题只有在N+1维的系统中才能解决
- 表面上来看是进度拖延，其实很多时候是需求、质量、成本、组织等问题
- 项目遇到的很多问题常常需要在更广范围、更高组织的层面上解决
- 只针对现象进行管控，实则是为系统注入了新的干扰和噪声，导致系统更加不稳定
- 治标是管理系统的噪声，治本是管理、优化甚至升级系统
- 在项目管理中，区分噪声和系统模式是一种能力
- 噪声是标，系统模式是本；噪声能由系统自己纠正，模式必须在N+1维系统中通过改进系统结构来优化
- 不触及系统结构，注定是在管理噪声，治标不治本的项目管理很多时候还不如不管
137
- 多数组织的管理比较关注短期而不是长期，是一种被动管理而不是主动管理。同样的问题也困扰着项目管理。
- 人们常常在健康问题上表现出矛盾的态度：一方面希望改善，另一方面却不愿付出努力。
- “太麻烦了！算了，以后再说吧。” 体现了面对困难选择时的逃避心态。
- “只要能治好，倾家荡产都行。” 反映了在危机时刻愿意付出巨大代价的转变。
138
- 人们如此关注今天的问题，以至于看不到将来的问题，或不能预见到今天的问题是项目将来更大“病情”的症状。
- 头痛医头，脚痛医脚。系统性问题得不到解决，真正的高效亦无法实现。
- 短期高效与体系效率的选择中，选择短期高效者往往还自鸣得意，认为自己“聪明”地以低成本实现了目的。
- 为解决一个问题，采取了一项短期内见效的对策，但长期而言，会产生越来越严重的后遗症，使问题更加恶化。
- 有时候对策可能比问题更糟。 人们在生活、工作时会面临大量的决策，不幸的是很多决策都有“副作用”。
- 系统思维的智慧体现在“下金蛋的鹅”、“拔苗助长”、“抽刀断水水更流，举杯消愁愁更愁”等典故中。
- 案例：公司因资金短缺采取高利率贷款和降价促销，短期缓解了现金流，但长期导致品牌形象受损、收入减少、新产品开发受阻，加剧了现金短缺问题。
- 麻烦的是，时间紧迫往往会放大问题本身。 从今天的问题中摆脱出来，从短期的关注中跳出，看到“大局”，这需要真正的修炼和能力。
- 不能只顾眼前、总事后补救，更重要的是预防、建立健康的系统。 然而，人们总是病治好后，就把锻炼身体的事又忘了，以致同样的故事反复上演。
139
- 现实中，人们时常鼓励“电风扇吹盒子”式的小聪明，美其名曰“秘籍”，这是一个充满秘籍的神奇世界。
- 问题是，这些秘籍经常是解决表象、不解决根源，舍本逐末。
- 解决系统问题的表象容易，解决系统问题的根源很难；而且，解决根源往往时间长、代价大，当代人更喜欢“短平快”的方式和方法。
- 项目管理者也时常如此，比如面对一个问题成员，你一般不直接处理（往往也没有处理员工的权力，而且，即便有这个权力也未必敢用），而是试图提高自己的人际关系技能。
- 正如甘地所言“改变别人很难，唯一可以改变的是自己”。
- 也许真正有效的方案是“开除该人”，但真的有人会这么做吗？
140: 第9章 极简项目管理，说起来容易做起来难
- 你们知道了，但是我们做到了。
- 很多人冲着我20余年的项目经验会阅读这本书，也有人因为这个原因上了我的课
- 我试图分享我的全部经验，为此我煞费苦心，还特地将项目过程做了非常细致的结构化：五大过程组、“如来十掌”“三字经”……
- 这的确有效降低了项目的实施难度，但你真的已经能够成功地管理项目了吗？
141
- 专家在回答完问题之后，通常还会鼓励我们：“这很容易的，按我说的做就能搞定！”
- 当我们真按照专家说的做了，却发现并不是那么回事！实际情况与专家所说的有很大的差别，结果也完全不同。
- 很多人得出了一个结论：“真是个‘砖家’，站着说话不腰疼！”
- 为什么按照专家的建议做了事情却没有搞定？是他们讲得不对，还是我们根本没有搞懂呢？
142
- 教练：这还要说啊！离合在你的左脚，不是右脚，刹车和油门才在你的右脚！
- 教练：快慢不是最重要的，挂挡速度要快。右脚干什么，那还用问吗？踩油门！
- 主管：（失去了耐心）受到影响的输电线路到工单上去找啊！数据库还能在哪里，在电脑里呀。（潜台词：这还用问！）
- 主管：（已非常生气）这个也要问！当然能找到。与电力传输或截止点有关的数字和字母的组合码（专业术语），你知道吗？
- 妈妈：这是啥话，这还用说吗？没有菠萝能做出菠萝派吗？
- 妈妈：就咱们俩吃的话，需要三勺面粉，或者四勺也行？还有糖，你想甜一点就多放一点儿，至于其他嘛，到底放多少合适呢？让我想想！
- 孩子：妈妈，你骗人！你根本不会做菠萝派！
143
- 专家与初学者的思维方式是不同的
- 传递知识涉及两个概念：陈述性知识和程序性知识
- 专家往往着眼于事物的模式和全局，而新手往往注重局部和细节
- 专家在描述信息时容易出现误区：常略去很多信息，假定学习者已具备基础知识
- 专家教会他人需要前提条件：双方必须在同一水平层次上交流
144
- 说起来容易做起来难，做起来容易说起来也难
- 请立即回答一下你家中有几个窗户。如果你现在就在家里，不要去数，请凭记忆回答。
- 你很难马上答出来。
- 你的思维是下面这个过程：首先会在头脑中勾勒出家的样子，然后，灵魂在房间里走了一遍。你在默数窗户的数量，嘴巴还可能会在动，也许眼睛还在发直！
- 我们为什么不能立刻回答出这个如此熟悉的问题呢？这可是我们自己的家呀！
- 答案跟前面几个场景中的知识和信息传递问题是一样的。
145
- 陈述性知识也叫“描述性知识”，是指个人具有能有意识地提取线索，并直接加以回忆和陈述的知识
- 程序性知识是个人不能有意识地提取线索，只能借助某种形式间接推导出其存在的知识
- 陈述性知识用于说明事物的性质、特征和状态，具有静态性质，主要是记忆和描述
- 程序性知识是一套办事的操作步骤，是关于“怎么办”的知识，具有动态性质，主要是行动
- 陈述性知识赋予我们把做的事情和任务进行描述的能力，只有人类具有陈述性知识
- 程序性知识是大多数动物都有的
- 举例说明：解释中美贸易摩擦是陈述性知识，开车是程序性知识；介绍京东商城是陈述性知识，在京东商城购买书籍是程序性知识
146
- 人类对陈述性知识和程序性知识的处理方式是不同的
- 你能“做”，但没做好“说”的准备
- 专家所掌握的很多知识是程序性的而非陈述性的
- 如何才能把程序性知识传递给其他人呢？答案是：专家必须想办法将程序性知识转化成陈述性知识说出来，而学习者必须要把陈述性知识转化成程序性知识来练习
- 认知心理学研究表明，学习到陈述性知识后是无法立刻转化为程序性知识的，这种转化需要试着做很多次
- 现实中不仅“说起来容易做起来难”，而且“做起来容易说起来也难”
147
- 成长与知识金字塔分为五个阶段：具体事和场景→方法论→逻辑→哲学→心法
- 现实中我们一开始遇到的都是一个个具体的事和场景，这些都是事物的局部和细节，自然每次情况就都不尽相同
- 随着遇到的事和场景的数量逐步增加，一般人都会发现同类事件的某些共性，最后通过总结找到某一类问题的解决办法——方法论
- 一些人会发现这些方法论之间还是有规律的——逻辑，这些逻辑基本可以总结为用几句话说出来的道理
- 少数人发现，其实逻辑背后也是有章可循的，于是，他们进一步将其提炼为哲学，这就是用一句话高度概括的本质
- 只有极少数人能开悟，也就是升华为几个字的心法——只可意会不可言传！
- 专家往往着眼于事物的模式和全局，而初学者往往注重局部和细节
- 初学者在做工作时，遇到的都是具体的事和场景，要完成这些工作需要的大部分知识是程序性的，但专家能告诉你的，是以陈述性为主的知识
- 一个专家的水平越高，他说出来的越有可能会上升并接近于哲学、逻辑和心法
- 成人和孩子产生代沟是必然的，孩子遇到的都是具体的事和场景，父母告诉他的总是经过总结提炼的方法论及其以上的道理和哲学
- 事经历得太少，连鸡毛蒜皮都是烦恼
- 越是好书字越少，越是好书案例越少（甚至没有）。因为每一个案例都是具体的，这就直接导致一个结果——仅反映事物的一个侧面
148
通过学习得到的知识基本上是陈述性知识的集合，如果仅仅学习，即便你全部了解了这些知识也未必能把事做好！
把学到的陈述性知识转化为程序性知识，一般都需要试错，悟性好的人需要的次数少一点儿，悟性差的人需要的次数多一点儿。
如果一个人不学习这些陈述性知识，尽管也可以通过不断试错最终掌握相应的程序性知识，但试错次数将大为增加。
学习的价值在于大大减少试错次数，从而节省试错成本。
无论如何，现在我们需要做的是，回去按学到的知识进行实践、总结、再实践、再总结，唯有如此才能真正将其转化为自己的能力。
否则，就仅仅是知道了一些道理而已。
一句话，仅听教练讲，自己不下水是学不会游泳的。
理论脱离实践是最大的不幸！ ——达·芬奇
仅阅读本书不能保证你一定能做好项目，即便是你背下来也不行。
149: 附录A 赋予逻辑意义的数字
- 赋予逻辑或物理含义的数字更容易被长期记忆
- 实验表明：无意义数字短时间内可复述，但10分钟后几乎无人记得
- 通过整理数字并赋予逻辑意义（如时间单位关系），参与者能在10分钟至1年后仍准确复述
- 关键示例：数字序列对应一年4季、12个月、52周、365天、每周7天、每天24小时、每小时60分钟、每分钟60秒