经验法则7　组建功能小组

2006版说明　"组建功能小组"仔细说明了一些与批评相关的问题。我在下面提议的"研讨会"解决方案发展为"完美行动"准则，它是最易于采用的准则之一。

现在我们相信，共识只是校正的初级阶段。于是我们使用"个人校正"和"决策过程"准则来实现全体一致并利用集体智慧，而不是直到最终也只找到为数不多的共同点。

在微软的Visual C++(www.cppentry.com)团队，我们组建了功能小组。我毫不掩饰自己对功能小组的热爱。在我们团队中，功能小组曾经发挥了惊人的作用。

如果你问Visual C++(www.cppentry.com)团队中的质保人员："你负责什么工作？"他们会告诉你："我的工作是交付产品。"是交付产品，而不是测试产品，单纯的测试是一种片面的观点。质保人员的工作是交付产品。质保人员还会参与产品开发、产品设计，了解客户需求，实际上，他们还需要了解技术计划、产品的运行状态、市场环境以及公司运营等各方面的情况。

我们组建了开发团队，这个团队由质保人员、开发人员、文档人员、项目主管和营销人员（如果需要）构成，并采用一种传统的组织结构。虽然这种组织结构的层次性不是很强（至少在最好的情况下是种扁平结构），但是，我们仍然从上述四五类人员中选派出代表，组成一个矩阵形的功能小组。我们选择了一类产品，如foobar，并告诉功能小组："好，你们就叫foobar小组。"于是，他们就成为foobar小组。随后，他们制定了小组的里程碑和工作计划。他们甚至确定了自己的工作流程，虽然我们鼓励每个小组采用相同的工作流程。

功能小组的工作涉及授权、责任、认同感、共识和平衡这5个方面。我认为迄今为止，功能小组是解决我前面提到的一些组织问题的最佳机制。

授权　将某个特殊的技术领域完全委托给一个职能小组，或者单独一个职能层（如开发小组），虽然说这种做法很难让我们放心，但是，将其托付给一个人员配置均衡、由多个领域的人员组成的团队，则无疑是极佳做法。来自生产第一线的专家比其他任何人都了解他们所工作的领域，如果不允许他们掌控自己擅长的领域，这种做法简直是愚蠢至极。我可以记起一些主管做出的许多错误决策（以及明智决策）被其他主管推翻的例子，但是，我记不起有任何一次功能小组提出的建议被管理层驳回的情形。而且我认为，现阶段我们团队也不会出现这样的情形。这说明，如果获得充分授权，功能小组不但能够发挥巨大的作用，其提出的建议也具有非常强的针对性。（这同样证实良好的人才雇用方法的重要性，我们将在第一部分的附录中讨论这个问题。）

责任　一次，我与某个功能小组的组长进行了有关软件开发中责任的有趣讨论。我们讨论的问题是："你的责任是什么？"我认为，多数团队中人们的多数好想法都被白白浪费或忽视，因为责任心不强的团队成员可能会非常轻率地对待他人提出的新点子（我在前面的经验法则4中已经提到过这种行为）。

首先，有了想法或新点子的个人或团队可能会觉得："这不是我负责的工作。"因此绝不会提出建设性的建议。基于这一想法，人们随后表现出的各种"病态"行为简直令人震惊。人们从不说出自己的想法，导致各种混乱、考虑不周的举措和无谓的花费。如果团队成员不去表明自己的观点，他们就会选择离开。

其次，如果有人说出自己的想法或新点子（这是一种极度冒险行为），其所针对的个人或团队（目标）可能会产生防范心理，做出各种激烈的反应。有时候，我们很难察觉这种防范心理，特别是在将防范心理视为错误行为的团队中。具有讽刺意味的是，越是成熟的团队，越具有防范意识，越会想方设法实施防范。如果个人或团队哭着喊着要求维持现状，拒绝改变，那一定应引起注意。

再次，提出创新观点的一方最初可能不会坚持己见，但等到话一出口说给对方听，情况就变了。人们普遍存有防范心理，也都想争强好胜。因此，人们表达想法时往往容易让人听出咄咄逼人或评头品足的味道来，其实说者无心，但却听者有意，这种情况十分普遍。这反过来又正好助长了上面提到的防范心理。于是，听者敏感地察觉到这种攻击性，并采取防范措施，因而忽略了有用的信息。同时，提出观点的一方也有些恼火，认为不值得进一步冒险再去说服目标，就贸然给对方扣上傻瓜的帽子。

因此，人们错过了许多重要的想法。就我所知，解决这个问题的唯一办法是召开研讨会。在研讨会上，人们会采取自愿的方式，恳请同事就自己的观点发表批评建议。只有在这种积极友好的氛围中寻求反馈意见，人们才会或多或少地放下防范心理。由于对方愿意接受批评，提出建议的一方也在很大程度上弱化了自己的攻击性。由于每个人或团队都是其他人的潜在目标，因此，这种研讨会的形式让每个人都解除了防卫心理。让我觉得奇怪的是，人们并没有更频繁及更广泛地采用这种"研讨会"手段。

我已经在我管理的一些团队中传播"案例分析"的理念，成功地将研讨会的观念应用于解决现实中的软件开发问题。其过程是这样的。首先，一名成员自愿讲述一种情况，当然是他自己亲身经历的，与当前的（或者至少是最近的）工作有关，并且通常与人际交流有关。当事人讲出让自己烦恼的事情，例如"没人接受我的观点"或"没人看我的电子邮件"，或者"某开发人员不按计划完成工作"。这名成员先花几分钟时间谈谈情况，有时他会把当事人的名字改一改，有时则直接指名道姓。然后，团队的其他成员向他提问，获取更多信息，并澄清一些问题，例如，已经做过了哪些尝试。接下来，整个团队就这个问题展开长时间的讨论。

这种简单的技巧在两方面一直让有我惊喜不已。第一，研讨会过程中将产生大量新点子。我都数不清有多少次讲述者拍案高呼"这是个好主意"，并在笔记本上飞快地做着记录。第二，每次几乎总会引起大家的共鸣。其他成员可能会说："我上个月也遇到过类似的问题。"讨论一些类似的问题后，有人会指出："你的问题不正是某某问题的特例吗？"随后，他们会总结出处理这类问题的一般原则，或出现这类问题的一般情形，并将这一切记录下来。

赋予责任的做法具有诸多优点，而且少有限制。在一个人员配置均衡的团队中，如果大家共同承担起设计、开发、调试、质保及交付等各方面的责任，那么，他们就会想出办法，彼此分享重要的意见。由于每位成员都负有责任，一旦他们发现问题，就会主动承担，并且把这个发现传播到整个团队中去。

认同感　充分授权和责任感必然会带来认同感。人们会认同他们能够控制或影响的事情。控制的程度越高，认同感也就越强。虽然这种认同感大多有利，至少是开发出伟大软件的先决条件，但它也可能使团队成员将个人的负面情绪融入到产品中。例如，某位团队成员的自暴自弃可能会表现在他的开发工作中。

在跨职能的功能小组中，个人会逐渐融入到部分产品开发中，而不是仅仅负责某一项专门的技术。如果出现问题，你很难推卸责任，个人的成功或失败全都一目了然。如果你每次向管理层寻求帮助，他们都给予积极的回答，说："为了实现目标，你还需要什么帮助吗？"那么，你不可能将责任推给他们。你也不能责怪其他小组成员，因为大家都在全力支持着你的功能。那么，问题到底出在什么地方呢？在充分授权的环境中，你必须从自身寻找答案。

共识　功能小组应建立共识的氛围。既然大家讨论的是产品特性而不是各人的职责，并且大家的责任是相互的，因此大家会敞开心扉，这既安全又有必要。我看到这些团队进行重组、建立共同的目标、重新分配资源、更改工作计划，而没有造成任何棘手的冲突。即使出现冲突，这些冲突也并非个人冲突，因此往往可以在团队内部进行解决，而不必求助管理层。

平衡　对于功能小组而言，平衡是指技能多样化、工作分配多样化以及观点多样化。功能小组由来自不同功能领域的人员构成，因而具备多样的技能。通常，擅长某种技能的人才针对他们所从事的领域会提出一些补充性的观点。由于每名团队成员关注的问题各不相同，因此，我们可以通过小组内多样的观点，来理解小组工作分配的多样性。各小组关心的主要问题如下。

项目管理　小组的状态如何？项目的进度如何？我们管理层的效率如何？我们当前在项目周期的什么阶段？工作计划是否适当？是否有工作需要其他小组的协助？我们的目标是否清晰？我们今天是否自己欺骗了自己？现在还有哪些工作没有完成？本周小组工作的主题是什么？

质保　开发人员是否能够按时交给我下一批代码？我们处理bug的进展如何？我们发现了哪些类型的bug？产品还缺乏哪些功能？这个平台的性能如何？本周我是否需要提出任何红色警告？项目管理层是否清楚这个平台的稳定性？我们小组成员之间的沟通是否顺畅？对于小组当前的状态，大家是否有着共同的认知？我们为本周制定的目标的合理性如何？

开发　我按时向质保人员和文档人员交付本周任务的可能性有多大？这款产品是否经过精心设计？用户是否会如期获得该产品？产品的使用说明是否简洁明了？产品是否足够快速，足够紧凑？我是否已经修复这款产品中的所有bug？我所做或未做的工作是否给其他团队成员造成妨碍？我是否认同本周的目标？这项工作是否符合策略要求？它是有助于技术计划的执行，还是完全是浪费时间？

产品经理/市场营销　客户对这项功能会有什么看法？我如何向他们生动地传达这项功能？这项功能会触发哪些情绪？我们如何修改产品来强化这些联系？从我口里听说这项功能，客户会有什么感受？他们什么时候会初次体验到这项功能？当前这项功能是否会促进我们与客户之间的关系？媒体对这项功能有什么评价？开发这项功能的背后有什么故事？我是否完全了解这项功能及其重要性？如期交付产品的可能性有多大？我是否给组织的其他部门中引入了更多的不确定因素？或是引入更多的确定因素？当前，我们如期交付产品的可能性有多大？

文档/用户培训　这项功能的操作是否可以更加简化？我对如何使用这项功能的解释是否清楚无误？我们是否可以做到清楚说明这项功能，而不需要其他解释？并且使这项功能最大限度地展现自己的作用？如果我现在仍然无法清楚地说明这项功能，时间上是不是已经太迟？这项功能是否通过质保人员的检测？我对这项功能的感觉如何？有什么办法可以改善这项功能？我的表述是否可以更加简洁？小组的其他人员对于我的工作是否满意？

虽说功能小组非常重要，但组建它们也并非易事。由传统的组织结构转而成功运用功能小组，这是一个非常困难的过渡。这些困难可能来自功能小组内外。

在功能小组内部，将会存在多种不确定因素。小组成员并不知道他们的自治权有多大。他们会觉得，如果不加明确，他们应该会合作得更好，因为很明显，管理层希望他们成为一个"团队"，不管这实际意味着什么。于是，小组成员仍旧会扮演传统的角色。最初自然是开发人员唱主角。看起来，似乎小组成员都在扮演他们最初的角色，只是成员之间的沟通略有改善。实际上，在一开始，为组建小组、召开会议、决定人员分配、重组团队等要付出巨大的代价，费尽九牛二虎之力只达到沟通略有改善这样的效果，似乎得不偿失。

人们不会在项目开始之初就组建功能小组。只有在项目不可避免地将要失败时，人们才匆忙建立功能小组。通常，如果管理层让功能小组"自生自灭"，小组成员会感到沮丧，觉得被抛弃了。这种"自治"会让人感到极为不适，因为人们不习惯授权给自己。

小组内部也会存在大量矛盾和冲突，这会是一个长期的问题，因为大部分人都肤浅地认为，团队协作不过是达成某种脆弱的共识和建立表面上的合作而已。

唯一有价值的共识是专注的成员们在相互冲突中形成的创意。这样的共识会在度过无数个不眠之夜、害怕被拒绝以及反复考验个人勇气之后才能形成。于是，冲突成为这种共识的标志，它往往也是进步的先兆。

但起初，功能小组的作用并未显现出来。这时，开发团队并未遇到太大的挑战，组建功能小组好像是管理层在赶时髦。

最终，一些小组成员开始认识到，他们实际上握有权力；他们不会受到任何人的限制；他们可以任意使用资源；他们的创造性受到欢迎；管理层乐于支持他们实现目标；实际上，他们可以毫不费力地实现软件开发的目标。在这样一个令人振奋的重大时刻，他们意识到小组可以自由发挥其作用，并且有责任这么做。

当然，这又引发了另外一些问题。许多充满创意的优秀人才下意识地认为：他们受到某种事物的限制，一些不利因素在阻止他们发挥才智。他们心中存在一种固有的"被管制"的感觉，这阻碍了他们充分发挥自己的创造能力。无疑，这种自我抑制源自于童年时期父母对孩子个性的压制，这种压制由上一代盲目地传至下一代，在孩子心里形成一种根深蒂固的恐惧：如果我完全与众不同，你们（父母亲）就会抛弃我。由于很少有父母亲会明确限制我们发展自己的独特品质，因此，我们对来自父母的这种负面"压制"非常敏感。要求孩子成长为普通人，保持平庸，遵循某种均衡的价值体系，这样做的动机可能出于某种健康、保护性的冲动，但是，这种冲动却成为阻止我们发挥聪明才智和创建伟大软件的最大障碍。

我们的这种自我抑制（即不由自主地寻找负面的东西），虽然在病态环境中是正常的，但在健康环境中却成为一种病态。于是，我们在管理层和其他权威人物面前变得诚惶诚恐，因而无法专注于自己的工作，充分发挥自己的才能。实际上，管理层可能只是下意识地发出"停止"信号（就像父母亲呵斥孩子一样盲目和可悲），不过，总的来说，在项目开发的这个阶段，管理层在很大程度上是提供有利而积极的支持。至少，他们会向小组成员表达他们的信任。

当小组成员逐渐意识到他们不会遭到任何人的反对，他们必须为项目的成败负责时（这是一种愉快的体验），他们会努力向其他成员传达这种自由及充分授权的感受。每位小组成员都会在不同的时刻，从不同的角度，或多或少地体会到这种个人自由。观察成员们体会这种自由的过程是一种奇妙的经历。在这个过程中，每个人都需要接受挑战、受到鼓励、得到帮助。在或快或慢地认识到这种自由的过程中，每名成员都需要具有适应能力和耐心。这个成长过程虽然艰辛，但却是伟大团队的必由之路。

我还发现，职能部门（如文档部门）的成员在功能小组中的参与程度是高是低，与他们在原有的、未获充分授权的体制中的成功程度成反比。如果在一个整体功能失调的组织中，有一个职能小组表现尚佳，并因为它们的独树一帜而取得了一定程度的成功，那么，当组织中其他部门的情况改善后，大环境正常时，这个小组的成员反而不容易改掉其"光荣孤立"式的种种习惯。

在功能小组之外，各职能领域的主管（开发主管、质保主管等）也有着矛盾的心情。尽管整个团队缺乏创意和协作，但在"组建功能小组成为潮流"之前，他们已然是成功的主管。因此，至少在某种程度上，他们必然不会赞成功能小组发展壮大。毕竟，他们是在旧有病态的体制下被提升到管理职位并树立权威的。他们是从可选的人才中被选拔出来的，虽然旧体制中广泛存在的"功能失调"给他们造成一些障碍，但他们仍然取得了一定的成功。现在，他们需要涉足不太熟悉的领域，而且，在当前提供充分授权的环境中，他们以往自主的能力无法展现。此前帮助他们取得成功的方法现在却难以适应新环境的需求，他们曾经受嘉许的做法现在却受到惩罚。

这些主管知道如何在缺乏创意和智力投入的旧有的体制下，以传统的方式交付产品。当他们看到功能小组最初采取的尝试性步骤时，他们会表示担心，甚至会提出警告："他们那样做不对。我会这样做。我应该告诉他们怎么做。"他们的这些反应出自真正的担心。同时，作为主管，他们几乎无法抗拒掌管一切的诱惑。起初，高级主管会感到恐惧（我就曾如此），整个功能小组是不是疯了，让经验不足、缺乏判断力的人员决定技术的走向，这种做法真是荒谬，他们定会再犯主管曾经犯过的错误。

在主管逐渐放弃命令和控制，学会鼓励和培训之后，一些异乎寻常的讨论开始了，大家开始商量应该由谁决定什么事情，以及主管应扮演什么角色。

我也曾有过疑虑。几位关键的主管都很疑惑，对于一个已经相当完美的团队，我们还要做出什么改善。我曾夜不能寐，辗转反侧，思考究竟为什么要用这个古怪的想法搅得大家心神不宁。后来我们这些主管将这段时期叫做"功能小组忧虑期"。慢慢地，我们意识到，我们的职责是培训组员，向他们提出挑战，给予鼓励，给开发过程增加价值。如果我们的想法是最好的，就肯定会被采纳。虽然权利主要集中于功能小组手中，但我们可以对他们的假设提出置疑，让他们检查其动机和行为，帮助他们达成共识和处理冲突，并向他们清楚表达对其目标的理解。我们可以指导他们提高效率。因为我们希望各小组自己承担责任，所以我们必须赋予他们权力，让他们决定自己认为适当的开发步骤。

当然，这整个过程是循序渐进的，在某种程度上说，它还在不断完善。很多时候，功能小组会要求管理层做出一些决策，或为他们设定目标。同样，管理层有时也会做出错误的决策，将一些不适当的任务交给小组完成。管理层与功能小组之间的关系并不单纯。但是，在这种变革中，我们能够管窥组织创建知识产权的终极策略。

在理想情况下，项目开发团队基本上由两种角色组成：创建者和促进者。创建者专门从事开发、营销、质保或文档工作，或负责其他一些直接应用的软件领域。促进者则专门提高团队认知，负责创建一个有利于发挥创造性的环境，并提供使创意变为现实所需的各种资源。促进者确保团队把所有想法全部提出来。促进者这一角色是由今天的主管和项目经理职位进化而来的，他们的技能在产品中间接体现出来。

促进者必须与创建者一样对最终产品负责，而创建者则必须与促进者一样对提高团队的认知负责。小组之间相互负责，并以某种方式"审核"对方的行为，这是一件好事。旧的组织结构慢慢失去其重要性。真正的权威来自于知识，而非职位。这是一个充满挑战的目标。

掌舵的主管