本文是《技术开发到团队管理》30 天系列的第 18 篇。这个系列关注的不是管理术语，而是技术负责人每天要做出的真实判断。
开发写代码只占交付周期的一部分。需求等待确认、环境不可用、评审排队、发布手工操作，往往才是主要耗时。
这篇文章尝试回答三个问题：这个概念解决什么管理难题，管理者需要采取哪些具体动作，以及如何在真实项目中验证它。
核心观点
今天我们学习「工程效率」。工程效率是价值从需求到稳定交付的流动能力，改进重点是减少等待、返工、切换和手工摩擦，而不是要求成员持续加速。
方法框架
1. 观察端到端流动
观察端到端流动：从需求进入到上线验证，而不是只看编码工时。
2. 识别四类摩擦
识别四类摩擦：等待、返工、上下文切换、重复手工操作。
3. 用数据定位瓶颈
用数据定位瓶颈：周期时间、部署频率、变更失败率、恢复时间和积压年龄。
4. 小步改进并验证
小步改进并验证：只改一个主要瓶颈，观察指标和团队体验是否改善。
一个具体案例
团队总在上线前两天集中准备配置。把上线清单前移到开发过程持续维护，比要求大家发布日更快操作更能改善效率和质量。
常见误区
效率不是忙碌度，也不是个人完成任务数。局部提速可能把更多未完成工作堆到下游，反而降低整体交付效率。
行动练习
画出一个需求从提出到上线的流程，标出所有等待和返工点，选择成本最高的一处设计最小改进。
留给自己的问题
- 工程效率与个人速度有什么区别？
- 当前流程最大的摩擦在哪里？
- 我会用什么指标验证改进？
小结
工程效率是价值从需求到稳定交付的流动能力，改进重点是减少等待、返工、切换和手工摩擦，而不是要求成员持续加速。