按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
这并不是震惊世界的大发现，而是极简单的道理，但
是，有多少软件开发主管是真的把“消除程序设计师工作
上的障碍”当作积极追求的优先目标，而且确实做到呢？
如果刚才提到的那位经理真的用心去减少组员不必要
的工作，我确信他可以想出更简单有效的方法掌握工作进
行的状况，而不必一再浪费组员的时间开会和写报告。
千万不要把程序设计师的时间浪费在改善产品以
外的工作上。
请不要从字面上解释我的话
我所谓的不要把程序设计师的时间花在改善产品以外
的工作上，请不要从字面解释成程序设计师只许写程序。
事实上，思考如何设计、测试程序和接受需要的训练等等，
虽然不是直接投入在改善产品上，但对产品品质却有重大
深远的影响。如果程序设计师在动手写程序前，仔细思考
过产品的设计，把缺点改正，当然会比一味地埋头苦干要
好得多了。
13
微软研发·致胜策略
奠定基础下载
有些团队的活动，用意是让团队成员在愉快的环境中
工作，提高程序设计师的生产力和士气，虽然看似与产品
无关，最后还是对产品品质与工作效率有正面的帮助。
排除干扰
如果您希望团队能在期限之内完成好的软件，就必须
尽可能排除一切不必要的工作，特别是您打算分派工作给
全体组员之前，请等一下，问问自己，这件工作真的有必
要叫大家做吗？能不能由您自己做呢？比方说，如果您要
准备向上级报告项目概况，非得要所有的程序员停下手边
的工作，为每个程序写一份摘要吗？我倒不这么认为。身
为经理，您应该平时就对项目的进度及一切的状况非常清
楚，不必靠人帮忙就能做出切中要点的演示文稿，而且信
息已经存在脑海中，比起再去汇总整理一堆人的报告应该
是快得多，也更好组织。或许这要花掉您几个小时，但总
比打搅整个团队去做一件与产品无关的工作要好。
我通常会做得更彻底一点。如果我发现一位程序设计
师总是被不能不做、却与产品无关的工作绊住，我会主动
解除这件工作，由我来做好了，这样程序设计师就能完全
专心在软件上面。除非是为了训练，否则没有任何理由要
14
微软研发
致胜策略下载
求程序设计师本人回复e…mail，询问项目的e…mail 交给适
当的经理来回答就行了。凡是能由主管出席的会议或能由
主管执笔的报告，都不应该丢给程序设计师，最好能把这
些开会、报告都废除。
我知道这些建议与大部分的管理课程或教科书上所指
的授权（delegation） 有所冲突，我并不是说这些课程和书籍
错了，而是您在实际工作中应该放聪明点，对于工作的分
派应该更有选择性。如果把工作分出去的目的仅仅是为了
减轻个人负担，实质上您做的是伤害团队生产力的事情。
别人“能”做某件事，并不代表他“必须”做那件事。
您看过整个房子的搬迁吗？我不是指搬家，而是整个
房子从地基上拔起，用车拖着移到别的地方（美国的房子
多是木造的，可以这样搬移）。我们可以把项目比喻成那
间房子，把经理想成开路先锋，他的责任是把前面所有的
障碍物排除，让房子能一路不停地稳定前进，而不是走走
停停，停停走走。
房子前进的时候，领导者不希望每到一个路口就停下
来处理红绿灯，或协调其他的车子让路。他必须事先就规
划好最理想的路线，在房子抵达路口之前，就协调好工程
人员卸下悬挂着的标志灯或是电线等会阻碍行进的东西，
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
微软研发
致胜策略下载
上级要求的话，我也可以轻松写出项目演示文稿，根本不必
劳驾别人，所以我带的程序设计师不会因此而被打扰。
更棒的是这两种反馈方式产生了双重好处：第一，团
队成员经常感到项目又向前迈进了一步；第二，这对主管
和属下都是很好的学习机会，我们不会耸耸肩，无所谓地
说：“反正进程一定会落后的，没啥大不了。”因为我们会
认真面对问题，商讨对策。
为了强调进度报告的正式性，而把它弄成一件沉重不
堪的工作，这就是主管过度重视进度而忘了自己真正的目
标。结果陷入