《项目管理之美》第1章

最新推荐文章于 2018-10-18 06:20:26 发布

cuad2192

最新推荐文章于 2018-10-18 06:20:26 发布

阅读量417

点赞数

文章标签：人工智能 java php

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE 第 1 章项目管理简史（以及您应该关注于此的原因）

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

本书的作用通过如下三种方式体现：作为主题明确的短文合集，作为长篇连续故事，作为常见问题的参考手册。每一章将关注一个高层任务，提供一个基本的框架，并提供成功完成该任务的方法。但是，对于本章有些不同：为了便于讲述本书后面的内容，我们下面提出三个更广泛的主题。

第一个主题是项目简史以及为什么我们应该从他人的做法中学习。第二个主题是关于各种项目管理风格的背景，包括我在微软工作时积累的经验。第三个主题是探索项目管理领域的挑战，以及如何应对这些挑战。虽然这些内容在后面将非常有用，但是对于我们理解本书后面各章，这些不是必需的。因此，如果您觉得本掌内容太宽泛了，您可以立刻翻到第2章，进入本书的核心内容。

利用历史

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

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

为了探寻带领Web开发和软件开发项目的更好方式，我为此花费了大量的精力。我研究了其他领域，以了解它们是怎样解决项目中的关键问题。我想知道像哈勃太空望远镜和波音777这些项目是如何设计和构建的？是否可以复用这些项目中复杂的规格说明和计划过程？或者，当在纽约建造克莱斯勒大厦，以及在雅典建造帕台农神殿时，项目领导者计划和评估项目的方式是否和我们软件开发者一样？有哪些显著差异？通过研究这些差异，我们可以获取什么？

对于报纸的编辑们，在实现网络出版梦想前的很长一段时间内，都需要进行多媒体（图片和文字）内容创作工作，他们是如何组织和计划每天的信息产品的？故事片电影是如何生产的？阿波罗13是如何发射的？通过研究这些问题，我了解了带领项目组的新方法。

但是，这些调查并不总是能够提供明显的答案。我不能保证您立刻领会，或者立刻作出完美的计划，因为本书提供的建议将受很多因素的影响。我发现，当我从其他环境回到软件世界中，我采用的过程和工具已经完全不同了。概括来说，我发现，在我大学计算机科学研究过程中，我已经不再提及那些过去有益的方法和比喻。无论是技术会议，还是为商业杂志编写的材料，都不再讨论它们了。

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

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

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

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

3 简单并不等于容易。优秀的运动员、作家、程序员以及经理人都有这种认识，认为他们所做的事在本质上很简单，但同时也非常困难。要记住，简单与容易并不相等。例如，跑马拉松是个简单的事。你开始跑，跑了26.2英里后就停下来。有什么比这更简单的？跑完马拉松很困难的这个事实，并无损其简单性。领导力和管理也很困难，但其本质是很简单的，就是以特定方式朝特定目标把事情做好。

我在很多章节中都会提到这些概念。所以，如果我的比喻超出了软件开发的范畴，希望你能了解我这么做的理由。此外，当我提到决策和进度控制是简单的管理工作时，我会假定你知道这些事并不容易做到。

从失败中学习

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

——Douglas Adams

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

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

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

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

因此，窍门就是尽可能从他人的失败中学习。我们应该利用他人的经验来应对未来的挑战。虽然失败的表象对于不同项目有很大的差异，但引发这些问题的根本原因或团队行动也许可以借鉴（并且是可用避免的）。即使是我们自己的项目，也要避免逃避失败的习惯。相反，我们应该视之为学习机会。失败的因素是什么？哪些因素可能很容易减少或消除？根据Petroski的说法，只要我们有勇气仔细检查发生过的事情，从实际失败中学得的实践知识，将是我们取得进步的最有力的源泉。

也许这就是为什么波音公司——全球最大的飞机设计和制造公司之一，会留着一本黑皮书，来记载从过去的设计和制造失败中获取的经验教训。4自从波音公司成立，就一直保存着这份文件，用来帮助现代设计师从，从过去的经历中吸取经验。任何这样做的组织，都可用增加项目成功的几率，同时也有助于建立一种可以公开讨论、面对失败的环境，而非否认和隐藏失败。看起来，软件开发人员也需要保存他们自己的黑皮书。

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

Web开发、厨房及急诊室

历史的一个问题就是并不总是能和现实产生关联。要把几十年前的经验用到如今差别似乎很大的事情上，又要维持同理性，的确很难。另一种做法是，对当代几种有趣的项目进行比较。虽然没有工程史的庄严感，不过，却让人可用亲身体验和观察。通常，亲眼所见是能给人充分信息的唯一办法，只有通过这些信息，才能在众多概念间建立联系。

例如，我知道有位Web开发人员，他认为自己的工作和宇宙史上的任何事物都不一样。他之所以会这么觉得，是因为Web开发需要他作复杂的工程决策，其中包括各种设计和协调工作，以及在几个小时甚至几分钟内就得完成的验证修改是否正确、然后就对世界发布的工作。因此，他认为他的项目及任务管理不同于以前看到的事物。对那些他所精通的CSS、XHTML、Flash、Java以及其他技术朗朗上口，他觉得很自豪，认为自己强过50年前那些最聪明的人。我确信，在你的经历中，一定遇到过这样的人。或者，你曾经在这样的环境下工作，好像宇宙中任何人都没有能力来处理像你现在正在解决的、如此复杂的问题。

我建议这位开发人员朋友，在餐馆忙碌的一天，去餐馆的后厨去看看。走进厨房是很有趣的（请参考Anthony Bourdain所写的好书Kitchen Confidential，Ecco出版，2001年），这有很多种原因，但是，我的焦点是生产力。任何人在第一次看到发生在忙碌的专业厨房中所采取的快速的任务管理和协调后，都可能会重新思考自己的工作到底有多难。烹饪时，通常要同时应付数个油炸中的平底锅，它们有着各有不同的先后次序和完成状态；同时，还得在厨房各角落的炉火间四处穿梭；此外，侍者进进出出，传达客户更改的菜单和各类问题。

这一切都放生在窄小拥挤的厨房内，头顶是刺眼的日光灯。尽管每隔几秒就出一道菜，但新菜单进来的速度同样很快。有时候，出菜后会被退回，或者，像软件项目那样，要做点定制工作和最后一分钟的改变（比如，一号桌不喜欢乳糖，二号桌要一些酱汁等）。大型忙碌的厨房看起来实在令人惊讶。乍看起来似乎一团混乱，但是，伟大的厨房却以一种紧张而精确的水平运作着，大多数开发团队都不如此。

主厨和副厨就是烹饪的项目经理，或者如Bourdain所说的，他们是空中交通管理员（另一个自省时可考虑的职业）。虽然厨房员工的工作规模比较小，也不及软件开发团队经理那样受人称赞，但是，就每日工作的紧张程度而言，二者无从比较。如果怀疑我，那么下一次，你可以到一个忙碌的午餐地点，询问服务员是不是可以看看厨房。他也许不会同意，但是，如果他同意，你将不会失望（某些时尚的餐馆和酒吧有开放式的厨房。如果你发现这种地方，可用尽可能坐在靠厨房近一些的位置。然后，盯着某人人看几分钟。注意查看怎么下菜单、怎么跟踪菜单、怎么烹饪菜肴以及怎么上菜。如果你找忙碌的一天去，那么，对于如何发现、如何跟踪以及如何修复软件bug这些问题，你就会有不同的想法）。

关于项目管理的另一个有趣的领域经验来自于医院的急诊室。我看过《探索》频道以及PBS（Public Broadcasting Service）频道的节目，其中，由专业医生、护士以及专家组成的项目组协同工作，来处理来到医院的各式各样、有时是异乎寻常的医疗病例。发明的分类处理是一种专业，这一点也不奇怪，软件项目经常使用分类处理这一术语，来按优先级分类问题和缺陷（第十五章会再次讨论）。

对于团队合作、高压下的决策制定以及每天影响到许多人的项目成果，医疗环境（尤其是外伤的情况）为其提供了很好的比较（关于这种环境与其他工作环境的比较，请参见图1-1）。这正如Atul Gawande在其著作Complications: A Surgeon’s Notes on an Imperfect Science（Picador USA出版，2003年）中所说的那样。

我们希望医学是关于知识和过程的有条理的专业。但实际并非如此，医学是不完美的科学，是由不断更新的知识、不确定的信息以及容易犯错的个人共同组成的，同时，又要按规则操作。是的，我们所做的事情有科学的做法，但同时也有习惯、直觉以及偶尔的单纯经验猜测。我们所知道的与我们持续追求的目标之间存在着差距，该差距把我们所做的一切都复杂化了。

电影	前期制作	拍摄	后期制作
软件开发	需求	设计	编码	测试
Web开发	前期工作	开发	维护	评估
急诊室	诊断	治疗	评估
厨房	点菜	烹调	上菜

图1-1 从抽象层次看，许多领域都有相似的过程，都把时间用在计划、执行以及改进（但是，你绝不会去厨房求医或者到急诊室找吃的东西。）

这一点，以及在Gawande的那本引人醒悟的书中所谈到的许多其他事情，对软件开发一样有效。Fred Brooks在其软件工程经典著作The Mythical Man-Month（Addison-Wesley出版，1995年）中，同样也通过外科医生团队和程序员团队进行类似的比较。尽管在开发网站或数据库时，很少有生命危险的情况，但是，这些不同团队的人远都必须面对许多相似的挑战。

项目管理的角色

项目管理可视为一种专业、一种工作、一种角色或一项活动。有些公司有项目经理，其职责是管理200人的整个项目。其他公司把这个职位当成高级经理，每位项目经理负责大项目中的一小部分。根据组织的结构、文化以及项目目标，项目管理可以是非正式的角色（“一有需要，就找人来做”），或者也可以是明确定义的角色（“Vincent、Claude以及Raphael都是全职项目经理”）。

本书中，我主要使用“项目经理”，或PM这个词汇来指那些涉及到项目领导和管理活动的人员。对于“项目管理活动”，我主要是指如下活动：领导整个团队以了解项目工作（计划、进度安排以及收集需求）、带领项目进行设计和开发工作（沟通、决策以及中期策略）、以及驱动完成整个项目（领导力、风险管理以及终局策略）。

如果这类工作在你所处的环境中没有那么正式，就把项目经理或PM看作是“负责项目管理任务的人，即使这不是他的主要工作”，或者将其视作“整体考虑项目的人”。我看到，不同的团队有着不同的方式来组织项目管理活动，但是，本书的建议对他们没有什么大的差异。本书不关注工作职称和形式，而是在意怎样把事情做好，让事情进展。不过，为了表达方便，我还是会使用项目经理或PM这个词汇。

有时，没有专职的的项目经理也工作得很好。程序员和他们的老板会控制进度和工程计划（如果有的话），业务分析师或市场营销人员作项目计划和需求工作。任何可视为项目管理的工作，都被分散在整个团队人员身上。也许，团队成员应聘更重要的原因是兴趣，而不只是编写代码。他们也许不在意早期计划、用户界面设计或者业务策略。以这种方式工作，也会达到很好的效果。只要每个成员都愿意承担工作职责之外的、协调整个项目的额外责任，分担应该由专职项目经理为团队承担的任务，团队就不需要增加人员。保持效率和简单都很好。

但是，有时没有项目经理会造成困难。如果没有人专职控制整体项目，个人的偏见和利益考虑会影响团队的方向。技术人员和业务人员之间会形成很大的矛盾，使得进度落后，并影响每个参与人员的心情。考虑一下医院的急诊室，医生会负责病人的治疗过程。这样可以让迅速开展各项工作，使外伤团队中每个角色都能明确自己的职责。对于项目管理类型的事情，如果没有这种清晰的授权，开发团队将陷入麻烦。如果没有明确的人负责专门分类bug，或者没有专人检查项目进度和标识的重要问题，这些任务可能会危险地被延迟，落后于以编程为中心的活动。

我想，很多优秀程序员对项目管理都非常了解，会自行这样做，他们也能体会到，由优秀的专职人员来承担项目经理角色所带来的独特价值。

微软的程序和项目管理

在20世纪80年代后期，微软遇到了问题，每个部门都不知道如何在工程方面的成果与市场、业务之间进行协调（有人可能会说，这仍然是微软和许多其他公司面临的问题）。有个叫Jabe Blumenthal的聪明人，意识到可以设立一个同时参与这两种功能的特殊职位，这是个同时扮演领导和协调人的角色。他从项目开始计划的那一天参与进来，直到测试的最后一天。这个人不但需要有一定的技术能力，使得他可用与程序员共事并获得尊敬；同时，他还要具有很好的能力和兴趣，来参与产品的开发过程。

为了让这个角色有效工作，他必须乐于把时间花在各种任务上，例如编写规格说明书、检查市场计划、制定项目进度表、领导团队、作策略计划、进行bug分类、培养团队士气以及做好任何需要做但没有人正在做的事情。在微软把这个新角色称为程序经理（program manager）。团队中的人员并非都直接报告给他，但程序经理被赋予很高的权限，来领导并推动项目（在管理理论中，这类似于矩阵式组织（matrix organization），5每个人有两条报告路线：一条以职能为基础，另一条以项目为基础。因此，对于一个程序员或测试员，可能有两种报告关系：主要的报告关系是他的职能角色，次要但更重要的报告关系就是他所参与的项目）。

注释5：关于矩阵和其他组织类型的总结，可参考Steven A. Silbiger’s所著的The Ten-Day MBA（William Morrow and Company出版，1993年）一书中的第139-145页。不过，几乎任何关于管理理论的书籍都会包含这个主题。

Jabe在一项称为Multiplan（后来演变成Microsoft Excel）的产品中扮演这个角色，而且做得不错。随着技术团队与业务团队之间沟通质量的改善，工程和开发过程也随之改善，在整个产品开发过程中，大家都很高兴。经过多次的备忘录和会议讨论后，公司内大多数团队开始逐渐采用该角色。说出你对最终产品的看法，无论好坏，都有其价值。通过定义一个不是小职员也不是仆人的专职通才角色来作为领导者和掌舵者，使得微软内部开发团队的工作情况彻底地发生了改变。这种程序经理角色，就是我在微软职业生涯中所担任的，我参与过的产品团队有Internet Explorer、MSN以及Windows。最好，我甚至管理了一群担任这个角色的团队。

知道现在，我都没有听说过，有多少公司对项目管理进行大的改变，重新定义并形成项目管理的特殊方式。在我和其他Web及软件开发公司的很多交往中，很少碰到过担任类似的角色（通常，不是工程人员就是商务人员，有时也许会是较少见的设计人员）。许多公司使用团队结构进行组织工作，但少有公司会专门定义横跨工程和业务领域的角色。今天，微软有5000名程序经理（员工总数超过80000名）。虽然项目管理这个概念的力量已经减弱，有时也会被误用，但其核心精神在公司内的许多团队都会看到。

但是，无论我的名片上印着什么，或者，无论你是否相信微软的故事，作为程序经理，我每日的职责就是项目管理。简而言之，就是我负责使项目及参与项目的人员获得最大限度地成功。本书各章讲述的都是与达成这项目标有关的核心任务，从早期计划（第3、4章）、规格说明书撰写（第7章）、决策（第8章）、到实现管理及发布（第14、15章）。

在这些技巧下，某些态度和性格特质也开始起作用。对任何领导或管理项目的人，忽视这些都极为不利。

项目管理的平衡之道

很难找到好的项目经理，因为他们需要保持态度的平衡。Tom Peters在其“Pursuing the Perfect Project Manager”一文中，6把这些互相矛盾的态度称之为悖论或困境。这样的说法很恰当，因为不同的环境需要不同的做法。这意味着，项目经理不但要有这些特性，还要具有在特定时期应该采取何种行动的直觉。这就是项目管理被视为艺术的原因：他需要直觉、判断以及经验，并有效运用这些力量。下列关于特性的列表大致上是从Peters的文章中推衍而来的：

注释6：请参考http://www.tompeters.com/co_entries.php?note=005297&year=1991。

自我/无我：由于责任重大，项目经理通常可从工作中获得极大的满足。对于项目经理为所做之事投注的极大的个人情感，很容易理解。对多数人来说，这种情感联系正是他们维持充沛能量的原因。但同时，项目经理必须避免把个人利益放在项目利益之前，他们必须愿意把重要或有趣的任务分配出去，和整个团队共享成功。适当的自我意识是一种激励，但好的项目经理必须认识到，他的自我意识是否变成了一种障碍。

独裁/委派：在某些情况下，最重要的事情就是明确的授权以及快速的反应时间。项目经理必须有自信，有足够的魄力控制并强迫团队执行特定行动。但是整体而言，应该避免这些极端情况出现。管理良好的项目应该建立一种环境，使得工作可被委派出去，同时又能互相有效合作。

忍受模糊/追求完美：任何项目的初期都是高度开放与变化的，未知的事物远比已知的事物重要。正如我们在第5、6章将会讨论的那样，控制模糊是可以产生优秀想法的关键。项目经理如果不去管理他，就必须尊重它。但在其他时期，特别是项目后期，规范和精确是最重要的。要聪明地分辨何时值得去追求完美，何时采用普通或应急的解决方法就足够了（请参阅第8章的“发现并权衡各种选择”一节）。

口头/书面：虽然多数软件开发组织以电子邮件为中心进行沟通，口语技巧对于项目管理依然十分重要。总是要有开会、协商、闲暇讨论以及头脑风暴讨论，项目经理在面对面了解和沟通想法方面必须有效率。组织或项目规模越大，书写技巧就越重要。无论项目经理个人喜好如何，他都必须认识到书写或口头沟通在特定时刻哪个更为有效。

承认复杂/拥护简单：许多人会成为复杂性的牺牲品。但他们面对复杂的组织或工程挑战时，就会迷失于细节而忘了整体。其他人则由于没有充分了解细节，只是否认复杂性，而作出不良的决策。这里，平衡的做法是要认识到有哪个项目观点对解决当前问题或作决策最有用，同时，还要能在两者间自由转换，或者同时记在心中（头别爆了）。项目经理必须有足够说服力，让团队为他们所做的工作努力的目标简单，而不要把编写优良可靠的程序代码所牵涉的复杂性最小化。

不耐烦/有耐心：大多时候，项目经理是推动他人集中工作的人员。但是在某些情况下，不耐烦会对项目不利。有些政治性、跨组织或官僚的活动，是不可避免的时间陷阱：要某人在房间里，或者要某人参加电话会议，而且要有耐心。所以，知道何时该推动问题、何时该退让一步让事情发生，是项目经理必须培养的能力。

勇气/恐惧：美国文化最大的误区就是勇者无惧。这完全是谎言。勇者是感到害怕但依然选择采取行动的人。项目经理必须对所有可能做错的事情保持适度重视，把这些事视为完全可能发生。同时，项目经理也必须要有接受挑战的勇气来面对这些风险。

相信/怀疑。受人景仰并且相信自己的领导者，就是团队斗志的最大来源。项目经理对所做的事要有信心，而且看得见即将达成的目标的真正价值，这些很重要。同时，也必须对事情的进展以及事情的做法保持怀疑（而非讥笑）。必须有人去调查和提问，揭开假设，使困难问题浮现出来。平衡的做法是热情地提问，挑战他人的假设，但决不动摇团队对所做事情的信念。

如同Peters在他的文章中所指出的：很难找到具备所有这些技能的人员，更别提对这些能力作适当的平衡。PM所犯的许多错误，都牵涉到对平衡一个或多个冲突力量的失算。然而，每个人都可以改善自己的能力，以平衡这些力量。所以，虽然我不会再多谈这些自相矛盾的悖论列表（虽然以后会再碰到几次），但这是值得参考的。看着这份冲突但却是必要的力量列表，可帮助你后退一步，重新思考你在做的事情及其原因，然后做出更为精明的决策。

压力和分心

项目管理新手的恐惧之一就是成功需要改变。新项目建立的目的是要借着修改、构造或摧毁某些事物来改变世界的状态。维持现状不是成功的结果——除非由于某种奇怪的原因而将此定为目标。世界一直在变，如果和去年相比，项目已经没那么好，这通常就意味着落后了，因为目标被误导或者项目的执行在某些方面失败了。

担任项目经理意味着必须承受压力，这很难视而不见，但是这个领域就是这样。但不要只是坐视，要做得更好。总是会有新的思考方法、新的学习和应用主题或者新的流程，使工作更有趣或更有效率。也许这种责任与领导力更相关，和管理关系要弱一些，但是两者区别不大。无论你怎么区分，要想管理得好都需要领导技能。任何参与项目管理的人对于这两者都有某些职责，无论他的工作介绍如何描述。

但是，回到压力的问题上，我见过很多经理人回避施展领导力的时机（例如，团队/项目需要有人采取果断行动的时候），退缩到只是追踪其他人的绩效，而不是为他们的工作带来便利或是参与其中。如果某人所做的事就是记录分数和站在边界线上看，他也许比较适合财务部门。如果某人担任领导角色，对压力的反应是避开争论，那么他不是在领导，而是在逃避。无效率或抗压性不良的PM，会倾向于关注于项目的次要部分，这使得他们只能贡献少许价值。

流程与目标相混淆

在这种情况下，某些PM会经常去量化一些不需要量化的事物。由于不确定该做什么其他的事情，或者害怕去做那些本来最需要做的事，他们最终将时间花费在次要的事情。随着PM和项目之间的隔阂逐渐变大，放在不必要的图、数据表、检查列表以及报告上的注意力就会增多。在某一时刻，PM开始相信数据和流程就是项目，这是有可能的。他们把焦点放在次重要且容易做的事情上（电子表格或报告），而不是重要且有挑战性的事情上（编程成果或进度）。他们也许会自欺说，如果照着特定流程执行，做好检查列表上的事，就可以保证项目成功（或者比较讽刺地说，对于任何可能发生的失败，在技术上都不是他们的错）。

为了把混淆的可能性减到最小，优秀的项目经理不会在他们愿意做和不愿意做的事情间划出明确的界限。他们会避免在项目管理任务和项目本身之间划下明确的分隔线。坚持检查列表意味着存在明确的可以保证获取特定成果的流程，但从来都不是这样。实际上，总是有三件事：目标、一堆工作以及一群人。定义明确的角色（参考第9章）可能有助于这些人分派工作，但是，建立角色并非目标。检查列表也许有助于这些人以满足目标的方式做事，但检查列表也不是目标。把流程和目标混淆，是管理层最大的错误之一。我知道这个，我就曾犯过这种错误。

在几年前做Internet Explorer 4.0项目时，我是几个大范围用户界面的PM。我感受到巨大压力：这是我接过的最大的任务。为了做好这个项目，我想到一个原则：如果可以把一切都写在检查列表上，就不会失败。虽然项目的各个事项都必须仔细追踪，但我做得太过头了。我做了一份细致的电子表格，以各种形式显示数据；同时，我办公室的几个大型白版也贴满了表格和列表（并且还在准备其他白板）。

我的上司放手让我去做，因为项目进展顺畅。直到他发现我花在检查列表和流程的时间超过我和团队相处的时间——这就是大红旗插下的时刻了（警告标记）。有一天，他来到我的办公室，看着我在办公室里每个平面上贴着的可笑的由检查列表和表格组成的大矩阵，说：“Scott，这些东西不错，但你的项目是你的团队，管理好团队，而不是检查列表。如果检查列表有助于管理团队，那非常好。但如果你这样做下去，不久之后，你就需要你的团队来帮助你管理检查列表。”

所以，项目经理不应把焦点放在流程和方法上，应该把焦点放在他们的团队上。简单的计划或追踪系统当然还是要使用，但他必须符合项目的复杂度和团队的文化。更精确地讲，计划和追踪应该支持团队达成项目目标，而不是阻碍他。我相信，只要PM注意这一点，并赢得团队信赖，那么任何漏掉的任务、流程、报告、检查列表或其他项目管理组织所需的事物，都会在问题恶化前清晰地浮现出来。

就如我们将在第10章中讨论的，只是有本书或有位领导说要做某事，或者在上个月或去年采用了某项技术，并不能表示今天依然适用。每个团队和项目都不同，通常都有很好的原因质疑过去的判断。对方法和流程保守的原因是，不必要的事情会像滚雪球般地越来越多，把团队拖进举步艰难的焦油坑——正如Fred Brook在其《人月神话》（The Mythical Man-Month）一书中所说的那样。如果管理流程也需要流程，就很难知道实际的工作在哪里。通常，正是团队领导或项目经理推动了团队的官僚主义，或者更为讽刺地，把团队送进永无止境的过程和会议讨论的，也正是这些人。

适度参与

从财富500强的管理人员到运动团队的教练，所有管理者都很容易过度参与。他们也知道可能过头了，强迫式的参与是一种方便的补救办法（虽然是负面）。这部分地解释了为何有这么多小经理：对于软弱的经理，采取的最简单的措施就是对下属滥用权力（在极端情况下，同时责怪下属能力不足，需要他花这么多的精力）。这种没安全感的管理者，采用工业革命的术语，源自于他不在生产线上的事实。他们没有亲手做事，与那些实际做事的人不同。

工厂或软件公司的经理，不像受聘的工人或程序员那样产生线性的工作量。相反地，领导者和经理的受聘用来增强周围每个人员的价值。增加这种价值的方法和在生产线上的工作不同。但是，因为很多经理人以前都是程序员，都是从生产线提拔到管理层，因此，对于这些人，通常自己编写程序代码比领导和管理那些编写代码的人员更有信心和技巧。

就像棒球教练那样，经理的出现应该贡献一些有别于增加另外一名球员所获的东西。有时候，这可能是解决争论或者让让球队远离政治；其他时候，是提供优秀的、高水平的计划，或者是寻找聪明的解决方法以处理意外状况。由于这些贡献难以估量，很多PM都为所处角色的模糊而挣扎。身为经理，他们很容易成为责难的对象，而且没什么地方可躲。身为团队领导者，必须将信念、自信和自觉结合起来，以同时获得效率和快乐。

利用好你的观点

寻找平衡点的最好方法就是利用不在生产线所能获得的心理差异。PM的职责自然使他会花比其他人更多的时间，来和团队中不同的人相处，因此，可以有更多信息来源，并对项目有更广阔的视野。PM会同时熟悉项目的业务视角以及技术视角，在需要时，可以协助这两个团队进行沟通。这种广阔的视角，使得在适当时机将重要信息传送给适当的人成为可能。虽然这种力量的影响很广，不过接下来的小故事，会以一种综合的方式协助说明这个观点。

作为习惯，我总是在走廊上走来走去，看见程序员的门开着，就走进去。我通常只是随便聊聊，尽量让他们为某事发笑，并让他们为我展示他们正在做的工作成果，如果他们有这些，我就会看他们的演示。每隔几天做一次，甚至每隔几分钟，这样通常可以让我对项目的实际状态有很好的了解（我们会在第9章讨论这种走动式管理的实践）。

例如，在做IE5.0项目时，有天早上，我走进Fred的办公室。他正和另一名程序员Steve在争论，关于如何让新的Listview控件正常工作——这是当天早上才发现的、预料之外的一个兼容性问题。他们两个都不想做这项工作。根据我所听到的内容，这将会花半天或更久才能解决。我走近他们，想确认他们讨论的内容，他们点了点头，好像在说：“是啊，关你什么事？”然后，我告诉他们可用去走廊尽头和Bill讨论一下。他们又问为什么，认为这是很特殊的架构问题，不是我能轻易理解的。我笑着说：“因为我刚刚离开他的办公室，他新做的树状控件在他的计算机上工作很好。他昨晚也遇上这个问题，并把它当成另一工作任务给解决了。”

当然，在这个小故事里，我不是在拯救世界或避开一场大灾难。如果我没替他们牵线，也只会浪费几小时或半天而已（不过，我们在第8章将会讨论，进度一般会稍稍落后）。但这不是重点。优秀项目经理的职责就是要知道关于团队状态、关于环境状态的所有有用的事情，并将其应用于其他场合，协助他人完成工作。就是这些微不足道并能实时传达的信息，正如这个故事中的场景，使平凡团队变成优秀团队、使优秀团队变成伟大团队。没有任何项目或bug跟踪系统能够完全替代人员彼此交谈关于项目的进展，因为社会网络总是强于科技网络（有时候会更快）。像项目远景、功能列表以及进度这些大挑战，总是会变成许多小挑战，知识和信息如果能够轻易在团队中流通，将对这些挑战产生积极的影响。关于能否顺畅地流通，项目经理扮演了关键的角色。

但是，无论大事还是小事，经理所做的行动和决策，对整个团队都应该有明确的效益。这也许要花一个星期或一个月才看得出成效，但优秀的项目经理会对工作成果的质量产生正面影响，而且通常也影响到相关人员的生活质量。人们对工作会有不同感受，会公开谈论他们对所做工作及他们选择该工作的原因有更深刻的理解，同时和从前比较，通常对即将面对的工作也会有更好的感觉。这类改变通常只会发生在一次会议、一个决策或一次讨论，但经历整个项目过程，这种共鸣和能量会急剧地转变和提高。

项目经理创造独特价值

因此，优秀的经理和领导者通常会赢得与那些其打交道的程序员、测试员、设计师、市场人员以及文档人员的特殊的尊敬。PM应该能够通过思考、策略以及领导力等各种比其他人多的方式，来积极影响团队。通常，这包括为日常工作流程寻找快捷和聪明的优化办法，或者在适当时机以适当方式给予他人帮助或激励。想做好这件事，他们不必当超人，也不用特别聪明（对此，我完全同意）。他们只需理解他人观点的好处，然后对其善用即可。

有一项简单明了的事实：项目经理或领导者与团队中与他人相处的时间多于任何人，他们需要开更多的会议、进入更多的办公室、和成员进行更多的会谈。在组织中，他们所作的决策或对决策的影响也比任何人多。如果项目经理高兴、难过、积极或失望，那么，这些情绪多少会影响他每天遇到的每个人。PM带给项目的东西，无论好坏，都会传播给团队的其他人。

所以，如果项目经理可以专心、坚定、积极而且有能力获取成功，那么每个人也具有同样行为的机率就会增加。任何类型的经理都有类似的潜力，在大多数工作环境中，没有多少具有很大价值的平衡点。这意味着，如果有可能培养我所谈的态度和想法，再也没有比领导者和经理更适合作为投资的对象了。这不是说项目经理必须是非常有魅力的英雄人物，只有耸耸肩就，能带领程序员团队投入战争（请参阅第11章的“英雄情结”一节）；取而代之，他只要诚心帮助团队成员做好汇报之事，并让结果更为成功即可。

最后，我相信的核心观念就是：只要没有人受伤（可能除了对手），参与的人都走正确的路，做出好的成果，那么其它的都不重要。只要结果是好的，有多少想法来自于你还是来自于其他人，并不重要。项目管理是以任何所需的方法，来增加实现积极结果的几率和速度。我每天所用的一句箴言是：让好事发生。人们会看见，我在走廊上或者白板边和程序员讨论，如果有人问：“嘿，Scott，你在做什么？”我会笑着说：“让好事发生。”这已成为我每天工作的主要部分。而且，当我管理其他项目时，这种态度也扩展出去，传播到整个团队。随着深入本书各个主题集中的章节，我希望你会感受到这种态度，本章的核心观点将逐渐得以展现。

摘要

本书每章结尾都有重点摘要，帮助你复习：

项目管理随处可见，而且历史悠久。

如果你保持初学者之心，你将更有机会进步。

项目管理可以是工作、角色或活动（无论你如何定义，本书的建议都适用于你）。

程序经理是微软强力定义的项目管理角色，它源自于矩阵式组织的思想。

领导力和管理需要对几个常见悖论的理解及直觉：包括自我/无我、独裁/委派，以及勇气/恐惧。

注意你在管理活动中的自负和过度参与。流程应支持团队，而不是以其他方式影响团队。

如果你是专职经理，要寻找合适的方式来利用你关于团队和项目的观点。

练习

A. 找几个与你工作领域不同的好朋友，问问他们是如何管理项目的？是否专门设立了项目领导这个特殊职位？还是将项目管理工作分配到多个人？

B. 作为优秀的PM，需要对各种观点进行平衡，PM如何决策才能不在某个方向走得过远？PM如何才能获取他人帮助，使其保持平衡。