第 １ 章 奠定基础
您是否曾经暂时停下手边的工作，思考一下如何能使项目的进行更有效 率？您想到的是需要高深学问才能解决的方式呢？还是只要利用一些经验法 则就能化腐朽为神奇呢？
但愿这个答案像猜谜游戏一般简单，这样我的训练工作就容易多了，可 惜事实不然。要让项目提高效率，需要长时间、一点一滴地累积非常多的知 识、技巧和信念，尤其新手更是如此，不幸的是，这种能力的培养需要很大 的耐心和毅力，而大部分的人都是用尝试错误的方式来学习，这样代价既高，
功效也不大。
尝试错误的方式会耗用很长的时间，可能得到经历很惨痛的教训，如果 能善用前人的经验和智能，学习前人已经归纳出来的知识，避免犯下同样的 错误，不就快得多了吗？
本章首先来介绍前人的经验。就我所知，对于一个希望不加班就能如期 完成任务的团队，必须把握好的原则，这是软件开发部门的基本观念，也是 往后几章的基础。
专心改善产品
公司付薪水给程序设计师，是要他们在合理的时间内做出品质精良的软 件，但是程序设计师的时间却经常被其他的事情占用掉了。这样的程序设计 师或他们的经理们，就是因为不了解软件开发的真理：
任何不能改善产品的工作，都是浪费时间或是偏离方向。
如果您一时不了解这个观念的重要，请想一想以下两个极端典型的比 较：一位程序设计师一天到晚开会、写报告、阅读和回复电子邮件，另一位 程序设计师则专心研究、设计和测试新产品的功能，试问谁比较容易脱颖而 出？毫无疑问是心无旁骛的那一位，他甚至可能提前完成工作呢。
我经常发现，团队出问题的原因之一，往往是因为程序设计师们都在做 他们不该做的事：他们花太多的时间准备开会、参加会议、读写开会记录和 进度报告，以及回复电子邮件。这些不能改善产品的工作，固然一部分是程 序设计师自己主动做的，但更大的一部分是主管下的命令。
曾经与我共事过的一位经理，要求每一位组员要用 ｅ－ｍａｉｌ 交一份工作周 报，每周开一小时的会讨论目前各人手上的工作内容，以及其他突发性的事 务，开完会后，提出意见的人负责写出书面报告，交给经理。
这位经理的动机只是想管理每一个细节，但并不了解这会让团队被无意 义的工作压得无法喘息。这些进度报告真的那么重要吗？那些后续报告的用 意又是什么呢？如果开会时经理自己做个简单的笔记，不就省了这些报告所 占用的时间和精神？
很显然，这个问题的答案必须视您身处的企业环境而异，但从我刚才所 举的实例来说，其实只有最初制定进度的那份报告是有价值的，其他的报告 都是可有可无，甚至进度检讨会都没有必要召开，而且每次那位经理要求后 续报告时，我都很纳闷，心想：“我刚才不是已经告诉他我的想法了，为什 么我还得再写一遍？”
我不过是偶尔去参加他们的定期进度会议，所以对我的时间损失并不 大，不过，我常在想，不知道公司里有多少不必要的例行工作正在加重员工
的负担？这位经理本意是尽力把每件事情做到巨细靡遗，但是却违背了身为 软件开发领导者的基本守则：
领导者的任务是努力消除程序设计师工作上的一切障碍，让程序设 计师全力专注在真正重要的工作——改善产品。
这并不是震惊世界的大发现，而是极简单的道理，但是，有多少软件开 发主管是真的把“消除程序设计师工作上的障碍”当作积极追求的优先目标，
而且确实做到呢？
如果刚才提到的那位经理真的用心去减少组员不必要的工作，我确信他 可以想出更简单有效的方法掌握工作进行的状况，而不必一再浪费组员的时 间开会和写报告。
千万不要把程序设计师的时间浪费在改善产品以外的工作上。
请不要从字面上解释我的话
我所谓的不要把程序设计师的时间花在改善产品以外的工作上，请不要从字面解释成程序设计 师只许写程序。事实上，思考如何设计、测试程序和接受需要的训练等等，虽然不是直接投入在改善 产品上，但对产品品质却有重大深远的影响。如果程序设计师在动手写程序前，仔细思考过产品的设 计，把缺点改正，当然会比一味地埋头苦干要好得多了。
有些团队的活动，用意是让团队成员在愉快的环境中工作，提高程序设计师的生产力和士气，
虽然看似与产品无关，最后还是对产品品质与工作效率有正面的帮助。
排除干扰
如果您希望团队能在期限之内完成好的软件，就必须尽可能排除一切不 必要的工作，特别是您打算分派工作给全体组员之前，请等一下，问问自己，
这件工作真的有必要叫大家做吗？能不能由您自己做呢？比方说，如果您要 准备向上级报告项目概况，非得要所有的程序员停下手边的工作，为每个程 序写一份摘要吗？我倒不这么认为。身为经理，您应该平时就对项目的进度 及一切的状况非常清楚，不必靠人帮忙就能做出切中要点的演示文稿，而且 信息已经存在脑海中，比起再去汇总整理一堆人的报告应该是快得多，也更 好组织。或许这要花掉您几个小时，但总比打搅整个团队去做一件与产品无 关的工作要好。
我通常会做得更彻底一点。如果我发现一位程序设计师总是被不能不 做、却与产品无关的工作绊住，我会主动解除这件工作，由我来做好了，这 样程序设计师就能完全专心在软件上面。除非是为了训练，否则没有任何理 由要求程序设计师本人回复 ｅ－ｍａｉｌ，询问项目的 ｅ－ｍａｉｌ 交给适当的经理来 回答就行了。凡是能由主管出席的会议或能由主管执笔的报告，都不应该丢 给程序设计师，最好能把这些开会、报告都废除。
我 知 道 这 些 建 议 与 大 部 分 的 管 理 课 程 或 教 科 书 上 所 指 的 授 权
（ｄｅｌｅｇａｔｉｏｎ）有所冲突，我并不是说这些课程和书籍错了，而是您在实际 工作中应该放聪明点，对于工作的分派应该更有选择性。如果把工作分出去 的目的仅仅是为了减轻个人负担，实质上您做的是伤害团队生产力的事情。
别人“能”做某件事，并不代表他“必须”做那件事。
您看过整个房子的搬迁吗？我不是指搬家，而是整个房子从地基上拔 起，用车拖着移到别的地方（美国的房子多是木造的，可以这样搬移）。我 们可以把项目比喻成那间房子，把经理想成开路先锋，他的责任是把前面所 有的障碍物排除，让房子能一路不停地稳定前进，而不是走走停停，停停走 走。
房子前进的时候，领导者不希望每到一个路口就停下来处理红绿灯，或 协调其他的车子让路。他必须事先就规划好最理想的路线，在房子抵达路口 之前，就协调好工程人员卸下悬挂着的标志灯或是电线等会阻碍行进的东 西，等房子经过了再装回去。他应该避免将拖车停下来缴过路费，或是等待 他跟工程人员开完协调会。
搬迁房子的开路人员明白一件事，如果要房子一路不停地向前行进，一 定要找出所有的障碍，并且排除掉。过路费当然也可以由拖车司机来交，可 是这样一来就得停下车子，如果由开路人员在前面交不是更好吗？很不幸，
有太多的软件开发经理在不该授权时授权，让组员为了与产品无关的事情疲 于奔命，被外界的杂事干扰正常的进度，以致项目进度不断延误，甚至停滞 不前了。
保护程序设计师不受任何阻碍和干扰
如果我带的不是程序设计师，而是主管…
前面的讨论中，我假定您是程序经理，带的是程序设计师，但是如果您带的是测试人员、文件 撰写人员或是其他类型的小组，您的原则还是一样的。基本上，身为主管的重责大任就是让属下专心
做他该做的事，不论他该做的是写程序、测软件还是写文件。
就算您带的全是主管，您也应该决定哪些工作是不必要的，尽可能免除。
开个会了解各位主管们手上项目的进度，和开个会了解各位程序设计师们手 上程序的进度，都一样是浪费时间，特别是独立进行项目的主管，没有必要 让一位主管了解与他项目无关的概况。主管的时间对产品影响也很大，浪费 主管的时间，他就没有办法做他该做的事——排除程序设计师的工作障碍。
一定有更好的方法可以减少干扰
身为经理，我在项目的每个阶段都会问自己一个问题：
“我努力的目的究竟是什么？”
我总是不断用这个问题提醒自己，因为太容易被不重要的工作拉偏方向 了。如果您经常把报告或备忘录东修西修的，换个字型或样式，结果美化文 件的时间比写的时间还长，您就明白我的意思。因为在那一刻，这件工作占 住了您全部的思绪，似乎是最重要的事情，但只要您随时以整个项目的眼光 来看事情，您就不会陷入细枝末节了。
我们谈过了把时间浪费在进度报告和检讨会议的案例，现在您应该可以 回答这个问题：
“我举行进度会议和要求进度报告的目的究竟是什么？”
我想，主要的目的是了解项目进行的状况，以便及早发现任何进度上的 延误，避免项目发生进度失控，不是吗？假定没有发生延误，每一个项目都 如期完成，也没有人需要加班，那还有必要报告进度吗？当然不必了。
如果您开进度会议和要求进度报告目的，是想确定项目进度有没有落 后，有必要动员全体去收集这些信息吗？我不这么认为。我从来不开进度会 议，不论我是带新的项目或是接手其他人带了一半的项目，我第一个废除的 就是这类没有意义的流程，我就是不相信非得用开会写报告的方式才能掌控 项目的进行状况。
至于进度报告呢，它究竟有多重要？我认为进度报告虽然令人厌恶，但 却是必要的，经理总得了解项目是否出了问题。但请别忘了，进度报告虽然 必要，但是它绝对不会对产品有任何帮助。所以，当您遇到一件必要但对产 品没有帮助的工作，您得寻求这个问题的答案：
“我该怎么样保有这项工作的好处，消除它的缺点？”
进度报告确实有重要的目的，但得花时间去写，而且令组员心生反感—
—至少在微软曾经有不少团队深受其害。
如果一位程式设计师要花几个小时写报告，交代自己做了什么工作、解 释这件工作为什么花的时间比预计的长，那的确会对他造成过度的压力，并 且让每个人预定项目一定会延误。更常见的现象是，程序设计师明明每天卖 力工作至少 １２ 小时，而且没有磨洋工，整整工作了 ８０ 小时之后即发现他只 完成了本周日程表上 ２７ 小时的工作。
进度会议（ＳｔａｔｕｓＭｅｅｔｉｎｇ）的用意
我想，每家公司的进度会议都不完全一样，我所指的进度会议，是指每个人坐在一起轮流讲讲 自己做了什么，或是没做什么，只有这个用意。
还有一种进度会议，其用意不是讲述各人做了什么或是没做什么，而是同一项目中不同小组的
协调，只有多小组项目（ｍｕｌｔｉ－ｔｅａｍｔｏｊｅｃｔ）才有这个需要。每一个小组的组长并不报告各事项进行 的细节，而只提出会影响其他小组的事项，例如上游工作进度比预期的慢，或是目前已经完成可以交 付下游工作小组，或有一件事希望别的小组配合或支持等等。这种进度会议是为了协调小组之间互相 依赖的工作事项。任何需要等待别的小组做完才能开始工作的下游小组，都需要预先知道上一小组的 工作情况如何，而且每一位应该尽早知道，这对于制定下游小组的工作进度是非常重要的，不然会临 时手忙脚乱，或是影响整个项目的进行。
但是真理依然不变，程序设计师是不该被这些事情干扰的，小组的组长去开会就够了。
如果您没有过这种痛苦的经验，请试着想像一下：您已经是拼尽全力加 班了，但永远赶不上进度，目标离您仿佛愈来愈远，那会多么令人沮丧！更 别提您不敢浪费一分一秒，每天都累得像狗。假如这种情况是日复一日、年 复一年，您还能每天早上精神抖擞地跳下床，满怀热忱去上班吗？或者更可 能的是，您心中充满愤怒、挫折、沮丧，愈是努力工作，工作积压愈多，结 果进度愈落愈远，天——啊……！
我恨进度报告，因为它迫使程序设计师想着自己没做的事，而不是强调 自己完成的事。组员无法感受到逐渐推进目标的快感，反而随时被提醒：进 度落后了喔，项目不晓得会不会莫名其妙地搞砸。他们只知道自己工作确实 很尽心尽力，但实在不知道如何跟上进度。
团队也和个人一样。如果团队觉得整体不断往前进，那么就会一直保持 前进，而如果团队觉得自己一定会落后进度的，那么，惯性和自我预示的心 理就会使它相信自己是永远的失败者，导致士气非常低落。
请不要误解我的意思：如果一位程序设计师明明工作了 ８０ 小时，却只能 完成进程表上 ２７ 小时的工作，那一定有什么地方搞错了；也许他最近做了太 多人员面试的工作，或是开了太多的会，或是最近 ｅ－ｍａｉｌ 太多，或是他正在 调整自己的情绪，主管应该和他一起找出问题。但是，即使是他个人不懂得 善用自己的时间，也不该用进度报告使他难堪。我们待会儿有更好的方法解 决这个问题。让我们回到前面提出的问题：如何保持进度报告的好处，又不 必忍受它的缺点？其中一个答案是设计一种新的进度报告，非常容易写，既 不花时间，且内容是正面性的。
以下是我的方法（我相信您一定可以想出更多更好的方法）：
◆每当有人完成了一项新的功能或特色，就发个 ｅ－ｍａｉｌ 给大家。
◆每当进度快要落后了，就到我的办公室私下讨论原因，我们一起开动 脑筋寻求解决之道。
就这么简单。依我的方法，典型的进度报告可能是这样的：
“我已完成 Ｆａｘｍａｎｇｌｅｒ 的搜寻与取代功能。Ｆｒａｎｋ”
主管应该看一下结果，然后回一个：
“我检查过 Ｆａｘｍａｎｇｌｅｒ 的搜寻与取代，不太顺畅，请再修改。Ｈｕｂｉｅ”
或是：
“很好，继续加油！Ｈｕｂｉｅ”
想想看，如果大家经常收送这类正面的 ｅ－ｍａｉｌ，一定会觉得充满干劲，
这和可恨的进度报告多么不同！程序设计师会很乐意看见这类的好消息，当 自己送出完成工作的信息时，也会很有成就感；没有人会觉得这是很讨厌的 报告。当某位程序设计师觉得自己可能要落后了，我会和他谈，研究将来如 何避免这种事情。是我们在制定进程时疏漏了某一个重要环节吗？或是时间
表定得太乐观了？是不是有个错虫（ｂｕｇ）在作祟，害得程序很难写或无法测 试？不论问题是什么，我们一定想办法解决掉，并且预防它将来再发生。
我只要靠这两种方式，就可以完全掌握项目进行的概况。上级要求的话，
我也可以轻松写出项目演示文稿，根本不必劳驾别人，所以我带的程序设计 师不会因此而被打扰。
更棒的是这两种反馈方式产生了双重好处：第一，团队成员经常感到项 目又向前迈进了一步；第二，这对主管和属下都是很好的学习机会，我们不 会耸耸肩，无所谓地说：“反正进程一定会落后的，没啥大不了。”因为我 们会认真面对问题，商讨对策。
为了强调进度报告的正式性，而把它弄成一件沉重不堪的工作，这就是 主管过度重视进度而忘了自己真正的目标。结果陷入了流程的陷阱，倒把产 品丢在一边了。
只有当您非常清楚您和您的团队该做的是什么，您才能用最少的时间和 最少的挫折去完成项目目标。回头检讨一下遭遇过的困难，有没有办法可以 改善？有没有更好的方法，让工作愉快些？至于那些对产品没有帮助的杂 务，如果可能的话，还是免了吧——至少不要把它丢给程序设计师。
永远记得自己真正的目标，然后让团队用最有效又最愉快的方法把它完 成。
被成功的喜讯围攻了？
您可能会有这样的疑问，如果每个人都把自己完成某件事的讯息发给大家，会不会塞满了每个 人的电子信箱。实际的情形是，每天的 ｅ－ｍａｉｌ 并不多，因为信息不会送给每个人，而是只送给同一组 的四到五位程序设计师而已。
微软比较大的团队可能有多达 ５０ 位的程序设计师，但是都会分成小组，每一个小组大约有五到 六人。每一个小组负责项目的一部分，有一个明确定义的目标，有一位组长，也有自己的进程。小组 内的程序设计师当然也属于整个团队，但是以每天的程序开发工作而言，只与四五位程序设计师有关 而已。
事实上，即使是 ５０ 位程序设计师的大型团队，每个人收到的“完成××”的 ｅ－ｍａｉｌ 也不多，
数量稳定，刚好够让每个人感觉到工作的进行，绝无爆炸之虞。
明白说出目标
您所认识的人中，有多少位一早起来突然发现奇迹，选了几门神奇的课 程就拿到了计算机硕士学位？有多少人随便收拾一下东西就搬到了您的隔 壁？听起来不太可能吧。没错，一般人不会兴之所至就去修个学位或搬家，
这些都是计划过的，他们会决定：“我要成为程序设计师”或是“我要住在 迪士尼乐园旁”，然后筹划一番，再采取行动，才会达到目的。
可是，生活中的确有些事情是不经意就发生了，您可能靠运气就得到一 份好工作，或是福星高照在股市捞了一笔。很不幸，推出一套软件的目标，
并不比“我们要完成 ＷｏｒｄＳｍａｓｈｅｒ”具体。
不错，大部分的时候您都可以完成目标，但问题是，在这之前，有多少 时间被浪费掉了？虽然您运气好，得到了一份理想的工作，但之前也许有好 几年频频跳槽；或者您先细细思量自己适合什么样的工作，然后找到符合自 己条件的几家公司寄履历、面谈，会比较稳当？
我所辅导过的案例中，有六个总是在失败边缘挣扎的团队，他们都有一 个共同的特征，就是目标太模糊。其中一个案例的情况是，小组的任务是做 出使用者界面的函数库，给 ２０ 个左右的其他小组使用，他们做得人仰马翻，
还被别的小组抱怨函数库既笨重，错虫又多，很不好用。
当我和这位组长共同检讨工作清单时，我问他项目的目标是什么。“为 ＭＳ－ＤＯＳ 的应用程序提供像 Ｗｉｎｄｏｗｓ 环境的使用者界面函数库。”我问他还有 什么。“您的意思是？”
我说，他刚才的答案太模糊，能不能说得更具体些？“嗯，函数库应该 做到零缺点。”
我点点头，再问：“还有呢？”
他想了一下，耸耸肩，答道：“我想不出来了。”接着，我说明任何函 数库的主要目的是存放每位需求者必要的公用程序，不是大家非得用到的东 西是不该在里面的。他很同意，认为这一点是显而易见的。但当我继续下面 的讨论，我开始不确定他是否真的懂得这一点。我指着工作清单上的一项，
问道：“这是做什么用的？”“那是 Ｗｏｒｋｓ 小组要求的，是用来……”
“对其他小组有用处吗？”
“没有，只有 Ｗｏｒｋｓ 小组会用到。”
我指着清单上的另一项，问道：“这个呢？”“那是给 ＣｏｄｅＶｉｅｗ 小组的。”
“那，这边这一项呢？”
“是 Ｗｏｒｄ 小组要的。”
我们一路看下去，我发现他对任何要求都来者不拒。我想他也知道函数 库中应该只有大家都要用的程序，但他在做决策的同时并没有确实把握这个 原则。他的目标只是“为 ＭＳ－ＤＯＳ 的应用程序提供像 Ｗｉｎｄｏｗｓ 环境的使用者界 面函数库”，有没有办法说得更详细些？
目标是为 ＭＳ－ＤＯＳ 的应用程序提供像 Ｗｉｎｄｏｗｓ 环境的使用者界面函 数库，只包含对每个小组都有用的程序。
如果把目标定义精确些，就可以发现很多程序其实是不应该放在函数库 中的。在我们检讨完工作清单后，我开始研究另一个问题：“很多小组抱怨，
函数库中每次一放入新版的程序，就会发生链接失败，这是怎么回事？”“喔，
那很简单，他们只是忘了修改自己程序中的函数名称而已。”
这我就不太懂了，于是我请他给我一个实例。他的小组修改过函数库中 的 ｂｕｇ 了，或是加强了该函数的功能，然后就连名称也顺手改了，用另一个 更能表达其功能的函数名称；或者是做了一点小小的修改，然后把函数名称 一道改了，以强调所改的差异部分。
这位组长不了解其他小组怎么会如此大惊小怪，不过是改个名字而已，
非常简单啊。他从来没想过，有 ２０ 个小组要因此检查所有的程序，把所有用 到函数库的地方都改过来；他也没有想到，经常链接失败的函数库是很不好 用的，函数朝令夕改，别的小组会无所适从，根本不知道程序应该是什么模 样才对。
如果这位组长稍微花点时间，从别的组的角度来看看这个函数库，他就 会明白放入新版程序时，与旧版能兼容是多么重要。大家都希望既用到新的 程序代码，希望所有的程序都能链接成功，没有任何失败。
于是，我们把项目的目标再更具体化一些，那是：
目标是为 ＭＳ－ＤＯＳ 的应用程序提供像 Ｗｉｎｄｏｗｓ 环境的使用者界面函
数库，只包含对每个小组都有用的程序，而且必须和其他部分的程序版 本一致。
现在我们理清了影响这个函数库的重要相关因素，我和组长一起定出了 清楚而明确的项目目标。我们发现，只要用心考虑各因素之间的关系，考虑 一项行动会造成什么影响，很多细节就会变得显而易见，而且是可以事先建 立正确的规范，避免事后再来花更多时间收拾残局。只要在做出决定之前想 一想，“我要这个函数库能做到什么？项目的目标是什么？”很多问题都能 迎刃而解，组长可以轻易决定什么是该做的，以及该如何做。
如果做得更彻底一些，组长可以花几个小时，甚至几天来订出详细的项 目目标，这些目标不一定要博大精深，只要目标能够写下来贴在容易看见的 地方，随时提醒、随时指引，让项目朝着正确的方向进行就可以。
如果函数库中都是全部小组需要用到的，函数库就会体积小些、精简而 标准化，新增的功能特色就比较容易做出来，开发小组就不必拼命加班做一 大堆只有少数人用得到的函数。想想看，只要把目标稍微理得清楚些，整个 项目的方向就会有惊人的改变。
理清详细的项目目标，可以避免在不必要的工作上浪费时间。
相互依赖
项目失控最有可能的原因是小组之间工作上的相互依赖：一方必须依赖另一方把工作做完才能 进行自己的工作，而且若是彼此的配合或沟通不够好，整体工作必然受到不利的影响，依赖愈多，愈 容易失控。使用共享函数库有很多好处，这是人尽皆知的事。但是身为组长的人，必须衡量是否该把 这部分的程序代码放进函数库，所获得的好处与必须忍受的缺点——让其他的工作依赖于它，孰轻孰 重。任何领导者，必须牢记并且实践以下的座右铭：
尽可能减少项目中小组彼此间的依赖。
想想看，万一函数库的开发工作进度落后了，又未能及时采取改善措施，对其他的小组有多大 的伤害！负责函数库开发的小组会拖累大家的进程，使大家不由自主地一起延误，若不能及时挽救，
项目就真的失控了。
另一方面，如果依赖函数库的小组听说开发函数库的小组无法在规定时间内完成要求的工作，
也不该强迫他们。因为函数库的开发是很多其他工作的基础，绝不容许发生丝毫错误。如果强迫开发 函数库的小组必须在某个期限内完成过多的工作，等于是不恰当地依赖开发函数库的小组。
以上所谈的道理似乎简单浅显，但是做起来可不然，我看过很多重复发生的错误，有许多小组 真的耗费了大量时间在函数库的依赖性问题上纠缠。
努力要有代价
有些管理学的书喜欢把设定目标看成一种神秘的哲学，让您读起来会有 这样的感想：“我不知道究竟为何要设定目标，只知道经过研究证实，有明 确目标的团队，会比目标模糊的团队更有生产力。”
我不知道这些管理学书籍为什么把设定目标这件事弄得这么玄，设定目 标只不过是把“你要完成的事”用清晰的语言描述出来，让每个人都有明确 的概念。如果您的目标是买一栋这样的房子：２０ 世纪初期的维多利亚式三彩 建筑，有四间卧室两间浴室，后院还要一尊法兰西斯雕像，您大概会先看过 一大堆的房子，然后才确定自己想要的是哪一栋。目标越是明确，达成目标 的过程就会越有效率，因为您能马上拒绝不符合脑中未来景像的事物；明确
的目标之所以带来效率，正是由于它能帮助您挡掉别的项目丢过来的不相干 的垃圾，让您专注在本项目的策略性事项上。
不幸的是，在软件开发过程中，没有任何事件能迫使领导者停下来想一 想，却有庞大的压力迫使领导者没有时间思考，反而忽略了设定目标这么重 要的事。当项目已经落后了一大截，都快失控了，谁还有时间去设定详细目 标呢？有些主管不设定目标则是基于完全不同的理由：别人都没有设定目 标，我们为什么要这样做？不论理由是什么，凡是没有明确目标的小组，必 定遭遇额外的挫折。
如果您希望项目进行顺利，就一定要花点时间设定详细的目标，这不是 什么有趣的事，但这一两天的功夫让您的项目不会偏离方向，相对的报酬是 非常值得的。组员的努力应该有代价，而长期加班、饱受压力的小组，多半 是工作漫无目标的后果。
不要因为制定目标需要花很多时间，或是别人都没有做，就省略了目标 的制定。制定明确详尽的目标所花的时间，绝对会让团队得到更大的好处。
程序设计的优先考虑
如果您请三位朋友顺路到超级市场帮您买些芦笋、绿豆、玉米，结果其 中一位买了罐头蔬菜因为最便宜，第二位买了冷冻蔬菜因为最容易煮，第三 位买了新鲜蔬菜因为最健康也最美味，您会觉得惊讶吗？至少，您觉得这样 的事情会发生吗？
这三位朋友买了不同的蔬菜，因为在他们心目中，强调的优先考虑不同，
程序设计也是一样的道理：即使同一个程序，由三位程序设计师写出来的程 序代码必定不同，第一位程序设计师强调程序代码应该越简炼越好，第二位 认为容易使用最重要，第三位则喜欢追求执行速度。
假若您的产品必须快得让人目不暇给，而程序设计师却认为写程序的第 一要点是轻薄短小，那么做出来的成品不太可能会使用特别的加速方法，执 行速度也不太可能令人惊喜。假若您的主要目的是在最短的时间内做出高稳 定性的软件，但是您的程序设计师却喜欢追求执行速度，而不太在乎稳定性，
结果一定无法令人满意。如果程序设计师心目中理想的考虑顺序和项目目标 并不一致，想得到满意的产品就好比缘木求鱼。
项目目标和程序设计的优先考虑并不相同，但二者常会发生部分重叠，
主要是因为项目目标能帮助考虑顺序的确立，以下是重要的基本观念：
◆项目目标引导项目进行的方向。
◆程序的考虑顺序影响程序设计的过程。
假定项目的目标是做出世界上最快的 Ｍａｎｄｅｌｂｒｏｔｐｌｏｔｔｅｒ（一种画几何 图形的程序），效率就是程序设计时的第一优先考虑。
暂时不谈程序设计的优先考虑有何重要性，在我的经验中，主管很少注 意到这个问题。程序设计究竟该以什么为最优先考虑？速度？体积？稳定与 坚固性？可移植性？可维护性？每一位程序设计师对于程序设计的优先考虑 看法不同，并且反映在他们的作品中。如果大家各自随意，就很容易出现不 一致的情况：有些人为了容易维护而坚持写干净漂亮的程序，另一些人认为 速度是最重要的，所以写了一大堆别人看不懂的程序代码或汇编语言。
如果您希望小组工作有效率，能够精确地达成项目目标，您就得建立最
适当的程序设计优先考虑顺序，并且让所有的程序设计师确实遵守。最低限 度，您应该为以下的程序设计考虑点排出一个优先级表：
◆体积大小（ｓｉｚｅ）
◆速度（ｓｐｅｅｄ）
◆坚固性（ｒｏｂｕｓｔｎｅｓｓ）
◆安全性（ｓａｆｅｔｙ）
◆可测试性（ｔｅｓｔａｂｉｌｉｔｙ）
◆容易维护（ｍａｉｎｔａｉｎａｂｉｌｉｔｙ）
◆简洁（Ｓｉｍｐｌｉｃｉｔｙ）
◆再用性（ｒｅｕｓａｂｉｌｉｔｙ）
◆可移植性（ｐｏｒｔａｂｉｌｉｔｙ）
这张顺序表中唯一需要解释的是安全性，如果您认为安全比速度重要，
您就得选择重安全而轻速度的方式，优先要求程序中没有 ｂｕｇ。比方说，程 序有两种方法可以选择，一是表格扫描（ｔａｂｌｅ－ｓｃａｎｎｉｎｇ）、一是逻辑判断
（ｌｏｇｉｃ－ｄｒｉｖｅｎ），前者比较慢，但也比较安全，既然安全比速度优先考虑，
那么除非有别的重要理由，您应该选择表格扫描的方式。
除了程序的优先考虑顺序之外，您还应该建立各项考虑点的质量规范指 导。例如您认为坚固性是第一优先考虑，那到底要多坚固才算合格呢？最低 限度，程序在输入资料正确时绝对不该发生错误，但万一输入资料不正确时，
程序会怎么办？程序应该很聪明地处理错误的输入资料，在某程度内自动更 正它（哪就得付出体积和速度的代价）？或是在程序中加入检查输入的动作，
尽可能督促使用者输入正确的资料？或是就让错误的资料进入处理，干脆一 路错到底？这个问题没有标准答案，全看您对品质的要求。
大致上，如果是操作系统，在不死机的前提之下应该尽可能接受输入值，
如果是应用软件，应该尽量能更正不合法的输入资料，对无法更正的输入应 该提出警告。但是，如果纯粹就程序的质量而言，也许该考虑强调性的失败 信息，例如一个函数库中的程序，遇到部分不正确的输入值时，虽然可以做 下去，但无法预料会有什么结果，此时不如当成错误的状况处理而中断执行，
以免错用这个函数的程序误以为一切安好。总之，在一般情况下都应该对不 正确的输入作某种程度的处理，只要别让程序代码过度庞杂就好。
这里的重点是，如果事前就决定了最合适的优先考虑顺序，以及各考虑 点的质量规范，团队就不会浪费太多时间把程序改来改去，程序的整体风格 比较容易一致。
事前决定最合适的优先考虑顺序，以及各考虑点的质量规范，能够指引 开发团队的工作。
安全性或是可移植性？
以我个人的观点，我通常把安全性放在比可移植性优先的地位，也就是说，我喜欢安全的程序 甚于可移植的程序，这听起来有点含糊，那是因为可移植性高的程序通常表现出的安全性也高，事实 上，这两种特性没有真正的关连，只是可移植性高的程序碰巧也是安全性高的程序罢了。
写 Ｃ 程序时，宏（ｍａｃｒｏ）是很好用的，它可以用来当作子程序的定义，
但事实上它跟函数（ｆｕｎｃｔｉｏｎ）不同，每一次启用宏，会被展开成一段一般
的程序代码。但如果写得不够小心（例如同一名称重复定义），它会造成潜 在的 ｂｕｇ，这一点 Ｃ 语言程序设计师都非常清楚。用宏的方式来做函数，很 好用但容易有危险。
如果您愿意利用某些 Ｃ 语言编译器特别提供的 ｉｎｌｉｎｅ 指令，就可以充分 享用宏的好处，而不必冒潜在的风险，惟一的问题是，ｉｎｌｉｎｅ 不具有可移植 性，在不同的编译器之间未必兼容。对我而言，安全比可移植性重要，所以 我宁愿选择用 ｉｎｌｉｎｅ 的方式来保护宏函数。
当机立断
您可能听过很多极为成功的人士都有当机立断（ｓｎａｐｄｉｃｉｓｉｏｎ）的倾向，事实上，一般人如果 过快做决定，大都是颜面尽失的悲惨下场。差别是在于，那些成功人士早就已经设定好清楚的目标和 优先考虑的顺序，遇到任何问题，或是要裁决某个建议时，只要把它放到脑海中的决策“尺”一量，
立刻就会有答案。另外，成功人士不会轻易改变主意的，改变主意等于是背叛了自己的信念。
事实上，成功人士并不是未经思考就草率决策，只不过他们把目标和优先级订得非常清楚，所 以他们不必想太久，也不必为无关紧要的事情浪费时间；结果是：他们不必花太多时间来做决定，而 是花时间去做已经决定的事。
严守基本原则
回顾本章的讨论内容，我们可以总结出软件开发的基本观念：“确定您 要达成什么样的目标及如何去做，让每位组员都明白目标，并专注地朝这个 目标努力，设定程序的优先考虑顺序，以及相对的质量规范指导。”这些都 是很基本、很简单的观念。
现在，回头看看您公司内的各个部门，有多少个部门有清楚的项目目标？
有多少程序设计师接到关于程序优先考虑顺序的明确指示，以及质量规范指 导？然后问问自己：“程序设计师真的全力投入在改善软件的工作中吗？”
再看看您公司内的项目主管们，他们是否习惯在会议中讨论一些芝麻小 事，或是在讨论真正重要的事情？他们是否常常扔些与产品无关的工作给程 序设计师，例如写报告等等，或是认真为程序设计师清除所有阻碍工作的障 碍呢？
本章所讨论的全都是相当基本的概念，但在我的经验中，很少人对基本 的 东 西 认 真 思 考 。 而 我 相 信 正 因 如 此 ， 您 随 手 抓 起 一 本《 信 息 世 界 》
（ＩｎｆｏＷｏｒｌｄ）或《Ｍａｃ 周刊》（ＭａｃＷＥＥＫ）之类的专业杂志，里面就充斥着
“某个项目已再度落后六个月”之类的报导，或是某位程序设计师为了工作 连家都不能回的故事。
重点提示
公司聘请程序设计师，是为了开发高品质的软件，但如果经常被杂事打扰、分心，就无法保持 专注在真正该做的事情上。主管必须确定程序设计师能专心投入在具有策略价值的工作上，而不是打 杂，凡是会阻碍软件开发的东西，主管应该毫不犹豫地把它排除。
然而，有很多杂事其实是无法避免的，大公司尤其如此，那就只好将它的负面效应尽量减少，
方法是不断自问：“我到底想要完成什么？”“我该怎么做才能既保持这件工作的好处，又能避免它 的坏处？”要满足实质上的需求，而不是表面上的作业程序。
拥有明确目标所带来的好处虽然不是立竿见影，但没有明确目标所造成的混乱绝对是显而易 见。没错，建立明确目标是一件费时又无趣的工作，但比起项目延误或失控的危险，肯定是值得付出
的。请记得使用者界面函数库的实例，项目目标只要稍微改好一些，就会明显地减轻压力，项目目标 再修正一次，问题就几乎都迎刃而解了。
每一位成员都必须有一致的程序优先考虑顺序，程序的可维护性是最重要的吗？可移植性？体 积？速度？为了让软件产品符合项目的目标，必须让程序设计师明白本项目的程序优先考虑顺序，他 们在程序设计时才知道该如何取舍。同时，您还得对每一项优先考虑点事先建立质量规范指导，以避 免到时候质量不合格又得重写部分程序，导致时间浪费和项目延误。愈早定出质量规范指针，愈能省 时省力。
第 ２ 章 策略性的作业方式
虽然我从事软件设计已达 ２０ 年，但我写技术文件或文章时，从不使用文 字处理器，听起来很意外吧？我仍然用最传统的纸和笔做最初的草稿，然后 再输入计算机去编辑。
我肯定自己没有计算机恐惧症，而且我很清楚用纸笔绝对比不上计算机 方便，但我仍然这么做。
很久以前我就发现，当我使用文字处理器时，每写完一句我就忍不住用 编辑功能东修西改的，最后一天下来写不了多少东西。由于在文字处理器上 编修文字远比撰写文字简单，我常常沉溺其中不可自拔，太分心在编修上，
忘了写作内容才是本旨。反正早晚得修饰嘛，现在编修并没有什么不对，只 是我拖延了自己的工作效率。
有一天我终于领悟到，原来我一直在破坏自己写的作品，我必须寻找提 高写作效率的方法，我试着在用文字处理器时专心写作，不去使用编修功能，
却没有什么成效。我需要的是撰写比编修容易的东西，那只有纸和笔了，于 是我不再使用文字处理器来写作，我只用它来编修那些已用纸笔写好的几页 文稿。
我的新方法解决了我在写作时分心编修的恶习，因为它让我只管写作。
从这里我们可以看出，在程序上的一点小小改变，可以造成非常不同的 结果。以前我写五段的时间，现在我可以写出五页，这样的进步是因为我成 了一位有经验的作家吗？还是因为我的工作时间加长了吗？都不是。我的生 产效率提高，是因为我了解到我使用的工具有个缺点，而我找出了另一种比 较有效率的方式。
当您读完本章后，您会看到更多小改变大收获的实例。一旦您掌握了这 个概念，把它应用在项目上，您可以大声说自己确实是在聪明地工作，而不 是辛苦地工作（ｗｏｒｋｉｎｇｓｍａｒｔ，ｎｏｔｗｏｒｋｉｎｇｈａｒｄ），并且您的工作能够事半 功倍，再也不用熬夜加班，也能如期完成项目。
浓淡合适的咖啡
在咖啡店里常常遇到的难题是记住哪位客人喝什么咖啡：有些人要喝无 咖啡因的，有些人要喝一般的咖啡。于是有些咖啡店经理不惜花大笔金钱送 员工去接受超强记忆术（ＫｅｖｉｎＴｒｕｄｅａｕ’ｓＭｅｇａＭｅｍｏｒｙ）的训练，在那里他们 训练学员如何把看似无关的事物作视觉联想：把客人点的咖啡和他的衣着、
领带等联想在一起，比方说点蓝山咖啡的这位小姐正好有个特征是戴蓝框眼 镜。而大部分的经理会用更简单的方法解决问题，比方说规定某种咖啡要用 某种特征的杯子，这样服务生只要一看到杯子，就知道这位客人喝哪种咖啡，
续杯时就不会弄错。
常见的问题，也许只用一个微不足道的方法就可以解决。
除了咖啡店的例子之外，我们来想像一下，还有没有别的地方也可以运 用这个原理解决问题。现在我们来看另一个例子。
我家附近有两家咖啡屋。他们用一模一样的咖啡壶、咖啡豆，连服务生 都一样用的是大学生，怪的是，煮出来的咖啡却大不相同：其中一家的咖啡 一直是浓淡相宜的，另一家却时浓时淡，有时甚至烧焦，简直令人难以下咽，
您根本不知道端上来的咖啡会是什么样的味道。
这两家咖啡屋的一切设施几乎完全一样，除了一个小小的细节：质量稳 定的那家，他们的咖啡壶上有一条横的浮雕花纹，这就是简单而关键的质量 体系（ｑｕａｌｉｔｙｓｙｓｔｅｍ）的秘诀，靠着这条细细的横纹，他们可以提供品质稳 定的好咖啡。每次新的服务员到职，经理就指着这条横纹给他上课，告诉他：
“你倒咖啡时，只要发现水位在这条线以下，就要立刻煮新的一壶，要 立刻去煮，不要被任何事情耽搁。”
“万一那时候店里很忙怎么办？”
“即使一整队的芝加哥公牛刚刚打完球，全挤到这儿来也不管，还是先 煮新咖啡要紧，那怕你已经倒好一杯咖啡要端给美国总统，只要看到水位在 这条线以下，就要停下所有的事，先去煮新咖啡再说。”
接着，经理开始解释，从一个空壶、放进磨好的咖啡豆、到开始煮，总 共要花 １５ 秒钟，这样虽然会让客人多等 １５ 秒钟，但却可以避免这壶咖啡全 空之后、新咖啡未煮好前，让客人多等 ７ 分钟。
但是如果您走进另一间咖啡屋，坐下来，您可能会看到服务生伸手拿咖 啡壶却发现里面是空的，于是您得等上 ７ 分钟。有时候，服务生为了让客人 少等些时候，就会看看从咖啡机滴到壶里的已经煮好的咖啡，如果能凑成一 杯的话，就把这杯倒给您。但是好的咖啡不是这样煮的，应该等到这一泡咖 啡完全从咖啡机里滴到壶中，热水和咖啡的混合比例才会恰到好处，如果太 早把壶内的咖啡倒出来喝，就会太浓而难以入口，而后段的咖啡又太淡没有 味道。这就是这间咖啡屋质量不稳定的原因。所以有时候倒出来的咖啡，虽 然看起来很像咖啡，味道却是咖啡渣加白开水，有时候喝到很正常的咖啡，
有时候咖啡竟煮焦了——为了快点煮好咖啡，咖啡机内只放了一杯份量的咖 啡和水，由于水太少，加热器不容易调到适当的火力，结果咖啡就焦了。
这两家咖啡屋唯一不同的是，一家等到壶内的咖啡全空了才再煮新的，
一家却是壶内的咖啡到了低水位时就再煮新的一壶。两家的作业方式几乎完 全一样，就只有这点小小的差异，结果竟然如此天差地远，而且这和人员的 技术毫无关系。
我举咖啡屋的例子，当然是因为这个原理和软件开发很有关连。
如果我问您，软件开发过程中，正确的除错时机是什么，您会怎么说？
等到所有的功能开发完毕后再一起测试、除错，或是一发现有错误就立刻除 掉它，或是无所谓，反正花的时间都是一样的。
如果您认为何时除错都一样的话，那可就错了。这就像咖啡屋经理误以 为什么时候煮新的咖啡都无所谓，是一样的错误观念。对于项目经理而言，
最坏的情况莫过于被错误整得团团转，根本无法追求项目目标；如果您想要 控制好项目的发展，最好是不要有任何的错虫，忽略了这个目标就等于是注 定 失 败 （ 我 在 《 零 错 误 程 序 》 一 书 中 有 详 细 的 说 明 ） 。 当 我 刚 加 入 ＭｉｃｒｏｓｏｆｔＥｘｃｅｌ 工作小组时，他们都喜欢把错虫留到后头再来清除，我指出 这种作法可能带来的种种问题，最糟的一个结果是，到时候会无法决定产品 究竟可不可以推出。因为实在太难估算一个错虫要多少时间去把它逮到、消 灭，再说，除错的动作可能带来新的潜在错虫，这是测试小组无法确定的。
如果只管开发，把错虫留到最后再来解决，会让项目的完成比率被高估。
看起来好像已经完成开发的项目，高层主管却惊异地发现还要用六个月的时 间除错，而只有真正在拼命除错的程序设计师才晓得为什么，因为到处都是 错虫，这个产品不能推出。
在好几项软件因为错虫太多而不得不宣告失败之后，微软决定好好自我 检讨一番，以下是这次检讨的摘要：
◆错虫愈晚清除，时间花得愈多。毕竟，您得知道程序是怎么写的，才 能判断那里出了错虫；刚写完的程序记忆犹新，一年前写的程序可能早就忘 了。
◆在开发的过程就立即除虫，可以让您早些学到经验，然后就不会再犯 同样的错误；相反地，如果到了项目后期才发现，您可能已经犯过多次同样 的错误而不自知。
◆发现错虫而立即除错是一种缓冲器，提醒那些讲求快速而不够谨慎的 程序设计师，以后多加小心。如果您坚持错虫全都清除了才能开发新的功能，
就可以防止所有的程序处于半完成状态，因为错虫太多而使项目延误乃至无 法推出；相反地，如果您允许错虫的存在，等于是埋下了项目失控的地雷，
最后看似完成的项目，其实已经失控。
◆若能保持没有任何错虫，您就能比较准确估出项目的完成时间。不必 猜测 ３２ 项功能和 １７４２ 个错虫共要花费多少时间，只要估算 ３２ 项功能的工作 时间就行了。更重要的时，万一到时候有些功能做不完，您可以做多少算多 少，因为软件一直保持在无错误状态。我经常提醒每一位程序设计师，假若 您发现了错虫，而不打算立刻除掉它，请想想微软的惨痛教训。从别人的经 验中学习比较上算，要不然您想自己走一遍错误的道路吗？
一发现错虫就立即清除掉，别拖延。
无法忍受的慢
在微软，有些小组把“错虫”的传统意义扩大解释，包括产品的性能缺陷也算是一种错误；例 如软件的执行速度太慢了，即使所有的功能在逻辑上都是正确的，仍然被认为是一种错虫。
如果他们有确实采取“一有错误、立即更正”的策略，他们就得事先定义何谓“无法忍受的慢”，
也就是必须早点定出质量规范指导，这样的话，程序设计师一开始就知道标准是什么，免得到时候又 得重写部分程序代码。
这样做的缺点是程序设计师可能过度追求速度而写出很复杂的程序，因为在写完之前他无法知 道整体的执行效率会如何，有时候会品质过高，不过一般来说这种缺点是很容易被发现并改正的。
程序设计师应该把找错虫当成一件很重大的事，必须立即采取相应的行 动，不为任何理由而耽误，就像咖啡壶里的水位一般。要求错虫随时发现随 时改，等于是在开发过程中引进一个小小的质量管理机制，多方的防微杜渐，
保护产品的正确性，这种策略还有其他的好处：
◆以事实向程序设计师耳提面命，错虫是一件严重的事情，不可轻视忽 略，也无法逃避，还是勇敢面对它、尽早解决它最好。
◆自己的错虫，自己负责清除。不该是小心翼翼的人去帮助散漫随便的 人收拾残局。老是出错虫的程序设计师，会因为必须清除错虫而十分辛苦，
而没有错虫的程序设计师则进度稳定，这样才公平。一方面也是鼓励程序设 计师，要非常小心谨慎，一个错虫的代价常常是很高昂的。
◆如果一发现错虫就立刻清除，就不会漏掉重要的错虫，也不会到头来 赫然发现好长一串错误清单，以致到了期限前才发现项目的延误。也就是说，
打击恶魔要趁早，趁它还没有长大到无法收拾以前就把它消灭掉。
◆最后，也是最重要的一点，如果您要求程序出现错虫时立刻清除，那 么程序设计师的功力高下便可立见分晓，如果有人的进度一直落后，这等于 是警告您——他需要加强训练了。
软件开发过程中，有非常多的小事情会影响整体项目进行的顺利与否，
以及产品的品质，绝对不可因为事情“小”就不予重视。咖啡壶上的那一条 小小横线就是例子，您可以看出来它的影响有多大。您可以想出更多让项目 顺利进行的方法，抓对要点的小小改变可以带来大效益，好好运用这个原理，
您会受用无穷。
妥善运用可以促进开发成效的策略性工作方式。
电子邮件的陷阱
ｅ－ｍａｉｌ 实在是个很棒的工具，我简直无法想像没有它的话，工作效率会变成什么样子。但是我 不得不说，水能载舟亦能覆舟，如果 ｅ－ｍａｉｌ 被不当使用，它也会伤害生产力。
我常发现新进的程序设计师喜欢让 ｅ－ｍａｉｌ 打断他们的工作，我不是指他们发了太多的 ｅ－ｍａｉｌ，
而是只要有新的 ｅ－ｍａｉｌ 进来，他们就停下手边的工作，看看有什么新鲜大事发生了。新进人员一般不 会有太多 ｅ－ｍａｉｌ 必须回复，大部分的 ｅ－ｍａｉｌ 都是被动性的信息，像微软股票的收盘价、同业的重大 讯息、当天的头条要闻等等。
新进人员常常每隔 ５ 分钟就看看 ｅ－ｍａｉｌ 信箱，这样他们一天下来可能一件事也做不成，因为写 程序的工作是无法分割成 ｎ 个 ５ 分钟的片段去完成的。为了解决这个问题，我只能不断告诫新进人员，
回复 ｅ－ｍａｉｌ 要分批做，不需要实时就做：早上一进公司时看、中午休息时看或是下班前看一下，都可 以。ｅ－ｍａｉｌ 的目的就是要让程序设计师思绪不被打断，所以不必有事没事就瞧瞧它。
每一位程序设计师看的信息数量都是相同的，这是固定的。您可以把 ｅ－ｍａｉｌ 处理得很有效率，
也可以让工作进行得更有效率。
学习前人的经验
我经常用很多例子，向程序设计师或主管们说明策略性工作方式的重 要，小小的要领可以带来重大的益处，有些人总是不相信，他们认为工作方 式是拐杖：“你是在欺骗那些人去倚赖经验，一旦他们换个角色，他们就没 有学习能力了。”
由于我深信策略性工作方式的好处，故而我也非常在乎这些人的反应。
我相信心存怀疑的人在读完本书之后，也会迫不及待地想要运用更好的技巧 来改进工作效能。我认为本书和书中的经验法则并不会阻碍一个人的学习潜 力。
最美妙的是，如果有完整设计的工作方式，任何小组成员（不论他是新 进人员或由他组调来的人）都能立刻用最有效的方式工作，不必费神去了解 或摸索这种工作方式背后的意义。我的建议是，对于每一项工作方式都详细 解释它的用意，您为什么如此规定，您期望组员做到什么。适当的时候，组 员自然会明白并感激您的巧妙安排，而且更服膺这些道理，甚至自己也开始 思考如何改进工作效能。因此，您应该鼓励您的团队成员用心了解与改进工 作方式。
不要把策略性工作方式当作训练的教条，应该向组员解释这些工作方式 的内涵与用意。
好方法要让大家分享
设计完善的工作方式是很有价值的，因为它很自然地促使人们做对产品 最有贡献的事情。策略也是非常重要的，因为它是许多经验和思维浓缩而成 的计划，让每个人都了解它，并且付诸行动。将这样的策略或方法集合起来，
能够让个人的生产力和工作质量提升到更高的境界。
身为一位主管，您应该鼓励组员提出改进工作效能的建议。以我来说，
我对于软件的第一优先考虑点是没有错虫，当然，我们都知道这是说来容易 做来难的。即便如此，我还是认真观察那些较少出错虫的程序设计师，研究 他们为什么比较能避免错误，我的结论是他们比较懂得在容易出错虫的地方 特别小心，懂得避开程序设计时常见的盲点或陷阱，也比较懂得用有效的方 法抓虫。换言之，他们懂得写出无错虫程序的方法。
为了鼓励程序设计师学到避免错虫的策略，每次他们在追查错误原因 时，我都会问这两个问题：
如何避免这个错误？
我如何以更简单（或自动）的方法发现这个错误？
如果程序设计师经常思考这两个问题的答案，他渐渐就能学会更高明的 程序设计技巧。有些程序设计师是同样的错误一再地出现，显然就是主管没 有鼓励他认真思考这两个问题，从错误中汲取教训。
当然，您的询问是否切中要害，也引导着组员的思考方法是不是问题的 要害。您可以经常问自己这类的问题：
为什么进度总是一再落后？
有什么办法可以避免将来再发生进度落后？
虽然这两个问题很类似，都在问进度，但我想您的答案不会相同吧。第 一个问题着重在原因：互赖性的工作太多，工具太难用，老板是个白痴，老 在阻碍工作的推动等等。第二个问题在问未来的预防方法：减少互赖性的工 作，请购更好的工具，与老板加强沟通，争取他的配合等等。这两个问题的 方向不同，第一个是探究原因，第二个是未来的改进方法，因此，这两个问 题 的 回 答 也 一 定 不 同 ， 第 一 个 导 引 出 抱 怨 ， 第 二 个 才 导 引 出 解 决 方 法
（ａｔｔａｃｋｐｌａｎ）。
即使您的问题非常好，完全正中核心，也未必能导出正确的策略。项目 的目标会因为定义精确而获得更好的效果，问题也是一样，问得愈精确、问 题愈有力，让我们来看看这个问题：
如何保持每次都如期完成软件？
有些主管问这个问题的后果是逼迫组员加班；有些则是以分红或主管掏 腰包买晚餐，或是安排一场热门的夜场电影外加爆米花（别只管笑，真有这 样的事儿）来贿赂组员加班。
但是，主管可以把问题问得更精确、更有建设性：
如何在不加班的前提下，而能如期交差？
这回的答案可不能一样了，因为逼迫加班和利诱加班都被排除在外，既 然不能增加工作时数，于是主管不得不想法子加强效率，去找寻更有效的解 决方案。为了不加班，也许得雇用更多的人手，这是解决方案之一，但公司 绝对不会喜欢，至少这个方案会摆在最后再来考虑。这样吧，我干脆再把问 题说得更精确些：
如何在不加班、也不增加人手的前提下，依然如期完成软件？
这可就真的迫使主管来点真正有创意的思考和认真检讨工作本身值得改 进的地方了。也许主管不认为所有的程序一定要自行开发，他可以雇用一位 短期的顾问，或是运用公司内别的小组已完成的程序代码，或是买一套文件 完整的函数库，这都能够大幅减少开发程序的时间。也许，可以把产品中较 无价值的功能特色从目标中删除，这也是个办法。
理想的问题
您读完本书之后，会发现不必每周工作 ８０ 小时就能如期完成项目的方法还真是不少。当您用自 问自答的方式来引导策略性思考时，请不要忘了第 １ 章所提的重点：“我到底要完成什么？”没有一 位主管喜欢自己的组员成天加班，事实上，大部分的主管都希望大家能在愈短的时间内完成愈多的任 务。要提出最佳问题最简单的技巧是：想像一下您理想中的项目应该如何运作，然后在您的问题中反 映您的理想。您理想中的项目，应该是对进程估计准确、每一个里程碑都准时到达、没有人需要加班、
每个人都乐于工作，不是吗？有太多值得自我检讨的问题，同一个问题有太多问法，您必须记得，在 问题中反映您所希望的理想项目，就比较容易得到接近理想的答案。
我们要强调的是，愈精确的问题，愈能促使人们朝向更接近理想的答案思考，剔除那些不够好 的答案，因为第一个想到的往往是最简单、不够理想的解决方案，我们不能这样就算了。一次比一次 更精确的问题，可以刺激思考过程，激发出更有创意的答案。
提出精确详尽的问题，可以引导出真正有效的策略性工作方式，帮助项 目目标顺利完成。
不要死守规则
当您提出并推动策略时，同时也要提醒开发团队，不见得要 １００％地遵 循策略，最重要的是灵活运用。做事情要用脑筋思考，理性判断，而不是盲 目地人云亦云，一味地死守规则。规则也有不太适用的时候。
有一项几乎是铁定的程序设计策略，就是不要使用 ｇｏｔｏ。但是，有经验 的程序设计师一般都认为，在某些特殊情况下——大部分是复杂的错误处 理，用 ｇｏｔｏ 反而使程序代码清楚明晰。如果我看到程序设计师在写错误处理 程序时，极力避免使用 ｇｏｔｏ，我通常会拿着程序代码和他一起讨论，我会问 道：
“你有没有想过用 ｇｏｔｏ 来写这段程序？”
“什么？当然没有！ｇｏｔｏ 是程序设计的祸源，会使程序既不稳定又难读 懂，只有低能的程序设计师才用 ｇｏｔｏ 吧。”
我解释道：“嗯，说得对，不过在某些情况下 ｇｏｔｏ 是合理的，复杂的错 误处理就是。让我们拿用 ｇｏｔｏ 做的程序和你的程序作个比较，你觉得哪一个 的程序代码比较清楚？”我拿用 ｇｏｔｏ 做错误处理的程序代码给他看。
通常程序设计师都会不太情愿地承认是 ｇｏｔｏ 版比较好。
“那么，你将来打算用哪种方式来写程序？”
“我自己的，因为它不用 ｇｏｔｏ。”
“等等，我以为你刚才同意了 ｇｏｔｏ 是比较好的方式，程序会比较好读，
不是吗？”
“它是比较好读，但是用 ｇｏｔｏ 的话，编译器会无法产生最优的执行码。”
“让我们假设你的论点是对的，编译器所产生的执行码的确差些。你想，
执行这一段程序机率大不大呢？”
“很少会执行到，我想，因为它是错误处理。”
“既然不常执行到，那么对于这段程序而言，执行速度和程序代码的可 读性，那个比较重要呢？”
“程序代码的可读性。”
“所以，哪种方式是比较符合项目的优先考虑的顺序呢？”
这时候通常会有一段较长的沉默。然后程序设计师终于勉强吐出了一句 痛苦的抗议：
“但是，用 ｇｏｔｏ 不好嘛。”
首先我得说明，该用 ｇｏｔｏ 的情况其实是很少的，大部分的时候只要一看 到 ｇｏｔｏ 我就有点紧张，生怕这里有问题。我虽不会对所有的 ｇｏｔｏ 去之而后 快，但我个人绝不赞成用 ｇｏｔｏ；大部分的 ｇｏｔｏ 都是散漫的程序设计师，一 边哼哼唱唱、一边在键盘上随意敲打的低劣程序。然而，我虽反对使用 ｇｏｔｏ，
我更反对的是对规则盲从，产品才是最重要的。
这就是策略性工作方式的主要缺点，规则太明确了，有时候反而让组员 把它视为不容打破的定律，而不去活用策略。僵化地死守策略无异于做傻事。
我知道学校里的老师在教程序语言时强调不要用 ｇｏｔｏ，基本上是出于善 意；他们是对的，但我希望程序设计师必须明白，尽量少用 ｇｏｔｏ 并不表示绝 对不要用。我更希望学校里会示范少数应该使用 ｇｏｔｏ 的时机，证明在那些情 况下使用 ｇｏｔｏ 是合理的，因为不该用 ｇｏｔｏ 的实例已经看得太多了。我想这 是因为很多老师自己主张绝对不该使用 ｇｏｔｏ，在教学时自然特别强调 ｇｏｔｏ 不可用，只要一看到学生的作业中有 ｇｏｔｏ 就认为这是可怕的程序，使得很多 毕业出来的程序设计师畏 ｇｏｔｏ 如蛇蝎，就好像电影中只要有裸露镜头就判定 这是不道德的一样。
程序设计中，只有很少数的策略应该被视为规则，规则该被遵循，但不 是死守，主管必须教育组员明白这一点，并教导组员应该如何灵活运用策略，
否则属下若是只晓得盲从，就是主管的危机。策略不是死的定律，要灵活运 用，不要死守，这是采用任何策略时都应该注意的，当然包括本书中所提的 所有策略。
策略不是死的定律，要把它当作指导原则来活用。大部分的时候都应该 遵循，但也有例外的时候。
给我看原始程序代码
关于是否该用 ｇｏｔｏ，教科书、参考书、杂志等已经都讲烂了。所有关于赞成和反对使用 ｇｏｔｏ 的文章中，麦康奈尔（ＭｃＣｏｎｎｅｌｌ）所著的《代码完成》（ＣｏｄｅＣｏｍｐｌｅｔｅ）一书中第 １６ 章可以说是最 完整的了。他除了举出许多用 ｇｏｔｏ 确实可以增加执行效率的实例之外，更进一步告诉读者他赞同 ｇｏｔｏ 的理由，也证明了部分反对 ｇｏｔｏ 的理由是太牵强了些；麦康奈尔也整理出很多参考资料，包括爱兹 格・迪杰克斯拉（ＥｄｓｇｅｒＤｉｊｋｓｔｒａ）引发这场世纪大论战的信件，以及大师唐纳・克努斯（ＤｏｎａｌｄＫｎｕｔｈ）
那篇举证繁多的“用 ｇｏｔｏ 的结构化程序设计”（ＳｔｒｕｃｔｕｒｅｄＰｒｏｇｒａｍｍｉｎｇｗｉｔｈｇｏｔｏＳｔａｔｅｍｅｎｔｓ）。正 如麦康奈尔所言，虽然是否使用 ｇｏｔｏ 的千古难题至今依然在程序设计师的生活中一再上演，但教科书 上的争论，也都还是 ２０ 年前的东西吵来吵去罢了。
反馈回路
电子工程师会利用一种“反馈回路”（ｆｅｅｄｂａｃｋｌｏｏｐ）的电路系统，将 输出的讯号再当成输入讯号，反馈给系统本身。图标如下：
由于输出不断反馈给输入，这样的电路系统会产生两种结果：反馈讯号 与输入讯号相加，称为正反馈，输出讯号愈强，得到的反馈愈强，因而导致 输出再放大、再放大；第二种结果正好相反，称作负反馈，反馈讯号会与输 入讯号相减，不断相减的结果，最后会达成一个较稳定的输出值。从这样相 当简单的描述看来，似乎正反馈很了不起，因为它会自我加强能量，而负反 馈则不好，因为无论它输出的起始值多大，最后都会缩小。事实呢？正好相 反，负反馈远比正回馈有用。
您在听演讲时，可曾听过麦克风尖锐的叫声？足以吓醒所有的瞌睡虫，
这就是正反馈的现象（译注又称作“反受放大”，在唱 ＫＴＶ 时麦克风绝对不 可指向喇叭，就是这个道理）。麦克风除了接收演讲者的声音外，还接收到 喇叭的放音，不断地反馈循环，最后使喇叭负荷超载，发出尖锐刺耳的声音，
而且频率还愈来愈高。负荷超载（ｏｖｅｒｌｏａｄ）就是正反馈常有的问题。
相反地，负反馈则是以输出来抑制回路未来的输出。其实我们开车就是 一种负反馈的系统，先踩点油门，慢慢加油，发现太快了就带点刹车来减速，
如果刚起步就是油门一踩到底，那就得重踩刹车才能达到正确的速度。也就 是说，输出愈强，需要负反馈的抑制力就要愈大，但也不是让反馈的力量决 定一切，负反馈只是调整用的，好让输出维持稳定。停车只是刹车踏板的作 用之一，让车速保持稳定也是刹车（负反馈）的作用。
除了电子工程，您还可以发现有很多各式各样的反馈回路，包括人际关 系和软件开发。有些反馈回路是刻意设计的，有些则是无意间自然形成的，
不论是有意无意的回馈，都有助于加强对项目的控制，所以，您必须明白反 馈回路的道理，并且善用它。
错虫，就是程序设计的输出产物之一，我们把软件开发当成电路系统，
如果有个负回路可以让错虫导回去抵销下一个潜在的错虫，那有多好！我们 前面谈过的立即除错就是一个负回路的观念：
要求程序设计师一发现错虫就立即清除。
如果一发现错虫就立即消灭它，它就没有机会影响到程序设计师的心 情，大家可以高枕无忧地继续做下一项工作。但是如果有个伤脑筋的扩散型 错虫，清了这里却错了那里，再去修改那里却发现还有某处情况不妙，就得 坚持要求这位程序设计师除错到底，把所有的错虫都确实清除干净了，才可 以继续开发工作，否则会造成野火燎原之势，错虫一发不可收拾。错虫愈多 的程序设计师，愈要加强督促。“立即除错”就是一个最好的负反馈系统，
让软件永远保持无错状态。当然，还有我们前面提过的种种立即除错的好处
——刚生成的错虫比较容易清除、让程序设计师学习速度加倍、更能准确估 算项目的完成日期等等。
反馈回路有利亦有弊，运用不当的话也是会有问题的。记得我在第 １ 章 中谈过的实例吧，那个项目经理总是要求他的组员写进度报告、开进度检讨 会、再做后续报告，没完没了。这位主管是希望藉此获得项目进度的信息，
很不幸，他的负回路却阻碍了他真正需要的产出，他想了解组员对于如何解 决问题的见解，可惜方法不对，他要求组员写报告，结果让组员心生反感，
根本不想发表意见，他的制度使人噤声——讲得愈多，你必须写的报告就愈 长，没有人想写报告，所以只好闭上嘴。这正所谓适得其反。
负反馈不是惩罚
惩罚是一种心理上的负向强化作用（ｎｅｇａｔｉｖｅ ｒｅｉｎｆｏｒｃｅｍｅｎｔ），惩罚是对员工责骂、训斥与 威胁，就像鞭打马匹使它服从主人的命令。发现有一位组员进度落后了，不得了！叫过来骂一顿，这 就等于是给了他一帖重剂量药物，逼使他以后不敢对进程掉以轻心。
这种管理手段是该受谴责的，我绝对不鼓励任何人这么做。想一想我们前面刚讨论过的负回馈 的观念，要求程序设计师立即除错，但程序设计师不需要对除错感到焦虑不安。由于立即除错的策略，
他必须花费好几天的时间解决这个问题，当然不是他所喜欢的结果，但主管不应该让他因此而感受到 威胁。我们希望任何事情都很自然，没有必要加重组员的苦恼，绝不是强调谁是老板谁是奴才，谁必 须服从谁。
在微软曾经有几位主管，每次一遇到项目进行不顺利，就把组员叫出来骂，说他们是最差劲的 程序设计师，不配自称是微软的程序设计师，以及等等之类的无聊话。我不能确定这几位主管究竟用 意何在，但是如果他们的目的是让组员工作更努力的话，那他们的方法可就大错特错了。我相信您完 全可以想像，这种责骂只会激起组员心中的愤恨、羞恼和沮丧。更糟的是，就我所知这些项目的问题 事实上都出在管理方面，目标不够明确或是野心太大，这些项目的程序设计师只是倒霉遇上了差劲的 主管，其实他们的能力并不比公司内其他的程序设计师差，因此责骂他们只会让项目更糟，绝对没有 改善的效果。
您必须小心注意，别设置了不当的负回路系统，例如以程序新增的行数、
或新加入程序的数目来决定组员的奖金，把程序改好则不记入功劳，那么，
程序员肯定只爱写拼拼凑凑的初稿，程序不求精巧，而且不愿认真改善现有 的程序。您原本希望奖励的是生产效率，结果却造成公司里大而无当的拼凑 程序到处泛滥。
我希望您能从以上的讨论中，体会到两点原则，第一，当您设计一个新 系统时，利用负回路的观念来帮助项目进行顺利；第二，要考虑这种回馈对 员工的长期影响，确定不会造成不良的副作用。
在您的软件开发活动中，小心谨慎地运用负回路的观念，让项目顺利进 行；但务必要注意避免反馈回路的不良副作用。
愈简单愈好
最后，请您确定您的策略性工作方式够简单明白，让 人容易了解和遵循。
请回想一下我刚才举过的实例：用纸笔写的稿子、咖啡的浓度、整批阅 读 ｅ－ｍａｉｌ、立即除错，这些都是细微的小事，不会对作业流程发生重大的影 响。
人都希望用简单的方式解决复杂又耗时的问题，因为人们常常被工作之 外的程序性事情绊住。如果问一位程序设计师：“如何避免错虫？”这个简
