《项目管理之美》样章更新中

txish

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

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

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

txish

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

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

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

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

人们被激怒的原因概述

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

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

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

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

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

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

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

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

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

txish

好流程的效果

    我把流程定义为任何可重复的一组动作，由团队决定定期执行以确保事情会以某种方式完成。流程有很多其它名称：规则、指导方针、形式、程序或限制规定。（例如，如何签入代码、测试和构建，就是工程流程的常见实例。其它实例包括规格说明书的撰写和管理日程表和进度表等等）。好的流程可以提高项目完工的机会，而且效益要大于成本。然而，因为很少花时间研究流程存在的原因，或者流程（应该）解决什么问题，所以很多团队只是空有很多流程而已，无法从中获得益处。
   
    有时，问题出在是谁有权力身上。任何有足够权限的白痴，都可以想像出最令人厌恶的白痴体制来做事，并且逼迫团队服从它。结果，当团队奋力在那个流程下求生存而且真的做出一些事情时，掌权的人可能甚至会说，那个流程对事情成功起到了贡献（却看不见，即使没有那个愚蠢的流程，团队也一样会成功）。如果他们有足够的权力，他们可以镇压任何反抗，甚至继续增加更多步骤来折磨团队。

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

    但是通常问题在于建立流程的复杂度。流程是试着组织大家如何工作和互动的，这两件事非常重要，但又非常有组织。人们的工作方式不同——他们对正式的控制有不同的偏好和容忍度。如果建立流程的人不注意，这个流程很容易变成瓶颈，让人们的工作慢下来，束缚他们的自由（感觉）和活力。
   
    建立好流程的技巧，就是要了解两件事：通常能让项目和团队成功的事项，以及使当前项目和团队与其它项目和团队有所不同的事项（请参阅图10-1）。了解通常如何制定好的团队决策是不够的：你必须对共事的当前团队的文化、个性和习惯负责。有时，不同的文化或项目需要不同的方法（例如，防抱死刹车嵌入系统的决定，和Steve朋克摇滚乐队网站的决定是不一样的）。通常，最好是让团队自行管理，而不要让上级单位管理。让团队修改和创建自己的标准规范，而不是复用标准模板。就像任何类型的协商那样（请参阅第11章），涉及到流程时，你必须要清楚知道你关心的利益，而不是特殊的立场。

txish

可在此找到好的流程

    通常能让团队有效的事情


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


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

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


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


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


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


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


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

txish

好流程的公式

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


    首先，考虑流程的成本：设计流程的时间（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

从下层管理流程

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

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


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


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


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

废话大仙

我也来顶

txish

不令人讨厌的电子邮件

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

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

    一个主要的挑战就是，很少有人承认他们寄出了很差的电子邮件。例如，做以下测试：利用你自己的主观判断，你从自己组织成员那儿收到的电子邮件中，具有高质量邮件的百分比是多少？中等质量的是多少？完全没有用的是多少？现在，问你自己，你寄的电子邮件中，各有多少百分比符合这每一种情况。以此为试验，我曾问过一个由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

差的电子邮件实例

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


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


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

    主题：最近检查讨论摘要

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

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

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

    谢谢。

       Jack


很好的电子邮件实例

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


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

    主题：新的签入程序流程

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

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

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

    谢谢。

       Jack

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

txish

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

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

    初学者要了解开会有多昂贵。如果会议持续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，你们两个去了解和处理这个问题，好吗？到时再回来，让我们知道你们的决定。”当其他五、六个人已经厌烦了一整小时，绝不要再让两个人控制发言权。

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

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