公司主要为全国不同的医院开发医疗行业的软件产品。六年前，公司规模还不到五百人；四年前，公司办公地点扩大了一倍，占地3000平方米，总人数也增加到接近900人。尽管公司骨干比较稳定，但新人的流动性很大。公司制定了很多量化指标，如需求一次性通过率、开发速度、测试缺陷密度等，并不断监控，但并未取得明显改善。
技术总监问："请教一个一直困扰我的问题------如何激励团队，让他们更有积极性？"
"现在你们员工的收入底薪和奖金的比例大概是多少？"
总监："大概七成底薪，其他的就按每人每年的表现分发。"
"主要依赖主管的打分吗？我完全可以理解为什么是这个结果了。因为在这种安排下，员工的收入既不会太差，但也不会特别高，所以他们自然缺乏动力去改进自己的工作表现。 "
总监解释："也不完全依赖主管的主观判断。我们制定了很多与绩效相关的度量指标，以根据这些指标客观地计算员工的奖金多少。"
"理解了，你觉得这样便能客观吗? 一旦把度量与绩效/奖金挂钩，就会导致收集不到真实的数据。因为只要数据与收入有关联，高层需要什么数据，下面都会提供，这完全失去了度量的本意。收集度量数据本来希望像镜子一样，让团队可以看到现在的真正水平。团队成员相互合作非常重要，所以日本公司通常不会发奖金给某个个人，而是发给团队。团队的奖金应该与团队为公司提供的价值（换算成金额）挂钩，这样才客观透明。大家可以预估到如果团队有了提升，能为公司赚多少钱，自己收入大概会增加多少。除了金钱上面的奖励，也不要忽略非金钱的赞赏，例如，定期让项目团队分享改进成功的故事，也可以帮助团队持续改善。你们每个开发团队里面都有明确的分工：需求、开发、测试等都有相关的度量指标。但岗位之间缺乏交流，导致团队的整体质量和效率没有显著提升，例如团队的缺陷密度和返工率一直没有明显下降。"
接下来，我用了15分钟时间讲述了60年代美国费城的Weisbord先生针对印刷公司订单管理部团队改革的故事。讲述了如何从每一个步骤都要按流程执行的传统管理模式（X型管理），改革成赋能每个5人团队（Y型管理）的成功案例。（详见第2章故事）
总监说："听完这个故事，确实感觉我们团队的管理模式类似于X型管理。虽然我们团队每两周进行一次迭代，但没有真正做到团队合作。测试人员只负责测试，开发人员只写程序，然后交给测试人员去测试。因此，从这个角度看，或许每个过程的指标，如测试和开发都很好，但团队的整体能力没有任何提升。"
"从这次观察来看，每个迭代中，系统测试的缺陷数保持在40-60个左右，六个月前是这个水平，现在依然如此，现在还是这个水平，没有任何进步。为什么？因为大家缺乏团队协作和互补的团队精神，导致没有改进的动力。各岗位只顾管好自己，确保指标达标，不被扣绩效就行。"因为我也对团队的停滞感到失望，所以不管总监是否高兴，我直言不讳地指出问题。
当敏捷开发团队建立起协作互补的基础后，就可以开始使用根因分析。
回顾流程
回顾流程冲刺可以按以下五个步骤进行，确保每位成员都全心投入参与，并通过分析形成行动，达到改进效果：
- 设置舞台------"破冰"。
- 收集数据（除了收集"硬"数据，如缺陷、工作量、进度偏差等，也要收集"软"数据,如团员感受）。
- 分析，找出根因。
- 决定做什么（必须明确下个迭代的具体改进行动到人、任务、时间）。
- 结束。
冲刺回顾本应是团队分析根因在下一轮冲刺改进的最佳时机，但很多团队不了解 改正(Correction)和 纠正措施(Corrective Action)的区别（详见之前第9章），团队在回顾时只讨论改正，导致以前发生过的问题还是会再发生。 有听过美国航空航天局(NASA)的太空穿梭机(航天飞机 Space Shuttle)计划的致命事故吗？
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 太空穿梭机（航天飞机）灾难 （Space Shuttle disasters) 1986: 挑战者号（Challenger）航天飞机升空后，于发射后的第73秒爆炸，机上7名宇航员全部罹难。( 相关视频可以在网上搜到) 直接原因是用来密封火箭液态氢气燃料缸的O型橡胶环在摄氏零度低温不能及时膨胀。 但这事故并非偶然。升空前，供应商已经警告过低温会影响橡胶的性能；以前的实验也发生过橡胶环有些部分半径只能达到预期的2/3。 但管理层为了按计划预期升空都漠视这些安全隐患预警。 2003：哥伦比亚号 (Columbia) 航天飞机在返回地球时，因为左翼的隔热保护胶在16天前升空时被固体火箭助推器外层脱落的乳胶击破损坏，导致航天飞机返航时进入大气层的第1000秒钟，在35,000米高空因过热解体，7名宇航员全部罹难。 Sally Ride在2003哥伦比亚号灾难事故调查回顾说 ：我很诧异这两次事故的原因非常相似（她也是挑战者号事故调查组员），86年引起挑战者灾难的陋习又再出现 : 为了赶上计划升空日期，而忽略了之前性能报告的发现，没有注意前线技术工程人员提出的安全隐患，也缺乏安全保障措施。其实从哥伦比亚号在1981年首次升空开始，每次都有出现升空时燃料缸外的保护乳胶掉落的事故，但管理层一直都没有关注，工程师因为赶进度，每次升空前，都没有时间预先处理好。 虽然调查报告有找出事故的根因，但过了几年后，管理层只关注项目的成本与进度，忽略了质量与安全，没有再注意调研报告指出隐患，事故还是重复发生。 |
因为发生了这两次致命事故，航天飞机计划最终被叫停。
听完这故事，你可能会反驳说： "NASA资源丰富，内部不缺经验丰富的工程师，也未能做好根因分析，避免同类问题再发生，敏捷团队未能在回顾时未能做好根因分析，不就是理所当然了吗？"
"听过PDCA吗？"
"当然听过，Plan Do Check Act ,也叫戴明环， 因为时戴明博士提倡的。"
"要做好PDCA背后就要分析根本原因，讨论 纠正措施。 其实不需要高深的统计分析， 只须使用二八原则识别改进方向， 然后大家头脑风暴，比如 使用鱼骨图记录主要根因，讨论纠正措施，制定计划， 最后判断是否得到显著提升就可以了。 你觉得开发团队在能否回顾时用上？"
"听你这样说应该不难。"
"其实甚至一家日本俱乐部里由7位年轻女服务员组成的QC圈在84年已经能做到。 如果不信，可以去B站搜索看这15分钟的短视频。"
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 根因分析(Causal Analysis & Resolution CAR)的主要步骤: 1. 选择要分析的结果, 利用二八原则识别引起大部分问题的最主要因素 2. 分析背后的主要根因 3. 对应改进措施(改进建议) 4. 评价改进效果 5. 总结成根因分析报告(A3报告) 可参考短视频:"绅士俱乐部PDCA过程改进"了解团队如何按以上步骤做过程改进。绅士俱乐部过程改进_哔哩哔哩_bilibili绅士俱乐部过程改进, 视频播放量 1、弹幕量 0、点赞数 0、投硬币枚数 0、收藏人数 0、转发人数 0, 视频作者 bili_99582759387, 作者简介 ，相关视频：2024.7.6直播互动答疑，玻切机，2025《解题觉醒》（九科全）电子版 免费分享 【高中逆袭】，面试高频题拆解（速成作弊版），个人述职报告 主页下载更多，大学里含金量最高的七个志愿活动，言语理解学习经验分享，我花了5年时间训练自己这种能力，希望你也能成功...，初高衔接---穿针引线法，重新介绍一下自己，法律咨询给个三连
https://www.bilibili.com/video/BV1Ks8De9EsN/ |
但不要误以为只要使用各种根因分析方法，如帕累托图、鱼骨图等，就能做好根因分析。以上的根因分析都是以定性讨论为止，没有利用相关数据做分析。
没有数据，就无法谈改进, 要做好根本原因分析也必须利用数据。 如收集了缺陷与返工工作量数据，并利用二八原则便能找出应该针对哪方面入手， 而不是指靠个人的主观判断和经验，直接制定改进措施。
应收集哪些数据？数据不是越多越好，因为收集数据花精力，所以是反过来越少越好。应针对收集哪些数据呢？就应考虑改进目标，例如按上章想降低返工，便应问以下问题：
| 业务目标 | 信息需要（问题） | 度量目标 | 度量类型 | 基本度量项实例 | 衍生度量项实例 |
|---|---|---|---|---|---|
| 不影响成本的前提下,交付给客户的产品的缺陷降低10% | 在交付之前,缺陷在哪里注入以及哪里被发现? | 在整个品生命周期中，评价缺陷检测的有效性 | 质量 | 按生命周期阶段注入及发现的缺陷个数 产品规模 | 生命周期阶段的缺陷检出比率 缺陷密度 |
| 不影响成本的前提下,交付给客户的产品的缺陷降低10% | 返工成本有多少? | 确定修复缺陷的成本 | 成本 | 按生命周期阶段注入及发现的缺陷个数 修复缺陷花费的工时 劳动力成本单价 | 返工成本 |
除了每个过程的返工工作量，也要有缺陷排除率。
缺陷排除率
从需求到设计、编码、单元测试、系统测试、验收，整个开发过程大家都很熟悉，需求、设计、编码后可以通过评审来排除缺陷，但仅仅做评审不一定能确保质量。因为最终验收缺陷数取决于每个步骤能否有效排除当前的缺陷。下面我们介绍一下怎么从引进量化管理来提高开发质量：
- 设定量化目标。例如希望最终遗漏到验收发现的缺陷数降多少？
- 并设定中间阶段目标缺陷数，从而预测能否达到最终目标，不要等到最后才知道不满足
可用缺陷排除率(Defect Removal Efficiency DRE) 来判断每一个过程的质量：
如果要最终质量好，缺陷排除率就要高。但计算缺陷排除率，必须要等到整个开发完成才可以计算。如果团队收集并分析本迭代的缺陷，如下：
然后使用DRE方程式计算各缺陷排除率：
例如：需求评审发现5个缺陷，但当时共有20个从需求引发的缺陷，所以DRE是25%。
设计评审共发现10个缺陷，但当时共有20个需求引发，加上22个设计引发的缺陷，减除5个已经在需求评审处理的缺陷，所以DRE是27%
如果我们按上面各阶段缺陷利率百分比，设计与需求排除缺陷15%，代码评审与单元测试55%，集成/系统测试22%，验收测试8%，下面按缺陷总数为100， 得出算出设计与需求排除共15缺陷, DR+RR=15，CR+UT=55, IT+ST=22, AT=8,求出各阶段的缺陷输入与缺陷排除率，把参数输入预测模型(XLS 模板）。
得出下面的表，缺陷分布是中间最高头尾低，右面与左面不同，有条长尾巴，类似估算软件开发项目工作量的Rayleigh曲线。
由于不同项目甚至不同迭代冲刺的缺陷数和缺陷率各异，难以进行比较，但如果方法和团队人员相似，缺陷排除率应该是可比的。 通过分析以往的缺陷数据，针对最薄弱的环节讨论根本原因，并在下一个迭代中进行改进，提升缺陷排除率，并可以预估各个阶段（如评审、测试等）的缺陷发现数。例如，如果需求评审的缺陷数远低于预期，就应立即进行纠正，而不是像以前那样仅仅提醒大家要重视评审工作。
根因分析的误解
请千万不要误以为只要使用了根因分析的方法（例如：二八原则）就能做好，很多团队在开始时对其理解可能只是一知半解，需要不断纠正和改进。
某公司过程改进组（共4人）对过去一年的项目进行了根因分析，旨在改进交付质量，减少交付验收时的缺陷数。
我：请问这帕累托图的依据？
组长：针对客户缺陷密度较高的现状，我们做了敏感度分析。发现需求引入的缺陷数跟它相关性最高，接下来，我们使用鱼骨图分析，请4个人一起头脑风暴，共识别出十几项主要原因种类。然后，按每人3票的原则，各自单独投票得出排序。最后根据二八原则，我们识别出前三项主要原因，接着，我们根据这三项原因又进一步发现，这些原因是导致需求缺陷的原因，包括流程图画不好等。
接下来，我们使用鱼骨图分析，请4个人一起头脑风暴，共识别出十几项主要原因种类。然后，按每人3票的原则，各自单独投票得出排序。最后根据二八原则，我们识别出前三项主要原因，接着，我们根据这三项原因又进一步发现，这些原因是导致需求缺陷的原因，包括流程图画不好等。
香港启德国际机场1996年航班延误统计：
然后我解释：
我们不应直接把几十条原因按他们对问题的影响度从最高排到最低做帕累托图，而应先对原因进行分类。 以机场延误为例，我们需要区分哪些是不可抗力的天然原因（如天气原因），哪些是与闸口管理相关的问题，哪些是与机场打印登机牌相关的问题。 例如，如果识别出与闸口管理相关的问题最多，后续就可以针对这些问题进一步分析根因。 分析才能有针对性和意义。
你们的分类和帕累托图依据的"数据"都不过是用数字来表达你们头脑风暴的主观判断，所以这种帕累托图其实与直接用头脑风暴做出的结论没什么差异。 你们只是用投票数据使结果看起来"量化"了，但其实并没有客观数据支撑。
你们的分类存在问题。 例如只有"功能描述不明确"，难道"非功能需求描述不明确"（如性能、安全性等）就不需要考虑吗?
你们现在的分类有不少是重复的，同样一个问题有可能归属于2、3个分类。
你们的度量操作定义也存在问题。例如，如何根据历史项目的数据判断哪些原因归属于"功能描述不明确"？
建议你们应该首先识别出与想要解决的问题相关的度量项，针对这些度量项收集数据，然后再做分析。 收集客观数据才是根因分析的第一步。
++++
我：你们现在的找出的其实并非根因，只是浮在水面上的现象，你们有听过5W吗？
组长：有，What When ..
我：不，你说的是5W+1H ，5W是五个为什么(Why)，你们应该不断追问"为什么"，才能更好地识别出背后的主因，并针对主因采取纠正措施，避免同类问题重复发生。
接着，我向他们讲述了丰田汽车大野耐一先生的5W故事（详见第一章附件"5Why例子"）。
除了通过问"为什么"之外，还可以通过画整个流程，识别有哪些失效点。
例如，可以像我用FMEA分析因迟到而搭不上飞机的例子（详见附件）那样，画出从需求开始到最终交付的全流程，分析哪个环节的影响最大，再分析原因。
当敏捷开发团队开始理解如何利用缺陷与返工数据，用各种方法分析根因时，还应考虑让各团队成员全心投入参与。只有这样，过程改进才能持久。下章讨论。
附件
航天飞机灾难 （Space Shuttle disasters）
1986: 挑战者号（Challenger）航天飞机升空后，于发射后的第73秒爆炸，机上7名宇航员全部罹难。( 相关视频可以在网上搜到)
直接原因是用来密封火箭液态氢燃料缸的O型橡胶环在摄氏零度低温下不能及时膨胀。 然而，这次事故并非偶然。在升空前，供应商已经警告过低温会影响橡胶的性能；以前的实验中也曾发生橡胶环部分半径只能达到预期半径2/3的情况。但管理层为了按计划预期升空，漠视了这些安全隐患预警。 2003：哥伦比亚号 (Columbia) 航天飞机在返回地球时，因为左翼的隔热保护胶在16天前升空时被固体火箭助推器外层脱落的乳胶击破损坏，导致航天飞机返航时进入大气层的第1000秒钟，在35,000米高空因过热解体，7名宇航员全部罹难。
Sally Ride在2003哥伦比亚号灾难事故调查回顾说 ：我很诧异这两次事故的原因非常相似（她也是挑战者号事故调查组员），1986 年引起挑战者号灾难的陋习再次出现了： 为了赶上计划升空日期，而忽略了之前性能报告的发现，没有注意前线技术工程人员提出的安全隐患，也缺乏安全保障措施。其实，从哥伦比亚号在 1981 年首次升空开始，每次都有燃料缸外的保护乳胶在升空时掉落的事故，但管理层一直没有关注。工程师们为了赶进度，每次升空前都没有时间预先处理好。
虽然调查报告找出了事故的根因，但几年后，管理层依然只关注项目的成本与进度，忽略了质量与安全，没有再注意调研报告指出的隐患，导致事故再次发生。
FMEA 实例
(FMEA: Failure Mode Effects Analysis)
大家可能都经历过因为没有管理好时间而导致迟到的情况。以坐飞机为例，从离开酒店到登上飞机的过程中，很可能因为一些风险导致最后没搭上飞机。
当你出发时，可能选择不同的交通方式，如出租车或机场大巴。如果你不能在起飞前45分钟到达机场办理登机牌，你就无法登机。但即使你拿到了登机牌，也有可能最后没能搭上飞机，因为机组严格执行起飞前15分钟关舱门的规定，所以你还需要在起飞前15分钟到达登机口。
图1 登机过程
要赶上飞机其实是个过程，中间有很多环节会导致最后失败，所以我们可以通过FMEA过程分析来看如何减少失败的概率。
图2 FMEA 例子
图3 打分参考
以第一个失效为例：如果发生就会坐不上飞机，所以严重性最高，评分为10。发生的概率比较高，评分为6。是否容易预防、预警？由于不熟悉当地情况，加上主要依靠酒店前台提供信息，而有时他们也不清楚，所以评分为6。RPN =10×6×6=360。
从以上登机的例子可以看出，FMEA是以整个过程进行风险管理的。比如在出发前，就要查询一下各个交通工具要花费的时间，例如，在出发前，需要查询各个交通工具所需的时间。在南京，从酒店坐地铁需要转车，要花费一个小时以上，如果时间紧张就会来不及，那么宁可多花钱打车，以控制风险。
即使拿到了登机牌，还需要经过安检并到达登机口。有时机场很大，到达登机口也要花很长时间，因此需要提前问好路径并计算好时间，避免误点。
如果从安检到登机口需要超过10分钟，那么就需要在起飞前35分钟通过安检，才能来得及。这些都可以通过FMEA的形式把整个坐飞机的过程识别出来，找出各个阶段可能出现的问题，从而知道如何控制。
以这个坐飞机的风险为例，我自己就多次没赶上飞机。原因很多，但总结一下，都是因为习惯没有改过来。我应依据以往差点赶不上的经验，回顾一下，确保每一个过程都控制住，就不会后面再次出问题 ，这个和企业做风险管理概念一样。
有度量才有管理。人和公司一样，很多事情看似是自己主动去想的，其实很多都是潜意识的习惯。如果没有设定一些量化的控制手段，就不会提高这方面的风险意识，还是会错过飞机。因此，我通过回顾以往几次搭飞机的情况，把每次到达机场的时间和到达登机口的时间记录下来（详见下面图4）。
图4 上面是机场柜台关闭（45分钟）前到达时间，下面是关闸口前到达时间（分钟）（X代表赶不上飞机）
最近一次赶不上飞机是因为未能在关闸门前到达，而之前也有两次类似情况------我刚到闸口，就到时间马上关闸了。
如果我把经验教训记下来，下次做好时间管理，就会避免后面的延误：有了数据，我们便可以更有效在回顾时做好根因分析 (CAR)。
以这登记延误风险为例，可以使用FMEA分析每个失效点，例如过安检（因没有预留足够时间）和从安检到闸口所需时间太长等的发生概率都很高（前者为8，后者为6）。
为了避免问题再发生，就要定一些具体的计划，最终希望把误点减到零。
在登机这个环节，可以利用以下有效方法/工具来帮助改善：
- 每次出发去机场前都查询各种交通方式的时间与风险（概率），预留足够时间，降低失效发生的概率。
- 拿到登机牌后，计划好在起飞前35分钟通过安检
在多次错过飞机后，我发现传统手表没有正负5分钟的准确性，而使用电子手表可以精确到正负1分钟，这有助于更好地把控时间。
图5 平常用于培训/评估计时的电子钟
经过这次误机，我就买了个电子手表，取代传统针式手表，希望对日后不迟到有帮助。
效果：这件事发生在2019年9月，之后我按这些计划行动，再没有出现赶不上飞机的情况。我每次都提醒自己必须在起飞前60 ~ 90分钟到机场，30 ~ 45分钟前到闸口。分析的目的是提高个人风险意识，避免问题发生。