项目管理之美经典读后感10篇
《项目管理之美》读后感(一)：继续实践
原谅我，这本书都是在电脑上翻得PDF，有好多截图直接保留在印象笔记里了，不然我是怎么都看不下去的啊。
本书的作者Scott berkun在工作之余撰写了多本书籍，其实在写作的过程中也是对自己工作的不断回顾和总结，也是对思路的一种梳理。而且在商界有经验的人到大学任教是非常合适的，这比纯学院派的老师更加实战，也能教会学生更实际的东西。
作者从古埃及建造金字塔、到旧出版社运行机制等等的思考，用以参考怎么将自己的工作做到最好。
同时提出，要重视失败的经验的积累，避免同样的错误，审视错误的假设。
在写作中作者提到专业的厨房，这让我想起在《麦克白》电影中的 餐厅，多从高专业角度的地方审视观察，以得到更广的思考角度，跳出目前的思维方框。
第一章20页提出一个很好的问题，就是流程和目标不要混淆，作为项目跟进人，如果仅仅是每周关注在好看的图表和报表上，那么不久之后，PM容易相信流程就是项目，那么他们就会挑一些容易做的事情，而不是重要而且有挑战的事情。某种程度上，他们会想，我们完成列表上的事情我们的项目就成功了。
这也是我们目前遇到的问题。
但是这个问题怎么解决呢？
最近跟进项目也有点流于形式了，搜集大家的报告很简单，仅仅有个漂亮的报表也很简单，我想走出办公室，多和在实践的同事们交流交流，去敞开怀抱、思想去交流学习，了解工作实际的状态。
我在等什么呢，如果上级没有提出让我这样做，我也可以试试这样做吧。
很值得提出的是，这本书每个章节在启发完大家之后，都有10-20个切合实际的、直指问题的思考题，还有实践题，大家可以以本书为参照，实践其中的题目，我想不管是对个人，还是对项目团队，都是非常的成长指引吧。
《项目管理之美》读后感(二)：只看了50页我就决定力荐这本书
看到这本书，是在china-pub的计算机类的软件工程销售排名中，我一直以这个排名做为标准来选择软件工程类的书籍，所买的书，都让我非常满意，这次也不例外，虽然我只看了50页。
这本书是The Art of Project Management《项目管理的艺术》的第2版。
在头50页中，几乎每页都有收获，有很多是於我心有戚戚焉，还有一些让我如醍醐灌顶般，还有一些观点让我意识到我以前做错了。
我决定摘取一些前50页，我做过标注的部分让大家参考：
1、项目经理的平衡。怎么处理自我/无我，独裁/委派，忍受模糊/最求精确，口头/书面，承认复杂/拥护简单，不耐烦/有耐心，勇气/恐惧，相信/怀疑的关系。几乎每一项都是我经历过或者正在经历的。
2、流程与目标。这一节涉及到目标管理和过程管理的关系。没有过程的项目是不正常，而强调过程管理而忽视目标管理是错误的。很多PM不会出现前一种不正常，但是常常会犯后一种错误。说白了，就是过程管理必须能有利于实现目标，而不要官僚。
3、适度参与。这一节我的理解与独裁和委派很类似。很多PM是从程序员走过来的，这一特点决定了他喜欢拘泥于细节，喜欢自己亲自担任核心的工作，实际上，对于10人以上的项目来说，这是非常危险的，因为PM都去写代码去了，谁来促进团队更好工作，谁来监控进度、质量、防范风险呢？
4、对于进度表的估计。书中列出了很多容易疏忽的问题，如：
是否考虑到了生病、事假、度假？（可以在计划的后期设置一些缓冲的时间，比如安排大家写文档等可做可不做的工作）
是否考虑到了节假日？（中国一般十一、春节之类前后工作效率是很低的）
每个人是否都能看到进度表，是否需要汇报进度？
是否有人每天检查进度表？这个人是否有调整的权利？（PM的职责）
团队是否对进度表有拥有感和承诺感？（让大家同意这个计划，并让他们对他们的承诺负责）
团队成员是否对玩不成的计划，可以说“不”？（非常重要）
计划表是否每个里程碑都要审查和调整？
是否团队成员的经验和训练水平？（如果是新手，时间要长一些）
这些问题都是很重要的问题，也都是我遇到过的问题。
软件产品研发的所有管理岗位的同学，都值得看。
《项目管理之美》读后感(三)：一些笔记
项目管理简史
保持初学者之心，更有机会进步
项目管理可以是工作、角色或活动
流程应支持团队，而不是以其他方式影响团队
规划
进度表
进度表的三个目的：对什么时候完成任务的承诺；鼓励每个人把自己的工作看作整体的一部分；追踪项目，分解工作
进度表三分法：设计、实现、测试；
分而治之：大进度表=许多小进度表，以最小化风险，同时便于增加调整的频率
越早估算进度表，误差越大
进度是一种几率，故进度表无需完美
好的估算来自于好的设计和需求，低质量的估算没有错，但不要将其余高质量估算相混淆
滚雪球效应：熵无处不在
以怀疑而非乐观的态度来制定进度表
如何知道该做什么
不同类型的项目：单个超人；小型合同团队；大型员工团队
组织如何影响规划：任何时候都要了解：谁分别对需求、设计、技术、预算授权？
常见规划产物： 市场需求文档（MRD）、远景/范围文档、规格说明书、WBS
规划的三种视角：业务视角、技术视角、客户视角
客户研究：小组调查、问卷调查、站立参观、可用性研究、市场研究
问题陈述：代表世界当前的状态，应该转换成功能陈述或场景，两者是沟通需求的简单方法
编写好的远景文档
远景文档把其他规划材料提炼唯一的、高层次的规划
好的远景是简单、目标驱动、统一、激励人心和容易记住的
想法从何而来
设计是介于早期规划和完成的规格说明书之间的神秘过程
编写高质量需求：要对需求协商和迭代做好计划；找出错误的假设；找出遗漏的信息；为每项需求定义相对优先级；改正模糊语言
设计的探索：问题空间不断增长，然后最终会缩小，设计与需求之间需要反馈回路
设计的过程不要害怕探索
存在不好的想法，多数的设计都不会获得成功
好的问题会带来好想法：焦点问题（好）、创意问题（不错）、夸张问题（不好）
不好的想法能够引出好的想法
好设计来自于众多的好想法
走出特定的领域，才能有更多的进步
激发想法的即兴规则：是的，而且；没有不好的；不能阻挠问题；无需记录谁说了什么
客户体验是设计想法的最佳起点
经过不同专业人员的多次交流后，想法就可以发展成为设计
有了想法之后做什么
问题空间必须在转折点处缩小
设计阶段的检查点：远景和概念论证—>想法分组/列表—>3个可选方案—>两个可选方案—>一个设计—>规格说明书，在完成远景文件的同时，定义这些检查点
用亲和图进行想法分组
原型的迭代与评估：
早期
晚期
开放问题列表需要进行管理，每个问题都要有人负责，在完成规格说明书之前需要解决
技巧
撰写优秀的规格说明书
规格说明书应该做到三件事情：确保构建正确的事情、提供总觉项目计划阶段的进度里程碑、在项目采取的方法上能够让不同的个体做深度评审和反馈
规格说明书的内容：需求、功能、技术规范、工作项目列表、测试标准以及里程碑退出标准
规格说明书不是设计：停止探索和创造，集中精力表达和说明
只要去问，就会比只是等待而更容易获得良好的反馈
确保正确的事情会发生：当世界改变时，规格说明书就应该更新
不要等到正式评审流程开始才去获得反馈信息，评审是用来提炼的，不是为了做好第一次和最终的确定
评审目标，回答两个问题：是否足够详细指引开发，结果会否满足项目的需求和目标？
要求会议之前先阅读规格说明书
如何制定好的决策
做决策的第一步就是决定手边这个决策的重要性（元决策）：什么问题是决策的核心；决策影响的时间、深度、成本，哪些决策会连带收到影响；机会之窗在哪里；以前作过这种决策吗；是否有人具有专家观点；需要谁的批准
做决策的基本方法：单项评估和比较评估
单项评估适用与解法之间区别不大的情况（无差异地带），能节省时间
想要说服他人或者想让他们参与决策过程，比较评估就是最佳架构
比较的简单方法：优缺点列表
信息和数据不能做决策
要提高决策技巧，需要做两件事：首先必须做决策，其次要专注于决策的结果（做回顾）
沟通和人际关系
人际关系能强化沟通
沟通的5种基本状态：传达、收到、理解、同意、转换成有用的行动
常见的沟通问题：假设、不够明确、没有倾听、独裁、问题错配、个人/人身攻击、嘲讽、奚落和指责
定义角色是改善人际关系的最简单方法：讨论哪些项目是由谁负责
问一个简单的问题：“我要怎么做才能帮助你们做出最好的工作？”
如何让人最佳工作：遵照建议、挑战/提出要求、鼓舞、清楚路障、提醒他们各自的角色、提醒他们项目的目标、教导、直接请求
流程、电子邮件和会议
人们被激怒的原因：假设我是白痴、不信任我、浪费我的时间、对我不尊重、让我听写蠢事
建立好的流程需要了解两件事：通常能让项目和团队成功的事项，和是当前项目和团队与其他有所不同的事项
建立或改进流程的检查列表：加速事情的进展、防止问题、让重要形同可见和可测量、包括修改或删除此流程的流程、受到影响的人会赞同
建立流程并付诸实践：找出项目可独立的低风险部分来实验这个新的流程，为它们制定测量标准，评估并修改，在应用到较大的小组中
遇到不同意的流程：替你的团队挡开流程、打赌不适合流程、忽视流程
好的电子邮件：要明确、简单和直接；提出行动和截止期限；优先级；不要假设人们会读所有的东西；避免太详细；隔离FYI邮件；电话是你的朋友
会议促进指标：建立主人的地位：制造权威感；倾听和反馈：帮助他人发展完整的想法，试试重复他人说话内容的反映技巧；引导会谈：把讨论推回必要的正规；结束会谈：确认问题，找出由谁负责，要求那个人自己进行；制造历史：花时间记录讨论内容
事情出错时做什么
如何处理困难情况：冷静下来；评估问题和项目之间的关系：决定优先级；再次冷静下来；让对的人出现在房间内；探讨替代方案；做出最简单的计划；执行；听取汇报
何为困难情况：现实和当前计划之间有很大的差距；对差距在哪、原因何在、谁负责解决它、是否存在这些问题感到困惑；对如何应用资源来解决差距还不明确
一些常见情况可以预期，包括疏忽、被迫做蠢事、资源短缺、低质量、方向改变、人事问题以及叛乱的威胁
艰难时期是学习的机会，确保花时间检查发生了什么事以及应该如何避免发生
对某件事情负起责任并不会让它变成你的错，只表示你对解决这种状况负责；某些状况下，放手你的责任
极端情况下，要进入损害控制模式。采取任何能做的事，使项目进入已知而稳定的状态
冲突解决和谈判：找出一致点；找出个性冲突，然后忽视他们；寻找共同的利益；刚中带柔；了解替代方案（BATNA）；使用说服力和论据
每个人都应该知道决策者是谁
在压力增高时，效能也跟着提高，但随着时间的推移，这种关系会减弱，当超过极限后事情会变得更糟
对感觉的感觉：应察觉自己和其他人的情绪并加以管理
具有英雄情节的人，可能会让项目处于风险中
管理
领导力和信任
要成为一名好领导，要学会如何发现、建立、赢得信任和信任他人、信任自己
信任通过承诺而建立，因为不一致的行为而失去
权力的两种类型：不要依赖授予型权力，努力去争取挣得型权力；说服比发号实例更有力，但必要时独裁专制
利用授权建立你对团队的信任
从自己开始树立榜样
批评时对事不对人
问题出现是从不当场指责，待问题解决后才寻找问题原因
如何让事情发生
优先级让事情发生：目标序列表—>功能序列表—>工作项目序列表
学会说不：不符合我们的优先级；除非我们有时间；除非你让（某件不可能的事情）发生；下一版再说；绝不，永不，真的
保持真实：真相越早暴露在阳光下，就能越早做些什么，必要时质疑他们
要有关键路径的意识
坚持不懈：不轻易放弃，不为了避免冲突而放弃，必须质疑众人、挑战假设及寻找真相，提问是质疑的最佳方式
要机智地工作并评估环境
游击战术：知道谁有权限，不要浪费时间和对问题没有影响力的人争论；找到信息的源头；沟通不起作用，就转换模式；与人独处；追踪众人，要有礼貌，但要追逐活的你要的东西；需要不被干扰的时候隐藏起来；获得建议，问别人问题；呼喊帮助、请求和贿赂；让人们彼此对立；码好牌，要知道会议室里重要人物的观点；请人喝咖啡和品尝美食
中盘战略
优秀的项目管理，大多是先走在项目前面一两步，开始就避免不稳定的情况
中盘和终盘阶段对应与项目的中期和后期部分
如果任何时候项目进展不顺利，要找出哪里出了问题并解决它们
项目是负责的非线性系统，并且有很大的惯性，如果等到发现严重的问题是才采取行动就太晚了
检查健康状态，准备问题列表，每天问一次战术问题，每周问一次战略问题，对团队进行公开透明的工作进展评价
掌握领先的战术问题：我们的目标和承诺是什么，现在仍然准确吗？我们今天做的事对目标有贡献吗？工作项目不仅是否完成，而且完成的方式也满足需要和使用场景吗？
掌握领先的战略问题：成功满足下个交付日期的概率是多少？提高这个概率需要哪些调整？最大或最可能的风险是什么？世界可能怎么改变？
三件重要的事情：当落后的时候要知道自己落后了；看到别人落后要提供自己的支持；不要犹豫去争取同时或上级的帮助
采取安全的行动：进展得越多，调整的成本越高；
编码管道是实现任务时，如何管理工作项目
完成每一项进度表里的工作项目，中盘阶段才结束，使用工作项目列表来追踪进度
方向越容易改变，里程碑的长度就越短
计划是赢覆盖所能支撑的变化
变化控制（DCR）：PM写下变动摘要—>所有受影响的人同意并参与—>交由审核
终盘战略
竭力赶上上一个日期的代价，就是让赶上下个日期的概率降低
里程碑内，有些关键期限应该追踪、锁定并给出退出标准：设计完成/规格说明书完成；功能完成；测试或里程碑完成
退出标准包括：需要完成的工作项目列表；必须完成的工作的质量定义；实际上完不成也可以的事项列表；不需要完成的事情
弥补进度差距的方式：改变进度表，把截止日期往后推；改变角度，让团队加快工作；竭尽全力赶上日期，砍掉功能或降低质量
每日构建
ug应该包括的信息：优先级、严重性、分配、再现、区域、公开者、状态、解决方法、类型、分类、标题
根据bug活动图评价趋势
需要各种控制来完成项目层次的调整：查看会议、bug分类和作战团队
项目完成后，要进入事后分析流程
政治与权力
不同的权力：奖励、高压、知识、关联、影响力
滥用权力，把精力花在对自己最有利的事情，而不是对项目整体最有利的事情上，个人动机必须和项目结合起来
导致滥用权力的因素：流程因素和动机因素
流程因素：决策过程不清晰、误解/沟通不畅、资源分配不清晰、缺少责任、不稳定和无效的目标
动机因素：保护他人、自私自利、自我、厌恶/报复