微软研发致胜策略-第18章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
把做决策的责任推给别人，因此，我要他在提出问题时，
做到下面几点：
◆ 向我解释整个问题。
◆ 有系统地描述他所想到的解决方案，包括他赞成的
和反对的。
187
微软研发·致胜策略
学无止境下载
◆ 告诉我他选择的解决方案，并解释理由。
在这位组长照着我们的“约法三章”做之后，我对他
的印象马上大幅扭转，其实他的思虑还挺周详的。十之八
九我只要对他说：“很好，就这么做。”就行了，偶尔我们
会有不同的意见，我就把我的看法解释给他听，两人讨论
一番，他就会有全新的见解，有时候是我会有全新的看法。
有时候我会有不同的建议，纯粹只是因为我俩观点上的不
同，其实我的建议执行起来未必最有效，这时候我们就决
定还是照他的方法做。
这种新方法对我们两人都没有增加什么负担，但是我
们的结果和两人的关系却是比以前改善太多了。以往我总
是觉得他要别人代他做决定，现在我欣赏他自己做的决定，
我对他的态度也有1 8 0度的转变，从“这家伙太依赖别人，
自己从来不去用脑筋”变成“这小子真是考虑周到，决策
都很正确”。他自己的态度也有相当显著的转变，从非常
害怕做决定、害怕做错，变成相信自己深思熟虑后的决定。
渐渐地，我们连那种“我该怎么办”的讨论都变少了，最
后完全消失，现在他只有遇到真正无法独力解决的难题才
来找我。
是什么造成这样大幅的转变呢？我并没有对他施予什
188
微软研发
致胜策略下载
么训练，他也没有刻意培养什么才能，只不过是沟通方式
上的一点小小调整，只因为我发现他过度依赖时立即着手
改善。这就是小小的改变、大大的效果。
一发现某处需要改进，就立即采取更正的行动。
马后炮式的管理
请注意我是在发现那位组长的问题时立即把我的看法
告诉他，而不是把我的意见反映在他的年终考评上，我从
不认为年终考评对于个人的成长计划有什么帮助。我的经
验是，主管对属下的表现有任何意见都应该立即表示出来，
迟来的纠正通常毫无效果—除非年终考评不只指出缺
失，还能够提出务实有效又详尽的改进计划。年终考评的
另一个缺点是，主管大都很难在这么长的时间后，对组员
的成长作出正确的衡量。
我们都听过许多有关考评争论的故事。主管在年终考
评时给某一位程序设计师很差的成绩，但是在一整年中从
来没有提过对他什么地方不满意。受到考绩的意外打击，
189
微软研发·致胜策略
学无止境下载
程序设计师震惊得连说话都结结巴巴了，向主管问道：
“您能不能举出一个例子，告诉我，这是什么道理，我表
现得这么差吗？”主管愣了好几秒钟，终于想出一件这位
程序设计师做错的事情，是的，那件事的确是他的错，但
是就为了这件事情就给这位程序设计师的“全年”考评这
么差的分数，听起来颇为荒唐，连主管自己也觉得说不过
去，于是再搜索枯肠、用力想想这位程序设计师做错过什
么事，但是通常都因为时间过去太久而根本想不起来。
程序设计师眼看着和主管也沟通不下去了，只好黯然
走开。稍微有时间思考刚才的对话之后，他就会气愤不已：
“为什么他从来不告诉我什么地方做错了，等到年终考评
再来放马后炮？如果我根本不知道自己哪里不好，我怎么
可能改进？”
这种故事我听过不知道多少遍了。
如果足球教练也这样做，那结果不知道会有多惨，难
道要等赛季结束、战绩为零时，教练才告诉球员哪里不对，
需要改进吗？
“疯狗，我决定下一季要你坐冷板凳。”
“什么？我不懂，我觉得我踢得很好呢。”
“是踢得不错，但是每次球要传给你时，你接球的反
190
微软研发
致胜策略下载
应都不够快。”
“我是这样吗？”
“没错。而且你因此而漏接到不少机会球，在你改进
这一点之前，我必须罚你不准上场，当然，这也就是说，
你的薪水将从520 万美元掉到不足2万美元。不过别担心，
你还享有各种福利，赛季中有免费的饮料和热狗，买纪念
品时还可以打折。”
疯狗这时候可真是疯了，向他的教练咆哮道：“既然
你看见了我接球不够敏捷，你为什么不早点告诉我？我可
以改的啊！”
“喂，我现在就在告诉你啊，而且赛季的检讨报告就
在这里，写得不够清楚吗？拿去，这是你的新合约。”
听起来很蠢，不是吗？但是很多管理者事实上就是这
样做，而且做了很多年。我刚才说的那位从依赖中学习独
立的组长，如果是在别的公司，不幸遇到马后炮型的主管，
结果会怎么样呢？他的考评表上会写着：
太依赖别人替他做决定，自己无法独立思
考。
经过一阵交换意见后，对问题的改进计划可能是这
191
微软研发·致胜策略
学无止境下载
样：
我不再依赖别人为我做决定，我以后会彻
底地思考每一个问题。
这种改进计划太含糊，不可能有任何效果，更谈
不上改进后的衡量指标。计划中没有说明要这位组长
做什么、怎么做、如何衡量成效，这样的计划根本行
不通。在明年的年终考评会上，同样的戏码将再度上
演一次。
我所见过的年终考评大都毫无用处，所以也不必管其
中的评语和新目标了。立定目标何必一定要在年终呢？主
动找出需要改进的地方，把它和项目的阶段性目标结合，
这就是最有效的学习方式。而正式的年终考评是回顾并记
录员工一年之内的成长，这才是高级主管应该要的。如果
只是把员工在一年内需要改进的地方，一条条列给高级主
管看，并没有表达出什么实质意义，反之，记录下员工确
实学习到的重要技术、以及他们如何运用这些技术帮助项
目的进行，既能具体描述员工的贡献，也让高级主管看出
员工的进步，好让高级主管正确评定是否调薪、核发工作
奖金、或是升迁。
192
微软研发
致胜策略下载
不要用年终考评来订立学习目标，要利用年终考
评来记录个人的成长。
全方位的才能
我在微软面试过的程序设计师大都是即将毕业的大学
生，但是偶尔我会面试到想跳槽到微软的在职程序设计师。
我发现已经进入社会工作的程序设计师中，即使工作资历
相当，来自小公司的人，几乎都比来自知名大公司的人能
干得多。起初我觉得很惊讶，后来我发现其中的缘故，是
由于大公司的人往往专注于某一个领域，因为公司有足够
的财力让他们分成三十组，每一组只有一个专长，而小公
司就没这么奢侈，一个人要顶好多人用，因此每个人都得
学习多方面的技术才能应付得来。这也就是我在本章提过
的重点：全方位学习和随时学习。
身为一位组长，即使您有充足的预算聘用专家，您也
得创造学习的压力和气氛，不论是由您亲自教授，还是让
组员去上课、读书或参加研讨会，都是非常好的学习方式。
193
微软研发·致胜策略
学无止境下载
只要学习是持续的，让组员保持不断的进步，您就会逐渐
提升公司内“一般程序设计师”的技术水准，就像冬季奥
运会的花样滑冰选手一样，不断挑战极限、突破极限。这
样的话，不管是对您的组员、项目或是公司，都是极大的
好处，最后，您的顾客也是赢家之一。
重点提示
绝对不要让组员一直做同样的工作，这样
是限制了他的学习，使他停滞在原来的领
域。一旦程序设计师精通了某一个领域，
就让他换别的领域做做看，永远让他们学
习新的技术。
各种技术的用途范围有所不同，有的技术
在一般的项目都用得上，有的技术只有在
特定性质的项目才用得上。当您训练您的
组员时，必须让他们的技术能在公司发挥
最大的用处，最好的办法就是，把应用范
围最广的技术放在训练的最前期，应用范
围最小的技术放在最后训练。
194
微软研发
致胜策略下载
优秀的程序设计师是项目经理最需要的，
所以经理们通常舍不得让自己手下功力最
强的人到别组去，但是如果这位第一高手
在本组内再也没有新东西可学时，经理就
应该让他到别的项目去，一方面他个人可
以重新开始另一次的成长，一方面让接替
他的人学着承担重要的工作，最后公司的
平均程序技术水准因而提升，对大家都很
有好处。
为了确保每位程序设计师的技术都在稳定
地进步，一定要让每个人有个努力的目标，
最好的方法是把个人的成长和项目每两个
月的阶段性目标相结合，这样一年就有至
少六次的进步了。假定一位组员在公司待
了五年，那么他就学了3 0种新技术、或是
读了3 0本好书、或是1 5项技术加1 5本书，
对他的工作能力影响多大啊。
最好的成长目标是出于当时的需要。如果
您发现有位组员工作缺乏效率，或总是在
195
微软研发·致胜策略
学无止境下载
犯同样的错误，最好抓住机会立即为他立
一个目标，并且要求他立刻开始改进。这
种当时设立的目标让人印象深刻，又是马
上寻求改善，效果通常会非常好。比起年
终考评那种模模糊糊的建议，更能引起程
序设计师的重视。
196
微软研发
致胜策略下载
下载
第7 章
态度问题
7
Chapter Seven
在第6章中，我主要在强调学习的重要性，组员的
技术和知识应该精益求精。让组员接触他没做过
的新工作会促使他学习，鼓励他多看书、养成良好的程序
习惯会有更好的结果，但是还有一种最深度的改善，发自
程序设计师内心的，就是开发软件产品的良好态度。
错误的态度
我在第1章中提到过一个基本概念，就是专业的程序
设计师应该在合理的时间内，开发出有价值，而且零错误
（bug…free） 的程序代码。但是很不幸的是，要写“零错误”
的程序实在很难，否则每个人都能写程序了，何必要专
业。
在软件业有一个公认的观念，就是错虫是无法避免的，
而且除了发现错误时把它清除之外，没有什么好的对策。
虽然这个观念如此普遍，却是大错特错。零错误程序是可
以达到的目标，只不过需要额外的努力，而通常程序设计
师不愿意为这个理想付出，除非他们真正了解“零错误”
对软件产品开发的重要性。
有一个非常简单的方法，我经常用，就是在编译程序
时，选择预警功能（warning option），也就是让编译器来帮
198
微软研发
致胜策略下载
您找到比较明显的错误，编译器会警告您这里可能有错虫，
并且把原始程序代码列出给您参考。例如很多C 语言的
编译器都抓得到这种错虫：
if （ ch = tab_char ） /* 注意这是单等号，应该是
才是比较的意思*/
虽然这一句指令是完全符合C 的语法，但却隐含了
一个错误，程序设计师的本意是比较这两者，结果却变成
把ch 的内容设定为tab_char 的值。正确的写法应该是：
if （ ch tab_char ） /* 注意现在已改成双等号*/
让编译器来替您做初步的纠错，显然是很方便的做
法，但是我就看过很多程序设计师拒绝使用这个功能，
他们觉得这些警告的信息看起来很恼人，会干扰自己的
思路，因为有时候就是要在if 条件式中放单等号，编译
器也会不分青红皂白地当作警告列出来。例如这样的i f
条件式：
if （ ch = readkeyboard（） ）
｛。。｝
这段程序代码有两个作用，一是执行r e a d k e y b o a r d （ ），
把传回值留给ch 变量，一是若传回null 字符，则if 条件
不成立。它是正确的，但编译器却会给程序设计师警告，
199
微软研发·致胜策略
态度问题下载
看起来有点烦人，于是就得改成这样：
ch = readkeyboard（）；
if （ ch ！= nul_char ） 。。
或是更简洁的：
if （ （ ch = readkeyboard（） ） ！= nul_char ） 。。
这两种方式都会编译出一样大小的可执行码，差别只
是在明显表示ch 与nul_char 的比较关系，或是隐含表示
二者的比较关系。对于大部分的程序设计师而言，这几种
写法都一样容易理解，而如果要快速浏览程序的话，又以
第三种（只有一行） 最快。
话虽如此，就是有顽固派的程序设计师不肯使用编译
器的预警功能，而认为“我要怎么写程序，是我的自由”
或是“编译器根本就不应该对语法正确的程序代码发出警
告”。如果您看到这些程序设计师对我的建议所表现出的
态度，您真会觉得我是在劝他们扔掉P C，回头去使用打
孔卡片的古董计算机来写程序呢。
这就是程序设计师面对错虫的态度问题了。以我个人
来说，因为我使用编译器的预警功能已经成为习惯，我并
不觉得警告讯息会困扰我，除非我不小心留了错虫在程序
里，编译器也不会用警告讯息来烦我，因为我写程序的习
200
微软研发
致胜策略下载
惯不会使用if （ch = readkeyboard（）） 这样的方式。对我来
说，只要能找到程序中的错误，程序风格上的修改是微不
足道的小事。在我看起来，那些拒绝使用预警功能的程序
设计师关心个人的表现远甚于程序的正确性，如果他们连
这一点小小的改变都不肯，又怎能期望他们做到重大的改
变呢？如果全部门或全公司从现在起规定新的命名原则，
或是固定的程序风格，怎能期望他们遵循呢？他们能不能
放弃自己喜欢、但容易出错的程序风格？他们会肯用除错
工具来一步步地追踪程序的执行步骤，以期及早发现错误
吗？
是的，撰写“零错误”程序的确需要下功夫，而程序
设计师大都不愿下这些功夫，除非程序设计师有正确的态
度：没有任何理由，有错虫就是不行。在我的项目中，我
会仔细追查错虫清单上的每一个错虫，看看这个错虫是不
是应该早在单元测试（unit test） 阶段就应该发现，或是在
用除错工具追踪时就该被找出来。如果是程序设计师粗心，
让这个早在开发时期就能发现的错虫留到整个系统建置完
毕时才被发现，我就会认为他的工作质量不及格，应该再
重新训练。
有些比较笨蛋的程序设计师会太早认为自己已经完成
201
微软研发·致胜策略
态度问题下载
工作，觉得编译能够过就表示没问题了，因为他们的基本
态度还没有认识到错虫是多么严重，程序无论如何就是不
能有错虫。他们会说：
我认为程序已经完成，因为编译都没有任
何错误，而且执行起来似乎蛮正确的。
笨蛋程序设计师会有这种态度，因为他们没有被各
种难缠的错虫搞得七荤八素过—溢出（overflow &
underflow） 错误、有号型别与无号型别（signed data type &
unsigned data type） 错误、一般性错误、运算子优先级的
错误、逻辑的错误以及特殊状况的错误。有太多种“地
雷”，笨蛋们还不懂得如何把它们嗅出来，也不懂得它的
可怕。
除错要趁早
我严格要求程序中绝对不允许有错虫：要程序设计师
在写程序的当时，就必须用除错工具一步步地追踪程序的
执行步骤、确实执行单位测试，因为如果让任何一个错虫
留到整体测试时才被发现，那不知道要花多少倍
