微软研发致胜策略-第2章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
减轻个人负担，实质上您做的是伤害团队生产力的事情。
别人“能”做某件事，并不代表他“必须”做那件事。
您看过整个房子的搬迁吗？我不是指搬家，而是整个
房子从地基上拔起，用车拖着移到别的地方（美国的房子
多是木造的，可以这样搬移）。我们可以把项目比喻成那
间房子，把经理想成开路先锋，他的责任是把前面所有的
障碍物排除，让房子能一路不停地稳定前进，而不是走走
停停，停停走走。
房子前进的时候，领导者不希望每到一个路口就停下
来处理红绿灯，或协调其他的车子让路。他必须事先就规
划好最理想的路线，在房子抵达路口之前，就协调好工程
人员卸下悬挂着的标志灯或是电线等会阻碍行进的东西，
15
微软研发·致胜策略
奠定基础下载
等房子经过了再装回去。他应该避免将拖车停下来缴过路
费，或是等待他跟工程人员开完协调会。
搬迁房子的开路人员明白一件事，如果要房子一路不
停地向前行进，一定要找出所有的障碍，并且排除掉。过
路费当然也可以由拖车司机来交，可是这样一来就得停下
车子，如果由开路人员在前面交不是更好吗？很不幸，有
太多的软件开发经理在不该授权时授权，让组员为了与产
品无关的事情疲于奔命，被外界的杂事干扰正常的进度，
以致项目进度不断延误，甚至停滞不前了。
保护程序设计师不受任何阻碍和干扰
如果我带的不是程序设计师，而是主管。
前面的讨论中，我假定您是程序经理，带的是程序设
计师，但是如果您带的是测试人员、文件撰写人员或是其
他类型的小组，您的原则还是一样的。基本上，身为主管
的重责大任就是让属下专心做他该做的事，不论他该做的
是写程序、测软件还是写文件。
16
微软研发
致胜策略下载
就算您带的全是主管，您也应该决定哪些工作是不必
要的，尽可能免除。开个会了解各位主管们手上项目的进
度，和开个会了解各位程序设计师们手上程序的进度，都
一样是浪费时间，特别是独立进行项目的主管，没有必要
让一位主管了解与他项目无关的概况。主管的时间对产品
影响也很大，浪费主管的时间，他就没有办法做他该做的
事—排除程序设计师的工作障碍。
一定有更好的方法可以减少干扰
身为经理，我在项目的每个阶段都会问自己一个问题：
“我努力的目的究竟是什么？”
我总是不断用这个问题提醒自己，因为太容易被不重
要的工作拉偏方向了。如果您经常把报告或备忘录东修西
修的，换个字型或样式，结果美化文件的时间比写的时间
还长，您就明白我的意思。因为在那一刻，这件工作占住
了您全部的思绪，似乎是最重要的事情，但只要您随时以
整个项目的眼光来看事情，您就不会陷入细枝末节了。
我们谈过了把时间浪费在进度报告和检讨会议的案
例，现在您应该可以回答这个问题：
17
微软研发·致胜策略
奠定基础下载
“我举行进度会议和要求进度报告的目的究
竟是什么？”
我想，主要的目的是了解项目进行的状况，以便及早
发现任何进度上的延误，避免项目发生进度失控，不是
吗？假定没有发生延误，每一个项目都如期完成，也没有
人需要加班，那还有必要报告进度吗？当然不必了。
如果您开进度会议和要求进度报告目的，是想确定项
目进度有没有落后，有必要动员全体去收集这些信息吗？
我不这么认为。我从来不开进度会议，不论我是带新的项
目或是接手其他人带了一半的项目，我第一个废除的就是
这类没有意义的流程，我就是不相信非得用开会写报告的
方式才能掌控项目的进行状况。
至于进度报告呢，它究竟有多重要？我认为进度报告
虽然令人厌恶，但却是必要的，经理总得了解项目是否出
了问题。但请别忘了，进度报告虽然必要，但是它绝对不
会对产品有任何帮助。所以，当您遇到一件必要但对产品
没有帮助的工作，您得寻求这个问题的答案：
“我该怎么样保有这项工作的好处，消除它
的缺点？”
18
微软研发
致胜策略下载
进度报告确实有重要的目的，但得花时间去写，而且
令组员心生反感—至少在微软曾经有不少团队深受其
害。
如果一位程式设计师要花几个小时写报告，交代自己
做了什么工作、解释这件工作为什么花的时间比预计的长，
那的确会对他造成过度的压力，并且让每个人预定项目一
定会延误。更常见的现象是，程序设计师明明每天卖力工
作至少1 2小时，而且没有磨洋工，整整工作了8 0小时之后
即发现他只完成了本周日程表上27小时的工作。
进度会议（Status Meeting）的用意
我想，每家公司的进度会议都不完全一样，我所指的
进度会议，是指每个人坐在一起轮流讲讲自己做了什么，
或是没做什么，只有这个用意。
还有一种进度会议，其用意不是讲述各人做了什么或
是没做什么，而是同一项目中不同小组的协调，只有多小
组项目（multi…team project） 才有这个需要。每一个小组的
组长并不报告各事项进行的细节，而只提出会影响其他小
组的事项，例如上游工作进度比预期的慢，或是目前已经
完成可以交付下游工作小组，或有一件事希望别的小组配
19
微软研发·致胜策略
奠定基础下载
合或支持等等。这种进度会议是为了协调小组之间互相依
赖的工作事项。任何需要等待别的小组做完才能开始工作
的下游小组，都需要预先知道上一小组的工作情况如何，
而且每一位应该尽早知道，这对于制定下游小组的工作进
度是非常重要的，不然会临时手忙脚乱，或是影响整个项
目的进行。
但是真理依然不变，程序设计师是不该被这些事情干
扰的，小组的组长去开会就够了。
如果您没有过这种痛苦的经验，请试着想像一下：您
已经是拼尽全力加班了，但永远赶不上进度，目标离您仿
佛愈来愈远，那会多么令人沮丧！更别提您不敢浪费一分
一秒，每天都累得像狗。假如这种情况是日复一日、年复
一年，您还能每天早上精神抖擞地跳下床，满怀热忱去上
班吗？或者更可能的是，您心中充满愤怒、挫折、沮丧，
愈是努力工作，工作积压愈多，结果进度愈落愈远，天
—啊。。！
我恨进度报告，因为它迫使程序设计师想着自己没做
的事，而不是强调自己完成的事。组员无法感受到逐渐推
进目标的快感，反而随时被提醒：进度落后了喔，项目不
20
微软研发
致胜策略下载
晓得会不会莫名其妙地搞砸。他们只知道自己工作确实很
尽心尽力，但实在不知道如何跟上进度。
团队也和个人一样。如果团队觉得整体不断往前进，
那么就会一直保持前进，而如果团队觉得自己一定会落后
进度的，那么，惯性和自我预示的心理就会使它相信自己
是永远的失败者，导致士气非常低落。
请不要误解我的意思：如果一位程序设计师明明工作
了8 0小时，却只能完成进程表上2 7小时的工作，那一定有
什么地方搞错了；也许他最近做了太多人员面试的工作，
或是开了太多的会，或是最近e…mail 太多，或是他正在调
整自己的情绪，主管应该和他一起找出问题。但是，即使
是他个人不懂得善用自己的时间，也不该用进度报告使他
难堪。我们待会儿有更好的方法解决这个问题。让我们回
到前面提出的问题：如何保持进度报告的好处，又不必忍
受它的缺点？其中一个答案是设计一种新的进度报告，非
常容易写，既不花时间，且内容是正面性的。
以下是我的方法（我相信您一定可以想出更多更好的
方法）：
◆ 每当有人完成了一项新的功能或特色，就发个e …
mail 给大家。
21
微软研发·致胜策略
奠定基础下载
◆ 每当进度快要落后了，就到我的办公室私下讨论原
因，我们一起开动脑筋寻求解决之道。
就这么简单。依我的方法，典型的进度报告可能是这
样的：
“我已完成Faxmangler 的搜寻与取代功能。Frank”
主管应该看一下结果，然后回一个：
“我检查过F a x m a n g l e r的搜寻与取代，不太顺畅，请
再修改。Hubie”
或是：
“很好，继续加油！Hubie”
想想看，如果大家经常收送这类正面的e … m a i l，一定会
觉得充满干劲，这和可恨的进度报告多么不同！程序设计师
会很乐意看见这类的好消息，当自己送出完成工作的信息时，
也会很有成就感；没有人会觉得这是很讨厌的报告。当某位
程序设计师觉得自己可能要落后了，我会和他谈，研究将来
如何避免这种事情。是我们在制定进程时疏漏了某一个重要
环节吗？或是时间表定得太乐观了？是不是有个错虫（ b u g ）
在作祟，害得程序很难写或无法测试？不论问题是什么，我
们一定想办法解决掉，并且预防它将来再发生。
我只要靠这两种方式，就可以完全掌握项目进行的概况。
22
微软研发
致胜策略下载
上级要求的话，我也可以轻松写出项目演示文稿，根本不必
劳驾别人，所以我带的程序设计师不会因此而被打扰。
更棒的是这两种反馈方式产生了双重好处：第一，团
队成员经常感到项目又向前迈进了一步；第二，这对主管
和属下都是很好的学习机会，我们不会耸耸肩，无所谓地
说：“反正进程一定会落后的，没啥大不了。”因为我们会
认真面对问题，商讨对策。
为了强调进度报告的正式性，而把它弄成一件沉重不
堪的工作，这就是主管过度重视进度而忘了自己真正的目
标。结果陷入了流程的陷阱，倒把产品丢在一边了。
只有当您非常清楚您和您的团队该做的是什么，您才能
用最少的时间和最少的挫折去完成项目目标。回头检讨一下
遭遇过的困难； 有没有办法可以改善？有没有更好的方法，
让工作愉快些？至于那些对产品没有帮助的杂务，如果可能
的话，还是免了吧—至少不要把它丢给程序设计师。
永远记得自己真正的目标，然后让团队用最有效
又最愉快的方法把它完成。
23
微软研发·致胜策略
奠定基础下载
被成功的喜讯围攻了？
您可能会有这样的疑问，如果每个人都把自己完成某
件事的讯息发给大家，会不会塞满了每个人的电子信箱。
实际的情形是，每天的e…mail 并不多，因为信息不会送给
每个人，而是只送给同一组的四到五位程序设计师而已。
微软比较大的团队可能有多达50 位的程序设计师，
但是都会分成小组，每一个小组大约有五到六人。每一个
小组负责项目的一部分，有一个明确定义的目标，有一位
组长，也有自己的进程。小组内的程序设计师当然也属于
整个团队，但是以每天的程序开发工作而言，只与四五位
程序设计师有关而已。
事实上，即使是50 位程序设计师的大型团队，每个
人收到的“完成ＸＸ”的e…mail 也不多，数量稳定，刚好
够让每个人感觉到工作的进行，绝无爆炸之虞。
明白说出目标
您所认识的人中，有多少位一早起来突然发现奇迹，
选了几门神奇的课程就拿到了计算机硕士学位？有多少人
随便收拾一下东西就搬到了您的隔壁？听起来不太可能
吧。没错，一般人不会兴之所至就去修个学位或搬家，这
24
微软研发
致胜策略下载
些都是计划过的，他们会决定：“我要成为程序设计师”
或是“我要住在迪士尼乐园旁”，然后筹划一番，再采取
行动，才会达到目的。
可是，生活中的确有些事情是不经意就发生了，您可
能靠运气就得到一份好工作，或是福星高照在股市捞了一
笔。很不幸，推出一套软件的目标，并不比“我们要完成
WordSmasher”具体。
不错，大部分的时候您都可以完成目标，但问题是，
在这之前，有多少时间被浪费掉了？虽然您运气好，得到
了一份理想的工作，但之前也许有好几年频频跳槽；或者
您先细细思量自己适合什么样的工作，然后找到符合自己
条件的几家公司寄履历、面谈，会比较稳当？
我所辅导过的案例中，有六个总是在失败边缘挣扎的
团队，他们都有一个共同的特征，就是目标太模糊。其中
一个案例的情况是，小组的任务是做出使用者界面的函数
库，给2 0个左右的其他小组使用，他们做得人仰马翻，还
被别的小组抱怨函数库既笨重，错虫又多，很不好用。
当我和这位组长共同检讨工作清单时，我问他项目的
目标是什么。“为MS…DOS 的应用程序提供像Windows 环
境的使用者界面函数库。”我问他还有什么。
25
微软研发·致胜策略
奠定基础下载
“您的意思是？”
我说，他刚才的答案太模糊，能不能说得更具体些？
“嗯，函数库应该做到零缺点。”
我点点头，再问：“还有呢？”
他想了一下，耸耸肩，答道：“我想不出来了。”
接着，我说明任何函数库的主要目的是存放每位需求
者必要的公用程序，不是大家非得用到的东西是不该在里
面的。他很同意，认为这一点是显而易见的。但当我继续
下面的讨论，我开始不确定他是否真的懂得这一点。我指
着工作清单上的一项，问道：“这是做什么用的？”
“那是Works 小组要求的，是用来。。”
“对其他小组有用处吗？”
“没有，只有Works 小组会用到。”
我指着清单上的另一项，问道：“这个呢？”
“那是给CodeView 小组的。”
“那，这边这一项呢？”
“是Word 小组要的。”
我们一路看下去，我发现他对任何要求都来者不拒。
我想他也知道函数库中应该只有大家都要用的程序，但他
在做决策的同时并没有确实把握这个原则。他的目标只是
26
微软研发
致胜策略下载
“为MS…DOS 的应用程序提供像Windows 环境的使用者界
面函数库”，有没有办法说得更详细些？
目标是为MS…DOS 的应用程序提供像
Windows 环境的使用者界面函数库，只包含对
每个小组都有用的程序。
如果把目标定义精确些，就可以发现很多程序其实是
不应该放在函数库中的。在我们检讨完工作清单后，我开
始研究另一个问题：“很多小组抱怨，函数库中每次一放
入新版的程序，就会发生链接失败，这是怎么回事？”
“喔，那很简单，他们只是忘了修改自己程序中的函
数名称而已。”
这我就不太懂了，于是我请他给我一个实例。他的小
组修改过函数库中的b u g了，或是加强了该函数的功能，
然后就连名称也顺手改了，用另一个更能表达其功能的函
数名称；或者是做了一点小小的修改，然后把函数名称一
道改了，以强调所改的差异部分。
这位组长不了解其他小组怎么会如此大惊小怪，不过
是改个名字而已，非常简单啊。他从来没想过，有20 个
小组要因此检查所有的程序，把所有用到函数库的地方都
27
微软研发·致胜策略
奠定基础下载
改过来；他也没有想到，经常链接失败的函数库是很不好
用的，函数朝令夕改，别的小组会无所适从，根本不知道
程序应该是什么模样才对。
如果这位组长稍微花点时间，从�
