微软是如何构建学习型组织的

1、战略：通过不断的自我批评、反馈和共享进行改善原则一：从过去与现在的项目和产品中学习目的：以能从过往的成功或失败经历中学习其经验教训措施：1 .事后分析：微软项目基本上都需要编写事后分析报告，并且举行事后分析讨论会。 事后分析报告还会在公司的最高层之间进行传阅。事后分析报告在由各组负责程序管理、开发、测试、产品管理和客户培训的主要人员执笔编写。最常 见的格式是，讨论在最近项目中哪些是做得好的地方，哪些是做得还不好的地方，以及本小组在下一次项 目中应该如何进行改善等。事后分析报告还包括描述性的材料，涉成成员（按职能分类的团队规模，工作 天数）、产品（代码行数规模，与前一版本的比较，所用的语言，生产

2、出的平台和语言的版本）、质量（每 千行代码的缺陷数量，在 4个分类中的缺陷严重程度，按产品领域划分的缺陷类型，找到和修复的缺陷的 记录，由上个项目遗留下来的和本次项目新产生的缺陷数目的对比）、进度（实际的和计划的里程碑与发 布日期的对比）以及过程（如使用的工具、涉及与提供产品“ add-ins ”扩展组件的其他小组或外部供应商 之间相互依赖的问题）2 .过程审计通常审计是主要会针对那些开展中但遭遇到问题的项目而进行。过程审计的目的在于收集最佳实践并广为传播。过程审计其要注意的是被审计项目的对抗情绪，让其理解为一种“技术交换”形式，努力识别出项目在什么地方表现不错，以及哪里可以做得更好。3 .休

3、假会20世纪80年代早期，微软开始了每年至少组织公司的核心人员召开一次“休假会”。目的之一，是 让不同部门就各自手头正在开展的工作进行信息交换，再就是对付一些难题，诸如怎样才能在一些特别的 产品领域更加有效的进行竞争，或者是关于如何改进开发产品和客户支持的过程。4 .跨组织间的资源共享和任何大公司一样，微软目前也是部门林立，以至于某一领域的人不一定知道另一领域的人正在干什 么。休假会有助于散播信息，但这种信息交换并不频繁，而且层次也太高。跨组织间的资源共享， 采取的形式多种多样， 例如相同职能部门的经理们之间的午餐会；定期进行非 正式会谈；电子邮件；讨论组等。其目的就是“异花授粉”。5 .“吃

4、自己的狗粮 （ eating your own dog food ）”创建某种产品的小组应该尽可能在自己的工作中率先使用该产品。如果产品太糟糕了，即使味道还不比自家的狗粮强而“难以下咽”，“厨师”和其他每个成员也都不得不把它给“吞了” （来用它）。“吃自己的狗粮”这个理念的另外一个部分，就是：开发人员应使用普通客户所用的那种档次的计算机，而不能是那种有很大 RAM存和硬盘存储空间的“彪悍”的机型。原则二：鼓励使用定量化的度量标准和衡量基准提供反馈和进行改善许多公司已经发现，管理和改进诸如产品开发这样的活动一个关键要素，是要建立定量的度量标准和衡量基准。度量标准是一些统计性测量和数据，据之可以对

5、产品质量做出评判，并可对产品或进程中的关 键要素进行特征刻画。至少作为对事后分析报告中记录下的那些问题的部分对策，微软的项目逐渐采纳并 坚持使用了一小批度量标准。经理们主要参考这些度量标准来做出项目中的关键决策，比如在一个里程碑 阶段中何时应该往前走了，或者何时应该推出产品了。另外，定量化的度量标准和数据可以作为一种信息 反馈，来帮助项目之间共享信息，做出改进。现在，微软的经理们还在尝试使用度量标准来建立一套全公 司范围内的衡量基准，以捕获开发方法中的最佳实践。这些衡量基准将会让所有小组更加方便地展示各自 的最佳实践并互相学习；这确定衡量基准而进行的数据收集过程，是对项目事后分析报告的一种扩展

6、。度量标准可以分为三大类：质量一一包括每日和每周的缺陷（错误）发现和修复率；缺陷的严重程度；缺陷的解决；对缺陷的 聚类分析；每1000行源代码中发现的缺陷数目；可用性实验到返回的结果；客户满意度；客户反馈问题的 频率。产品-包括特性类型和数目；以代码行数、存储所用字节数和可执行文件的字节数来计算的产品 规模；产品规模在前后两个版本之间的变化；代码复用的程度；速度和内存使用情况；以及代码的测试覆 盖率。过程-包括特性开发小组的规模；各个特性、各个里程碑阶段和可发布产品的估计完成日期与实 际完成日期之间的偏差；进度拖延程度；各个里程碑阶段完成情况的检查对照表；发现缺陷的有效办法。措施：1 .基于度

7、量标准的过程改进。2 .聚焦于过程（而不是聚焦于产品）的事后分析。以解释为什么一个进行中的项目出了问题，而不仅限于说明出了什么问题。例如几乎每个小组的每份事后分析报告中都提到了由于团队成员向项目中不断地加入新特性从而致使进度失控的问题.我们只是想少关注些发生了什么，而更多的关注是怎么发生的。你怎么会失控的？并不是“当我需要一份缺陷列表 时，某人总是屡次不给我，”而是“为了确保当你需要缺陷列表时就能得到它，哪个环节出了问题？” 3.最佳实践的衡量基准。“最佳实践的衡量基准”这一想法是把事后分析的概念和过程审计综合在了一起。比起编写一份事后分析报告，它花的时间更少些，但是它要能够创造出一个易于共享

8、的优秀实践的清单。原则三：视客户支持为产品的一部分，并做为改善的数据依据微软的支持哲学强调，每一次客户支持的接触活动都是改进产品设计的一个机会-相应地，我们会用更易用、更少需要求助于产品支持组织的产品来回报客户。微软已在实践着的这种在产品设计上采取客 户驱动的方法，改变了软件开发周期的目标。在以前，开发人员们的焦点放在“为计算机进行设计”的目 标上-如果没有额外编码就能实现优雅的设计，他们便会感到心满意足。而现在，只有当他们完成的特 性使客户在初次使用就理解时，他们才会感到满意。1 .产品支持战略和组织这一战略有两大支柱：一是使产品更易于使用.通过设计会预先提示问题解决方法的用户界面和产品，来

9、减少我们最终会接收到的电话数，并通过提供支持和文档来减少问题的数量。另一个是建立起支持 组织。2 .电话数据及其处理微软每天大约会收到 60000个“故障”咨询.每个电话平均历时12分钟总体上平均每个电话耗 费约12美元.过去，微软要求每个部门等额交纳产品支持组织所需的财务费用。但从 1991年7月开始， 微软已改为向各个产品单元单独收取支持费用。这意味着如果某个小组开发的产品很难用，其设计的许多 特性是“电话呼入的发生源”，那么这个产品单元就必须承担所有这些支持费用。.然后，推出了一些确实极为简单的指导准则，比如，在每个产品单元每次发布时，为什么不把减 少一半原有支持电话数或一半的支持电话时

10、间做为一项目标呢？然后你会开始去想，好吧，怎么解决这一 问题？很明显，你必须要首先处理那些所占比重最多的问题。3 .用于产品改进的信息反馈对于微软而言一个主要的挑战，是要去组织和分析每天从不同渠道收到的来自客户的海量信息。而后，再把这些信息以一种有用而且精简的形式传递到各个开发小组中。如果正确处理这些信息，它将有助于开 发小组确定修改缺陷的优先级次序，使产品更易于使用，从而提供客户真正想要的新特性。4 .用户研究和可用性测试微软每天支出50成美元就产品支持服务和客户满意度进行市场研究.数据表明，产品设计和对客户支持与公司总体的满意度，这两者之间存在非常高的相关性。产品在现实生活中的使用， 比任

11、何人所想象到的要简单得多一一虽然产品的功能众多，但实际客户使用的功能却较少。.信息的另一重要来源是微软的产品工具版。这些产品的拷贝版本都有一个独立文件，用以记录用 户每一次点击鼠标或敲下键盘的动作，以及完成每个动作所花的时间。这对研究人们实际上是如何使用产 品，以及他们在要完成特定任务时选择什么选项，是极为重要的。可用性实验室测试-这是一种让你的产品变得更好的有效途径。显然，你能够使产品更棒些.人们经常认为凭借常识或聪明就能做好设计。但是人们与软件之间进行交互的方法是极其复杂的。即使是最 好的设计者，只能做到大约 60娼正确的，我想这点其实对任何人都成立。要达到“ 60%E确”，指的是微 软用

12、以对实验室结果进行度量的一个简单标准：没有参阅用户手册第一次就能够正确完成任务的人数，或 者人们首次试用就能正确无误执行任何的百分比。原则四：促进跨产品小组间的沟通联系和共享不同的产品小组如何学会共享组件和充分协作，以形成一个一体化的公司。不仅仅只是在设计和代码方面进行显式的复用，项目组还正朝着定义基于组件的架构的方向努力工作着。他们还正构建独立的组件，不同产品通过诸如动态链接库或对象链接和嵌入的机制都能够使用它们。应用软件产品，尤其是 OFFICE,需要复用共享组件（比如工具条、绘图工具或窗口框架），以向用 户提供一致的用户界面。这种复用还减少了向单个应用软件添加新功能时所需付出的努力。同时

13、，标准化 和组件共享，还可以减少向客户提供支持服务时，因不同产品中相似功能的操作差异所付出的额外开销。措施1 . 互操作性小组微软在这个方向上的首批措施之一，就是创立互操作性委员会，然后在几年之前变成了互操作小组。1993年，互操作性小组发展成为了现在的OFFICE产品事业部。互操作性小组的工作，首先是说服了不同的应用软件小组采纳使用通用的用户界面（比如标准化的菜单和工具条）的做法，然后识别出了跨主要的几个产品之间的通用功能。2 .通用特性的核心集合1993年，互操作性小组在所有产品中，识别出大约35种主要特性是通用的，但是它们还没能在产品间实现共享。于是微软新创出一个方法，那些拥有专门知识的

14、产品小组主导构建相应特性，并用OLE封装这些特性。其他小组使用这些 OLE的接口，从而能够把那些特性做一个“对象”纳入到自己的程序中。3 .针对通用特性进行数据收集微软收集了大量数据以了解哪些特性应该包括在通用特性集合中。首先，他们对来自主要产品-如EXCEL WOR簪中的300多个特性进行了深思熟虑和评估。第二步，他们利用EXCElS WORD）工具版收集了各特性详细的使用和频度数据。最后，小组通过从基于活动的规划中获得的真知灼见，对以上所获 信息作进一步的补充。4 .产品和组件间的相互依赖性基于组件的方法大大提高了产品之间的相互依赖，而这是和诸如创造一流的独立产品、不断提高按时发布的能力或保持每日构建的原则等目标是相抵触的。所以项目小组以尽可能多地监控组件提供者内部的 里程碑的方式，尽量紧密地跟踪其所需组件的进度。5 .共享和互操作机制微软开发人员在把 OFFICE的组件和应用软件之间紧密联系起来的过