信息系统项目管理师_2024年软考学习应考交流_信息系统项目管理师考试

标题: 《项目管理之美》样章更新中 [打印本页]

作者: chengrong 时间: 2009-4-29 18:30
标题: 《项目管理之美》样章更新中
本帖最后由 txish 于 2009-5-12 23:55 编辑

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

第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年）。

作者: txish 时间: 2009-4-29 22:48
好东西！我们会持续关注你的更新，呵呵，楼主加油！

作者: 废话大仙 时间: 2009-4-29 23:02
两个管理员顶，呵呵，好书共分享
一本好书，就看几段就能觉得获益匪浅

作者: chengrong 时间: 2009-5-6 10:43
本帖最后由 txish 于 2009-5-12 23:48 编辑

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章）。

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

作者: txish 时间: 2009-5-12 23:41
本帖最后由 txish 于 2009-5-12 23:52 编辑

(受楼主之托，代楼主继续发，感兴趣的同仁请继续关注)

项目管理的平衡之道

   很难找到好的项目经理，因为他们需要保持态度的平衡。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所犯的许多错误，都牵涉到对平衡一个或多个冲突力量的失算。然而，每个人都可以改善自己的能力，以平衡这些力量。所以，虽然我不会再多谈这些自相矛盾的悖论列表（虽然以后会再碰到几次），但这是值得参考的。看着这份冲突但却是必要的力量列表，可帮助你后退一步，重新思考你在做的事情及其原因，然后做出更为精明的决策。

作者: txish 时间: 2009-5-12 23:57
本帖最后由 txish 于 2009-5-12 23:58 编辑

压力和分心

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

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

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

流程与目标相混淆

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

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

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

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

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

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

作者: txish 时间: 2009-5-13 00:00
本帖最后由 txish 于 2009-5-13 00:04 编辑

适度参与

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

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

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

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

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

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

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

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

项目经理创造独特价值

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

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

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

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

作者: hyx1234 时间: 2009-5-13 15:21
不错,等你的续篇

作者: txish 时间: 2009-5-13 22:14
本章摘要

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

项目管理随处可见，而且历史悠久。
如果你保持初学者之心，你将更有机会进步。
项目管理可以是工作、角色或活动（无论你如何定义，本书的建议都适用于你）。
程序经理是微软强力定义的项目管理角色，它源自于矩阵式组织的思想。
领导力和管理需要对几个常见悖论的理解及直觉：包括自我/无我、独裁/委派，以及勇气/恐惧。
注意你在管理活动中的自负和过度参与。流程应支持团队，而不是以其他方式影响团队。
如果你是专职经理，要寻找合适的方式来利用你关于团队和项目的观点。
练习
A. 找几个与你工作领域不同的好朋友，问问他们是如何管理项目的？是否专门设立了项目领导这个特殊职位？还是将项目管理工作分配到多个人？
B. 作为优秀的PM，需要对各种观点进行平衡，PM如何决策才能不在某个方向走得过远？PM如何才能获取他人帮助，使其保持平衡。
C. 编造一个理由来推掉一次聚会。（从本书的第1章中幸免于难，这个理由充分吗？）当你从醉酒中恢复之后，并且当你将朋友从拘留所保释出来之后，考虑如下问题：聚会和项目有哪些不同？比较一下，作为聚会组织者和作为一个工作项目的项目经理，都有哪些挑战和利益？哪些是不同点？哪些是相同点？
D. 考虑你失败过的一个项目。你从中学到了什么？怎么学的？列出你曾犯过的错误，以及后来为了避免其再次发生，你是如何做的？回答本问题的过程将迫使你更小心地思考，并从这些经历中获得更多的见识。
E. 你能想象到一种不需要项目管理的工作吗？如果存在，在其领域，他们如何组织和计划工作？缺少组织会产生哪些限制？同时又带来哪些机会？
F. 你能建立领导力时刻吗？还是只有当那些脱离控制的事件发生时，该时刻才出现？如果你想增加展现领导力的时机，你需要怎样做？
G. 想像一下，如果一个团队，仅以人员对流程和规范的遵守程度，而不是完成目标，作为奖励标准。工作质量会如何？项目管理角色会如何？这说明，项目经理可以带来哪些可能的危险？
H. 中层管理者，或者管理经理的人员，由于处于组织的中间位置，尤其愿意过度参与工作，并建立不必要的流程。作为一个聪明的中层管理者，如何避免过细管理以及建立过多的规则？

作者: txish 时间: 2009-5-13 22:19
本帖最后由 txish 于 2009-5-13 22:28 编辑

不错,等你的续篇
hyx1234 发表于 2009-5-13 15:21

呵呵，回九楼的，我手头的资料是《项目管理之美》的样章，只有三章，我会逐节发上来。
不成体系，但就像废话大仙说的，一本好书，读每一部分的内容都会有相应的收获的，而且项目管理知识体系中，每一部分都有一定的相对的独立性，所以，我想对大家还是有用处的，请感兴趣的朋友们继续关注。

为了易于大家阅读，我每次只发一两个章节。如果有意见或者建议，大家可以跟帖提出来。

作者: txish 时间: 2009-5-13 22:24
本帖最后由 txish 于 2009-5-13 22:25 编辑

选自《项目管理之美》样章
第10章怎样才能不惹恼别人：流程、电子邮件和会议

官僚是一种行政体系，其中需要或倾向于遵照呆板或复杂的程序，对有效率的行动产生阻碍。

你的团队越大，你的项目管理活动让人讨厌的可能就越大。每当你追踪其他人的工作，或者做出会影响其他人的决策时，可能就会惹恼他人；这与领域有关。如果你很聪明，就会找到方法把烦恼之事减到最少。他们会比较开心，项目也会运作得很好，而你在门厅中也不会看到很多人脸色十分难看。

最可能惹恼大家的三项活动是电子邮件、会议以及团队流程（例如构建流程或规格说明书撰写流程）。本章要讨论执行这些任务常犯的错误，以及让你以最小激怒风险因子（minimal annoyance risk factor，MARF）执行这些任务的基本方法。

人们被激怒的原因概述

因为我找不到有关恼怒历史的出版物，我只能依靠自己的观察，总结人们为什么会被惹怒。我在这方面有很多经验：我被惹恼过很多次，也见证过其他人处于生气中的状态，而且也知道偶尔也会惹恼其他人。

为了完全了解这些实例，描述时都以第一人称来表达（阅读时，想到你曾经和某个特殊的你所尊重的人一起工作的经历，应该会有所帮助）。

*  假设我是白痴。如果我受聘来做X，我能把它做好，无论何时，只要有人认为我无法做到X——或者需要20步的过程、规则手册、模板、每日评估、委员会或其它可以让我做X的流程——我当然有理由被惹火了。我的部分工作应该是帮助定义我的工作内容，并以某种能满足管理阶层颁布的任何目标的方法。我应该被当成有能力才对，除非我失败了并且证明我能力不足。只要合理，我应该能自由决定完成我工作的最好方法。

*  不信任我。如果每天我都被指望要签入程序，并且一而再，再而三地检查，并要求汇报那些在我职责范围内所做的决策，我就会被激怒。如果什么事我都得确认，我究竟还有什么权限？如果我做得很好，为什么还要把每件事都写在文件上、记录下来？即使一开始因为某些原因我不值得信任，但管理阶层的工作应该是提供一条公平的道路让我去赢得信任，并让我在那条路上继续前进。

*  浪费我的时间。如果团队的运作方法逼得我不断重复（无聊的）任务很多次，或者要做一些和我职务无关的事，去防止可笑而不可能发生、而且又无关紧要的偶然事件和管理阶层的妄想，我就会被激怒。这包括重要决策的改变，或者传达的信息或行为非常不一致，甚至在被询问时，也没有试着去解释（或者至少说声抱歉）。

*  对我不尊重。如果派我去做些白费力气的事，指派给我的工作没有实际的基础，或者注定会失败，却因为那些超越我职责范围的事情而指责我，我就会被激怒。应该要有人看着我，确保我的努力和项目的目标一致，指引我走向成功。因此，我请求协助，应该被认真看待，而不是一直被拖延或者忽视。

*  让我听或读些蠢事。不管什么时候，要我去听其他人讲话，或者读另一个人写的东西，而这和我们正在做的工作没什么关系，我就会被激怒。对于bug的质量，我们有分类标准，为什么对蠢事却没分类？有人说召集开会、写文件或发电子邮件，并不说明这些就值得我花时间去做。越是要求（或逼迫）我去做次要或更次要的工作，我就越没生产力，越不高兴。

惹怒的很多原因，可以解释为什么很多人都讨厌工作流程的想法。他们害怕任何试图将他们的工作系统化的事，最后只会导致官僚或其它形式的受难。我想，这种恐惧是没有事实根据的。就和其它事情一样，流程也是人设计出来的，只要设计者很聪明，心中有正确的目标，流程就能对每个人有益处。流程可以帮助大家，而不是限制和惹恼大家。

(未完待续，请感兴趣的朋友继续关注)

作者: txish 时间: 2009-5-15 12:41
本帖最后由 txish 于 2009-5-15 12:44 编辑

好流程的效果

我把流程定义为任何可重复的一组动作，由团队决定定期执行以确保事情会以某种方式完成。流程有很多其它名称：规则、指导方针、形式、程序或限制规定。（例如，如何签入代码、测试和构建，就是工程流程的常见实例。其它实例包括规格说明书的撰写和管理日程表和进度表等等）。好的流程可以提高项目完工的机会，而且效益要大于成本。然而，因为很少花时间研究流程存在的原因，或者流程（应该）解决什么问题，所以很多团队只是空有很多流程而已，无法从中获得益处。

有时，问题出在是谁有权力身上。任何有足够权限的白痴，都可以想像出最令人厌恶的白痴体制来做事，并且逼迫团队服从它。结果，当团队奋力在那个流程下求生存而且真的做出一些事情时，掌权的人可能甚至会说，那个流程对事情成功起到了贡献（却看不见，即使没有那个愚蠢的流程，团队也一样会成功）。如果他们有足够的权力，他们可以镇压任何反抗，甚至继续增加更多步骤来折磨团队。

其它时间，问题在于哲学观：X以前行有效，所以，我们就做X吧。”在这种情况下，团队领导者过去曾以某种方式完成事情，就会坚持把该方法或流程强加到他所带领的没一个新团队上（第8章提到了这种不良管理习惯）。这种习惯不好，因为只有当前的情况类似于过去的情况，否则之前X能成功，与现在无关。对流程的实际接受度测试，应该重点强调当前的需求，而不是观察过去。

但是通常问题在于建立流程的复杂度。流程是试着组织大家如何工作和互动的，这两件事非常重要，但又非常有组织。人们的工作方式不同——他们对正式的控制有不同的偏好和容忍度。如果建立流程的人不注意，这个流程很容易变成瓶颈，让人们的工作慢下来，束缚他们的自由（感觉）和活力。

建立好流程的技巧，就是要了解两件事：通常能让项目和团队成功的事项，以及使当前项目和团队与其它项目和团队有所不同的事项（请参阅图10-1）。了解通常如何制定好的团队决策是不够的：你必须对共事的当前团队的文化、个性和习惯负责。有时，不同的文化或项目需要不同的方法（例如，防抱死刹车嵌入系统的决定，和Steve朋克摇滚乐队网站的决定是不一样的）。通常，最好是让团队自行管理，而不要让上级单位管理。让团队修改和创建自己的标准规范，而不是复用标准模板。就像任何类型的协商那样（请参阅第11章），涉及到流程时，你必须要清楚知道你关心的利益，而不是特殊的立场。

作者: txish 时间: 2009-5-15 12:43
本帖最后由 txish 于 2009-5-15 12:45 编辑

可在此找到好的流程

通常能让团队有效的事情

使得这个团队/项目和其它的有所不同的事情

图10-1：好的流程通常需要对项目有感觉，还需要认识当前项目的独特属性。

为了帮助你寻找并辨认好的流程，这里列出了好流程的特征，和其对项目所造成的影响结果。当你坐下来建立或改进流程时，这份列表可以作为检查列表来使用。

* 加速事情的进展。看起来似乎违反直觉，但是好的流程会让人更加有效率。例如，美国高速公路上的白色分隔线限制你能往哪里开。但是，因为每个人都受到同样限制，所以，每个驾驶员都能开得很快。好的流程提供了人们可以依赖，并根据其定决策的系统。在某些情况下，程序定义了人们扮演的角色，使得Steve从Molly那里获得他所需要的东西会非常容易（例如，找人查看程序代码）。一个规范的实例是自动化构建工具，可以让人按几个按键就能构建项目工作，只要他们按照构建系统所定义的设计要求进行。

* 防止问题。适当制定流程的最常见动机，就是防止某种愚蠢的事情发生（或再次发生）。挑战在于做此的同时不让事情的进展变得更困难，或滋生其它蠢事。这需要了解问题的起因，以及哪些因素对事情的进展最重要。只要问：“要确保X、Y、Z不再发生，最没有干扰、最不会惹恼人和最便宜的方法是什么？”或者，走另一条路，“这个流程能够防止什么问题发生？那个问题有多严重或可能怎样？”如果流程没有防止问题出现或者加速流程进展，就放弃它。

* 让重要行动可见和可测量。通过公开bug或发布规格说明书的流程，可以轻易追踪这些事情多久会发生。你也可以追踪它们的状态、结果如何以及团队整体的趋势。对于bug、规格说明书和测试而言，好的流程会很容易使其找出项目的状态。这对中盘战略和终局战略非常重要（请参阅第14、15章）。

* 包扩修改或删除此流程的流程。因为项目随时在变，这个月有用的流程，到了下个月也许就没有用了。流程必须有内置的机制，可以决定何时需要更新或者停止。绝不要假设流程可一直用下去，而且因为这个原因，要避免围绕流程定义工作。某人认为本身的工作是“执行测试通过5的人”，会用生命保卫测试通过5。相反，要让人们对流程在项目上的影响和结果负责，而不是项目本身。

* 受到影响的人会赞同。人们喜欢有帮助的流程。好的流程对那些需要的人来说是值得的。如果你提出的一个新流程会影响到程序员，但你的流程对项目有价值，这应该很容易让他们试一试。人们应该直接参与制定他们会使用的新流程。可选择地，如果会受提议中的流程影响的人，能够列举出数十个理由来指出为什么这个流程很差，他们也许是对的。

作者: txish 时间: 2009-5-16 16:46
好流程的公式

思考流程的一种方式是考虑流程正面效应的价值与实际的制定和运行成本的对比。有个公式可以帮助比较。你不需要为公式找到实际的数字就能使用它。我提出来它，主要是做为练习，来帮助你思考与增加工程流程有关的代价。如果你不喜欢练习或公式，就跳到下一节：这不会错过重点。

首先，考虑流程的成本：设计流程的时间（DT），加上团队学习它的时间（LT），加上通过流程做事的实际工作时间乘以使用的频率（AT×N）。任何流程的总成本就是：
DT＋LT＋（AT×N）

然后，考虑流程的效益：流程避开的失败成本（FC），乘以单位时间内没有这个流程时，失败情况发生的机率（FP），再乘以项目里有多少单位时间（T）。
总效益＝（FC×FP）×T

结果大概是：
流程价值＝（（FC×FP）×T）-（DT＋LT＋（AT×N））

我完全承认，公式中全部都是过度的简化，但是它的精神已足以令人感兴趣。如果结果是高分，就比低分更有价值。负分表明流程效益比成本低。

开始开起来，这个公式表明，很容易建立能有效消除问题的流程。然而，这么做的代价，可能超出一辈子跟那个问题共存的风险性（例如，为饼干罐买价值5000美元的安全系统）。如果你把设计时间和学习时间包含进来，确认只有失败的可能，那么修改流程就不符合成本效益。

然而，你必须考虑效益的生命周期：它们通常会横跨多个项目。更重要的是，后续几个项目的失败几率可能增加到100％。公式中的T值很重要：即使失败几率（FP）很低，但时间间隔越长，失败发生的机会就越大，采用流程防止发生的价值也越大。（这里显示出作为领导者的主要挑战之一：决定何时付出有形的短期成本，以获取较不明显的长期收益。这种挑战到处都是：雇用、设备、工具、培训等。种瓜得瓜，种豆得豆；长期投资是获取长期提高的唯一方法。）

关于这个公式，最后一点要注意：AT值（使用此流程的实际时间）比看上去的要重要。好的流程应该要让事情花费较少的时间；与没有这个流程而完成工作所需的时间相比，如果真能节省时间，AT值应为负值。这改变了等式中构建的成本/效益关系。例如，如果AT等于5小时，但之前此任务花费7小时，净值就是2小时。这表示现在完成此任务少花2小时，流程的整体价值就更高了。

如何建立流程并付诸实践

当你找出一个问题，觉得可以用流程来解决时，就按照我在第11章所提及的那个粗略步骤来做。（即使你不是面临危机，执行短期计划的基本步骤也如此。）明确定义你试图解决的问题以及最能帮助解决此问题的小组人员。以小组方式运作，产生几个替代方案，然后，挑选最有希望的一个来执行。

接着，找出项目中可独立出来的低风险部分，来试验这个新的流程。如果可能的话，找几个对改变流程有兴趣，并且善于接受的人，让他们参与创建流程。要对流程改变后应该有的效果达成一致意见，可能的话，要为它们制定测量标准。然后，让相关的人参与制定改变。设定未来的日期，用以评估流程改变后的效用。

当评估日期到了时，再次和小组以及试验相关的人一起开会。讨论发生了什么事。如果试验是场灾难，就重复流程，做第二次小试验。否则，就根据你们学到的东西修改流程，再应用到较大的小组中（可能是整个团队）。每个被要求使用此流程的人，都应该清楚你试着解决什么问题，以及是什么原因说服你这个提议的方法会的确帮助你（参与试验的人给你的证据和证词应该大有帮助）。

作者: txish 时间: 2009-5-16 16:49
本帖最后由 txish 于 2009-5-16 16:50 编辑

从下层管理流程

“绝不要低估大型团体里蠢人的能力。” ——Todd Blanchard

有时，比你更有权力的人会强加给你的团队那些你们不同意的流程。你们可能只是人数占优势，或者没有权力修改流程。我们之中最优秀的人就碰过这种事。我知道有三种方式可以对付这种情况。虽然不总是有效，但值得一试。

* 替你的团队挡开流程。有时，你可以为你的团队吸收流程。如果必须完成某些书面工作，你可以自己做。这可能让你觉得自己好像是团队的秘书，但是，如果你只花掉一个下午时间，而你的团队就不用浪费时间，这样的代价可能是值得的。在某些情况中，替他们挡掉蠢事，会让你从团队那儿赢得很多信任分。工作时间记录卡、费用报告、强制性（但也很可笑）HR类型会议、设备申请和其它恼人的琐事，都是常见的可轻易挡开的流程实例。

* 打赌不适合流程。召集你的团队，讨论对流程的反意见。找出流程试图预防或确保的事，并对当权者保证，没有这个流程，你的团队也能实现那些目标。设定一段时间做评估。如果在那时间之后你的团队失败了，你就同意采用流程。但如果他们成功了，你就不再理会这个提案。至少，这样可以把对流程的讨论集中在正确的问题上（我们试图解决什么问题？），所以，即使你失败了，也会得到一个改善后的流程。（在一些罕见的案例中，利用对其他类似而成功的组织进行的研究成果，或者以某种不太愚蠢的方式来做，可以获得支持，并避免打赌的需要。）

* 忽视流程。我倾向于忽视那些我不了解的遥远的、模糊的、官僚的、组织性的事情。我的理论是，通过忽视它，我会迫使两件事的其中之一发生。或者负责那件事的人会和我联系，问我为什么没做，给我机会和他对话，了解我为什么到底应该做；或者，如果没有人问我为什么没做，那么可能就是没那么重要。我将继续做我的事，没有那件有争议的事，我会很成功，同时，如果日后有人问我为什么没做这件事，我也有很好的正当理由（“哦，嗯，没有那件事，我们也把X做得很好。也许你可以说服我，Y应该有什么帮助？”）。在新的组织中，这通常很有效，因为你有对组织有不熟的额外借口。不过，要小心：你的政治前景可能因为忽视官僚，而让你身陷危险之中。

作者: 废话大仙 时间: 2009-5-20 21:16
我也来顶

作者: txish 时间: 2009-5-28 22:58
本帖最后由 txish 于 2009-5-28 23:00 编辑

不令人讨厌的电子邮件

虽然邮件的主题似乎有助于阅览，电子邮件仍然是人们处理项目时，最令人讨厌的系统。因为我们收到的电子邮件数量太多，要尽可能快速阅读和回应新邮件，自然就会感到压力，通常也会牺牲好的阅读质量和写作技巧。多数人都不会认真阅读或写好电子邮件。讽刺的是，当我们无法理解别人到底想说什么时，或者无法让他们理解我们想说什么时，电子邮件的便捷也就被浪费了。

对项目经理们最重要的，就是电子邮件是和领导们沟通的基本方式。在创建新邮件和回应其他人发送的邮件时，领导者会影响项目内的信息流动。如果领导者有明确的想法，提出实质的问题，就等于鼓励其他人也这么做。对与数十人进行的广泛讨论做一次响应，就可以让清楚的想法传递给整个组织。但是，如果领导者思路表达模糊，常发表不清或混乱的观点，就会破坏团队的沟通能力。

一个主要的挑战就是，很少有人承认他们寄出了很差的电子邮件。例如，做以下测试：利用你自己的主观判断，你从自己组织成员那儿收到的电子邮件中，具有高质量邮件的百分比是多少？中等质量的是多少？完全没有用的是多少？现在，问你自己，你寄的电子邮件中，各有多少百分比符合这每一种情况。以此为试验，我曾问过一个由PM、测试员和程序员所组成的小团体这个问题。差不多2比1，每个人都认为其他人写的垃圾邮件比他们自己写的还多。因为他们都一起工作，这个有趣的数据表明，每个人都认为问题都是由别人写的邮件引起的，而不是自己的。我没有更有力的数据可以支持这种主张，但确实如此。不知何故，当沟失败时，人们一般倾向于责怪他人（要找更多的证据，只要看西方文明的国际政治史就可以了）。

好的电子邮件

我在微软学到的一个习惯就是奖励好的电子邮件。很多重要的讨论都会在电子邮件里进行，这类讨论常常使不同阶层的人参与进来——产品线PM、中层经理，VP也许会来回交换邮件，将彼此几乎视为平等的。我发现自己也时常身陷这些争论之中，通常是因为我负责的事突然间成为公司的关键。

在这些电子邮件的讨论中，我经常对其他人所说的某件事，做出强烈的回应。我谨慎用字，不断修改到正好为止：简单、强硬而清晰。然后我再把它发出去。我的论点有时被粉碎，有时被忽视。不过，偶尔我击出全垒打。几分钟后，通常会接到VP或“其他比我重要的人”私下发给我的电子邮件：“邮件不错”。讨论也许还在继续，但我知道我已在讨论中取得成功。更重要的是：有人花时间让我知道我的观点很好，而且我表达它们的方式获得了赞赏。1

注释1：我一直保留着那些赞赏的电子邮件，有点不好意思，可能是因为管理层没有做出足够的赞赏。IM和电子邮件所能提供的，和开会时点个头或来个微笑这种次要的反馈不一样：也许这些额外的电子邮件，以某种方式补偿了这一点。

聪明的经理人会重视好的电子邮件。经理们每天都要读一堆写得很糟糕的电子邮件，如果他们不花时间赞美那些沟通良好的人，就不可能看见更多人这么做。稍微处理的电子邮件大约只花15秒就能寄出，就我的故事表明，这种信对组织中的其他人而言，要意味着比你想的还要多的事情。

但是，赞美他人容易，要对自己发送差邮件的习惯负责就难了。如前所述，我相信多数人都认为，他们写的电子邮件比别人认为的要好（你越认为自己写得好，就越难得到有关你电子邮件礼节的诚实反馈）。因为领导者和经理们发的邮件比别人多，找出你有什么坏习惯并投人精力加以改正，是很重要的。以下是一些关于项目管理的建议，指出好的电子邮件应该是什么样子，以及有哪些常见的不好习惯。

* 要明确、简单和直接。数学家帕斯卡，Pascal程序语言就是以他命名，曾写过；“如果有更多的时间，我会写更短的信。”语言就像程序一样，可以最优化。你想让沟通效率最优化，而不是让逻辑效率最优化。如果收件者无法理解由语法和逻辑都正确的三个字所传递的消息到底是什么意思，那么它是无用的，这一点和代码不同。2要考虑谁会读这封电子邮件，如果你和他面对面交谈，你要如何解释？还需要什么细节？能省略什么？你能假定他知道哪些概念？你能够使用哪些比喻？对于重要的电子邮件，在发出之前，先离开几分钟，然后再回来读一遍，在你发送它之前，脑海中想着那些问题。对于重要的电子邮件，或者要发送给一大群人的邮件，要让你团队中的某个人先流览一遍，并给你一些反馈。

注释2：关于Victor Hugo但可能是捏造的故事，描述了聪明地利用简洁沟通。当《悲惨世界》出版时，Hugo给出版商发了一封电报询问结果。他的电报尽可能简洁，只有一个字符“？”，而他收到的回应也只有一个字符“！”。显然，销售相当可观。如果这里有什么可学的，那就是两个彼此非常了解的人，能够比其他互相不了解的人沟通起来更加有效，这也是和同事发展人际关系的另一个重要原因。

* 提出行动和截止期限。最好的电子邮件有明确陈述的特定要求，而且在适当情况下确定了合理的截止期限。应该很容易就让人读懂电子邮件，了解他们为什么收到这封电子邮件，采取行动会对如何影他们，以及他们必须做什么（在截止期限前）。假设你坚持截止期限（“这些要求必须在周五给我”），那就等于你通过电子邮件交流，让人注意到未来的行动，使你处于有权力的立场。

* 优先级。有其必要发送这封电子邮件吗？你发的邮件越多，其他人就越要对你要求的事排出优先顺序。有多少你提到的事情是重要的？如果你有10个问题要讨论，就把它们分成两组，集中焦点在最重要的一组。考虑是否有哪些事情可以用电话处理，在下次团队会议中处理，或者挨个办公室去谈来处理。如果你没有分出优先级，却希望收件者为你分出优先级——那他们只会按照他们的利益去区分，而不是按照你的。

* 不要假设人们会读所有东西（尤其是对你特别重要的）。因为你发了邮件，别人就要读，这是很傲慢的想法。人们每天都收到很多电子邮件，多数都来自和你一样重要的人。问题对你越重要，你就越得花心思以确保人们真的会积极针对邮件做些事情。你和团队成员之间建立的信任越多，就越能假设人们会如何回应你发的邮件。

* 避免太详细。很少有情况是让每个人必须了解导致事件发生的前因后果。要避免在写电子邮件时，把焦点放在不同参与者所贡献的行动上：“当Sally第一次设计我们的构建流程时，她对……感兴趣”，或者像叙述式的散文一样，“会议召开顺利，Bob和Steve以极大的热情和信念谈论他们的幻灯片。就是这样，直到……”相反，应该集中在影响上：发生了什么事？会如何改变世界？以及我们应该为此做些什么？如果你被迫加入一些背景细节，就把它们列在要点之后。对于幻灯片、网站、文件等参考资料，也这么处理。尽量让每个人都能尽快看过前两行之后，就能立刻知道是否足够重要，值得他们继续读下去。

* 隔离FYI（For Your Information，供你参考）信件。我曾经待过一些团队，他们坚持转寄大量有些有趣，但和任何事都没有直接关系的电子邮件。有些人称这类邮件为FYI邮件，也就是供你参考的电子邮件。好奇心和了解业界状态都是良好的习惯，但不要让这些事主导了用于更实际工作的沟通论坛。设立另一个电子邮件名或讨论组，专供“业内趋势”或“技术展望”使用，让你的团队可以把他们发现的很酷的东西放上去。如果你的邮箱委托人支持它，就让每个人把这类邮件设为低优先级，或者在主题栏开头加上“FYI：”。让大家很容易把它们过滤出来。

* 电话是你的朋友。如果你不明白你收到的重要电子邮件中的某些事，就不要回复一封包括精致的五部分问题的邮件。看看你是否能用电话联发件人。交互式沟通在解决困惑和冲突时，总是比电子邮件更好用。30秒的电话交谈，通常相当于一长串费时的电子邮件交换。如果真的能用电话联系发件人并解决问题，那么你就能在电子邮件中写出你已理清的理解并分享给每个人——如果你感到困惑，其他人可能也是如此。电话（或走到门厅）是群体电子邮件沟通的重要促进工具。3

注释3：可能有种沟通定律主张，沟通的优势模式（电子邮件）依然依靠之前的优势模式（电话）：IM一电子邮件一电话一传统邮件一烟雾信号一面对面等。

作者: txish 时间: 2009-5-28 23:05
差的电子邮件实例

吓人的电子邮件很容易就被识别出来。吓人的电子邮件通常很长，写得也很差，有很多附件，而且很难略读。很明显就能看出来，这通常会被忽略或被适度提出疑义：“Fred，我发现这封电子邮件很难懂。如果其他人同意，你可以修改一下或召集会议说明吗？如果不行，我再打给你。谢谢。”因此，吓人的电子邮件并不是最危险的那种。

真正危险的电子邮件，是那些看起来写得很好，但实际上却充满了让人分心的东西，想法也不全面，而且令人模糊不清的邮件。下面是相同内容的两封电子邮件实例：一封很差，一封很好。这是很差的那封：

寄件人：Jack Colono
收件人：前锋开发团队

主题：最近检查讨论摘要

过去四周以来，我们之中有很多人想知道，我们重新设计的程序代码签入流程，什么时候可以最终完成。我知道我们花了很长时间在门厅和会议室里讨论，想找出正确的方法来决策，但却没有了解新流程的实质设计。挑选委员会成员对我来说也不容易，很多人都知道，花的时间要比预期多。我为此感到道歉，但这些事还是发生了。
所以，首先，我想让你们知道新提案的一些重点，避免有人错过了我们的周会讨论，或者这两周没有和我谈过情况：

   1．签入程序非常重要。它们决定我们到底在构建什么。
   2．每个人都有意见。我们都听过Randy和Bob各自的详细描述，解释他们认为当前系统这么糟糕的原因。
   3．没有简单的答案。我们讨论过的多数修改都有缺点。所以，当我们最后达成结论时，在转换时期会有一些粗糙之处，而且可能会持续不断。

得出这些结论后，现在我想让你们知道，本周剩下的时间我会给你们发去修改过的提案。请注意我发的下一封电子邮件，应该很快就会发了。

谢谢。

   Jack

很好的电子邮件实例

和很差的邮件不同，这封电子邮件没有提到任何情节，或试着为任何事情辩解：所有都是关于行动。电子邮件内容很短、又十分明确而且抓住重点。它实际提供了提案，而不是在谈论那些提案。虽然有最后通碟的味道，但确实达到为提案建立逃逸速度的目的，以帮助把提案推出。

寄件人：Jack Colono
收件人：前锋开发团队

主题：新的签入程序流程

新的签入程序流程的最终提案已完成，放在网站上：http://intman/proc/checkin/。

因为这是一个有争议的问题，我已经和团队中的多数人一对一地讨论过这个提案，整合了每个人的反馈意见。如果其中没包括你的，而你有强烈意见，请尽快发给我。
但要注意：关于这些即将到来的改变，这是第二次公开声明。目前修改的机会很小，今后会更小。请现在就采取行动，不然就保持沉默。

周五下午五点，是针对上述提案和我联络以提出反馈意见的截止时间。在那之前，我会考虑和回应任何问题或意见（和适当的人共同研究）；否则，这件事就这样，并在下周开始生效。

谢谢。

   Jack

不用对范例中的内容深入细读，就会发现这两封电子邮件的差异很明显。这些电子邮件不是应该怎么做什么或不应该做什么的模板。你寄出的每封电子邮件都有不同的目的，和这些范例不同也许有其道理。只要你写的时候经过深思熟虑，有明确原因，就去做任何必要的事。但总是要寻找方法直指要点，利用电子邮件使事情发生。

作者: txish 时间: 2009-5-30 21:29
本帖最后由 txish 于 2009-5-30 21:31 编辑

如何召开不让人讨厌的会议

以下是我对会议的看法：我不喜欢定期开会。除非有股力量可使会议保持精简利落，否则最后都会变成缓慢、膨胀、令人沮丧、功能紊乱地浪费时间。然而，如果有那股力量存在，会议就会变得有活力、能把房间内每个人的经验集中起来。挑战在于，无论是谁组织和主持会议，都必须知道他在做什么。

初学者要了解开会有多昂贵。如果会议持续1小时，有10个人在那里，会议的成本就是10人1小时。整个团队被关在会议室里，等候着值得他们花时间的事情发生，而不是去修改bug或结束问题——这是两种保证事情有进展的形式。事情也许会发生，也许不会发生。所以，我认为程序员和其他人抱怨开会是有理由的；相对于待在计算机前时间的价值，开会用掉的时间通常没有什么价值。

然而，如果因为要公布重要想法或决策而需要大家参加开会，会议产生的信息会改变每个人参会后的行为，或者深入了解项目进行中的事项或受到激励，那么，这种会议的价值就比较高。开会就不再是杂物事，而是一种难以靠其它方式消化或交换信息的方式。

促进的艺术

几年前，我记得曾对如何构建Windows系统的重要部分有过重大争论。我提前到了，看着每个人走进会议室并坐下，对他们自己的意见有信心而自鸣得意。我看着他们斜靠在椅背上，在会议开始前，演练他们脑海中的论据。当然，争论恰恰就是我们要做的事。10分钟的时间，讨论就在大浪里来来回回。白板上尽是些非常潦草而且互相冲突的图表，完全无法达成一致意见，到处都是讽刺的陈述和修辞性的质问。最后，我的组经理Hadi Partovi站了起来，他安静地走到房间前方的白板前。

一句话也没说，他就列了一份问题列表。房间安静了下来。每个人都停止了争论，看着他在做些什么。当他写完时，他问白板上写的是否是正确问题。每个人都点头。然后，他让我们一次解决一个问题。其中还是有争议，但有了架构，就戏剧性地大幅减少了。Hadi没有提出自己的意见（虽然我知道他有意见）。相反，他花费精力帮助我们探索我们认同的问题。这就是促进的艺术。

促进（facilitate，动词）：让事情变得简单或更简单的行动。

只有当房间内有人知道如何促进，才会开好会议。有些人出于本能这么做，而有些人甚至连做的时候也没有意识到。就像其它人与人之间互动的技巧一样，人们对进行互动的各种方式以及如何影响它，也有不同层次的认识。

促进者可以是一种半正式的角色，由组织展示的指定人选担任（通常是PM），或者由召开会议的人担任。有的团队有很强的促进文化（表示很多人有这种技巧），因此，在会谈过程中，他们可以自然地转换由谁来扮演这一角色。但是，多数时候，对多数项目来说，开会时都特别需要促进的才能。
促进指标
促进是多数团队都视为理所当然的一种技巧。有一些书4和课程都在谈如何促进，但是，如果你想了解所涉及的技巧，最好的办法是观察能做得很好的人，然后试着在下次你组织的会议中，应用你观察到的技巧。然而，有一些指标值得一提。我花了很长时间才了解这些指标，它们可长期帮助你发展自己的各种自然促进技巧。

注释4：两本起步的好书是Tom Justice所著的The Facilitator’s Fieldbook（American Management Association出版，1999年）和Thomas A. Kayser所著的Mining Group Gold （McGraw-Hill出版，1991年）。

* 建立主人的地位。如果你是会议的组织者，那么你就是实际上的促进者。会议开始时，先介绍参会人、澄清日程，然后开始讨论。如果你从人们走进门的那一刻起就像个主人，他们就会表现得像客人，很尊重地对待你。谨慎选择你坐在房间里的位置：坐在桌子前端或中心区，会给你最多的权威感，而坐在角落给你的权威感最少。

* 倾听和反映。促进者的核心作用就是帮助他人沟通。如果有人说了不完整的事（但不是完全没有价值），就要帮助他发展完整这个想法。试一试重复他人说话内容的反映技巧（reflection trick）：“所以，Mike，我想你是说（加入Mike想表达观点的较好说法）。对吧？”这样不但提炼了他的观点，也为大家示范了该如何合作讨论。然而，要小心地把想支持自己想法的愿望隔离出来——如果你被自己的议程所负累，就很难做个称职的促进者。有些组织会聘请专业的促进者，来帮助解决有争论的会议并提供咨询。

* 引导会谈。以议程作为向导，必要时跳出来，把讨论推回必要的正轨。要有灵活性，让人表达自己，如果议程指出要往西走，而会谈却往南去，那就必须做些事情。礼貌地打断谈话，指着墙上的议程，要求他们暂时搁置眼前的讨论，直到日程中的问题都结束为止（或者，如果新问题非常有价值，可以提议调整日程）。注意看谁讲得太多，谁又说得太少，根据情况控制发言权（“Bob，暂停一下……Steve，对此你还有什么想法吗？”）。

* 结束会谈。对于问题应该何时改到其它地方解决，你的心里要有个标准。通常确认问题，找出由谁来负责，要求那个人自己进行，明天或后天再把提议的方案拿出来，这样就足够了。这是很好的方式，可以结束占用会议时间的不必要争论：“嘘……，大家暂停。Sam和Bob，你们两个去了解和处理这个问题，好吗？到时再回来，让我们知道你们的决定。”当其他五、六个人已经厌烦了一整小时，绝不要再让两个人控制发言权。

* 制造历史。花时间记录讨论内容（如果有可能，发生时就记录）。作为促进者，这可以帮助你追踪议程的进度，和帮你与小组进行沟通。因此，我完全迷上了白板。白板是最容易的方式，可以抓住人们所说的事，列出待办事项的列表，或者找出一致（不一致）的观点。但是，你要怎么做并不重要。重要的是当会议结束时，接下来的步骤和会议重点已被记录下来，发送给那些参会的人。有人说，记录员是个有权力的职位，因为你可以影响事情记录的方式和要强调哪些方面。即使情况不是这样，发送记录的确提供了推进作用，使别人理清你误记的事情。

即使你不同意这些指标，我还是希望它们能够帮助你了解开会时需要有个领导角色。如果没人积极扮演这个角色，会议就倾向于令人沮丧而且/或者让人感觉很无聊。一般的看法是“开会很让人讨厌，尽量避免。”但真正的问题是会议应该怎么开，而不是会议本身的观点。

作者: txish 时间: 2009-5-30 21:36
本帖最后由 txish 于 2009-5-30 21:50 编辑

三种会议

对会议组织者最大的陷阶，就是忘了会议有多么多面。不是所有的会议都以同样的方式召开，或者应该有相同的结构。90％的人认为很多会议很无聊的原因，是因为目标和会议的结构、大小互相冲突。超过七、八人时，不管谁在促进，都无法进行高度互动的讨论。以非常粗略的规则来分，有三种会议，各有不同的限制和应用。一定要考虑哪种会议最适用于必须要解决的问题。

* 高度互动的讨论。希望会议中的每个人都参与。目标：深度和密切。焦点：探索或解决特殊问题，或者寻找可替代的想法。大小：小到中（2～8人）。实例：设计讨论、头脑风暴、危机管理和分类。

* 报告或一般的讨论。有人要公布信息，而他需要人们响应或理解那些内容。目标：获得高层次的反馈或分享知识。这也可以是高度互动的，但只会在群体中的少数人之间发生。有几个人会在会议期间取得发言权，驱动者和响应者的角色会改变。大小：中到大（5～15人）。实例：规格说明书查看、架构查看、管理查看以及小型展示。

* 状态和项目查看。目标是总结团队或整个项目的状态。给领导者机会，让他在过程中做出修正，并立刻从管理阶层提出新指令给全组成员。当这类会议包括搜集状态的活动，或者迫使每个人听取状态报告时，这些通常就是全世界最无聊的体验了。大小：中到大（0～100人）。实例：状态查看、项目查看、大型展示以及全体会议。
当目标和会议的组织方式不一致时，最令人讨厌的会议就会发生。如果房间内有10多个人，就很难有高度互动或深入的讨论。每个参与的人没有足够时间，结果就会出现一小群有主导个性的人会用掉大部分可用的时间（除非有人在促进会议来避开这种状况；然而有一小群有主导性格的人，也不总是坏事）。多数委员会因为采取这种形式，而做出可预期的没有价值的结果。

周期性会议的祸害

第二最令人讨厌的会议，就是周期性会议（每周、每天、每月），尽管已经不需要，却还是会持续数周（微软的一些大楼里，根本无法订会议室，因为被已经放弃的周期性会议塞满了会议室预订系统）。周期性会议能为工作制定一种节奏，迫使大家在同一时间待在同一房间内，这点很好。当大家实际聚在一起时，所有小问题就能快速且随意地解决，而且可以每周相互会面一次或多次。“哦，嘿，Sam，我一直想问你……这个API要改变吗？我看见你的签入，我想这可能会影响我，但我不能确定。”电子邮件和打电话不保证会有响应，但是，当别人坐在你旁边时，你通常会得到你所想要的。

问题在于，太容易召开的周期性会议了，以至于这类会议的价值失去以后它还能持续很久。当有些人不再来时，或者其他人利用这段时间用笔记本电脑检查电子邮件时，这就表示出问题了；这种会议不再值得花时间召开了。经理们（以及其它会议组织者）常有的恐惧就是取消这类会议，他们便会失去控制。但是相反地，拿不需要的会议折磨团队，正好是经理人失去他们试图保护的影响力的原因。

这有一条好规则：选择参加会议（opt-in meetings）。把周期性会议放在进度表上，并要求每个人在会议召开前5分钟检查电子邮件，看是否有议程。如果有实质性议程，组织者就把它发给大家，然后就开会讨论。如果没有议程，就寄信说没有，会议就取消（针对那一周）。这样如果必要就给团队预留了时间表，但又没有迫使众人参加虚设的会议。如果超过三、四周后还没有会议召开，这种周期性会议就应该完全取消。

会议指标

最后一节是关于成功管理和参加会议的、时常被忽视的战术列表。这种事没什么迷人或有趣的地方：就是一些你和一小群人共事时，必须处理的特殊事情。任何只要运作过很多会的人，都会有他自己喜欢的技巧和小贴士列表。至少，我希望这份列表能帮助你想一想，过去哪些事情对你是行得通的。

* 房间里坐的是该坐的人吗？有些人只要你邀请，他们就会来。有些人除非你把他们打得不省人事并拖来，否则他们不会来（并且/或者用糖果贿赂他们）。PM大部分工作就是让该来的人在正确的时间出现在房间里，所以，如果有人应该出现在你的会议上却还没有到，不用害怕跑到门厅或者冲进其他会议室去找他。甚至，更糟糕的是：如果你要开会了，还没找到该来的人，就停止会议。不要浪费一小时的时间去做一些你在明天或后天达到最低指定人数时，还要再做一遍的事。最后，如果你找到该来的人了，但是看见不需要的人出现在房间内，就告诉他们吧。要讲求策略，告诉他们会发会议记录或摘要给他们，但要让他们离开，尤其是如果他们会阻碍会议召开时。

* 坐下或站着。让会议简短的一种技巧，就是让每个人都站着（例如，在门厅或外面开会）。这个理论就是这样能迫使众人抓住重点，只提出值得群体讨论的问题。会议只需持续5或10分钟，最多就这样。SCRUM5流程提倡每日站着召开状态情况会议，会上只问三个问题：上次会议之后，你都做了什么？什么阻碍着你？到明天会议前，你将要做些什么？通过这种赤裸裸的承诺来精简会议，即使是最暴躁的工程师也应该愿意参加会议了。传统的坐式会议应该留给较小的群体。至少，值得试一试作为实验；最差也会激发大家去思考，安排一个小时的会议并不需要耗掉整整一小时。

注释5：了解SCRUM的更多信息，可登陆http://c2.com/cgi/wiki?ScrumMeetings或者http://www.controlchaos.com/。

* 准备。会议经常是因为缺乏准备而失败。一定要考虑你需要多少准备时间来召开，才能达到它的目的。有时，这会很少：一份问题或开放问题列表，或者在前一天发出包含议程的电子邮件。其它时候，会复杂些：幻灯片、样本展示、装订好的印刷品。无论何时，只要有会议不像你想像的那样开展，就问问你自己，还有什么可以做得不一样。多数时候，答案会涉及到某种粗心的准备工作。一种技巧就是当你发出会议邀请函时，要考虑这一点：在你的日历上空出时间，让会议在召开前，有足够的准备时间。

* 笔记本电脑和小工具。我有很强烈的偏见，反对在会议期间使用小器具和笔记本电脑。如果房间里的人认为进行中的事不够重要，不值得他们全神贯注，那他们就不应该出现在这房间内（除非这是状态或项目查看类型的会议，此时信号与噪声比很低）。面对面的时间很珍贵，应该用于大家自然就觉得很重要而且值得他们花时间的事情上，而电子邮件和语音信箱是设计为等待的。如果你对这点有意见，可以和团队的其他人谈一谈，针对会议期间妥当使用笔记本电脑，看看你们是否能达成一致的政策。

* 准时。这是由资深人士推动的行为。如果VP倾向于晚到，那么每个人都会如此。如果他通常都准时，那么每个人也会如此。你可以试着准时谈重点，但如果重要人士不在那儿，等他们出现时，你只能再重讲一遍——这就是失败的原因。然而，如果你在等的是你的同级或下属，可以试试喜剧性的激怒战术。我最喜欢的技巧是打电话到每个迟到者的办公室。如果他还在那，适度地当着众人的面，在电话里嘲笑他：“晦，Sam，如果你出现在第5会议室，我们会感到很荣幸的。”如果他不在那，就给他的语音信箱留话。对着麦克风，让房间里的每个人都说：“我们爱你，Sam！”或者唱生日快乐歌。每次开会时，都用这招对付那些迟到或最晚到的人。这样，会议就会变得有乐趣地开始——而且也多了一个准时到会的动机。

* 会议结束时要有明确的步骤和负责人。会议结束后，最重要的就是接下来要发生什么事。你可以开个人类史上最可憎、最令人讨厌、最残酷的会议，但是如果你离开会议室时，有5件必须完成事情的正确列表，以及5个同意把这些事情做好的人的名字，那么你就成功了。绝不要让人们离开时，还不清楚接下来的步骤是什么。你的事前部分准备工作，就是应该考虑你该如何实现这个结果，以及由谁来负责每项任务。

作者: txish 时间: 2009-5-30 21:53
本帖最后由 txish 于 2009-5-30 21:56 编辑

摘要

   * 项目经理总是容易惹恼别人。有些是可以避免的。

   * 人们生气的原因有很多。通常，当他们感觉时间被浪费了，他们被别人像白痴一样对待，或者当他们被认为可以忍受长期沉闷和虐待时，就会被惹恼。

   * 好的流程有很多正面的影响，包括加速流程和防治出现问题。但是，人们很难设计好流程。

   * 不令人讨厌的邮件是简洁而具有行动力的，它能迅速让读者明确其是否有足够影响需要他们进一步读下去，或者只看一句就结束。

   * 当有人推动会议时，它就能顺畅运转。

   * 当目标和会议类型不符时，令人沮丧的会议就会出现。

练习

   A. 你认识的最令人讨厌的人是谁？他什么地方让你讨厌？你觉得有人针对他令人讨厌的地方给他反馈吗？如果你不想令团队的人讨厌你，如何才能获得他们的反馈？

   B. 你所经历的最好的工作流程是什么？是什么使得这个流程那么好？这个流程应用一年后，仍然对项目十分有用吗？

   C. 你所经历的最差的工作流程是什么？是什么使得这个流程那么差？领导们本来应该能做哪些不同的事情？你曾建议那些被忽视的改变吗？或者你只是保持沉默？团队领导如何才能从团队成员那里或者关于令人讨厌的流程的信息？

   D. 上一次你称赞某人电子邮件既简单由清晰是什么时候？在接下来的一周，每天都感谢那个发送给你最清晰、最有效的电子邮件的人。

   E. 控制你的电子邮件。没有法律规定邮件一来你就要读它，或者在一个小时之内回复它。有些研究表明如果你成批处理邮件，一天两到三次，你花费在邮件上的时间就会下降，总体的工作效率就会提升。做一个实验，把你每次检查邮件的时间记录下来。明天，把少检查一次作为目标，这样一天天减少，知道你能控制它。

   F. 这是一个团队实验：把一周的某一天下午作为无邮件时间；例如，从2点到5点要求每个人不能回复邮件。这样可以让所有人在这几个小时内可以自由地、更好地控制自己的工作。实验之后，询问团队成员感觉生产力提高了，还是减少，或者没有区别。

   G. 下次参加会议时，带一个记事本。每次会议，都找出谁能推动会议，记下他是怎么表现的。一周结束时，列出你看到的最好的技巧和习惯，并且把模仿它们作为你自己开会时的目标。

   H. 如果你发现自己并不符合某次会议（会议的大小不合目标要求），你应该做些什么？a）等着看看是否有其他人抱怨；b）建议会议组织者改变会议的规模，这样会增加开好会议的机会；c）或者开始一个听音乐抢椅子的游戏，把没抢到椅子的人赶出去，直到会议人数合适为止。你选择其中哪一个？

   I. 历史上，每一种官僚都滋生于简单而倾斜的流程。研究官僚系统历史会让你极大地感到灰心（例如，政府税收系统，HR雇用程序，工作花费报告，等等）。找出那个系统的第一个版本像什么？它是如何进入现在你所知道的这个系统里的？官僚原本可以被阻止吗？既然你知道了历史，你本该做哪些不同的事情呢？

   J. 看看所有你反复的会议，把它们按重要性排列起来。取消最不重要的反复召开的会议，试着用其它会议或者邮件来代替它本身传达的目的。

作者: phebe 时间: 2009-5-31 11:41
好，支持持续更新，感谢发表，

作者: txish 时间: 2009-6-1 09:54
呵呵，谢谢关注，我会把我手头剩下的最后一章样章第十二章《为什么领导力以信任为基础》，陆续发上来，感兴趣的同志们请继续关注。

作者: txish 时间: 2009-6-1 09:56
第12章为什么领导力以信任为基础

我曾遇到过十几个经理。其中多数人很容易就被忘掉了，但是有些人却是非常令人害怕。但是，那些我很欣赏的人需要时间才能赢得我的信任。他们希望我的工作出色圆满，但他们也知道，只有我每天都能依靠他们，我才你达到这样的工作状态，否则根本不可能。但是，这并不意味着，他们只做我所要求的任何事情，或者只屈从于我的建议。然而，这的确说明他们的行为是可以预期的。他们时常来到我面前，跟我谈论他们的职责、动机和期望。我知道我的立场，也清楚我的角色和他们的角色，更明白对于所要的事情，我能从他们那里得到多大的支持。

身为团队的领导，所有的事情都依赖于每个成员能够对你做出何种假设。当你说：“我明天会把它完成”或者“我会和Sally谈，让她同意这一点。”其他人心里就会打起小算盘，看看你所说的话能够成功的几率到底有多少。渐渐地，如果你对团队管理得很好，这种成功的几率就会很高。他们就会开始听从你所说的，并且非常信任你。
虽然电影把领导力描述成高度戏剧化的活动——让英雄冲进燃烧的大楼中，或者孤身一人勇敢地对抗成群的敌人——而真正的领导力其实是非常简单而实际的事情。做你所说的，说你所想的，当你做错的时就认错。做决策前，征求那些受影响者的意见和建议。如果你能经常做到这些，你就会赢得和你一起工作的同事们的信任。当你必须要求他们做一些他们不愿意做，或者他们并不同意那样做的事情时，对你信任就会使你的领导力发挥作用。

这说明，要想成为一名出色的领导，你并不需要成为最好的程序员、计划者、架构师、沟通者、能说笑话者、设计师或者其他任何角色。你所要做的事情就是，把信任当成一件重要的事情去培养，并且刻意和你身边的人共同分享。因此，要成为一名好领导，你就要学会如何发现、建立、赢得信任和信任他人——同时你也要学会培养信任自己。

作者: txish 时间: 2009-6-1 10:15
本帖最后由 txish 于 2009-6-1 10:18 编辑

建立和失去信任

信任（Trust）：名词，对某人的正直、能力和品质非常有信心。

“信任是所有有意义的人际关系的核心。没有信任，就没有付出、结盟和风险承担。”

——Terry Mizrahi, 社区组织教育中心主任 (Education Center for Community Organizations)

在一次试验中，我把一些熟人作为样本，询问他们在当前的工作场所信任谁，为什信任他？他们的回答大致都相同：信任是由这样的人赢得的，他们努力做好自己的工作，对项目的的目标尽职尽责，公平地对待每个人，在艰难的时刻表现也始终如一。没有一个人谈到，他们是否喜欢这样的人，或者愿意邀请他们共进晚餐。看上去，信任是某种穿透其它人格优点的东西。人们可以信任那些他们根本不喜欢，或者不愿意花时间相处的人。

不同于其他的人类特征，信任和个人喜好没有多少联系。人们不会基于肤浅的事情去选择相信谁。相反，对于可以依赖谁这个问题，我们总会做出深入的思考。如果我问你，在一种危险的情况下，你相信谁会挽救你？你所选的人，和我问你愿意和谁一起看电影所选的人一定不同。无论如何，个人感情和可靠性之间没有必然连接的关系。
但是，要在一个项目环境中检验信任，我们需要把概念分成可以利用的各个部分。信任的其中一个简单的单位，就是承诺。承诺，或者叫允诺，就是针对双方达成一致意见的事情，所签订的最简单的合同。

信任通过承诺而建立

你结交了一个新朋友，当他告诉你会在哪里和你见面时，你相信他会出现在他所说的地方。但是，如果连续两、三次，他都让没有守约，最后，你一个人看了电影或者呆在俱乐部里，你对他的信任就会大打折扣。实际上，你没有遵守对你的承诺。如果这种事情继续发生，你的看法就会改变。你将不再信任他，在重要的事情面前，你会怀疑你对他的信任。

根据Watts S. Humphrey所著《管理软件开发过程》（Managing the Software Process，Addison-Wesley出版，1989年），合理管理项目的核心元素之一，就是领导者对工作作出承诺，并且努力完成承诺的能力。Humphrey认为这一能力非常重要，因此他详细地定义了有效承诺的元素。他列出了一下几点，并且做了一些修正。

有效承诺的元素

1.做出承诺的人非常愿意这样做。

2.承诺不是轻易做出的，这就是说，承诺是在充分地考虑了工作、资源和进度的情况下做出的。

3.双方对做什么，由谁来做，以及什么时候去做，达成一致意见。

4.公开且坦诚地做出承诺。

5.即使需要帮助，责任人也要尽力实现承诺。

6.在承诺兑现之前，如果有任何影响其中一方履行承诺的事情发生，都要提前通知对方，并且重新做出承诺。

这里，有两件非常有意思的事情。第一，承诺在双方生效。相关的两方互相承诺。如果Cornelius 对Rupert承诺，当Rupert外出时，他会帮他遛狗，那么双方都会尊重彼此的利益。Cornelius绝不会在穿过25个街区，来到Rupert公寓，想要带Rover去中央公园散步的时候，却发现Rupert正躺在沙发上看着电视（“哦，对不起。我本来想昨天给你打电话来着——我的行程取消了。”）。双方交换彼此的信任，同时希望对方尊重彼此的信任——而不是亵渎或者遗忘。让对方浪费时间或者金钱，就是在破坏这种信任。

第二，我们经常做出承诺。在每一次的谈话中，我们都会要求或者被要求做些什么，并且对此达成某个期限，这样，我们就是在做着某种承诺。其中包括某些简单的陈述，例如，“嗨，晚餐后我会打电话给你”或者“明天我会读那份草稿”。对于承诺有多认真，双方想法可能各不相同，但是，几乎没有人会怀疑已经做出了某种承诺。我们对待别人的承诺越不尽心，别人对我们的信任就越会下降。承诺有不同的等级（例如，如果你忘记了某天下午给你妻子打电话，她不会把这看成是因为你要和她离婚的表现），但是，这些承诺对于我们理解其他人是否值得信任都是相关联和有作用的。

信任因为不一致的行为而失去

回到项目上来，当人们的行为难以预料时，就会破坏信任。当某人采取的行动一直和他的承诺毫无关系，就会产生影响团队的波动情绪。那些和他一起工作（或竞争）的人的精力就会被消耗。他们现在要花费精力去考虑他是否会按照他所说的去做，而不是把精力放在完成工作上。他们必须要制定一些应变的计划，同时各种程度的压力和怀疑都会增加（“如果Marla今天不能签入那些代码，我们就完了。”）。越是有人对他的工作不负责任，就越会引起团队的情绪波动。

我来讲个有趣的（虽然令人感到痛苦）关于失去信任的故事，这个故事和我以前的一个经理有关。我那时是一名程序经理，下面有五个程序员和测试员，而且我们相处十分融洽。Jake是团队的领导，也是我的经理，他的手下除了我还有其他几个项目经理。问题出在Jake喜欢改变想法的习惯上。例如，他和我一起讨论我要做出的重要决定，而这些需要他的支持。我们很快就对最佳方法达成一致意见。但是，一旦我们开始开会，会上出现个性强硬的人，资历和他相同或者比他还高的人不同意他的观点，那么，Jake就会以喜剧性的方式屈服（有三分之一的时间，他会这么做，而我总是不知道是哪三分之一）。他会改用其它方法，赞成任何受欢迎的决策。

我还记得在会上，我站在白板前讲解我的A计划，刚讲到一半，他就同意别人的意见而采取B计划。我停下来，盯着他，非常惊讶，他竟然可以泰然处之地做出这种事情。难道他真的忘了吗？他真的是那种爱拍马屁的人吗？他对我所做的一切竟然毫无知觉吗？或者他那风向标一样的行为（跟着房间里的方向转），真的不在他的控制范围内吗？我那时还没有能力处理这样的事情，而且也不知道和别人讲讲我所经历的遭遇，所以我只有忍耐。而我去体育馆健身时，却从来也没有像这样有忍耐力。

最后，我开始和他讨论他的这种做法。而且，只要我们做出决定，我就把它写成文件（电子邮件对此非常有用），作为日后的参照。我甚至还让他在开会前做好准备。但是，所有这些努力只是对他之前的行为得到有限的改善（他把不支持B计划，改成不参与讨论，不帮助推进A计划了）。我很快发现，我已经绕开他做事了。我故意在他没有出席会议的时候做出决定。与他参会相比，这样做不但减少工作，而且还更加有效。虽然这样，对我的团队会造成其他的问题（也会对我和Jake之间的关系不利），但是我却可以管好我这一摊儿，把事情做好。

糟糕的是，Jake很精明，和他共事很有趣。但是，因为我不信任他，这些也就变得无所谓了。作为经理，如果他再笨点，而值得信任的程度再增加一倍，那么他将非常有所作为。当然，我们就会做出更好的产品，我就不用花费太多的精力来对付他，而是把更多的精力放在协助团队上。

明确信任（挂起绿灯）

我碰到的优秀的经理，都会把信任感表现出来。他们明确地告诉我，我有权对我所负责的事情做出决策，只要我能得到团队的支持就行。他们（我的经理）可能会检查一些他们所关注的特别事项，要求我和他们一起核实这些问题。而且，他们会指引我把重点放在实现事情上，而不是寻求别人的认可上。给予信任，是授权的真实意义，是强而有力的东西。有些运动对这种授权有特殊的行话——例如，在篮球场上是说或者“绿灯（green light）”。

多年以前，我在高中打篮球，加入Rob Elkins1教练的篮球队，就在纽约市道格拉斯顿的塞缪尔Y体育场。有一天训练时，他把我拉到一边，这通常是指他要开始训斥你了。我在练习时一直犯错，把其他运动员的短裤拉扯下来，害得他们无法进行防守。当我坐下时，把头低下，准备好挨骂了。但是，他什么也没说。我们坐了很久，看着场上其他队员的混战。最后，他说：“Scott，你有绿灯了。”我看着他，问道：“绿灯？”他笑着回答道“是的”，但却连看都没看我。我说“好吧，教练”，然后就跑回场上。尽管很少有人听过这话，但是不知怎么，所有队员都知道这话什么意思。一般情况下，球员是否有义务射篮，必须要看教练的战术安排，但是绿灯除外。我可以随时射篮，只要我觉得合适——当我认为必要时，我可以接替任何打法和练习权限。

注释1：纽约市道格拉斯顿的塞缪尔Y体育场的Rob和Eric，教了我很多关于教练和管理的知识，他们所教的内容比我后来高中和大学的篮球队教练教的内容要多的多。如果你认识他们，请告诉他们和我联系。

告诉一个球员这样的话，就是给予他非常的信任，这恰恰是为什么大多数球员在其整个职业生涯中都没有听说过这事（我高中一直打篮球，后来还在第三级大学队里打，但是我再也没有听过这样的话，而且之前也从未听说）。教练通常害怕放弃职权，就像经理们那样，他们认为自己的权力非常脆弱。站在边上（或者一个人坐在角落的办公室）是非常容易受到攻击的地方。很多经理和教练们担心，如果给他们的团队额外的自由，就会出现什么状况。他们忘了自己可以随时调整信任度，如果我滥用Elkins教练给我的信任，那么没有什么可以阻止他收回他对我的信任（把绿灯变成黄灯）。更重要的是，或许，经理们害怕给予的信任程度，正好就是团队实际所需的跟随他们的领导的程度。

可以说，我在Elkins教练带下表现得比其他教练带领时都更加努力。我本能地认为我要实现更高的目标（虽然有场比赛，我十五分钟内射了7次篮，结果一次也没射中，我确信这种射篮成绩可以称得上是某种俱乐部记录了）。对那些给予我相似信任感的经理，我也会尽力和他们工作，而对于那些没有这么做的经理，我工作起来就不那么尽力。这并不是因为我喜欢他们（虽然这有所帮助），而是因为我有了更可以努力工作的空间。信任的传达才产生真正的授权，因为这会给人空间，使人能够在他们的颠覆状态下工作。

如果获得最大可能的成功就是你的目标，那么你就要寻找各种办法，给别人绿灯。经理人的工作，就是给他的团队创造机会，同时还要协助团队有能力和做好准备去抓住这些机会。

作者: txish 时间: 2009-6-12 18:22
不同类型的权力
在本书中，我会使用两种权力模型。在后面的第十六章中，会介绍高级模型。现在开始，我会专注介绍简单而有效的职能性权力。

职能性权力有两种：授予的和自己争取得来的。授予的权力来自积极体制或者工作头衔（有时，被称为职权）。例如，篮球队教练有权决定哪个队员可以上场，哪个队员要做冷板凳。小规模营销办公室领导有权聘用和开除任何人。但是，这种权力和人们对他们有多少尊重无关，甚至于和人们认为他们有多少技能和知识也无关。相反，自己争取的权力，是必须经过表现和行为的不断进取而获得的。获取的权力，或者是获取的授权，就是那种人们出于领导的英明和有所帮助，而不是因为他的权限，而选择去听从的那种权力。

不要依赖授予型权力

“我不相信任何体系的组织者，而且会避开他们：对体系的渴望，就是因为自身不完整。”
——Nietzsche

如果领导以授予型权力作为主要的影响力，那么就会限制人际关系。它排除了交换想法的可能，把重点放在了如何使用这些影响力，而不是如何调用那些聪明人上。虽然在某些情况下，必须使用独裁专制的权力，但是，优秀的领导尽可能地把剑插在剑鞘中。一旦你拔剑，就没有人听你说什么了——他们都听剑的了。更糟糕的的是，你身边的每个人都会拔出自己的剑去回应你的剑（他们的剑可能比你的剑还要好）。他们不会和你解释为什么你做错了，他们只会利用自己的授予型权力去挑战你的力量。这就导致了各种力量的竞争，这种竞争和智慧无关，也不会去寻找最佳的解决方法。授予型权力（就像力量的黑暗面）是临时的，因为它很容易获得：你无需努力，就可以得到你想要的。

我曾遇到这样的情况，把我推到授予的权力和争取得到的权力的十字路口。那时在开发IE2.0，那是我第一项重大的程序管理任务。第一天，我被介绍给两位我要共事的程序员，Bill和Jay。Jay非常友好，而Bill则比较沉默和吓人。他在组织中也是一位资力很高的人（以微软的行话来说是13级，这意味着，他是程序员中可能的最高级别的人）。我还记得坐在他的办公室里，隔着桌子看着他。我谈了有10分钟，而他几乎什么都没说。他就是那样斜靠在椅子里，盯着我。

我试着走到白板前，看看那样能够让他谈点什么，但是没有生效。他只会说些讽刺或者含糊不清的事，例如，“哦，真的是那样吗？”以及“哇……真有趣，你竟然你那样想。”他只是在玩弄我，就像猫在玩一只半死的老鼠一样。要知道，我那时只是个狂妄自大的23岁的年轻人，我对我所做的事情根本不清楚，尽管我不断让自己相信，我可以装懂。另一方面，Bill是经验丰富的专家，他前有几十次碰到过这样的程序。事实上，我确定他脑海中只有两个想法：“我怎么能跟着这样一个年轻的新人？”以及“他是不是我碰到过的最蠢或者第二蠢的人？”见面结束，我用一种“直接从HR训练录像”里学来的方式，胡乱说道，将和你一起工作多么好啊。（我坚信，这一点让他确信，我事实上是那个最蠢的家伙。）

那时，一个好朋友（另一位PM）给了这样的建议：按规矩办事。我应该告诉Bill，因为我是PM，他是程序员，在一些高层次的决定上，他应该按我说的去做。这点与我曾听说的微软PM神话（“谁挡了我的路，我就杀谁”）不谋而合，于是，我重新鼓起勇气，去尝试和实践这句话。但是，在我拔剑准备往前冲时，我找我的经理谈话。就在温和的笑声中，他告诉我不要贸然行事。他提醒我，Bill在他的领域内，非常聪明且知识渊博，我应该想办法如何利用他这一点。他还补充道，和Bill一起工作，就像他提过的那样，“对我有好处”。尽管他在笑，但我还是相信他。我把剑放到了一边，开始从尽量让Bill发挥作用的角度出来去解决问题。

努力去争取挣得型权力

几个星期下来，我逐渐赢得了Bill的信任。开始的时候，非常令人痛苦。为了让他能够协助我，我必须得证明我有能力，能够从小做大。我发现，当我承认对于某事他知道得比我要多时，就很容易从他那里得到不错的建议。当我做出承诺，并且兑现时，他变得非常大度。虽然我要做出正确的决策，用有力的论据来证明我的观点，但是，最终我们培养出一种稳固的工作关系。Bill赋予我权力做出对他有重大影响的决策。他只是需要我表明我值得他付出信心。

如果一开始，我就运用我所拥有的授予型权力，那么我将失去赢得权力的机会。第一天，Bill可能会屈服于我，但是，因为他只对我的权力做出回应，就很难越过这一点，以一种更加易于合作的方式来共同工作。如果我继续依赖那种权力（当你开始运用这种权力时，就会倾向于一直这样），渐渐地，它就变得不再那么有效。每次当经理或者领导说，“应为我这么说”，他们就会终止讨论，封杀可能产生的好建议。他们周围任何精明和有激情的人，都不会尽全力去工作，对于他们所扮演的有限角色，也不会感到高兴。

从组织的立场来看，独裁专制的行为，会把善于思考的人推到一边。同时，也会鼓励那些习惯于按命令办事的人留在周围。暴君创造了一种只有奴才才可以忍受的环境，反之亦然。更糟糕的是，暴君把底下的人也变成了暴君。这种行为模式（只听授予型权力）会向下传遍组织，最终会毒害他们。

说服比发号施令更有力

在管理他人时，我学会了如果我在要求他们做之前能够说服他们，我就能更加有效地让结果出现。白痴会利用残暴的权力，要求某种特殊的行为——这部需要任何技巧。但是，如果要说服一个聪明人（或者一群人），让他们相信他们原本不想去做的事情是正确的、有益的，甚至是符合他们的兴趣的，这样就会更加有利于事情的开展。当他们工作了一段时间，开始质疑为什么要做这样事时，他们不会责怪到你。他们会依赖自己的智慧，而智慧收到你的论据的影响，去解释为什么自己花费时间在他们所作的事情上。

最后，众人听从于我，是因为他们相信我的能力，对于我的观点总是有合理的理由。他们只提出很少的问题，因为他们相信，我在这样要求他们做之前，已经深思熟虑了。他们也并不担心我对他们的利用，因为他们有多次经历表明，我的行为只是为了项目和团队的利益。众人越相信你，你就越容易说服他们。就像和Bill那样，随着时间的累积，我花费越来越少的精力去说服他们——尽管那是我和他们建立关系的开端——把更多的时间用在做事上。

必要时独裁专制

授予型权力确实有它存在的理由。当事情失控时，授予型权力是恢复秩序的最快办法。如果会议就要失败，重大承诺无法达成，或者出现最基本的问题，那么就要拔剑了。如果你认为，利用直接的权利是让结果成功的唯一真实可能，那么不管结果怎样，都要想尽办法去使用。要明确、直接地利用你手中的行政权力去推动项目进行。
但是，越多地使用这种权力，就越多地掩饰组织内部的基本性问题。如果度过这一星期的唯一方式，就是在会议上大吼你的方法，或者在小办公室里咆哮下令，这样只能说明需要开始审视你的项目远景、组织结构或者你的领导能力了。

作者: txish 时间: 2009-6-12 18:25
相信别人

当组织变得越来越大，它就越依赖授予型权力。领导者非常担心如何把这么一群人整合到一起共同工作（或者，也许是防止革命），有一种观点认为，没有时间让组织中的每个人都参与那些需要利用挣得型的权力才能开展的讨论和沟通。即使是在小团队中，我知道有些领导，也不相信他们有精力或者时间，让那些核心贡献者都使用这种领导方式。这一问题的解决方式，就是利用另外一种信任，称为授权：相信别人去做决策。

权威和信任，通常在各种任务或者知识领域周围累积起来。Joe可能在C++对象方面最有权威，Sally也许是解决数据库工作的最合适人选。健康而沟通良好的团队成员之间彼此相信，而这种信任足以让他们了解，在哪些方面谁更有能力或者有更好观点，然后直接去征求那个人的建议，而不用担心遭遇尴尬或者讽刺。这种担心很现实，因为在工程界，当你寻求协助时，有一种成熟的消极攻击型的行为文化（那就是，去读那些愚蠢的手册）。即使在大学里的计算机科学系，倚靠自己也被看成是核心能力，学生请求同学的帮助，通常被看成是一种软弱的表现。

从项目的角度来看，Sally在数据库设计上的权威，只有应用到项目上时才有用。如果她独自坐在办公室里，没有人借助她的权威去解决问题，那么Sally的权威就被浪费了，或者最多，Sally只限于做自己的任务而已。项目领导者或者经理的重要职责之一，就是为整个团队塑造授权和共享知识。如果他们做得好，团队的其他人就会很容易随从。

传统而言，授权是用来描述把特殊任务或者责任交出去的行为。我认为，授权的更加有力的形式，是决策或者影响决策的能力被分散。这种情况可能在会议或者小组讨论中发生。当询问领导或者经理“那么，我们如何解决这些问题呢？”，他就有机会把权力传给其他人。“好，Sally，你是最优秀的数据库设计人员。你认为这里我们应该怎么做？”只要这不是不公平的行为（例如，在紧张的VP查看会议中，演示失败，Sally根本没有想到要她去回答任何问题），就能建立协作的基调。众人若能大方地认可他人的专长，他们就会恰当地服从于权威。当然，对于项目经理来说，就没有什么风险了。如果Sally的建议不好，大家可以继续讨论。但是，倘若没有那第一个提问，讨论就根本不会发生。

当然，授权也可以扩展到明确地把权力交付出去。公开宣布，某块工作或者功能将由某人来负责，经理把他的权力交给那个人。授权要做得有足够的透明度，让那些需要看见的人都能真正看到，这一点非常重要。每一次，当我把责任转交给替我工作的人时，我确保联系每一个有关联的程序员或测试员，这样他们就会明白，我对这项工作所掌握的权力和职权将转交给其他人。当然，有时，人们不愿看到有事要授权，但是，这是领导的工作，你要用你的权力去强迫执行。

John是我团队中的一位项目经理，他已经准备好承担更多的责任。因此，当需要重新组织团队工作任务分配的时机到来时，我就可以把握之前一直负责的一块工作交给他。通过与John和Steve（该领域的一名程序员）适当的讨论后，我把职责交给John。一周后，Steve来到我的办公室，请求该领域的PM帮忙。当我听他讲述时，我试图找出他和我谈，而不是和John谈的原因。我打断他道：“Steve，你为什么要和我谈这件事呢？”“哦，Scott，你以前负责这件事，不是吗？”“没错，Steve，不过现在John负责它。你和他谈过了吗？”他耸耸肩。“Steve，去和John谈吧，”我说道。“他很精明，很不错，相信他吧。”过了几天，Steve又回来了，我们又做了一次更短版本版的相同对话。自那以后，我再也没有听到Steve说些什么（至少是关于这项工作）。

John可能永远也不知道这件事情，也没有必要知道。Steve宁愿和我一起工作，这是出于某种原因的，他希望继续保持我们之间的关系，尽管负责人已经改变。但是，因为授权，我必须让自己置身于讨论之外。我或许可以亲自回答Steve的问题，也可能我很愿意这么做，但是，那样，我会违背自己所做的授权决定。除非我有理由参与到那个项目领域，否则，我就得信任John和Steve能够做好他们的工作，包括运用Steve对我的信任，说服他相信John。

很多经理在授权上，都遇到麻烦。因为有能力自己把事情做好，所以他们的资历不断提升，但是，领导需要各种技能的平衡，而这种平衡和作为一个独立的贡献者所需的平衡不同（请参阅第1章中“项目经理的平衡之道”部分）。这些经理往往因为害怕没有足够的掌控能力而退缩。当然，这是一个陷阱，因为如果害怕驱使着决策，那他们就永远也学不会信任别人，没有信任，就没有领导力。

有时，解决办法就是妥协。在授权时，经理必须和团队成员讨论，授权要考虑哪些事情。（“John，我担心Steve。每次评估时，他都落后。所以，要格外注意这一点，好吗？”）对授权任务设定期望后，领导可以传授一些经验和指引，这样可能增加成功的机会。

作者: txish 时间: 2009-6-12 18:26
信任是灾祸的保险

就像我们上一章所谈到的，所有的项目都会出错。竞争对手不会按照你所期望他们做的那样去做事情（那是他们的工作），技术不断发展变化，重要任务会改变想法。作为一个项目经理，可以明确的是，事情总会出乎意料或者无法解决的发生。在艰难或者不确定的时候，你希望团队或者同事能够依赖你，并且彼此信任。

如果信任已经培养起来，并且随时间茁壮成长，人们有合作决策的经验（而不是不顾他人），那么项目对于面对问题的解决能力就会很强。当众人相信团队时，他们就可以鼓起各种信心和耐心，而这是通过其它方法无法获得的。就像散兵坑里的士兵那样，每个人都可以依赖在他背后的人，让他们可以把更多的精力放在面前的任务上。

当团队的成员能够彼此信任，就会给项目经理赢得时间，去专注于解决手边的问题，而不是试着让走廊里惊慌失措或者沮丧的员工的情绪稳定下来。优势，领导者需要明确请求这种支持。他要承认问题，并且征求，而不是命令他们给予支持，以此来表明他想从团队那里获得的尊敬（大叫“现在支持我”是不起作用的）。总而言之，是人与人之间的关系让他们度过艰难时光：而不是薪水，也不是他们所使用的技术，当然也不是个人拥有多大的权力，或者没有什么权力。

因此，聪明的领导，就像一艘轮船的船长一样，知道看不见的风暴和危险潜藏在大海深处，他会让自己和船员尽自己所能做好准备，去面对他所不能准备的事情。如果不确定是一种必然，那么项目经理的最佳投资，就是在他和每一位项目贡献者之间建立起强大的信任网络。对于那些较大的团队而言，需要花更多的时间，在那些对项目最重要或者最可能在压力下失败的人际关系上，建立信任感。虽然规范、远景文件，或者其他工作，确实能够帮助把众人联结起来，但是真正有力量的是那些东西背后所隐藏的人与人之间的信任。

榜样、问题和冲突

已所不欲，勿施于人，这条金科玉律（golden rule），也适用于经理人。只有领导自己遵守命令，底下的人才会服从命令。人是社会性的动物，我们在生活中学习行为举止，尤其是从其他的榜样身上学习。通常，看到那些我们尊重或者崇拜的人做某些事，就开始试着，有意识或者无意识地，去模仿那种行为举止，这种学习往往具有最好的效果。谈到信任，项目领导者要想让共事者也有这样的行为，就要首先证实这种行为。Michael Jordan除了具有品质外，还具有高度敬业的好名声。即使是NBA中，薪水最丰厚，知名度最高的篮球球员，他的工作努力程度也鲜有人及。这就，其他次要球员就不可能请求停止练习去休息，也不可能少花点时间呆在体育馆里。领导树立了一个榜样，其他人都得照着做。

职业道德放一旁，这条金科玉律对领导者而言，就是他们相信自己的判断，足以遵循其他人也会跟着遵循的相同的原则（请参阅本章后面的“相信自己（自我依靠）”那部分）。这样做，就表示允许其他人、同事或者下属，对领导者的判断或者行为，提出质疑或挑战。如果有人被授予权力，就需要某种反馈来挑战它（换言之，谁被允许说国王没有穿衣服？）。优秀的领导充分信任他的队友，以求对他的行为和表现做出反馈（有时，也许私下要求）。当然，领导者没有义务对反馈采取行动或者评论什么，但是，如果没有健康和安全的途径可以把这些信息传达到项目经理那里，我们就很难想象项目会成功了。

作者: txish 时间: 2009-6-12 18:30
领导者要规范信息反馈程序

人们对于给有权威的人物提供反馈信息时，都非常犹豫。作为经理，我有个习惯，在每周一对一的会面时，我会询问那些向我汇报的人，他们是否希望我仔细考虑一下，某些有关我的工作、行为或者执行的事情。对此，他们很少说些什么，但是我知道，这不是因为我是一个完美的经理（没有完美的经理）。我发现唯一的解决方法，就是信任和时间。我必须不断地建立他们所需的信心，使他们非常自然地批评我的行为——他们无需担心我会变得防范心强，或者因为他们的批评而受到斥责。后来，他们终于可以提出少量的批评，如果我掌握的好，下一次，他们就会提出更多。

然而，一旦建立起和他们之间的一个信息反馈圈，我就明白，他们的观点非常有助于我成为一名更加优秀的经理，这些信息远比我从老板那里得到的反馈信息更加有效。当然，我不是和每个人都保持这种关系，但是大多数人，迟早都会回答我的问题，提出有效的反馈信息。建议以不同的方式开会，对我的决策提出疑议，或者其它建议，这些都能保证接下来的讨论，能够使我们双方对事物本身到底怎样的判断更加准确。

每次我参与讨论时，我都试着揭示，批评某种观点和批评提出某种观点的人之间的差异2。某A不同意某B所说的事，并不代表某A在评判某B这个人。我希望我的团队能够感到，他们彼此信任的程度足以让他们想什么就说什么，就是公开的反对，也不需要道歉。幽默感非常有助于创造这样的氛围，领导者要说明，什么时候讽刺或者挖苦是不恰当的，也许应该把自己当成笑话的靶子。但是，我要强调的是，领导要自己示范这种行为，控制好那些太过火的人，同时，把那些斗争着想要加入的人拉进来。

注释2：请到以下网站http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/，参阅“评批和接受批评（How to give and receive criticism）”

这样，也可能导致冲突和意见不一致。如果糟糕的事情出现时，他们只是安静地坐在那里，那么无论是授予型权力，还是挣得型权力都无法帮上忙。除了打断愚蠢的争论，和解除那些乱发言人的发言权外，权力就没有什么更好的用法了。当意见不同转变成人身攻击，或者利用虚假的论据来证明决策的正确，就要有人必须打断和提出反对。绝不能容忍这样的行为发生，每个人都要同时得到相同的信息：不要再试这样的借口，因为我们这里不欢迎这些。

当然，这里遵循另一天金科玉律，真正的领导必须做好准备，如果他试着使用虚假论据，那就等着别人可能（或者必然）对他的挑战吧。最优秀的领导，就是那些可以承受来自忠于理性准则的团队的压力，而这些准则甚至无惧于对领导的行为提出质疑。

信任和犯错

当人们成功是，别人很容易信任他们；如何处理众人犯的错，就要复杂得多。而这正是经理们赢得酬劳的好机会。

根据我自己的经验，我认识到，每次有人带着他所造成的问题，出现在我的办公室门口时，我都尽量（并不总是成功）保持三种观点：
1、我很高兴，他能来找我谈这事。我宁愿他来找我，而不是隐瞒事实，或者自己试着解决却把事情变得更糟。我应该马上让他明白这一点。
2、我给如何协助他解决这个问题？这能解决吗？有哪些选择？我该如何参与？我应该尽可能给他所需的建议，但是，如果可能的话，让他自己去做该做的事情。然而，我要保证他没有头脑发昏。在有99%的可能立即死亡的情况下，把他送回战场，绝不是一种合理的管理实践。

3、
我必须确定，这里是否存在可以让他吸取的教训3。犯错就是真正要学习之处，因为犯错的人对所发生的事，有个人和情绪的投入，而他要有相当大的动机不能再犯这样的错误（尤其是如果他感到团队非常信任他）。

注释3：在很多军事组织中，只有事件和任务才要求做任务报告。因此，如果有什么蠢事发生，而且真的不是任何人的错，影响又很小，根本没什么教训可供吸取，所以也就不值得大费周折去处理。实际上，最好的响应可能是告诉众人，以后，类似的小问题不需要你的认可了。

如果你问任何学科的大师，最大的教训是什么，他们总会讲述那些自己如何把事情搞砸，可能是一件非常重要的事情，最后终于学会如何用更好的方式去完成的故事。这说明，要想成为大人物，你不光要犯错误4，还要有人给你机会去犯错误。经理人在处理问题时而获得报酬，因为他们不仅能够协助恢复，还能引导着把错误转化成教训的过程，使之成为团队可以吸取经验的教训。

注释4：请到以下网站http://www.scottberkun.com/essays/44-how-to-learn-from-your-mistake/，参阅“如何从错误中吸取教训”（How to learn from your mistakes）。

优秀的管理，就是尽可能地给人以他的能力所能承担的责任，但是又不能让他们觉得自己在孤单地工作，或者他们只能在事情顺畅时才能得到你的支持。犯错的潜能，恰恰就是做贡献和成功的潜能，这是很有道理的。这就是说，如果因为人们判断错误，或者因为决策而引发问题，就把他们钉在墙上的话，这是不公平的。

相反，要创造的理想环境是，让众人自由自在地雄心勃勃，但是，也会承认他们所犯的错误，并对此负责。他们应该受到足够的信任，并且要尽所能去学习，以避免再次犯同样的错误。如果团队集体共享这种文化，这就能形成自我改正的氛围。当有个辨认、响应以及从错误中汲取教训的健康机制时，慢慢地，错误出现的趋势就越来越少（或者当错误发生时，人们也会很快处理好它们），众人在不会犯错的多数时间里，就会更加自信地采取各种行动。

作者: txish 时间: 2009-6-12 18:33
从不当场指责

世上最糟糕的事情，尤其是在面对危机时，就是经理人或者领导在问题尚未解决的情况下，就去指责某人。这样，什么也解决不了，而且还把问题解决的可能减小到最低，因为那个最了解这个问题的人（被指责）觉得有罪恶感，而别还变得自我防卫起来。想象一下，一个和你共事的人跑到你办公室大喊：“我的办公室着火了！我的办公室着火了！”，结果你所能提供的就是，“嗨，真是太愚蠢了。你为什么要那么做？我对你真是太失望了。”经理们总是这样做，而且很难不去考虑为什么要这样。我的观点就是，有些人认为，开始解决问题的方式就是指手画脚、散布指责，而这些可能是从差劲的经理或者父母那里学来的。当然，让人感觉难过，找出谁应该觉得最痛苦，对改善状况没有任何帮助（知道谁放的火，通常并不能帮着灭火）。相反，等到问题解决之后，当头脑都冷静下来，压力也释放了，这时才有适当的机会回头看看，究竟发生了什么，为什么发生，对于个人、领导和团队，应该从这件事中吸取什么教训。

相信自己（自我依靠）

   “不分日夜，保持真诚，则不论对谁，你都不会虚伪。”
   ——莎士比亚，《哈姆雷特》

关于领导力和信任之间关系的最后一点，就是学会信任你自己。这是哲学的问题，超出了本书的讨论范围。但是，我对我们之间有足够的信任，可以在短短的章节中，了解一些重要的基础。

如果你看看美国高中和大学的课程表，你会发现有一门课你找不到：如何了解你是谁。这很奇怪。对于一个像美国这样把重点放在个人和自由的国家，竟然没有教公民关于自我发现的课程，更无用说自我依靠了。自我发现是一个过程，这个过程了解你自己身为一个独立于朋友、家庭、老板或者国家的个体，究竟是谁。自我依靠是一种能力，这种能力使你根据自身的情绪、身体和财务状况，让自己适应这个世界。这并不是说，你要赤身生活在森林里，远离尘世。而是指，你要向内看，找出你可以相信的力量，做出选择，不管别人是否同意这些选择。

   “不管你在哪里读到，或者谁说的，除非符合你自己的理由和常情，否则什么也不要相信，即使是我说的也不要相信。”
   ——佛陀

从传统的观点来看，领导力要求个人有某种自我依靠的认识。只要你内心有指南针，指引着你走向你认为对的方向，你就可以冒险或者做出艰难选择。没有自我依靠，你所有的决定都要强烈地依赖他人的观点，或者你想要愉悦他人，没有任何的核心力量去引导这些影响。Tom Peters、John P. Kotter和其他作者把核心力量成为价值体系。他们建议，应该有一系列价值观可以作为你或者组织的核心，指引你度过难关。这种做法可以起作用，但是我建议的是比较深层次的、更为个性化的事情。

自我依靠始于相信自己的观点——即使别人不相信某事为真，你却有可能你相信。只有你考虑它，并且自己想通，要去改变你的想法，不同的意见才能否决你的想法。否则，没有理由放弃你对某个问题的观点（你可能仍就某个决策需要让步，把你的权限让给他人，但是这并不要求你失去自己的主张）。你的信念应该是自信的。如果你只是出于别人和你想的不一样，就打算改变自己的想法，那就是做出违背信任自己的行为。背叛对自己的信任，就像背叛对自己团队的信任一样，十分危险。

对勇者而言，自我依靠会走得更远。他们不但相信自己的观点，而且还相信自己的价值观，这种信任足以允许自己改变观点，甚至承认错误。没有改变和偶尔的挣扎，我们就无法学习或进步。但是，如果你真的相信自己，你就会发现你还是你自己，即使当你失败，或者产生新的想法时，你还是你。Emerson写道，“愚蠢的一致性就是心思狭隘的鬼怪。”他的意思是，只是为了保有相同的想法而保有它们，毫无意义。聪明人应该随时学习更多知识，因此，要求人们产生新的想法和观点，即使这些新的想法和原有的想法有所冲突。如果你过着积极理智和感性的生活，你的想法就会和你一起进步。

这就是说，自我依靠的人对自己非常自信，而且想办法让别人能够影响他，帮助他一起定义未来的远景，接受各种正面的改变。你不担心犯错误，承认错误，改变想法，因为你还是你自己。

因此，如果你可以学会用这些方式相信你自己，你就会，以一个领导者的副产品角色，帮助别人学会相信他们自己。在项目世界或者人类心理学里，没有什么授权活动，比帮助人们相信自己有能力变得更加自己依靠，更加有力量了。

我建议大家读一读Ralph Waldo Emerson写的文章《自我依靠》（Self-Reliance）。你在他作品集的多数版本中都能看到这边文章，或者你可以去网站上阅读：http://www.emersoncentral.com/selfreliance.htm。有关自我发现的最好的普通读物就是Rick Fields所著的Chop Wood, Carry Water（Jeremy P. Tarcher，1984）。有关哲学的冒险，可以试着阅读Albert Camus所著的The Myth of Sisyphus（Vintage, 1991）

“只有当人们摒弃外在的支援，自我挺立，才能发现自己十分强大和成功……如果谁知道力量是天赋的，知道他之所以软弱是因为他从自身之外寻求美好，有了这种认识，他就会毫不犹豫地依靠自己的思想，立即改正自己，挺身直立，掌控自己的身体，创造奇迹，就像一个用双脚站立的人，比一个用头站立的人更加强壮一样。”
——Ralph Waldo Emerson，出自《自我依靠》

作者: txish 时间: 2009-6-12 18:35
摘要

信任是通过有效承诺而建立起来的。

信任是因为对重要事情的不一致行为而丧失的。

利用授权和信任，让众人能够出色完成工作。

授予型权力来自组织阶层体制。挣得型权力来自众人对你行动的响应。尽管这两种权力都是十分必要的，但是，挣得型权力比授予型权力更加有用。

利用授权建立你对团队的信任，确保你的团队能够抵御灾祸。

以能够维持众人信任的方式来应对问题。在危难时刻，支持队友，这样他们才会把问题告诉你，而不是隐藏起来。

信任自己是领导力的核心内容。自我发现是了解自己和发展健康自我依靠的好办法。

练习

A.

列出你经常一起共事的五个同事。你最信任谁，为什么？

B.

是否有一种毫无风险的方式，可以赢得某人的信任？你能使某种关系变得很安全，同时，加深这种关系，使它变得更加值得信赖吗？

在你所遇到的那些经理中，谁依靠授予型权力，谁依靠挣得型权力？这和他们的行为是如何关联的？
D.

想一想，你曾遇到过的，别人对你最大的失效承诺。这对你和他之间的关系有怎样的影响？你曾讨论过这是怎么发生的吗？你曾对你的团队有什么失效的承诺？有什么方法能够从一个失效的承诺中恢复过来？

E.
你最近一次犯错时，你的经理是怎么对待你的？他的方式，和你最近对待为你工作的人犯了错的方式有怎样的不同？
F.

当你探索自我依靠时，你曾为什么决定斗争过，虽然它不受欢迎？你是否记得你曾遇到的这样的情形：尽管你明知道别人会批评你，但是你知道应该做什么，并且做了。

G.
你什么时候最后一次对重要的事情改变主意？去改变你对生活中某件事情的看法，把它当成你的目标。邀请你的团队，或者一帮朋友，共进午餐，并告诉他们，如果他们能够改变你的想法，你就买单。

H.
研究以下任何两个领导的领导类型：Gandhi，Abraham Lincoln，Alexander the Great，Napoleon，Genghis Kahn，Queen Elizabeth I，Nelson Mandela。你宁愿为谁工作？为什么？他们通过什么方式来赢得（或者利用）追随者的信任？他们手中掌握多少授予型权力和挣得型权力？

I.
领导力是后天习得的还是天生的？例出成为一名优秀的领导者所必备的优点（利用你希望从本书所学得的，或者随便写一下）。用1-9分来给每一项优点打分：1代表完全是天赋的，9代表完全是后天习得的。

作者: txish 时间: 2009-6-12 18:37
本帖最后由 txish 于 2009-6-12 18:41 编辑

目录

译者序  3
      序    4
前言 5

第1章项目管理简史  7

第1部分规划       15

第2章关于进度表的原理  16
第3章如何知道该做什么  25
第4章编写好的远景文档  36
第5章想法从何而来  44
第6章有了想法之后做什么  54

第2部分技巧  62

第7章撰写优秀的规格说明书  63
第8章如何制定好的决策  72
第9章沟通和人际关系 81
第10章怎样才能不惹恼别人：流程、电子邮件和会议  88
第11章事情出错时该做什么 97

第3部分管理 108

第12章为什么领导力以信任为基础 109
第13章如何让事情发生 117
第14章中盘战略 126
第15章终盘战略 135
第16章政治与权力 147
附录讨论组指导  156

作者: txish 时间: 2009-6-12 18:43
本帖最后由 txish 于 2009-6-12 18:44 编辑

译者序

本书是《项目管理艺术》的修订版。《项目管理艺术》一书是项目管理领域的一部经典书籍，曾获2006年度Jolt世界图书大奖，在各种畅销书排行榜上都名列前茅，这些都从一个侧面说明了本书的份量。

在翻译此书的过程中，我的最大的一个感受就是本书的实用性。本书的作者在其职业生涯中，主要就职于微软公司的项目管理工作，有着十多年的项目管理经验，书中内容都是来自于作者的一线实践经验。本书抓住了我们在平时项目管理过程中所涉及的重点，以轻松朴实、容易理解的叙述方式告诉我们：什么是项目管理？相关管理该做哪些事情？为什么做这些事情？怎么做这些事情？在具体的环境下应该抓住什么？忽略什么？

我们平时看到的大多理论书籍都有着非常完备、严谨、系统的知识体系，想来大家对此都深有体会。这些书籍的内容很严谨，不容易发现问题，但常常与实践的距离太远，使得我们不知道如何将这些理论运用到实践中。本书则完全是从实践出发，将项目管理理论中的要点通过实践经验一一道来，并将实践中面对的问题毫不忌讳地一一呈现，虽然某些问题的解决方法未必是完全正确的，但作者敢于提出问题、面对问题、找到解决方法的态度是非常值得赞赏的。我相信，这些来自于一线的实践经验对你会更有价值。

与大多数项目管理的书籍相比，本书还有另外一个鲜明的特色，就是考虑了人的因素，这也使得提出的观点具有很好的实践性。

本书适用于与项目管理工作相关的各种行业的人士阅读，包括领导、项目经理、开发经理、产品经理、业务分析师、架构设计师、软件工程师、测试工程师等等各种相关角色。虽然作者主要经历的项目多为软件开发项目，但项目管理的思路都是类似的。当然，如果你是来自于软件开发领域，会发现作者所说的于你工作中所遇到的会更加的一致。

我很荣幸作为本书的译者，向大家强力推荐这本好书。从我自己的体会来说，这是我看过的项目管理领域最有收获的书籍，我相信你也一定可以从中获得收益。
本书由李桂杰、黄明军共同翻译而成，由于能力和时间所限，疏漏在所难免，请大家批评指正，谢谢！

李桂杰、黄明军

2008年11月

作者: txish 时间: 2009-6-12 18:46
本帖最后由 txish 于 2009-6-12 18:51 编辑

前言

在英语中，我最喜欢的单词是“how”。这是如何工作的？这是怎么做的？他们是怎么做到的？每当我看见有趣的事情发生时，就会充满了与这个短小有力的单词有关的许多问题。并且，我找到的大多数答案都集中在人们如何应用他们的智慧，而非特定的技术或理论知识。

经多多年的项目开发经历，以及对我的经验和其他经理人、程序师、设计师的经验进行比较，我了解到如何把项目管理好。本书是这些想法的总结，涉及用于如下领域的方法：领导团队、管理想法、组织项目．管理进度、处理政治以及让事情发生，甚至是面对巨大挑战和不公平的情况。

尽管本书的标题是个很广泛的领域，但我的工作经验主要来自于技术领域，尤其是微软公司。从1994年到2003年的这段时间，我一直在微软那里工作，领导项目团队，例如：Internet Explorer、Microsoft Windows以及MSN。有几年时间，我在微软的卓越工程组（engineering excellence group）工作。我在那里负责为公司内各个团队提供教学和咨询工作，并经常受邀在许多公开的会议、公司和大学中演讲。本书中的大多数建议、教训以及故事都来自于这些经验。

虽然我的背景来自于软件和网站开发，但我编写的这本书的内容还是很广泛的，利用了工程和管理领域以外的很多参考资料和技术。对于通常的商业世界人士，本书会有非常大的价值。我相信，无论在哪个领域，组织、领导、设计以及交付所面对的挑战，都基本类似。制造烤箱、摩天大楼、汽车、网站以及软件产品所涉及的流程，都会遇到很多相同的挑战，本书主要关注的就是如何克服这些挑战。

不同于其他介绍如何领导项目的书籍，本书并没有依赖于任何正规的理论，也没有推断出创新的理论。替而代之，我主要关注的是实用性和多样性。当人员、技能、态度和使用的战术得以恰当地组合时，无论这些因素来自何处（或缺少出处），项目都将产生好的结果。本书的结构是我所发现的最合理的结构：聚焦于核心情况，提供建议来说明如何正确地处理它们。关于如何挑选正确的主题、如何提供好建议等话题，我经过深思熟虑，下了很大的赌注来做出选择。我希望你将发现我做出的抉择是正确的。

谁应该读这本书？

想了解这本书是否适合于你，我建议你打开本书，翻到目录，从中挑选一个你感兴趣的主题，看看我在说什么。我通常不大相信前言，因此，我建议你也不要相信它，很少有书会在前言之后依然保持与前言相同的凤格或语调。但无论如何，本书还是值得你试一试。

本书对于下面的一种或多种类型的人员将非常有价值：

   * 有经验的团队领导和经理人。对于在任何项目任何担任领导角色的人，本书都非常适用。这些实例来自于软件开发领域，但很多概念都可以很容易地用于其他种类的工作。你也许是正式的团队领导者，或者只是团队中比较有经验的人员。对于本书的某些主题，你可能已经非常熟悉，但本书采用的直接的方法仍将有助于你澄清和精炼你的想法。即使你不同意我持有的观点，你也会有一个清晰的工作基础，来精炼你自己的观点。

   * 新的团队领导和经理人。如果你看看本书目录中列的主题，就会对领导和经理人参与项目时实际所做的每件事情，有个扎实的概要了解。每章都会提供即使是有经验的人员也会犯的、常见的错误，并且说明为什么会发生此事以及可以使用哪些战术来避免这些错误。本书将为你提供一个更为宽广的视野，让你了解即将承担的新的责任，以及管理它们的最明智的方法。因为大多数章节都主要关注于重要的主题，因此，会经常包含一些注释，来参考更深入的信息来源。

   * 程序员和测试人员，或者项目的其他成员。本书会改善你对所做工作的了解，并介绍可以运用哪些手段来有效地工作。如果你曾怀疑为什么项目方向经常改变或者项目为什么管理得很差，本书可帮助你了解其原因和补救方法。至少，读这本书可以帮助你在工作中表现不凡（使你在工作时，始终保持清醒的头脑）。如果你对以后自己管理或领导团队感兴趣，本书将帮助你研究其真正的规律，是你了解你是否已为其做好准备。

   * 商业管理、产品设计或软件工程的学生。我使用学生这个词是从广义来说的：如果你对这些主题有兴趣，或者目前正在研究这些领域，本书应该非常有益。和其他讨论这些主题的书籍不同，本书关注于问题和叙述上。书中的经验和故事都是真实的，它们是教训和战术的基础，而不是反过来。我有意避免在不同学科之间画上界线，以我的经验来看，这些界线对项目没帮助，也无助于了解实际（世界也不会像在大学里那样被划分）。替而代之，本书结合了商业理论、心理学、管理战术、设计流程和软件工程等领域的知识，以任何所需的方式来为重要的主题提供建议。

我在编写本书时，对读者所做的假设如下：

   * 你不笨。我假设只要我选对章节，把它写好，你就不需要我花时间慢慢地建立详尽的信息框架。替而代之，我会主要讲重点，把时间花在这里。我把你当成是找我来咨询的同事——经验也许多些、少些，或有着不同的经验。

   * 你是好奇和务实的。我列举了很多学科的实例，假定你会从网站和软件开发以外的教训中找到价值。这不是障碍，而是为了满足好奇心的要求。有时这些信息只是以脚注形式呈现。我假定你想学习知识，对各种不同的想法保持开放的心态，而且将认识到深思熟虑的意见的价值——即使你不同意那些意见。

   * 你不喜欢行话或深奥的理论。我不认为行话和深奥的理论会有助于学习和应用新信息。我会避开它们，除非它们可以提供未来对我们有帮助的有用的信息。

   * 你对自己、软件或管理不会看的太严肃。软件开发和项目管理可能会很无聊。虽然本书不会是好笑的游戏（虽然由Mark Twain或David Sedans编写的软件工程书籍可能会这样），但我会毫不犹豫地开自己的玩笑（或某些其他人），或者以幽默的手法来举例说明论点。

如何使用本书？

如果读到某处你开始厌烦了，或者发现例子会使你分心，跳过去就是了。我在编写本书时，已考虑到有人会略读，或者只需要特定主题的正确建议。这些章节的安排适合于这些需求，尤其是哪些关于人员的内容（第8-13章和第16章）。但是，按照顺序进行阅读会有好处，因为有些后面的概念是在前面建立的，而且本书基本是按照大多数项目的时间进程进行内容设计的。第一章是本书中内容最广的一章，同时深度也超过其他章节。如果你对为什么应该关心项目管理感到奇怪，或者有其他重要的人士曾说过这个，那你就应该看一看。如果你试过，但讨厌它，我强烈建议你，在抛开本书前再试试另一章。

本书所列的所有参考资料、URL以及附加注释和说明，都放在www.makingthingshappen.org网站上。如果你对本书的讨论组感兴趣，一定要阅读本书后面的附录，它解释了存在哪些讨论组，并为你建立自己的讨论组提供了建议。

现在，因为你很聪明，而且有耐心读完这段介绍，我想，你该急于了解本书的其他内容了（页数、脚注及所有其他的事项），那就继续吧。
如何联系我们

请将本书的建议和问题发给本书的出版社：

   O'Reilly Media, Inc.
   1005 Gravenstein Highway North
   Sebastopol, CA 95472
   800-998-9938 (in the United States or Canada)
   707-829-0515 (international or local)
   707-829-0104 (fax)

我们建立了本书网站，网站上包括勘误表、实例和所有附加信息，你可以访问下面这个地址：http://www.oreilly.com/catalog/9780596517717

如果对本书有建议或技术问题，请发邮件到这个地址：bookquestions@oreilly.com

想要获取关于书籍、会议、资源中心和O'Reilly网络的更多信息，可以访问我们的网站：http://www.oreilly.com

作者: txish 时间: 2009-6-12 18:59
本书是本站受机械工业出版社华章分社委托，代发本书的样章，一方面，供有兴趣的坛友们阅读、学习；另一方面，给对本书感兴趣的坛友们提供一些本书的信息。我手头只有这三章的内容，后续不再续发，如果想阅读全书请购买《项目管理之美》原书。

本帖结贴，谢谢各位的关注。

作者: 下午茶 时间: 2009-8-5 22:35
谢谢分享，抄收了！

作者: wy20030212 时间: 2009-10-8 17:11
书不错，值得阅读思考

作者: 从不知 时间: 2011-7-5 14:35
嘿嘿

作者: 从不知 时间: 2011-7-5 14:35
好啊，，不错、、、、

作者: 海边疯 时间: 2012-2-27 13:10
一起交流！对这个话题感兴趣的朋友们

欢迎光临信息系统项目管理师_2024年软考学习应考交流_信息系统项目管理师考试 (http://bbs.tuandui.org.cn/)