《项目管理修炼之道》书评

很好的书

间隔了半年，每次都是读了前八章的样子很好的书，没有项目管理经验的缘故无法产生太深的共鸣，真是遗憾...继续收起来，等待下一个半年~呵呵

这本书对项目管理很实用

整本书总结得很不错，对每个管理环节都描述得很具体，其中还介绍了一些管理工具和技巧，很实用！比起PMBOK这种记流水账的要好上很多！抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了抱歉，你的评论太短了

第一章 项目启动

每个项目启动时都要有章程。对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。要知道"质量"的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。温伯格这样说："质量，就是对于某人的价值。"[Wei92]这个定义也就意味着可以为项目产品添加新功能，并可查看一个功能吸引（或排斥）了多少个（以及什么样的）"某人"。

实际的问题，不太实际的解决方法

本来想把自己的读书笔记都贴上来的，后来发现这里不支持列表，也不支持表格，而且发布了就不能删除，于是便懒了，还是用有道笔记记吧。书不错，前面好于后面。提出的问题都很实际，都很具有代表性，所以读起来觉得非常心有戚戚焉，可惜的是，没有提出什么真正切实可行的解决方案来。是啊，这种管理问题的确很难有非常明确的解决方法，强人所难了吗？可是，我们读书，不就是为了找到解决方法吗？我们不需要更多的同命相怜者。希望随着自己经验的不断积累，能够对本书有更进一步的理解

第五章 项目生命周期的估算

提示：项目日程并非一成不变日程安排是由整个项目团队共同制订完成的，所以每个人都对日程有信心。可是"天有不测风云"，总会发生点儿意外。别担心。项目日程是团队当前对于项目工作会如何展开的估计。随着时间的推移，意外情况发生了，通常在日程"完成"一到两天之后，最初的日程就变成明日黄花了。这就是我为什么只做足够的时间计划，而且会使用波浪式规划，这样我就可以随着环境变化很容易地更新日程安排。

第五章 项目生命周期的估算

提示：项目日程并非一成不变日程安排是由整个项目团队共同制订完成的，所以每个人都对日程有信心。可是"天有不测风云"，总会发生点儿意外。别担心。项目日程是团队当前对于项目工作会如何展开的估计。随着时间的推移，意外情况发生了，通常在日程"完成"一到两天之后，最初的日程就变成明日黄花了。这就是我为什么只做足够的时间计划，而且会使用波浪式规划，这样我就可以随着环境变化很容易地更新日程安排。

实践是检验真理的唯一标准

本人就是学软件工程与管理出身，关于项目管理，一些书很理论，但并不实用。一本好的项目管理的书，并不好写。一方面要深入浅出，另一方面要一针见血。而这本书做到了。一看就是经过了一定的历练后的经验总结。由于写了一些笔记，具体就不说了。

好书一本

我只看了一章，结合目前进展的项目进行总结已经觉得受益匪浅。JR女士语言简练，直指问题核心，把项目管理这个看似复杂纠结的工作抽丝剥茧般理的清清楚楚。正如该书推荐的一样，无论是对于项目管理的老兵还是新晋菜鸟来说，这都是值得一读的好书。此外一楼lance根据书本内容整理出的项目管理检索图用来温故知新也是非常方便的，在此感谢一个。

实践敏捷研发的工具书

此书的一大特点是好用，好懂！可以作为日常敏捷的工具书。此书没有讲敏捷的深奥理论，但是给出如何实践敏捷的最佳方式，同时对这些方式进行了理论的分析，教会团队如何有效实践敏捷开发。此书是敏捷开发实践的上等工具好书。

越读到后面越觉得理论化，后来就舍弃了。

特地从妹妹学校的图书馆借来的这本书，刚开始读的还有些味道，自己的感想与作者有些不谋而合。越读到后面越觉得理论化，有些背离了实际，开始有了“怀疑精神”，后来慢慢的就舍弃了。总体而言，这本书可能比较适合刚刚想要从事软件项目管理的人员。

实用

这本书最大的特点就是实用，很多内容拿过来就能在我们的项目中直接应用，比方说项目启动时的章程的写法和重要性，比方说估算工作的方式，比方说创建并使用项目仪表板等等。虽然没有谈很多很高深的理论，但同样有深度http://www.cnblogs.com/nuaalfm/archive/2010/05/17/1737464.html

很实用

这本关于IT项目管理的书，比我之前看过的所有关于项目管理的书都要实用。很多方法可以马上应用到实际的工作中，而且是可以起到作用的。花了几天时间浏览了一遍，计划根据书的最有用的内容，摘录下来做成PPT，在公司里面做沙龙培训。

实用之道

和之前看过的一些类似教材的项目管理书籍不同，正如这本书的英文名——“Your Guide to Modern, Pragmatic Project Management”，这本书侧重在实际的、现代的项目管理方法和技巧。（1）实际的。可以立即用于项目管理中的方法，如我看到用即时贴安排项目日程，马上就用在管理的项目中，效果还确实不错；（2）现代的。因为我是在做小型软件项目管理，相比传统的项目管理方法不太适用，新的方法如何具体应用还需进一步考虑。综上，虽然还没看完，但已经是值得从事软件项目管理人士一读的好书。

《项目管理修炼之道》笔记

原文链接: http://blog.log4d.com/2014/08/manage-it/3a1ff193cee606bd1e2ea554a16353ee--------随着团队规模的变大，成员之间合作的模式逐渐由单打独斗变成协作开发。这时候会遇到很多意想不到的问题，项目管理的重要性也就显现出来了。[项目管理修炼之道](http://book.douban.com/subject/4058336/)是一本讲技术类项目管理方法和实践的书。从业者可以从这本书获得了有益的指导。我在 Kindle 上面翻了好几遍，感觉受益匪浅，就把读书笔记拿出来供大家参考。## 1、内容核心内容是项目管理的生命周期和每个阶段的交付物：* 项目章程* 日程规划* 开发（控制节奏）* 结束项目，项目回顾其他内容：* 如何和投资者沟通* 管理会议* 控制项目节奏<!-- more -->## 2、关键字* 项目定义：一个独特的任务或是系统化的流程，其目的是创建新的产品或服务，产品和服务交付完成标志着项目的结束。项目都有风险，并且受制于有限的资源。* 关键（章程）* 驱动因素：功能集合、发布时间、缺陷等级，只能有一个* 约束：环境、流程、人力资源、预算等，决定了规模* 浮动因素* 规划：带有项目发布条件的项目计划* 日程安排：对工作项目的有序描述* 发布条件：S.M.A.R.T.，需要一起协商* 仪表盘* 定性或者定量的方式，将结果公布出来* 保持项目节奏的方法* 快速开发* 持续集成* 自动冒烟测试* 功能拆分和日程排期* 按功能实现，而非架构* 优先实现高价值功能* 通过用户故事、角色和场景来定义需求* 分离需求和 GUI* 质量控制* 复查：Code Review，结对编程* 重构* 项目成员的角色构成* 项目经理* 架构师* 开发人员* 测试人员* 业务分析师* 运维## 3、我的问题和部分解答Q：项目经理的职责是什么？> 监控项目进度，牢记里程碑验收条件。保障项目按需求交付。Q：如何成为优秀的项目经理？项目经理需要下面这些技能：> * 倾听> * 谈判技巧> * 协作和表达技能> * 目标导向> * 真诚，尊重> * 信息不足下进行决策能力> * 解决问题的技巧> * 发现问题能力>> * 理解产品的生命周期> * 认识自己技术的不足> * 能够安排日程> * 能够估算任务，并指导其他人完成任务估算> * 指导如何管理风险，评估项目状态Q：用何种生命周期组织项目？互联网项目看中发布时间和功能集合，适合用迭代式的生命周期。Q：如何安排项目日程？细化日程，让成员自省讨论，**基于可交付物** 的日程规划。注意，这里的日程和具体的时间安排没有关系，而是处理任务之间的依赖关系。Q：如何估算日程中每个任务书中给了一个方法：使用日期范围，但问题是，在小团队工作时候，可能整个项目周期也就 1 个月，如果按日期范围估计，就比较难评估了。还有一个方法是使用「1、2、3、5、8、13、21、34、55、89」这样的方式来拆解估算任务。每个任务可以拆解成小石子（不超过 2 天的任务）。还有一个 tip 是使用波浪式规划，即不在一开始时候规划全部。在进行的过程中调整日程。以 2 周或者 4 周的长度规划，太长了就更容易出错，对预测能力要求太高。项目经理目标是**按驱动因素完成既定需求，而不是给一个漂亮的甘特图**。关于估算日程的三条忠告：> * 绝对不要提供确定的项目结束日期> * 任务越小，估算起来越容易> * 寻求估算的准确性，而不是精确性Q：前期延迟了，后期能追赶么？不能，强行安排的话，是一个日程安排游戏。但是从 Deadline 意识来说，需要对成员达成 Deadline 意识。Q：如何创建优秀团队？招对的人，激励个人，形成团队凝聚力。团队发展分成 5 个时期：组建、激荡、规范、表现、终止。Q：如何估算日程安排里面的时间？参见上面所说「1、2、3、5、8、13」和小石子。Q：如何对项目的模块进行拆分？书中没有过多提及，我从自己经验得出的答案是：* 原则：拆解成耦合度低，可以并发进行的子任务，互不依赖* 每个拆分出来的子任务，是可以被描述，并且其产出是可量化的* 如果子任务之间，有相互依赖点，需要在早期就约定好接口和交付时间点* 如果一个模块 A 很大（比如超过 4 周开发时间），那应该团队作战以这个模块为开发目标，将模块 A 拆成多个子任务，然后并发进行。而不是模块 A、模块 B 并发进行。Q：如何保持项目节奏，避免发生延期？参见上面的「关键词」中「项目节奏」部分。Q：如何管理工程（多个项目），并且在里面进行协调？多个项目，但是**使用一个发布计划**（类比前端、后台、移动端）。并一起制定好各个项目的计划。如果基于敏捷开发，问题可以被简化，因为每条线都是随时可以发布的状态。如果不行，那就组织里程碑的发布计划。需要管理各个子项目的项目经理，并且创建统一的日程表。Q：团队里面有执行迟缓，不听从决策的人员，怎么办？这个问题其实是管理问题，而不是项目管理问题。书中并没有合适答案，我自身感想是这几方面：* 弄清楚为什么不听从决策，需要明确项目的发布目标* 从精神、物质上面进行激励* 直白的进行沟通，向对方请求帮助* 从自身寻找问题，提高自身沟通能力和专业技能能力

书看起来不错，但翻译的太烂

翻译太差，很多地方根本就不通，甚至感觉像机器翻译。什么仪表盘，产出物、小石子、上下文之类的，很多意思都不通，如果没有背景知识读起来很累。比如有这么一段：”如果结对不起作用，就让人们在隐秘的空间中讨论，从而不至影响他人。如果很难获得一个‘隐秘’的办公室，就弄一个项目‘作战室’吧，可以在其中贴出项目的仪表板、架构文档等各种产出物。“你能看懂吗，类似的段落充斥了正本书

实战类的好书

虽然是比较薄的一本书，但作者用精炼的语言讲了项目管理的整个过程，并且对每个阶段用管理方法和管理工具做了相关介绍，比较贴近实战。无论你是刚刚进入项目管理的菜鸟，还是有已经有多年团队经验的人都能从中汲取有用的东西