极简项目管理

很多的事情都可以当做一次项目管理，只要我们能够梳理好过程当中的细节，把控好方向，最终的结果一定不会太差。正所谓谋定后动。 希望我们人生的道路上成功与预期的结果相伴。细节计划管控逻辑思维一路同行。括号我们每个人自己的人生。 减少不必要的消耗与心力的付出。拥抱更美好的明天。

极简项目管理

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