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

读书笔记《极简项目管理》： 陈述性知识：主要是用来说明事物的性质、特征和状态，用于区分和辨别事物（介绍京东商城是做什么的是陈述性知识）

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

• 327 附录C　一个办公室装修的WBS
• 326 附录B　一个大型学术会议的WBS
• 325 附录A　赋予逻辑意义的数字
• 第一部分 | 认识项目管理
  • 002 第1章　极简项目管理基础
    • 003 1.1　项目是独特的一次性事业
    • 004 1.1.1　项目开始时总存在说不清的成分
      • 【观点】：
        • 用户根本不知道自己需要什么，直到你把它摆在他面前。（人总是用之前见过的东西，来描述一个未曾出现过的东西）
        • 项目在刚开始时，总存在说不清的成分；频繁的变更也是项目工作本身的性质决定的
      • 【案例】：在汽车还没有诞生之前，要你去做一个“让马跑得更快”的项目~~
    • 006 1.1.2　项目是一个业务过程，而非技术过程
      • 【观点】
        • 如果不盯着技术指标，问题也许还能解决，但若只盯着技术指标，往往就容易沉浸在细节里面出不来了。
        • 不要试图仅仅解决问题本身，还要去解决问题所在环境的问题。
        • N维系统产生的问题只有在N+1维系统中才能解决
        • 项目是一个业务过程，而不是技术过程。这是重要的项目思维！项目管理者也应该是一个业务层面的管理者。
    • 008 1.1.3　拥抱变更：无关人品，项目使然
      • 【观点】
        • 客户每一次提出新的要求，都是在帮我们逐步逼近事实真相。
        • 实际上，只要理解项目的不确定性，就很容易明白绝大多数变更不是人的问题，而是项目属性所决定的。在频繁变更这件事上，无论谁做项目都不可避免，因此唯一需要调整的就是我们面对变更的态度。
    • 009 1.2　项目的特点
      • 010 1.2.1　独特性
      • 011 1.2.2　临时性
      • 012 1.2.3　渐进明细性
        • 【观点】
          • 指逐渐细化，意味着项目是在连续积累中分步骤实现的，即逐步明确项目的细节特征
          • 项目需要渐进明细的方面包括：项目目标、项目计划、项目范围
          • 项目渐进明细≠范围蔓延
            • 【案例】在去商场前，甲计划买两套运动衣，可是到了商场后，他发现运动鞋促销，于是就买了一双——这是范围蔓延。在到达商场前，甲只考虑需要买运动衣，没有确定款式、色彩、价位，到商场后，看到了越来越多的商品后，甲慢慢对要买的运动衣的款式、色彩、价位有了明确的认识——这是渐进明细。
          • 渐进的方式：
            • 化大为小，逐步推进
            • 剥洋葱式，逐层深入
    • 014 1.3　项目的价值在于驱动变革
      • 015 1.3.1　组织的工作类型与框架
        • 【观点】
          • 组织的工作分为三类：战略规划类工作、日常运营类工作、项目类工作
          • 运营能够维持组织在一定水平上持续运行，而项目可以实现组织运营水平的提升。
      • 018 1.3.2　你说的项目管理可能不是项目管理
        • 【观点】
          • 项目管理类的工作分为三个层次：
            • 1、项目组合管理：在资金有限的情况下，组织必须认真考虑、评估各项目的特点和价值，以判断它们的投资优先级。
            • 2、项目集管理：把一些有相关性的项目打包在一起，形成项目集，就能够实现节约资源的目标。
            • 3、项目管理：在一定的约束（范围、进度、成本、质量等）下完成既定工作
      • 020 1.3.3　大多数项目缺乏有效管理
    • 022 1.4　极简项目管理：用结构化降低项目难度
      • 022 1.4.1　提高沟通能力靠悟性吗
        • 【观点/方法】
          • 问题本身、环境、解决主体这三个维度组成了理解和分析问题的空间结构，掌握了这个结构就能很容易找到问题的多种解决方案，把问题想全面，并且还能分得很清。
        • 【案例】
          • 将200毫升的水装进100毫升的杯子里
          • 解决方案：
            • 问题本身（杯子/水本身）：水结冰、杯子换成有弹性的；
            • 环境：送上太空；
            • 解决主体：找专家
      • 027 1.4.2　极简项目管理：一个结构化的方法
        • 【观点】
          • 作为项目管理者，如果你拥有了结构化思维，它将为你的职业生涯带来巨大的帮助，可以使你面对项目中的困难时能够更淡定从容。
          • 五大过程组：
            • ·启动：确立项目的合法地位和总体要求（目标），宣布项目正式立项（上马）。
            • ·规划：编制项目计划，把项目目标具体化，制订达到目标的路线图。
            • ·执行：按计划开展项目活动，把纸面上的成果变成实实在在的成果。
            • ·监控：把实际情况与计划要求进行比较，发现偏差，分析偏差，并在必要时进行变更（包括调整计划或对执行纠偏）。
            • ·收尾：按序开展收尾工作，把项目正式关门。
          • 如来十掌：
            • （1）范围管理——确定项目的工作内容
            • （2）进度管理——确定这些工作要在什么时间完成。
            • （3）成本管理——确定这些工作要花多大代价完成。
            • （4）质量管理——确定这些工作做到什么程度才可以接受。
            • （5）弄清需要谁、使用哪些资源来完成项目（资源管理）。
            • （6）如果没有足够的资源，需要外包一些工作给其他公司或个人（采购管理）。
            • （7）项目所涉及的内外部人员之间需要进行有效沟通，才能较好地相互协调（沟通管理）。
            • （8）如何实现各相关人员有效参与和期望控制并获得其对项目的满意（相关方管理）。
            • （9）识别哪些不确定性因素会促进或妨碍项目成功，并积极加以管理（风险管理）。
            • （10）在上述9个相互竞争的目标下，如何实现最优（整合管理）。
          • 三字经
• 第二部分 | 极简项目管理过程
  • 032 第2章　启动：师出有名，名正言顺
    • 032 2.1　生命周期模型是项目管理的工具
      • 033 2.1.1　项目生命周期的特征
        • 【观点】
          • 站在实施方（乙方）的角度，项目过程就是“绑架客户上贼船的过程”。当然，如果站在委托方（甲方）的角度，项目过程则是“逐步移交主动权的过程”。
        • 【案例】
          • 如果把培养孩子当成一个生命周期来看
      • 037 2.1.2　项目需要阶段化管控
        • 【观点】
          • 项目阶段化管理的好处：
            • 项目在被分成多个阶段后，能更清楚地展现其规律性，人们也更容易把控项目的发展，提高项目成功的可能性。
            • 通过划分阶段对工作按照时间进行分类，也更容易搞清楚每个时期的主要矛盾是什么。
            • 可以减轻痛苦、降低不确定性，从而增强项目经理成功的信心
          • 瀑布式&敏捷式项目管理的区别：
            • 缺图
      • 042 2.1.3　延伸：疯狂的项目之六拍、四没、三边、只谈
        • 【观点】
          • 六拍：拍脑袋、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿
          • 四没：没问题、没关系、没办法、没资源
          • 三边：边设计、边实施、边修改
          • 只谈：项目初期只谈成本、项目中期只谈进度、项目后期只谈质量
    • 045 2.2　定目标：项目始于业务终于业务
      • 【金句】如果你不知道要去哪里，给你张地图也没有用
      • 046 2.2.1　自我欣赏的是艺术，他人接受的才是商品
        • 【案例】更好，和更快有什么区别
          • 这三个工作到底需要多长时间才能完成呢？哪种组合方式更好呢？
      • 048 2.2.2　定义明确的项目目标
        • SMART法则
      • 050 2.2.3　跳一跳、够得着：基于愿望的目标必将破产
        • 【观点】
          • 基于愿望的目标必将破产，原因是：
            • 目标建立在愿望大大超过能力的基础上，团队成员只能被迫接受。但是，他们不是发自内心地认可这个目标，于是在后续工作中他们不会努力去实现这个目标，而是用行动来证明你们定的目标是错的。
            • 人们对项目团队的目标或交付能力失去信心，于是人们不再把精力投入项目实施中去，转而去设置下一轮的基于愿望的目标
          • 不切实际的高目标，容易滋生消极的组织文化：
            • （1）“狼来了”和“掩耳盗铃”从此相伴相生。
            • （2）会干的往往搞不过会说的。
            • （3）自欺欺人的激励方法。
            • （4）奖励任劳任怨却惩罚灵活应变。
        • 【点评与反思】这个观点感觉是有问题的
          • 就以福特如果得到的两个目标（“培养出能够跑得更快的马” 和“造出汽车”），后者显然在现有认知下是够不着的，但是如果没有这个目标，就很难产生颠覆性的创新
          • 理论基础就是行动学习的理论
      • 053 2.2.4　能否相信客户的话
        • 【方法】如何分辨客户需求
          • （1）你想要，拿钱来。客户的期望总是比能交付的要多。区分需要与想要的一个方法是：客户愿意付钱的是其真正需要的，否则就不是。
          • （2）多关注已知的真实行为。少关注客户说什么，多关注客户的行为。很多时候，客户对自己说的话既没有认真思考，更不用付出代价。
          • （3）时刻记住项目是一个业务过程。遇到问题以后不要仅仅解决问题的本身，还要去解决问题所在环境。
            • 【案例】：
              • 客户要买一个电钻，是因为他缺一个电钻吗？不是，是因为他想在家里的墙上打一个洞。那客户真的想要一个洞吗？不是，是因为他想在墙上钉一个钉子。那客户真的是想要在墙上钉一个钉子吗？不是，他只是想挂一幅画。而想要挂一幅画，客户只需要一个粘钩就可以了。
        • 【观点】
          • 切忌“鸵鸟心态”：答应与否都不能算错，但明知道客户有这种需要，却不加以明确，让这个问题“悬”着就是一个严重的问题
          • 如确实有问题存在而且躲不掉，假如争吵不可避免，那么早吵也会比晚吵好。一方面，问题在早期解决成本会比较低，另一方面，尽早暴露问题，吵完了大家也就可以安心地做事了。
        • 【观点】
          • 目标和需求是需要确认的
          • 真正想要的并非他们的签字，而是希望他们借此机会认真考虑项目问题
    • 058 2.3　识鬼神：项目是面向人的复杂过程
      • 058 2.3.1　关键是要管理与平衡相关方的期望和利益
        • 【观点】
          • 项目管理者的两个重要职责：管理人的期望；平衡人们的不同利益，并确保项目团队以专业和友好的态度与他们打交道。
      • 061 2.3.2　用权力–利益方格分析和管理相关方
        • 【方法】
          • 编写相关方登记册的步骤如下（缺图）：
            • （1）收集相关人员的个人资料（姓名、从属单位和职务）。
            • （2）评估每个人对项目的期望和态度。
            • （3）确定每个人的权力和利益分值（在规定范围内的分值，如1~10分）。
            • （4）使用权力–利益方格（见图2-14）分析每个人的影响。
            • （5）基于每个人在权力–利益方格中的位置，制订管理策略。
    • 062 2.4　组团队：干部是把事做成的关键
      • 062 2.4.1　项目经理的压力是全方位的
        • 【观点】
          • 如果你喜欢一个人，就让他去当项目经理，因为这使他有机会驱动组织变革；如果你恨一个人，也让他去当项目经理，因为十有八九他会被失败的项目“毁”了
      • 065 2.4.2　小心旁观者效应，做好三落实
        • 【观点/方法】
          • 为确保每个人都能承担起自己对组织的责任，必须做好三落实：
            • 任务落实：每个任务都必须有明确的负责人
            • 人员落实：任何一个人，不能让其只享有权利而不承担义务
            • 组织落实：确保组织中的制度、流程、工具、技术协调一致，并有统一的激励措施
      • 066 2.4.3　使用RAM明确每个人的责任
        • 【方法/工具】
          • 责任分配矩阵图（缺图） #方法
    • 068 2.5　发章程：建立项目团队与组织的契约
      • 068 2.5.1　项目章程是项目团队与组织的契约
      • 069 2.5.2　编制项目任务书的重点在于达成共识
        • 项目启动阶段最重要的成果并不是项目任务书本身，而是在编写项目任务书的过程中所获得的洞察力和达成的共识。 #观点
        • 项目任务书的主要内容 #方法
          • （1）可测量的项目目标和相关的成功标准。
          • （2）项目的总体要求。
          • （3）概括性的项目描述。
          • （4）项目的主要风险。
          • （5）总体里程碑进度计划。
          • （6）总体预算。
          • （7）项目审批要求。
          • （8）委派的项目经理及其职责和职权。
          • （9）发起人或其他批准项目任务书的人员的姓名和职权。
    • 074 2.6　开好头：名正言顺地启动项目
      • 重要的节点必须要举行仪式，要引起领导和相关部门的重视，让项目团队更有凝聚力 #观点
      • 074 2.6.1　项目不是在结束时失败，而是在开始时失败、
        • 尽量营造项目的工作氛围，例如张贴项目总体进度图，制作项目的标志图，或者有意识地更换一下项目成员的工位，让他们坐得更近一些。 #方法
        • 可以让每个人想一句话，表达一下自己要如何努力来保证整个团队的绩效。 #方法
        • 当事情真实发生的时候，也就是固定的“程序”触发条件产生时，对方的固有“程序”便会失去原有效用。这在心理学中被称为“免疫效应”。（示范：你可以这样和你的家人沟通：“我知道你听了我的想法之后会感到生气，但是我真的很想要那部越野车！”）#观点
        • 启动阶段必须明确的规则包括：#方法
          • （1）沟通方式、频率、内容及格式。（2）项目管理者的权力，即项目奖惩权力、人事调度权力和项目方案的决定权力等。（3）甲方责任、需求提供、调研配合和业务指导等。（4）变更处理的流程、文档、权力等。（5）团队合作模式、风格、出勤、考核标准、争议解决等。（6）项目开发方的各个部门的义务及责任。
        • 以上信息不一定都以项目制度的形式公布出来，如果映射到制度上，应该包括 #方法 ：
          • （1）项目例会制度。（2）绩效考核制度。（3）汇报制度。（4）文档流程。（5）变更管理制度等。
      • 078 2.6.2　表明正式开始的项目启动会
        • #观点 省略了项目启动会的项目，其过程往往很混乱，很多人对项目的配合不够，协同性很差，项目目标也就无法按计划实现。
        • #观点 如果可能，要大张旗鼓，千万不要像鬼子进村——“悄悄地来，悄悄地走”。
        • #方法 为了完美地启动项目，建议用结构化方法实施项目启动会。
          • 缺图：表2-5　启动会议10问；表2-6　启动会议10个需要注意的细节
  • 082 第3章　规划：运筹帷幄，决胜千里
    • 083 3.1　计划是花费最少、影响最大的工作
      • 084 3.1.1　事前想清楚，事后不折腾
        • #案例 两个前往南极探险的团队遭遇
          • 阿蒙森团队率先到达南极点之后，又顺利地返回了原来的基地。而斯科特团队没有获得荣誉，更糟糕的是，他们返回的路上天气非常恶劣，不断地有人掉队，最后没有一个人生还。斯科特团队不但没有完成首先到达南极点的目标，而且全军覆没，这已经是生与死的区别了。
          • 一个是有计划的（物资准备充足、风险预估等），另一个是随心所欲的
        • #观点 布利斯定理：用较多的时间为一次工作做计划，做这项工作所用的总时间就会减少（不可能完全按照计划进行，但是计划会为你提供做事的优先顺序，这样会事半功倍）
      • 085 3.1.2　魔鬼藏在细节中
        • #案例 南极探险案例补充：阿蒙森团队对午餐的特别安排（省去了生火做饭的时间和能源浪费）
        • #观点 管理项目是个复杂的过程，计划充当着这个过程的地图。该地图必须足够详细，使项目经理能据此决定下一步做什么，进而保证工作在规定时间、预算、范围内能保质保量地完成。
      • 087 3.1.3　“如来十掌”为制订计划提供了抓手
        • #案例 张斌带领团队为客户进行无线通信基站的建设，他们的项目需要于三天后在野外施工。天气预报显示，三天后暴风雨将至，而张斌的团队并没有防雨设备。现在该怎么办？
        • #方法 通过“如来十掌”为制订计划提供了抓手
          • （1）“如来十掌”的第一个问题：做什么（范围、需求）
          • （2）“如来十掌”的第二个问题：什么时候做（时间、进度）
          • （3）“如来十掌”的第三个问题：花多大的代价做（成本、费用）。
          • （4）“如来十掌”的第四个问题：做到什么程度（质量）可以接受。
          • （5）“如来十掌”的第五个问题：需要什么资源（团队、采购或外包）。
    • 090 3.2　拆任务：没有WBS就没有项目管理
      • 091 3.2.1　隐性工作显性化，显性工作结构化，结构工作标准化
        • #观点 WBS及其词典是组织的重要无形资产。在同一企业中，尽管所有项目各不相同，但有许多项目在较高层次上是相似的。如果能够花费些精力去编制涵盖这些同类型项目的标准WBS，那么这样的WBS就成了企业的一种无形资产。
        • #方法 4种常见的WBS类型（没有最佳方法，合适的就是最好的。建议在项目启动时每种方法都要考虑一下，从中选择一个可以清晰定义项目工作的方法来分解项目。）
          • （1）按组成分解
          • （2）按功能用途分解
          • （3）按生命周期分解
          • （4）按地域/组织分解
        • #方法 WBS的展示方法
          • 树形层次结构更适用于向高层管理者汇报工作或沟通
          • 而表格形式更适合项目团队成员自己使用，因为可以在表格右侧增加更多细节备注，这有利于团队协作，但看起来更复杂。
      • 098 3.2.2　心法：创建有价值的WBS
        • #方法 如何创建WBS
          • 拿到一个项目后，对于一个具体的目标可以从两个视角考量：“怎么完成”和“交付什么”
          • 当选择了一个视角后，下一步又可以分别从这两个视角进一步分解，直到满足“易于管理”和“足够详细”两条标准为止（WBS的最底层组件一定是“交付什么”，即都是具体的交付成果。）
        • #方法 如何判断WBS的好坏
          • （1）MECE法则：相互独立，完全穷尽
          • （2）信息透明原则：指可以估算工作包的工作量以及完成工作包所需的时间、成本和验收标准。
          • （3）80小时原则：单个工作包的完成时间不应超过80个小时
          • （4）独立责任原则：单个工作包只分配给一个单独的人
          • （5）滚动式规划原则：近细远粗，近多远少
          • （6）不同层次原则。不同可交付成果可以分解到不同的层次
          • （7）一个上级原则。每个下一级组件有且只有一个上级组件
        • #工具 判断WBS好坏的检查表
          • 缺图：判断WBS好坏的检查表
      • 106 3.2.3　WBS是有效项目管理的基础
        • #观点 WBS被认为是现代项目管理的重要基石： WBS首先解决的就是项目中“做正确的事”的问题，只有明确了“做正确的事”，“正确地做事”才有基础
        • #方法 看见即降服：看见即降伏的原理对项目管理极有价值，利用这个原理，通过可视化、透明化工具对项目过程进行管控。在项目过程中，让项目所有相关人员一起来创建WBS，并在WBS中使用不同色块标明每个工作包的状态，还可以把各项工作的责任人标明，同时给出各项工作包的时间计划。
        • #方法 WBS实现任务墙
          • 缺图
        • #点评和思考 团队内部的WBS配合表
    • 109 3.3　排计划：绘制项目作战线路图
      • 109 3.3.1　让进度估算走向科学
      • 114 3.3.2　关键路径法：进度计划与网络技术
      • 121 3.3.3　案例：路易十四的地牢
    • 124 3.4　算投入：项目管理是一项平衡的艺术
      • 125 3.4.1　核心在于花多少钱对应完成多少工作量
        • #观点 将预算与实际完成工作量做比较，表明了项目的进度状况；将实际成本与实际完成工作量做比较，表明了项目的成本花费状况。将实际花费与预算比较，只能得出花钱速度的快慢，对项目并无实际价值。
        • #案例 T公司为某项目A制订了4个月的实施计划，第二个月月底的财务数据如表3-10所示。T公司财务部经理黄兴拿到该项目的数据，向公司总经理高静汇报：该项目运行得不错——费用节约了！
          • 分析缺图 图3-36　第一个月工作情况的三种可能情景
      • 129 3.4.2　抓住项目预算的关键
    • 131 3.5　估风险：不信邪就会中邪
      • 132 3.5.1　优秀的管理者不是善于冒险，而是善于控制风险
        • #观点 优秀的管理者不是善于冒险，而是善于控制风险
      • 133 3.5.2　风险管理在国内的困境
        • #观点 风险管理的悖论：如果风险管理很好，风险就不会发生，可是风险不发生怎么证明是因为风险管理得好呢？
      • 135 3.5.3　分析风险的概率和影响
        • #方法 做好对已知风险的管理，在识别后，我们需要以下数据进行风险分析。
          • （1）风险事件发生的概率。（2）风险真的发生后，可能产生的后果的范围与影响。（3）每个结果的可能性。
        • #方法 通常首先查询风险的影响评级（见表3-13），然后查询概率影响矩阵（见表3-14）来评估每个风险的重要性和所需的关注优先级。
          • 缺图：表3-13　风险影响评级[插图] 表3-14　概率影响矩阵
  • 139 第4章　执行：依计而行，行必结果
    • 140 4.1　无关人品，系统使然
      • 140 4.1.1　系统的意志
        • #观点 系统的意志决定了粒子做事情的阻力系数，按系统的意志做事是阻力最小的方式
        • #观点 元素会继承系统的意志 2.符合系统意志的元素获益最大
      • 142 4.1.2　结构决定行为
        • #案例 狱警实验是心理学史上最著名、最有争议性的实验之一，曾经多次被改编成电影。狱警实验告诉我们：角色变了，人也跟着改变。
      • 145 4.1.3　花瓶之碎，谁之过
        • #观点 被误解的蝴蝶效应。人们心目中蝴蝶效应的一个形象写照：从小到大的一堆柱子排在一起，推倒最小的一根柱子就会产生连锁反应，最终把右侧的花瓶砸碎。谁谁砸碎了花瓶？是整个系统和结构
        • #观点 总之，如果把一堆炸药放在一起，只要一个火星就能引起爆炸，那如果真的爆炸了，也不应该埋怨那个火星，而应该反思为什么炸药这么危险的东西不好好管理。火星总会来的，小骨牌总要倒下，蝴蝶总要振动翅膀。应该怪罪的是设计系统结构的人，而不是系统中的元素。
        • #观点 把系统结构搞好了，我们就可以安心专注于正常的工作。
    • 148 4.2　建组织：结构决定行为
      • 148 4.2.1　职能型组织
        • #观点 有趣的（职能型组织中常见的问题）
          • ·高层感觉中层能力不行、素质不够，就替中层思考。
          • ·中层感觉基层能力不行、素质不够，就替基层思考。
          • ·基层没事干，也感觉高层领导能力不行，就替高层思考。
      • 152 4.2.2　矩阵型组织
      • 154 4.2.3　项目型组织
        • #观点 项目性组织的缺点
          • 它对企业的资源利用程度不够。项目资源被各项目组独占，当项目需要这些资源的时候固然能及时获得，但当项目不需要这些资源时却很难从项目组释放。
          • 当项目遇到技术难题需要调用组织更多力量时，这种形式也颇为不便。
      • 155 4.2.4　组织结构应与组织发展阶段相适应
        • #观点 无数实践证明，成功的企业从诞生、职能化、规范化到逐步引入项目化，有着类似的历程和发展阶段，这个过程没有捷径。
    • 158 4.3　带队伍：建设和维护高绩效团队
      • 158 4.3.1　选择合适的团队成员
      • 159 4.3.2　项目团队的组织方式
        • #观点 项目团队的组织方式有很多种，但基本上可以归为外科手术式、交响乐队式、爵士乐队式和足球队式四种。最适合的就是最好的
          • 1.外科手术式项目团队（所有人都围绕着主刀医生，主刀医生就是整个团队的核心。）
          • 2.交响乐队式项目团队（在演奏过程中，指挥其实是一个精神领袖，团队成员都全情投入，陶醉在美妙的乐曲中。）
          • 3.爵士乐队式项目团队（有一个灵魂人物，但是不脱产，所有人都参与演奏）
          • 4.足球队式项目团队（有明确的分工，但是不规定在何时、由谁、在何位置、做什么，一切要随时进行调整）
      • 164 4.3.3　顺利走过团队的生命期
    • 168 4.4　善协调：项目管理是一个极具挑战性的工作
      • 169 4.4.1　项目与部门间的冲突
      • 174 4.4.2　项目间的冲突：“牛人”争夺战
      • 178 4.4.3　影响项目的治理与人际因素
  • 184 第5章　监控：审时度势，沉着应变
    • 184 5.1　采数据：用数据而不是用感觉管理项目
      • 186 5.1.1　用直方图展示和理解数据
      • 190 5.1.2　用散点图寻找数据之间的关系
      • 192 5.1.3　用帕累托图定位需要关注的重点
      • 195 5.1.4　用控制图实现过程管控
    • 208 5.2　控质量：质量是要命的事
      • 210 5.2.1　项目质量管理的尴尬
        • #观点 五中质量管理的水平
          • 靠客户逼
          • 靠检查控
          • 靠过程保
          • 靠设计防
          • 靠文化治
      • 212 5.2.2　项目需要什么样的质量管理部
        • #观点 QA 和 测试的区别：QA的重点在于流程度量和过程改进，而不仅仅是问题测试
        • #观点 名副其实的QA小组或QA经理具备以下特质。（QA工作对人的要求非常高，熟悉质量体系仅仅是基本条件，更需要很高的综合素质、业务能力和项目经验）
          • （1）有权有钱，能够对团队成员提供必要的培训。
          • （2）有权处理客户的投诉，推动客户投诉的处理。
          • （3）有能力制订过程改进计划，并根据过程改进计划进行组织结构调整、人员配置以实施过程改进。
          • （4）有能力、有权力通过多个项目来度量过程改进是否有效。
        • #观点 合格的QA的三种角色
          • 警察：及时发现和报告项目中的问题
          • 教师：对项目成员进行过程和规范的培训以及在过程中进行指导等
          • 医生：QA人员可以承担收集、统计、分析度量数据的工作，对项目过程进行诊断，帮助分析原因，开处方
      • 215 5.2.3　决心比技巧更重要
        • #观点 项目复盘中常常看到“加强过程管控，要求团队成员自检、互检，严格按程序要求实施，加强培训”等，1次、2次、5次、10次……有时连自己都麻木了，不是吗？——能做什么呢？就是坚持一贯的原则了。
    • 218 5.3　勤监控：让项目走在正轨上
      • 219 5.3.1　过程控制方法论
        • #方法 解决问题的万能公式（行动之前要计划，计划之前要分析，分析之前要信息）
          • 缺图
      • 221 5.3.2　项目监督控制最佳实践
        • #观点 很多的加班现象都是项目管理不当造成的
        • #方法 5分钟站立会议（5 minutes stand-up meeting）
          • 是实践中项目管控的好办法。会议时，项目团队成员在固定时间（如每天上午8:30—8:35）、固定地点，每天站着围在一起，轮流主持、相互通报，每人回答以下3个问题。（1）昨天我做了什么？（2）现在我遇到了什么困难？（3）今天我计划做什么？5分钟站立会议既可以推动项目进展、跟踪项目问题，往往也可以提升团队对项目的责任感，起到团队建设的作用。
      • 224 5.3.3　要想避免混乱，必须在沟通上下功夫
    • 225 5.4　管变更：让变更可管理、可控制
      • 225 5.4.1　唯一不变的就是变化
      • 228 5.4.2　让变更受控
        • #方法 管理变更的九阴真经 （“九阴真经”人为地增加了变更的摩擦系数，让变更变得困难，客观上降低了变更的频率）
          • 第一步，当有人提出变更时，首先要评估信息的准确性，确认项目变更事实。
          • 第二步，提供变更申请的书面记录。
          • 第三步，分析变更对范围、进度、成本、质量等诸方面的影响。
          • 第四步，沟通变更影响，确认是否取消变更。
          • 第五步，针对变更请求，提出相应解决方案。
          • 第六步，查阅审批权限，选择合适人员对变更进行审批。
          • 第七步，召开变更控制会议，批准或否决变更。
          • 第八步，根据对变更请求的审批状态，与相关人员进行沟通。
          • 第九步，指导与执行变更相关工作，跟踪变更执行状态。
      • 233 5.4.3　对变更的管控是项目管理水平的体现
        • #观点 谨慎对待第一次：
          • 如你顶不住压力同意了变更，这在事实上会给客户一个信号：变更是可以被接受的，只要对项目团队施压就行。
        • #方法 利用框架效应（面临收益时人们会小心翼翼，选择风险规避；面临损失时人们甘愿冒风险，选择倾向风险偏好，以损失为导向进行沟通往往更有效。总之，忠告不如警告！）
          • #案例 有点玄乎不太好理解 总体就是说，要把不变更的收益、变更的损失清晰的对比出来
  • 243 第6章　收尾：慎终如始，好戏杀青
    • 244 6.1　做好项目收尾，不留后遗症
      • 244 6.1.1　收尾好才是真的好
        • #方法 项目收尾工作的维度
          • 缺图
      • 248 6.1.2　提高成功的概率
      • 249 6.1.3　编写项目收尾报告
        • #方法 项目收尾工作应该包含的内容
          • 第一部分，描述原项目（招标时）的基本方面，即范围、进度、成本、质量等。
          • 第二部分，说明在范围、进度、成本、质量等方面与原计划的偏差。
          • 第三部分，分析项目生命周期中的客户关系。
          • 第四部分，总结风险管理，提供项目过程中发生的主要威胁和机会的列表，并说明是如何应对的，以及应对的实际结果。
          • 第五部分，经验教训，包含事情的经过和采取的措施，并指出这些经验教训的受益者会有哪些。
    • 250 6.2　过验收：项目不能做成烂尾楼
      • 250 6.2.1　理解客户“真实的”问题是顺利验收的关键
      • 251 6.2.2　验收后的工作
    • 252 6.3　得总结：最大的浪费是经验教训的浪费
      • 254 6.3.1　从无知之错到无能之错
        • #方法 内部专利制度
          • 参考专利制度，我们在实践中设计了一套行之有效的经验教训管理方法——内部专利。文档被其他人查阅一次就付一次费用给撰写人；同时，如果总结的方法被使用后，的确防范了问题的再次发生，由此降低的成本也给撰写人分成。在我所供职的研究院，有人撰写了非常有价值的文档，因为被人查阅的次数多、对问题解决的贡献大，仅此一项就拿到了不菲的现金奖励。
      • 255 6.3.2　经验教训的悲剧
        • #案例 “二战”期间，盟军对德国本土展开空袭。盟军飞机遭到了德国地面防空炮火的猛烈攻击，大量飞机被击伤、击落，损失惨重。为降低飞机被击落的概率，有必要对机身的关键部位进行相应的加固。工作人员在对参战返回的飞机做了全面的检查后发现，几乎所有飞机的机腹部分都弹痕累累，而机翼却几乎没有被炮火击中的痕迹。军方决定对飞机的机腹部分进行加固，以此应对敌方密集的枪弹。哥伦比亚大学的统计学教授亚伯拉罕·沃德（Abraham Wald）却给出完全不同的建议：真正需要加固的是机翼，而不是机腹！
      • 263 6.3.3　避免吃二遍苦、受二茬罪
        • #方法 以项目后评估为契机，用结构化方法确保经验教训总结的有效性
          • 缺图建议使用图6-3所示的结构化过程保证经验教训总结的质量。
        • #方法 使用递增式方法管理文档
          • 准备一份包含所有最终文档的提纲，并将此提纲放在每个团队成员的工作任务书里。然后，在项目过程中，当每一项关键任务完成时，都要求相应团队成员提供与任务相关的几句、几段或几页文档，然后将这些片段插入提纲内适当的位置。我把这种方法称为“递增式文档”。“递增式文档”操作起来相对不那么“痛苦”，为最终文档的完成提供了好方法。
    • 265 6.4　去归档：让经验教训真发挥作用
      • 266 6.4.1　让经验教训发挥作用不是一件容易的事
      • 268 6.4.2　扎紧无能之错的篱笆
        • #方法 如何做好经验/教训管理工作？
          • 1.建立内部专利制度。采用正向激励，让提供经验教训的人拿到实实在在的好处。这是最关键的措施。
            • （1）追加案例前查重。在新项目实施和相关评审环节，项目团队必须提交经验教训检查表，确保案例库中的经验教训及其应对措施得以落实。
            • （2）将经验教训使用作为质量控制（quality control，QC）的检查项。作为项目质量工作的一项内容，QC部门将按照经验教训总结表对方案进行检查。
          • 2.优化现有案例库
            • （1）案例库瘦身。
            • （2）简化案例描述。
            • （3）对案例按逻辑分类。
• 第三部分 | 成为卓有成效的项目管理者
  • 272 第7章　好的项目管理者为何如此稀缺
    • 273 7.1　智商–情商矩阵
      • 275 7.1.1　成长路径
      • 279 7.1.2　十年磨一剑
    • 280 7.2　选错人注定是一个悲剧
      • 280 7.2.1　技术专家型管理者未必有更多优势
      • 282 7.2.2　项目管理者应该了解多少技术
      • 283 7.2.3　非技术背景管理者如何管理技术团队
    • 288 7.3　项目管理者的能力素质
      • 289 7.3.1　和谐的人际关系能力
      • 291 7.3.2　系统思考的能力
      • 291 7.3.3　换位思考的沟通能力
      • 291 7.3.4　管理自己、影响他人的领导力
  • 293 第8章　打造面向业务的系统化思维
    • 293 8.1　系统复杂性与思维的局限
      • 294 8.1.1　机械性思维的局限（相对于系统性思维）
        • #案例 为一个延误的项目增加人员，将导致更多的延误。（牛人在“救火”，项目经理在“帮忙”，但都没有采取任何措施来预防未来的火灾。）
          • 技术牛人杜鑫负责的负压检测子系统工作进度落后，在项目经理江峰的协调下，杜鑫同意加班以赶上原定计划。经过连续两周每天12小时的努力工作，终于有所进展。糟糕的是，一个月以后负压检测子系统暴露出越来越多的错误，杜鑫不得不花时间纠正错误。他完成的工作量也开始有所下降，而且情况正在恶化。既然加班不能解决问题，江峰决定采取行动。他说服老板增加资源，让另一个人加入了负压检测子系统工作。更糟糕的是，二人完成的工作量只相当于杜鑫一人单独完成的工作量，并且出现了更多的错误。江峰找杜鑫了解情况。杜鑫说：“你给我找来的人对工作不了解。我花了三天时间让他了解情况。后来，我发现他犯了很多错误，不得不帮他纠正。我还要加班培训他……还不如没有人帮忙！”你有没有似曾相识的感觉？
        • #观点 机械性思维的特点：
          • （1）关注的焦点在于事物的内部、构成元素以及这些元素之间的关联关系。
          • （2）认为系统整体的最优来源于各个局部的最优。
      • 296 8.1.2　最高明的医生善治“未病之病”
      • 299 8.1.3　系统的关键在于相互作用
        • #案例 如何用系统性思维解决问题
          • 机械性思维：按照见招拆招的机械性思维方式寻找高犯罪率问题的解决方案，一般可以形成三种做法。（1）惩奸除恶，形成对罪犯的高压态势。（2）政府进行干预，加强枪支器械管制等治安管控手段。（3）对潜在的罪犯进行教育。
          • 系统性思维：堕胎合法化；
    • 301 8.2　提高问题的认知层次
      • 302 8.2.1　博士和农民工的PK
        • #观点 认知世界可以分为4个层次（以项目经理救火为例）
          • 反应层：救火
          • 模式层：培训新员工，解决问题
          • 系统结构层：开始面向未来，找到预防出问题的方法
          • 共同愿景层：创建新模式，替代旧模式
        • #案例 某企业引进了一条香皂包装生产线，结果发现经常有空盒流过。厂长请了一个博士花了200万元设计了一套自动分拣系统。一乡镇企业遇到同样问题，农民工花90元买了一台大电风扇放在生产线旁，有空盒经过便被吹走。
          • 博士和农民工的解决方案，层次不同，不具备可比性。
      • 303 8.2.2　系统思维解决问题的方法
      • 305 8.2.3　牧场效应与囚徒困境
    • 306 8.3　提升效率的关键在于综合优化
      • 306 8.3.1　寻找复杂系统的平衡
      • 309 8.3.2　提升效率的关键在于综合优化
      • 310 8.3.3　N维系统中的问题在N+1维系统中解决
    • 311 8.4　艰难的选择
      • 312 8.4.1　短期高效与体系效率孰重孰轻
      • 313 8.4.2　见长效还是短平快
  • 314 第9章　极简项目管理，说起来容易做起来难
    • 314 9.1　站着说话不腰疼
      • 315 9.1.1　似曾相识的场景
      • 317 9.1.2　专家与初学者的思维方式的不同
    • 317 9.2　说起来容易做起来难，做起来容易说起来也难
      • 318 9.2.1　陈述性知识与程序性知识
        • #知识 陈述性知识 & 程序性知识
          • 陈述性知识：主要是用来说明事物的性质、特征和状态，用于区分和辨别事物（介绍京东商城是做什么的是陈述性知识）
          • 程序性知识：是一套办事的操作步骤，是关于“怎么办”的知识。程序性知识具有动态的性质，主要是行动，而不是记忆。（在京东商城购买一本书是程序性知识）
        • #观点 如何才能把程序性知识传递给其他人呢？答案是：专家必须想办法将程序性知识转化成陈述性知识说出来，而学习者必须要把陈述性知识转化成程序性知识来练习。
      • 319 9.2.2　知识传递的困境
    • 321 9.3　仅阅读本书不能保证做好项目
      • 321 9.3.1　成长与知识金字塔
      • 323 9.3.2　学习陈述性知识的必要性
        • #观点 陈述性知识便于理解和学习，但是要转化成自己的程序性知识，必须通过不断的实践练习和反思