那天是在开会、写报告、访谈、传e … m a i l，还是一整天不
受打搅，终于想出一个绝佳的点子，或是完成了一件很棒
的程序设计杰作？不必说，您我都知道答案。到目前为止，
我从没见过一个热爱开会或写报告的程序设计师。
以我身为一位软件开发团队的领导者来说，我极力想
达到的目标就是创造一个理想的工作环境，让所有的人都
能尽情发挥，创造出足以自豪的产品。为了做到这一点，
我很努力地让程序设计师免除不必要的报告和会议，尽量
不是为了赶进程而压力过大，任何与改善产品无关的杂事
我都尽量排除；我希望程序设计师安心工作，专心开发产
品。在本章中，我会告诉您为什么这些杂事会伤害生产效
率（尽管这些杂事随处可见，似乎每家公司都是如此），我
116
微软研发
致胜策略下载
也会告诉您如何用比较简单有效的方式达到同样的目的，
而不要让这些杂事淹没了程序设计师以致影响了他们的生
产效率。
无人理睬的报告
有一次我出差回来后，我的上司找我到他的办公室，
问我有关这趟公务的细节。我们谈完之后，他要我把所讲
的每件事都一五一十地写成一份出差报告。对我而言，这
实在是非常浪费时间的事情，所以我问他报告真的非写不
可吗？他很肯定地说是的，所以我花了一整个下午的时间
写报告，项目的事情只好暂时搁在一边。
不到一个月，我的上司又把我叫去，口头询问一个问
题，而这是我在书面的出差报告中早就详细说明过了的，
我能体谅他日理万机，无法记住报告中的每一项细节，但
我忍不住怀疑他到底有没有看过我写的报告，所以我就单
刀直入地问他。哦，答案可真是令我心碎，他一个字也没
看，我把报告交给他的下一秒钟，报告就进了档案柜。
我忍不住有点恼怒：“既然你根本没打算看这份报告，
为什么一定要我写呢？”
我没想到他露出惊讶的表情说：“每个人都要写出差
117
微软研发·致胜策略
走极端的狂热下载
报告，这是公司的政策。”
随便哪个理由都比这个好。他可以告诉我，研究显示
人们对自己写过的东西记忆会深刻些，那我也就认了；他
也可以告诉我，他想要把我的报告呈给上一级的主管或别
的小组看，把报告中的心得分享给别人，那我也可以理解。
但是他明明就不想看，却仍然要我写出报告，再丢进档案
柜，这未免太荒谬了。这就是过度死守规则的错误示范，
规则是该遵守没错，但把规则当作铁一样的法律就太蠢了。
任何公司都一样，凡是没人看的报告就不该写，除非是要
作者加深自己的印象，即便如此，也不是每一次出差都该
写报告。奉劝各位明智的主管，绝对不要像我的上司一样，
只知道墨守陈规，而从未考虑对正经事的伤害。
炖肉必须切掉两端
有很多事情因为长久以来大家都这么做，后来就忘了
究竟为什么，结果即使在原因消失之后还是习惯这么做。
有一个故事把这种情形描绘得非常贴切：
有一个小男孩，看到妈妈每次炖肉时都要把肉的两端
切掉，觉得很好奇，就问妈妈为什么。妈妈回答说：“喔，
那是因为我妈妈教我炖肉要这样做。”但被孩子这么一问，
118
微软研发
致胜策略下载
妈妈自己也开始疑惑，于是就去问外婆，外婆说：“说实
话我也不知道，我妈妈以前都这样做，所以我也是有样学
样。”这就奇怪了，于是妈妈就再去问曾外婆，曾外婆说：
“喔，那是因为我那个年头的锅子都很小，除非我把肉的
两端切掉，否则肉放不进锅子啊。”
我的上司就是如此，只一味地墨守陈规，不去了解背
后的原因，所以就永远不知变通。要我写一份没有人看的
报告，很显然不合理，但他仍然这么做，因为他只在形式
上遵守规定，而不肯去了解写报告的理由。事实上，我后
来发现，并不是每次出差都硬性规定要交报告。
有一些出差报告确实值得一写，像是DEX 这样
的信息商展盛会，公司派去参加的同仁应该一回来就把所
见所闻写出来让大家分享。这种报告中应该充满对信息产
业的敏锐观察和明智的见解，像某一种新趋势逐渐成形，
竞争对手出了什么招数，造成了群众什么样的反应。。每
当DEX 信息展结束后，出差报告就会塞满了电子邮
件信箱，而这都是非常宝贵的信息。
但并不是所有的出差报告都有价值。也许您去了一趟
印第安纳州的科克莫（Indiana； Kokomo），解决一个您在办
119
微软研发·致胜策略
走极端的狂热下载
公室里已经抓到的错虫，这种事情实在不值得写报告；如
果您刚好去总公司，在经过大厅时顺便帮别人抓到了一只
错虫，难道这样也要写报告吗？我觉得不必。如果您出差
到顾客的公司时，顺便帮顾客把他们的错虫抓到了，要不
要写个报告？至少在微软是不要的。大部分的情况是，如
果您开车两小时到市郊，替顾客解决一个问题，那您大概
不必写报告，但如果您坐2 0分钟的飞机到另一个城市，您
很可能必须交出一份报告才能证明公司没有白费机票钱。
这好象是和业务无关，只和报账有关。
我曾经大力主张，主管应该全力扫除那些阻碍目标而
不必要的工作，像这种没有意义的报告就是其中一种。除
非我认为这个会议重要到可以打断程序设计师的工作，否
则我尽量不召开。同样地，除非很有必要，我也不会要求
他们写报告。我宁愿他们去做开发工作、和其他的同仁互
相切磋技术，我也不要他们写一份其实不需要的报告。我
认为，除非有充分的理由，我不应该剥夺他们写程序的时
间，打断他们进行到一半的构想。
我很少要求我的组员交报告，因为我认为大部分的报
告都不值得中断他们正常的工作。即使我觉得需要报告，
我也倾向口头的报告，一方面是双向沟通，我可以反问他
120
微软研发
致胜策略下载
们问题，一方面是不用花太多时间， 5分钟到半小时就够
了，比起写报告快得多。
有些人一听说要写报告就头大心情坏，您过了三个小
时再去看他，准会发现他在文字处理器前面发呆，只写出
寥寥数语。对于某些人，写报告就好像是对着一大群人演
讲一样令人浑身不自在。
写报告的另一个问题是，如果您不说清楚究竟要的是
什么样的报告，交上来的东西可能是拉拉杂杂的一大篇您
根本没兴趣的文字。很多人觉得报告一定要篇幅够多，才
看起来有报告的模样，或者是一定要文诌诌的，才会感觉
到这份报告够水准，结果明明很简单的一句话可以表达清
楚，却弄得嗦一大串，这类的报告不但是写的人累，
看的人也觉得很累。这种报告就像是电视机的测试报告，
架势十足，但是看不懂。
当我请属下写报告时，我都要求愈短愈好，而且表达
清楚就行，不要什么正式的文体。尤其对于那些想到要写
报告就心烦的人，这是个大好消息。我希望写报告的时间
愈少愈好，给属下的负担愈轻愈好。
“写得愈短愈好？”他们会说：“没问题！”
当然，如果有人想在书面报告中多发挥一点个人观点，
121
微软研发·致胜策略
走极端的狂热下载
我也很欢迎。有些人比较喜欢书面报告，因为用写的比用
说的容易理清思绪，尤其是当报告的目的是说服别人时，
用文字比用语言有效。书面的报告可以帮助作者更审慎地
思考他的建议，也可以帮助读者更清楚报告的内容。总之，
我的目的是让属下用最少的时间和最少的打搅，让我获得
我真正需要的信息。
写报告和开会一样，对开发工作都是干扰，所以除非
真的有必要，尽量不要打断属下做该做的事。
确定您所要求的报告真的值得属下暂停工作，花
那么多时间去写。
好报告、坏报告、束之高阁的报告
有一种很值得花功夫写读的报告，就是项目的检讨报
告，也就是开发小组在产品刚完成不久所写的分析报告。
分析报告主要是针对“我们能从刚完成的项目中学到什
么？”这类的主题进行探讨，并且检讨我们哪里做对了
（就继续这样做），哪里做错了（下次如何避免再犯）。项目
122
微软研发
致胜策略下载
的检讨报告很重要，因为这会促使组员主动而认真地思考
如何改进开发程序。
我很喜欢阅读项目的检讨报告，因为里面有许多宝贵
的信息。但是非常可惜，我经常看到很好的见解，却没有
实际的效用，因为少了下一步──如何做到。有一回，我
读了同一项目的检讨报告发现，每一份的开头都是“我们
应该在项目一开始时就在程序里加入除错用的指令”，接
下来是“我们应该早点开始抓错虫，而不是等到项目快结
束时才进行”。当然这是很好的意见，但是很不幸，这两
个观点一再出现在每一份检讨报告中，表示这个教训并没
有被大家放在心上。
如果您正准备写一份项目检讨报告，我诚恳地建议您，
除了指出您发现的问题，提出您的看法和意见，还要建议
如何防范这个问题，把详细的步骤一并写出来，这样才能
让下一次的项目进步，不重蹈覆辙。这样的报告就很有建
设性。我想前面所提的小组一定是把写出来的项目检讨报
告束之高阁，再也不去看它，因此不论报告写得多详细，
同样的毛病仍然一犯再犯。
有时候检讨报告确实有包括改进事项的实施步骤，但
是不够明确具体，因而流于不切实际。举例来说，有几份
123
微软研发·致胜策略
走极端的狂热下载
检讨报告是这样写的：
问题：Mandelbrot 软件包的Beta 版试用者
觉得他们的测试报告好像都没有人注意，因为
同样的错虫每一版都出现。这主要是因为我们
没有建立一套系统的方法去追踪外部的Beta 测
试报告。所以，我们将来应该更加小心地追踪
外部的Beta 测试报告，并加强后续处理。
大部分的情况下，检讨报告这么说过就算了。偶尔会
有人比较认真，提出更明确的做法：
解决方案：企划部门应该草拟较佳的办法，
追踪外部的Beta 测试报告。
这样还是太笼统了，很难得会有小组真正做出切合实
际的检讨报告：
解决方案：由于对Beta 测试报告的疏忽，
不仅影响了Mandelbrot 项目， 也影响了
Biorhythm 和Morph 两个项目。Hubie 经理已经
同意重新考虑三个追踪错虫的系统— B u g
C o n t r o l、P r o g r a m m e r’s Database 和F i x I t ！，我们
124
微软研发
致胜策略下载
将在三者中择一使用，以便追踪Mandelbrot 项
目的测试报告，我们还要把错虫和清除错虫的
行动记录下来。
您觉得最能够改善软件开发程序的是那一份报告，是
描述问题的报告，提出意见的报告，或是拟出详细改善步
骤的报告呢？
无庸置疑，第三份报告才是最有效用的，因为它提出
了清楚的解决方案、详细的执行步骤、由谁负责、什么时
候该完成、应用在那几个项目。这份报告同时还建议了追
踪错虫成效的检讨方式。第二份报告虽�