《项目经理应该知道的97件事》是一本由戴维斯 编著作，邮电出版的平装图书，本书定价：39.00元，页数：216，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《项目经理应该知道的97件事》读后感(一)：项目经理应该知道的97件事
《项目经理应该知道的97件事》是集体智慧的结晶，是来自世界各地的具有成功项目管理经验的项目经理、软件人员和其他职业领域的专家集体创作的。书中，这个领域里活跃分子分享了他们多年来积累的经验和秘诀，作者将诸多成功项目经理的经验提炼为97个方法，读者可以随意捡起其中一个急需的方法。
《项目经理应该知道的97件事》是一本项目经理的实战宝典，项目人员、软件经理等项目相关人员也能从中获得有益的指导。
《项目经理应该知道的97件事》读后感(二)：所谓激发团队士气
项目经理主要职责之一，创造一个良好的工作环境，激发团队士气。
一些技巧：
1.对团队在项目发展方向上加以控制。跟团队交流频繁吗？经常征询他们的意见吗？有人会提议或向你抱怨吗？有人会觉得你会因为他们的提议或者抱怨做成改变吗？
2.保护成员免受“官僚制”的影响。当公司出台禁止办公桌装饰的规章是，你会据理力争，保护李××能在办公室展示他收集的魔方吗？即使失败，团队士气也会受益。
3.想办法改善工作环境。为团队成员去争取。
4.让团队成员感觉他们的确像一个团队。团队设立一个每周最佳队员奖，并每周在团队会议上轮换。吴××可能会说：我将奖给玛丽，因为她周四工作到很晚，虽然我给他的文件已经是下班后，但她加班完成了，保证了我们周五完成了迭代。下一次，玛丽将会指出另一名队员的贡献，并把奖项授予他。
5.保持工作和生活间的协调关系。可以偶尔要求加班，但如果你打算从人们的生活中占用时间，需要日后把时间还回去。
6.确保团队成员看到你做出的努力。他们往往不信任一个总是藏在门后的经历，也很容易跟随那些有目共睹在为团队争取利益的人。
《项目经理应该知道的97件事》读后感(三)：中规中矩
97篇短文，基本上两类：
1. 一类是，告诉你应该如何看待项目管理中的一些事情。什么是重要的，什么应该被重视。
2. 一类是工具，就一些具体问题，提供行之有效的操作备忘录指导。
整体可打4星。适合作为手册，遇到问题时查阅。97 things 系列图书一贯两份目录，一是正常按篇目顺序，一是按技巧分类。
优点：
短小。每篇都在两页篇幅内完成，一目十行的朋友分分钟可看完。
多人参与。53位撰稿人97篇文章，每人分享了自己的观点和经验，覆盖了项目管理的方方面面。
缺点：
短小。很多话题浅尝辄止，点到的那一下似乎又没点到点子上，或者说刚挠到地方，但还没止痒。
多人参与。文章质量高低不齐，有人善于表达，有理有据说得清楚，有人可能差点儿劲。
这本书每一篇英文原版都已经基于Creative Commons, Attribution 3在网上公开，地址是：http://pm.97things.oreilly.com/wiki/index.php/M网友n_Page。使用时必须指出文章的出处和作者。
问题几处：
12页、44页、61页都有“迭代”或“迭代周期”的注释，三处注释基本一样。只保留第一处就可以了吧。
50页，原文“This is a perfect space to centralize access to working documents and dom网友n artifacts which can be accessed from multiple locations.”，译文“他需要能够进入工作文件和从多个位置访问领域制品的集中入口。”有点儿欠准确。
126页，2009年1月15日，原文是January 15th, 2008。
《项目经理应该知道的97件事》读后感(四)：千万别觉得自己很牛逼
刚来这家创业公司工作时，公司的产品都是几个刚毕业的学生，主管也是很沉闷的一个人，沟通少，以至于交付的工作往往达不到其他门的要求。运营就是吐槽声最大的门之一，而我就是主力，虽然都是自己对自己吐槽，但是深知吐槽改变不了任何事情。所以我作为一个运营，居然也担起了产品规划和原型制作的工作。你要说我抢别人的猴子，那我也认了。读完这本书，针对我个人，印象最深的还是这四点：
——招一个人才，而不是技能
我把门岗位要求都写得非常详细，以至于有朋友向我反映说“你们公司的要求真高啊!”我一笑带过，但事实上作为面试者面试应聘者的时候我都没有针对性的问“某个问题出现后你会怎么解决？”类似的具体答案，常常是不必要到这一步，素质礼仪就让我觉得就不过关。唯一我说出“公司希望招一个人才，而不是技能”这句话的时候，是一个内容主管，他已经30出头，能从表情和举止看出来他对这句话的认同感，但是很可惜，最后他仍然没来。
一家公司，想找到的到底是什么样的人才？专业知识过硬其中一个考量的维度，而不是全。任何专业知识，只要肯花精力去学，大多都能掌握，可是一些做人的基本品德，已经潜移默化几十年，确实很难再改变的。所以我们需要应聘者所具备的优良技能不过是在幼儿园里就开始培养的：你能和他人融洽相处吗？能主动合作吗？当完成任务后，会把自己的工作整理以做备用吗？会对新事物感到兴奋吗？喜欢学吗？
——鼓励加快进度，而不是鼓励更多加班
“加班≠高效率”是我一直认同的职场观点，而奉行加班文化的公司一直是我不齿的公司文化之一。虽然在某些紧急时刻，某产品被催促上线，某大型活动的预热开展，都避免不了加班，但你一定要记住，始终把效率放在第一位，而不是攀比加班的时间。
如果组员经常比我下班还晚，我会单独发消息问问他们，是不是因为工作上的事情太多，忙不过。如果答案是否定的，那没什么关系，但是如果是肯定的，那么作为管理者，你就要好好找找团队目前出现的问题，到底是组员个人的工作效率不行？还是真的负担太重？如果是效率不行，你要亲子观察或安排他人留意她每天的工作行为和惯，帮助他解决效率低下的问题。如果真的是负担太重，作为管理者你就需要反思，为什么会出现这种情况？是否错估了该员工的工作能力？以及如何解决它。
掌握一个人的工作细节，而不是只看重最终的花费时间。
——立项5步
任何一个项目之前，一定要先厘清步骤，分别有这5步：
1）启动-捕捉好点子，共同商议，是否可行，如果可行就立项并确定项目负责人
2）计划-针对项目的初期方案，如何规划？背景+调研+预算+结果分析...
3）执行-针对目标进行分工，细分平台和责任人，然后具体施行
4）监控-在计划推近的过程中，如有和项目预期不一样的地方要进行实时反馈并记录，是哪个分出了问题，具体责任人是谁？
5）总结-为项目实施难点写点评，并将项目过程中的所有文件归档[excel+word+...]
任何方案按照这5个基本步骤去走，肯定没问题，难就难在作为团队能不能为项目负责人提供资源及权利支持，以及最后数据的分析及总结成功，一头一尾，多加修炼。
——“非我发明不可”综合症
别觉得自己是最牛逼的，看见什么都觉得不如自己做得好，觉得是个颠覆者，什么都想推翻重来，还号称自己是“完美主义者”，互联网时代，完美的产品都不完美，有现行的解决方案就别瞎鼓捣。具体的改进方法我也没有，只能一步步来，因为我就是这样的人。o(╯□╰)o
《项目经理应该知道的97件事》读后感(五)：都是高手们的经验之谈
http://kaverjody.com/97_things_pm_should_know_reading/
起源于Larry的一篇微博，我对这本书有些感兴趣并决定提高优先级先读一读。亚马逊上的英文原版评价三星半，豆瓣上中文版评价7.6分。英文原版在O’Reilly的网站上以Creative Commons 3协议分享出来，大家可以免费看；中文版么，@图灵郭志敏之前发过微博分享迷你书，然后，译言上似乎也有翻译小组翻译了一分。
《项目经理应该知道的97件事》阅读笔记
总体来说，个人感觉亚马逊和豆瓣上的评分比较真实地反映了这本书，IT职场的老油条看起来可能都会觉得有点初级或小儿科，但我想对于一些刚刚走上项目经理职位的朋友们，还是很值得一看的。当然，我自己并未亲身经历项目经理的角色，也有可能是我并未对某些分感同身受。书中的文章偏重经验的介绍和分享，类似于技巧、诀窍之类的文章，所以，整本书并没有一个所谓的线索或主线，也并非一个完整的知识体系。
个人比较喜欢的篇章包括：
尽早让用户参与：这也是Standish Group的CHAOS调查中，多年来都位列首位的原则“User Involvement”。
避免打地鼠式：关注可延续性的速度，这也是敏捷原则所要求的。
为团队增添人才而非技能：他们是“人”不是“资源”，不要只关注完成“项目目标”需要的“能力”，还要关注承载这些“能力”的“人”。
优秀与普通的天壤之别：讲过很多次的东西，优秀和普通工程师的差距，以及人数增长带来的沟通压力。
矛盾体的需求说明书：要将用户需求和系统功能规格说明进行区隔。
授权-蒂姆的故事：这让我回想起以前有段时间不被理解的日子，因为我的思维超越了救火队员的模式，更期望从“预防”的角度做事，而不被理解，也被认为绩效欠佳，令我非常不爽。千里马还需伯乐，太对了。
遭遇敌人……敌人就是我们自己：软件团队的成员们一定非常高兴有人愿意理解他们，只是，我在想，如果他们需要理解这么多人才能开始工作，那么。。。是否需要他们呢。。。
艾丽丝不是美国人了：多站点、多时区、多语言的项目群体，绝对是软件的巨大挑战，敏捷社区多数人对此的解决办法是“Don’t Do It”。
要现在不要马上：“快速的成功仅仅比迟来的成功好上倍，但快速失败可比迟来的失败要好上百万倍。”
速度就是生命，越快越好：“科学研究证明，对于特定的行动、战术和表现形态而言，具有优势的是最佳速度，而非超常速度。”，我感觉这篇文章很贴合我在今年敏捷上的演讲主题《速度——敏捷的丹田之气》。
做实际工作的人才是最好的估算人员：让干活的人来估计，这才是王道。所以Scrum里说团队应该享有决定自己能做多少的权利。
状态的假象：这就是敏捷原则中所说的“可工作的软件是进度的首要度量标准。”
不要总是扮演信使、你没有控制住、分享观点、善于支持的组织就能获得成功：他们和我之前微博中提到的“全景”、“透明”的问题很相关，参考http://weibo.com/1408827293/xkbABxFd5、http://weibo.com/1408827293/xkbIFvuKi、http://weibo.com/1408827293/xkc6PrRjb。
==========
徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。
