01-从「会写代码」到「交付特性」.docxVIP

01从「会写代码」到「交付特性」

很多开发者把FDE理解为「前端后端都会」，于是拼命学框架、背API，这恰恰是本末倒置。FDE的真正分水岭不是技术广度，而是交付观：你是否以「用户可感知的价值」为单位来组织工作。

传统研发以「任务」为单位：UI做页面、后端做接口、测试做用例，每个人只对局部负责。FDE以「特性」为单位：一个特性=一段用户可感知的价值+一组可验证的验收标准。比如「用户注册」「订单导出」「首页性能优化」都是一个特性，它们可以独立开发、独立测试、独立上线、独立回滚。

落地时建议做三件事：第一，接到需求先写一句话价值声明（给谁用、解决什么、怎样算做完）；第二，把大需求切成3到7天可交付的特性列表，而不是按「前端任务/后端任务」切；第三，每个特性交付时问自己一句：如果产品经理今天就要演示，我能否演示一条完整闭环？如果不行，说明特性还没真正完成。

自查清单：我能否在5分钟内说清楚最近这个特性解决了谁的什么问题？验收标准是否可被客观验证？这个特性能否独立上线和回滚？三个问题都能答「是」，才算真正进入FDE的工作方式。