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

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 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
您是否曾经暂时停下手边的工作，思考一下如何能
使项目的进行更有效率？您想到的是需要高深学
问才能解决的方式呢？还是只要利用一些经验法则就能化
腐朽为神奇呢？
但愿这个答案像猜谜游戏一般简单，这样我的训练工
作就容易多了，可惜事实不然。要让项目提高效率，需要
长时间、一点一滴地累积非常多的知识、技巧和信念，尤
其新手更是如此，不幸的是，这种能力的培养需要很大的
耐心和毅力，而大部分的人都是用尝试错误的方式来学习，
这样代价既高，功效也不大。
尝试错误的方式会耗用很长的时间，可能得到经历很
惨痛的教训，如果能善用前人的经验和智能，学习前人已
经归纳出来的知识，避免犯下同样的错误，不就快得多了
吗？
本章首先来介绍前人的经验。就我所知，对于一个希
望不加班就能如期完成任务的团队，必须把握好的原则，
这是软件开发部门的基