msumshk/TakeoutSaaS.Prototypes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fd532b54e0769e724031e537b4b1dc2049517cac
TakeoutSaaS.Prototypes/Cend-MiniProgram-Prototype/docs/10-全周期研发实施顺序与交付清单.md

11 KiB
Raw Blame History

全周期研发实施顺序与交付清单

  • 文档版本：V1.0
  • 适用项目：TakeoutSaaS 小程序 C 端
  • 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但阶段混乱、边界失控”

1. 文档目的

本文件回答 4 个问题：

  1. 全周期应该按什么实施顺序推进
  2. 每一阶段需要产出什么交付物
  3. 每一阶段达到什么标准，才算可以进入下一阶段
  4. 如何让实现顺序和当前已经冻结的页面职责保持一致

2. 推荐实施总节奏

阶段 名称 主要目标 核心交付
S0 范围收口 定边界、定版本、定母版文档 08 / 09 / 10 规划文档、页面优先级
S1 信息架构与设计基线 定路由、定组件、定状态与场景差异 路由、低保真、状态矩阵、组件清单
S2 交易主链路开发 跑通选店、点餐、结算、支付主闭环 首页、门店、点餐、抽屉、结算、支付成功
S3 履约与售后开发 补齐订单后半段体验 订单页、订单详情、退款、评价
S4 我的与资产开发 形成身份、资产、复购聚合闭环 我的、会员、积分、储值、次卡
S5 活动导购开发 把活动导流能力前置到顾客端 领券、秒杀、限时折扣、首页活动位
S6 服务与预留补位 补齐服务兜底和预留职责页 帮助中心、消息中心职责页、服务入口
S7 联调验收与上线准备 全局走查、联调和上线准备 联调清单、验收清单、演示脚本

3. 各阶段实施顺序

3.1 S0 范围收口

目标

  • 把“本期做什么、不做什么、先做什么”收口

必做事项

  1. 确认版本分期：V1.0 / V1.1 / V2.0 / V2.1 / V3.0
  2. 确认页面优先级：P0 / P1 / P2
  3. 确认三场景：delivery / pickup / dine_in
  4. 确认后台到前台的功能映射层级：
    • 直接承接
    • 间接支撑
    • 未来扩展
    • 明确不前置

必交付物

  • docs/08-全周期版本规划与范围分层.md
  • docs/09-租户后台与C端功能映射总表.md
  • docs/10-全周期研发实施顺序与交付清单.md
  • 页面优先级结论

完成标准

  • 团队已明确“本期不做什么”
  • 不再有人按后台菜单数量直接推导前台页面数量

3.2 S1 信息架构与设计基线

目标

  • 让后续页面开发不再反复讨论结构边界

必做事项

  1. 确认 4 个 Tab 与全部二级页、抽屉、弹层路由
  2. 确认页面模板：Tab 页、二级页、抽屉、弹层
  3. 确认全局状态矩阵：
    • 默认态
    • 空态
    • 加载态
    • 错误态
    • 禁用态
  4. 确认三场景差异矩阵：外卖 / 自提 / 堂食
  5. 确认页面职责边界：
    • 聚合页
    • 导购页
    • 结果页
    • 预留职责页

必交付物

  • 路由与页面层级总表
  • 页面低保真骨架
  • 全局设计基线
  • 页面状态矩阵
  • 场景差异矩阵
  • 通用组件清单

完成标准

  • 任意页面都能用统一模板快速搭出骨架
  • 新页面设计不会再脱离现有模式和边界

3.3 S2 交易主链路开发

目标

  • 先跑通“当前门店上下文建立 → 点餐 → 结算 → 支付成功”

开发顺序

  1. T01 首页
  2. P01 门店选择页
  3. P02 地址管理页
  4. P18 堂食扫码确认页
  5. T02 点餐页
  6. C01 商品详情抽屉
  7. C02 购物车抽屉
  8. P03 结算确认页
  9. P04 支付成功页

必交付物

  • 路由可跳转的交易主闭环
  • 当前门店 / 当前场景上下文闭环
  • 商品与购物车 mock 或服务层数据
  • 金额试算与结算结果占位逻辑
  • 三场景基础差异展示

验收重点

  • 能否在正确门店和场景下进入点餐
  • 能否看清费用来源、优惠结果和实付金额
  • 能否从支付成功页进入正确后续动作

当前阶段必须守住的边界

  • P03 手动资产当前只确认：
    • 优惠券
    • 余额
    • 次卡
  • 积分抵扣 当前不作为已冻结结算能力
  • C05 支付方式当前只收敛为：
    • 微信支付
    • 余额支付

3.4 S3 履约与售后开发

目标

  • 补齐支付之后的订单、履约、售后和评价体验

开发顺序

  1. T03 订单页
  2. P05 订单详情页
  3. P06 退款申请页
  4. P07 退款详情页
  5. P08 评价页

必交付物

  • 顾客视角订单状态分组
  • 履约时间轴与场景信息区
  • 最小退款申请与退款结果页
  • 最小评价闭环
  • 再来一单入口

验收重点

  • 顾客是否能快速看懂“这单现在到哪一步了”
  • 售后入口和售后结果是否清楚
  • 评价页是否保持最小闭环，不夹带复杂运营玩法

当前阶段必须守住的边界

  • 不把商家看板四列直接搬到订单页
  • 不把商家动作直接前置给顾客
  • 不把 催单 / 骑手轨迹 / 取餐码 写成固定必做按钮

3.5 S4 我的与资产开发

目标

  • 把“我的”做成身份、资产、服务、复购的聚合页

开发顺序

  1. T04 我的页
  2. P12 会员中心页
  3. P13 积分商城页
  4. P14 储值充值页
  5. P15 次卡页

必交付物

  • 我的页身份头部卡、资产摘要、订单快捷入口、服务入口、复购区
  • 会员权益表达
  • 积分余额、兑换内容与兑换记录
  • 储值余额、充值方案与充值记录
  • 次卡模板说明与使用结果记录

验收重点

  • T04 是否仍然是聚合页，而不是资产真源
  • 资产页是否能回流到交易链路，而不只是静态展示
  • 次卡和储值是否按当前证据边界表达，没有写成过满系统

当前阶段必须守住的边界

  • 不把 优惠券数量 / 次卡数量 / 未读消息数 写死成首页强依赖
  • 不把积分商城反向扩成订单积分抵扣总入口
  • 不把消息中心当成已经成型的完整收件箱

3.6 S5 活动导购开发

目标

  • 把活动能力前置为“导购页 + 导流结果”，而不是活动孤岛

开发顺序

  1. 回补 T01 首页动态活动区
  2. 回补 T02 点餐页活动摘要和活动价表达
  3. P09 领券中心页
  4. P10 秒杀活动页
  5. P11 限时折扣活动页
  6. 回补 P03 结算页自动优惠命中说明

必交付物

  • 首页动态活动位
  • 点餐页活动条与活动价商品表达
  • 券模板聚合页
  • 秒杀活动会场
  • 限时折扣活动会场
  • 活动导流回商品和结算的链路说明

验收重点

  • 活动是否真正导流进商品、购物车和结算
  • P09 是否保持“券模板导购页”定位
  • P10 和 P11 是否明确分开，不再用一套活动页糊过去

当前阶段必须守住的边界

  • 满减和新客活动主要做规则结果展示，不做重页面
  • 首页活动位必须动态化，不做固定八宫格
  • 活动页不能绕开标准交易主链路

3.7 S6 服务与预留补位

目标

  • 补齐服务兜底能力和当前只保留职责的预留页

开发顺序

  1. P17 帮助中心页
  2. P16 消息中心页
  3. 回补 T04 服务入口与说明文案
  4. 预留未来发票、客服等扩展入口位

必交付物

  • 帮助中心页
  • 消息中心职责页
  • 服务入口表达
  • 未来扩展入口位规划

验收重点

  • 顾客是否能找到基础帮助和服务兜底入口
  • 是否没有把后台发送中心、FAQ CMS、客服系统直接假定为已完整存在

当前阶段必须守住的边界

  • P16 当前只保留页面职责，不冻结完整消息 inbox
  • P17 当前是服务兜底页，不冻结后台 FAQ / 客服动态能力

3.8 S7 联调验收与上线准备

目标

  • 把前面阶段串成一套真正可演示、可交付、可联调的版本

必做事项

  1. 检查所有页面路由跳转
  2. 检查所有主 CTA 是否闭环
  3. 检查三场景差异是否完整
  4. 检查金额、优惠、状态文案是否一致
  5. 检查登录拦截与回跳逻辑
  6. 检查空态、错误态、禁用态
  7. 检查导购页是否都正确回流到交易主链路
  8. 整理演示脚本、验收清单、联调顺序

必交付物

  • 联调清单
  • 验收清单
  • 演示路径脚本
  • 版本发布说明

完成标准

  • 业务、设计、开发、测试都能按同一套路径演示
  • 新接手的 AI 或工程师可以快速理解全局结构和边界

4. 推荐交付物清单

阶段 必交付物
S0 分期文档、映射文档、实施文档
S1 低保真、状态矩阵、场景矩阵、组件清单
S2 交易主链路页面、mock 数据、跳转脚本
S3 履约售后页面、状态时间轴、订单操作脚本
S4 我的页与资产页、资产回流脚本
S5 活动页、活动入口、活动承接脚本
S6 服务页、预留职责页、服务入口规划
S7 联调文档、验收清单、演示说明

5. 如果是个人或 AI 独立推进，建议这样执行

模式 A：先文档后代码

  1. 先补齐文档、边界和低保真
  2. 再实现可点击原型或页面骨架
  3. 最后把原型骨架转成真实小程序代码

模式 B：边文档边代码

  1. 每完成一个页面规格，就同步搭建页面骨架
  2. 每完成一个阶段，就统一走查路由、状态和边界
  3. 不要跨阶段抢做复杂资产、复杂营销或分析页

模式 C：只做 MVP

  1. 只做 S0 + S1 + S2 + S3
  2. 上线后再根据业务反馈扩展 S4-S7

6. 阶段切换门槛

从 S1 进入 S2 前

  • 页面结构、路由、组件模板已稳定

从 S2 进入 S3 前

  • 主交易闭环可完整演示

从 S3 进入 S4 前

  • 订单与售后体验清晰，没有主流程断点

从 S4 进入 S5 前

  • 资产页已能回流到交易链路

从 S5 进入 S6 前

  • 活动页不是孤岛，已能导流到交易闭环

从 S6 进入 S7 前

  • 页面、服务、活动、资产已基本成套

7. 实施时最容易踩的坑

  1. 一开始就想把所有资产、活动、服务一起做完。
  2. 先画很多视觉稿，却没有先收口状态和流程。
  3. 把后台字段原样搬到前台，没有翻译成顾客语言。
  4. 把后台发送中心、财务驾驶舱、分析页直接当成前台设计来源。
  5. 只做页面，不做关键跳转与交互闭环。

8. 最终建议

这套项目最稳的推进方式不是“按页面零散推进”，而是：

  1. 先按版本收口
  2. 再按闭环推进
  3. 然后按阶段交付
  4. 最后统一联调与上线准备

只有这样，租户后台到 C 端小程序的关系才会清晰，整个项目也不会越做越散。

Reference in New Issue View Git Blame Copy Permalink