第4节

吗？程序是否执行够快体积够轻巧？我清除了所有的错 虫吗？有没有人因为在等待我的工作进度而耽误进度？

我 是否完全了解本周的短期目标？我的工作是否符合策略上 的方向？而且工作内涵对技术规划有无贡献，或只是个早80晚会被丢掉的垃圾？产品经理／行销：产品特色是否吸引顾客（包括潜在 顾客）？我该如何生动地表达这个产品的特色？它能否牵 动顾客心中的心理或情感反应？我们应该如何修改产品， 才能加强顾客的购买欲？当顾客听到我们的产品时心里会 有什么样的反应？顾客在什么时候会使用这个产品？产品 特色是否能加强我们与顾客之间的关系？媒体是如何报导 我们的产品？开发这项产品特色背后的动机是什么？我是 否完全了解产品特色及其重要性？准时完成的可能性有多 大？我是否应该向公司说明产品的不确定性有多高（或是 非常确定）？产品成功推出的机会点在哪里？技术文件／教育训练：这项功能是否以更容易的方式 使用？我对它的说明够清楚吗？使用者接口能不能设计到 不必学就能操作？如果我现在还没有完成文件，会不会太 迟？这项产品特色是否已经通过品保人员的核准？我对这 项产品特色有什么感觉？我能不能用更简洁的方式来说 明？其他的组员认同我写出来的文件吗？虽然特色监督小组是非常的重要，但要成功地组织起 来可不是件容易的事。

在传统的阶层式组织中加入横向的 特色监督小组是非常困难的转变，这种转变上的困难可能下载来自团队的内部或外部。

微软团队·成 功 秘 诀法则7建运用特色监督小组81在特色监督小组的内部，本身就会面对相当大的不确 定性，大家不知道自主权的范畴是什么，只知道我们是一 组人，应该在一起做事，但不确定的该用什么样管理方式。 特色监督小组的本意是突破传统角色的藩篱，但是组员却 会很自然地以原来的传统角色来为自己的定位，如此特色 监督小组的作用就会明显受限。开发人员常常会主导小组 的运作，导致使其他的功能不容易发挥。如此一来，特色 监督小组的横向组织功能大概只能改善沟通，这似乎与它 的高成本（组织小组、召集开会、物色人选、行政作业等 等）完全不成比例。

在很多人的心中,所谓的团队只不过是虚伪矫情的共识和假装一团和气罢了。

而且，人们总是要等到问题已经很严重时，才会成立 特色监督小组。如果这个时候管理阶层放手让他们自行决 定命运，组员反而会有被抛弃的沮丧感。向来不习惯自治 的组员突然要组织起高难度的特色监督小组，一定会觉得82非常不安。特色监督小组的功能在这样的情况之下很难发 挥，问题反而很可能雪上加霜。特色监督小组本身也充满了矛盾和冲突，因为在很多 人的心中，所谓的团队只不过是虚伪矫情的共识和假装一 团和气罢了。特色监督小组惟一不可磨灭的贡献是创意，代价是无 数不眠的夜、对拒绝的害怕、对个人勇气的磨炼。于是，“冲突”便成了特色监督小组的标志，虽然它也是成长的 动力。所以，项目的初期往往看不出来特色监督小组的重要 性，因为没有什么挑战性，特色监督小组看起来像是管理 阶层在搞的流行玩意。最后特色监督小组还是会发挥很大的效用，只要它能 被适当的组织和赋予足够的权力。它有资源、有创意、有 管理者支持，能够发挥惊人的力量，在关键时刻，他们会 发现自己竟然能够搞定这么多、这么重要的事情。当然在特色监督小组内也有它的问题。

很多头脑优秀 而充满创意的人不敢提出他们的构想，有一种内在的负面 力量阻止他们将自己的天份表现出来。大多数人都会害怕 在团体中被排斥，这种心理源自于做个乖小孩的童年经验：法则7建运用特色监督小组83由于父母很少会限制小孩的发展，因此小孩对于“不要这 样”的信息特别敏感，为了保护自己，尽量表现得与大家 一样，服从于大多数平庸者的价值体系，而不太敢表现自 己的才能。然而，与众不同才是软件开发的成功要素。这种自我设限的负面行为，虽然在一般的生活环境中 是正常现象，但在正常的软件开发环境中却是病态。一般 人都会为了在阶级系统中求生存而学会“善伺上意、察颜 观色”，自然而然地会去迎合管理者的态度而改变自己的 行为。然而，管理者也会不知不觉地发出“停止！不要这 样”的信号（也许是出自盲目的策略或单纯的固执，就像 父母对孩子的行为教育一般），导致属下害怕功高震主、 得不偿失。管理者应该率先鼓励人们尽量发挥，对于优异 的组员表示肯定和支持，至少对于不同的意见采取开放的、 正面的态度。另一方面，每个人对于这种意见自由也会有不同的反 应。

每个人感受到自己被充分授权，一肩挑起一件大事的 成败责任，会自然地把这种情绪传达给团队中的其他成员。 这种个人自由（personal liberation）在不同的时机会以不 同的样貌呈现，也会以不同的方式强化，每个人都不一样， 但这并不容易被观察出来。每个人都需要被挑战、被鼓励、84被栽培；弹性和耐性使个人形成团体，而以自己的脚步共 同成长。这种成长过程虽然艰辛，却是成为优秀智能工作 团队的先决条件。

在特色监督小组中容易发生奇怪的对 话，像是谁能决定什么事，除了控制 之外到底该有什么样的管理角色是管理者应该担当的。

我也同时注意到，每个人对横向组织（特色监督小组） 的参与程度，恰好与他原功能组织（例如系统文件等角色） 的成功程度成反比。如果整体组织的功能表现不彰时，其 中某个功能部门的表现还算不错，致使这个部门的表现显 得突出，那么在整个组织效能改善之后，原来的疏离感反 而使得这个部门的人较不容易融入横向组织中。我们再来谈谈特色监督小组可能面临的外部问题。参 与者本身所隶属的功能部门管理者（如开发经理、品保经 理等等之类的各式经理）有他原来的部门目标，现在要抽 调人力参加特色监督小组，当然不免有些挣扎。也许其原法则7建运用特色监督小组85属的功能部门不是那么有创意，但在这“疯狂的特色监督 小组”成立之前，他们对组织也有一定的贡献，或多或少 都对特色监督小组抱持着对立的态度，毕竟，他们已在原 来的专门领域建立起一定的责任感和权威性，现在要他们 加入一个陌生的组织，做一些自己不擅长事情，而且在原 本未被授权的环境中，他们凭者能力取得一席之地，但现 在不需要了，却在新环境中被授权却更多，使得他们对原 有的成功价值产生怀疑，因而使他们更难适应新的环境。

管理者知道如何以传统的方式推出软件产品，当他看到特色监督小组刚成立时所作的尝试，会觉得太幼稚了， 会感到非常地担心：“他们这样做是错的，应该由我来做， 或是由我来教他们如何做。”这真的是善意的关心，管理 者无法忘记自己对产品的责任，会怀疑特色监督小组是不 是疯了（我自己就曾经这么想），竟然让这些没有经验的 笨蛋决定技术与产品的发展方向，并且管理者从前犯过的 错误他们现在一样照犯！管理者学习在“鼓励属下”与“控制属下”之间取得 平衡，于是发生奇怪的对话，像是谁能决定什么事？除了 控制之外到底该有什么样的管理角色？如果不是管理者该 做的决定，那么他要如何负责？如何自处？如何定位？

86当年我也曾经怀疑过，和其他多位资深经理怀疑我们 为什么要大费周章地成立特色监督小组，我曾经在深夜醒 来，自问我们究竟为什么要这样自找麻烦，想出这种疯狂 的主意使每个人都全心投入。渐渐地，我们了解到管理者 的角色应该是教导、挑战、鼓励，并肯定这个创意思考的 过程。如果我们的观点是对的，事实自然能够证明它。在 授权给特色监督小组的同时，经理挑战组员假设的前提， 让他们能够自我检视自己的动机和行为，协助他们达成共 识和化解冲突，并让他们明白管理者了解他们，会支持他 们的决定。我们训练组员自己去追求效能，这是非常基本 的要求，因为我们要让组员自行负责，让组员有能力决定， 并且以自认最理想的方式去实现。

权威是来自学识，而非职位。

当然，这整个过程是循序渐进的，就某种意义来说， 它仍然不断地在发展。有很多时候，小组希望由经理直接 替他们做决定和设立目标；也有些时候是经理不当地命令 小组做事。传统性的功能组织和横向特色监督小组之间，法则7建运用特色监督小组87没有全然的界线。但是在这一切都在转变中，我清楚地感 觉到大家都朝着正确的方向在进步。在一个理想的项目中，基本上有两种角色存在：创造 者（c r e a t o r）和推动者（f a c i l i t a t o r）。创造者是一些专业 人员，例如开发程序、行销、软件品保和文件撰写；而推 动者则负责凝聚团队共识和维持最佳的开发环境。在这里 可以无忧无虑地尽情发挥创意，有充足的资源解决问题和 实现理想，组织的运作非常有效率。推动者就是项目经理 或一般的管理者，他们的能力不直接显示在产品中，但却 是推动产品成功的保姆。推动者必须像创造者一样对最后的成果负责，而创造 者也必须像推动者一样对团队共识负责。让两种角色互相 负责是很好的做法，可以互助互补。传统阶层式组织的重 要性逐渐降低，权力来自于知识，而非地位，这是一项革 命性的突破，值得所有的软件开发组织深思。

管理者的角色是舵手下载

法则 8

Use program managers项目经理的职责90项目经理是软件开发团队的一份子，他的职责是：领导大家定义出一个成功的产品。

引导大家对产品注入深切的期望和信念。 带领团队将理想实现，变成可预见的产品诞生。 要定义“项目经理是什么”，倒不如从定义“项目经理不是什么”，还比较简单些。一位项目经理实际所扮演 的角色并不是一般人直觉上想到的工作性质而已。项目经理并没有（或只有很少的）正式的权力或地位， 至少刚开始时是如此，所以项目经理通常会为此感到非常 地焦虑。笨蛋项目经理可能以为他的工作是写出软件规格， 让其它人去写程序、测试程序、撰写文件等等，最后完成 项目经理心目中理想的成品。在最好的情况下，别人会认 为他天真；在最坏的情况下，别人会认为他愚蠢、成事不 足败事有余。在项目经理可以对团队有任何的价值之前， 不应该有任何直接的控制权；幸好，一个健全的开发团队 不会让这种事情发生，组员会适时阻止项目经理不当地直 接控制。当然这类事件会导致在项目经理心中有些气愤和挫 折，因而要求上级授予更多的权力，如果上级愚蠢到真的 这么做，就会导致更严重的愚蠢事件（请参考法则 9：要下载权威，不要霸权）。

微软团队·成 功 秘 诀法则8建项目经理的职责91

通常是等到情况已经坏到无可救药 时，项目经理才会明白“政治”只是合法的借口。

对于这类项目经理的挫折感，我见过很多不同类型的 反应。最常见的一种是项目经理开始对他真正的角色─ 领导─做出负面的、反叛性的行为，这种行为通常是通 过对“政治垃圾”（political bullshit）的厌恶来表现。除了 对科技要有一定的知识之外，软件开发团队的领导人还得 具备对人性高度敏锐的观察力，必须能够看出在团队外在 行为背后那些隐藏着的情绪因素。可想而知，有些专案经 理为了避免那些剪不断理还乱的人性问题，开始寻求比较“清爽”的自我形象，而在软件公司中免不了的科技挂帅 文化，很容易视“政治”为畏途。当然，驾驭技术要比掌 握人性要简单多了。然而，当人们抱怨政治的奸诈诡谲时， 其实是对不良领导的反感所致。不幸的是这种不满的情况 比比皆是，健全的组织却少得多。于是失败的项目经理把92过错推到“政治”这个字眼。然而，大概要等到情况已经 坏到无可救药时，专案经理才会明白“政治”只是合法的 借口，他应该用领导代替控制，才懂得为自己的偏执负责。 有谁愿意身处于乌烟瘴气的组织环境？但是当项目经理或 任何人伤害组织的健全性时，那就是走向失败。

虽然刚开始时项目经理对自己的角色非常不确定，不 能肯定自己对项目的贡献度，还对政治嗤之以鼻，不过当 他了解到应该以领导代替控制时，就会觉得一切都得心应 手。项目经理应该是以栽培和教育的全方位领导，来引领 软件的发展。项目经理应该要有技术的背景，而且必须在两种层 面非常专精：一是对开发产品所使用的技术很熟悉，二 是拥有建构软件的技术领导能力，而后者是本书主要的 讨论范围。项目经理必须精于哄骗、驱策、鼓励、要求 他的团队做出最好的软件和表现出最好的工作效能，他 清楚知道软件制作过程中每一项的投入和产出细节，他 必须懂得用最好的方式定义产品和维持健全的技术。最 后，项目经理还必须是团队的发言人，面对媒体、客户、 以及整个组织。

项目经理是维系团队灵魂的关键人物，他应该是擅长法则8建项目经理的职责93沟通和倾听的人，具有设身处地为他人着想的本领。总之， 项目经理是软件开发的核心人物。

团队的精神在此我强调一个观念，在后面也会再重复提及：软件 代表着创造它的团队。你想了解这个团队？看看他们的软 件就知道了，反之亦然。我特别强调这个观念是因为这是 软件开发管理的基础。在某一个时间点或是从某一段描述 中，或是从这个团队的行为，常常无法准确判断这是个什 么样的团队，但软件不会说谎。软件会忠实地展现创造它 的团队：一切优点和缺点，天赋和天谴，从潜伏期的小病 到最极致的团队合作。若对这个团队有任何疑问？他们的 软件作品就是答案。如果你的询问对象是人，你还得注意 他的表情和肢体等等隐性语言，但是如果你仔细研究他们 的软件作品，你不必问任何人就知道他们团队有没有问题。 软件会自我表达，它绝不说谎，也不隐瞒。这项理论是软件开发管理的基础，可以用一个恒等式 表示：团队＝软件(team = software)94基本的原则是：如果你对团队有任何疑惑，去看他们 的软件；如果二者一致，你可以相信自己看到的团队现状。 相反地，如果软件未能表现出应有的水准，表示团队有问 题，不论团队看起来多么健康，你都应该去分析、去发掘， 找出问题解决掉。

团队的精神法则8建项目经理的职责95团队等于软件，不错，但团队是什么呢？你是以什么 方式或风格领导这个团队？我相信软件开发的关键是与“团队精神”（group psyche）保持密切的连系（P s y c h e是 小爱神丘比特所爱的美少女的名字，原意是灵魂或精神， 这里的灵魂不是宗教上的含义，那是s o u l，精神也不是强 调团队的合作协调，那是t e a m w o r k，group psyche是指一 群人所共有的中心思想和心理状态）。这样说很抽象，下 面是“团队精神”的具体描述：1. 一群人同心协力，集合大家的脑力，共同创造一项 智能财产。2. 个人的创造力是一种神奇的东西，源自于潜在的人 类心智潜能，它被情感丰富，而被技术束缚。3. 一群人全心全意地贡献自己的创造力，结合成巨大 的力量。结合的创造力由于这一群人的互动关系、彼此激 荡，而更加复杂。4. 这种复杂的情况之下，领导变成像是人际互动的交 响乐指挥，辅助并疏导各种微妙的人际沟通。5. 在团体中的沟通和互动是正确而健康时，能够使这 一群人的力量完全结合，会产生相加相乘的效果，抵销互 斥。沟通顺畅能使思想在团队中充分交流传达。

966. 团队工作的品质比时程更重要，而作品的伟大是需 要对“团队精神”特别加强，才能达成。“团队精神”可 视为个别成员精神的平均值，而个人的精神（p s y c h e）则 是使他能感觉、能思考、能推论的内在力量。7. 倘若忽视了“团队精神”，则只会有平庸的成果。 那么，如何照顾“团队精神”呢？我的答案就在本书中。

法则 9

Be an authority ， not an authority figure 要权威，不要霸权98在组织中，大多数人都会寻求一种权威，而不在乎这 种管理风格好或不好。这种心理现象可能是因为人们希望 重建来自家庭的权力结构：父母亲控制并保护孩子，而孩 子依靠父母。无论这种需求来自何处，人们迫切地需要权 力和依靠的对象，以致将领导者投射成权威的化身──也 许另一方面管理者也有迫切的掌权欲望吧。权威的目的是让每一位团队成员都有自己的专业权 威，和团队的专业自信，这才是管理者真正的权威。在任何社会中，人们总是会将群体投射到自己所熟悉 自在的心理结构，这种倾向在工作团体中特别明显。人们 会很自然地将工作中所遇到的他或她，比拟成过去相处过 的人物，特别容易将管理者当成父母，更有甚者，团队中 最优秀的人可能会将组织中的高层人物比拟成某位权威人 士。这种奇怪的不理性现象必然造成管理者有一种“霸权” 的形象产生。就像在家里一样，一个健康的组织一定会经历三个阶 段：孩童期、青春期和成熟期。

在团队成立之初的孩童期， 组员通常会不知不觉地将管理者当成无所不能的权威人 物：决定事情的人、保障资源的人、主宰奖赏和惩罚的人。 而组员则早已预设了自己的角色：服膺阶级。由于他们对法则9建要权威，不要霸权99权威的信赖，在组员心里会投射出一大堆“应该如此”的 模式到管理者的形像上，他们会说：“事情应该是这样。” 并把团队与管理者之间的关系看得单纯而天真。这种管理 者“应该如此”的模式包括了领袖特质、权威和成就等等， 其实没什么实质上的意义，睿智的管理者应该避免浪费时 间去探究在每个人心目中的权威形象。

让每个人都有权威，而不是让管理者独霸权力

人们倾向将管理者当成像父母般的权威。

如果管理者接受了这种幼稚的权威形象，和不健康的“领导者－团队成员”关系，整个团队就永远停留在孩童 期。千万记住我们的目标是让团队中的每一个份子都有权 威，而不是把权威集中给管理者。管理者也许要花一点时 间才能让大家接受这个观念，也许在过程中会有人抱怨， 但团队一定要有对权威的正确观念才能成长。对于一个不 成熟的团队，为它描绘目标比凝聚它的共识容易，你可以 召集所有的人在一起，告诉他们你为他们拟定的目标是什 么，这是短期的做法，长期来看，一定会有技术或产品的 专家脱颖而出，主导大家对产品的目标，而管理者必须相 信并支持这个目标，并且将它传递给整个团队。

充分授权我很想找另一个字来表达“充分授权”(e m p o w e r- m e n t)的涵义，因为这个字现在已经被用滥了。不论它法则9建要权威，不要霸权

101用什么样的名词表达，这个观念永远是创造智能财产 团 队 的 中 心 价 值 。 人 们 经 常 分 不 清 楚 准 许（p e r m i s s i v e n e s s）和授权（e m p o w e r m e n t）的差异，前 者是“让组员去做任何他认为最好的事”，后者是“让组员能够思考，然后尽全力去做”，完全是不同的 两回事。充分授权是让组员能够全力发挥，无所阻碍， 是为他们清除各种不同的障碍，让他们以自己的力量 达到某种成就。自由是充分授权的基石，让他自由判 断和实行判断，自由地思考和表达他认为应该思考和 表达的事情，自由地冒险尝试，而不必怕受到额外的 惩罚。充分授权是充分学习的结果，而不是忽视他， 让他胡搞瞎搞。当管理者对属下说：“这是你的决定” 时，他必须已经提供完善的支持─训练、信息、资 源─让属下能够做出正确的决定，这样才算是充分 授权。否则的话，让属下做决定等于是弃他于不顾。如果每个人都能获得充分的授权，那么在冲突 发生时该怎么做决定？这是一个理论上的问题，实际 上不会发生。在充分授权的环境中，不是无政府的混 乱而是事实和才能领导一切，每个人都有安全感，因

此而会放弃因为骄傲所造成的愚蠢、去除自我的狭隘 心态，于是软件的设计开发以及决策问题就变成是单 纯的资源分配运用。一个充分授权的团队有能力分析 各种方法的优点和缺点，并且能够选择对目标最有利 的方法，决策没有对或错，而是在产品功能、资源与 时间三者之间的权衡（trade