第04章 如何做工程交付

创新探索解决的是“方向是否成立”，工程交付解决的是“方案能不能可靠落地”。

很多研发绩效问题，并不是团队不会探索，而是探索之后无法稳定交付。Demo 能跑，产品不能用；功能能上线，质量不可控；项目能完成，后续维护成本很高。

所以，工程交付不是简单地“把功能做完”，而是：

把经过验证的方案，做成可靠、可维护、可复用、可规模化的系统能力。

工程交付的核心问题

工程交付至少要回答五个问题：

如果只完成第一个问题，不能算高质量工程交付。

工程交付和创新探索的关系

探索和交付不是对立关系，而是前后衔接。

探索：降低方向不确定性
交付：降低工程不确定性

探索阶段的产出，不应该只是一个 Demo，而应该给工程交付提供明确输入：

1. 哪些假设已经被验证；
2. 哪些风险仍然存在；
3. 哪些指标必须达成；
4. 哪些范围可以延后；
5. 哪些技术债是有意识接受的。

如果探索没有结论，交付阶段就会变成补课；如果交付没有质量约束，探索成果就会变成一次性表演。

什么叫交付完成

工程交付最容易被误解的地方，是把“开发完成”当成“交付完成”。

更合理的交付完成标准应该包括：

交付完成不是一个时间点，而是一组工程条件被满足。

工程交付的绩效维度

工程交付阶段，可以更强地使用 KPI，但仍然不能只看单一指标。

建议至少看四类维度：

这里的关键是组合判断。交付快但质量差，不是高绩效；质量好但长期无法交付，也不是高绩效；效率高但技术债失控，同样不可持续。

技术债如何进入绩效

技术债不是完全不能有。

为了验证方向、抢时间窗口、降低初期成本，团队可以有意识地接受技术债。但技术债必须被看见、被记录、被评估、被偿还。

可以把技术债分为三类：

绩效体系不应该惩罚所有技术债，但必须惩罚不可见、不可控、不可偿还的技术债。

工程交付的常见误区

1. 只看按期完成

按期完成很重要，但不能单独作为高绩效结论。

如果按期完成靠的是砍测试、绕流程、隐瞒风险、牺牲可维护性，那么它只是把成本推给未来。

2. 把质量当成测试团队的问题

质量不是测试最后兜底，而是研发全过程的问题。

需求理解、架构设计、代码实现、测试策略、发布策略、监控告警、事故复盘，都会影响质量。

3. 用英雄式交付替代系统能力

偶尔靠少数人熬夜救火可以理解，但如果长期依赖英雄式交付，说明系统能力不足。

高质量工程交付应该让组织越来越不依赖单点英雄。

4. 没有沉淀

项目结束后，如果没有文档、组件、工具、复盘、规范，下一次还要从头再来。

没有沉淀的交付，只完成了项目，没有提升组织能力。

工程交付的管理节奏

工程交付需要稳定节奏。

建议按阶段管理：

工程交付的本质，是把风险前移，而不是把问题留到最后集中爆发。

小结

工程交付的绩效评价，不应该只问“有没有做完”，而应该问：

1. 是否满足真实使用场景；
2. 是否稳定可靠；
3. 是否质量可控；
4. 是否技术债可见、可控、可偿还；
5. 是否提升了未来交付效率；
6. 是否形成了可复用的组织能力。

探索阶段要保护不确定性，交付阶段要消化不确定性。

一个好的研发团队，既要能探索新方向，也要能把方向做成可靠系统。这两件事缺一不可。