按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
不悦，您还是要耐心解释，问题总得交代清楚。
每个人都不愿意被别人讨厌，这是人类的本性。但是
身为软件开发的主管，您就必须掌握这个道理：如果您希
望每个人都满意，最后您会焦头烂额，什么事都做不成。
91
微软研发·致胜策略
保持进度下载
以我的经验，人们虽然不喜欢自己的需求被拒绝，但
如果您有充分的理由，他们还是会了解的，并且感谢您的
用心。
不要为了讨好别人而伤害双方的工作进程，您永
远要根据自己的目标，做适当的决策。
如果不是函数库项目
我以函数库的实例讨论互相冲突的需求，您可能不是
负责开发函数库的，无论您负责的是什么项目，我们所讨
论的观念和做法几乎都可适用。基本上，您难免会遇到外
部的要求，提出需求的人甚至可能是行销小组，或是来自
使用者的反应，即使是极端机密的软件开发项目都可能有
人来插上一手，您必须学会摆平冲突。
上级的建议
一位主管在做任何决策时应该以项目目标为最大的考
虑，不要企图讨好别人，尤其不要盲从上级提出的建议。
92
微软研发
致胜策略下载
我不是主张反抗权威，而是强调上级也是人，一样可能犯
错，他们的建议不一定是好的，尤其是他们可能不了解您
的目标、决策优先级，以及您所必须面对的技术挑战。如
果您想做一位出色的主管，您必须非常认真地衡量所有的
建议，不论是谁提出的，您都得确定其符合项目目标才能
采纳。
如果上级要求您做一件事，而您认为不妥，那您应该
在着手进行之前向上级说明您的想法。也许，上级会同意
您的想法而放弃他的建议，也许，上级会赞许您的想法，
但仍请您考虑他的意见。不论结果如何，起码经过沟通对
彼此都有帮助。
有一次，我查阅一位资深程序设计师的程序。对其中
有一些很明显属于设计上的缺点我很惊讶，我不太相信这
么一位优秀的程序员会写出此等程序，于是我问他为什么
这样设计。
“是柯比设计的，我只是照做而已。”柯比是他的项目
经理。
我觉得好奇的是他自己的看法：“你自己觉得这样设
计好吗？”
“如果是我设计，不会用这种方式。”
93
微软研发·致胜策略
保持进度下载
“你在写程序的时候，应该能感觉到这一点吧？”
他轻描淡写地说是的，并且耸耸肩道：“但我刚到微
软不久，柯比是我上司，我认为他应该比我有经验，他这
样设计也许有特别的用意。我可不想把事情搞砸。”
事实上，柯比并没有比这位程序设计师有经验，他只
是比较幸运，在微软待得比较久罢了。
对于这个观念，我还有另一个很有意义的实例。当时
我领导Microsoft 680x0 的交叉发展系统（在Macintosh 和
PC 之间使用），我的顶头上司，也就是有权变动我计划的
人，名叫莫特。每隔一段时间，莫特就会到我的办公室来
问我有关680x0 的C/C＋＋ 编译器项目进展的问题。他每
次来必定会问一个问题：
“FORTRAN 进行得怎么样了？”
莫特很清楚我们根本不做F O RTRAN 的编译器，但
是他喜欢F O RT R A N，而且他相信一个好的M a c i n t o s h版
F O RTRAN 编译器一定很有销路。事实上，如果把我们做
好的C/C＋＋ 编译器修改成F O RTRAN 编译器并不太难，
我和莫特都知道，微软开发编译器都是遵循大部分教科书
所描述的三阶段方式：
1 。前端处理（front end） ：把高级语言（如C / C ＋ ＋，
94
微软研发
致胜策略下载
FORTRAN 等） 解析成中间代码。
2。 优化（ o p t i m i z e r ）：对中间代码做执行时间的优化
处理，诸如程序代码搬移、调整，同次表示式消去等
等。
3。 后端处理（back end）：从经过优化的中间代码，产
生最佳的执行代码。
当然，实际工作比这三点略述要复杂得多。但是由这
些您可以看出来，要推出一个Macintosh 用的编译器，只
要重新写一个后端处理，就可以把英特尔80x86 的编译器
转成摩托罗拉680x0 的编译器。
从理论上说，一旦我们完成了680x0 的后端程序，我
们就可以用它来把所有的英特尔80x86 的C / C ＋ ＋、
F O RT R A N、Pascal 的后端处理替换掉，这样就做出摩托
罗拉680x0 的C / C ＋ ＋、F O RT R A N、Pascal 的编译器了。
这就是莫特对F O RTRAN 特别有兴趣的原因。然而事实
上，我们要做F O RTRAN 编译器的话，必须把后端处理
完全做好才行，当时我们只完成了95％ 的C / C ＋ ＋编译器
后端处理。
每一次莫特问我有关F O RTRAN 的问题时，我的回
答也是千篇一律：“我们还没有开始。”然后再补充道：
95
微软研发·致胜策略
保持进度下载
“主要是因为F O RT R A N编译器的关键组件—后端处理，
尚未完成的缘故。”
莫特也许是对的， F O RTRAN 编译器在M a c i n t o s h上
也许会有很好的市场，但是他忽略了项目最优先的目标。
就算是有再好的市场，也实在没道理要把做了一半的项目
停掉，更何况他自己也认为C/C＋＋ 编译器的市场潜力应
该比F O RTRAN 更好。要不是莫特的个人兴趣，我不会
和他讨论这么多次，他的个人兴趣已经蒙蔽了他身为主管
的智能。
您必须保护项目不受外界的左右，尤其是当这种操控
来自特权人物之手。像莫特这样，想法明明是错的，您却
得服从上意。如果是我刚开始担任主管时，我会向压力低
头，服从上级的意思，现在我学会了独立判断，不论是谁
的建议或要求，我一定会先问自己：“这样做对产品有没
有帮助？对于目标的完成有没有策略上的价值？这样做是
否会使我忽略了更重要的事情？这样做的成本和风险会不
会太高？”您必须好好想这些问题，答案如果对项目无益，
您就不应该照做。
96
微软研发
致胜策略下载
是您在为项目负责。
不要让任何人的建议阻碍项目的进行，包括上级
的建议。
真正的成本
为什么莫特会认为M a c i n t o s h上的F O RTRAN 编译器
值得开发呢？是因为很多人想买吗？还是因为F O RT R A N
对Macintosh 有特殊意义呢？其实都不是，真正的原因是
他自己对F O RTRAN 情有独钟，他希望能够得到一份免
费的Macintosh FORTRAN 编译器，如此而已。
我对能附送那些副产品的兴趣，绝不下于任何人。那
是一种欣慰的感觉，因为自己是一位优秀的软件开发专家，
才能有这么多精彩的创意，额外做出这些副产品。但是这
些副产品对公司或产品都没有策略上的价值，充其量只是
一种消费者回馈。如果它们有策略上的重要性，早就放在
产品设计的计划里面了。
有趣的是，我们也可以把C/C＋＋ 编译器的前端处理
换成Pascal 的，那么我们又多了一个M a c i n t o s h的P a s c a l
97
微软研发·致胜策略
保持进度下载
编译器了。但我从来没打算这么做，虽然我们都知道
M a c i n t o s h曾经有很长的一段时间只有Pascal 程序，苹果
计算机所有的手册和范例程序都是采用P a s c a l，而且苹果
计算机的Pascal 编译器市场并没有太大的竞争。现在的情
况则完全改观了，苹果计算机如今已是C/C＋＋ 语言的天
下。但是如果我们要在C/C＋＋ 编译器产品之外附送一种
语言的编译器，那Pascal 绝对比F O RTRAN 要适当。
莫特对F O RTRAN 编译器有兴趣，纯粹因为它免费，
而不是基于任何策略性的考虑。但是F O RTRAN 编译器
真正的成本可未必那么便宜，如果我们要把F O RT R A N
编译器引进市场，我们要做的事情是：
◆ 完成后端处理，目前剩下5％ 尚未完成，这大概要
花几个月的时间。
◆ 想办法让F O RTRAN 和M a c i n t o s h的操作系统交谈，
因为M a c i n t o s h向来是用Pascal 写的，而Pascal 的
记录，FORTRAN 无法支持，所以这方面有个鸿沟，
需要另外设法跨越。
◆ 撰写手册和线上求助的文档。
◆ 完整地测试F O RTRAN 编译器，包括它的链接能
力，除错工具，以及其他的各种辅助工具。
98
微软研发
致胜策略下载
其实还有一些额外的行政工作也是不可或缺，例如训
练产品支持小组等等，以上只是几项开发性质的工作。现
在您觉得F O RTRAN 编译器很便宜吗？好吧，即使前面
三项可以利用C/C＋＋ 编译器的东西过来改一改，但测试
工作没有快捷方式，它可是完全无法打折扣的，任何产品
都要有同样严谨的测试工作，F O RTRAN 编译器必须通过
和C/C＋＋ 编译器同样一丝不苟的测试程序。
所以F O RTRAN 编译器绝对不是白吃的午餐，虽然
比起完全从头开始的C/C＋＋ 编译器，成本低廉得多，但
是“便宜”可能仍然是高价—只要问问最近买过二手波
音747飞机的人就知道了。
免费的软件或功能其实并不存在。想想看，您每次听
到广告中的“免费”，内心的反应恐怕是抗拒多于接受吧，
感觉上，这就像是听到“参观某工地表演就可以免费参加
夏威夷六日游大抽奖”一样。大部分时候，这类的免费软
件都没什么重要性，只有极少极少的例外会中大奖，如果
您希望确实掌握项目朝正确的方向进行，就请专注在有策
略价值的工作上，不要被一些花俏的噱头分心。
99
微软研发·致胜策略
保持进度下载
天下没有真正免费的软件
炒鱿鱼宏
不只是上级会提出不合理的请求，行销人员也可能会。
有时候为了争取一张大订单，行销人员会为这位大客户要
求一些匪夷所思的修改。您必须捍卫您的产品，避免被这
些不正常的杂音所扭曲。
当我负责Microsoft Excel 时，行销人员要求开发一个
炒鱿鱼宏（ L AYOFF macro），而这个宏的内容您大概已经
猜到了，就是一份名单，用随机的方式挑出其中一些人来
遣散，因为大公司想要裁减人员，又不想造成反弹或不公
平之议，干脆用计算机随机选取，反正遣散谁都一样，正
好利用Excel 来推卸责任。
如果您熟悉E x c e l，您就知道并没有这个宏。这个宏
我做不来，所以我拒绝了这个要求，因为我认为这会伤害
我们的产品。而我的上级也同意我的看法，所以我们成功
地阻挡了这个要求。但行销人员持续要求了好几个月，他
们认为要有这个特色，才能让顾客更需要Excel。
100
微软研发
致胜策略下载
这个炒鱿鱼宏成了我们开发小组的大笑话。“这样好
了，我们就来做这个宏，里面做点手脚，凡是遇到我们的
名字就忽略过去，这样我们就永远不会被炒鱿鱼了！不，
还可以更好，我们把程序写成让行销人员的名字优先中奖，
这样一来，行销人员永远最先被解雇！”当然我们不会真
的这样做。最后的结果是，行销人员另外写了一个使用者
自订的宏，去满足那位大客户，而我们始终没有在产品中
加入这个讨厌的宏。
就我多年的经验，这类荒唐爆笑的要求其实很少见，
因为行销人员一点儿也不想伤害产品，相反地，他们和开
发人员一样渴望有最好的产品，只不过有些时候他们并不
那么清楚怎么做才是对产品最有利的，因此会要求一些也
许不应该开发的功能特色。这种不该加入产品的功能特色
有两类，一是不符合产品的未来发展方向，仅仅因为这项
功能属于杂志上所列评比清单中的一项；二是特殊客户的
要求。有时候，功能齐全不一定是最好的，有自己独特的
风格更重要，在产品中加进了太多枝枝节节的东西，可能
使产品过度膨胀，也花费了太多开发人员的时间精力，未
必是值得的。
遇到这种情形的话，您该怎么办呢？以我的经验，您
101
微软研发·致胜策略
保持进度下载
应该探究这个需求背后的动机。好好想一想。如果行销人
员跑来对您说：“惠普公司（HP） 的HP12c 商业用计算器
有五项功能是我们的电子表格所不能提供的，希望你们把
这些功能加上去。”对产品而言，加入这些功能有没有策
略上的价值？能不能真正改善产品？或者只是因为行销人
员这么想：“嘿，别人都有这个，就我们没有，须得加紧
赶上。”这些功能也许真的很重要，而前一版中来不及加
入，也许是当时觉得不值得开发，现在您仍然要坚守原则，
不值得开发的功能就不要做。
策略性行销
我希望上面的例子不会造成您对行销人员的负面印
象，因而对他们的建议不予理会。有时候他们的要求并不
妥当，但是他们通常都很有道理。至少我的经验是如此。
有时候，行销人员要求增加某个功能，由产品的观点
来看是没有策略上的意义，但是由行销的观点却非常有必
要。比方说，以产品的观点而言，实在没有必要支持2 3
种不同的档案格式，使用者只需要一种格式就够了，即使
是要与别的软件互读档案，也只需要业界标准的几种档案
格式；但是就行销的观点，如果产品没有非常足够的档案
102
微软研发
致胜策略下载
兼容性，就会降低顾客购买的意愿，或者，如果他过去所
使用的档案格式是本产品不兼容的，而他不能失去过去的
资料，那本产品对他就没有什么吸引力了。
如果您认为某些修改产品的要求应该予以拒绝，因为
不能改善产品，那么请考虑是否能大幅增加销售量。炒鱿
鱼的宏是应该拒绝的，因为它对产品有害，只对少部分大
客户有用，对大部分的小客户是无用的，而且对产品形象
颇为不利。
如果行销人员常常阅读杂志，很在意上面的评比清单，
您可能免不了这类的问题：对于功能特色的要求，是为了
在评比的项目上领先别人，而不是产品本身策略上的需要。
行销人员很可能会看到对手有一个很受注目的特点，或是
很红的卖点（尤其是对手的销量因此增加时），就强烈要求
开发人员跟进，这时候您的产品方向可能会因此转变，您
得特别小心，产品的长期目标不可因此而偏废。
应该开发策略上具有重要性的功能，
而不是把媒体的评比项目都做齐全。
103
微软研发·致胜策略
保持进度下载
很酷，但并不重要
在第1 章中我提过一位使用者界面函数库的组长，我
和他一起检视函数库的工作清单。清单中有一项六星期内
要完成的工作，是要容许协作厂商所开发的独立小程序直
接挂入微软的非窗口应用软件。其目的是将小算盘、小作
家、时钟等Windows 和M a c i n t o s h必备的附属应用程序，
也能在非窗口应用软件（主要是MS…DOS） 中用到。我认
为这项功能很有趣，但对于微软内部2 0个使用本函数库的
小组而言，并不重要。
于是我问这位组长，是谁要求加入这项功能，他说没
有人要求，这是因为前任组长觉得它很重要，才会列在工
作清单上。我再问是否有哪位组员对它很有兴趣，这位组
长说不知道，不过他加了一句，如果我把它删掉，被前任
组长发现的话准会跳起来。
我猜想如果前任组长对这项功能如此坚持，应该是有
某个小组真的想要，只是现任组长不知道罢了。所以在我
删掉它之前，我先问过使用本函数库的2 0个小组，有没有
人对这项功能很需要，或是对它很有兴趣，结果我得到的
回答几乎都是清一色的：“噢，我们听说过。是某某人一
直说服我们这个东西非常重要。”
104
微软研发
致胜策略下载
大部分的应用软件小组根本就不想要这个功能，有许
多更有趣的工作等着他们。况且，要完成这个功能的话，
附属应用程序集就会为了能够与协作厂商的程序交谈而变
得复杂，那么，应用软件与附属应用程序集之间，就需要
大量的沟通。他们并不想要有个桌钟或计算器摆在画面上，
他们要的是真正能加强应用软件功能的东西，例如文法检
查或是其他的重要工具。提供一般用途的使用者界面固然
不是坏事，但这项功能本身要花六星期来做不说，它还连
带使其他的部分也复杂化，我们没有时间做这项工作，也
不愿把现有的程序弄复杂。
到此为止我几乎已经决定把它删掉了。但我还是先找
了前任组长谈，了解他的看法。他对于这项功能将被删掉
的事颇感失望，但也别无他法。他主张开发这项功能的理
由是，这是一项有趣的挑战，很能磨练写程序的技巧，而
在MS…DOS 的环境下使用弹出式的附属应用程序是一件
很酷的事。他说的不错，但除了酷之外，没有其他更具说
服力的理由。
至于协作厂商呢。。
协作厂商也许会乐