按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
问题：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章中房屋搬迁的例子吧，这也是同样的
道理。房屋搬迁的主管没有事先考虑过最恰当路径，结果
房屋搬进时困扰不断。开会也一样，您必须事先想清楚自
己的目的是什么。
当您问自己：“我希望在这次会议中获得什么结果？”
您等于是强迫自己向前看，瞧瞧前方有没有障碍物需要我
们绕道而行。如果您对未来的目标有清楚的认识，而且知
道要如何达成这个目标，您就会成竹在胸，该请谁来开会、
讨论什么议题、如何导出结论。很多会议之所以无疾而终，
就是因为该做决定的人根本没有出席，或是该提供重要讯
息的人未受邀列席。
当然，无论再怎么努力，会议也有失败的可能：您可
能会开到一半才发现有一项重要信息无法取得，因此无法
做出决策。这时候只好用一句话草草结束：“乔治，看看
133
微软研发·致胜策略
走极端的狂热下载
你能否在两周内完成Anagram 的功能，其他的事我们下
次再讨论。”这样的做法无疑是浪费大家的时间，每个人
聚在一起，却讨论不出个所以然来。如果您的目的是做出
决策，那就起码有个决策才能散会。您可以做个有条件的
决策，总比用以下这句话来结束会议好得多：“假定乔治
对Anagram 的功能所预估的时间完全正确，大家是否都
同意为了这项功能而推迟我们WordSmasher 的推出日
期？”
如果您这样作出总结，到头来就会发现，没有人真的
觉得Anagram 的功能会重要到我们可以为它延后推出日
期，要不然就是认为Anagram 的功能太重要了，即使因
此延后推出日期也无所谓。最好是能得到某种程度的结论：
“假设因为Anagram 所造成的延误在两周以内，我们就这
么办吧！”
这样的结论虽然不如“是”与“不是”那般铿锵有力，
但是总比把决策延到下次不知何时召开的会议好得多。如
果您开会的目的是做出决策，就一定要做到，如果您的目
的是别的，也务必让您的会议有效果。
134
微软研发
致胜策略下载
召开任何会议之前，请确定本次会