微软研发致胜策略-第5章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
在追查错误原因时，我都会问这两个问题：
如何避免这个错误？
我如何以更简单（或自动） 的方法发现这个
错误？
如果程序设计师经常思考这两个问题的答案，他渐渐
就能学会更高明的程序设计技巧。有些程序设计师是同样
的错误一再地出现，显然就是主管没有鼓励他认真思考这
两个问题，从错误中汲取教训。
当然，您的询问是否切中要害，也引导着组员的思考
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 的话，编译器会无法产
生最优的执行码。”
“让我们假设你的论点是对的，编译器所产生的执行
码的确差些。你想，执行这一段程序机率大不大呢？”
“很少会执行到，我想，因为它是错误处理。”
“既然不常执行到，那么对于这段程序而言，执行速
度和程序代码的可读性，那个比较重要呢？”
“程序代码的可读性。”
“所以，哪种方式是比较符合项目的优先考虑的顺序
呢？”
61
微软研发·致胜策略
策略性的作业方式下载
这时候通常会有一段较长的沉默。然后程序设计师终
于勉强吐出了一句痛苦的抗议：
“但是，用goto 不好嘛。”
首先我得说明，该用goto 的情况其实是很少的，大
部分的时候只要一看到goto 我就有点紧张，生怕这里有
问题。我虽不会对所有的goto 去之而后快，但我个人绝
不赞成用g o t o；大部分的goto 都是散漫的程序设计师，
一边哼哼唱唱、一边在键盘上随意敲打的低劣程序。然而，
我虽反对使用goto，我更反对的是对规则盲从，产品才是
最重要的。
这就是策略性工作方式的主要缺点，规则太明确了，
有时候反而让组员把它视为不容打破的定律，而不去活用
策略。僵化地死守策略无异于做傻事。
我知道学校里的老师在教程序语言时强调不要用
g o t o，基本上是出于善意；他们是对的，但我希望程序设
计师必须明白，尽量少用goto 并不表示绝对不要用。我
更希望学校里会示范少数应该使用goto 的时机，证明在
那些情况下使用goto 是合理的，因为不该用goto 的实例
已经看得太多了。我想这是因为很多老师自己主张绝对不
该使用g o t o，在教学时自然特别强调goto 不可用，只要
62
微软研发
致胜策略下载
一看到学生的作业中有goto 就认为这是可怕的程序，使
得很多毕业出来的程序设计师畏goto 如蛇蝎，就好像电
影中只要有裸露镜头就判定这是不道德的一样。
程序设计中，只有很少数的策略应该被视为规则，规
则该被遵循，但不是死守，主管必须教育组员明白这一点，
并教导组员应该如何灵活运用策略，否则属下若是只晓得
盲从，就是主管的危机。策略不是死的定律，要灵活运用，
不要死守，这是采用任何策略时都应该注意的，当然包括
本书中所提的所有策略。
策略不是死的定律，要把它当作指导原则来活用。
大部分的时候都应该遵循，但也有例外的时候。
给我看原始程序代码
关于是否该用g o t o，教科书、参考书、杂志等已经都
讲烂了。所有关于赞成和反对使用goto 的文章中，麦康
奈尔（McConnell） 所著的《代码完成》（Code plete）一
书中第16章可以说是最完整的了。他除了举出许多用goto
63
微软研发·致胜策略
策略性的作业方式下载
确实可以增加执行效率的实例之外，更进一步告诉读者他
赞同goto 的理由，也证明了部分反对goto 的理由是太牵
强了些；麦康奈尔也整理出很多参考资料，包括爱兹
格·迪杰克斯拉（Edsger Dijkstra） 引发这场世纪大论战的
信件，以及大师唐纳·克努斯（Donald Knuth） 那篇举证繁
多的“ 用goto 的结构化程序设计” （ S t r u c t u r e d
Programming with gotoStatements）。正如麦康奈尔所言，
虽然是否使用goto 的千古难题至今依然在程序设计师的
生活中一再上演，但教科书上的争论，也都还是2 0年前的
东西吵来吵去罢了。
反馈回路
电子工程师会利用一种“反馈回路” （feedback loop）
的电路系统，将输出的讯号再当成输入讯号，反馈给系统
本身。图标如下：
64
微软研发
致胜策略下载
反馈
电路系统
4 输入
1 输出
由于输出不断反馈给输入，这样的电路系统会产生两
种结果：反馈讯号与输入讯号相加，称为正反馈，输出讯
号愈强，得到的反馈愈强，因而导致输出再放大、再放
大；第二种结果正好相反，称作负反馈，反馈讯号会与输
入讯号相减，不断相减的结果，最后会达成一个较稳定的
输出值。从这样相当简单的描述看来，似乎正反馈很了不
起，因为它会自我加强能量，而负反馈则不好，因为无论
它输出的起始值多大，最后都会缩小。事实呢？正好相反，
负反馈远比正回馈有用。
您在听演讲时，可曾听过麦克风尖锐的叫声？足以吓
醒所有的瞌睡虫，这就是正反馈的现象（译注又称作“反
受放大”，在唱KTV 时麦克风绝对不可指向喇叭，就是这
个道理）。麦克风除了接收演讲者的声音外，还接收到喇
叭的放音，不断地反馈循环，最后使喇叭负荷超载，发出
尖锐刺耳的声音，而且频率还愈来愈高。负荷超载
（overload） 就是正反馈常有的问题。
相反地，负反馈则是以输出来抑制回路未来的输出。
其实我们开车就是一种负反馈的系统，先踩点油门，慢慢
加油，发现太快了就带点刹车来减速，如果刚起步就是油
门一踩到底，那就得重踩刹车才能达到正确的速度。也就
65
微软研发·致胜策略
策略性的作业方式下载
是说，输出愈强，需要负反馈的抑制力就要愈大，但也不
是让反馈的力量决定一切，负反馈只是调整用的，好让输
出维持稳定。停车只是刹车踏板的作用之一，让车速保持
稳定也是刹车（负反馈） 的作用。
除了电子工程，您还可以发现有很多各式各样的反馈
回路，包括人际关系和软件开发。有些反馈回路是刻意设
计的，有些则是无意间自然形成的，不论是有意无意的回
馈，都有助于加强对项目的控制，所以，您必须明白反馈
回路的道理，并且善用它。
错虫，就是程序设计的输出产物之一，我们把软件开
发当成电路系统，如果有个负回路可以让错虫导回去抵销
下一个潜在的错虫，那有多好！我们前面谈过的立即除错
就是一个负回路的观念：
要求程序设计师一发现错虫就立即清除。
如果一发现错虫就立即消灭它，它就没有机会影响到
程序设计师的心情，大家可以高枕无忧地继续做下一项工
作。但是如果有个伤脑筋的扩散型错虫，清了这里却错了
那里，再去修改那里却发现还有某处情况不妙，就得坚持
要求这位程序设计师除错到底，把所有的错虫都确实清除
66
微软研发
致胜策略下载
干净了，才可以继续开发工作，否则会造成野火燎原之势，
错虫一发不可收拾。错虫愈多的程序设计师，愈要加强督
促。“立即除错”就是一个最好的负反馈系统，让软件永
远保持无错状态。当然，还有我们前面提过的种种立即除
错的好处—刚生成的错虫比较容易清除、让程序设计师
学习速度加倍、更能准确估算项目的完成日期等等。
反馈回路有利亦有弊，运用不当的话也是会有问题的。
记得我在第1章中谈过的实例吧，那个项目经理总是要求
他的组员写进度报告、开进度检讨会、再做后续报告，没
完没了。这位主管是希望藉此获得项目进度的信息，很不
幸，他的负回路却阻碍了他真正需要的产出，他想了解组
员对于如何解决问题的见解，可惜方法不对，他要求组员
写报告，结果让组员心生反感，根本不想发表意见，他的
制度使人噤声—讲得愈多，你必须写的报告就愈长，没
有人想写报告，所以只好闭上嘴。这正所谓适得其反。
负反馈不是惩罚
惩罚是一种心理上的负向强化作用（ n e g a t i v e
r e i n f o r c e m e n t ），惩罚是对员工责骂、训斥与威胁，就像鞭
打马匹使它服从主人的命令。发现有一位组员进度落后了，
67
微软研发·致胜策略
策略性的作业方式下载
不得了！叫过来骂一顿，这就等于是给了他一帖重剂量药
物，逼使他以后不敢对进程掉以轻心。
这种管理手段是该受谴责的，我绝对不鼓励任何人这
么做。想一想我们前面刚讨论过的负回馈的观念，要求程序
设计师立即除错，但程序设计师不需要对除错感到焦虑不安。
由于立即除错的策略，他必须花费好几天的时间解决这个问
题，当然不是他所喜欢的结果，但主管不应该让他因此而感
受到威胁。我们希望任何事情都很自然，没有必要加重组员
的苦恼，绝不是强调谁是老板谁是奴才，谁必须服从谁。
在微软曾经有几位主管，每次一遇到项目进行不顺利，
就把组员叫出来骂，说他们是最差劲的程序设计师，不配
自称是微软的程序设计师，以及等等之类的无聊话。我不
能确定这几位主管究竟用意何在，但是如果他们的目的是
让组员工作更努力的话，那他们的方法可就大错特错了。
我相信您完全可以想像，这种责骂只会激起组员心中的愤
恨、羞恼和沮丧。更糟的是，就我所知这些项目的问题事
实上都出在管理方面，目标不够明确或是野心太大，这些
项目的程序设计师只是倒霉遇上了差劲的主管，其实他们
的能力并不比公司内其他的程序设计师差，因此责骂他们
只会让项目更糟，绝对没有改善的效果。
68
微软研发
致胜策略下载
您必须小心注意，别设置了不当的负回路系统，例如
以程序新增的行数、或新加入程序的数目来决定组员的奖
金，把程序改好则不记入功劳，那么，程序员肯定只爱写
拼拼凑凑的初稿，程序不求精巧，而且不愿认真改善现有
的程序。您原本希望奖励的是生产效率，结果却造成公司
里大而无当的拼凑程序到处泛滥。
我希望您能从以上的讨论中，体会到两点原则，第一，
当您设计一个新系统时，利用负回路的观念来帮助项目进
行顺利；第二，要考虑�
