微软研发致胜策略-第20部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


清楚就行，不要什么正式的文体。尤其对于那些想到要写
报告就心烦的人，这是个大好消息。我希望写报告的时间
愈少愈好，给属下的负担愈轻愈好。
“写得愈短愈好？”他们会说：“没问题！”
当然，如果有人想在书面报告中多发挥一点个人观点，
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
微软研发·致胜策略
走极端的狂热下载
很重要，因为可以借机让小组面对面齐聚一堂，有助于团
队精神的培养；我甚至见过有些主管开会的主要原因只是
把大家聚集在一起。这些目的是对的，但是我认为开会是
最差的方法。以我的经验