第3节

或是前一个项目的到期压力太大而影响了软件的品质，或 是虽然前一个项目还算顺利但人员筋疲力尽想暂时歇会 儿，这一切的理由都埋下了延迟和品质不良的种子。为了 如期完成软件，工程师明知其中有不少有错虫，明知程序 写得多松散，甚至没把握程序能够正常执行，为了赶时间 只好牺牲自尊心，放弃对“我的作品”理想的执着，他们 无法以自己的作品为傲，以通过软件争霸战的残酷考验而 自豪。在符合进度且产出稳定的开发团队中，最后每个人 都会是团队的英雄，牺牲自己无私奉献终能完成任务，事 实也确是如此，软件开发是多少人绞尽脑汁的成果啊！

58然而现在他们认为自己应该得到一些适当的休息，有 适当的奖励或充电的机会，做些自己有兴趣的事情，或是 玩玩他们心爱的计算机。重点是，他们无论是用爬的、用滚的，还是被鞭子赶 的方式，毕竟如期完成了软件，也许不是那么漂亮完美， 总是达成了目标。任何有开发时间限制的软件，到最后工 程师大概都是除日程之外什么都顾不了，这是非常巨大的 压力。然后紧接着又一个项目开始，不知道又要投入多少 脑力，这造成各种有形无形的员工的反弹，其中最可怕的 是那种江郎才尽（b u r n - o u t）的感觉，这将是团队最迫切 也最严重的危机。

江郎才尽软件工程师那种“江郎才尽”的感觉，就好像 巴拿马运河的建筑工人染上疟疾一般，一发不可收拾。“江郎才尽”是你再也无法承受压力的感觉，那是一 种极度的疲惫和沮丧，只有软件从业人员会染上，其 症状包括：确信这个软件正在榨干所有的人的精力。

觉得这个项目管理简直乱得无可救药。

法则4建别做笨蛋59 一想到要出下一个版本，就觉得头晕想吐。 对于任何企图解决问题的作法抱着愤世嫉俗的 态度。

完全无法沟通。 对计算机失去兴趣。 工程师染上这种“病”时，不论《P C周刊》(P CWe e k )或《信息世界》( I n f o w o r l d )(或是 D r. Dobb’s 和Midnight Engineering)等杂志看都不想看，觉得科 幻小说荒诞可笑，虚拟实境(Virtual Reality)不过是人 工智能的游戏，新版的 M F C手册懒得去翻，甚至对 最新款的计算机毫无兴趣。基本上，就是软件工程师 那种做出最好的软件的狂热，已经消耗殆尽或是转移 到别处，只剩下颓废。其实管理者也可能发生这种“病”，这是必须特 别防范的，因为发生在管理者身上的症候特别容易传 染到整个团队。对一位软件开发人员而言，计算机的狂热是他最 重要的动力泉源，对某些人而言这是一种终极的自我 实现。就像是笔之于诗人，颜料之于画家，程序编译 器是软件开发人员心灵之所系，用以发挥才情的工具。

60当热情燃尽时，将自己的智能倾注于软件开发的那种 无怨无悔，也就随之化为一堆肮脏的灰烬。我和每一位软件从业人员一样，非常害怕染上 这种综合症。如果不加以防范，这就像是艺术家的陨 落一般，会使软件从业人员的职业生命骤然消失。

江郎才尽的感觉下载

法则 5

Use scouts刺探敌情62在开始下一个项目之前，先刺探敌情吧！

“侦察员”（s c o u t）是军队中先派出去侦察敌情的“探子”。他们负责先了解四周的环境和敌我界线、我方资 源、寻找安全的驻扎地点、确认最好的前进路线，并且随 时注意任何敌方行动的迹象。长久以来，当一群人在一个 危险的旅程中，通常都会先派出侦察员去了解一下前方的 路况。倘若软件项目不是大批精英的危险道路，就没什么 好谈的了，所以当然得派个先知先觉者去为项目事先“侦 探”一番。

倘若没有人事先研究出最适合的路 线，各版本的开发过程就像在沙漠中胡乱游荡。

“侦察员”必须敏锐地嗅出任何软件产业的蛛丝马迹： 软件开发团队与大环境之间的依存关系、正在开发中的操 作系统新版本、与本项目有关的技术发展现况（也许还得 另外找人来研究这项新技术）等等。“侦察员”能建立或 修订多版本的技术规划（请参阅法则 3），他们访问顾客、法则5建刺探敌情63学习有竞争力的新技术（至少要有基本的了解），并且研 究决定项目该以何种方式或路线进行。“侦察员”必须能够提出硬件最低需求的建议书，分 析所有的使用者需求及各项软件开发规范，准备原型产品， 草拟未来的产品计划，以及建议下一版产品的重要特色。“侦察员”的任务和贡献可以说是无限的。倘若没有 人决定好最适合的路线，你的开发过程就会像在沙漠中迷 失了方向，版本与版本之间毫无组织和明确的方向，注定 了悲惨的命运。虽然有好的侦察员不能保证情报够充分， 至少“侦察员”会让你不致盲目乱走。

侦察员的重要性最近我与一家大公司的 M I S部门有接触的机会。 他们在过去三年内成功地将原本在大型主机上的终端 机全部（有上千部之多）换成 P C及Wi n d o w s的作业 系统与网络环境。可想而知这是非常艰巨的任务，需 要大量的人力与金钱，和一段很长时间，整个公司在 这个转换的过程中，受尽各种煎熬。完成了Windows 和 P C的转换之后，M I S部门开 始发展一套分布式的应用软件，以期充分发挥新科技64的效用，这是他们第一个重大的投资回收项目，预计 降低的成本和增加的利润可达每年数百万美元。这个工作团队大约由1 0 0个人所组成，主要是软 件工程师与品保工程师，大部分都是公司的新人，或 对技术还不是很熟悉，再加上对公司而言也是第一次 开发这种关键性任务（ m i s s i o n - c r i t i c a l）软件，可想 而知他们一定得克服无数的困难。在我与他们接触之 初，这个项目的进度已经严重落后，并且大大超出预 算，更糟的是眼看期限就要到了。

这项 PC 软件的项目自开始至今已经有三年了， 当初他们开发软件时规划的硬件、网络协议等环境早 就已经过时，目前所使用的软件开发工具和操作系统 竟然落后了两个版本！这三年来，硬件价格大幅滑落， P C效能大幅提升，所要求的硬件运算能力也提高了 几倍，他们使用的 P C已经在市场上绝迹，但运行在 上面的应用软件却无法淘汰。我实在无法帮助他们解决这个难题，只能说这个 实例证明了“侦察员”的重要性。当年他们几乎是凭 着直觉和谨慎保守的作风来决定软硬件环境和工具策 略：“我们尽量不要改变任何东西，反正它能用就好。”

法则5建刺探敌情65倘若他们曾经好好调查一下计算机的发展趋势，倘若 他们曾经考虑过兼容性的问题，他们就会知道必须使 用最新的工具和最新版的操作系统，并且尽可能将未 来的发展也估算在内，多花一点钱也是值得的，也不 会因为当年决策错误而造成今日难以挽回的局面。不过还好，这支勇敢的 MIS团队毕竟最后还是 圆满达成了任务，成功地完成了新的软件。这次他们 学乖了，事先派了两位最优秀的组员担任“侦察员”， 做了一次彻底的技术调查和完善的规划，终于在危机 爆发之前将之化解。老实说，对于类似上例的公司，我只能感到同情。计 算机科技进步太快太剧烈，冲击着组织不够健全的公司， 旧的系统难以割舍，新的技术又逼着你不得不进步。是的， 使用第0版的软件也许会让你惶恐，但从第 7 版升级到第8 版可能意味着重大的进步。如果你做决策之前，好好做 过“侦察员”和完善的规划，而且知道这些对系统的重要 性，你就会乐于接受科技带来的改变。本书强调的基本观念是，我们并不企图减缓科技进步 的速度，也不是要建立僵化的系统，而是要在改变中获得 益处，将不断变化的科技管理得宜。

行动总比停滞好，行66动力高的组织会有较高的适应环境能力。“侦察员”就是 为科技的改变而准备的，如果你决定永远停着不动，那你 不需要“侦察员”。当然“侦察员”也可能带来问题。如果他对多版本计 划没有非常清楚的认识，他可能不知道要侦察什么；他们 也可能不懂这项任务的重要性而随便做做。“侦察员”必 须要非常了解自己肩上所担负的责任：一旦选错了一个操 作系统或开发工具，可能会害死整个组织。另一方面，“侦察员”本身也可能因为这项任务的重 要性而过度膨胀自我，看不起其他的人，自以为是“定 义未来的人”。团队中的其余成员会因此而觉得沮丧，对 未来的方向完全没办法掌握，觉得自己不受重视；甚至 以为事情已经多得做不完，管理者竟然把人调出去研究 无关的技术：“我每周工作 70 小时，而那个家伙悠闲地 在看书!”这种抱怨在派最顶尖的人去当“侦察员”时尤 其会发生。团队成员对“侦察员”的工作不免嫉妒。当“侦察员” 比当开发者好─比较光鲜亮眼、比较先进、比较酷。当 几个月的“侦察员”

似乎真是不错，你可以观摩别人的公 司、跟厂商谈谈、玩玩软件原型、趁机多充实自己的技术法则5建刺探敌情67能力、有权力影响未来的方向。但是“侦察员”不参与软 件开发，只负责做初步的规划、培养团队对于目标的共识。 如果“侦察员”能够让团队信任，并凝聚出真正的共识， 开发人员就比较能够自在工作，相信这些担任“侦察员” 的优秀同事是在为大家的未来披荆斩棘地开路。对开发团队来说，“侦察员”能够运用得愈成功，代 表他们愈相信项目经理的领导，团队的共识愈强；不论 是否处于技术转换的过程，对团体和个人都是一种很好 的现象。

法则 6

Watch the ratio注意人员的组成比例法则6建注意人员的组成比例69项目经理经常犯的错误之一，是以为只要雇用软件工 程师就好，其他的人都不必要，或是让软件工程师占整个 团队很高的比例。也许是认为开发人员愈多，写出来的程 序就愈多，这是错误的观念，项目的目的是完成软件，不 是完成很多程序代码。在开发团队中，事实上有一些工作 是不适宜交给软件工程师的。在我的小组中，比例通常是 6位开发人员，2～3位品 保人员，一位项目经理，以及两位技术文件撰写人。在微 软的各个部门中，这个比例会稍有不同，也许和您的人员 比例也不同；但基本原则是开发人员和品保人员的比例不 超过2:1。其实真正负责软件如期完成的是品保人员。当 进度落后时，我们第一个要看的是品保人员：人数够不 够？有没有充分授权？有没有确实参与设计？进度上能不 能跟开发人员配合良好？能不能一有问题出现就立刻提出 警告？品保人员和开发人员的理念一致吗？是不是跟开发 人员过度亲密而放水？对于人员的组成比例应该着重于有效的人数比，而不 是实际人数比。一个健全的软件开发团队一定要符合上述 的人数比例原则，平均每一位品保人员所支援的开发人员 不超过两位：前者是思考并监督软件的状况是否达到预期70水准，后者专心写程序和抓错虫。注意人员的组成比例， 可以帮助（但不保证）团队的运作取得平衡，记住，平衡 才是你真正的目的。

法则 7

Use feature teams运用特色监督小组72在微软的C + +开发小组中，我们就用过特色监督小组（feature team）的横向组织。我觉得这是非常好的做法， 对整个团队的工作品质产生了绝佳的影响。

如果你问一个品保人员他的工作是什么，他会回答：“监督软件开发的进度，确保如期完成，并且确保品质达 到预定的目标。”他绝不会说：“测试程序。”那是肤浅的 答案。品保人员的工作是如期完成软件，是开发“产品”， 是去了解顾客，而且还知道技术规划中每一件大大小小的 事情进行得如何；可以说，品保人员必须要管我们的产品、 我们的市场和我们的整个事业。我们的团队组织像一个二维矩阵，传统的组织模式为 经，特色监督小组为纬。以经理、品保、开发、文件四种 角色，虽然是一个传统的阶层式组织，但还算相当扁平化 的；除此之外，这四种角色必须各派代表参加特色监督小 组，每一项产品特色都有专属的特色监督小组，以确保每 项特色都能照日程做出来，这个小组必要时可自行开会。(特色( f e a t u r e )一词，也有人为了听起来较大众化而译 为功能，这是因为中文里的功能一词，意义非常广的 缘故。

事实上特色是指完成某项功能的独特方法，特 别是与竞争者不同的地方，它适用的范围很广，您可法则7建运用特色监督小组73以说，采用C o n t r o l - C . C o n t r o l - X . C o n t r o l - V来操作“剪 贴簿”是微软产品一贯的特色，您也可以说，某软件 具有随插即用的特色。—译者注）特色监督小组运作模式有几个重要因素：分别是充分 授权、赋予责任、融入任务、建立共识和地位平等。特色 监督小组是我所经历过最神效的组织方法，我将它的五项 重要因素讨论如下：充分授权（E m p o w e r m e n t） 像特色监督小组这样的 编制似乎比较非正式，无法像阶层式的组织那样容易管理， 但它需要被充分授权才能发挥作用。譬如像开发人员，他 们是“专才”，几乎专职负责某一特定的技术领域，若是 让他们完全主导一项产品的设计显然太不智，如果加进一 些别的角色，形成“通才”的局面，就平衡多了。单靠经 理人的决定，恐怕不够全面，我看过太多好的（或坏的） 决策，一下子就被另一位经理完全推翻，我倒是没见过特 色监督小组把事情搞砸过。

也就是说，只要特色监督小组 能被充分授权，并且发挥它的作用，就可以确保决策的品 质。（当然特色监督小组的必须挑选适合的人参加，本书 附录中将说明这一点。）

赋予责任（A c c o u n t a b i l i t y） 我认为软件开发问题中74最有趣的就是赋予责任这个主题。我们讨论过的题目是：“你负责什么？”我的理论是，大多数人的思考都没有好 好利用到，因为人们并不把提出新想法当成自己的责任之 一（请参考法则4：别做笨蛋）。首先，人们可能认为：“这不是我的责任范围”，因此 少管闲事，不提任何有建设性的提议。如此一来会有很多 不良的后果，尤其是当事情没有用语言沟通，会引起许多 误解、猜忌、行动力的相互抵销，而最后只有用行动来抗 议了。

只要单纯地请对方表示看法，这样的姿态很容易解除对方的心理防线。

其次，如果建议的来源真的说出了他的想法（可能要 冒很大的风险），被建议的对象很可能产生防卫心理（又 不是你的事情，管什么管嘛！），导致争端。有时候，防 卫心理是非常隐讳的，特别是当这个组织的文化将防卫心 理视为缺点时。讽刺的是，愈是成熟的团队或个人，愈会 执着于现有的优良管理制度，愈会提出各种反驳的理由来法则7建运用特色监督小组75证明现有的做法才是最好的，不需要什么建议。第三，除非建议者克服自己的攻击心理，否则这个 建议可能永远到不了对方的心中。就像防卫心理是普遍 存在一样，攻击心理亦然。通常提出建议的人都有某种 攻击性或包含价值判断的态度，这也是绝大多数的人都 有的弱点，而受到批评的人会感觉到威胁而更强烈反弹， 于是提出建议的人立刻下结论：这人是个笨蛋，沟通的 大门立刻关上。有很多建设性的想法就此消失。我所想到惟一的解决 办法，就是所谓的研讨会（w o r k s h o p）。

在研讨会中人们 主动上前邀请同事提出批评指教，这样单纯的提出、接受、 反馈的循环中，每个人都会受到批评、提出建议，这是比 较容易让人卸除心理武装的气氛，比较容易对事不对人， 如此单纯的信息传达让每一个人都轻松接受建议而愿意改 善。令我惊讶的是，由于研讨会的练习使得组员熟悉沟通 技巧，最后反而不需要经常开研讨会了。我有过多次运用研讨会的方式解决软件开发问题的经 验。方法像是个案研究（case study），由一位志愿的组员 主持；这个案例当然是现在发生的真实情况，通常是关于 组内的人际关系，主持人先描述案例的大致情况，有时故76意不说明当事人的名字，比方说：──我实在无法接受这种想法。

──没有人看我的电子邮件（指建议）。──某人根本没有把心放在项目上。 然后其他的人开始讨论，询问主持人关于此案更详细的信息，并理清一些盲点，或是询问主持人尝试过那些方 式，之类的问题。最后事情会在讨论中澄清，问题也就差 不多解决了。前述的两种简单方法会产生两项很重要的结果（从来 没有让我失望过），其一是这样的讨论会造成非常多的新 点子伴随而生：你会看见主持人不断地说：“这个想法太 棒了！”然后当场记在笔记本上；其二是这种案例研讨的 结论通常可以应用在其他类似的情况，人们会发现，这就 是我上个月讨论过的某案嘛！当类似的过去案例累积到相 当的数量，人们就会发现本案也不是什么特例，然后就会 发现处理这类事情的通则，把它记在笔记本上作为日后的 参考。

法则7建运用特色监督小组77在横向的特色监督小组中，一个人的成功或失败是完全透明的。

“赋予责任”有很大的好处，很少有应用上的限制。 如果一个组织健全的团队成员，对于整个任务的过程─ 设计、开发、除错、品质、期限─彼此都负有责任，就 会自然地互相给予建议和建设性的批评，而且用正面的态 度接受。因为每个人都有相同的责任。一旦建立团队的责 任感，这种对责任的认知会分享、传递到团队中的每一个 份子。融入任务（I d e n t i t y） 充分的授权和责任感，使人具 有控制权和影响力，愈能使自己与任务融为一体。控制权 愈大，融为一体的一致性愈高。这种融为一体的一致性是 开发任何好软件的先决条件，它会将个人的心理状态健全 与否，表现在软件作品中。譬如说，有一个人心中有挫败 感或是自我毁灭的倾向，就会在他所负责的软件功能中表 现出来。

在横向的特色监督小组中，每个人会将产品当作他的78任务，而非狭隘的技术而已。没有什么人可以推诿塞责， 一个人的成功或失败是完全赤裸而透明的。你不能责怪管 理不良，因为你自己就是管理者，你不能责怪其他的功能 支持人员没有好好配合你的产品特色，因为你们是相互负 责。因此，你有责任自己找到答案，你有责任克服自己的 障碍。建立共识（C o n s e n s u s） 共识是特色监督小组的气 氛。因为大家聚在一起的原因是“产品特色”而非功能， 由于责任是互相的，敞开心胸是安全也是必要的。我见过 有些特色监督小组自动地重新组织他们的关系，建立共同 目标、重新规划资源、适度修改日程，而没有发生严重冲 突。即使有冲突，由于不是对人的或是出于私心，通常都 很容易解决，不需要主管以职权介入。地位平等（B a l a n c e） 由于特色监督小组的每一位成 员都是不同的背景、专长，不同的工作角色和不同的观念， 没有谁比谁优越的情形，所以每个人的地位都是平等的。 通常人们对于不属于自己专业的领域，反而会有一些全新 的看法，刺激彼此打破过去的观念限制或盲点，激发更好 的创意。

由于各人的意见来自不同的着眼点，就可以使产 品的开发顾全更广的层面，而更周全、完美。不同角色的下载人会关心不同的问题：微软团队·成 功 秘 诀法则7建运用特色监督小组79项目经理：团队目前的状况如何？开发过程顺利吗？ 领导是否有效而得宜？我们走到开发周期的哪个阶段？进 度是否控制得当？需要别部门协助的地方是否已经取得支 持？我们的目标明确吗？还有什么尚未完成的工作？本周 的工作主题是什么？品保人员：我能不能依照预定的时间自开发人员手中 取得阶段性程序代码？程序有什么样的错虫出现？这些错 虫对付得如何？有什么功能尚未开发出来？程序的执行效 能如何？本周的产品状况是否合格，需要对谁提出警告 吗？项目经理知不知道程序的稳定程度？我们团队的沟通 如何？是不是每一个人对产品状况都有相同的认知？本周 合理的短期目标应该是什么？开发人员：本周我能不能完成预定的工作进度，将阶 段性程序代码交给品保人员和文件人员？这一段程序代码 写得够好吗？使用者需不需要这个功能？这个程序容易使 用