《极简项目管理》读书笔记

这是一本值得推荐的书籍，尤其适合项目管理的新手和有经验的从业者。这本书不同于传统刻板的项目管理教材，融入了作者对项目管理的独特理解，提供了一种更简单、更易懂、更实用的项目管理方法‌。无论你是项目管理的新手还是拥有多年经验的老手，这本书都能帮助你更好地理解项目管理的本质和挑战，提升项目规划、执行与协作能力‌！

《极简项目管理》读书笔记

• 第二部分 | 极简项目管理过程
  • 启动：师出有名，名正言顺
    • 项目管理谚语
      • 项目不是在结束时失败，而是在开始时失败
      • 在过程中打败自己，在结果上打败对手
    • 生命周期模型是项目管理的工具
      • 项目生命周期的特征
        • 观点
          • 站在实施方（乙方）的角度，项目过程就是“绑架客户上贼船的过程”
            • 当然，如果站在委托方（甲方）的角度，项目过程则是“逐步移交主动权的过程”
          • 项目变更的代价不仅包括成本，还包括时间和质量代价
        • 举例：如果把培养孩子当成一个生命周期来看
          • 幼儿时，父母要求孩子学什么他就学什么，父母影响孩子的能力很强
          • 孩子上小学后，父母的影响力减小了，如果提的要求过多，孩子就会叛逆
          • 孩子上中学后，父母再提太多的要求，某些孩子就会不回家吃饭，以此威胁父母
          • 当孩子大学毕业了，父母还敢提要求吗？不提要求人家都不回家吃饭，父母只能期望孩子能“常回家看看”
        • 变更
          • 乙方角度
            • 项目初期，让怎么干就怎么干，（遵守变更控制程序）
            • 项目中期，要变更，先谈谈，尽可能取消变更
            • 项目后期，变更成本太高，当务之急是项目验收，将项目收尾
              • 遇到大的变更，重启一个项目，小的变更等到维护阶段再去变更
              • 生米煮成熟饭
        • 没有时间把事情做对，却总是有时间返工
      • 项目需要阶段化管控
        • 当存在不确定性因素时，人们会感觉痛苦、煎熬
        • 观点
          • 项目阶段化管理的好处
            • 项目在被分成多个阶段后，能更清楚地展现其规律性，人们也更容易把控项目的发展，提高项目成功的可能性
            • 通过划分阶段对工作按照时间进行分类，也更容易搞清楚每个时期的主要矛盾是什么
            • 可以减轻痛苦、降低不确定性，从而增强项目经理成功的信心
          • 分阶段
            • 确定各阶段需要完成哪些工作
            • 明确各阶段的可交付成果何时产生，如何验证和确认
            • 确定各阶段需要哪些人员参加
            • 确定如何控制风险和验收各个阶段的成果
          • 瀑布式&敏捷式项目管理的区别
            • 瀑布
              • 什么情况下 选择瀑布生命周期
                • 充分了解交付的产品
                • 有扎实的行业实践基础
                • 整批一次性交付产品有利于每个人
            • 敏捷
              • 什么情况下选择敏捷型生命周期
                • 需要应对快速变化的环境
                • 需求和范围难以事先确定
                • 能够以有利于相关人员的方式定义较小的增量改进
              • 迭代和增量
            • 喜欢敏捷型生命周期的人对于瀑布型生命周期的误解可概括为以下几个方面
              • 过多的文档工作
              • 表格烦琐
              • 流程繁重
              • 人被流程管理而不是人管理流程
            • 而喜欢瀑布型生命周期的人对于敏捷型生命周期的误解则可概括为以下几个方面
              • 完全抛弃流程
              • 无序、失控
              • 不适用于复杂项目
              • 不专业
        • 举例
          • 日本人获得马拉松冠军
            • 提前一天熟悉比赛路线，把路线分成几段
            • 根据显眼的建筑物--里程碑事件
      • 延伸：疯狂的项目之六拍、四没、三边、只谈
        • 观点
          • 六拍：拍脑袋、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿
          • 四没：没问题、没关系、没办法、没资源
          • 三边：边设计、边实施、边修改
          • 只谈：项目初期只谈成本、项目中期只谈进度、项目后期只谈质量
    • 定目标：项目始于业务终于业务
      • 如果你不知道要去哪里，给你张地图也没有用
      • 自我欣赏的是艺术，他人接受的才是商品
        • 举例：更好，和更快有什么区别
          • 这三个工作到底需要多长时间才能完成呢？哪种组合方式更好呢
      • 定义明确的项目目标
        • SMART法则
          • 明确的（Specific）
          • 可以测量的（Measurable）
          • 可以实现的（Attainable）
          • 相关的（Relevant）
          • 有明确的时限的（Time-based）
      • 跳一跳、够得着：基于愿望的目标必将破产
        • 观点
          • 基于愿望的目标必将破产，原因是
            • 目标建立在愿望大大超过能力的基础上，团队成员只能被迫接受
              • 但是，他们不是发自内心地认可这个目标，于是在后续工作中他们不会努力去实现这个目标，而是用行动来证明你们定的目标是错的
            • 人们对项目团队的目标或交付能力失去信心，于是人们不再把精力投入项目实施中去，转而去设置下一轮的基于愿望的目标
          • 不切实际的高目标，容易滋生消极的组织文化
            • “狼来了”和“掩耳盗铃”从此相伴相生
            • 会干的往往搞不过会说的
            • 自欺欺人的激励方法
            • 奖励任劳任怨却惩罚灵活应变
          • 跳一跳，够的着
            • 提出比实际能力稍高的目标
        • 思考：这个观点感觉是有问题的
          • 就以福特如果得到的两个目标（“培养出能够跑得更快的马” 和“造出汽车”），后者显然在现有认知下是够不着的，但是如果没有这个目标，就很难产生颠覆性的创新
          • 理论基础就是行动学习的理论
      • 能否相信客户的话
        • 如何分辨客户需求
          • 你想要，拿钱来。客户的期望总是比能交付的要多
            • 区分需要与想要的一个方法是：客户愿意付钱的是其真正需要的，否则就不是
          • 多关注已知的真实行为
            • 少关注客户说什么，多关注客户的行为
            • 很多时候，客户对自己说的话既没有认真思考，更不用付出代价
          • 时刻记住项目是一个业务过程
            • 遇到问题以后不要仅仅解决问题的本身，还要去解决问题所在环境
            • 举例
              • 客户要买一个电钻，是因为他缺一个电钻吗？不是，是因为他想在家里的墙上打一个洞。那客户真的想要一个洞吗
              • 不是，是因为他想在墙上钉一个钉子。那客户真的是想要在墙上钉一个钉子吗？不是，他只是想挂一幅画。而想要挂一幅画，客户只需要一个粘钩就可以了
        • 观点
          • 切忌“鸵鸟心态”
            • 答应与否都不能算错，但明知道客户有这种需要，却不加以明确，让这个问题“悬”着就是一个严重的问题
          • 如确实有问题存在而且躲不掉，假如争吵不可避免，那么早吵也会比晚吵好
            • 一方面，问题在早期解决成本会比较低
            • 另一方面，尽早暴露问题，吵完了大家也就可以安心地做事了
        • 观点
          • 目标和需求是需要确认的
          • 真正想要的并非他们的签字，而是希望他们借此机会认真考虑项目问题
    • 识鬼神：项目是面向人的复杂过程
      • 关键是要管理与平衡相关方的期望和利益
        • 观点
          • 项目管理者的两个重要职责：管理人的期望
          • 平衡人们的不同利益，并确保项目团队以专业和友好的态度与他们打交道
      • 用权力–利益方格分析和管理相关方
        • 编写相关方登记册的步骤如下
          • 收集相关人员的个人资料（姓名、从属单位和职务）
          • 评估每个人对项目的期望和态度
          • 确定每个人的权力和利益分值（在规定范围内的分值，如1~10分）
          • 使用权力–利益方格（见图.2-14）分析每个人的影响
          • 基于每个人在权力–利益方格中的位置，制订管理策略
    • 组团队：干部是把事做成的关键
      • 项目经理的压力是全方位的
        • 观点
          • 如果你喜欢一个人，就让他去当项目经理，因为这使他有机会驱动组织变革
          • 如果你恨一个人，也让他去当项目经理，因为十有八九他会被失败的项目“毁”了
      • 小心旁观者效应，做好三落实
        • 为确保每个人都能承担起自己对组织的责任，必须做好三落实
          • 任务落实：每个任务都必须有明确的负责人
          • 人员落实：任何一个人，不能让其只享有权利而不承担义务
          • 组织落实：确保组织中的制度、流程、工具、技术协调一致，并有统一的激励措施
      • 使用RAM明确每个人的责任
        • RACI
          • Responsible（负责）
          • Accountable（批准）
          • Consulted（咨询）
          • Informed（知悉）
        • 每项活动有且只能有一个R
    • 发章程：建立项目团队与组织的契约
      • 项目章程是项目团队与组织的契约
      • 编制项目任务书的重点在于达成共识
        • 项目启动阶段最重要的成果并不是项目任务书本身，而是在编写项目任务书的过程中所获得的洞察力和达成的共识
        • 项目任务书的主要内容
          • 可测量的项目目标和相关的成功标准
          • 项目的总体要求
          • 概括性的项目描述
          • 项目的主要风险
          • 总体里程碑进度计划
          • 总体预算
          • 项目审批要求
          • 委派的项目经理及其职责和职权
          • 发起人或其他批准项目任务书的人员的姓名和职权
        • 批准过程的参与者
          • 高级管理层
            • 管理层的支持对于项目的成功实施起着至关重要的作用
            • 他们的批准意味着“可以做详细计划，我们授权项目可以使用所需的资源”
          • 客户
            • 在我们的项目管理概念里，客户起着非常重要的作用
          • 职能部门经理
            • 项目的可交付成果不可能存在于真空中，总是有一些部门对项目的产品或服务提供输入或从中获得输出
            • 应征求职能部门经理的意见和建议，使他们在最初阶段就了解项目并对项目做出承诺
          • 项目经理
            • 在理想情况下，项目经理应在最初阶段就确定下来，并参与起草项目任务书
            • 因为他将管理项目，所以他应该在项目定义和项目批准过程中发挥重要作用
          • 项目团队核心成员
            • 其中主要指团队内的专家们，他们将留在项目团队中，从项目的开始直到最后结束
            • 让他们参与到批准过程中来，往往会加强其对项目的主人翁责任感
    • 开好头：名正言顺地启动项目
      • 重要的节点必须要举行仪式，要引起领导和相关部门的重视，让项目团队更有凝聚力
      • 项目不是在结束时失败，而是在开始时失败
        • 尽量营造项目的工作氛围，例如张贴项目总体进度图，制作项目的标志图，或者有意识地更换一下项目成员的工位，让他们坐得更近一些
        • 可以让每个人想一句话，表达一下自己要如何努力来保证整个团队的绩效
        • 当事情真实发生的时候，也就是固定的“程序”触发条件产生时，对方的固有“程序”便会失去原有效用
          • 这在心理学中被称为“免疫效应”
          • 示范：你可以这样和你的家人沟通：“我知道你听了我的想法之后会感到生气，但是我真的很想要那部越野车！”
        • 启动阶段必须明确的规则包括
          • 沟通方式、频率、内容及格式
          • 项目管理者的权力，即项目奖惩权力、人事调度权力和项目方案的决定权力等
          • 甲方责任、需求提供、调研配合和业务指导等
          • 变更处理的流程、文档、权力等
          • 团队合作模式、风格、出勤、考核标准、争议解决等
          • 项目开发方的各个部门的义务及责任
        • 以上信息不一定都以项目制度的形式公布出来，如果映射到制度上，应该包括
          • 项目例会制度
          • 绩效考核制度
          • 汇报制度
          • 文档流程
          • 变更管理制度等
      • 表明正式开始的项目启动会
        • 省略了项目启动会的项目，其过程往往很混乱，很多人对项目的配合不够，协同性很差，项目目标也就无法按计划实现
        • 如果可能，要大张旗鼓，千万不要像鬼子进村——“悄悄地来，悄悄地走”
        • 方法
          • 为了完美地启动项目，建议用结构化方法实施项目启动会
  • 规划：运筹帷幄，决胜千里
    • 计划是花费最少、影响最大的工作
      • 事前想清楚，事后不折腾
        • 举例：两个前往南极探险的团队遭遇
          • 阿蒙森团队率先到达南极点之后，又顺利地返回了原来的基地
            • 而斯科特团队没有获得荣誉，更糟糕的是，他们返回的路上天气非常恶劣，不断地有人掉队，最后没有一个人生还
            • 斯科特团队不但没有完成首先到达南极点的目标，而且全军覆没，这已经是生与死的区别了
          • 一个是有计划的（物资准备充足、风险预估等），另一个是随心所欲的
        • 观点
          • 布利斯定理：用较多的时间为一次工作做计划，做这项工作所用的总时间就会减少
          • 不可能完全按照计划进行，但是计划会为你提供做事的优先顺序，这样会事半功倍
      • 魔鬼藏在细节中
        • 举例
          • 南极探险案例补充：阿蒙森团队对午餐的特别安排
          • 省去了生火做饭的时间和能源浪费
        • 观点
          • 管理项目是个复杂的过程，计划充当着这个过程的地图
          • 该地图必须足够详细，使项目经理能据此决定下一步做什么，进而保证工作在规定时间、预算、范围内能保质保量地完成
      • “如来十掌”为制订计划提供了抓手
        • 举例
          • 张斌带领团队为客户进行无线通信基站的建设，他们的项目需要于三天后在野外施工
          • 天气预报显示，三天后暴风雨将至，而张斌的团队并没有防雨设备。现在该怎么办
        • 方法：通过“如来十掌”为制订计划提供了抓手
          • “如来十掌”的第一个问题：做什么（范围、需求）
          • “如来十掌”的第二个问题：什么时候做（时间、进度）
          • “如来十掌”的第三个问题：花多大的代价做（成本、费用）
          • “如来十掌”的第四个问题：做到什么程度（质量）可以接受
          • “如来十掌”的第五个问题：需要什么资源（团队、采购或外包）
        • 对有效计划的建议
          • 对计划进行计划
          • 计划执行者应该参与制定计划
          • 计划制订的第一规则是随时准备重新做计划
          • 制定备用计划
          • 定义问题比解决问题更重要
          • 重点关注项目的工作分解结构（WBS）
          • 分阶段编制计划（滚动式计划
        • 关于项目计划，以下几句话分享给大家
          • 计划是用来改的，正因为计划没有变化快，才更需要做计划
          • 领导不应该直接管人管事，而应该管计划
          • 项目不应该被领导管着，而应该被计划管着
          • 员工不应该按领导的指示做事，而应该按计划做事
    • 拆任务：没有WBS就没有项目管理
      • 隐性工作显性化，显性工作结构化，结构工作标准化
        • 观点
          • WBS及其词典是组织的重要无形资产。在同一企业中，尽管所有项目各不相同，但有许多项目在较高层次上是相似的
          • 如果能够花费些精力去编制涵盖这些同类型项目的标准WBS，那么这样的WBS就成了企业的一种无形资产
        • 方法：4种常见的WBS类型
          • 按组成分解
          • 按功能用途分解
          • 按生命周期分解
          • 按地域/组织分解
          • 没有最佳方法，合适的就是最好的
            • 建议在项目启动时每种方法都要考虑一下，从中选择一个可以清晰定义项目工作的方法来分解项目
        • 方法： WBS的展示方法
          • 树形层次结构更适用于向高层管理者汇报工作或沟通
          • 而表格形式更适合项目团队成员自己使用，因为可以在表格右侧增加更多细节备注，这有利于团队协作，但看起来更复杂
      • 心法：创建有价值的WBS
        • 方法：如何创建WBS
          • 拿到一个项目后，对于一个具体的目标可以从两个视角考量：“怎么完成”和“交付什么”
          • 当选择了一个视角后，下一步又可以分别从这两个视角进一步分解，直到满足“易于管理”和“足够详细”两条标准为止
            • WBS的最底层组件一定是“交付什么”，即都是具体的交付成果
        • 方法：如何判断WBS的好坏
          • MECE法则：相互独立，完全穷尽
          • 信息透明原则：指可以估算工作包的工作量以及完成工作包所需的时间、成本和验收标准
          • 80小时原则：单个工作包的完成时间不应超过80个小时
          • 独立责任原则：单个工作包只分配给一个单独的人
          • 滚动式规划原则：近细远粗，近多远少
          • 不同层次原则：不同可交付成果可以分解到不同的层次
          • 一个上级原则：每个下一级组件有且只有一个上级组件
        • 工具：判断WBS好坏的检查表
      • WBS是有效项目管理的基础
        • 观点
          • WBS被认为是现代项目管理的重要基石
          • WBS首先解决的就是项目中“做正确的事”的问题，只有明确了“做正确的事”，“正确地做事”才有基础
        • 方法
          • 看见即降服：看见即降伏的原理对项目管理极有价值，利用这个原理，通过可视化、透明化工具对项目过程进行管控
          • 在项目过程中，让项目所有相关人员一起来创建WBS，并在WBS中使用不同色块标明每个工作包的状态，还可以把各项工作的责任人标明，同时给出各项工作包的时间计划
    • 排计划：绘制项目作战线路图
      • 让进度估算走向科学
      • 关键路径法：进度计划与网络技术
    • 算投入：项目管理是一项平衡的艺术
      • 核心在于花多少钱对应完成多少工作量
        • 观点
          • 将预算与实际完成工作量做比较，表明了项目的进度状况；将实际成本与实际完成工作量做比较，表明了项目的成本花费状况
          • 将实际花费与预算比较，只能得出花钱速度的快慢，对项目并无实际价值
        • 预算
          • 完成对应费用的工作量
          • 即计划完成工作量的价值
      • 抓住项目预算的关键
    • 估风险：不信邪就会中邪
      • 优秀的管理者不是善于冒险，而是善于控制风险
        • 优秀的管理者不是善于冒险，而是善于控制风险
      • 风险管理在国内的困境
        • 风险管理的悖论：如果风险管理很好，风险就不会发生，可是风险不发生怎么证明是因为风险管理得好呢
      • 分析风险的概率和影响
        • 方法
          • 风险事件发生的概率
          • 风险真的发生后，可能产生的后果的范围与影响
          • 每个结果的可能性
          • 做好对已知风险的管理，在识别后，我们需要以下数据进行风险分析
        • 通常首先查询风险的影响评级，然后查询概率影响矩阵来评估每个风险的重要性和所需的关注优先级
  • 执行：依计而行，行必结果
    • 无关人品，系统使然
      • 系统的意志
        • 观点
          • 元素会继承系统的意志
          • 符合系统意志的元素获益最大
        • 系统的意志决定了粒子做事情的阻力系数，按系统的意志做事是阻力最小的方式
      • 结构决定行为
        • 举例
          • 狱警实验是心理学史上最著名、最有争议性的实验之一，曾经多次被改编成电影
          • 狱警实验告诉我们：角色变了，人也跟着改变
      • 花瓶之碎，谁之过
        • 被误解的蝴蝶效应
          • 人们心目中蝴蝶效应的一个形象写照：从小到大的一堆柱子排在一起，推倒最小的一根柱子就会产生连锁反应，最终把右侧的花瓶砸碎
          • 谁谁砸碎了花瓶？是整个系统和结构
        • 观点
          • 总之，如果把一堆炸药放在一起，只要一个火星就能引起爆炸，那如果真的爆炸了，也不应该埋怨那个火星，而应该反思为什么炸药这么危险的东西不好好管理
          • 火星总会来的，小骨牌总要倒下，蝴蝶总要振动翅膀
            • 应该怪罪的是设计系统结构的人，而不是系统中的元素
        • 把系统结构搞好了，我们就可以安心专注于正常的工作
    • 建组织：结构决定行为
      • 职能型组织
        • 有趣的（职能型组织中常见的问题）
          • 高层感觉中层能力不行、素质不够，就替中层思考
          • 中层感觉基层能力不行、素质不够，就替基层思考
          • 基层没事干，也感觉高层领导能力不行，就替高层思考
      • 矩阵型组织
      • 项目型组织
        • 项目性组织的缺点
          • 它对企业的资源利用程度不够。项目资源被各项目组独占，当项目需要这些资源的时候固然能及时获得，但当项目不需要这些资源时却很难从项目组释放
          • 当项目遇到技术难题需要调用组织更多力量时，这种形式也颇为不便
      • 组织结构应与组织发展阶段相适应
        • 观点：无数实践证明，成功的企业从诞生、职能化、规范化到逐步引入项目化，有着类似的历程和发展阶段，这个过程没有捷径
    • 带队伍：建设和维护高绩效团队
      • 选择合适的团队成员
      • 项目团队的组织方式
        • 项目团队的组织方式有很多种，但基本上可以归为外科手术式、交响乐队式、爵士乐队式和足球队式四种
        • 最适合的就是最好的
          • 外科手术式项目团队
            • 所有人都围绕着主刀医生，主刀医生就是整个团队的核心
          • 交响乐队式项目团队
            • 在演奏过程中，指挥其实是一个精神领袖，团队成员都全情投入，陶醉在美妙的乐曲中
          • 爵士乐队式项目团队
            • 有一个灵魂人物，但是不脱产，所有人都参与演奏
          • 足球队式项目团队
            • 有明确的分工，但是不规定在何时、由谁、在何位置、做什么，一切要随时进行调整
      • 顺利走过团队的生命期
    • 善协调：项目管理是一个极具挑战性的工作
      • 项目与部门间的冲突
        • 明确目标、并让每个人知悉
        • 设定一个可以短期实现的历程碑
      • 项目间的冲突：“牛人”争夺战
      • 影响项目的治理与人际因素
        • 搞好项目=搞好人脉+搞好关系+搞好资源+搞好工作
  • 监控：审时度势，沉着应变
    • 采数据：用数据而不是用感觉管理项目
      • 用直方图展示和理解数据
      • 用散点图寻找数据之间的关系
      • 用帕累托图定位需要关注的重点
      • 用控制图实现过程管控
    • 控质量：质量是要命的事
      • 项目质量管理的尴尬
        • 五中质量管理的水平
          • 靠客户逼
          • 靠检查控
          • 靠过程保
          • 靠设计防
          • 靠文化治
      • 项目需要什么样的质量管理部
        • QA 和 测试的区别：QA的重点在于流程度量和过程改进，而不仅仅是问题测试
        • 名副其实的QA小组或QA经理具备以下特质
          • 有权有钱，能够对团队成员提供必要的培训
          • 有权处理客户的投诉，推动客户投诉的处理
          • 有能力制订过程改进计划，并根据过程改进计划进行组织结构调整、人员配置以实施过程改进
          • 有能力、有权力通过多个项目来度量过程改进是否有效
          • QA工作对人的要求非常高，熟悉质量体系仅仅是基本条件，更需要很高的综合素质、业务能力和项目经验
        • 合格的QA的三种角色
          • 警察：及时发现和报告项目中的问题
          • 教师：对项目成员进行过程和规范的培训以及在过程中进行指导等
          • 医生：QA人员可以承担收集、统计、分析度量数据的工作，对项目过程进行诊断，帮助分析原因，开处方
      • 决心比技巧更重要
        • 项目复盘中常常看到“加强过程管控，要求团队成员自检、互检，严格按程序要求实施，加强培训”等，1次、2次、5次、10次……有时连自己都麻木了，不是吗
        • 能做什么呢？就是坚持一贯的原则了
    • 勤监控：让项目走在正轨上
      • 过程控制方法论
        • PDCA
        • 方法:解决问题的万能公式
          • 行动之前要计划，计划之前要分析，分析之前要信息
        • 作为项目管理者，你应该做到以下几点
          • 在计划过程中，合理规划里程碑节点，使其有可行性，有验收价值
          • 在执行过程中，围绕每一个里程碑安排工作，找到项目的节奏
          • 在管理过程中，将里程碑的压力传递给项目中的每一个人
        • 请记住
          • 眼睛盯住细节的，是工程师
          • 眼睛盯住结果的，是老板
          • 眼睛盯住过程的，是项目管理者
      • 项目监督控制最佳实践
        • 很多的加班现象都是项目管理不当造成的
        • 5分钟站立会议（5 minutes stand-up meeting）
          • 是实践中项目管控的好办法
          • 会议时，项目团队成员在固定时间（如每天上午8:30—8:35）、固定地点，每天站着围在一起，轮流主持、相互通报
          • 每人回答以下3个问题
            • 昨天我做了什么
            • 现在我遇到了什么困难
            • 今天我计划做什么
            • 5分钟站立会议既可以推动项目进展、跟踪项目问题，往往也可以提升团队对项目的责任感，起到团队建设的作用
      • 要想避免混乱，必须在沟通上下功夫
        • 向上沟通要有“胆”
          • 跟上级（组织高层、客户领导等）沟通，要克服惧怕心理，多出选择题、少出问答题，做到主动、及时
          • 永远不要让他们从别人那里得知你该汇报的信息
        • 平级沟通要有“肺”
          • 流程与制度是框架，人际关系是润滑剂，与职能部门和其他项目管理者沟通要平心静气、互惠互利
        • 向下沟通要有“心”
          • 项目团队成员是实现业务的人，当你成为项目管理者以后，你的成功都是基于团队的，你必须懂得倾听团队成员的声音
    • 管变更：让变更可管理、可控制
      • 唯一不变的就是变化
      • 让变更受控
        • 管理变更的九阴真经
          • 第一步，当有人提出变更时，首先要评估信息的准确性，确认项目变更事实
          • 第二步，提供变更申请的书面记录
          • 第三步，分析变更对范围、进度、成本、质量等诸方面的影响
          • 第四步，沟通变更影响，确认是否取消变更
          • 第五步，针对变更请求，提出相应解决方案
          • 第六步，查阅审批权限，选择合适人员对变更进行审批
          • 第七步，召开变更控制会议，批准或否决变更
          • 第八步，根据对变更请求的审批状态，与相关人员进行沟通
          • 第九步，指导与执行变更相关工作，跟踪变更执行状态
        • “九阴真经”人为地增加了变更的摩擦系数，让变更变得困难，客观上降低了变更的频率
      • 对变更的管控是项目管理水平的体现
        • 谨慎对待第一次
          • 如你顶不住压力同意了变更，这在事实上会给客户一个信号
          • 变更是可以被接受的，只要对项目团队施压就行
        • 方法
          • 利用框架效应
            • 面临收益时人们会小心翼翼，选择风险规避
            • 面临损失时人们甘愿冒风险，选择倾向风险偏好，以损失为导向进行沟通往往更有效
            • 总之，忠告不如警告
          • 举例
            • 有点玄乎不太好理解 总体就是说，要把不变更的收益、变更的损失清晰的对比出来
        • 话在出口之前你是它的主人，一旦出口你就成了它的奴隶
        • 与你的承诺有关的条件可能会被忘记，但你的承诺本身却不会被忘记
        • 不管产品特性多么耀眼，过一段时间人们就会将其视为正常的功能
        • 决不让步，除非交换
        • 范围蔓延
          • 项目组自身造成的范围蔓延较为隐蔽，它一般是由于项目人员的技术心态造成的
          • 技术人员想从技术中获得成就感的渴望促使他们自觉或不自觉地按照兴趣去创造一些没有必要的、不合理的、仅满足自身情感需要的产品
        • 今天的问题来自昨天的解
        • 框架效应
          • 忠告不如警告，以损失为导向的沟通将更加有效
          • 面临收益时人们会小心翼翼，选择风险规避
          • 面临损失时人们甘愿冒风险，选择倾向风险偏好
  • 收尾：慎终如始，好戏杀青
    • 做好项目收尾，不留后遗症
      • 收尾好才是真的好
        • 项目收尾工作的维度
      • 提高成功的概率
      • 编写项目收尾报告
        • 项目收尾工作应该包含的内容
          • 第一部分，描述原项目（招标时）的基本方面，即范围、进度、成本、质量等
          • 第二部分，说明在范围、进度、成本、质量等方面与原计划的偏差
          • 第三部分，分析项目生命周期中的客户关系
          • 第四部分，总结风险管理，提供项目过程中发生的主要威胁和机会的列表，并说明是如何应对的，以及应对的实际结果
          • 第五部分，经验教训，包含事情的经过和采取的措施，并指出这些经验教训的受益者会有哪些
    • 过验收：项目不能做成烂尾楼
      • 理解客户“真实的”问题是顺利验收的关键
      • 验收后的工作
    • 得总结：最大的浪费是经验教训的浪费
      • 从无知之错到无能之错
        • 内部专利制度
          • 参考专利制度，我们在实践中设计了一套行之有效的经验教训管理方法——内部专利
          • 文档被其他人查阅一次就付一次费用给撰写人
          • 同时，如果总结的方法被使用后，的确防范了问题的再次发生，由此降低的成本也给撰写人分成
          • 在我所供职的研究院，有人撰写了非常有价值的文档，因为被人查阅的次数多、对问题解决的贡献大，仅此一项就拿到了不菲的现金奖励
      • 经验教训的悲剧
        • 举例
          • “二战”期间，盟军对德国本土展开空袭。盟军飞机遭到了德国地面防空炮火的猛烈攻击，大量飞机被击伤、击落，损失惨重
          • 为降低飞机被击落的概率，有必要对机身的关键部位进行相应的加固
          • 工作人员在对参战返回的飞机做了全面的检查后发现，几乎所有飞机的机腹部分都弹痕累累，而机翼却几乎没有被炮火击中的痕迹
          • 军方决定对飞机的机腹部分进行加固，以此应对敌方密集的枪弹
        • 哥伦比亚大学的统计学教授亚伯拉罕·沃德（Abraham Wald）却给出完全不同的建议：真正需要加固的是机翼，而不是机腹
      • 避免吃二遍苦、受二茬罪
        • 以项目后评估为契机，用结构化方法确保经验教训总结的有效性
        • 使用递增式方法管理文档
          • 准备一份包含所有最终文档的提纲，并将此提纲放在每个团队成员的工作任务书里
          • 然后，在项目过程中，当每一项关键任务完成时，都要求相应团队成员提供与任务相关的几句、几段或几页文档，然后将这些片段插入提纲内适当的位置
          • 我把这种方法称为“递增式文档”，“递增式文档”操作起来相对不那么“痛苦”，为最终文档的完成提供了好方法
    • 去归档：让经验教训真发挥作用
      • 让经验教训发挥作用不是一件容易的事
      • 扎紧无能之错的篱笆
        • 如何做好经验/教训管理工作
          • 建立内部专利制度
            • 采用正向激励，让提供经验教训的人拿到实实在在的好处
              • 这是最关键的措施
            • 追加案例前查重
              • 在新项目实施和相关评审环节，项目团队必须提交经验教训检查表，确保案例库中的经验教训及其应对措施得以落实
            • 将经验教训使用作为质量控制（quality control，QC）的检查项
              • 作为项目质量工作的一项内容，QC部门将按照经验教训总结表对方案进行检查
          • 优化现有案例库
            • 案例库瘦身
            • 简化案例描述
            • 对案例按逻辑分类
• 第三部分 | 成为卓有成效的项目管理者
  • 好的项目管理者为何如此稀缺
    • 智商–情商矩阵
      • 成长路径
      • 十年磨一剑
    • 选错人注定是一个悲剧
      • 技术专家型管理者未必有更多优势
      • 项目管理者应该了解多少技术
      • 非技术背景管理者如何管理技术团队
    • 项目管理者的能力素质
      • 和谐的人际关系能力
      • 系统思考的能力
      • 换位思考的沟通能力
      • 管理自己、影响他人的领导力
    • 从技术专家到优秀项目管理者
      • 由专注技术转向关注拥有技术的人
      • 由理性转向感性和理性相结合
      • 由追求完美转向追求满意
      • 由做自己感兴趣的事转向自己该做的事情
      • 由着眼于项目工作转向着眼于项目的商业价值
      • 由技术权威转向管理能手
  • 打造面向业务的系统化思维
    • 系统复杂性与思维的局限
      • 机械性思维的局限（相对于系统性思维）
        • 举例：为一个延误的项目增加人员，将导致更多的延误
          • 牛人在“救火”，项目经理在“帮忙”，但都没有采取任何措施来预防未来的火灾
          • 技术牛人杜鑫负责的负压检测子系统工作进度落后，在项目经理江峰的协调下，杜鑫同意加班以赶上原定计划
          • 经过连续两周每天12小时的努力工作，终于有所进展。糟糕的是，一个月以后负压检测子系统暴露出越来越多的错误，杜鑫不得不花时间纠正错误
          • 他完成的工作量也开始有所下降，而且情况正在恶化。既然加班不能解决问题，江峰决定采取行动。他说服老板增加资源，让另一个人加入了负压检测子系统工作
          • 更糟糕的是，二人完成的工作量只相当于杜鑫一人单独完成的工作量，并且出现了更多的错误。江峰找杜鑫了解情况。杜鑫说：“你给我找来的人对工作不了解
          • 我花了三天时间让他了解情况。后来，我发现他犯了很多错误，不得不帮他纠正。我还要加班培训他……还不如没有人帮忙！”你有没有似曾相识的感觉
        • 机械性思维的特点
          • 关注的焦点在于事物的内部、构成元素以及这些元素之间的关联关系
          • 认为系统整体的最优来源于各个局部的最优
      • 最高明的医生善治“未病之病”
      • 系统的关键在于相互作用
        • 举例：如何用系统性思维解决问题
          • 机械性思维：按照见招拆招的机械性思维方式寻找高犯罪率问题的解决方案
          • 一般可以形成三种做法
            • 惩奸除恶，形成对罪犯的高压态势
            • 政府进行干预，加强枪支器械管制等治安管控手段
            • 对潜在的罪犯进行教育
          • 系统性思维：堕胎合法化
    • 提高问题的认知层次
      • 博士和农民工的PK
        • 认知世界可以分为4个层次（以项目经理救火为例）
          • 反应层：救火
          • 模式层：培训新员工，解决问题
          • 系统结构层：开始面向未来，找到预防出问题的方法
          • 共同愿景层：创建新模式，替代旧模式
        • 举例
          • 某企业引进了一条香皂包装生产线，结果发现经常有空盒流过。厂长请了一个博士花了200万元设计了一套自动分拣系统
          • 一乡镇企业遇到同样问题，农民工花90元买了一台大电风扇放在生产线旁，有空盒经过便被吹走
          • 博士和农民工的解决方案，层次不同，不具备可比性
      • 系统思维解决问题的方法
      • 牧场效应与囚徒困境
    • 提升效率的关键在于综合优化
      • 寻找复杂系统的平衡
      • 提升效率的关键在于综合优化
      • N维系统中的问题在N+1维系统中解决
    • 艰难的选择
      • 短期高效与体系效率孰重孰轻
      • 见长效还是短平快
  • 极简项目管理，说起来容易做起来难
    • 站着说话不腰疼
      • 似曾相识的场景
      • 专家与初学者的思维方式的不同
    • 说起来容易做起来难，做起来容易说起来也难
      • 陈述性知识与程序性知识
        • 陈述性知识 & 程序性知识
          • 陈述性知识
            • 主要是用来说明事物的性质、特征和状态，用于区分和辨别事物
            • 介绍京东商城是做什么的是陈述性知识
          • 程序性知识
            • 是一套办事的操作步骤，是关于“怎么办”的知识
            • 程序性知识具有动态的性质，主要是行动，而不是记忆
              • 在京东商城购买一本书是程序性知识
        • 如何才能把程序性知识传递给其他人呢
          • 答案是：专家必须想办法将程序性知识转化成陈述性知识说出来，而学习者必须要把陈述性知识转化成程序性知识来练习
      • 知识传递的困境
    • 仅阅读本书不能保证做好项目
      • 成长与知识金字塔
      • 学习陈述性知识的必要性
        • 陈述性知识便于理解和学习，但是要转化成自己的程序性知识，必须通过不断的实践练习和反思
• 第一部分 | 认识项目管理
  • 项目开始时总存在说不清的成分
    • 观点
      • 用户根本不知道自己需要什么，直到你把它摆在他面前
        • 人总是用之前见过的东西，来描述一个未曾出现过的东西
      • 项目在刚开始时，总存在说不清的成分；频繁的变更也是项目工作本身的性质决定的
      • 频繁的变更是由项目工作本身的性质决定的
        • 让客户签字，是为了让客户的变更不要变的那么随意
        • 孩子没出生之前，你能把孩子长什么样说清楚吗
    • 举例：在汽车还没有诞生之前，要你去做一个“让马跑得更快”的项目
  • 项目是一个业务过程，而非技术过程
    • 观点
      • 如果不盯着技术指标，问题也许还能解决，但若只盯着技术指标，往往就容易沉浸在细节里面出不来了
      • 针对业务的需求才是客户的真实需求
      • 遇到问题以后，不要试图仅仅解决问题本身，还要去解决问题所在环境的问题
      • N维系统产生的问题只有在N+1维系统中才能解决
      • 项目是一个业务过程，而不是技术过程
        • 这是重要的项目思维！项目管理者也应该是一个业务层面的管理者
    • 实施
      • 业务建模
      • 多年的经验告诉我，对于项目，一定要给客户看到“样板房”，如样品、模型、照片、软件的基本界面等，否则很可能会出问题
  • 拥抱变更：无关人品，项目使然
    • 观点
      • 客户每一次提出新的要求，都是在帮我们逐步逼近事实真相
      • 实际上，只要理解项目的不确定性，就很容易明白绝大多数变更不是人的问题，而是项目属性所决定的
        • 在频繁变更这件事上，无论谁做项目都不可避免，因此唯一需要调整的就是我们面对变更的态度
      • 客户虐我千百遍，我待客户如初恋
        • 更严重的是，有的人在面对变更时，不是去消灭新需求，而是去消灭提出新需求的人
        • 于是，因为变更导致的冲突、打架事件层出不穷
      • 时刻记住，变更来源于项目属性，与人无关
      • 一句话：在项目中拥抱变更
        • 注意是“拥抱”而非“接受”
  • 项目的特点
    • 项目管理谚语
      • 如果你现在还没有参加项目，那么你多半是在做一些费力不讨好而且枯燥无味的重复性工作
      • 但是，如果你参加了一个项目，日子就更难过了，你会觉得干一件费力不讨好且枯燥无味的重复性工作是多么令人神往
    • 独特性
    • 临时性
      • 临时性是指项目有明确的起点与终点
      • 临时性并补意味着项目的持续时间短
      • 临时性会造成项目管理者的权限不足
      • 临时性的项目不意味着成果的临时性
      • 项目可因多种原因结束
        • 达成项目目标
        • 不会或不能达到目标
        • 项目资金缺乏或没有可分配资金
        • 项目需求不复存在
        • 无法获得所需人力或物力资源
        • 出于法律或其他原因而终止项目
    • 渐进明细性
      • 观点
        • 指逐渐细化，意味着项目是在连续积累中分步骤实现的，即逐步明确项目的细节特征
        • 项目需要渐进明细的方面包括：项目目标、项目计划、项目范围
        • 项目渐进明细≠范围蔓延
          • 举例
            • 在去商场前，甲计划买两套运动衣，可是到了商场后，他发现运动鞋促销，于是就买了一双——这是范围蔓延
            • 在到达商场前，甲只考虑需要买运动衣，没有确定款式、色彩、价位，到商场后，看到了越来越多的商品后，甲慢慢对要买的运动衣的款式、色彩、价位有了明确的认识——这是渐进明细
        • 渐进的方式
          • 化大为小，逐步推进
          • 剥洋葱式，逐层深入
  • 项目的价值在于驱动变革
    • 做项目管理一定要关注企业的宏观环境，由宏观看微观，再从微观看宏观
  • 组织的工作类型与框架
    • 观点
      • 组织的工作分为三类
        • 战略规划类工作
        • 日常运营类工作
          • 运营以追求效率为目的，赚钱的事要好好干，这对组织很重要
        • 项目类工作
          • 而由于外界环境在不断地变化，组织的机制和工作方式也需要随之改变，应进行内部调整，以适应环境，也就是必须做项目
      • 运营能够维持组织在一定水平上持续运行，而项目可以实现组织运营水平的提升
  • 你说的项目管理可能不是项目管理
    • 项目管理类的工作分为三个层次
      • 项目组合管理
        • 在资金有限的情况下，组织必须认真考虑、评估各项目的特点和价值，以判断它们的投资优先级
      • 项目集管理
        • 把一些有相关性的项目打包在一起，形成项目集，就能够实现节约资源的目标
      • 项目管理
        • 在一定的约束（范围、进度、成本、质量等）下完成既定工作
  • 大多数项目缺乏有效管理
  • 极简项目管理：用结构化降低项目难度
    • 提高沟通能力靠悟性吗
      • 观点/方法
        • 问题本身、环境、解决主体这三个维度组成了理解和分析问题的空间结构
        • 掌握了这个结构就能很容易找到问题的多种解决方案，把问题想全面，并且还能分得很清
      • 举例
        • 将200毫升的水装进100毫升的杯子里
        • 解决方案
          • 问题本身（杯子/水本身）：水结冰、杯子换成有弹性的
          • 环境：送上太空
          • 解决主体：找专家
    • 极简项目管理：一个结构化的方法
      • 作为项目管理者，如果你拥有了结构化思维，它将为你的职业生涯带来巨大的帮助，可以使你面对项目中的困难时能够更淡定从容
      • 五大过程组
        • 启动：确立项目的合法地位和总体要求（目标），宣布项目正式立项（上马）
        • 规划：编制项目计划，把项目目标具体化，制订达到目标的路线图
        • 执行：按计划开展项目活动，把纸面上的成果变成实实在在的成果
        • 监控：把实际情况与计划要求进行比较，发现偏差，分析偏差，并在必要时进行变更（包括调整计划或对执行纠偏）
        • 收尾：按序开展收尾工作，把项目正式关门
      • 如来十掌
        • 范围管理——确定项目的工作内容
        • 进度管理——确定这些工作要在什么时间完成
        • 成本管理——确定这些工作要花多大代价完成
        • 质量管理——确定这些工作做到什么程度才可以接受
        • 弄清需要谁、使用哪些资源来完成项目（资源管理）
        • 如果没有足够的资源，需要外包一些工作给其他公司或个人（采购管理）
        • 项目所涉及的内外部人员之间需要进行有效沟通，才能较好地相互协调（沟通管理）
        • 如何实现各相关人员有效参与和期望控制并获得其对项目的满意（相关方管理）
        • 识别哪些不确定性因素会促进或妨碍项目成功，并积极加以管理（风险管理）
        • 在上述9个相互竞争的目标下，如何实现最优（整合管理）
      • 三字经
      • 管理思路
        • 明确项目目标（要什么）
        • 确定需要完成什么（需要得到的结果）
        • 制定需要做什么和怎么做的步骤（计划）
        • 构建考核的标准（范围、进度、成本），组织好实施人员（管理人员），并在项目过程中通过绩效考核（管理绩效）以确保项目的完成
• 书籍信息
  • 作者: 郭致星
    • 一位项目管理布道者，一位资深的项目管理实践者，国家重点工程项目管理专家组成员
    • 专注项目实践二十余年，主持了20多项863、973和国家重点专项的研发和管理工作
  • 副标题: 让目标落地、把事办成并使成功可复制的方法论
  • 出版社: 机械工业出版社
  • 出版年: 2020-9
  • 相关书籍推荐
    • 《极简学习法》
    • 《管理的常识》
    • 《决策思维》