跳转至

工作量评估说明

项目名称： 千乘坊（ride-loop）
文档状态： 草稿
负责人：
主要读者： 项目负责人 | 商务 | 客户决策方 | 交付负责人
上游输入： 工作量评估详单 | PRD | 系统架构 | WBS | 任务拆解
下游输出： 报价单 | 合同附件 | 付款与验收口径
最后更新： 2026-03-29

1. 文档用途

明确本次首版开发工作量的范围、边界、阶段付款建议和验收建议。
将第三方服务、资质申请和实际资源消耗与开发服务费拆开，避免口径混淆。

2. 评估摘要

2.1 项目范围摘要

本次评估基于武汉单城首版上线目标。
首版同时覆盖“本地生活商城闭环”和“网约车派单闭环”两条主线。
统一司机账户，司机同时具备接单司机、分销商和商城消费者能力。
返现与返现券仅支持平台内循环，不支持提现。
技术范围为 Node.js + Stratix 主业务后端、Go 调度服务、乘客微信小程序、司机轻端微信小程序、司机重端 Android App、运营 Web 后台。

2.2 估算摘要

项目	工作量
开发总估算	`164 人天`
建议总工期	`约 9 周`
报价依据	开发工作量评估详单
第三方服务费用	不计入本次开发报价
云资源实际费用	不计入本次开发报价

2.3 商务填写区

项目	建议填写内容
综合人天单价	`____ 元 / 人天`
开发服务费小计	`____ 元`
商务折扣	`____ 元` 或 `____ %`
税率 / 税金	`____`
合同总价	`____ 元`

3. 本次工作量评估包含范围

3.1 交付端

乘客微信小程序
司机轻端微信小程序
司机重端 Android App
运营 Web 后台
gateway-api
platform-core
dispatch-engine

3.2 交付模块

工程基线与研发环境
统一账户与司机准入
商城、归因与商品中心
返佣、钱包与司机专区
出行订单与计价主链路
调度引擎 MVP
多端前端交互与后台联动
消息、工单、审计与风控基础支撑
联调、测试与上线准备

3.3 交付件

对应范围内的代码实现
数据库结构与基础脚本
已确认接口契约的落地实现
测试报告、上线检查清单、回滚预案
必要的交接说明和演示说明

4. 本次报价不包含范围

外部服务清单
已完成的需求调研、PRD、系统设计、OpenAPI 设计等文档工作量
第三方平台账号申请、资质办理、合同签约和预充值
微信支付、短信、地图、对象存储、CDN、云主机、数据库、Redis 等实际服务费用
Android 应用市场上架代办与相关费用
iOS 客户端开发
多城市运营能力
提现能力、清分到银行卡、对公结算等资金能力
高精度真实计价引擎、复杂动态调价和高级风控规则引擎
商家独立端、BI 深度经营分析平台

5. 付款节点建议

以下为建议口径，实际比例可按合同协商调整。

付款节点	建议比例	触发条件	建议说明
`P1` 合同生效与项目启动	30%	合同签署完成，项目启动会完成	用于锁定排期并投入实施
`P3` 双主链路联调完成	20%	`M2`、`M3` 达成，商城返佣链路和出行派单链路可联调	首版核心业务价值基本形成
`P4` 多端后台完成并进入 UAT	15%	`M4` 达成，多端主页面与后台功能完成	进入客户验收测试阶段
`P5` 上线验收完成	15%	`M5` 达成，完成上线准备并通过验收	可根据合同约定设置质保期条款

6. 验收节点建议

6.1 阶段验收节点

验收节点	对应里程碑	核心验收内容	主要证据
`A1` 基线验收	`M1`	工程基线、账户域、司机准入流程可演示	环境说明、接口联调记录、页面演示
`A2` 商城闭环验收	`M2`	扫码归因、商城下单、支付后返佣、司机专区消费可演示	测试单、台账记录、页面录屏
`A3` 出行闭环验收	`M3`	叫车、派单、接单、行程推进、完单支付可演示	调度日志、订单流转记录、录屏
`A4` 多端功能验收	`M4`	乘客端、司机轻端、司机重端、运营后台主功能联调通过	页面清单走查、缺陷关闭记录
`A5` 上线验收	`M5`	测试通过、上线清单齐备、回滚预案齐备	测试报告、上线检查表、验收单

6.2 验收原则

以当前已确认的需求和设计文档作为功能验收基线。
验收以“主流程可用、关键页面可走通、关键接口可联调、关键异常可处理”为主，不以视觉高定制为默认标准。
第三方外部服务若未按时准备，导致功能无法在真实环境验证，不计为研发未完成，应在验收备注中单列。

7. 变更控制规则

7.1 视为变更的典型情形

从武汉单城扩展到多城市
新增 iOS 司机端或乘客端原生 App
新增提现、银行卡结算、分账、对公结算
新增商家独立端、商家结算中心
新增高级 BI、复杂营销裂变、复杂风控规则引擎
对已确认页面、状态机、接口契约做大范围重构

7.2 变更处理建议

变更需求进入评审后，按新增人天、影响模块、对当前排期的影响三项重新评估。
建议在 2 个工作日 内给出影响说明和补充说明。
未经书面确认的新增需求，不纳入当前合同交付范围。

8. 外部依赖与客户配合项

8.1 启动前建议准备

微信小程序主体与 AppID
微信支付商户号
测试与生产环境域名
地图服务 Key
短信服务账号

8.2 上线前必须准备

HTTPS 证书与公网回调地址
云资源与基础环境
日志、监控、告警服务
Android 签名与发版渠道

8.3 说明

以上事项的申请、采购、充值和实际费用，不计入本次开发报价。
详细清单由内部运维文档单独维护。

9. 风险与前提

当前工作量评估以前期需求和设计已冻结为前提；若范围继续扩大，报价和工期需同步调整。
若客户不能按里程碑提供账号、资质、域名、支付、地图等外部条件，会直接影响联调和验收时间。
若首版要求提高到“高并发正式商用 + 多城市复制 + 完整风控合规”，应视为下一阶段项目，不建议压缩进当前首版。

10. 新增需求影响说明

新增需求：司机返现券支持通过微信或手机号转赠给其他司机。
影响范围：资金与券服务、司机轻端页面与消息触达、审计与回归测试。
建议口径：把它视为当前基线后的增量需求，单独补充报价与排期，而不是直接吞入原 164 人天 基线。
建议增量估算：+3.0 ~ +4.0 人天
资金与券模型、接口、审计：+2.0
司机轻端页面与消息联动：+0.5 ~ +1.0
回归测试与验收补充：+0.5 ~ +1.0
建议工期影响：如资源不变，预计新增 2 ~ 3 个工作日缓冲。

11. 推荐配套使用文档

12. 变更记录

日期	变更内容	变更人
2026-03-29	初始版本
2026-03-29	补充 `REQ-018` 券转赠需求的增量报价建议