在传统IT项目中，有一个经典的”法则”：花在需求分析上的时间越多，开发返工的可能性越小。
这个法则在需求相对稳定、边界清晰的项目中是成立的。但在数据空间项目中，参与者还在变化、规则还在调整、用例还在涌现，所以如果花三个月写一份完美的设计文档，大概率三个月后设计稿已经过时了。
数据空间开发的现实是：你永远不可能在设计阶段就把所有需求想清楚。 因为很多需求只有在数据空间开始实际运转后才会浮现。新的参与方带来了新的数据类型，新的数据类型催生了新的使用场景，新的使用场景暴露了原有策略的盲区。
这就引出了数据空间开发的一个核心理念：从交付开始，而非从设计开始。
快速交付路线
快速交付路线的输入端包含四个准备工作：发现可用的技术（有哪些开源的连接器实现、有哪些现成的身份认证组件）、组建开发团队（不仅仅是技术团队，还包括运营方和参与方的代表）、锁定目标（第一周期要交付什么，越具体越好，比如”让A和B两家企业之间的碳排放数据可以通过数据空间流通”）、分解任务（把锁定目标分解为可以独立交付的子任务，每一个子任务的交付周期不超过24小时）。
核心过程是”快速交付”，不是”快速开发”，而是”快速交付”。两者区别在于：快速开发只关注”代码写没写完”；快速交付关注的是”功能能不能被使用”。
快速交付的产出是一系列的基线产品：第一个交付物可能只是一个”数据在两个连接器之间打通”的技术验证；第二个交付物可能是”一个使用方可以通过数据目录找到这个数据集”；第三个交付物可能是”数据产品有了使用控制策略”。每一个交付物都是”可用的”，不是”半成品”。
敏捷交付周期
这里建议的敏捷交付节奏是：任务级的交付周期不超过24小时，版本级的交付周期为2~4周。
24小时不是随意定的数字。它的心理学依据是：如果一项任务预计需要超过一天才能完成，人们倾向于把它”挂起来”而不是”持续推进”。24小时周期强制团队”每天都有可交付的东西”，哪怕只是一个连接器的配置更新，也比”在写代码但还没写完”更有价值。
2~4周的版本级交付周期，对应数据空间运营方跟参与方同步新功能的节奏，太短（一周一版），参与方来不及消化新功能；太长（两个月一版），参与方等待新功能的耐心会耗尽。
持续设计：跟快速交付互补
快速交付不是”不做设计”，而是用”持续设计”替代”一次性设计”。
在每个交付周期开始前，花（不超过周期20%的时间做设计。如果一个版本周期是两周，设计阶段不超过两个工作日。
设计不是出”完整的技术方案”，而是出”支撑下一个交付物所需的最小设计方案”，这个API怎么定义、这个策略怎么配置、这个数据产品的元数据怎么写。设计方案跟随交付节奏持续演进，而不是在设计阶段一次性完成。
在任何层面交付
这里强调一条关键原则：交付可以在多个层次上进行。
任务级交付：一个具体的功能模块开发完成。
组件级交付：一个完整的数据空间组件（连接器、控制器、数据目录）部署运行。
系统级交付：数据空间的基础平台跑通。
数据空间级交付：整个数据空间投入运营。
不是所有交付都必须达到”数据空间级”才算成功。一个”任务级”的成功交付，比如配置好一个新的连接器，同样是推进整体进展的实质性步骤。
数据空间开发的”从交付开始”法则，本质上是把”学习的周期”从”先学完再做”变成”边做边学”。放在表格里的设计决策只有在开发过程中才能真正被验证——快速交付是让验证尽可能早地发生。
我是BSN联盟成员。有十年区块链与隐私计算的产品开发和方案咨询经验，先后参与多个国家重大课题，亲手建过区块链、隐私计算、可信数据空间的落地项目。不追概念，写真的。