别让自己成为笨蛋懂得思考的人当听到诸如批评或别人比较优秀等不顺耳的话时，会把自高自大的心理干扰过滤掉，并从沟通中 接收正确的信息。他们能够避免下面两种心理现象：
第一种心理现象是防卫心理，让接受信息的人无法忍 受别人的批评。在创造智能财产的工作中需要很多的情绪 和创意投入（像是自己心血结晶的宝贝孩子，有一份特殊 的情感），别人对产品或制程的意见往往会听起来像是讽 刺。懂得思考的人在三思之后，会将自我的主观意识排除，然后接受信息的真实内涵，不过这种人并不多见。
将自己的意见强行加诸于他人者，其实是笨蛋。
不懂思考的人不但不会请求别人赐教，反而在别人好 意提供信息时过度防卫，而导致正面的冲突，所以无法对 信息作出正确的判断，对事情毫无建设性。如果这种现象 不断地发生，信息接受者会有两种可能的反应：一是这项 信息确实很重要，二是这个笨蛋在将自己的意见强行加诸 他人。结果呢？当然是后者。
第二种心理现象是相互排斥，发生的可能性更高。如果向别人提出建议，但对方却因为恐惧或其他负面情绪而 排拒，久而久之，这位好意的建议人就会认定对方是无法 沟通的笨蛋。
团队中有人无法沟通是极危险的事情，这会导致团体 中人际关系的恶性循环，对团体能力造成莫大的伤害，而 且几乎无法弥补。而且一旦管理者认为某人是无法沟通的 笨蛋，团队中的其他人都会跟着这么认为。
对这个问题的药方是加强每个人正面的沟通能力，能 够虚心接受别人的意见。如果你正试着传出信息，而对方 似乎无法接受，那么换一种比较轻松的方式做做看，至少， 试着向对方解释他的封闭令你难过。相反地，如果有个家 伙不断灌输你“差劲的”想法或是“恶意”的“攻击”， 放下自尊心彻底反省，是不是原始本能的防卫心理蒙蔽了 你的判断力。如果你能在团体中实践这个准则，当你不小 心犯错时就会有人及时纠正你，团队才能在和谐中进步。
死亡进行曲在大多数的软件开发项目中，一开始多半都在做前一 个项目的收尾工作。如果你的项目是以这种方式展开序幕（很不幸几乎所有的软件项目都是这样的开场），这个过程被比喻为“死亡进行曲”（death march）。
为了赶时间，产生了太多没人能懂的程序代码。
当前一个项目拖得太久（也许是为了更前面的一个项 目而晚了几个月才真正开始进行），也许因为项目经理忽 略了该注意的地方，或是因为客户的强烈抱怨你食言而肥， 或是前一个项目的到期压力太大而影响了软件的品质，或 是虽然前一个项目还算顺利但人员筋疲力尽想暂时歇会 儿，这一切的理由都埋下了延迟和品质不良的种子。为了 如期完成软件，工程师明知其中有不少有错虫，明知程序 写得多松散，甚至没把握程序能够正常执行，为了赶时间 只好牺牲自尊心，放弃对“我的作品”理想的执着，他们 无法以自己的作品为傲，以通过软件争霸战的残酷考验而 自豪。在符合进度且产出稳定的开发团队中，最后每个人 都会是团队的英雄，牺牲自己无私奉献终能完成任务，事 实也确是如此，软件开发是多少人绞尽脑汁的成果啊！
然而现在他们认为自己应该得到一些适当的休息，有适当的奖励或充电的机会，做些自己有兴趣的事情，或是 玩玩他们心爱的计算机。
重点是，他们无论是用爬的、用滚的，还是被鞭子赶 的方式，毕竟如期完成了软件，也许不是那么漂亮完美， 总是达成了目标。任何有开发时间限制的软件，到最后工 程师大概都是除日程之外什么都顾不了，这是非常巨大的 压力。然后紧接着又一个项目开始，不知道又要投入多少 脑力，这造成各种有形无形的员工的反弹，其中最可怕的 是那种江郎才尽（ burn-out）的感觉，这将是团队最迫切也最严重的危机。
江郎才尽软件工程师那种“江郎才尽”的感觉，就好像巴拿马运河的建筑工人染上疟疾一般，一发不可收拾。 “江郎才尽”是你再也无法承受压力的感觉，那是一 种极度的疲惫和沮丧，只有软件从业人员会染上，其 症状包括：
确信这个软件正在榨干所有的人的精力。
觉得这个项目管理简直乱得无可救药。
一想到要出下一个版本，就觉得头晕想吐。
对于任何企图解决问题的作法抱着愤世嫉俗的 态度。
完全无法沟通。
对计算机失去兴趣。 工程师染上这种“病”时，不论《PC周刊》
或《信息世界》(Infoworld)(或是 Dr. Dobb's 和Midnight Engineering)等杂志看都不想看，觉得科 幻小说荒诞可笑，虚拟实境(Virtual Reality)不过是人 工智能的游戏，新版的 MFC手册懒得去翻，甚至对 最新款的计算机毫无兴趣。基本上，就是软件工程师 那种做出最好的软件的狂热，已经消耗殆尽或是转移 到别处，只剩下颓废。
其实管理者也可能发生这种“病”，这是必须特 别防范的，因为发生在管理者身上的症候特别容易传 染到整个团队。
对一位软件开发人员而言，计算机的狂热是他最 重要的动力泉源，对某些人而言这是一种终极的自我 实现。就像是笔之于诗人，颜料之于画家，程序编译 器是软件开发人员心灵之所系，用以发挥才情的工具。
当热情燃尽时，将自己的智能倾注于软件开发的那种无怨无悔，也就随之化为一堆肮脏的灰烬。 我和每一位软件从业人员一样，非常害怕染上这种综合症。如果不加以防范，这就像是艺术家的陨 落一般，会使软件从业人员的职业生命骤然消失。
江郎才尽的感觉下载法则刺探敌情在开始下一个项目之前，先刺探敌情吧！
“侦察员 ”（ s c o u t ）是军队中先派出去侦察敌情的 “探子”。他们负责先了解四周的环境和敌我界线、我方资 源、寻找安全的驻扎地点、确认最好的前进路线，并且随 时注意任何敌方行动的迹象。长久以来，当一群人在一个 危险的旅程中，通常都会先派出侦察员去了解一下前方的 路况。倘若软件项目不是大批精英的危险道路，就没什么 好谈的了，所以当然得派个先知先觉者去为项目事先“侦 探”一番。
倘若没有人事先研究出最适合的路线，各版本的开发过程就像在沙漠 中胡乱游荡。
“侦察员”必须敏锐地嗅出任何软件产业的蛛丝马迹： 软件开发团队与大环境之间的依存关系、正在开发中的操 作系统新版本、与本项目有关的技术发展现况（也许还得 另外找人来研究这项新技术）等等。“侦察员”能建立或 修订多版本的技术规划（请参阅法则 3），他们访问顾客、微软团队?成 功 秘 诀法则5 刺探敌情学习有竞争力的新技术（至少要有基本的了解），并且研究决定项目该以何种方式或路线进行。 “侦察员”必须能够提出硬件最低需求的建议书，分析所有的使用者需求及各项软件开发规范，准备原型产品， 草拟未来的产品计划，以及建议下一版产品的重要特色。
“侦察员”的任务和贡献可以说是无限的。倘若没有 人决定好最适合的路线，你的开发过程就会像在沙漠中迷 失了方向，版本与版本之间毫无组织和明确的方向，注定 了悲惨的命运。虽然有好的侦察员不能保证情报够充分，至少“侦察员”会让你不致盲目乱走。
侦察员的重要性最近我与一家大公司的 MIS部门有接触的机会。
他们在过去三年内成功地将原本在大型主机上的终端 机全部（有上千部之多）换成 PC及Windows的作业 系统与网络环境。可想而知这是非常艰巨的任务，需 要大量的人力与金钱，和一段很长时间，整个公司在 这个转换的过程中，受尽各种煎熬。
完成了Windows 和 PC的转换之后，MIS部门开 始发展一套分布式的应用软件，以期充分发挥新科技的效用，这是他们第一个重大的投资回收项目，预计降低的成本和增加的利润可达每年数百万美元。 这个工作团队大约由100个人所组成，主要是软件工程师与品保工程师，大部分都是公司的新人，或 对技术还不是很熟悉，再加上对公司而言也是第一次 开发这种关键性任务（ mission-critical）软件，可想 而知他们一定得克服无数的困难。在我与他们接触之 初，这个项目的进度已经严重落后，并且大大超出预 算，更糟的是眼看期限就要到了。
这项 PC 软件的项目自开始至今已经有三年了， 当初他们开发软件时规划的硬件、网络协议等环境早 就已经过时，目前所使用的软件开发工具和操作系统 竟然落后了两个版本！这三年来，硬件价格大幅滑落， PC效能大幅提升，所要求的硬件运算能力也提高了 几倍，他们使用的 PC已经在市场上绝迹，但运行在 上面的应用软件却无法淘汰。
我实在无法帮助他们解决这个难题，只能说这个 实例证明了“侦察员”的重要性。当年他们几乎是凭 着直觉和谨慎保守的作风来决定软硬件环境和工具策 略：“我们尽量不要改变任何东西，反正它能用就好。”
倘若他们曾经好好调查一下计算机的发展趋势，倘若他们曾经考虑过兼容性的问题，他们就会知道必须使 用最新的工具和最新版的操作系统，并且尽可能将未 来的发展也估算在内，多花一点钱也是值得的，也不 会因为当年决策错误而造成今日难以挽回的局面。
不过还好，这支勇敢的 MIS 团队毕竟最后还是 圆满达成了任务，成功地完成了新的软件。这次他们 学乖了，事先派了两位最优秀的组员担任“侦察员”， 做了一次彻底的技术调查和完善的规划，终于在危机 爆发之前将之化解。
老实说，对于类似上例的公司，我只能感到同情。计 算机科技进步太快太剧烈，冲击着组织不够健全的公司， 旧的系统难以割舍，新的技术又逼着你不得不进步。是的， 使用第0版的软件也许会让你惶恐，但从第 7 版升级到第版可能意味着重大的进步。如果你做决策之前，好好做 过“侦察员”和完善的规划，而且知道这些对系统的重要 性，你就会乐于接受科技带来的改变。
本书强调的基本观念是，我们并不企图减缓科技进步 的速度，也不是要建立僵化的系统，而是要在改变中获得 益处，将不断变化的科技管理得宜。行动总比停滞好，行动力高的组织会有较高的适应环境能力。“侦察员”就是为科技的改变而准备的，如果你决定永远停着不动，那你 不需要“侦察员”。
当然“侦察员”也可能带来问题。如果他对多版本计 划没有非常清楚的认识，他可能不知道要侦察什么；他们 也可能不懂这项任务的重要性而随便做做。“侦察员”必 须要非常了解自己肩上所担负的责任：一旦选错了一个操 作系统或开发工具，可能会害死整个组织。
另一方面，“侦察员”本身也可能因为这项任务的重 要性而过度膨胀自我，看不起其他的人，自以为是“定 义未来的人”。团队中的其余成员会因此而觉得沮丧，对 未来的方向完全没办法掌握，觉得自己不受重视；甚至 以为事情已经多得做不完，管理者竟然把人调出去研究 无关的技术：“我每周工作 70 小时，而那个家伙悠闲地 在看书!”这种抱怨在派最顶尖的人去当“侦察员”时尤 其会发生。
团队成员对“侦察员”的工作不免嫉妒。当“侦察员” 比当开发者好─比较光鲜亮眼、比较先进、比较酷。当 几个月的“侦察员”似乎真是不错，你可以观摩别人的公 司、跟厂商谈谈、玩玩软件原型、趁机多充实自己的技术能力、有权力影响未来的方向。但是“侦察员”不参与软件开发，只负责做初步的规划、培养团队对于目标的共识。 如果“侦察员”能够让团队信任，并凝聚出真正的共识， 开发人员就比较能够自在工作，相信这些担任“侦察员” 的优秀同事是在为大家的未来披荆斩棘地开路。
对开发团队来说，“侦察员”能够运用得愈成功，代 表他们愈相信项目经理的领导，团队的共识愈强；不论 是否处于技术转换的过程，对团体和个人都是一种很好 的现象。
下载法则注意人员的组成比例项目经理经常犯的错误之一，是以为只要雇用软件工程师就好，其他的人都不必要，或是让软件工程师占整个 团队很高的比例。也许是认为开发人员愈多，写出来的程 序就愈多，这是错误的观念，项目的目的是完成软件，不 是完成很多程序代码。在开发团队中，事实上有一些工作 是不适宜交给软件工程师的。
在我的小组中，比例通常是 6位开发人员， 2～3位品 保人员，一位项目经理，以及两位技术文件撰写人。在微 软的各个部门中，这个比例会稍有不同，也许和您的人员 比例也不同；但基本原则是开发人员和品保人员的比例不 超过2:1。其实真正负责软件如期完成的是品保人员。当 进度落后时，我们第一个要看的是品保人员：人数够不 够？有没有充分授权？有没有确实参与设计？进度上能不 能跟开发人员配合良好？能不能一有问题出现就立刻提出 警告？品保人员和开发人员的理念一致吗？是不是跟开发 人员过度亲密而放水？
对于人员的组成比例应该着重于有效的人数比，而不 是实际人数比。一个健全的软件开发团队一定要符合上述 的人数比例原则，平均每一位品保人员所支援的开发人员 不超过两位：前者是思考并监督软件的状况是否达到预期水准，后者专心写程序和抓错虫。注意人员的组成比例，可以帮助（但不保证）团队的运作取得平衡，记住，平衡 才是你真正的目的。
下载法则运用特色监督小组在微软的C++开发小组中，我们就用过特色监督小组（feature team）的横向组织。我觉得这是非常好的做法， 对整个团队的工作品质产生了绝佳的影响。
如果你问一个品保人员他的工作是什么，他会回答： “监督软件开发的进度，确保如期完成，并且确保品质达 到预定的目标。”他绝不会说：“测试程序。”那是肤浅的 答案。品保人员的工作是如期完成软件，是开发“产品”， 是去了解顾客，而且还知道技术规划中每一件大大小小的 事情进行得如何；可以说，品保人员必须要管我们的产品、 我们的市场和我们的整个事业。
我们的团队组织像一个二维矩阵，传统的组织模式为 经，特色监督小组为纬。以经理、品保、开发、文件四种 角色，虽然是一个传统的阶层式组织，但还算相当扁平化 的；除此之外，这四种角色必须各派代表参加特色监督小 组，每一项产品特色都有专属的特色监督小组，以确保每 项特色都能照日程做出来，这个小组必要时可自行开会。
特色(feature)一词，也有人为了听起来较大众化而译为功能，这是因为中文里的功能一词，意义非常广的 缘故。事实上特色是指完成某项功能的独特方法，特 别是与竞争者不同的地方，它适用的范围很广，您可以说，采用Control-C.Control-X.Control-V来操作“剪贴簿”是微软产品一贯的特色，您也可以说，某软件 具有随插即用的特色。—译者注）特色监督小组运作模式有几个重要因素：分别是充分 授权、赋予责任、融入任务、建立共识和地位平等。特色 监督小组是我所经历过最神效的组织方法，我将它的五项 重要因素讨论如下：
充分授权（Empowerment） 像特色监督小组这样的编制似乎比较非正式，无法像阶层式的组织那样容易管理， 但它需要被充分授权才能发挥作用。譬如像开发人员，他 们是“专才”，几乎专职负责某一特定的技术领域，若是 让他们完全主导一项产品的设计显然太不智，如果加进一 些别的角色，形成“通才”的局面，就平衡多了。单靠经 理人的决定，恐怕不够全面，我看过太多好的（或坏的） 决策，一下子就被另一位经理完全推翻，我倒是没见过特 色监督小组把事情搞砸过。也就是说，只要特色监督小组 能被充分授权，并且发挥它的作用，就可以确保决策的品 质。（当然特色监督小组的必须挑选适合的人参加，本书 附录中将说明这一点。）赋予责任（Accountability） 我认为软件开发问题中最有趣的就是赋予责任这个主题。我们讨论过的题目是：
“你负责什么？”我的理论是，大多数人的思考都没有好 好利用到，因为人们并不把提出新想法当成自己的责任之 一（请参考法则4：别做笨蛋）。
首先，人们可能认为：“这不是我的责任范围”，因此 少管闲事，不提任何有建设性的提议。如此一来会有很多 不良的后果，尤其是当事情没有用语言沟通，会引起许多 误解、猜忌、行动力的相互抵销，而最后只有用行动来抗议了。
只要单纯地请对方表示看法，这样的姿态很容易解除对方的心理防线。
其次，如果建议的来源真的说出了他的想法（可能要 冒很大的风险），被建议的对象很可能产生防卫心理（又 不是你的事情，管什么管嘛！），导致争端。有时候，防 卫心理是非常隐讳的，特别是当这个组织的文化将防卫心 理视为缺点时。讽刺的是，愈是成熟的团队或个人，愈会 执着于现有的优良管理制度，愈会提出各种反驳的理由来证明现有的做法才是最好的，不需要什么建议。
第三，除非建议者克服自己的攻击心理，否则这个 建议可能永远到不了对方的心中。就像防卫心理是普遍 存在一样，攻击心理亦然。通常提出建议的人都有某种 攻击性或包含价值判断的态度，这也是绝大多数的人都 有的弱点，而受到批评的人会感觉到威胁而更强烈反弹， 于是提出建议的人立刻下结论：这人是个笨蛋，沟通的 大门立刻关上。
有很多建设性的想法就此消失。我所想到惟一的解决 办法，就是所谓的研讨会（ workshop）。在研讨会中人们 主动上前邀请同事提出批评指教，这样单纯的提出、接受、 反馈的循环中，每个人都会受到批评、提出建议，这是比 较容易让人卸除心理武装的气氛，比较容易对事不对人， 如此单纯的信息传达让每一个人都轻松接受建议而愿意改 善。令我惊讶的是，由于研讨会的练习使得组员熟悉沟通 技巧，最后反而不需要经常开研讨会了。
我有过多次运用研讨会的方式解决软件开发问题的经 验。方法像是个案研究（ case study），由一位志愿的组员 主持；这个案例当然是现在发生的真实情况，通常是关于 组内的人际关系，主持人先描述案例的大致情况，有时故意不说明当事人的名字，比方说：
──我实在无法接受这种想法。
──没有人看我的电子邮件（指建议）。
──某人根本没有把心放在项目上。 然后其他的人开始讨论，询问主持人关于此案更详细的信息，并理清一些盲点，或是询问主持人尝试过那些方 式，之类的问题。最后事情会在讨论中澄清，问题也就差 不多解决了。
前述的两种简单方法会产生两项很重要的结果（从来 没有让我失望过），其一是这样的讨论会造成非常多的新 点子伴随而生：你会看见主持人不断地说：“这个想法太 棒了！”然后当场记在笔记本上；其二是这种案例研讨的 结论通常可以应用在其他类似的情况，人们会发现，这就 是我上个月讨论过的某案嘛！当类似的过去案例累积到相 当的数量，人们就会发现本案也不是什么特例，然后就会 发现处理这类事情的通则，把它记在笔记本上作为日后的 参考。
在横向的特色监督小组中，一个人的成功或失败是完全透明的。
“赋予责任”有很大的好处，很少有应用上的限制。 如果一个组织健全的团队成员，对于整个任务的过程─ 设计、开发、除错、品质、期限 ─彼此都负有责任，就 会自然地互相给予建议和建设性的批评，而且用正面的态 度接受。因为每个人都有相同的责任。一旦建立团队的责 任感，这种对责任的认知会分享、传递到团队中的每一个 份子。
融入任务（Identity） 充分的授权和责任感，使人具有控制权和影响力，愈能使自己与任务融为一体。控制权 愈大，融为一体的一致性愈高。这种融为一体的一致性是 开发任何好软件的先决条件，它会将个人的心理状态健全 与否，表现在软件作品中。譬如说，有一个人心中有挫败 感或是自我毁灭的倾向，就会在他所负责的软件功能中表 现出来。
在横向的特色监督小组中，每个人会将产品当作他的任务，而非狭隘的技术而已。没有什么人可以推诿塞责，一个人的成功或失败是完全赤裸而透明的。你不能责怪管 理不良，因为你自己就是管理者，你不能责怪其他的功能 支持人员没有好好配合你的产品特色，因为你们是相互负 责。因此，你有责任自己找到答案，你有责任克服自己的 障碍。
建立共识（Consensus） 共识是特色监督小组的气氛。因为大家聚在一起的原因是“产品特色”而非功能， 由于责任是互相的，敞开心胸是安全也是必要的。我见过 有些特色监督小组自动地重新组织他们的关系，建立共同 目标、重新规划资源、适度修改日程，而没有发生严重冲 突。即使有冲突，由于不是对人的或是出于私心，通常都 很容易解决，不需要主管以职权介入。
地位平等（Balance） 由于特色监督小组的每一位成员都是不同的背景、专长，不同的工作角色和不同的观念， 没有谁比谁优越的情形，所以每个人的地位都是平等的。 通常人们对于不属于自己专业的领域，反而会有一些全新 的看法，刺激彼此打破过去的观念限制或盲点，激发更好 的创意。由于各人的意见来自不同的着眼点，就可以使产 品的开发顾全更广的层面，而更周全、完美。不同角色的人会关心不同的问题：
项目经理：团队目前的状况如何？开发过程顺利吗？ 领导是否有效而得宜？我们走到开发周期的哪个阶段？进 度是否控制得当？需要别部门协助的地方是否已经取得支 持？我们的目标明确吗？还有什么尚未完成的工作？本周 的工作主题是什么？
品保人员：我能不能依照预定的时间自开发人员手中 取得阶段性程序代码？程序有什么样的错虫出现？这些错 虫对付得如何？有什么功能尚未开发出来？程序的执行效 能如何？本周的产品状况是否合格，需要对谁提出警告 吗？项目经理知不知道程序的稳定程度？我们团队的沟通 如何？是不是每一个人对产品状况都有相同的认知？本周 合理的短期目标应该是什么？
开发人员：本周我能不能完成预定的工作进度，将阶 段性程序代码交给品保人员和文件人员？这一段程序代码 写得够好吗？使用者需不需要这个功能？这个程序容易使 用吗？程序是否执行够快体积够轻巧？我清除了所有的错 虫吗？有没有人因为在等待我的工作进度而耽误进度？我 是否完全了解本周的短期目标？我的工作是否符合策略上 的方向？而且工作内涵对技术规划有无贡献，或只是个早晚会被丢掉的垃圾？
产品经理／行销：产品特色是否吸引顾客（包括潜在 顾客）？我该如何生动地表达这个产品的特色？它能否牵 动顾客心中的心理或情感反应？我们应该如何修改产品， 才能加强顾客的购买欲？当顾客听到我们的产品时心里会 有什么样的反应？顾客在什么时候会使用这个产品？产品 特色是否能加强我们与顾客之间的关系？媒体是如何报导 我们的产品？开发这项产品特色背后的动机是什么？我是 否完全了解产品特色及其重要性？准时完成的可能性有多 大？我是否应该向公司说明产品的不确定性有多高（或是 非常确定）？产品成功推出的机会点在哪里？
技术文件／教育训练：这项功能是否以更容易的方式 使用？我对它的说明够清楚吗？使用者接口能不能设计到 不必学就能操作？如果我现在还没有完成文件，会不会太 迟？这项产品特色是否已经通过品保人员的核准？我对这 项产品特色有什么感觉？我能不能用更简洁的方式来说 明？其他的组员认同我写出来的文件吗？
虽然特色监督小组是非常的重要，但要成功地组织起 来可不是件容易的事。在传统的阶层式组织中加入横向的 特色监督小组是非常困难的转变，这种转变上的困难可能来自团队的内部或外部。
在特色监督小组的内部，本身就会面对相当大的不确 定性，大家不知道自主权的范畴是什么，只知道我们是一 组人，应该在一起做事，但不确定的该用什么样管理方式。 特色监督小组的本意是突破传统角色的藩篱，但是组员却 会很自然地以原来的传统角色来为自己的定位，如此特色 监督小组的作用就会明显受限。开发人员常常会主导小组 的运作，导致使其他的功能不容易发挥。如此一来，特色 监督小组的横向组织功能大概只能改善沟通，这似乎与它 的高成本（组织小组、召集开会、物色人选、行政作业等 等）完全不成比例。
在很多人的心中,所谓的团队只不过是虚伪矫情的共识和假装一团和气罢了。
而且，人们总是要等到问题已经很严重时，才会成立 特色监督小组。如果这个时候管理阶层放手让他们自行决 定命运，组员反而会有被抛弃的沮丧感。向来不习惯自治 的组员突然要组织起高难度的特色监督小组，一定会觉得非常不安。特色监督小组的功能在这样的情况之下很难发挥，问题反而很可能雪上加霜。 特色监督小组本身也充满了矛盾和冲突，因为在很多人的心中，所谓的团队只不过是虚伪矫情的共识和假装一 团和气罢了。
特色监督小组惟一不可磨灭的贡献是创意，代价是无 数不眠的夜、对拒绝的害怕、对个人勇气的磨炼。于是， “冲突”便成了特色监督小组的标志，虽然它也是成长的 动力。
所以，项目的初期往往看不出来特色监督小组的重要 性，因为没有什么挑战性，特色监督小组看起来像是管理 阶层在搞的流行玩意。
最后特色监督小组还是会发挥很大的效用，只要它能 被适当的组织和赋予足够的权力。它有资源、有创意、有 管理者支持，能够发挥惊人的力量，在关键时刻，他们会 发现自己竟然能够搞定这么多、这么重要的事情。
当然在特色监督小组内也有它的问题。很多头脑优秀 而充满创意的人不敢提出他们的构想，有一种内在的负面 力量阻止他们将自己的天份表现出来。大多数人都会害怕 在团体中被排斥，这种心理源自于做个乖小孩的童年经验：
由于父母很少会限制小孩的发展，因此小孩对于“不要这样”的信息特别敏感，为了保护自己，尽量表现得与大家 一样，服从于大多数平庸者的价值体系，而不太敢表现自 己的才能。然而，与众不同才是软件开发的成功要素。
这种自我设限的负面行为，虽然在一般的生活环境中 是正常现象，但在正常的软件开发环境中却是病态。一般 人都会为了在阶级系统中求生存而学会“善伺上意、察颜 观色”，自然而然地会去迎合管理者的态度而改变自己的 行为。然而，管理者也会不知不觉地发出“停止！不要这 样”的信号（也许是出自盲目的策略或单纯的固执，就像 父母对孩子的行为教育一般），导致属下害怕功高震主、 得不偿失。管理者应该率先鼓励人们尽量发挥，对于优异 的组员表示肯定和支持，至少对于不同的意见采取开放的、 正面的态度。
另一方面，每个人对于这种意见自由也会有不同的反 应。每个人感受到自己被充分授权，一肩挑起一件大事的 成败责任，会自然地把这种情绪传达给团队中的其他成员。 这种个人自由（ personal liberation）在不同的时机会以不 同的样貌呈现，也会以不同的方式强化，每个人都不一样， 但这并不容易被观察出来。每个人都需要被挑战、被鼓励、被栽培；弹性和耐性使个人形成团体，而以自己的脚步共同成长。这种成长过程虽然艰辛，却是成为优秀智能工作 团队的先决条件。
在特色监督小组中容易发生奇怪的对话，像是谁能决定什么事，除了控制 之外到底该有什么样的管理角色是管 理者应该担当的。
我也同时注意到，每个人对横向组织（特色监督小组） 的参与程度，恰好与他原功能组织（例如系统文件等角色） 的成功程度成反比。如果整体组织的功能表现不彰时，其 中某个功能部门的表现还算不错，致使这个部门的表现显 得突出，那么在整个组织效能改善之后，原来的疏离感反 而使得这个部门的人较不容易融入横向组织中。
我们再来谈谈特色监督小组可能面临的外部问题。参 与者本身所隶属的功能部门管理者（如开发经理、品保经 理等等之类的各式经理）有他原来的部门目标，现在要抽 调人力参加特色监督小组，当然不免有些挣扎。也许其原属的功能部门不是那么有创意，但在这“疯狂的特色监督小组”成立之前，他们对组织也有一定的贡献，或多或少 都对特色监督小组抱持着对立的态度，毕竟，他们已在原 来的专门领域建立起一定的责任感和权威性，现在要他们 加入一个陌生的组织，做一些自己不擅长事情，而且在原 本未被授权的环境中，他们凭者能力取得一席之地，但现 在不需要了，却在新环境中被授权却更多，使得他们对原 有的成功价值产生怀疑，因而使他们更难适应新的环境。 管理者知道如何以传统的方式推出软件产品，当他看到特色监督小组刚成立时所作的尝试，会觉得太幼稚了， 会感到非常地担心：“他们这样做是错的，应该由我来做， 或是由我来教他们如何做。”这真的是善意的关心，管理 者无法忘记自己对产品的责任，会怀疑特色监督小组是不 是疯了（我自己就曾经这么想），竟然让这些没有经验的 笨蛋决定技术与产品的发展方向，并且管理者从前犯过的 错误他们现在一样照犯！
管理者学习在“鼓励属下”与“控制属下”之间取得 平衡，于是发生奇怪的对话，像是谁能决定什么事？除了 控制之外到底该有什么样的管理角色？如果不是管理者该 做的决定，那么他要如何负责？如何自处？如何定位？
当年我也曾经怀疑过，和其他多位资深经理怀疑我们为什么要大费周章地成立特色监督小组，我曾经在深夜醒 来，自问我们究竟为什么要这样自找麻烦，想出这种疯狂 的主意使每个人都全心投入。渐渐地，我们了解到管理者 的角色应该是教导、挑战、鼓励，并肯定这个创意思考的 过程。如果我们的观点是对的，事实自然能够证明它。在 授权给特色监督小组的同时，经理挑战组员假设的前提， 让他们能够自我检视自己的动机和行为，协助他们达成共 识和化解冲突，并让他们明白管理者了解他们，会支持他 们的决定。我们训练组员自己去追求效能，这是非常基本 的要求，因为我们要让组员自行负责，让组员有能力决定， 并且以自认最理想的方式去实现。
权威是来自学识，而非职位。
当然，这整个过程是循序渐进的，就某种意义来说， 它仍然不断地在发展。有很多时候，小组希望由经理直接 替他们做决定和设立目标；也有些时候是经理不当地命令 小组做事。传统性的功能组织和横向特色监督小组之间，没有全然的界线。但是在这一切都在转变中，我清楚地感觉到大家都朝着正确的方向在进步。 在一个理想的项目中，基本上有两种角色存在：创造者（creator）和推动者（ facilitator）。创造者是一些专业 人员，例如开发程序、行销、软件品保和文件撰写；而推 动者则负责凝聚团队共识和维持最佳的开发环境。在这里 可以无忧无虑地尽情发挥创意，有充足的资源解决问题和 实现理想，组织的运作非常有效率。推动者就是项目经理 或一般的管理者，他们的能力不直接显示在产品中，但却 是推动产品成功的保姆。
推动者必须像创造者一样对最后的成果负责，而创造 者也必须像推动者一样对团队共识负责。让两种角色互相 负责是很好的做法，可以互助互补。传统阶层式组织的重 要性逐渐降低，权力来自于知识，而非地位，这是一项革 命性的突破，值得所有的软件开发组织深思。
管理者的角色是舵手下载法则项目经理的职责项目经理是软件开发团队的一份子，他的职责是：
领导大家定义出一个成功的产品。
引导大家对产品注入深切的期望和信念。
带领团队将理想实现，变成可预见的产品诞生。 要定义“项目经理是什么”，倒不如从定义“项目经理不是什么”，还比较简单些。一位项目经理实际所扮演 的角色并不是一般人直觉上想到的工作性质而已。
项目经理并没有（或只有很少的）正式的权力或地位， 至少刚开始时是如此，所以项目经理通常会为此感到非常 地焦虑。笨蛋项目经理可能以为他的工作是写出软件规格， 让其它人去写程序、测试程序、撰写文件等等，最后完成 项目经理心目中理想的成品。在最好的情况下，别人会认 为他天真；在最坏的情况下，别人会认为他愚蠢、成事不 足败事有余。在项目经理可以对团队有任何的价值之前， 不应该有任何直接的控制权；幸好，一个健全的开发团队 不会让这种事情发生，组员会适时阻止项目经理不当地直 接控制。
当然这类事件会导致在项目经理心中有些气愤和挫 折，因而要求上级授予更多的权力，如果上级愚蠢到真的 这么做，就会导致更严重的愚蠢事件（请参考法则 9：要权威，不要霸权）。
通常是等到情况已经坏到无可救药时，项目经理才会明白“政治”只 是合法的借口。
对于这类项目经理的挫折感，我见过很多不同类型的 反应。最常见的一种是项目经理开始对他真正的角色─ 领导─做出负面的、反叛性的行为，这种行为通常是通 过对“政治垃圾”（political bullshit）的厌恶来表现。除了 对科技要有一定的知识之外，软件开发团队的领导人还得 具备对人性高度敏锐的观察力，必须能够看出在团队外在 行为背后那些隐藏着的情绪因素。可想而知，有些专案经 理为了避免那些剪不断理还乱的人性问题，开始寻求比较 “清爽”的自我形象，而在软件公司中免不了的科技挂帅 文化，很容易视“政治”为畏途。当然，驾驭技术要比掌 握人性要简单多了。然而，当人们抱怨政治的奸诈诡谲时， 其实是对不良领导的反感所致。不幸的是这种不满的情况 比比皆是，健全的组织却少得多。于是失败的项目经理把过错推到“政治”这个字眼。然而，大概要等到情况已经坏到无可救药时，专案经理才会明白“政治”只是合法的 借口，他应该用领导代替控制，才懂得为自己的偏执负责。 有谁愿意身处于乌烟瘴气的组织环境？但是当项目经理或 任何人伤害组织的健全性时，那就是走向失败。
虽然刚开始时项目经理对自己的角色非常不确定，不 能肯定自己对项目的贡献度，还对政治嗤之以鼻，不过当 他了解到应该以领导代替控制时，就会觉得一切都得心应 手。项目经理应该是以栽培和教育的全方位领导，来引领 软件的发展。
项目经理应该要有技术的背景，而且必须在两种层 面非常专精：一是对开发产品所使用的技术很熟悉，二 是拥有建构软件的技术领导能力，而后者是本书主要的 讨论范围。项目经理必须精于哄骗、驱策、鼓励、要求 他的团队做出最好的软件和表现出最好的工作效能，他 清楚知道软件制作过程中每一项的投入和产出细节，他 必须懂得用最好的方式定义产品和维持健全的技术。最 后，项目经理还必须是团队的发言人，面对媒体、客户、 以及整个组织。
项目经理是维系团队灵魂的关键人物，他应该是擅长沟通和倾听的人，具有设身处地为他人着想的本领。总之，项目经理是软件开发的核心人物。
团队的精神在此我强调一个观念，在后面也会再重复提及：软件 代表着创造它的团队。你想了解这个团队？看看他们的软 件就知道了，反之亦然。我特别强调这个观念是因为这是 软件开发管理的基础。在某一个时间点或是从某一段描述 中，或是从这个团队的行为，常常无法准确判断这是个什 么样的团队，但软件不会说谎。软件会忠实地展现创造它 的团队：一切优点和缺点，天赋和天谴，从潜伏期的小病 到最极致的团队合作。若对这个团队有任何疑问？他们的 软件作品就是答案。如果你的询问对象是人，你还得注意 他的表情和肢体等等隐性语言，但是如果你仔细研究他们 的软件作品，你不必问任何人就知道他们团队有没有问题。 软件会自我表达，它绝不说谎，也不隐瞒。
这项理论是软件开发管理的基础，可以用一个恒等式表示：
团队＝软件基本的原则是：如果你对团队有任何疑惑，去看他们的软件；如果二者一致，你可以相信自己看到的团队现状。 相反地，如果软件未能表现出应有的水准，表示团队有问 题，不论团队看起来多么健康，你都应该去分析、去发掘， 找出问题解决掉。
团队的精神团队等于软件，不错，但团队是什么呢？你是以什么方式或风格领导这个团队？我相信软件开发的关键是与 “团队精神”（group psyche）保持密切的连系（ Psyche是 小爱神丘比特所爱的美少女的名字，原意是灵魂或精神， 这里的灵魂不是宗教上的含义，那是 soul，精神也不是强 调团队的合作协调，那是 teamwork，group psyche是指一 群人所共有的中心思想和心理状态）。这样说很抽象，下 面是”团队精神“的具体描述：
一群人同心协力，集合大家的脑力，共同创造一项 智能财产。
个人的创造力是一种神奇的东西，源自于潜在的人 类心智潜能，它被情感丰富，而被技术束缚。
一群人全心全意地贡献自己的创造力，结合成巨大 的力量。结合的创造力由于这一群人的互动关系、彼此激 荡，而更加复杂。
这种复杂的情况之下，领导变成像是人际互动的交 响乐指挥，辅助并疏导各种微妙的人际沟通。
