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

战略：通过不断的自我批评、反馈和共享进行改善  原则一：从过去与现在的项目和产品中学习 目的：以能从过往的成功或失败经历中学习其经验教训  措施： 1.?事后分析： ?? 微软项目基本上都需要编写事后分析报告，并且举行事后分析讨论会。事后分析报告还会在公司的最高层之间进行传阅。 ?? 事后分析报告在由各组负责程序管理、开发、测试、产品管理和客户培训的主要人员执笔编写。最常见的格式是，讨论在最近项目中哪些是做得好的地方，哪些是做得还不好的地方，以及本小组在下一次项目中应该如何进行改善等。事后分析报告还包括描述性的材料，涉成成员（按职能分类的团队规模，工作天数）、产品（代码行数规模，与前一版本的比较，所用的语言，生产出的平台和语言的版本）、质量（每千行代码的缺陷数量，在4个分类中的缺陷严重程度，按产品领域划分的缺陷类型，找到和修复的缺陷的记录，由上个项目遗留下来的和本次项目新产生的缺陷数目的对比）、进度（实际的和计划的里程碑与发布日期的对比）以及过程（如使用的工具、涉及与提供产品“add-ins”扩展组件的其他小组或外部供应商之间相互依赖的问题） 2.?过程审计 ?? 通常审计是主要会针对那些开展中但遭遇到问题的项目而进行。 ?? 过程审计的目的在于收集最佳实践并广为传播。过程审计其要注意的是被审计项目的对抗情绪，让其理解为一种“技术交换”形式，努力识别出项目在什么地方表现不错，以及哪里可以做得更好。 3.?休假会 ?? 20世纪80年代早期，微软开始了每年至少组织公司的核心人员召开一次“休假会”。目的之一，是让不同部门就各自手头正在开展的工作进行信息交换，再就是对付一些难题，诸如怎样才能在一些特别的产品领域更加有效的进行竞争，或者是关于如何改进开发产品和客户支持的过程。 4.?跨组织间的资源共享 ?? 和任何大公司一样，微软目前也是部门林立，以至于某一领域的人不一定知道另一领域的人正在干什么。休假会有助于散播信息，但这种信息交换并不频繁，而且层次也太高。 ?? 跨组织间的资源共享，采取的形式多种多样，例如相同职能部门的经理们之间的午餐会；定期进行非正式会谈；电子邮件；讨论组等。其目的就是“异花授粉”。 5.?“吃自己的狗粮（eating your own dog food）” ?? 创建某种产品的小组应该尽可能在自己的工作中率先使用该产品。如果产品太糟糕了，即使味道还不比自家的狗粮强而“难以下咽”，“厨师”和其他每个成员也都不得不把它给“吞了”（来用它）。 ?? “吃自己的狗粮”这个理念的另外一个部分，就是：开发人员应使用普通客户所用的那种档次的计算机，而不能是那种有很大RAM内存和硬盘存储空间的“彪悍”的机型。 原则二：鼓励使用定量化的度量标准和衡量基准提供反馈和进行改善 ?? 许多公司已经发现，管理和改进诸如产品开发这样的活动一个关键要素，是要建立定量的度量标准和衡量基准。度量标准是一些统计性测量和数据，据之可以对产品质量做出评判，并可对产品或进程中的关键要素进行特征刻画。至少作为对事后分析报告中记录下的那些问题的部分对策，微软的项目逐渐采纳并坚持使用了一小批度量标准。经理们主要参考这些度量标准来做出项目中的关键决策，比如在一个里程碑阶段中何时应该往前走了，或者何时应该推出产品了。另外，定量化的度量标准和数据可以作为一种信息反馈，来帮助项目之间共享信息，做出改进。现在，微软的经理们还在尝试使用度量标准来建立一套全公司范围内的衡量基准，以捕获开发方法中的最佳实践。这些衡量基准将会让所有小组更加方便地展示各自的最佳实践并互相学习；这确定衡量基准而进行的数据收集过程，是对项目事后分析报告的一种扩展。 ?? 度量标准可以分为三大类： ???质量－－包括每日和每周的缺陷（错误）发现和修复率；缺陷的严重程度；缺陷的解决；对缺陷的聚类分析；每1000行源代码中发现的缺陷数目；可用性实验到返回的结果；客户满意度；客户反馈问题的频率。 ???产品－－包括特性类型和数目；以代码行数、存储所用字节数和可执行文件的字节数来计算的产品规模；产品规模在前后两个版本之间的变化；代码复用的程度；速度和内存使用情况；以及代码的测试覆盖率。 ???过程－－包括特性开发小组的规模；各个特性、各个里程碑阶段和可发布产品的估计完成日期与实际完成日期之间的偏差；进度拖延程度；各个里程碑阶段完成情况的检查对照表；发现缺陷的有效办法。 措施： 1.?基于度量标准的过程改进。 2.?聚焦于过程（而不是聚焦于产品）的事后分析。 ?? 以解释为什么一个进行中的项目出了问题，而不仅限于说明出了什么问题。例如几乎每个小组的每份事后分析报告中都提到了由于团队成员向项目中不断地加入新特性从而致使进度失控的问题...我们只是想少关注些发生了什么，而更多的关注是怎么发生的。你怎么会失控