按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
啡要端给美国总统，只要看到水位在这条线以下，就要停
下所有的事，先去煮新咖啡再说。”
接着，经理开始解释，从一个空壶、放进磨好的咖啡
豆、到开始煮，总共要花1 5秒钟，这样虽然会让客人多等
1 5秒钟，但却可以避免这壶咖啡全空之后、新咖啡未煮好
前，让客人多等7分钟。
但是如果您走进另一间咖啡屋，坐下来，您可能会
看到服务生伸手拿咖啡壶却发现里面是空的，于是您得
等上7分钟。有时候，服务生为了让客人少等些时候，就
会看看从咖啡机滴到壶里的已经煮好的咖啡，如果能凑
成一杯的话，就把这杯倒给您。但是好的咖啡不是这样
煮的，应该等到这一泡咖啡完全从咖啡机里滴到壶中，
热水和咖啡的混合比例才会恰到好处，如果太早把壶内
的咖啡倒出来喝，就会太浓而难以入口，而后段的咖啡
又太淡没有味道。这就是这间咖啡屋质量不稳定的原因。
所以有时候倒出来的咖啡，虽然看起来很像咖啡，味道
47
微软研发·致胜策略
策略性的作业方式下载
却是咖啡渣加白开水，有时候喝到很正常的咖啡，有时
候咖啡竟煮焦了—为了快点煮好咖啡，咖啡机内只放
了一杯份量的咖啡和水，由于水太少，加热器不容易调
到适当的火力，结果咖啡就焦了。
这两家咖啡屋唯一不同的是，一家等到壶内的咖啡全
空了才再煮新的，一家却是壶内的咖啡到了低水位时就再
煮新的一壶。两家的作业方式几乎完全一样，就只有这点
小小的差异，结果竟然如此天差地远，而且这和人员的技
术毫无关系。
我举咖啡屋的例子，当然是因为这个原理和软件开发
很有关连。
如果我问您，软件开发过程中，正确的除错时机是什
么； 您会怎么说？等到所有的功能开发完毕后再一起测试、
除错，或是一发现有错误就立刻除掉它，或是无所谓，反
正花的时间都是一样的。
如果您认为何时除错都一样的话，那可就错了。这就
像咖啡屋经理误以为什么时候煮新的咖啡都无所谓，是一
样的错误观念。对于项目经理而言，最坏的情况莫过于被
错误整得团团转，根本无法追求项目目标；如果您想要控
制好项目的发展，最好是不要有任何的错虫，忽略了这个
48
微软研发
致胜策略下载
目标就等于是注定失败（我在《零错误程序》一书中有详
细的说明）。当我刚加入Microsoft Excel 工作小组时，他
们都喜欢把错虫留到后头再来清除，我指出这种作法可能
带来的种种问题，最糟的一个结果是，到时候会无法决定
产品究竟可不可以推出。因为实在太难估算一个错虫要多
少时间去把它逮到、消灭，再说，除错的动作可能带来新
的潜在错虫，这是测试小组无法确定的。
如果只管开发，把错虫留到最后再来解决，会让项目
的完成比率被高估。看起来好像已经完成开发的项目，高
层主管却惊异地发现还要用六个月的时间除错，而只有真
正在拼命除错的程序设计师才晓得为什么，因为到处都是
错虫，这个产品不能推出。
在好几项软件因为错虫太多而不得不宣告失败之后，
微软决定好好自我检讨一番，以下是这次检讨的摘要：
◆ 错虫愈晚清除，时间花得愈多。毕竟，您得知道程
序是怎么写的，才能判断那里出了错虫；刚写完的
程序记忆犹新，一年前写的程序可能早就忘了。
◆ 在开发的过程就立即除虫，可以让您早些学到经验，
然后就不会再犯同样的错误；相反地，如果到了项
目后期才发现，您可能已经犯过多次同样的错误而
49
微软研发·致胜策略
策略性的作业方式下载
不自知。
◆ 发现错虫而立即除错是一种缓冲器，提醒那些讲求
快速而不够谨慎的程序设计师，以后多加小心。如
果您坚持错虫全都清除了才能开发新的功能，就可
以防止所有的程序处于半完成状态，因为错虫太多
而使项目延误乃至无法推出；相反地，如果您允许
错虫的存在，等于是埋下了项目失控的地雷，最后
看似完成的项目，其实已经失控。
◆若能保持没有任何错虫，您就能比较准确估出项目
的完成时间。不必猜测3 2项功能和1 742个错虫共要
花费多少时间，只要估算3 2项功能的工作时间就行了。
更重要的时，万一到时候有些功能做不完，您可以做
多少算多少，因为软件一直保持在无错误状态。
我经常提醒每一位程序设计师，假若您发现了错虫，
而不打算立刻除掉它，请想想微软的惨痛教训。从别人的经
验中学习比较上算，要不然您想自己走一遍错误的道路吗？
一发现错虫就立即清除掉，别拖延。
50
微软研发
致胜策略下载
无法忍受的慢
在微软，有些小组把“错虫”的传统意义扩大解释，
包括产品的性能缺陷也算是一种错误；例如软件的执行速
度太慢了，即使所有的功能在逻辑上都是正确的，仍然被
认为是一种错虫。
如果他们有确实采取“一有错误、立即更正”的策略，
他们就得事先定义何谓“无法忍受的慢”，也就是必须早
点定出质量规范指导，这样的话，程序设计师一开始就知
道标准是什么，免得到时候又得重写部分程序代码。
这样做的缺点是程序设计师可能过度追求速度而写出
很复杂的程序，因为在写完之前他无法知道整体的执行效
率会如何，有时候会品质过高，不过一般来说这种缺点是
很容易被发现并改正的。
程序设计师应该把找错虫当成一件很重大的事，必须
立即采取相应的行动，不为任何理由而耽误，就像咖啡壶
里的水位一般。要求错虫随时发现随时改，等于是在开发
过程中引进一个小小的质量管理机制，多方的防微杜渐，
保护产品的正确性，这种策略还有其他的好处：
◆ 以事实向程序设计师耳提面命，错虫是一件严重的
51
微软研发·致胜策略
策略性的作业方式下载
事情，不可轻视忽略，也无法逃避，还是勇敢面对
它、尽早解决它最好。
◆ 自己的错虫，自己负责清除。不该是小心翼翼的人
去帮助散漫随便的人收拾残局。老是出错虫的程序
设计师，会因为必须清除错虫而十分辛苦，而没有
错虫的程序设计师则进度稳定，这样才公平。一方
面也是鼓励程序设计师，要非常小心谨慎，一个错
虫的代价常常是很高昂的。
◆ 如果一发现错虫就立刻清除，就不会漏掉重要的
错虫，也不会到头来赫然发现好长一串错误清单，
以致到了期限前才发现项目的延误。也就是说，打
击恶魔要趁早，趁它还没有长大到无法收拾以前就
把它消灭掉。
◆ 最后，也是最重要的一点，如果您要求程序出现
错虫时立刻清除，那么程序设计师的功力高下便可
立见分晓，如果有人的进度一直落后，这等于是警
告您—他需要加强训练了。
软件开发过程中，有非常多的小事情会影响整体项目
进行的顺利与否，以及产品的品质，绝对不可因为事情
“小”就不予重视。咖啡壶上的那一条小小横线就是例子，
52
微软研发
致胜策略下载
您可以看出来它的影响有多大。您可以想出更多让项目顺
利进行的方法，抓对要点的小小改变可以带来大效益，好
好运用这个原理，您会受用无穷。
妥善运用可以促进开发成效的策略性工作方式。
电子邮件的陷阱
e…mail 实在是个很棒的工具，我简直无法想像没有它
的话，工作效率会变成什么样子。但是我不得不说，水能
载舟亦能覆舟，如果e…mail 被不当使用，它也会伤害生产
力。
我常发现新进的程序设计师喜欢让e…mail 打断他们
的工作，我不是指他们发了太多的e … m a i l，而是只要有新
的e…mail 进来，他们就停下手边的工作，看看有什么新鲜
大事发生了。新进人员一般不会有太多e…mail 必须回复，
大部分的e…mail 都是被动性的信息，像微软股票的收盘价、
同业的重大讯息、当天的头条要闻等等。
新进人员常常每隔5 分钟就看看e…mail 信箱，这样
53
微软研发·致胜策略
策略性的作业方式下载
他们一天下来可能一件事也做不成，因为写程序的工作是
无法分割成n个5 分钟的片段去完成的。为了解决这个问
题，我只能不断告诫新进人员，回复e…mail 要分批做，不
需要实时就做：早上一进公司时看、中午休息时看或是下
班前看一下，都可以。e…mail 的目的就是要让程序设计师
思绪不被打断，所以不必有事没事就瞧瞧它。
每一位程序设计师看的信息数量都是相同的，这是固
定的。您可以把e…mail 处理得很有效率，也可以让工作进
行得更有效率。
学习前人的经验
我经常用很多例子，向程序设计师或主管们说明策略
性工作方式的重要，小小的要领可以带来重大的益处，有
些人总是不相信，他们认为工作方式是拐杖：“你是在欺
骗那些人去倚赖经验，一旦他们换个角色，他们就没有学
习能力了。”
由于我深信策略性工作方式的好处，故而我也非常
在乎这些人的反应。我相信心存怀疑的人在读完本书之
后，也会迫不及待地想要运用更好的技巧来改进工作效
能。我认为本书和书中的经验法则并不会阻碍一个人的
54
微软研发
致胜策略下载
学习潜力。
最美妙的是，如果有完整设计的工作方式，任何小组
成员（不论他是新进人员或由他组调来的人） 都能立刻用最
有效的方式工作，不必费神去了解或摸索这种工作方式背
后的意义。我的建议是，对于每一项工作方式都详细解释
它的用意，您为什么如此规定，您期望组员做到什么。适
当的时候，组员自然会明白并感激您的巧妙安排，而且更
服膺这些道理，甚至自己也开始思考如何改进工作效能。
因此，您应该鼓励您的团队成员用心了解与改进工作方式。
不要把策略性工作方式当作训练的教条，应该向
组员解释这些工作方式的内涵与用意。
好方法要让大家分享
设计完善的工作方式是很有价值的，因为它很自然地
促使人们做对产品最有贡献的事情。策略也是非常重要
的，因为它是许多经验和思维浓缩而成的计划，让每个人
都了解它，并且付诸行动。将这样的策略或方法集合起来，
55
微软研发·致胜策略
策略性的作业方式下载
能够让个人的生产力和工作质量提升到更高的境界。
身为一位主管，您应该鼓励组员提出改进工作效能的
建议。以我来说，我对于软件的第一优先考虑点是没有错
虫，当然，我们都知道这是说来容易做来难的。即便如此，
我还是认真观察那些较少出错虫的程序设计师，研究他们
为什么比较能避免错误，我的结论是他们比较懂得在容易
出错虫的地方特别小心，懂得避开程序设计时常见的盲点
或陷阱，也比较懂得用有效的方法抓虫。换言之，他们懂
得写出无错虫程序的方法。
为了鼓励程序设计师学到避免错虫的策略，每次他们
在追查错误原因时，我都会问这两个问题：
如何避免这个错误？
我如何以更简单（或自动） 的方法发现这个
错误？
如果程序设计师经常思考这两个问题的答案，他渐渐
就能学会更高明的程序设计技巧。有些程序设计师是同样
的错误一再地出现，显然就是主管没有鼓励他认真思考这
两个问题，从错误中汲取教训。
当然，您的询问是否切中要害，也引导着组员的思考
56
微软研发
致胜策略下载
方法是不是问题的要害。您可以经常问自己这类的问题：
为什么进度总是一再落后？
有什么办法可以避免将来再发生进度落后？
虽然这两个问题很类似，都在问进度，但我想您的答
案不会相同吧。第一个问题着重在原因：互赖性的工作太多，
工具太难用，老板是个白痴，老在阻碍工作的推动等等。第
二个问题在问未来的预防方法：减少互赖性的工作，请购更
好的工具，与老板加强沟通，争取他的配合等等。这两个问
题的方向不同，第一个是探究原因，第二个是未来的改进方
法，因此，这两个问题的回答也一定不同，第一个导引出抱
怨，第二个才导引出解决方法（attack plan）。
即使您的问题非常好，完全正中核心，也未必能导出
正确的策略。项目的目标会因为定义精确而获得更好的效
果，问题也是一样，问得愈精确、问题愈有力，让我们来
看看这个问题：
如何保持每次都如期完成软件？
有些主管问这个问题的后果是逼迫组员加班；有些则
是以分红或主管掏腰包买晚餐，或是安排一场热门的夜场
57
微软研发·致胜策略
策略性的作业方式下载
电影外加爆米花（别只管笑，真有这样的事儿）来贿赂组员
加班。
但是，主管可以把问题问得更精确、更有建设性：
如何在不加班的前提下，而能如期交差？
这回的答案可不能一样了，因为逼迫加班和利诱加班
都被排除在外，既然不能增加工作时数，于是主管不得不
想法子加强效率，去找寻更有效的解决方案。为了不加班，
也许得雇用更多的人手，这是解决方案之一，但公司绝对
不会喜欢，至少这个方案会摆在最后再来考虑。这样吧，
我干脆再把问题说得更精确些：
如何在不加班、也不增加人手的前提下，
依然如期完成软件？
这可就真的迫使主管来点真正有创意的思考和认真检
讨工作本身值得改进的地方了。也许主管不认为所有的程
序一定要自行开发，他可以雇用一位短期的顾问，或是运
用公司内别的小组已完成的程序代码，或是买一套文件完
整的函数库，这都能够大幅减少开发程序的时间。也许，
可以把产品中较无价值的功能特色从目标中删除，这也是
58
微软研发
致胜策略下载
个办法。
理想的问题
您读完本书之后，会发现不必每周工作8 0小时就能如
期完成项目的方法还真是不少。当您用自问自答的方式来
引导策略性思考时，请不要忘了第1章所提的重点：“我到
底要完成什么？”没有一位主管喜欢自己的组员成天加班，
事实上，大部分的主管都希望大家能在愈短的时间内完成
愈多的任务。要提出最佳问题最简单的技巧是：想像一下
您理想中的项目应该如何运作，然后在您的问题中反映您
的理想。您理想中的项目，应该是对进程估计准确、每一
个里程碑都准时到达、没有人需要加班、每个人都乐于工
作，不是吗？有太多值得自我检讨的问题，同一个问题有
太多问法，您必须记得，在问题中反映您所希望的理想项
目，就比较容易得到接近理想的答案。
我们要强调的是，愈精确的问题，愈能促使人们朝向
更接近理想的答案思考，剔除那些不够好的答案，因为第
一个想到的往往是最简单、不够理想的解决方案，我们不
能这样就算了。一次比一次更精确的问题，可以刺激思考
过程，激发出更有创意的答案。
59
微软研发·致胜策略
策略性的作业方式下载
提出精确详尽的问题，可以引导出真正有效的策
略性工作方式，帮助项目目标顺利完成。
不要死守规则
当您提出并推动策略时，同时也要提醒开发团队，不
见得要1 0 0 ％地遵循策略，最重要的是灵活运用。做事情
要用脑筋思考，理性判断，而不是盲目地人云亦云，一味
地死守规则。规则也有不太适用的时候。
有一项几乎是铁定的程序设计策略，就是不要使用
g o t o。但是，有经验的程序设计师一般都认为，在某些特
殊情况下—大部分是复杂的错误处理，用goto 反而使
程序代码清楚明晰。如果我看到程序设计师在写错误处理
程序时，极力避免使用goto，我通常会拿着程序代码和他
一起讨论，我会问道：
“你有没有想过用goto 来写这段程序？”
“什么？当然没有！goto 是程序设计的祸源，会使程
序既不稳定又难读懂，只有低能的程序设计师才用g o t o
吧。”
60
微软研发
致胜策略下载
我解释道：“嗯，说得对，不过在某些情况下goto 是
合理的，复杂的错误处理就是。让我们拿用goto 做的程
序和你的程序作个比较，你觉得哪一个的程序代码比较清
楚？”我拿用goto 做错误处理的程序代码给他看。
通常程序设计师都会不太情愿地承认是goto 版比较
好。
“那么，你将来打算用哪种方式来写程序？”
“我自己的，因为它不用goto。”
“等等，我以为你刚才同意了goto 是比较好的方式，
程序会比较好读，不是吗？”
“它是比较好读，但是用goto 的话，编译器会无法产
生最优的执行码。”
“让我们假设你的�