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