《微软是如何构建学习型组织的.doc》由会员分享，可在线阅读，更多相关《微软是如何构建学习型组织的.doc（4页珍藏版）》请在三一文库上搜索。
1、战略：通过不断的自我批评、反馈和共享进行改善原则一：从过去与现在的项目和产品中学习目的：以能从过往的成功或失败经历中学习其经验教训措施：1.事后分析： 微软项目基本上都需要编写事后分析报告，并且举行事后分析讨论会。事后分析报告还会在公司的最高层之间进行传阅。 事后分析报告在由各组负责程序管理、开发、测试、产品管理和客户培训的主要人员执笔编写。最常见的格式是，讨论在最近项目中哪些是做得好的地方，哪些是做得还不好的地方，以及本小组在下一次项目中应该如何进行改善等。事后分析报告还包括描述性的材料，涉成成员（按职能分类的团队规模，工作天数）、产品（代码行数规模，与前一版本的比较，所用的语言，生产出的平
2、台和语言的版本）、质量（每千行代码的缺陷数量，在4个分类中的缺陷严重程度，按产品领域划分的缺陷类型，找到和修复的缺陷的记录，由上个项目遗留下来的和本次项目新产生的缺陷数目的对比）、进度（实际的和计划的里程碑与发布日期的对比）以及过程（如使用的工具、涉及与提供产品“add-ins”扩展组件的其他小组或外部供应商之间相互依赖的问题）2.过程审计 通常审计是主要会针对那些开展中但遭遇到问题的项目而进行。 过程审计的目的在于收集最佳实践并广为传播。过程审计其要注意的是被审计项目的对抗情绪，让其理解为一种“技术交换”形式，努力识别出项目在什么地方表现不错，以及哪里可以做得更好。3.休假会 20世纪80年
3、代早期，微软开始了每年至少组织公司的核心人员召开一次“休假会”。目的之一，是让不同部门就各自手头正在开展的工作进行信息交换，再就是对付一些难题，诸如怎样才能在一些特别的产品领域更加有效的进行竞争，或者是关于如何改进开发产品和客户支持的过程。4.跨组织间的资源共享 和任何大公司一样，微软目前也是部门林立，以至于某一领域的人不一定知道另一领域的人正在干什么。休假会有助于散播信息，但这种信息交换并不频繁，而且层次也太高。 跨组织间的资源共享，采取的形式多种多样，例如相同职能部门的经理们之间的午餐会；定期进行非正式会谈；电子邮件；讨论组等。其目的就是“异花授粉”。5.“吃自己的狗粮（eating yo
4、ur own dog food）” 创建某种产品的小组应该尽可能在自己的工作中率先使用该产品。如果产品太糟糕了，即使味道还不比自家的狗粮强而“难以下咽”，“厨师”和其他每个成员也都不得不把它给“吞了”（来用它）。 “吃自己的狗粮”这个理念的另外一个部分，就是：开发人员应使用普通客户所用的那种档次的计算机，而不能是那种有很大RAM内存和硬盘存储空间的“彪悍”的机型。原则二：鼓励使用定量化的度量标准和衡量基准提供反馈和进行改善 许多公司已经发现，管理和改进诸如产品开发这样的活动一个关键要素，是要建立定量的度量标准和衡量基准。度量标准是一些统计性测量和数据，据之可以对产品质量做出评判，并可对产品或进
5、程中的关键要素进行特征刻画。至少作为对事后分析报告中记录下的那些问题的部分对策，微软的项目逐渐采纳并坚持使用了一小批度量标准。经理们主要参考这些度量标准来做出项目中的关键决策，比如在一个里程碑阶段中何时应该往前走了，或者何时应该推出产品了。另外，定量化的度量标准和数据可以作为一种信息反馈，来帮助项目之间共享信息，做出改进。现在，微软的经理们还在尝试使用度量标准来建立一套全公司范围内的衡量基准，以捕获开发方法中的最佳实践。这些衡量基准将会让所有小组更加方便地展示各自的最佳实践并互相学习；这确定衡量基准而进行的数据收集过程，是对项目事后分析报告的一种扩展。 度量标准可以分为三大类：质量包括每日和每
6、周的缺陷（错误）发现和修复率；缺陷的严重程度；缺陷的解决；对缺陷的聚类分析；每1000行源代码中发现的缺陷数目；可用性实验到返回的结果；客户满意度；客户反馈问题的频率。产品包括特性类型和数目；以代码行数、存储所用字节数和可执行文件的字节数来计算的产品规模；产品规模在前后两个版本之间的变化；代码复用的程度；速度和内存使用情况；以及代码的测试覆盖率。过程包括特性开发小组的规模；各个特性、各个里程碑阶段和可发布产品的估计完成日期与实际完成日期之间的偏差；进度拖延程度；各个里程碑阶段完成情况的检查对照表；发现缺陷的有效办法。措施：1.基于度量标准的过程改进。2.聚焦于过程（而不是聚焦于产品）的事后分析
7、。 以解释为什么一个进行中的项目出了问题，而不仅限于说明出了什么问题。例如几乎每个小组的每份事后分析报告中都提到了由于团队成员向项目中不断地加入新特性从而致使进度失控的问题.我们只是想少关注些发生了什么，而更多的关注是怎么发生的。你怎么会失控的？并不是“当我需要一份缺陷列表时，某人总是屡次不给我，”而是“为了确保当你需要缺陷列表时就能得到它，哪个环节出了问题？”3.最佳实践的衡量基准。 “最佳实践的衡量基准”这一想法是把事后分析的概念和过程审计综合在了一起。比起编写一份事后分析报告，它花的时间更少些，但是它要能够创造出一个易于共享的优秀实践的清单。原则三：视客户支持为产品的一部分，并做为改善的
8、数据依据 微软的支持哲学强调，每一次客户支持的接触活动都是改进产品设计的一个机会相应地，我们会用更易用、更少需要求助于产品支持组织的产品来回报客户。微软已在实践着的这种在产品设计上采取客户驱动的方法，改变了软件开发周期的目标。在以前，开发人员们的焦点放在“为计算机进行设计”的目标上如果没有额外编码就能实现优雅的设计，他们便会感到心满意足。而现在，只有当他们完成的特性使客户在初次使用就理解时，他们才会感到满意。1.产品支持战略和组织 这一战略有两大支柱：一是使产品更易于使用.通过设计会预先提示问题解决方法的用户界面和产品，来减少我们最终会接收到的电话数，并通过提供支持和文档来减少问题的数量。另一
9、个是建立起支持组织。2.电话数据及其处理 微软每天大约会收到60000个“故障”咨询.每个电话平均历时12分钟.总体上平均每个电话耗费约12美元.过去，微软要求每个部门等额交纳产品支持组织所需的财务费用。但从1991年7月开始，微软已改为向各个产品单元单独收取支持费用。这意味着如果某个小组开发的产品很难用，其设计的许多特性是“电话呼入的发生源”，那么这个产品单元就必须承担所有这些支持费用。 .然后，推出了一些确实极为简单的指导准则，比如，在每个产品单元每次发布时，为什么不把减少一半原有支持电话数或一半的支持电话时间做为一项目标呢？然后你会开始去想，好吧，怎么解决这一问题？很明显，你必须要首先处
10、理那些所占比重最多的问题。3.用于产品改进的信息反馈 对于微软而言一个主要的挑战，是要去组织和分析每天从不同渠道收到的来自客户的海量信息。而后，再把这些信息以一种有用而且精简的形式传递到各个开发小组中。如果正确处理这些信息，它将有助于开发小组确定修改缺陷的优先级次序，使产品更易于使用，从而提供客户真正想要的新特性。4.用户研究和可用性测试 微软每天支出50成美元就产品支持服务和客户满意度进行市场研究.数据表明，产品设计和对客户支持与公司总体的满意度，这两者之间存在非常高的相关性。 产品在现实生活中的使用，比任何人所想象到的要简单得多虽然产品的功能众多，但实际客户使用的功能却较少。 .信息的另一
11、重要来源是微软的产品工具版。这些产品的拷贝版本都有一个独立文件，用以记录用户每一次点击鼠标或敲下键盘的动作，以及完成每个动作所花的时间。这对研究人们实际上是如何使用产品，以及他们在要完成特定任务时选择什么选项，是极为重要的。 可用性实验室测试这是一种让你的产品变得更好的有效途径。显然，你能够使产品更棒些.人们经常认为凭借常识或聪明就能做好设计。但是人们与软件之间进行交互的方法是极其复杂的。即使是最好的设计者，只能做到大约60%是正确的，我想这点其实对任何人都成立。要达到“60%正确”，指的是微软用以对实验室结果进行度量的一个简单标准：没有参阅用户手册第一次就能够正确完成任务的人数，或者人们首次
12、试用就能正确无误执行任何的百分比。原则四：促进跨产品小组间的沟通联系和共享 不同的产品小组如何学会共享组件和充分协作，以形成一个一体化的公司。 不仅仅只是在设计和代码方面进行显式的复用，项目组还正朝着定义基于组件的架构的方向努力工作着。他们还正构建独立的组件，不同产品通过诸如动态链接库或对象链接和嵌入的机制都能够使用它们。 应用软件产品，尤其是OFFICE，需要复用共享组件（比如工具条、绘图工具或窗口框架），以向用户提供一致的用户界面。这种复用还减少了向单个应用软件添加新功能时所需付出的努力。同时，标准化和组件共享，还可以减少向客户提供支持服务时，因不同产品中相似功能的操作差异所付出的额外开销
13、。措施1.互操作性小组 微软在这个方向上的首批措施之一，就是创立互操作性委员会，然后在几年之前变成了互操作小组。1993年，互操作性小组发展成为了现在的OFFICE产品事业部。 互操作性小组的工作，首先是说服了不同的应用软件小组采纳使用通用的用户界面（比如标准化的菜单和工具条）的做法，然后识别出了跨主要的几个产品之间的通用功能。2.通用特性的核心集合 1993年，互操作性小组在所有产品中，识别出大约35种主要特性是通用的，但是它们还没能在产品间实现共享。于是微软新创出一个方法，那些拥有专门知识的产品小组主导构建相应特性，并用OLE封装这些特性。其他小组使用这些OLE的接口，从而能够把那些特性做
14、一个“对象”纳入到自己的程序中。3.针对通用特性进行数据收集 微软收集了大量数据以了解哪些特性应该包括在通用特性集合中。首先，他们对来自主要产品如EXCEL、WORD等中的300多个特性进行了深思熟虑和评估。第二步，他们利用EXCEL和WORD的工具版收集了各特性详细的使用和频度数据。最后，小组通过从基于活动的规划中获得的真知灼见，对以上所获信息作进一步的补充。4.产品和组件间的相互依赖性 基于组件的方法大大提高了产品之间的相互依赖，而这是和诸如创造一流的独立产品、不断提高按时发布的能力或保持每日构建的原则等目标是相抵触的。所以项目小组以尽可能多地监控组件提供者内部的里程碑的方式，尽量紧密地跟踪其所需组件的进度。5.共享和互操作机制 微软开发人员在把OFFICE的组件和应用软件之间紧密联系起来的过程中，使用了一系列互操作机制，如对象链接和嵌入与动态链接库。通过组件和数据共享以及同步操作，这些机制使得两个或多个应用程序之彰能够合作运行，因此开发人员称之为“互操作”机制。6.复用 微软在某一特定产品的一系列版本中如从1.0版本到2.0版，或在PC和Macintosh平台之间会复用大量的代码（超过了50%）。 微软还采用了许多方法以进行独立产品之间的代码复用，比如共享组件、共享一个通用的API，或者干脆采取“拿来主义”（拷贝已有的代码）的办法。