按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
欢迎访问： txtsk
前言
Introduction
卓越的领导者从不同的角度看世界。若是公司被大
火烧得精光，他非但不为丢饭碗惊慌，反而利用
火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导
者仍有充分的信心保持乐观，对每件事都从正面角度来思
考。就因为凡事都看光明面，卓越的领导者并不把失败当
失败，反将其当作学习克服障碍的经验。正因如此，卓越
的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大
的突破，即使不成功，他只把这次经验当成获得信息的方
式之一。这种领导人不一定要有经验，而是需要强烈的进
取心和明确的理想，能够将理想与他人沟通，鼓舞他人共
同追寻理想的能力，再加上一点机会，这就是能将理想实
现的卓越领导者。
也许有人认为这种领导者是天生的，其实，任何人都
可以学习做个卓越的领导者，不过并不容易，他必须学习
排除成见和习惯，从各种不同的角度思考问题。你可能会
说，那不就等于彻头彻尾换了个人？那几乎是不可能的，
就算做得到也是一种虚伪和矛盾。我想这就是大多数人无
法成为卓越领导者的原因之一，人们大都不愿意将自己改
变到这种程度。
2
微软研发
致胜策略下载
一般的领导者
幸而大部分的软件开发主管不需要是卓越的领导者，
不必找一片处女地开疆拓土、披荆斩棘，开一家打败传统
的新公司；大部分的软件开发主管只要把某个软件的新版
本开发完成就可以了。软件开发主管大都已有明确的目标，
项目内容是每位组员基本上都同意的，不必彻底改变传统
或是鼓舞人们去做极困难的事；基本上软件开发主管最重
要的任务就是提高工作效能，这是可以学习的，不必彻底
改变自己的性格，只要懂得开发软件的技巧和策略，就可
以让软件叫好又叫座，而且不必每周工作80小时。
追求效能的主管很明白，成功的项目维系在每位组员
身上，才能如期完成高品质的软件。本书所提供的技巧和
策略，不是软件开发主管会用就够了，每位组员都必须充
分了解。除非每个人都懂得如何在合理的工作时间内做出
高品质的软件，否则项目仍是不会成功的。
写出好的程序
软件从开始构想到开发完成、上市，这中间要经历的
步骤非常多，每一步骤都可能会出错，这已经没什么稀奇
了。本书希望程序设计师试着把开发程序想成写程序：开
3
微软研发·致胜策略
下载前言
发程序像程序一样可能有错，程序有错误是一定会造成伤
害的，最后得浪费非常多的时间和精神去找出错误，所以
最好是第一次就把它做对，或者说，愈少错误、愈高效
能。
本书的重点是提高软件开发的工作效能，将人力的浪
费减到最少，并兼顾软件的品质。前3章主要谈的是让团
队不必大量加班的基本观念和策略，后面5章是慎防流程
的僵化、开发进程的掌握、开发人员的训练、正确的工作
态度以及长时间工作的症候群上。
简介微软的软件开发制度
本书大部分的例子都是我在微软的工作经验，因此先
了解一下微软的软件开发制度，会比较容易抓住本书正文
的内容要旨。
微软的开发项目一般都会包括三种不同的主管，其中：
◆ 项目经理（Project Lead）：他是项目的主要负责人，
同时负责拟定进程，监督工作确实按进程进行，确
保所有的工作都走上轨道，不出纰漏，训练程序设
计师，负责向高级主管报告本项目的状况。通常是
由团队中最资深的程序设计师担任，偶尔他也写点
4
微软研发
致胜策略下载
程序，但那是次要的工作。
◆ 技术经理（ Technical Lead）：技术经理是团队中对
程序最熟悉的程序设计师，负责软件内部的整合性，
确定所有的开发活动都符合设计规格，而且没有互
相掣肘，他通常也负责让技术文件都确有更新，包
括档案格式、内部设计图等等。通常也是由团队中
最资深的程序设计师担任。
◆ 程序经理（Program Manager）：程序经理负责与行
销人员协调，使得产品的开发、文件、测试与顾客
支持等事宜能配合行销方面的动作。简言之，程序
经理的工作是监督每件事都确实做到，而且做得符
合公司的期望。程序经理还常和产品支持小组共同
合作B e t a测试的种种事宜，并根据最终使用者的反
应，研究产品如何改善。程序经理也可以是程序设
计师，但是他们写程序的工作很少，而且仅限于产
品的宏语言（如果有的话），或是像精灵之类的东西。
程序经理是对产品未来适用性的主要负责人。
程序经理的原文是M a n a g e r，听起来好像比较大，事
实上三种经理角色是不分大小高低的，也许更正确的名称
是“产品经理”（Product Lead），因为他的责任是使整个产
5
微软研发·致胜策略
前言下载
品（而不只是程序） 要跟上进度，而且要保持良好的品质。
在一个典型的项目中，程序经理（如果这个项目规模
比较大，会有不只一位程序经理） 要带头与行销、开发、
产品支持等小组合作，共同拟出一张清单，上面列着本产
品可以改善的地方。然后，程序经理着手撰写产品规格，
详细描述每个功能要如何具体展现，包括细节的执行步
骤；比方说，决定要开一个新的对话窗，那么产品规格中
必须绘出这个对话窗的模样，用文字描述它如何操作，能
引发什么功能等等，如果要加一个新的子程序或宏，就得
把它的所有参数都定义好。产品规格定好后，必须给所有
相关的工作小组复审，完全确定所有的细节后，开发小组
才正式开始工作。
在拟定产品规格的同时，程序经理还必须进行一些
“使用难易度研究” （usability studies），确定所有的功能都
跟想像中的一样容易使用，没有始料未及的障碍。如果实
验结果是有些地方操作上怪怪的，或是容易引起使用者误
解，程序经理就得提出改进的建议。当然，这些操作的环
境、范例资料、相关文件等等，程序经理都必须事先准备
妥当。最后，程序经理要对每项功能或特色逐一审查，特
别是对那些改变幅度较大的更要仔细，完全确定产品规格
6
微软研发
致胜策略下载
能够符合项目的目标，产品的规格才算完成。
开发工作进行到比较后期时，会进入一个“视觉冻结”
（visual freeze） 的阶段，意思是使用者界面就固定不动了，
这样做的目的是要让使用手册等文件能够定稿。所以从这
时候起，开发动作要特别小心，各个画面及其彼此的逻辑
关系都不能再受到影响，这样手册上的画面才会跟实际执
行的画面完全一致。程序设计师当然希望程序全部完工后
再来排画面做手册，但是手册的编撰需要比较长的时间，
还要排版印刷等等，为了让软件推出时手册也同时就绪，
“视觉冻结”是绝对必要的措施。所以，在“视觉冻结”以
前，一定要把画面确定，功能尚未齐备的部分稍后再进行。
一旦所有的功能都完成，软件就进入了“程序完成”
（code plete） 阶段，意思是程序不再作功能上的修改，
只要进行抓错除错（debugging） 和必要的改进。等到产品
确定可以推出了，项目经理或技术经理负责准备好“母片”
（golden master disk），也就是即将大量复制的原型，和手
册登录卡等包装成盒，再做好出货的登录号等管理工作，
这个产品就可以交给使用者了。
我略去了许多细节，以上所述仅只是让读者有一个基
本的概念，让读者比较能理解正文中所提的案例，不然这
7
微软研发·致胜策略
前言下载
些案例会让人觉得隔靴搔痒。
还有一点我必须提到的，就是电子邮件是微软内部沟
通的命脉，电子邮件让我们工作时不被电话打扰，这在开
发人员来说尤其重要。开发人员彼此之间大部分的讨论也
通过电子邮件，只有必要时才开会。微软这种防止干扰的
做法等于让每个人都有了一间私人的办公室，如果你想专
心工作，不要任何干扰，把门关上就行了。
说来容易做来难
我最后要提醒读者一点，本书也许会让您觉得，只要
照书上的每一个建议去做，就能立刻将一个濒临失控的项
目起死回生。当然本书中有些建议是能立竿见影地看到效
果的，但有一些技巧和策略则是需要时间的，比方说训练
方法就是。所以，如果您的团队遇到问题，您不能期望照
着本书做就可以在一星期后让团队改头换面。以我的经验，
让项目起死回生大概要二到六个月，前两个月会有大幅的
改善，而以后是比较缓慢而渐进的改善。
8
微软研发
致胜策略下载
下载
第1 章
奠定基础
1
Chapter One
您是否曾经暂时停下手边的工作，思考一下如何能
使项目的进行更有效率？您想到的是需要高深学
问才能解决的方式呢？还是只要利用一些经验法则就能化
腐朽为神奇呢？
但愿这个答案像猜谜游戏一般简单，这样我的训练工
作就容易多了，可惜事实不然。要让项目提高效率，需要
长时间、一点一滴地累积非常多的知识、技巧和信念，尤
其新手更是如此，不幸的是，这种能力的培养需要很大的
耐心和毅力，而大部分的人都是用尝试错误的方式来学习，
这样代价既高，功效也不大。
尝试错误的方式会耗用很长的时间，可能得到经历很
惨痛的教训，如果能善用前人的经验和智能，学习前人已
经归纳出来的知识，避免犯下同样的错误，不就快得多了
吗？
本章首先来介绍前人的经验。就我所知，对于一个希
望不加班就能如期完成任务的团队，必须把握好的原则，
这是软件开发部门的基本观念，也是往后几章的基础。
专心改善产品
公司付薪水给程序设计师，是要他们在合理的时间内
10
微软研发
致胜策略下载
做出品质精良的软件，但是程序设计师的时间却经常被其
他的事情占用掉了。这样的程序设计师或他们的经理们，
就是因为不了解软件开发的真理：
任何不能改善产品的工作，都是浪费时间
或是偏离方向。
如果您一时不了解这个观念的重要，请想一想以下
两个极端典型的比较：一位程序设计师一天到晚开会、
写报告、阅读和回复电子邮件，另一位程序设计师则专
心研究、设计和测试新产品的功能，试问谁比较容易脱
颖而出？毫无疑问是心无旁骛的那一位，他甚至可能提
前完成工作呢。
我经常发现，团队出问题的原因之一，往往是因为程
序设计师们都在做他们不该做的事：他们花太多的时间准
备开会、参加会议、读写开会记录和进度报告，以及回复
电子邮件。这些不能改善产品的工作，固然一部分是程序
设计师自己主动做的，但更大的一部分是主管下的命令。
曾经与我共事过的一位经理，要求每一位组员要用
e…mail 交一份工作周报，每周开一小时的会讨论目前各人
手上的工作内容，以及其他突发性的事务，开完会后，提
11
微软研发·致胜策略
奠定基础下载
出意见的人负责写出书面报告，交给经理。
这位经理的动机只是想管理每一个细节，但并不了解
这会让团队被无意义的工作压得无法喘息。这些进度报告
真的那么重要吗？那些后续报告的用意又是什么呢？如果
开会时经理自己做个简单的笔记，不就省了这些报告所占
用的时间和精神？
很显然，这个问题的答案必须视您身处的企业环境而
异，但从我刚才所举的实例来说，其实只有最初制定进度
的那份报告是有价值的，其他的报告都是可有可无，甚至
进度检讨会都没有必要召开，而且每次那位经理要求后续
报告时，我都很纳闷，心想：“我刚才不是已经告诉他我
的想法了，为什么我还得再写一遍？”
我不过是偶尔去参加他们的定期进度会议，所以对我
的时间损失并不大，不过，我常在想，不知道公司里有多
少不必要的例行工作正在加重员工的负担？这位经理本意
是尽力把每件事情做到巨细靡遗，但是却违背了身为软件
开发领导者的基本守则：
领导者的任务是努力消除程序设计师工作
上的一切障碍，让程序设计师全力专注在真正
重要的工作─改善产品。
12
微软研发
致胜策略下载
这并不是震惊世界的大发现，而是极简单的道理，但
是，有多少软件开发主管是真的把“消除程序设计师工作
上的障碍”当作积�