友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
微软研发致胜策略-第14部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
写报告。奉劝各位明智的主管，绝对不要像我的上司一样，
只知道墨守陈规，而从未考虑对正经事的伤害。
炖肉必须切掉两端
有很多事情因为长久以来大家都这么做，后来就忘了
究竟为什么，结果即使在原因消失之后还是习惯这么做。
有一个故事把这种情形描绘得非常贴切：
有一个小男孩，看到妈妈每次炖肉时都要把肉的两端
切掉，觉得很好奇，就问妈妈为什么。妈妈回答说：“喔，
那是因为我妈妈教我炖肉要这样做。”但被孩子这么一问，
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 项
目的测试报告，我们还要把错虫和清除错虫的
行动记录下来。
您觉得最能够改善软件开发程序的是那一份报告，是
描述问题的报告，提出意见的报告，或是拟出详细改善步
骤的报告呢？
无庸置疑，第三份报告才是最有效用的，因为它提出
了清楚的解决方案、详细的执行步骤、由谁负责、什么时
候该完成、应用在那几个项目。这份报告同时还建议了追
踪错虫成效的检讨方式。第二份报告虽然说明了由谁主导，
企划部应该拟出追踪办法，但没有说明由谁负责，而且也
没有说应该什么时候完成什么样的系统、用在哪些项目中、
是否在实施之后进行成效检查？少了这些，解决方案就没
有说服力。
除此之外，检讨报告应该包括本项目在开发过程中，
值得记录的心得与收获。报告中可以这么说：我们在程序
中加入维护叙述（assertion） 和除错指令之后，竟然发现程
序中到处都是错虫，连那些应该是完全正确的程序中也有
错虫。或者是：刚开始使用除错工具一步步查看程序的进
125
微软研发·致胜策略
走极端的狂热下载
行时，觉得很无聊，但是习惯了之后就觉得很有意义，可
以抓出很多错虫，而且事实上也不影响进度。检讨报告中
也可以有这样的感想：我觉得有一套详尽的项目目标对工
作帮助很大，让我们对真正该做的事保持专注。这些都是
非常不错的内容，我只是举例说明，当然报告中是不止这
些的。
除了将观察或体会到的心得写出来，检讨报告中还要
进一步指出将来应该如何利用这些经验。光是发现那些方
法有效是不够的，大家更应该学习如何充分发挥这些方法
的最大效用。如果有部分组员习惯程序刚写完就立刻用除
错工具检查，并且发现这个方法对预防错虫很有用，就应
该在报告中详细说明做法和相关注意事项，让所有的小组
成员都能够学习这种减少错虫的技巧。
最后，报告中不妨加入作者认为谁应该分享这些信息，
让本报告得以发挥最大的作用，比方说：我们基于某个理
由，将于某日期提供本报告给某某经理。将原因、时间、
人交待清楚。
读和写这样的报告是需要相当的心思和时间的，当然
多少会占用软件开发的时间，但是，其中的教育效果非常
卓著，所以非常值得投资。当然，前提是主管很重视项目
126
微软研发
致胜策略下载
检讨报告，而且确实吸取其中的经验，应用到将来的开发
工作上。如果检讨报告只进入档案柜，却没有进入每一个
人的心中，写得再好的报告也不过是废纸。
顺便一提的是，最好不要等到项目完成了再来回想有
什么值得写（搞不好已经忘了一大半），您应该在每一次遇
到问题、并发现好方法可以解决时，就顺手记下这项发现，
您何必等项目结束时再来学习？经验的累积是随时的。
利用项目检查报告来改进软件开发的工作程序。
为了使报告发生作用，报告中必须确实描述我们
这次解决问题的每一个详细步骤，以及将来应该
如何运用这项新发现。
避免召开会议
在第1 章我曾提过，如果您已经得知项目目前进行的
状况，就不必再召开进度报告会议了。我极力主张应该避
免的周期性会议不只这些，进度报告会议只是其中之一。
“周期性会议”（recurrent meeting） 是定期召开的会议：您
127
微软研发·致胜策略
走极端的狂热下载
一早进到办公室，想到今天是星期二，可别忘了每周二下
午3点的那个某某汇报。
我很少召开会议，因为那会打断组员的工作，影响工
作的顺利进行。我也很不喜欢周期性的会议，因为这种会
议大都没有明确的动机。您去开会是因为真有什么事需要
用开会解决，还是因为“时间到”？有些人认为每周一次
的进度报告会议是不能少的，但是我已经好几年没有举行，
因为我认为开会本身不重要，重要的是您需要项目现况的
信息，如果这些信息可以用更好、更有效率的方式取得，
何必非开会不可？我在第1章已经说过，我的小组用一个
简短的e … m a i l：“我已完成。。”，对我而言，这样就足够
了。
当然有时候开会是很不错的方法，在什么情况下，开
会是利多于弊的呢？以下是我的看法：
◆ 当某个人必须把信息传达给很多人时。
◆ 信息需要双向或多向沟通时，人们必须立即反问发
言人或与会人才能了解信息。
◆ 必须要亲眼目睹或亲身经历，信息才能传达给接受
者，例如产品示范等。
◆ 有些事情用e…mail 很难表示清楚，而要大家一起讨
128
微软研发
致胜策略下载
论时，例如组织再造等。
符合上列条件之一的会议，就是值得召开的会议，但
是如果有更有效率的方式达到同样的目的，还是避免开会
为宜。在古时候，发布信息最有效的方式是大家集合在一
起，由一人宣读羊皮纸上的皇帝诏书，但科技发达的今日，
我们有复印机、e … m a i l、电子布告栏，有很多方法让信息
的传达更有效率，又不会打断手边的工作。当然，如果您
有很重要的事情，面对面开会的方式，会比用e … m a i l的方
式更让与会者感受到这项信息的重要性，而且也能保证每
个人都收到信息；况且，如果您是一位很好的演说家，会
议还可以达到激励的效果。无论如何，在您决定召开一次
会议之前，请花一分钟问自己以下的问题：
“这个会议的结果是否非常重要，即使是中
断这么多人的工作都值得？”
“还有没有比较不影响组员工作的方法，可
以让我达到同样的目的？”
团队精神
我曾听过某些主管说，他们认为每周一次的进度报告
129
微软研发·致胜策略
走极端的狂热下载
很重要，因为可以借机让小组面对面齐聚一堂，有助于团
队精神的培养；我甚至见过有些主管开会的主要原因只是
把大家聚集在一起。这些目的是对的，但�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！