按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
切的办法侦测和预防错误，即使要自己改变
程序风格也无妨。
小心那种“太难了”、“太花时间”或是
“太麻烦”的反射性反应。当您遇到别人有
这种反应，请先问自己他有没有认真思考
过这件事的重要性、以及是否符合项目目
标，如果您认为他其实未经深思熟虑，只
是直觉的反应，那您就应该把您的想法告
诉他，请他重新评估，也许就会有公平的
答案。
人们遇到经验范围之外的事情，多少有恐
惧感，就会认为“这完全不可能”而强烈
反对。试着消除这种习惯性的反应，设法
给组员灌输“只要花时间想想看，大部分
235
微软研发·致胜策略
态度问题下载
的事情都做得到”的观念。您不妨以这个
问题来对付那种“凡事不能”的态度：“我
了解这是做不到的，但是‘如果’做得到，
那你会怎么做？”然后您就会发现惊人的
转变，您马上就会听到组员七嘴八舌地说
应该这样做、那样做，说的是他们刚刚坚
持做不到的事情。这个“如果”把他们带
离直觉的反应，带到全新的思考模式，这
才是他们应该做的。
把使用者当作什么都不懂的外行人，是非
常不好的观念。每当您发现有人表露出这
种心理，一定要立即纠正，提醒他们使用
者才是真正受产品好坏影响最深的人，他
们和程序设计师一样关心软件的执行速度
和质量。
教导程序设计师以使用者的角度来看产品。
程序设计师必须对产品有整体性的认知，
包装盒内一切有形无形的东西都是产品的
一部分，使用者并不在乎其中一部分好或
236
微软研发
致胜策略下载
不好，也不会想知道里面有多少不同的小
组各负责几个组件，也不在乎究竟用什么
语言写成，他不在乎软件是怎么做出来的，
这只对软件公司有意义，他们只知道产品
是那家公司出的。程序设计师当然不会每
个程序都参与，但是他们必须了解产品是
一个整体，任何一部分不符品质标准，都
得研究对策，而不是只做自己被分配到的
程序。只要大家都关心产品中比较弱的组
件，自然那一部分就会被设法改善。
杠杆原理是您最有用的观念，找到您工作
中的杠杆，您可以为小组、项目、公司、
甚至软件业创造无可限量的价值。无论如
何，尽量利用资源并创造资源，这个原则
是绝对错不了的。在您写程序的时候注意
程序代码的共享性、训练组员的时候注意
到他对公司的价值，即使是像函数命名这
种小事，都有杠杆的存在。不管做任何事，
都要想到“善用资源”，为未来做好准备。
237
微软研发·致胜策略
态度问题下载
下载
第8 章
沉船的感
觉
8
Chapter Eight
当项目的进度开始落后时，主管第一个想到的策略
不外是：增加人手，或是要求组员加班。看起来似
乎很合理，但是对于扭转项目的劣势来说，是最差的对策。
让我们想象一下16世纪，有一艘大商船正横越大西洋，
朝向新世界展开冒险的旅程。商船航行在大洋中时，大副
发现船进水了，立刻向船长报告，于是船长命令船员将船
内的水舀出去，但是不论船员如何努力，水还是渐渐升高。
船长眼看情形不妙，又叫来更多的船员一起舀水，依然没
有用，这下船长慌了，只好命令全体船员以轮班的方式来
舀水，但海水还是继续渗进船里，船渐渐往下沉。。
这时船长也知道他已经用尽了所有的人力，可是船还
是不断地进水，所以他只好下令所有的船员日夜不停地舀
水，累倒了之后醒来，再继续工作，这下真的发挥了作用，
船果真不再往下沉，进水线降低了。船长因为这次的成功
而沾沾自喜，想必是自己对人力资源运用得宜的缘故。好
歹一个星期是撑过去了。
但是很快地，船员就因为过度劳累而舀不动水了，舀
出去的水愈来愈少，船又下度下沉。大副试着说服船长，
如果要船员工作有效率，就必须让他们休息。但是因为船
仍然在往下沉，所以船长拒绝讨论让船员休息的事。船长
240
微软研发
致胜策略下载
咆哮着：“我们快沉船了，所以船员不准休息，在船没有
停止下沉以前，没有人可以休息，你没看见吗？我们就要
沉船了！！”
进水线仍然残酷地升高，愈来愈高，于是船终于沉入
海底！
大家不妨想一想，如果您是船长，除了命令所有的人
拼命舀水，有没有更好的办法呢？如果您正在一艘漏水的
船上，四周都是一片汪洋，您怎么办？我的想法很简单，
我可以告诉您我怎么办：“找出漏水的地方，把它堵上。”
您不也是这么做的吗？
这实在是显而易见的道理，但是为什么总有那么多项
目经理不懂得用这一招来挽救他们的项目呢？我只看见一
大堆项目经理一遇到进度落后就二话不说地要求组员加
班，组员加班若还是解决不了问题，就寻求更多的人手投
入。就像那位船长，水都到腰际了，仍然不肯停止舀水、
先去“找漏”、“补漏”，直到所有的人跟着陪葬。所幸，
大部分的项目还不至于沉船，因为组员舀水的速度，勉强
可以比进水的速度快一些，所以项目最后大都是硬干蛮干
也把它赶出来了，只不过，浪费了无数的人力，折损了无
数程序设计师的青春血汗。
241
微软研发·致胜策略
沉船的感觉下载
在第1章我谈过的那个使用者界面函数库小组，他们
一年来每周工作8 0小时，但项目看起来一点进展都没有，
情况只是愈来愈糟，却没有人想到停下来找出问题症结，
一味埋头继续苦干，祈祷自己的辛勤能感动上苍，他们一
天工作12小时，每周工作7 天，他们还能怎么样？就像我
在第1章描述的，这个小组把大部分的时间都花在他们不
应该做的工作上，他们并没有认清项目的目标是：“提供
对每一个需求小组都有益的使用者界面函数”，这就是漏
水的地方，问题的症结所在。
在第3章中，我也举过另一个对话框函数库的例子，
他为了Word 小组而改写程序代码，企图加强执行速度，
却始终达不到Word 小组的要求；而事实上根本不是对话
框程序不够快的问题，而是由于Word 本身的置换
（swapping） 功能会把所有暂时不用的程序代码移出内存，
要用时再重新加载（ r e l o a d ），是这段重新加载的时间使得
对话框看起来很慢，和本身的速度无关。但是当时却没有
人注意到这个问题，双方都把焦点放在对话框的执行速度，
要求将对话框的程序代码优化。
在第5章，我也提过Excel 小组曾经每周工作80小时，
试图赶上那不合理的日程表。
242
微软研发
致胜策略下载
在这些事例中，“加班”本身就是一个危险讯号，明
白告诉您一定有什么地方出了问题，很不幸地，大部分的
主管都不明白这一点，而忽略了这个严重的警讯，反而在
项目发生进度落后时，直觉地采取两个最愚蠢的步骤：增
加人手，或是要求组员加更多班，而不是去找进度落后的
原因。
过正常的生活
我在微软的七年，最重要的工作是让那些挣扎中的项
目起死回生。在每一个案例中，小组的成员都是每周工作
七天，天天加班，只为了赶上预计的完成日期，团队的士
气非常低落，程序设计师开始憎恨自己的工作。
每次我正式进入一个小组成为他们的新主管，我做的
第一件事就是停止加班，并寻找进度落后的真正原因。我
会在每天的傍晚，到程序设计师的办公室把他们都赶回家
去：“赶快下班去！过个像人的生活！”
程序设计师会抗议道：“我不能走，我的进度落后
了。”
我会说：“没关系的。整个小组都已经加班工作了整
整一年，仍然无法使项目赶上进度，可见加班绝不是解决
243
微软研发·致胜策略
沉船的感觉下载
问题的方法。一定有其他从根本上就出错的问题，我们必
须把问题找出来，再针对它改正。加班是没有用的。回家
吧！好好休息一下。我们明天第一件事就是找到出错的地
方。”
一开始大家都以为我在开玩笑。这种话似乎从来没听
主管说过，主管们向来是要求他们再多一点努力、再多一
点加班，现在太阳还没下山呢，而我竟然叫他们回家，他
们以为我疯了。项目目前的进度已然严重落后，如果大家
都停止加班的话，后果岂不是会更糟？
但是接下来的几个星期，我会用本书前面所介绍过的
策略来改善项目的体制。我会停止不必要的报告和会议，
我会排除不必要的杂务；我会把条例式的工作进度表丢
掉，换成我在第5章建议的阶段式小项目来取代；我会为
组员建立第7章所述的正确心态，例如一发现错虫就立刻
清除；我把项目的目标定得非常清楚，并且让程序设计师
明白，我身为主管的目标之一就是保护他们有一大段完整、
不受干扰的时间，专心去开发程序。大约经过一两个月的
辛苦，小组学会了正确的方式，能够完成小项目的目标了，
大家打胜了第一仗，而且不必每周工作8 0小时，小组开始
有信心，接下来的几个月，大家已经很能掌握正确的工作
244
微软研发
致胜策略下载
方式，把我传授给他们的技巧变成工作的习惯，渐渐地，
愈来愈容易完成各个小项目，而最后整体进度终于得以完
成。
如果进度发生落后，那表示有个地方出错了。
您应该找出问题，并加以解决，不要一味要求组
员加班，在问题没有解决之前，加班是没有用
的。
鞠躬尽瘁的迷惑
有的小组加班的原因不是为了赶进度，而是因为高层
主管们认为程序设计师不加班的话是无法如期完成产品
的，因此他们非加班不可，每周工作必须超过80小时才行。
这种笃信加班的主管看到有某个小组每周“才”工作4 0小
时而已，就会以为这个小组对公司没有尽心尽力。也许高
层管理者认为如果小组每周工作4 0小时就能完成进度，那
一定是进度表定得太宽松了，他会把每周工作8 0小时的小
组拿来作例子，说道：“这样才是对公司鞠躬尽瘁的表
245
微软研发·致胜策略
沉船的感觉下载
现！”要求所有的小组也每周工作8 0小时，不然的话就是
对公司不够鞠躬尽瘁。我当然完全不同意这种看法。如果
我赞成这种论调，前面所说过的那些故事的主角：使用者
界面函数库、对话框函数库、Excel 的部门，就会变成应
该模仿的英雄偶像，而那些拥有具体目标、不断学习、坚
持工作效率的不加班团队，不就应该经常进度落后了？事
实正好相反。
我这样说，读者一定觉得很蠢，但是且听一位高层主
管对不加班的小组说的话：“公司雇用他们并不是让他们
在数时间混日子的，告诉他们工作时间必须长一点，我要
看到他们为公司尽心尽力！”
真是没道理，高层管理者竟然把没有效率的小组拿来
表扬，而把有效率的小组说成愉懒。还好有另一种高层管
理者，当他看到有一个小组不加班却能完成工作，就会去
请教这个小组如何做到的，并要求其他的小组效法。
为什么同一件事却有截然不同的反应呢？简单的说，
就是观念问题。
同样是不加班而能完成进度的情况，有的管理者认为
是罪恶，有的管理者认为是典范。聪明的读者，您觉得如
何呢？当然在某些特例之中，这两种管理者可能都是错的，
246
微软研发
致胜策略下载
但是我们应该从正面去思考这个问题，对吗？
就像是有些项目经理在遇到进度落后时，第一个反应
是要求组员加班，而不是寻找哪里出了问题，有些高层主
管也是一样的直觉式反应，因为他们在观念上相信加班对
项目有好处，对公司勤奋的文化也有好处。他们都忘了一
件事，在软件业，开发小组贡献给公司的是智能的价值，
这是重质不重量的，有很多比加班更好的方式增加小组对
公司的贡献：像是提高产品的质量（却不一定以投入更多
的工时为代价）、写出可共享的程序代码供别的小组利用
等等。但是对于笃信加班神话的主管来说，他只在意程序
设计师是否把自己所有清醒的时间加上部分的睡眠时间完
全付出给公司，以为这样就可以增加开发小组对公司的贡
献，这是完全错误的。
“加班加得愈多，代表总投入工作时数愈多，产品就
能愈快完成”，在理论上看来似乎没什么不对，在传统制
造业或许成立，但是在软件业是行不通的。软件业的投入
工时和产出价值没有必�