《项目管理之美》试读

铅笔小星

选自《项目管理之美》样章

第1章
项目管理简史（以及您应该关注于此的原因）

      在很多组织中，带领项目的人员并没有“项目经理”（projectmanager）这一职位。但这没什么影响。实际上，无论是独自工作，还是带领一个团队，每个人在日常工作中都在管理项目。这里，我们暂不关心这些差别。我的目的是获取如下信息：是什么使项目成功？成功带领项目的人员是怎样做的？实际上，这些原则并不限于特殊的阶层、工作职位或方法。因此，如果你正在参与一个项目，并且对项目结果承担一定的责任，那么下面的内容将适用于您。如果您的名片上恰好印着“项目经理”，那么您将受益更多。

      本书的作用通过如下三种方式体现：作为主题明确的短文合集，作为长篇连续故事，作为常见问题的参考手册。每一章将关注一个高层任务，提供一个基本的框架，并提供成功完成该任务的方法。但是，对于本章有些不同：为了便于讲述本书后面的内容，我们下面提出三个更广泛的主题。
第一个主题是项目简史以及为什么我们应该从他人的做法中学习。第二个主题是关于各种项目管理风格的背景，包括我在微软工作时积累的经验。第三个主题是探索项目管理领域的挑战，以及如何应对这些挑战。虽然这些内容在后面将非常有用，但是对于我们理解本书后面各章，这些不是必需的。因此，如果您觉得本掌内容太宽泛了，您可以立刻翻到第2章，进入本书的核心内容。

利用历史

      项目管理作为一种思想，可以追溯到很久之前。如果考虑一下人类文明历史上曾建立的所有事物，可以供我们学习的项目经验已经有数千年的历史了。对于我们现在的软件开发人员画出的虚线，如果向前回顾，埃及金字塔的建造者和罗马沟渠的设计师在当时就是这样使用的。无论是古代，还是现代，项目管理者都在扮演着类似的角色，将技术用在各自时代关心的问题上。但是，直到今天，当很多人想要改善Web开发和软件开发的项目管理时，却很少会去注意过去的历史教训。在项目管理知识发展的时间轴中，今天比古代的进步不大，这实在是不该。

      工程项目的历史说明大多数的项目都非常类似。它们都涉及需求、涉及和限制。它们都依赖于沟通、作决策、创新思维和逻辑思维的结合。项目一般都包括进度、预算和客户。最重要的是，项目的中心任务是将不同人的工作结合起来，形成单一完整的、对人类或客户有价值的产物。对于构建项目，无论是通过HTML、C++，还是水泥和钢铁，都存在一套不可否认的、大多数项目所共享的核心概念。

      为了探寻带领Web开发和软件开发项目的更好方式，我为此花费了大量的精力。我研究了其他领域，以了解它们是怎样解决项目中的关键问题。我想知道像哈勃太空望远镜和波音777这些项目是如何设计和构建的？是否可以复用这些项目中复杂的规格说明和计划过程？或者，当在纽约建造克莱斯勒大厦，以及在雅典建造帕台农神殿时，项目领导者计划和评估项目的方式是否和我们软件开发者一样？有哪些显著差异？通过研究这些差异，我们可以获取什么？
对于报纸的编辑们，在实现网络出版梦想前的很长一段时间内，都需要进行多媒体（图片和文字）内容创作工作，他们是如何组织和计划每天的信息产品的？故事片电影是如何生产的？阿波罗13是如何发射的？通过研究这些问题，我了解了带领项目组的新方法。
      
      但是，这些调查并不总是能够提供明显的答案。我不能保证您立刻领会，或者立刻作出完美的计划，因为本书提供的建议将受很多因素的影响。我发现，当我从其他环境回到软件世界中，我采用的过程和工具已经完全不同了。概括来说，我发现，在我大学计算机科学研究过程中，我已经不再提及那些过去有益的方法和比喻。无论是技术会议，还是为商业杂志编写的材料，都不再讨论它们了。

通过对过去历史的调查，我得出如下三项关键的收获：

      1. 项目管理和软件开发不是什么神圣的艺术。对于漫长的造物史而言，任何现代的工程项目都是一种新的出现。技术和技能可能会改变，但那些造成工程难题的关键挑战依然存在。无论是编程语言，还是开发方法，它们在某些方面是独一无二的，而在其他方面则是从其他事物衍生而来的。但是，如果我们想要尽可能多地复用已有的知识，在与过去进行比较时，必须以开放的态度来考虑知识的唯一性和衍生性。

      2. 对于您所做的事情了解的越少，您就有越多的精力去完成它。如果我们对工作有一个简单的了解，我们就能够从制造其他身边已有事物的过程中发现有益的类比。历史上曾有很多的例子和教训，可以供现代工业来借鉴、比较、对照。这类似于日语单词shosshin所表述的概念，即习武规则的最重要之处——初学者态度1或开放态度。保持求知和开放的态度才能取得进步，同时还需要实践来维持这种心态。只要不断学习，我们就可以避免走入歧途，安全地考虑我们所做的事情。

注释1：初心是禅宗的基本概念。其经典的故事是以空杯作比喻：如果你执着于杯中之物，那么你的杯子将没有空间容纳新知识。请参考铃木俊隆禅师所著的Beginner’s Mind（Weacherhil出版，1972年）。

      3 简单并不等于容易。优秀的运动员、作家、程序员以及经理人都有这种认识，认为他们所做的事在本质上很简单，但同时也非常困难。要记住，简单与容易并不相等。例如，跑马拉松是个简单的事。你开始跑，跑了26.2英里后就停下来。有什么比这更简单的？跑完马拉松很困难的这个事实，并无损其简单性。领导力和管理也很困难，但其本质是很简单的，就是以特定方式朝特定目标把事情做好。
我在很多章节中都会提到这些概念。所以，如果我的比喻超出了软件开发的范畴，希望你能了解我这么做的理由。此外，当我提到决策和进度控制是简单的管理工作时，我会假定你知道这些事并不容易做到。
      
从失败中学习

      “人类是万物之灵，有能力学习他人的经验，却也最容易对他人经验视若无睹。”——DouglasAdams

      当研究项目历史时，会引发一个简单的问题：既然我们可以避免，为什么还有人愿意去经历错误和失望？如果古代及现代工程史都是公开的，而且无论灵感来自何处，我们也因做些聪明的事而领取薪水，为什么少有组织奖赏那些从过去获取经验的人？每天都有项目完成或取消（许多开发项目都以此结束2），但少有人从中吸取经验。大多数组织中的经理人似乎很少奖赏那些寻找这类知识的人。也许是害怕他们找出来的东西（害怕必须为此负责），或者也可能对此缺乏兴趣。当我们花费时间来开展新项目时，没有人愿意回顾痛苦或令人沮丧的经验。

注释2：CHAOS报告（Standish Group出版）是一份经常被引用的文献，内容关注于软件项目的预算、进度以及常见失败上。请参考http://standishgroup.com/sample_research/。

      Henry Petroski在其To Engineer Is Humman: TheRole of Failure is Successful Design（Vintage Books出版，1992年）一书中提及：许多工程的突破都来源于失败的结果。产生这种现象的部分原因在于，失败会使我们集中注意力，重新检查我们忘却的假设（当原型烧起来时，很难假装一切正常）。正如Karl Popper3所说的，只存在两种理论：错误的理论和不完整的理论。如果没有失败，我们就会变得骄傲，忘记了我们对事物的了解实际上并不像我们所想象的那样周全。

注释3：KarlPopper是20世纪著名的哲学家。请参考http://en.wikipedia.org/wiki/Karl_Popper。

      因此，窍门就是尽可能从他人的失败中学习。我们应该利用他人的经验来应对未来的挑战。虽然失败的表象对于不同项目有很大的差异，但引发这些问题的根本原因或团队行动也许可以借鉴（并且是可用避免的）。即使是我们自己的项目，也要避免逃避失败的习惯。相反，我们应该视之为学习机会。失败的因素是什么？哪些因素可能很容易减少或消除？根据Petroski的说法，只要我们有勇气仔细检查发生过的事情，从实际失败中学得的实践知识，将是我们取得进步的最有力的源泉。
也许这就是为什么波音公司——全球最大的飞机设计和制造公司之一，会留着一本黑皮书，来记载从过去的设计和制造失败中获取的经验教训。4自从波音公司成立，就一直保存着这份文件，用来帮助现代设计师从，从过去的经历中吸取经验。任何这样做的组织，都可用增加项目成功的几率，同时也有助于建立一种可以公开讨论、面对失败的环境，而非否认和隐藏失败。看起来，软件开发人员也需要保存他们自己的黑皮书。

注释4：引自James R. Chiles所著的InvitingDisaster: Lessons from the Edge of Technology（HarperBusiness出版，2002年）。


更多内容请参阅：http://bbs.itpmp.org/thread-5263-1-1.html

jllml