按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
那么清楚怎么做才是对产品最有利的，因此会要求一些也
许不应该开发的功能特色。这种不该加入产品的功能特色
有两类，一是不符合产品的未来发展方向，仅仅因为这项
功能属于杂志上所列评比清单中的一项；二是特殊客户的
要求。有时候，功能齐全不一定是最好的，有自己独特的
风格更重要，在产品中加进了太多枝枝节节的东西，可能
使产品过度膨胀，也花费了太多开发人员的时间精力，未
必是值得的。
遇到这种情形的话，您该怎么办呢？以我的经验，您
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 的环境下使用弹出式的附属应用程序是一件
很酷的事。他说的不错，但除了酷之外，没有其他更具说
服力的理由。
至于协作厂商呢。。
协作厂商也许会乐意见到这个界面。如果非视窗软件
105
微软研发·致胜策略
保持进度下载
可以让一些小而有趣的应用程式弹出执行，那么协作厂商
就可以利用这个“利基”，做出许多特别的小型应用程式，
外挂在微软的应用软件。这一点始终没有实现，因为我决
定不开发这个界面，但我是在审慎考虑过协作厂商所带来
的利益之后，才这么决定的。
倘若这些外挂式小型应用程序真的这么吸引人，协作
厂商一定会开发许许多多的新奇作品，使用者也会喜欢，
最终会增加产品的需求量。但是，小算盘？记事本？时
钟？没有人会单为了拥有这些小东西，这决定购买微软的
文字处理器、除错器等应用软件吧？
更简单地说，使用者并不需要这些外挂式小型应用程
式，因此产品也不需要它，为了一项使用者并不在乎的功
能要花费六个星期的工作时间，那是浪费。
事实上，这项需要六星期的工作并没有任何策略上的
价值，对我们的使用者界面函数库的目标没有帮助，对于
我们的20 个需求小组没有用处。这件工作之所以列在清
单上只有两个理由：一是有趣，二是够有个性，对于在
MS…DOS 的文字模式中待习惯的使用者而言，拥有
Windows 和M a c i n t o s h的附属应用程序确实很有个性—
106
微软研发
致胜策略下载
说服他们改用Windows 不是更有个性吗？
软件产品的开发，不能只为了有趣、挑战性，或
是够有个性够令人眩目。
这样比较好吗
有时候日程表中会突然插进一件工作，因为它似乎非
常重要，但是如果您再从策略的观点考虑一下，也许就会
改变。举例来说吧，Excel 有一个剪贴板（ c l i p b o a r d ），总是
让我看了很不舒服，因为它的处理方式与众不同，不会留
在内存。这个剪贴板一点也不难用，没有b u g，也不是说
它处理方式很怪异，但这就是非标准模式。因为它的做法
和所有的Windows 和M a c i n t o s h的剪贴板都不一样，所幸
操作上是完全相同的，使用者鲜少会注意到其中的差异。
我的原则是遵循标准重于一切，特别是关于使用者界
面的部分。所以您想想看，如果我是Excel 的程序经理，我
一定会认为“把剪贴板标准化”是一件很重要的工作，而
把它排进日程表里。是的，我确实认为它很重要，但是从
107
微软研发·致胜策略
保持进度下载
策略上来看就不重要了。此外，修改剪贴板的程序代码会
有一个不良的副作用，就是可能会破坏使用者自己写的宏。
如果我是Excel 的程序经理，我会非常想把剪贴板标
准化，但是考虑到使用者的感受—可能会为了需要修改
旧的宏而恼火，可能会搞不清楚剪贴板到底怎么回事，我
还是不能改剪贴板。反过来说，如果使用者对现在的剪贴
板不满意，觉得很难用的话，我就会把修改剪贴板列为第
一优先考虑。然而，现在的Excel 剪贴板对使用者而言，
和其他的剪贴板完全相同，所以并不是非改不可。
还有一个很重要但无关策略性的工作，就是写程序的
风格（program style） 与命名原则（naming convention）。写
过程序的人都知道，程序的风格有点类似文章的文体，每
个人喜欢的分段方式不完全相同，对于文件名称、变量名
称和函数名称的命名原则也不一样。这没有绝对的标准，
但是同一套的程序最好有一致的程序风格和命名原则，写
和读程序比较方便，维护时也较不易弄错。一般而言，软
件在刚成形时源代码并不太多，就是有点乱也无妨，随着
程序代码的增长，程序风格和命名原则应该统一，所以会
有需要把过去随便取的名字改成统一的原则，有时候是因
为统一的命名原则在后期才被确立下来的缘故。
108
微软研发
致胜策略下载
假定有一位项目经理决定所有的函数都要有一段标
注，说明这个函数的功能和各参数的意义。这是非常合理
的。我所质疑的是接下来的行动，程序设计师就得停下所
有的开发工作，花几天或几周的时间，把所有的函数加上
这个标注。如果项目经理决定更改命名原则，那就更严重
了，要更改所有的函数名称、变量名称成本是极高的。这
些工作对于日后程序的维护很重要，但是没有策略上的重
要性，因为它对改善产品完全没有帮助。
不错，您可以把这类一时没有生产成果的工作当成对
日后程序可维护性的投资，这些努力终究有助于改善产品
的，但是要停下所有的开发工作代价实在太高。如果您想
取其优点、去其缺点，我的建议是不要停下开发工作，而
要求程序设计师在这次用到的函数上面，顺手补齐它的标
注。如此一来，程序设计师一周下来，多花的时间也许只
有一个小时，当然如果欠缺标注的函数很多，时间就会花
得多些。这种方式固然无法非常彻底，但无论如何，是比
较符合投资效益的。
然而，如果您要停下所有的开发工作，在全部的程序
中加进除错用的程序代码，那就是另一回事了，这是能改
善产品质量的，而且成效立见。
109
微软研发·致胜策略
保持进度下载
偶尔我会看一下乌斯奈特（Usnet） 的文章，我曾经看
过一位程序设计师写道：“我们正在把所有的C 程序改写
成C ＋ ＋，但我无法了解C＋＋ 如何做某事某事。。”我看
到这里，忍不住战栗了一下，我希望这位程序设计师—
事实上是他的主管不要浪费大量的时间重写程序，这样太
伤害程序设计师的生产效率。
同样的道理，您可能认为把汇编语言的程序用C 全
部重写，会使程序代码更具可移植性，日后也比较容易修
改和维护。但是，用C 重写Pascal 程序，或是用C＋＋ 重
写C 程序，并不能直接翻译，有很多地方是要从地基再
开始盖到顶楼，所以我个人非常怀疑这种做法。我猜想，
这类的重写工作大都是来自沉迷于科技潮流的主管所下的
命令。当C＋＋ 刚开始蔚然成风时，微软内部也有一些程
序设计师很想用C＋＋ 来写程序，而忽略了原来的程序代
码是否能继续运作的问题，他们固执地认为，就是要用最
新的技术，重写所有的程序。所幸大多数的微软人是很冷
静的，这种主张重写所有程序的声浪终于逐渐平息，公司
最后决定的政策是对象导向只用在新开发的程序，必须是
真的有策略上的需要才考虑重写。
110
微软研发
致胜策略下载
不要把时间浪费在无法改善产品的工作上，
即使这么做在将来会有潜在的利益，
也要与现在投入的时间成本做个衡量。
生产效率的迷惑
用C＋＋ 重写C 程序的理由中，我最常听到的是对象
导向的方式可以提高程序设计师的生产效率，他们也许是
对的，但是忽略了一个很重要的细节，那就是所有的时间
都要耗在重写，用C＋＋ 重写C 程序不是逐行翻译，而是
完全彻底重写。
如果您带的程序设计师中有人向您建议把C 转成
C ＋ ＋，您不妨了解一下，他们是真的认为本产品有必要利
用C＋＋ 特有的优点，还只不过对C＋＋ 有�