微软研发致胜策略-第13章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
他们写报告。我宁愿他们去做开发工作、和其他的同仁互
相切磋技术，我也不要他们写一份其实不需要的报告。我
认为，除非有充分的理由，我不应该剥夺他们写程序的时
间，打断他们进行到一半的构想。
我很少要求我的组员交报告，因为我认为大部分的报
告都不值得中断他们正常的工作。即使我觉得需要报告，
我也倾向口头的报告，一方面是双向沟通，我可以反问他
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
微软研发·致胜策略
走极端的狂热下载
很重要，因为可以借机让小组面对面齐聚一堂，有助于团
队精神的培养；我甚至见过有些主管开会的主要原因只是
把大家聚集在一起。这些目的是对的，但是我认为开会是
最差的方法。以我的经验，这种会议事实上都在报告谁手
上的什么工作还没做完，这种会议对团队精神有害无益。
如果您的组员不喜欢聚在一起头脑风暴，您就得为他
们制造一些共同活动的机会。如果是为了培养团队精神，
来个全体聚餐，或是安排大家喜爱的活动，会比报告进度
的会议更有效果。
当您考虑是否召开产品设计会议，那么思考过前面的
两个问题之后，您就会发现召开产品设计会议是很值得的，
即使不得不打断组员的开发工作。产品设计会议确实能改
善产品，大家能借此机会充分讨论各种意见，对各种设计
上的论点做最适当的取舍权衡，对产品产生更清楚的共
识；虽然暂时让大家离开手边的工作，但对日后的项目进
展有非常大的帮助。用e…mail 来讨论的话，效果就不会这
么好，e…mail 并不适合用来做头脑风暴。
但是，如果把产品设计会议定成每星期二下午3点，
定期召开呢？我可不认为这是个好主意。除非您已经定好
130
微软研发
致胜策略下载
了一系列的议程主题：本周讨论内存管理，下周讨论档案
处理，再下周讨论使用者界面。。即使如此，我仍然不觉
得定期的产品会议有什么意义，它很可能是这样的开场白：
“这个星期有没有新的设计问题需要讨论？”假设有这样
的问题需要讨论，我想也不该等到了定期会议时才说出来，
应该在发现设计问题时立即提出，如果严重到需要大家讨
论才能解决，您可以召开临时性的特别会议。您应该把开
会时间保留给真正需要的时机，而不是先定期开会再看有
没有问题要讨论。
请注意定期会议的价值，确定它值得每个人放下
手上的工作。
适当的开会时间
如果您实在非开会不可，请尽量不要中断做了一半的
工作。不要把时间定在上午1 0点或下午3点，这样会把上
午或下午的时间切割得太零碎，最好排在一清早、快下班
前，或是下午工作时间的开始。换句话说，把开会间排在
131
微软研发·致胜策略
走极端的狂热下载
时段的最前面或最后面，不要把这个时段切割，就可以尽
量减少工作的中断。
另一个方法是把所有的每周会议集中在同一个时段，
例如星期一上午或星期五下午，因为这是工作效率最差的
时段，因此不妨把所有的会议集中，让其他更有生产力的
时段保留给更重要的工作。
让会议有效果
即使我很讨厌召开会议，也不喜欢参加会议，我还是
得承认有一些会议是必要的。既然是必要的，我们必须尽
量让会议有效果，去其弊取其利。我们如何从会议中获得
最大的效益，又将它的缺点降到最低呢？
会议的目的在于获得结论，但必须耗费时间成本。有
时候因为开会的目的对与会者而言不够明确，以致无法得
到共识，只是白白浪费时间，所以，为了让会议有效果，
您必须一开始就明确定出究竟要做到什么，并拟出一串计
划。
一旦您确定某一会议是必须举行的，在发出开会通知
前，请先问自己这样的问题：
132
微软研发
致胜策略下载
这次会议的目的是什么？我希望在这次会
议中获得什么结果？我该怎么做，才能确保我
的目的能够达到？
如果您能清楚回答以上的问题，那您就比较能掌握开
会的效率，不会让会议变成漫无目的的讨论。
记得我在第3章中房屋搬迁的例子吧，这也是同样的
道理。房屋搬迁的主管没有事先考虑过最恰当路径，结果
房屋搬进时困扰不断。开会也一样，您必须事先想清楚自
己的目的是什么。
当您问自己：“我希望在这次会议中获得什么结果？”
您等于是强迫自己向前看，瞧瞧前方有没有障碍物需要我
们绕道而行。如果您对未来的目标有清楚的认识，而且知
道要如何达成这个目标，您就会成竹在胸，该请谁来开会、
讨论什么议题、如何导出结论。很多会议之所以无疾而终，
就是因为该做决定的人根本没有出席，或是该提供重要讯
息的人未受邀列席。
当然，无论再怎么努力，会议也有失败的可能：您可
能
