INFO6007 Week 05 Quality Management 讲课总结
INFO6007 Week 05 讲课总结：Quality Management
课程：INFO6007 — Project Management in IT，Semester 2 2026 讲义：
Lecture - INFO6007 Week 05 - Quality Management.pdf（63 页） 参考：Schwalbe, K. (2018). Information Technology Project Management, pp. 327–364.本讲的主线是 质量管理的三个过程，配合 七种质量工具 和 两位质量大师的方法论，终点落在 Cost of Quality（CoC vs CoNC）。
📢 课堂公告：Week 6 有客座讲座（HJ from HEO，晚 8 点起）；⚠️ 项目看板改用新方式（详见 Week 05 Tutorial）。
一、什么是质量
定义
PMBOK 定义：「Quality is the degree to which a set of inherent characteristics fulfill requirements.」 （质量是一组固有特性满足要求的程度。）
通俗说：质量是产品或服务满足要求、满足期望、并适合其预期用途的程度。
IT 项目中质量的六个维度
| 维度 | 问的问题 |
|---|---|
| Functionality（功能性） | 它做了它该做的事吗？ |
| Reliability（可靠性） | 它能持续无故障运行吗？ |
| Performance（性能） | 它够快够高效吗？ |
| Usability（易用性） | 对终端用户直观吗？ |
| Maintenance（可维护性） | 能方便地更新和改进吗？ |
| Security（安全性） | 数据和系统受保护吗？ |
质量的三种视角（重点）
| 视角 | 含义 | 讲义的薪资系统例子 |
|---|---|---|
| Conformance to
Requirements （符合要求） |
交付的东西是否符合范围/规格文档？ | 薪资系统能正确计算工资和税吗？ |
| Fitness for
Use （适合使用） |
系统是否真的有效服务用户？ | 系统「能跑」，但如果太慢或太难用，它就缺乏质量 |
| Customer
Satisfaction （客户满意） |
质量最终由终端用户/客户的体验判定 | 即使是零 bug 的软件，如果没满足真实业务需求，也是「低质量」 |
这三个视角是层层递进的，也是本讲最重要的概念之一： 符合规格 → 能用好用 → 客户真的满意。 通过所有测试只保证了第一层。 讲义后面那道选课系统的讨论题（见第七节）整个就是在攻击这一点。
二、项目质量管理
Project Quality Management 确保项目的交付物满足干系人期望、要求和约定标准，同时确保项目过程本身高效且有效。
它同时管两件事：
| 对象 | 名称 |
|---|---|
| 交付物的质量 | 产品质量（product quality） |
| 项目过程的质量 | 过程质量（process quality） |
四大原则
| # | 原则 | 含义 |
|---|---|---|
| 1 | Customer focus（客户导向） | 终端用户满意度是最终的质量衡量标准 |
| 2 | Prevention over Inspection（预防优于检查） | 预防缺陷比事后修复便宜得多 |
| 3 | Continuous Improvement（持续改进） | 利用经验教训和反馈回路（Agile、Kaizen、DevOps） |
| 4 | Fact-based decision making（基于事实决策） | 使用指标、仪表盘和数据分析 |
原则 2 是全章的灵魂，后面的 Cost of Quality、Deming 第 3 点、风险与缺陷预防，全都是它的展开。
三、三大过程
| # | 过程 | 核心 | 面向 |
|---|---|---|---|
| 1 | Planning Quality Management | 识别质量要求与标准，以及如何证明合规 | 计划 |
| 2 | Managing Quality（即 QA） | 把计划转化为可执行的质量活动；预防缺陷 | 过程 |
| 3 | Controlling Quality（即 QC） | 监控并验证交付物是否达标；检测缺陷 | 产出 |
1. 规划质量管理
识别三件事： - 项目与交付物的质量要求和标准 - 如何证明和衡量合规 - 从一开始就把质量内建进去所需的活动、资源和指标
目标：定义「质量」对本项目意味着什么；确定标准、政策与指标；确定过程、工具与技术；明确角色与职责（谁在什么时候用什么方式检查什么）。
关键活动：识别质量标准 → 定义质量指标 → 规划 QA 活动 → 规划 QC 活动 → 写入质量管理计划（QMP）。
四类角色与职责
| 角色 | 主要职责 |
|---|---|
| Project Manager | 编制维护 QMP；确保标准与项目目标和客户要求对齐；在成本、时间、质量之间做权衡；监控 CoQ、CoC、CoNC；批准纠正与预防措施 |
| QA Lead / QA 团队 | 定义并实施 QA 过程、方法和指标；执行审计验证是否遵守标准；制定测试策略；向 PM 报告质量问题与风险 |
| QC / 测试团队 | 执行测试（单元、集成、系统、UAT、性能）；记录缺陷；使用质量工具监控；验证修复；向开发团队反馈以预防缺陷 |
| 开发团队 | 遵守编码标准；交付给 QA 前完成同行评审和单元测试；实施预防与纠正措施；维护可追溯性文档 |
注意 PM 是唯一负责「权衡」的角色 —— QA/QC 保证标准，但在成本、时间、质量之间做取舍是 PM 的职责。
IT 领域的四个质量标准
| 标准 | 全称 | 关注点 |
|---|---|---|
| ISO 9001 | Quality Management Systems | 通用质量管理体系；持续改进、客户满意、过程文档化 |
| ISO/IEC 27001 | Information Security Management | 把安全作为 IT 质量的核心组成；保障数据的机密性、完整性、可用性；金融、医疗、政府 IT 项目常强制要求 |
| CMMI | Capability Maturity Model Integration | 评估与改进软件开发过程的框架，五个等级 |
| ITIL | IT Infrastructure Library | IT 服务管理（ITSM）框架；质量 = 服务与业务需求对齐并提供价值；强调 SLA 与持续服务改进（后续课程会细讲） |
CMMI 五级（考点）
| 级别 | 名称 | 特征 |
|---|---|---|
| 1 | Initial | 不可预测、临时应付（ad hoc） |
| 2 | Managed | 过程是项目特定的 |
| 3 | Defined | 过程在整个组织内标准化 |
| 4 | Quantitatively Managed | 指标驱动的过程 |
| 5 | Optimizing | 持续改进 |
记忆线索：从「没规矩」→「单个项目有规矩」→「全组织有规矩」→「用数据管规矩」→「不断改进规矩」。 第 2 级和第 3 级的分界是「项目级 vs 组织级」，这是最容易考的一对。
2. 管理质量（Managing Quality = QA）
把 QMP 转化为可执行的质量活动。 确保项目过程被遵守；重点是预防缺陷，而不只是检测缺陷。 在 IT 项目中，这意味着把质量嵌入开发、测试和交付的工作流。
四个关键活动
| 活动 | 定义 | 例子 |
|---|---|---|
| Process
Audits （过程审计） |
系统性审查项目过程，检查团队是否遵守既定标准、政策和程序 | 审计开发者是否使用安全编码实践（OWASP）；检查敏捷团队是否为 user story 补充验收标准；验证 CI/CD 流水线是否正确记录测试结果 |
| QA
Reviews （质量保证评审） |
对交付物和过程的结构化评估，贯穿项目全程。包括同行评审、设计走查、回顾会 | 代码同行评审；架构评审评估微服务可扩展性；敏捷 sprint 回顾识别过程缺口 |
| Continuous Process
Improvement （持续过程改进） |
持续优化过程。常由 PDCA（Plan–Do–Check–Act）或六西格玛 DMAIC 指导 | 改进构建自动化以减少手工部署错误；用缺陷周转时间优化 QA 工作流；手工回归测试 → 自动化回归套件 |
| Risk and Defect
Prevention （风险与缺陷预防） |
识别可能导致缺陷的过程弱点或风险，在其发生前解决 | 静态代码分析（SonarQube）；威胁建模预判安全风险；评审第三方 API 依赖 |
第四项的理由讲义写得很直白：「预防远比事后修复缺陷便宜（cost of quality 原则）」 —— 又回到四大原则的第 2 条。
敏捷与 DevOps 视角的 QMP
| Agile 版 QMP | DevOps 版 QMP |
|---|---|
| 质量是共同责任（Shared Responsibility） | 处处自动化（Automation Everywhere） |
| 以客户为中心的质量 | CI/CD 持续集成与交付 |
| 持续测试（Continuous Testing） | 监控与可观测性 |
| 频繁反馈 | 基础设施即代码（IaC） |
| 自适应的 QMP | — |
| 聚焦：增量式地交付质量 | 聚焦：端到端地保证持续质量 |
3. 控制质量（Controlling Quality = QC）
监控并验证交付物是否满足既定的质量标准和要求。
| 特征 | 说明 |
|---|---|
| 反应式（reactive） | 检测交付物中的缺陷 |
| 面向产出 | 关注产品、服务、结果，而非过程 |
| 把关 | 确保只有被批准的交付物才被接受 |
五个关键活动
| 活动 | 说明 |
|---|---|
| 测试与检查 | 对照既定要求验证交付物 |
| 缺陷识别与记录 | 记录测试中发现的问题 |
| 对照质量指标衡量 | 把实际表现与计划阈值比较 |
| 验收决策 | 接受 / 有条件接受 / 拒绝 |
| Verification 与 Validation | 见下 |
Verification vs Validation（必考）
| 问题 | 含义 | |
|---|---|---|
| Verification（验证） | "Did we build it right?" | 是否符合规格 |
| Validation（确认） | "Did we build the right thing?" | 是否满足用户需求 |
这一对必须能秒答。记忆法： Verification 对的是「文档」，Validation 对的是「人」。 一个系统可以完美通过 verification（完全符合规格）却在 validation 上失败——因为规格本身就写错了。
四类测试
| 测试 | 对象 |
|---|---|
| Unit（单元） | 孤立地测试单个组件或模块 |
| Integration（集成） | 测试多个模块之间的交互 |
| System（系统） | 对照需求测试完整的集成系统 |
| User Acceptance（UAT） | 由终端用户或客户执行的最终测试 |
💡 讲义写了 "And many more!" —— 性能测试、负载测试、安全测试等都属于 QC 范畴。这个提示在后面的讨论题里变成了关键。
QA vs QC 对照（最高频考点）
| QA = Managing Quality | QC = Controlling Quality | |
|---|---|---|
| 对象 | 过程（process） | 产品/产出（product） |
| 性质 | 主动预防（proactive, prevention） | 被动检测（reactive, detection） |
| 典型活动 | 过程审计、同行评审、过程改进 | 测试、检查、缺陷记录、验收决策 |
| 提问方式 | 「我们的做事方式对吗？」 | 「做出来的东西合格吗？」 |
四、七种质量工具与技术
| 工具 | 是什么 | 用来做什么 |
|---|---|---|
| Cost-Benefit
Analysis （成本效益分析） |
评估质量活动的成本 vs 预期收益 | 按 ROI 排定质量举措优先级。例：自动化测试工具的成本 vs 缺陷减少与发布加快 |
| Cause and Effect
Diagram （因果图 / 鱼骨图 / Ishikawa） |
识别质量问题潜在根因的可视化工具 | 系统性地调查缺陷或问题 |
| Control
Chart （控制图） |
展示过程随时间的表现，带上下控制限 | 检测超出可接受阈值的波动或趋势 |
| Checksheet （检查表） |
实时收集和统计数据的结构化表单 | 简化缺陷、错误或过程失败的数据收集 |
| Flowchart （流程图） |
可视化映射流程步骤 | 识别流程缺口、冗余和潜在质量风险点 |
| Scatter
Diagram （散点图） |
展示两个变量之间关系的图 | 识别相关性，检测质量问题的潜在原因或趋势 |
| Histogram （直方图） |
展示数据频率分布的条形图 | 理解模式、常见缺陷类型或错误分布 |
| Pareto
Chart （帕累托图） |
条形图 + 累积折线图 | 识别最重大的问题（80/20 法则） |
帕累托原则（80/20 法则）
大约 80% 的问题由 20% 的原因造成。
用途：把改进精力集中在造成大多数缺陷的那少数问题上。
💡 区分三个容易混的图： - Pareto：找哪些问题最值得先解决（按频次排序 + 累积线） - Histogram：看分布形状（不排序） - Control Chart：看随时间的波动是否失控（有控制限）
五、演进中的 IT 质量实践
背景：随着 IT 项目越发复杂和快节奏，传统质量管理方法（检查表、人工检验、后期测试）已经不够用了。组织转向强调速度、自动化和持续改进的现代实践。
Lean Six Sigma in IT
| 关注点 | |
|---|---|
| Lean（精益） | 消除浪费 —— 冗余流程、缺陷解决延迟、过度文档 |
| Six Sigma（六西格玛） | 减少变异和缺陷，用数据驱动的 DMAIC（Define–Measure–Analyze–Improve–Control） |
在 IT 项目中的应用：减少交接（handoff）以精简开发流程；用缺陷根因分析和统计方法提升软件可靠性。
注意区分两个缩写：PDCA 用于持续过程改进的日常循环；DMAIC 是六西格玛的结构化改进方法。
AI in Quality
AI 帮助在质量问题发生前预测和预防它们 —— 把质量保证从「反应式缺陷检测」推向「主动式缺陷预防」。
例子：AI 驱动的代码分析（SonarQube + ML）标记潜在缺陷；预测性分析评估项目风险和缺陷概率；AI 机器人做探索性测试和回归测试。
自动化与 DevOps 集成
| 实践 | 说明 |
|---|---|
| 自动化测试 | 单元、集成、回归、性能测试嵌入 CI/CD 流水线 |
| 持续质量门禁 | 缺陷超过阈值时构建被自动拒绝 |
| 基础设施自动化（IaC） | 防止环境相关的缺陷 |
收益：更快发布、减少人为错误、跨环境的一致质量。
六、两位质量大师
Deming 的十四点管理原则
| # | 要点 | 含义 |
|---|---|---|
| 1 | Create constancy of purpose | 聚焦长期目标、质量改进和创新，而非短期利润 |
| 2 | Adopt the new philosophy | 把质量当作每个人的责任 |
| 3 | Cease dependence on inspection | 把质量建进过程，而不是依赖事后检验 |
| 4 | End awarding business on price alone | 关注长期供应商关系与质量 |
| 5 | Improve constantly and forever | 过程、产品、服务的持续改进 |
| 6 | Institute training on the job | 确保员工具备质量所需的知识和技能 |
| 7 | Adopt and institute leadership | 领导者应帮助人们做得更好，而不只是监督 |
| 8 | Drive out fear | 鼓励开放沟通，让人敢于报告问题而不必害怕 |
| 9 | Break down barriers between departments | 促进跨团队协作 |
| 10 | Eliminate slogans and targets | 避免无意义的数字目标，聚焦改进过程 |
| 11 | Eliminate numerical quotas and MBO | 避免只盯数字，聚焦质量与持续改进 |
| 12 | Remove barriers to pride of workmanship | 让员工能为自己的工作感到自豪 |
| 13 | Institute education and self-improvement | 推动全员持续学习 |
| 14 | Put everyone to work on the transformation | 质量改进是各层级的共同责任 |
第 3 点是 Deming 思想的核心，也和四大原则的「预防优于检查」完全一致。 第 8 点「驱除恐惧」在软件团队里尤其现实：如果报 bug 会被责怪，缺陷就会被藏起来，质量数据全部失真。
Deming 对 QMP 的作用：让 QMP 以过程为中心、以预防为主、以持续改进为常态。
Juran 的十步质量改进（强调高层承诺）
| # | 步骤 | 说明 |
|---|---|---|
| 1 | Build awareness of the need for improvement | 管理层必须传达质量的重要性和潜在收益 |
| 2 | Set goals for improvement | 定义清晰、可衡量的质量目标 |
| 3 | Organise to reach the goals | 分配责任，组建改进团队 |
| 4 | Provide resources | 确保足够的预算、工具、培训和人员 |
| 5 | Train personnel | 让员工具备质量改进所需技能 |
| 6 | Take action to improve | 基于分析实施流程变更或纠正措施 |
| 7 | Report progress | 用指标跟踪并沟通改进 |
| 8 | Give recognition | 表彰贡献者 |
| 9 | Communicate results | 全组织分享成功、失败与经验教训 |
| 10 | Maintain momentum | 把改进固化进标准流程，并持续寻求提升 |
Juran 与 Deming 的分工（考试容易问二者区别）： - Deming = 哲学与文化：十四点讲的是组织该秉持什么理念（预防、驱除恐惧、破除部门壁垒） - Juran = 可执行的路线图：十步讲的是具体怎么落地（设目标、给资源、报进展、给认可） - Juran 的独特强调点是「高层管理承诺」 —— 十步里第 1、3、4 步全是管理层的动作
七、Cost of Quality（质量成本）
Cost of Quality（CoQ） 是为确保产品或服务满足质量要求而发生的总成本 —— 即预防、检测和纠正缺陷的成本。
四组权衡
| 权衡 | 说明 |
|---|---|
| Cost vs Quality | 更高质量通常需要更多投入（预防、测试、培训）；削减成本会增加缺陷和返工 |
| Time vs Quality | 紧张的进度会迫使削减测试或走捷径，损害质量；延长工期能做充分 QA 但成本上升 |
| Scope vs Quality | 增加功能会稀释对既有功能质量的关注 |
| Prevention vs Quality | 在预防上投入（培训、标准）能减少后期缺陷 |
CoC vs CoNC（必考对照表）
| 方面 | Cost of Conformance（CoC） | Cost of Non-Conformance（CoNC） |
|---|---|---|
| 定义 | 为确保产品/服务达标而付出的成本 | 产品未能达标时产生的成本 |
| 重点 | 主动预防缺陷 | 被动修复缺陷 |
| 构成 | Prevention（预防）+ Appraisal（评估） | Internal Failures（内部失败）+ External Failures（外部失败） |
| IT 例子 | 自动化测试、代码评审、培训 | 修 bug、系统宕机、客户投诉 |
| 目标 | 最小化未来成本、提升可靠性 | 最小化失败带来的影响 |
「构成」那一行是最常考的： CoC = 预防 + 评估；CoNC = 内部失败 + 外部失败。
内部 vs 外部失败的分界线是「有没有交到客户手上」： - 内部失败：发布前发现并修复（返工、重测）—— 便宜 - 外部失败：客户发现（宕机、投诉、赔偿、声誉损失）—— 最贵
这解释了为什么「预防优于检查」是原则：成本沿着「预防 → 评估 → 内部失败 → 外部失败」逐级放大。
八、课堂讨论题：选课系统的教训
场景：某大学开发了新的在线选课系统。项目全程遵守了批准的质量计划： - ✅ 所有功能测试用例全部通过 - ✅ 完成了代码评审和安全检查 - ✅ 发布前无遗留严重缺陷 - ✅ 测试期间系统达到了响应时间目标 - ✅ 客户批准上线
PM 据此报告：系统已就绪，满足全部质量要求。
然而选课一开放，数千名学生同时涌入。系统极度缓慢，部分用户收到错误信息，还有学生不确定自己是否选课成功。
三个问题与分析
① 如果系统通过了每一项计划中的测试，能说它的质量被成功管理了吗？
不能。
理由：这只满足了质量三视角中的第一层「Conformance to Requirements」，但在 「Fitness for Use」和「Customer Satisfaction」上彻底失败 —— 正好印证了讲义那句 「即使是零 bug 的软件，如果没满足真实业务需求，也是低质量」。
② 主要问题出在规划质量、管理质量、还是控制质量？
根源在「规划质量」（Planning Quality Management）。
为什么不是 QC：QC 忠实地执行了计划中要求的所有测试，并且全部通过。QC 没有失职——它只能测计划让它测的东西。
真正的失败是：质量计划里从来就没有「并发负载」这条质量要求。 - 响应时间目标是在测试环境的低负载下验证的 - 没有定义峰值并发用户数这个质量指标 - 没有规划负载测试 / 压力测试
讲义在「四类测试」后面写的那句 "And many more!"，在这道题里成了关键 —— 性能与负载测试没被纳入计划。
③ 哪些质量标准、测试活动或干系人输入本可以避免这个局面？
| 类别 | 具体措施 |
|---|---|
| 质量指标 | 定义峰值并发用户数（如「支持 5000 并发用户，响应 < 2 秒」），而不只是笼统的「响应时间目标」 |
| 测试活动 | 负载测试与压力测试；在模拟生产规模的环境下测试；故障恢复测试 |
| 干系人输入 | 教务处应提供「选课开放时的历史并发峰值」 —— 这是只有业务方才知道的关键输入 |
| 验收标准 | 把性能门槛写进发布准出条件（对比 NSW 数字驾照案例：「达成约定标准且严重缺陷关闭才允许全州发布」） |
| UAT 设计 | UAT 应在真实使用场景下进行，而不只是功能走查 |
这道题的终极教训： 测试通过率是 QC 的指标，不是质量的指标。 如果质量计划本身漏掉了一个维度，那么后续所有的 QA 和 QC 活动都不可能发现它 —— 缺陷在规划阶段就已经注入了。
九、课后案例：TechSolutions HRM 系统
背景：TechSolutions Pty Ltd 为大客户开发云端人力资源管理（HRM）系统，模块包括员工管理、薪资、考勤、绩效跟踪，工期紧张，仅 6 个月。
第 4 个月末首次重大发布，客户报告多个缺陷： - 薪资模块对某些员工加班费计算错误 - 考勤模块偶尔无法与生物识别设备同步 - 绩效模块在为超过 500 名员工生成报表时崩溃
QA 团队做了单元测试和集成测试，但由于时间限制，系统测试和 UAT 都很有限。
六道题的分析要点
① 遗漏了哪些类型的测试？如何本可预防这些缺陷？
| 缺陷 | 遗漏的测试 | 为什么能预防 |
|---|---|---|
| 加班费算错 | UAT | 加班规则是业务规则，只有真实 HR 用户用真实边界案例（跨夜班、公共假日）才能发现 |
| 生物识别同步失败 | 系统测试（端到端） | 集成测试只测模块间接口，不测与外部硬件设备的完整链路 |
| 500+ 员工时崩溃 | 性能 / 负载测试 | 单元和集成测试都用小数据集，规模问题只有在真实数据量下才暴露 |
注意这三个缺陷刚好对应「测试金字塔上被砍掉的三层」——单元和集成测试做了，越往上越接近真实使用的测试反而被时间压力砍掉了。这正是 Time vs Quality 权衡的教科书案例。
② 用因果图（Ishikawa）分析薪资模块缺陷的根因
按经典的鱼骨分类展开：
| 类别 | 可能根因 |
|---|---|
| People（人） | 开发者不理解加班的业务规则；缺乏领域培训；无 HR 专家参与 |
| Process（过程） | 需求中加班规则定义模糊；没有验收标准；UAT 被削减 |
| Methods（方法） | 测试用例未覆盖边界情况（跨夜、公共假日、部分工时）；无边界值测试 |
| Tools（工具） | 缺少自动化回归测试；测试数据不具代表性 |
| Environment（环境） | 测试环境的数据集与生产不符 |
| Materials/Data（数据） | 测试数据不含触发该 bug 的员工类型 |
③ 把报告的缺陷归类为 CoC 还是 CoNC
报告中的三个缺陷全部是 CoNC（Cost of Non-Conformance），而且是外部失败——因为是客户发现的。
| 项目 | 分类 |
|---|---|
| 修复三个缺陷的返工成本 | CoNC — 外部失败（客户已发现） |
| 交付延期、客户不满 | CoNC — 外部失败 |
| （假设）发布前自己测出并修掉的 bug | CoNC — 内部失败 |
| 原本的单元测试、集成测试、代码评审 | CoC — 评估（Appraisal） |
| 本该做但被砍掉的系统测试、UAT、性能测试 | CoC — 评估 |
| 本该做的领域培训、需求澄清 | CoC — 预防（Prevention） |
这题的核心洞见：项目为了赶工期省下了 CoC（砍测试），结果付出了更大的 CoNC（外部失败）。 这就是「预防优于检查」的量化版本 —— 省下的评估成本，最终以数倍的失败成本还回来。
④ 用 Juran 十步提出预防措施
| Juran 步骤 | 对本项目的具体措施 |
|---|---|
| 2. 设定目标 | 定义可衡量的质量目标：如「薪资计算准确率 100%」「支持 5000 员工报表生成」 |
| 4. 提供资源 | 为 QA 分配足够的时间和人力 —— 这正是本项目失败的直接原因 |
| 5. 培训人员 | 对开发和 QA 团队做 HR 领域业务规则培训 |
| 6. 采取改进行动 | 引入自动化回归测试和代表性测试数据集 |
| 7. 报告进展 | 用缺陷密度、测试覆盖率等指标定期汇报 |
| 10. 保持势头 | 把系统测试和 UAT 固化为发布准出的强制门禁，不允许因工期削减 |
⑤ 用 Deming 十四点改进开发过程
| Deming 点 | 应用 |
|---|---|
| 3. 停止依赖检验 | 把质量建进过程：静态代码分析、CI 中的自动化测试门禁 |
| 5. 持续改进 | 对三个缺陷做根因分析并固化改进 |
| 6. 岗位培训 | 补足领域知识（HR 业务规则） |
| 8. 驱除恐惧 | 让 QA 敢于说「测试时间不够，不能发布」 —— 本案例中很可能正是这个环节失守 |
| 9. 打破部门壁垒 | 开发、QA、客户业务方尽早协作 |
| 1. 长期目标 | 不为赶 6 个月的期限牺牲长期的产品可靠性和客户关系 |
⑥ 高层管理承诺的作用
这是 Juran 的核心主张。在本案例中：
- 「工期紧张」这个约束是管理层设定的 —— 削减 QA 时间的根本决定权在管理层，不在 QA 团队
- 只有管理层能 提供资源（增加 QA 人手或延长工期）
- 只有管理层能 确立「质量门禁不可绕过」的政策，并在压力下坚持它
- 管理层的认可与奖励机制决定了团队是追求「按时发布」还是「发布得对」
一句话总结：如果管理层只考核交付日期，那么任何 QMP 都会在期限压力下被架空。
十、考点重点
- PMBOK 的质量定义：「一组固有特性满足要求的程度」。
- 质量的三种视角：符合要求 → 适合使用 → 客户满意，层层递进；零 bug 也可能是低质量。
- 四大原则，尤其 预防优于检查。
- QA（管理质量）vs QC（控制质量）：过程 vs 产品；预防 vs 检测；主动 vs 被动。
- Verification（"Did we build it right?"）vs Validation（"Did we build the right thing?"）。
- 验收决策三种结果：接受 / 有条件接受 / 拒绝。
- CMMI 五级：Initial → Managed → Defined → Quantitatively Managed → Optimizing；2 级与 3 级的分界是「项目级 vs 组织级」。
- 四个标准的定位：ISO 9001（通用 QMS）、ISO 27001（信息安全）、CMMI（过程成熟度）、ITIL（服务管理 + SLA）。
- 七种质量工具要能列出并说明用途；Pareto = 80/20，条形图 + 累积线；区分 Pareto / Histogram / Control Chart。
- PDCA vs DMAIC：前者是持续改进循环，后者是六西格玛方法。
- Deming 十四点的核心是第 3 点「停止依赖检验」；第 8 点「驱除恐惧」在软件团队尤其现实。
- Deming（哲学/文化）vs Juran（可执行路线图 + 高层承诺）。
- CoC = 预防 + 评估；CoNC = 内部失败 + 外部失败；成本沿「预防→评估→内部失败→外部失败」逐级放大。
- 四组权衡：成本、时间、范围、预防，各自与质量的关系。
- 选课系统讨论题的结论：测试全通过 ≠ 质量合格；缺陷可能在规划阶段就注入了。
十一、本讲与前后的衔接
| Week | 内容 | 关键词 |
|---|---|---|
| 3 | 时间管理 | WBS、关键路径 |
| 4 | 成本管理 | EVM、成本基线、储备 |
| 5 | 质量管理 | QA/QC、七种工具、CoQ |
| 6 | 资源管理（含客座讲座） | Maslow 需求层次 |
与 Week 4 的三处直接呼应： 1. CoQ 是成本管理的延伸 —— PM 的职责里明确写着「监控 CoQ、CoC、CoNC」 2. Cost-Benefit Analysis 作为质量工具，用的正是 Week 4 的成本思维（按 ROI 排优先级） 3. NSW 数字驾照案例贯穿两周 —— Week 4 讲它的成本控制，Week 5 讲它的质量门禁（「达成约定标准且严重缺陷关闭才允许全州发布」）
⚠️ 注意：与 Week 4 一样，Week 5 的 tutorial 内容仍然滞后一周 —— 这次做的是 Week 4 的 EVM 计算题（见 Week 05 Tutorial 解析）。