项目背景
美吉姆英语早教是一家教育机构，需要一套线上约课小程序，覆盖课程排期、预约、取消和到店提醒。这类需求看起来不复杂，但教育机构的约课场景有几个容易被低估的细节：课程有排期、时段有容量上限、预约后需要取消和改期、家长到店前需要提醒。如果需求清单只写“预约功能”四个字，开发阶段就会出现“这个功能到底算不算预约”的反复讨论。
我们做了什么
项目启动前，我们先和客户确认需求清单，把“预约”拆成可测试的功能点：课程排期怎么设置、每个时段的预约容量怎么控制、预约后多久可以取消、取消后名额是否释放、到店提醒在预约后多久触发。每个功能点都对应一条验收标准，写进合同附件。
开发阶段按“需求确认—原型设计—开发联调—测试—上线交付”推进。小程序约课端和后台管理端同步开发：家长端完成课程浏览、时段选择、预约和取消；后台管理端支持机构自主排课、查看预约记录、管理时段容量。验收阶段按功能清单逐项打勾，而不是“整体看一眼觉得还行”。
源代码、部署文档和后台操作手册作为交付清单的固定项。后台管理端的操作逻辑在交付时做了录屏说明，机构运营人员可以自己完成排课和预约管理，不需要每次调整都找开发方。
结果
项目于2018年交付，从需求确认到上线验收的整体周期约31个工作日（数据来源：项目交付记录）。后台管理端交付后，机构可以自主完成课程排期、时段容量调整和预约记录查看。
我们的复盘
这个项目让我们确认了一个判断：预约类项目的交付质量，取决于“预约”这个词被拆得多细。只写“预约功能”的需求清单，开发阶段一定会反复；把排期、容量、取消规则、提醒触发拆成可测试的功能点，开发和验收才有共同语言。
这套“需求清单细化到功能点”的做法，后来成了我们做所有预约类项目的标准流程。炙爱自助烤肉线上预约小程序（2022年）也是按同样的颗粒度拆的：时段选择、桌位管理、到店提醒，每个功能点对应验收标准。项目类型不同，但“先拆细、再开发”的逻辑是一样的。
