《极简项目管理》读书笔记
2021-07-07 21:39:13 1 举报AI智能生成
如何解决中小企业和创业团队的项目问题是本书的着眼点，书中给出了中小企业和创业团队实施项目的关键步骤和行动策略。全书共3部分：第1部分介绍项目管理的基础知识。第2部分是实施极简项目管理的五大过程，这也是全书的重点。为方便项目的实施和落地，这些过程被进一步分解为19个步骤，即极简项目管理地图。第3部分着眼于项目管理者的成长问题。
作者其他创作
大纲/内容
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 避免吃二遍苦、受二茬罪
#方法 以项目后评估为契机，用结构化方法确保经验教训总结的有效性
#方法 使用递增式方法管理文档
准备一份包含所有最终文档的提纲，并将此提纲放在每个团队成员的工作任务书里。然后，在项目过程中，当每一项关键任务完成时，都要求相应团队成员提供与任务相关的几句、几段或几页文档，然后将这些片段插入提纲内适当的位置。我把这种方法称为“递增式文档”。“递增式文档”操作起来相对不那么“痛苦”，为最终文档的完成提供了好方法。
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 学习陈述性知识的必要性
#观点 陈述性知识便于理解和学习，但是要转化成自己的程序性知识，必须通过不断的实践练习和反思
作品目录
前言
创业公司也适用的极简项目管理法
第一部分：认识项目管理
第1章 极简项目管理基础
第二部分：极简项目管理过程
第2章 启动：师出有名，名正言顺
第3章 规划：运筹帷幄，决胜千里
第4章 执行：依计而行，行必结果
第5章 监控：审时度势，沉着应变
第6章 收尾：慎终如始，好戏杀青
第三部分 成为卓有成效的项目管理者
第7章 好的项目管理者为何如此稀缺
第8章 打造面向业务的系统化思维
第9章 极简项目管理，说起来容易做起来难
附录
附录A 赋予逻辑意义的数字
附录B 一个大型学术会议的WBS
附录C 一个办公室装修的WBS
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 表明正式开始的项目启动会
#观点 省略了项目启动会的项目，其过程往往很混乱，很多人对项目的配合不够，协同性很差，项目目标也就无法按计划实现。
#观点 如果可能，要大张旗鼓，千万不要像鬼子进村——“悄悄地来，悄悄地走”。
#方法 为了完美地启动项目，建议用结构化方法实施项目启动会。
启动会议10问
启动会议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公司财务部经理黄兴拿到该项目的数据，向公司总经理高静汇报：该项目运行得不错——费用节约了！
129 3.4.2 抓住项目预算的关键
131 3.5 估风险：不信邪就会中邪
132 3.5.1 优秀的管理者不是善于冒险，而是善于控制风险
#观点 优秀的管理者不是善于冒险，而是善于控制风险
133 3.5.2 风险管理在国内的困境
#观点 风险管理的悖论：如果风险管理很好，风险就不会发生，可是风险不发生怎么证明是因为风险管理得好呢？
135 3.5.3 分析风险的概率和影响
#方法 做好对已知风险的管理，在识别后，我们需要以下数据进行风险分析。
（1）风险事件发生的概率。（2）风险真的发生后，可能产生的后果的范围与影响。（3）每个结果的可能性。
#方法 通常首先查询风险的影响评级，然后查询概率影响矩阵，来评估每个风险的重要性和所需的关注优先级。
0 条评论
下一页
为你推荐
查看更多
