效率的敌人不是忙碌，而是看不见的浪费。而PDCA，是照亮浪费的探照灯。
在软件开发与运维领域，"快"常被等同于"高效"。但现实是：许多团队日以继夜地编码、部署、救火，交付周期却未缩短，质量反而下滑。问题不在努力程度，而在系统性浪费------那些不创造客户价值、却消耗资源的活动。
精益思想（Lean Thinking）起源于丰田生产方式，其核心是识别并消除浪费（Muda） 。而PDCA（Plan-Do-Check-Act）循环，则提供了一套可操作的持续改进机制。当两者结合，便形成一种强大的实践范式：以精益为眼，看见浪费；以PDCA为手，消除浪费。
一、软件交付中的七大浪费（源自精益，适配IT）
丰田定义了制造业的七大浪费，经ThoughtWorks等机构适配后，软件工程中的典型浪费包括：
| 浪费类型 | 软件/运维中的表现 | 是否创造客户价值？ |
|---|---|---|
| 1. 过度处理（Over-processing） | 冗余审批、过度设计、不必要的高可用架构 | ❌ |
| 2. 等待（Waiting） | 代码等待Review、测试环境排队、依赖方阻塞 | ❌ |
| 3. 缺陷（Defects） | Bug、配置错误、线上事故导致返工 | ❌ |
| 4. 过量生产（Over-production） | 开发未被使用的需求、提前优化性能 | ❌ |
| 5. 库存（Inventory） | 积压的PR、未上线的功能、技术债 | ❌ |
| 6. 不必要移动（Motion） | 频繁切换上下文、跨系统查日志、重复填表 | ❌ |
| 7. 运输（Transportation） | 信息在团队间低效传递（如口头传需求） | ❌ |
✦ 关键洞察：所有不直接带来用户价值或系统稳定性的活动，都是潜在浪费。
二、案例实证：用"精益×PDCA"缩短部署等待时间
背景
某金融科技公司每周仅能部署2次，主因是"测试环境不足"------开发提交代码后平均等待18小时才能验证。团队抱怨："我们不是慢，是卡住了。"
Step 1：Plan ------ 用精益视角识别浪费
-
观察流程 ：绘制当前部署价值流图（Value Stream Mapping）：
开发完成 → 提交PR → 等待CI队列（2h） → 自动化测试通过 → 申请测试环境（邮件） → 运维人工分配（平均8h） → 手动部署 → 验证 -
识别浪费 ：
- 等待：8小时人工分配环境（占总等待70%）
- 不必要移动：需跨3个系统查环境状态
- 过度处理：每个环境分配需填写5字段表单，其中3项冗余
-
设定目标：将"从PR合入到可验证"时间从18h压缩至≤4h。
-
改进措施 （最小可行）：
- 将测试环境池化，通过API自动分配（基于K8s Namespace）
- 合并表单字段，仅保留"服务名+负责人"
- 部署成功后自动推送通知至企业微信
Step 2：Do ------ 嵌入现有工具链
- 运维团队用3天开发环境自助平台（基于Argo CD + Internal API）
- 开发在PR描述中添加
/deploy-test指令即可触发 - 无需新培训，沿用现有Git工作流
Step 3：Check ------ 用数据验证浪费是否减少
| 指标 | 改进前 | 改进后（2周均值） | 变化 |
|---|---|---|---|
| 平均等待时间 | 18.2h | 3.1h | ↓83% |
| 环境申请人工干预次数 | 24次/周 | 2次/周 | ↓92% |
| 开发满意度（NPS） | +12 | +68 | ↑56分 |
✦ 关键：Check聚焦浪费指标本身（等待时间），而非"是否上线了平台"。
Step 4：Act ------ 将"无等待"固化为标准
- 更新《部署规范》："所有新服务必须支持自助测试环境"
- 在CI流水线加入检查：若PR未触发测试部署，禁止合入主干
- 将该模式推广至预发环境
结果：6周后，团队部署频率从2次/周提升至1.2次/天，且无新增运维人力。
三、另一个案例：消除"缺陷"浪费------从修复到预防
问题
每月线上P2级事故中，35%源于"配置错误"（如超时设为0、开关误开）。
Plan
- 浪费类型：缺陷（导致回滚、排查、用户影响）
- 根因：配置变更无校验，依赖人工记忆
- 目标：配置类事故归零
- 措施：在GitOps流程中加入配置Schema校验
Do
- 使用JSON Schema定义关键配置结构（如timeout > 0, feature_flag ∈ {on,off}）
- 在CI阶段自动校验，失败则阻断合并
Check
- 30天内配置相关事故：0起（此前月均5.2起）
- 开发反馈："现在写错配置，秒级报错，不用等到上线才炸"
Act
- 将Schema模板纳入服务脚手架（Boilerplate）
- 新项目初始化即自带校验能力
✦ 此例体现精益核心：不让缺陷流入下游，比快速修复更重要。
四、为什么"精益×PDCA"比单独使用更有效？
| 方法 | 局限 | 结合后的优势 |
|---|---|---|
| 仅用精益 | 能识别浪费，但缺乏行动框架 | PDCA提供"如何改"的步骤 |
| 仅用PDCA | 可能改进非关键问题（如优化已高效环节） | 精益确保聚焦最大浪费点 |
| 两者结合 | --- | 精准打击高杠杆改进机会 |
✦ 精益回答"改什么 "，PDCA回答"怎么改"。
五、实践建议：启动你的"浪费狩猎"计划
-
每周花30分钟做"浪费扫描"
团队围坐，问："过去一周，哪些时间花得最冤？"归类到七大浪费。
-
选一个"最痛的浪费"启动PDCA
优先选择：高频、高成本、易干预（如等待、缺陷）。
-
用现有工具实现最小闭环
不新建系统，用Git、CI、监控、聊天机器人组合解决。
-
衡量"浪费减少量"，而非"任务完成量"
例：不是"上线了自助平台"，而是"等待时间减少X小时"。
六、结语：效率的本质是"不做无用功"
在资源有限的世界里，真正的提速不是"跑得更快"，而是"少走弯路"。
精益思想教会我们看见浪费 ，PDCA教会我们消灭浪费。二者结合，便是在混沌的工程实践中，开辟出一条清晰、可持续的改进路径。
优秀的工程团队，不以加班为荣，而以消除浪费为傲。
而每一次对浪费的清除，都是对工程师时间与尊严的尊重。
附：软件交付浪费自查清单（可直接用于团队讨论）
| 浪费类型 | 自查问题 |
|---|---|
| 等待 | PR平均等待Review多久？测试环境是否排队？ |
| 缺陷 | 多少Bug本可在CI阶段拦截？ |
| 过度处理 | 是否有无人使用的监控告警？是否过度审批？ |
| 库存 | 有多少已完成但未上线的功能？技术债是否可视化？ |
| 不必要移动 | 查一个问题是否要登录5个系统？ |