项目管理之美
点此进入淘宝搜索页搜索分类: 图书,计算机/网络,项目管理 IT人文,
作者： （美）博克顿（Berkun，S.） 著，李桂杰，黄明军 译
出 版 社： 机械工业出版社
出版时间： 2009-4-1字数：版次： 1页数： 358印刷时间：开本： 16开印次：纸张：I S B N ： 9787111259527包装： 平装编辑推荐
“该书涵盖了从实践方法到确保工作按质按时完成的所有方面内容，让你创新思考，使你成为了不起的领导，激励你的团队全力以赴地工作。阅读本书就像阅读微软公司关于如何管理最好项目的宏伟蓝图……我希望大家能把书中的经验付诸于行动！”
——Joe Belfiore，Microsoft E-home部门VP
“Berkun写了一本节奏轻快、没有术语且诙谐的指南……本书是一本了不起的原理介绍。无论是经验丰富的管理者，还是新手经理，都能从作者的观点中受益匪浅！”
——Joe Mirza，Director，CNET Networks（Cnet.com）
“大多数以‘项目管理’为标题的书都很枯燥厚重。如果这也是你对Berkun的书的期待，那么你将收获愉悦的惊喜。当然，这是关于项目管理方面的好书。然而，这也是关于创新、情景问题解决和领导力的一本书。不管你是一名团队成员、项目经理或是非技术的相关人员，Berkun都会为你提供很多实用的工具和技术，毫无疑问，这将确保你的成功。
-Bill Bliss，产品和客户体验高级VP，Expedia.com
作者简介：
SCOTT BERKUN在微软公司工作了10年，参与的项目包括IE、MSN和Microsoft Windows。同时，在为微软公司卓越工程组（Engineering Excellence Group）工作的两年中，他为开发团队授课和提供咨询。2007年，他写了畅销书The Myths Of Innovation（O'Reilly出版）。Scott是一位知名的演说家和培训师，涉及的领域包括管理、创新思考和设计。你可以在网站www.scottberkun.com上看到有关播客、文章和管理讨论组。
内容简介
通过本书，你可以从一位经验丰富、从事多年软件开发和Web开发的经理那里学习如何计划、管理和领导项目。书中的那些宝贵而有用的建议，是作者十多年经验的积累，从很多复杂的概念和挑战中提炼而来。本书引人思考、生动有趣、坦诚直率、引人注目，是你和你的团队在当前和未来的项目中所必备的参考。
包括如下主题：如何制定好的决策、想法以及如何处理、领导力和信任、当事情出错时该怎么办。
新版包括：120多道新的练习题考察你所学到的知识、用于和团队一起使用本书的讨论指南、每章都有修订和改进的建议。
目录
序
前言
第1章 项目管理简史
第1部分 规划
第2章 关于进度表的原理
第3章 如何知道该做什么
第4章 编写好的远景文档
第5章 想法从何而来
第6章 有了想法之后做什么
第2部分 技巧
第7章 撰写优秀的规格说明书
第8章 如何制定好的决策
第9章 沟通和人际关系
第10章 怎样才能不惹恼别人：流程、电子邮件和会议
第11章 事情出错时该做什么
第3部分 管理
第12章 为什么领导力以信任为基础
第13章 如何让事情发生
第14章 中盘战略
第15章 终盘战略
第16章 政治与权力
附录 讨论组指导
参考资料
致谢
照片来源
书摘插图
第1章 项目管理简史
在很多组织中，带领项目的人员并没有“项目经理”（project manager）这一职位。但这没什么影响。实际上，无论是独自工作还是带领一个团队，每个人在日常工作中都在管理项目。这里，我们暂不关心这些差别。我的目的是获取如下信息：是什么使项目成功？成功带领项目的人员是怎样做的？实际上，这些原则并不限于特殊的阶层、工作职位或方法。因此，如果你正在参与一个项目，并且对项目结果承担一定的责任，那么下面的内容将适用于您。如果您的名片上恰好印着“项目经理”，那么您将受益更多。
本书的作用通过如下三种方式体现：作为主题明确的短文合集，作为长篇连续故事，作为常见问题的参考手册。每一章将关注一个高级任务，提供一个基本的框架，并提供成功完成该任务的方法。但是，本章有些不同：为了便于讲述本书后面的内容，我们下面提出三个更广泛的主题。
第一个主题是项目简史以及为什么我们应该从他人的做法中学习。第二个主题是关于各种项目管理风格的背景，包括我在微软工作时积累的经验。第三个主题是探索项目管理领域的挑战，以及如何应对这些挑战。虽然这些内容在后面将非常有用，但是对于我们理解本书后面各章，这些不是必需的。因此，如果您觉得本章内容太宽泛了，您可以立刻翻到第2章，进入本书的核心内容。
使用历史
项目管理作为一种思想，可以追溯到很久之前。如果考虑一下人类文明历史上曾建立的所有事物，可以供我们学习的项目经验已经有数千年的历史了。对于我们现在的软件开发人员画出的虚线，如果向前回顾，埃及金字塔的建造者和罗马沟渠的设计师在当时就是这样使用的。无论是古代还是现代，项目管理者都扮演着类似的角色，将技术用在各自时代关心的问题上。但是，直到今天，当很多人想要改善Web开发和软件开发的项目管理时，却很少会去注意过去的历史教训。在项目管理知识发展的时间轴中，今天与古代相比进步不大，这实在是不应该。
工程项目的历史说明大多数的项目都非常类似。它们都涉及需求、设计和限制。它们都依赖于沟通、作决策、创新思维和逻辑思维的结合。项目一般都包括进度、预算和客户。最重要的是，项目的中心任务是将不同人的工作结合起来，形成单一完整的、对人类或客户有价值的产物。对于构建项目，无论是通过HTML、c++，还是水泥和钢铁，都存在一套不可否认的、大多数项目所共享的核心概念。
为了探寻带领Web开发和软件开发项目的更好方式，我花费了大量的精力。我研究了其他领域，以了解它们是怎样解决项目中的关键问题。我想知道像哈勃太空望远镜和波音777这些项目是如何设计和构建的？是否可以复用这些项目中复杂的规格说明和计划过程？或者，当在纽约建造克莱斯勒大厦以及在雅典建造帕台农神殿时，项目领导者计划和评估项目的方式是否和我们软件开发者一样？有哪些显著差异？通过研究这些差异，我们可以获取什么？
对于报纸的编辑们，在实现网络出版梦想前的很长一段时间内，都需要进行多媒体（图片和文字）内容创作工作，他们是如何组织和计划每天的信息产品的？故事片电影是如何生产的？阿波罗13是如何发射的？通过研究这些问题，我了解了带领项目组的新方法。
但是，这些调查并不总是能够提供明显的答案。我不能保证您立刻领会，或者立刻作出完美的计划，因为本书提供的建议将受很多因素的影响。我发现，当我从其他环境回到软件世界中，所采用的过程和工具已经完全不同了。概括来说，我发现，在我大学计算机科学研究过程中，我已经不再提及那些过去有益的方法和比喻。无论是技术会议，还是为商业杂志编写的材料，都不再讨论它们了。
通过对过去历史的调查，我得出如下三项关键的收获：
1.项目管理和软件开发不是神秘的艺术。对于漫长的造物史而言，任何现代的工程项目都是一种新的出现。技术和技能可能会改变，但那些造成工程难题的关键挑战依然存在。无论是编程语言，还是开发方法，它们在某些方面是独一无二的，而在其他方面则是从其他事物衍生而来的。但是，如果我们想要尽可能多地复用已有的知识，在与过去进行比较时，必须以开放的态度来考虑知识的唯一性和衍生性。
2.对于您所做的事情了解得越少，您就有越多的精力去完成它。如果我们对工作有一个简单的了解，我们就能够从制造其他身边已有事物的过程中发现有益的类比。历史上曾有很多的例子和教训，可以供现代工业来借鉴、比较和对照。这类似于日语单词shoshin所表述的概念，即习武规则的最重要之处——初学者态度或开放态度。保持求知和开放的态度才能取得进步，同时还需要实践来维持这种心态。只要不断学习，我们就可以避免走入歧途，安全地考虑我们所做的事情。
3.简单并不等于容易。优秀的运动员、作家、程序员以及经理人都有这种认识，认为他们所做的事在本质上很简单，但同时也非常困难。要记住，简单并不等于容易。例如，跑马拉松是个简单的事。你开始跑，跑了26．2英里后就停下来。有什么比这更简单的？跑完马拉松很困难这个事实并无损其简单性。领导力和管理也很困难，但其本质是很简单的，就是以特定方式朝特定目标把事情做好。
我在很多章节中都会提到这些概念。所以，如果我的比喻超出了软件开发的范畴，希望你能了解我这么做的理由。此外，当我提到决策和进度控制是简单的管理工作时，我会假定你知道这些事并不容易做到。
从失败中学习
“人类是万物之灵，有能力学习他人的经验，却也最容易对他人经验视若无睹。”
——Douglas Adams
当研究项目历史时，会引发一个简单的问题：既然我们可以避免，为什么还有人愿意去经历错误和失望？如果古代及现代工程史都是公开的，而且无论灵感来自何处，我们也因做些聪明的事而领取薪水，为什么很少有组织奖赏那些从过去获取经验的人？每天都有项目完成或取消，但很少有人从中吸取经验。大多数组织中的经理人似乎很少奖赏那些寻找这类知识的人。也许是害怕他们找出来的东西（害怕必须为此负责），或者也可能对此缺乏兴趣。当我们花费时间来开展新项目时，没有人愿意回顾痛苦或令人沮丧的经验。
Henry Petroski在其《To Engineer Is Humman：The Role of Failure is Successful Design》（Vintage Books出版，1992年）一书中提及：许多工程的突破都来源于失败的结果。产生这种现象的部分原因在于，失败会使我们集中注意力，重新检查我们忘却的假设（当原型出现问题时，很难假装一切正常）。正如Karl Popper所说的，只存在两种理论：错误的理论和不完整的理论。如果没有失败，我们就会变得骄傲，忘记了我们对事物的了解实际上并不像我们所想像的那样周全。
因此，窍门就是尽可能从他人的失败中学习。我们应该利用他人的经验来应对未来的挑战。虽然失败的表象对于不同项目有很大的差异，但引发这些问题的根本原因或团队行动也许可以借鉴（并且是可避免的）。即使是我们自己的项目，也要避免逃避失败的习惯。相反，我们应该视之为学习机会。失败的因素是什么？哪些因素可能很容易减少或消除？根据Petroski的说法，只要我们有勇气仔细检查发生过的事情，从实际失败中学得的实践知识将是我们取得进步的最有力的源泉。
也许这就是为什么波音公司——全球最大的飞机设计和制造公司之一，会留着一本黑皮书，来记载从过去的设计和制造失败中获取的经验教训。自从波音公司成立之后，就一直保存着这份文件，用来帮助现代设计师，从过去的经历中吸取经验。任何这样做的组织，都可以增加项目成功的几率，同时也有助于建立一种可以公开讨论、面对失败的环境，而非否认和隐藏失败。看起来，软件开发人员也需要保存他们自己的黑皮书。
Web开发、厨房及急诊室
历史的一个问题就是并不总是能和现实产生关联。要把几十年前的经验用到如今差别似乎很大的事情上，又要维持同理性，的确很难。另一种做法是，对当代几种有趣的项目进行比较。虽然没有工程史的庄严感，不过，却让人可以亲身体验和观察。通常，亲眼所见是能给人充分信息的唯一办法，只有通过这些信息，才能在众多概念间建立联系。例如，我知道有位Web开发人员，他认为自己的工作和宇宙史上的任何事物都不一样。他之所以会这么觉得，是因为Web开发需要他作复杂的工程决策，其中包括各种设计和协调工作，以及在几个小时甚至几分钟内就得完成的验证修改是否正确、然后就对世界发布的工作。因此，他认为他的项目及任务管理不同于以前看到的事物。对那些他所精通的CSS、XHTML、Flash、Java以及其他技术朗朗上口，他觉得很自豪，认为自己强过50年前那些最聪明的人。我确信，在你的经历中一定遇到过这样的人。或者，你曾经在这样的环境下工作，好像宇宙中任何人都没有能力来处理像你现在正在解决的、如此复杂的问题。
……
