微软研发致胜策略-第10部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


如果您带的程序设计师中有人向您建议把C　转成
C　＋　＋，您不妨了解一下，他们是真的认为本产品有必要利
用C＋＋　特有的优点，还只不过对C＋＋　有兴趣，想借此机
会学习一种新的技术。如果确定要重写，您必须慎重衡量
二者之间的利弊得失，重写所耗费的大量时间成本，是否
能得到相对的产品改善和获益的结果。
111
微软研发·致胜策略
保持进度下载
避免干扰
到目前为止，想必您已经很清楚什么样的工作才是应
该全力投入的：与目标一致的策略性工作。但是这样还不
足以让您保持进度，您还得尽量撇开“免费”的附送软件，
克制大家追求“酷”的欲望，尽量减少对产品没有改善效
果的工作。如果您无法学会说“不”，或无法了解别人真
正需要的是什么，您就会发现自己深陷泥沼，净做不该做
的事情。
要想确保项目依照计划进行，没有脱序或偏离，其关
键就在领导者完全明白该做什么，并且不让该做的事受到
不当的干扰。这也就是为什么详细的项目目标是那么重要
了。
重点提示
不要让意外出现的问题打乱项目的脚步，如
果您要项目顺利进行，您得花点时间思考未
来。今天做个小小的动作，可以防范许多意
想不到的问题，即使真发生了无法避免的灾
难，您也能在风雨中稳稳掌舵。如果您随时
112
微软研发
致胜策略下载
问自己：“有什么事情是我今天能做的，而
且可以帮助项目在未来几个月内顺利进
行？”您就会知道该采取什么行动。
在您准备解决一个问题之前，先确定您找
到了问题的症结。还记得对话框函数库的
例子吧，Word　小组的抱怨不小心误导了问
题的症结，使得函数库小组极力设法优化，
却徒劳无功。因此，在您企图解决任何问
题之前，请务必确定已经对问题有了彻底
的了解。
在投入大量时间于任何一件工作之前，请
想一想这件工作是否能满足真正的需求。
您还记得那怪异的下拉式列表框，其实应
该是个级连式菜单的例子吧。当您接获任
何一项要求，最好了解一下背后的原因，
提出这项要求的人究竟想要做什么。这样
可以节省很多宝贵的时间。
基于非常多的原因，有些主管很难对提出
需求的小组说“不”。在比较严重的情况下，
113
微软研发·致胜策略
保持进度下载
主管会“知其不可而为之”，答应对方自己
做不到的承诺。如果您发现自己常常不好
意思说“不”，请将心比心替对方想一想，
万一到时候做不出来，是不是会造成更严
重的后果？如果您是需求小组，您对该到
货的东西迟迟不见，是不是焦急又恼怒？
您必须对其他的小组负责，就像您希望他
们也能对您要求的工作负责一样。
每当您接到一项请求，要您在产品中加入
某一项功能特色，请先想一想这项工作在
策略上重不重要，如果不，就不要开发
它；至于这个功能特色是否免费、是不是
很酷、竞争对手有没有，都不是重点。特
别是有些整组的功能，它们看起来很重要，
因为它给您一种没有它就不够完整的感觉。
您必须牢记，产品的策略性比完整性重要。
如果您不敢确定这项功能特色是否有策略
上的重要性，只要想一想这项请求的动机，
就可明白大半了。
114
微软研发
致胜策略下载
下载
第3　章
保持进度
3
Chapter　Three
我们都会希望项目按照事先规划好的进程来进行，
但是事实总是无法尽如人愿，有时候项目会有一
点超前，有时候会落后些，但不会与计划差太多。项目的
进行大都是以迂回的方式前进。
即使是进行最顺利的项目，也无法完全按照计划执行。
但是如果您放任项目随意进行，有一天您猛然发现项目脱
轨太远，无法把方向扭过来，剩下的时间也不够，也就是
说，项目完蛋了。项目就像是一枚瞄准月球的火箭，只要
有一点点不够精确，到时候就无法命中目标，差之毫厘，
失之千里，实在不可不慎。所以，绝对不要让项目有一点
点脱轨，不论是多么小的偏差，倘若您没有立即修正错误，
它很快就会愈跑愈远、无法抓回。
聪明的主管懂得这个道理，他们会经常注意项目的进
度，随时修正方向，保持项目不偏离计划进行。本章将介
绍一些很有效的策略，帮助项目保持进度。
高架道路
我一直相信，项目之所以脱轨，主要的原因在于人们
并未认真思考如何使项目保持进度、顺利前进。如果没有
未雨绸缪，只是坐待问题发生，到那时候就太迟了。一个
74
微软研发
致胜策略下载
月前没有花3　0分钟思考这个问题，现在得浪费几小时或几
天的时间去修正。这就是所谓的“被动式行动”　（　w　o　r　k　i　n　g
on　reaction），而很多主管都是如此。
解决这种被动式行动的方法，就是化被动为主动，发
掘潜在的问题，并设法避免。以我们在第一章的搬移房子
的比喻来说吧，假定拖车原本缓慢而稳定的行驶，突然在
转角边上动弹不得了，原来是有个高架道路拦住了去路，
这下子只好掉头绕道行驶，结果前方又多了一些电话线，
真是气死人了。本来在地图上看来都是平路，上路了才发
现是这么崎岖，不仅要爬坡，还加上坑洞，怎么办呢？事
先没有勘察好路况，没有准备好应付路况的辅助工具，临
时手忙脚乱不说，还得老天保佑车子别翻了。要是主管用
心做好“向前看”的工作，事先把路铺好，把障碍扫除掉，
这些麻烦都不会发生。
主管不愿意认真地“向前看”，因为不看似乎比较轻
松。您可曾听说过某个主管在面临一个始料未及的障碍时
说：“啊，要是我事先多花点时间想想，就可以避免这件
事了。”以我的经验，很少有主管会这样承认的，反而是
在意外出现时不以为意，他们认为，意外难免发生，很正
常嘛。
75
微软研发·致胜策略
保持进度下载
您得驱逐这种被动式的想法，要积极防范意外才行。
有很多方法和技巧可以训练自己“向前看”　（　w　o　r　k
proactively），但总结起来不过是一句简单的要诀：
定期暂停手边的工作，然后往前思考，随
时做必要的修正，以避免未来的大障碍。
只要您懂得向前看，要事先避免大障碍并不困难。比
方说，　Windows　版的软件完成后，自然得继续开发
Windows　NT　版，或是准备一些示范用的软件。这些事看
似小，但是如果不及早做出相应措施，后面的事情就很难
收拾。就好像开车进入山区之前先把油箱加满是一样的道
理，小小的动作可以避免在山区里加不到油而必须跋山涉
水的窘况。
我已有十年以上的习惯，每天花1　0到1　5分钟思考下面
的问题，并且列出答案：
有什么事情是我今天能做，而且可以帮助
项目在未来几个月内顺利进行的？
这是一个十分简单的问题，但是如果主管定期用它来
检讨、思考，必定能想到许多保护项目不受意外打击的妙
76
微软研发
致胜策略下载
方。请不要把这个问题的答案想得太复杂，事实上，答案
应该简单到能在几分钟之内写完，通常是这样的：
◆　订购MIPS　和Alpha　处理器的技术手册，以便
Hubie　需要时，随时可得。
◆　发个e…mail　给Word　的工作部门，提醒他们如果有
任何功能要加在这次的新版里，请在下周一前提出
需求。
◆　发个e…mail　给负责Graphics　的各位经理，我们需
要的函数库预计在3个星期后用到，确认他们届时
可以交货，没有问题。
没有一件事占掉我很多时间，但是却能省掉我将来可
能面对的麻烦。订购MIPS　的技术手册显然是件小事，但
是手册若是3星期后才送来，万一这中间MIPS　发生了问
题，没有手册，工作就无法继续，那项目就延误下来了。
订购手册要花多少时间，1　0分钟够了吧？现在花1　0分钟让
手册早点有得用，比起急需要用时再花1　0分钟订，再等3
星期，那事情都甭做了。
经常用这种方式思考，您就会想到许多也许会发生的
情况，也许G　r　a　p　h　i　c　s小组会晚两周，也许Word　小组不知
道该早点告诉您需求，因为他们以为不急于一时嘛。如果
77
微软研发·致胜策略
保持进度下载
没有经常“向前看”，到时候可能突然发现Graphics　小组
延误了。这下可惨了，所有的工作都会因此而赶不上进程，
或者是Word　小组最后一分钟才发现他们的需求因为告知
太晚而来不及做出来。
当然，在理想的情况下，Graphics　的主管们会事先告
诉我他们要延期完成，但是他们真的会这样做吗？根据我
的经验，几乎是从未有过，因为主管通常会在项目已经明
摆着延误了才会跟别人说—通常是到期的前三天。
每天都要问自己：
“有什么事情是我今天能做，而且会帮助项目在
未来几个月内进行顺利的？”
错误的问题
在Word　for　Windows　的开发过程中，我曾被要求检
查一个函数库。这个函数库不是Word　小组的人写的，是
一个对话窗管理程序，目的是把应用软件和操作系统区隔
开来，让应用软件的程序设计师在需要对话窗时，只要调
78
微软研发
致胜策略下载
用这个函数库就行，不必担心操作系统是Wi　n　d　o　w　s、
Macintosh或是其他的系统。
我被交代找出这个函数库为何速度这么慢—Wo　r　d
的项目经理们无法忍受每次调一个对话窗要等那么久，写
对话窗函数库的程序设计师已经做了一些最优化的措施，
也监测过程序的执行，但是Word　小组还是不满意，认为
这样简直是使公司声誉扫地，双方大吵了一架，而其他原
本打算使用这个对话窗函数库的小组也开始迟疑了。
我去找Word　的程序经理谈，以便更深入了解速度的
问题，还要找出什么速度才可以被Word　小组接受。他递
给我一张清单，上面表列着很多项目，每一个项目旁注记
有可容许的最长显示时间，也就是他们的质量规范指导。
然后我们开始测试，我们一只手按鼠标调出交谈窗口，一
只手同时按下秒表计时，等待对话窗出现。“看！”他一
边指着秒表说：“这个等太久了吧。”我倒觉得没那么可怕，
所以我再测一次，咦，这次快多了，几乎一下就蹦出来，
我说，第二次的速度一点儿也不慢，很明显符合可接受的
质量水准。
“没错，第二次总是没问题，我们是针对第一次要求
改进。因为只要停了一段时间没有使用，再调出对话窗时，
79
微软研发·致胜策略
保持进度下载
速度又变慢了。”
等我了解了实际状况后，回到我的办公室查看原始程
序代码，结果使我大吃一惊，原来问题的症结是Word　的
优化功能。因为Word　的优化功能会取代Windows　的程序
代码置换算法（code…swapping　algorithm），当Word　发现某
段程序久未使用，就会自动把它从内存中删除，以充分运
用宝贵的内存。因此，就算对话窗程序再快也无法通过测
试，因为它必须重新自硬盘加载。
所以，让Word　小组抱怨了好几个月的速度问题根本
不是程序的问题，而是内存运用的问题。Word　小组抱怨
对话窗太慢，却没有深入了解原因。单独测试函数库，似
乎是够快了，同样的程序实在没道理在Word　里面就跑得
特别慢。
猜猜错虫在哪里？
很多程序设计师并未下功夫研究如何清除错虫。很多
人都是直接去看原始码，随便修改某个地方，再执行一次
看看错虫是否还在，如果还在，就回来改另一个地方，猜
猜看是不是这儿错了，如此猜了一回又一回。。直到错虫
消失。
80
微软研发
致胜策略下载
我之所以知道程序设计师用猜的方式找错，是因为当
他们实在找不出错虫在哪里时，就过来问我，“接下来该
怎么办？”这种心态好像是在游戏结束前“不玩了”，并
不是真正在寻找错虫出现的原因。
以我的经验，最有效的除错方式是用debugger　（除错
工具）　设定一个暂停点，当程序执行到暂停点时，一一检
视变量的值是否正确，如果不对，针对这个变量往前找它
的变化，如果变量全对，就往下再设一个暂停点，继续执
行到那里再来看变量对不对。即使程序极复杂，要在庞大
的数据结构中转来转去，用这种方法总可以找到错虫，比
起用猜的方法要有效多了，如果靠猜测来找错，即使猜中
也不过是运气好，未必能找出错虫出现的真正原因。
我同时要提醒那些用看程序的方式来找错的人，应该
去读一下安德鲁·科恩尼（Andrew　Koenig）　的《C　语言陷
阱》（C　Traps　and　Pitfalls）　一书，里面有很多C程序的范例，
看起来都完美无瑕，但都有微妙的错误。要不然，有些杂
志定期会介绍一些附范例的C程序除错的技巧，也不妨看
看。
用看程序的方式找错，是既懒惰又无效率的方法，用
d　e　b　u　g　g　e　r来找错虫是最快又最方便的，观察各变量在程序
81
微软研发·致胜策略
保持进度下载
执行过程中的变化，是非常有效的方法，绝对不要用猜或
用看的办法来找错。
在这个案例中，Word　小组为了对话窗的速度问题抱
怨了好几个月，使得做对话窗函数库的小组花了好多时间，
辛辛苦苦地把程序最佳化，希望这是最后一次修改，可以
满足Word　小组的需求。其实，只要有人去看一下Wo　r　d
是怎么处理对话窗函数呼叫的，那问题早就迎刃而解了。
当然，不应该要求函数库的制作小组来测试应用程序，
因为调用这个函数库的应用程序总有数十上百种。然而，
函数库小组自己也该积极点，应该做一个专门测试本函数
库的假应用软件，对函数库单独测试，就能为函数库本身
的质量建立信心指导。在本例中，Word　小组已经大声地抱
怨了很久，而且函数库小组也找不出Word　在调用时有没