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

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


很酷的事。他说的不错，但除了酷之外，没有其他更具说
服力的理由。
至于协作厂商呢。。
协作厂商也许会乐意见到这个界面。如果非视窗软件
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＋＋　有兴趣，想借此机
会学习一种新的技术。如果确定要重写，您必须慎重衡量
二者之间的利弊得失，重写所耗费的大量时间成本，是否
能得到相对的产品改善和获益的结果。
111
微软研发·致胜策略
保持进度下载
避免干扰
到目前为止，想必您已经很清楚什么样的工作才是应
该全力投入的：与目标一致的策略性工作。但是这样还不
足以让您保持进度，您还得尽量撇开“免费”的附送软件，
克制大家追求“酷”的欲望，尽量减少对产品没有改善效
果的工作。如果您无法学会说“不”，或无法了解别人真
正需要的是什么，您就会发现自己深陷泥沼，净做不该做
的事情。
要想确保项目依照计划进行，没有脱序或偏离，其关
键就在领导者完全明白该做什么，并且不让该做的事受到
不当的干扰。这也就是为什么详细的项目目标是那么重要
了。
重点提示
不要让意外出现的问题打乱项目的脚步，如
果您要项目顺利进行，您得花点时间思考未
来。今天做个小小的动作，可以防范许多意
想不到的问题，即使真发生了无法避免的灾
难，您也能在风雨中稳稳掌舵。如果您随时
112
微软研发
致胜策略下载
问自己：“有什么事情是我今天能做的，而
且可以帮助项目在未来几个月内顺利进
行？”您就会知道该采取什么行动。
在您准备解决一个问题之前，先确定您找
到了问题的症结。还记得对话框函数库的
例子吧，Word　小组的抱怨不小心误导了问
题的症结，使得函数库小组极力设法优化，
却徒劳无功。因此，在您企图解决任何问
题之前，请务必确定已经对问题有了彻底
的了解。
在投入大量时间于任何一件工作之前，请
想一想这件工作是否能满足真正的需求。
您还记得那怪异的下拉式列表框，其实应
该是个级连式菜单的例子吧。当您接获任
何一项要求，最好了解一下背后的原因，
提出这项要求的人究竟想要做什么。这样
可以节省很多宝贵的时间。
基于非常多的原因，有些主管很难对提出
需求的小组说“不”。在比较严重的情况下，
113
微软研发·致胜策略
保持进度下载
主管会“知其不可而为之”，答应对方自己
做不到的承诺。如果您发现自己常常不好
意思说“不”，请将心比心替对方想一想，
万一到时候做不出来，是不是会造成更严
重的后果？如果您是需求小组，您对该到
货的东西迟迟不见，是不是焦急又恼怒？
您必须对其他的小组负责，就像您希望他
们也能对您要求的工作负责一样。
每当您接到一项请求，要您在产品中加入
某一项功能特色，请先想一想这项工作在
策略上重不重要，如果不，就不要开发
它；至于这个功能特色是否免费、是不是
很酷、竞争对手有没有，都不是重点。特
别是有些整组的功能，它们看起来很重要，
因为它给您一种没有它就不够完整的感觉。
您必须牢记，产品的策略性比完整性重要。
如果您不敢确定这项功能特色是否有策略
上的重要性，只要想一想这项请求的动机，
就可明白大半了。
114
微软研发
致胜策略下载
下载
第4　章
走极端的
狂热
4
Chapter　Four
在您读完前3章后，您或许会对我有点误解，以为
我是那种专门压榨属下，唯生产力是图的主管。
的确，我非常重视生产力，但我的目标绝不是榨取属下，
而是尽力营造愉快的工作气氛，让属下很自然地发挥最大
的生产效率。
您是否有过顺利完成项目的那种无法言喻的成就感？
或者至少有过一次，您带着万分愉快的心情走出办公室，
觉得自己今天好充实好满足。试着回忆那个愉快的日子，
那天是在开会、写报告、访谈、传e　…　m　a　i　l，还是一整天不
受打搅，终于想出一个绝佳的点子，或是完成了一件很棒
的程序设计杰作？不必说，您我都知道答案。到目前为止，
我从没见过一个热爱开会或写报告的程序设计师。
以我身为一位软件开发团队的领导者来说，我极力想
达到的目标就是创造一个理想的工作环境，让所有的人都
能尽情发挥，创造出足以自豪的产品。为了做到这一点，
我很努力地让程序设计师免除不必要的报告和会议，尽量
不是为了赶进程而压力过大，任何与改善产品无关的杂事
我都尽量排除；我希望程序设计师安心工作，专心开发产
品。在本章中，我会告诉您为什么这些杂事会伤害生产效
率（尽管这些杂事随处可见，似乎每家公司都是如此），我
116
微软研发
致胜策略下载
也会告诉您如何用比较简单有效的方式达到同样的目的，
而不要让这些杂事淹没了程序设计师以致影响了他们的生
产效率。
无人理睬的报告
有一次我出差回来后，我的上司找我到他的办公室，
问我有关这趟公务的细节。我们谈完之后，他要我把所讲
的每件事都一五一十地写成一份出差报告。对我而言，这
实在是非常浪费时间的事情，所以我问他报告真的非写不
可吗？他很肯定地说是的，所以我花了一整个下午的时间
写报告，项目的事情只好暂时搁在一边。
不到一个月，我的上司又把我叫去，口头询问一个问
题，而这是我在书面的出差报告中早就详细说明过了的，
我能体谅他日理万机，无法记住报告中的每一项细节，但
我忍不住怀疑他到底有没有看过我写的报告，所以我就单
刀直入地问他。哦，答案可真是令我心碎，他一个字也没
看，我把报告交给他的下一秒钟，报告就进了档案柜。
我忍不住有点恼怒：“既然你根本没打算看这份报告，
为什么一定要我写呢？”
我没想到他露出惊讶的表情说：“每个人都要写出差
117
微软研发·致胜策略
走极端的狂热下载
报告，这是公司的政策。”
随便哪个理由都比这个好。他可以告诉我，研究显示
人们对自己写过的东西记忆会深刻些，那我也就认了；他
也可以告诉我，他想要把我的报告呈给上一级的主管或别
的小组看，把报告中的心得分享给别人，那我也可以理解。
但是他明明就不想看，却仍然要我写出报告，再丢进档案
柜，这未免太荒谬了。这就是过度死守规则的错误示范，
规则是该遵守没错，但把规则当作铁一样的法律就太蠢了。
任何公司都一样，凡是没人看的报告就不该写，除非是要
作者加深自己的印象，即便如此，也不是每一次出差都该
写报告。奉劝各位明智的主管，绝对不要像我的上司一样，
只知道墨守陈规，而从未考虑对正经事的伤害。
炖肉必须切掉两端
有很多事情因