微软的秘密读后感

2009年《程序员》杂志的公开调查，78.8%的中国IT企业的研发团队小于20人

《微软的秘密》的写作方法很醒目，从组织结构和岗位职责到产品战略、产品设计、产品开发、产品测试、产品发布、产品总结改进，完成了一个产品的全过程循环。

在公司管理方面依靠既懂技术又善经营的精明人士 ●在公司结构方面组建职能交叉的专家小组

●在市场竞争方面不断推出新的产品并创建行业标准 ●在定义产品时通过改进产品特性不断创新

●在产品开发与出品过程中所有工作都平行进行并经常协调以保持同步 ●通过自我批评、信息反馈和交流不断进步 ●抓住机遇、迎接挑战、向未来进军

创建学习组织

――通过自我批评，信息反馈和交流而力求进步

系统的从过去和当前的研究项目与产品中学习。

鼓励使用数量化的测量标准和衡量基准进行信息反馈和改进。 视客户的支持为产品的一部分和进步依据。 促进各产品组之间的联系，实现资源共享。

无论何时，好企业都会对生产过程和产品吹毛求疵，以求从过去的成功中获得经验，从失败中吸取教训，对自身行为制定标准、进行衡量，再广泛地研究客户；并且，他们试图促成不同组织部门间更普遍地相互合作，共享构件，并交流产品与生产过程的知识。

我们相信该公司正孜孜不倦地（虽说仍不够）努力着，要建成一个更具凝聚力的组织。

而微软的各组却在事后

检查与项目审计两方面都做到了制度性管理。和众多软件制造商及服务业企 业一样，微软在充分衡量产品开发过程的各要素之后，竭力在进行更有效的 管理和避免过度官僚化之间寻求一种平衡。当然，这种衡量与那些处理 机和微机世界中的一流软件制造商并不完全相同，比如 IBM、惠普或日本的 计算机制造商。不管怎样，微软正在培养一种习惯，即对其发展过程中的关 键因素进行数量化测量。而经理们正是使用这些资料做出关键决策的——例 如，何时推进某一个研究项目，或何时发布一个产品。他们还在创造一些用 来评判绩效的标准，从而推动进步。

鼓励各组写事后分析报告，至少就项目进展开会讨论，实施过程审计以帮助各组分析和解决问题；又组织起正式的休假会活动，届时有关重要人士会就软件开发与质量控制的相关问题相互切磋；再就是在相同职务的人员间极力搓合一些非正式会谈以鼓励知识共享。这些努力弥补了微软公司另一惯例的缺憾，即所谓“自食其果”——内部率先使用微软的产品和工具，以直接体验它们对顾客的好（或糟糕）的程度。穆尔还开始设法制定公司各组的评估标准,这个理想现已为全公司所强调和追求。

1：系统的从过去和当前的研究项目与产品中学习。

(1) 事后分析报告，事后分析讨论会

关键点：高层参与并阅读，使GPT人习惯于自我批评。 间 隔：3-6个月

内 容：各产品负责程序管理、开发、测试、产品管理和用户培训的主要人员分别执笔， （1）哪些做的好，哪些做的不好。如何在下阶段做的更好。

（2）描述性资料，涉及成员（按职能分的小组规模、工作天数），产品（编码规模、

与前一版本的比较、所用语言、生产出的平台和语言版本），质量（每1000 行编码的错误数、在四个等级中的错误程度、按产品领域分的错误类型、发现和修正错误的记录、由上一项目遗留下来的以及新产生的错误数目），进度表（实际的以及计划的阶段和出品日期）以及过程（比如所用工具、涉及到与其他组

及提供产品附件的外部供应商的合作问题）。

方 式：草拟文件，然后有小组成员进行添加意见，最好定稿，发给相关人员，召开分析会。 （2）过程审计

关键点：实施不定期的过程审计，尤其在项目进展遇到困难时。 时 间：集中力量一周时间

内 容：查阅资料，尽可能多的与项目成员交谈，并试图鉴定他们什么地方表现不错及哪里

可能做得更好。找出一个过程典范以促使小组的工作更为成功；并且，对于核心的项目人员他还会写成文稿或口头上予以详细信息反馈。

方 式：亲切引导小组朝着更好的做法迈进。非官僚式的帮助。 （3）休假会

关键点：促成不同部门就手头工作交换信息，再就是对付一些难题， 时 间：每年至少组织一次“休假会”

内 容：比如：怎样才能在特别产品领域更有效地竞争，要求与会者读有关软件工程及相

关领域的经典文献，讨论这些作者的洞察力何在以及微软意欲着手进行哪些改进。领导人物会首先就所读发言，引导讨论。同时：我们也需要就业务单位之间相互配合的改进问题，是“互相依赖”的管理问题：即当项目依赖的关键构件是由其他项目开发的或从公司外部引进的时，如何处理日益严重的进度安排和质量保证问题。

（4）小组间的资源共享

关键点：高层一下的其他人员在不太正式的场合更经常地交流各自所知。 时 间：定期午餐，博览会议，每周一次“自带酒食”午餐会

内 容：每组就各自产品及其走势发表意见，交流各自工作内容，人

们借此机会谈论不同领域的代码，既对正在了解产品的新人有所裨益；也会使自己熟悉一些经验丰富的开发员，他们往往可以填补自己在某些变化和领域内的空白。有时，开发员还会就有关代码的细节问题发行备忘录。

2 鼓励使用数量化的测量标准和衡量基准进行信息反馈和改进。

（1）测量标准的类别

·质量——包括错误的发现和每日每周的修改率；错误严重程度；错 误的解决；错误群分析；每1000 行源代码发现的错误；实验室使用结 果；客户使用中满意程度；客户使用中出现问题的频率。

·产品——包括特性类型和数目；按照源代码行数、储存字节和可执 行文件字节来考虑的产品规模；上、下两版间产品规模的变化；代码 重复使用程度；进度和内存使用情况； 代码的测试范围。

·过程——包括特性小组规模；估计的和实际的各特性、各阶段和可 推出产品的完成日期；进度拖延程度；各阶段完成情况一览表；发现 错误的有效方法。

―――建立一套测量标准 举例：一级错误比重呈下降趋势。 （2）以测量标准为基础的过程改进

（3）以过程为中心（而非以产品为中心）的事后分析

3 视客户的支持为产品的一部分和进步依据

除了尽力从内源——公司项目——多加学习外，微软最近还千方百计地从外源学习：即它的数以百万的客户们。客户可能成为信息的无价源泉。

4：促进各产品组之间的联系，实现资源共享

2 ：管理创造型人才和技术

顺序型的过程也不利于促进频繁的产品构造，如果一个项目是创造一种全新的，毫无已有特性基础的产品，这

个小组通常会采用一种混合的开发方式。开始的时候它采用较为传统的顺序 型步骤；而一旦特性的第一部分完成了，小组就会迅速转向一种经常构造过，

原则一：在平行的小组里工作，但要保持同步和每天调试每日构造过程。

无论单个开发员多久向源代码记录一次他的改变，一个专门指定的被称为项目“构造主管”的开发员每天都要运用源代码的主版本生成产品的一个 完整的构造。

（1）每日构造——保持小组之间协调的严格法则 （2）保持与产品的每日“同步化”:

每日构造过程保证了所开发产品的基本功能在绝大多数

时间里运行良好。为了确保这种高度稳定性，微软希望开发员们每天都同步 化和融合（但不一定记录）他们的源文件 （3）构造暂停

每天下午的中间，构造主管开始使用源代码的主版本进行产品的主 要构造。他通常要等到构造成功之后才回家；所得到的版本即这一产品的每 日构造。各组通常都对暂停构造的人施以惩罚。在应用软件组，由有罪的人来担 任构造主管的职务。

（4）尽量缩短总的构造过程.

Windows 3. 1、WindowsNT 和 MS—DOS 在它们开发周期的早期每月和每周构造，然后在发布前的数月内每日构造。

我们赢了，因为我们能够永远处于有产品可推出的状态。 “培育”而不是设计软件 － 原型法创建软件。

原则三：在同一个开发场所使用一种共同的开发语言

单一场所开发，C 程序语言，“匈牙利语”命名的惯例，支持项目的通用工具

原则四：在构造产品的过程中持续测试产品

因为太多的软件开发员基本是在开发周期的尾声才强调产品测试的重要性，而这时要修改错误可能是特别困难和耗时的。

快速测试

促使每日构造过程有效运作的一个关键工具是一套被称作“快速测试” 的高度自动化的测试。当一个开发员完成了一项新特性而尚未把源代码改变 记录入源文件的主版本的时候，他构造产品的一个私人版本（见表5.1 中所 描述的每日构造过程的步骤7）。然后他在其私人版本上执行快速测试。

每周测试版本 在开发阶段，开发员每周一次把产品的每日构造提供给测试 组。这种“每周测试版本”倾向于使用调试版本，因为这种版本中的方便之 处如断言可以更快反映出问题。当项目接近出品日期时，开发员的每周版本 会更多是产出版本（它不包括调试代码的数千条额外条码）而非调试版本。

内部使用和自产自用

原则五：使用度量数据来决定重大的阶段成果和产品的发布

我们认为产品开发是微软所有事业的中心，公司的存亡和盛衰关键在于新产品。

第五，微软并不要求对项目开始时所提出的每个特性构件都完成并完

善。相反，尤其是在应用软件产品中，微软设置了时间及人员的，然后 制定出除去最严重错误的目标。各小组将会把他们在前次项目中不能完成的 特性构件等到下一次产品发布时再添加进去，或者消除上次他们没有发现或 无法消除的不太严重的错误。这样，微软就避免了一种常见的困境，即陷于 永无止境的修改，添加特性及消除错误的死循环中。别的软件公司也采用多 次发布周期，包括处在每年或经常进行“式样改进”行业中的公司。但是微 软却在这种开发和营销方式上更上了一层楼。它甚至想出了年度软件式样改 进的绝妙主意——从而也有了Windows 95 和Office95 这些名称。（当然， 假如微软没能精确地测定出进度表的话，这种每年出新款式的策略也会起副 作用。把年份加入名称之中也产生了在某一年内完成的额外压力。）

1 ：建立 β测试基地 － 我们需要与一些关系客户，或者我们称之为“关系”

客户，进行合约签订，保证其不会对软件产品进行泄密，把软件交给他们进行 β测试。这样也有助于我们了了解客户的感受。

微软人士：“我们花费更多时间去弄明白怎样从小处着眼去想、去做，而不是好高骛远，一味求大。”

（1）团队建设

研发团队的壮大，进行大型团队的出现，如何管理大型团队呢，如何使大团队像小团队一样有序的工作呢？

（1） 项目规模和范围

明确而有限的产品想象蓝图

·项目规模和范围（明确而有限的产品想象蓝图，人员和时间） ·可分解的产品结构（根据特性构件、子系统和对象来划分模块） ·可分解的项目结构（特性构件小组和特性构件群、里程碑子项目） ·小团体的构成和管理（许多小型多功能组，享有高度的自主权和责任） ·一些“强制”协调和同步的规则（每日构造，“不要破坏构造”的“故障”规 则，里程碑稳定化）

·在各功能和小组内部以及跨功能、跨小组的良好交流（共担责任，同一基地， 共同语言，非官僚文化）

·产品及过程的灵活性以容纳未知因素（不断发展变化的规范，缓冲时间，发展 变化的过程）

人员，时间（新版本1－2年）新产品（不定）

可分解的产品结构 特性和构件小组 特性（和构件）群

里程碑子项目：强调开发，测试和稳定性全部完成的过程。 一些强制实行协调与同步的严格规则性 每日构造 不要破坏构造 里程碑稳定化

在各技术专长和小组内部以及相互之间的交流

共担责任和任务 我们已经讨论过虽说有一些职能专门化和人员分工，微软 是如何通过模糊这些区分来使人们共担责任和任务的。程序经理和产品经理 共同起草产品的想象性描述；程序经理和开发者一起确定产品的特性构件； 开发者和测试者共同测试代码；程序经理，开发者和测试者在新产品发布之 后都要接听顾客支持电话，为顾客解答问题。

同一基地开发

加强对中层领导的培训力度：（1），增长缓慢一点，积累经验 （2）有机会，继续聘请有经验的经理。（3）注重培养经理，“休假会”，“专题讨论”，“管理教育“， ”跨组学习“