旅游网站全栈项目管理手册

一、项目全景规划

1.1 项目基本盘

1.2 技术选型决策依据

作为老板，技术选型不需要懂细节，但要清楚选型理由：

1.3 团队角色配置

一个四端并行的项目，最少需要这些角色：

最小团队规模：9-10 人。如果预算紧张，至少 6 人（砍掉 1 前端、合并 iOS/Android 用 Flutter/React Native——但客户要求原生，此路不通）。

1.4 沟通机制

二、需求与产品设计

2.1 需求收集与确认

项目启动后第一件事：把客户的需求写下来并让客户签字确认。

核心文档：

1. 需求清单（Excel / 在线表格）

2. 核心业务流程确认

老板要记住：不要等开发了一半才发现客户想要的和你理解的不一样。

必须跟客户对齐的核心流程：

• 找线路 → 看详情 → 下单 → 支付 → 出行 → 评价（主链路）
• 用户注册 → 登录 → 收藏 → 查看订单（用户侧）
• 供应商发布线路 → 后台审核 → 上架 → 订单管理（后台侧）

2.2 原型与设计稿评审流程

客户需求 → PM 输出 PRD → 设计师出原型 → 客户确认原型    → 设计师出视觉稿 → 客户确认视觉稿 → 开发切图

老板要卡死的原则：

• 原型没确认，不要进视觉设计——改原型的成本是改设计稿的 1/10
• 视觉稿没确认，不要进开发——改视觉稿的成本是改代码的 1/5
• 客户口头说的"差不多"不算确认，邮件/签字确认才算
• 如果客户频繁改需求，记录变更次数，超出范围走商务流程加钱

2.3 多端设计规范

四端共用品牌识别系统，但适配各自平台特性：

三、架构设计

3.1 整体架构图

┌──────────────────────────────────────────────────┐│                    用户层                         ││    PC 网站     H5 手机站     小程序     App       ││   (Vue 3)     (Vue 3)      (UniApp)   (原生)    │└────────────────────┬─────────────────────────────┘                     │ HTTPS┌────────────────────▼─────────────────────────────┐│                API 网关 / Nginx                    ││              统一入口、限流、鉴权                   │└────────────────────┬─────────────────────────────┘                     │┌────────────────────▼─────────────────────────────┐│              PHP 后端 API 层                       ││        Restful API / JWT 鉴权 / 统一返回格式       ││                                                   ││     ┌──────────┐ ┌──────────┐ ┌──────────┐      ││     │ 用户模块  │ │ 线路模块  │ │ 订单模块  │      ││     └──────────┘ └──────────┘ └──────────┘      ││     ┌──────────┐ ┌──────────┐ ┌──────────┐      ││     │ 支付模块  │ │ 评论模块  │ │ 后台管理  │      ││     └──────────┘ └──────────┘ └──────────┘      │└────────────────────┬─────────────────────────────┘                     │┌────────────────────▼─────────────────────────────┐│               MySQL 数据库                         ││        线路表 / 用户表 / 订单表 / 评论表           │└──────────────────────────────────────────────────┘┌────────────────────┬─────────────────────────────┐│               Redis 缓存                           ││        会话管理 / 热门线路缓存 / 接口限流           │└──────────────────────────────────────────────────┘

3.2 四端共用后端 API

这是本项目的核心架构决策：四端共用一套 API。

API 设计原则：- 统一域名：https://api.xxx.com- 统一格式：{ code: 200, message: "success", data: {} }- 统一鉴权：JWT Token- 统一分页：{ page, pageSize, total, list[] }- 版本管理：/api/v1/xxx

各端差异点（老板需要知道这些地方容易出问题）：

3.3 数据库设计策略

作为老板，不需要看懂每张表，但要确认几点：

• 表名规范统一：全小写+下划线（travel_route、user_order）
• 统一主键：全部用 id 自增主键
• 必要通用字段：每张表有 created_at、updated_at
• 软删除设计：订单、用户等敏感数据不要物理删除，加 status 或 deleted_at
• 索引策略：高频查询字段（用户ID、订单号、线路ID）必须建索引
• 避免过度设计：先满足当前需求，不要为了"以后可能用"建一堆字段

3.4 目录结构约定

# 后端目录结构（PHP）/project-backend  /app    /Controllers    # 控制器    /Models         # 数据模型    /Services       # 业务逻辑层    /Middleware     # 中间件（鉴权、日志）  /config           # 配置文件  /database    /migrations     # 数据库迁移脚本  /routes           # 路由定义  /storage          # 上传文件# PC / H5 前端目录结构（Vue）/project-frontend  /src    /api            # API 接口封装    /assets         # 静态资源    /components     # 公共组件    /views      /pc           # PC 端页面      /mobile       # H5 端页面    /router         # 路由    /store          # 状态管理（Pinia）    /utils          # 工具函数  /public           # 公共资源# 小程序目录结构/project-miniapp  /pages            # 页面  /components       # 组件  /api              # API 封装  /utils            # 工具函数

四、团队分工与排期

4.1 并行开发策略

四端并行的核心思路：后端先行，前端并行，接口驱动。

第 1-2 周     第 3-6 周       第 7-10 周      第 11-14 周需求确认 ──→ 后端 API 开发 ──→ 各端联调 ──→ 测试验收             PC 前端开发 ──→ 联调 ──→ 测试             H5 前端开发 ──→ 联调 ──→ 测试             小程序开发 ──→ 联调 ──→ 测试             App 开发 ──→ 联调 ──→ 测试

关键依赖关系：

4.2 里程碑设定

4.3 排期避坑指南

老板最容易犯的排期错误：

错误 1：低估接口联调时间

• 接口联调不是"后端写完了前端直接对接"那么简单
• 字段不一致、返回格式不对、异常情况没考虑——联调至少占总工期的 25%
• 对策：后端出 API 文档、前端用 Mock 数据并行开发，最后留足联调时间

错误 2：前端设计没有提前做适配

• PC 端一套样式，H5 一套样式，小程序还有自定义组件
• 如果 UI 只出了 PC 端设计稿，H5 和 App 让开发"自由发挥"，结果各端长得不一样
• 对策：设计稿一定覆盖 PC + H5 + 关键 App 页面，至少核心页面的适配要标清楚

错误 3：忽略非功能性需求的时间

• 支付对接、短信服务、第三方登录、数据迁移……这些非"页面功能"的活儿往往被忽略
• 对策：排期时单独列一个"集成与配置"任务清单

4.4 典型排期模板

以 14 周（约 3.5 个月）为例：

五、协作规范

5.1 Git 分支策略

main (生产分支)  └── develop (开发主分支)       ├── feature/backend-user     (后端用户模块)       ├── feature/backend-route    (后端线路模块)       ├── feature/frontend-pc      (PC 前端)       ├── feature/frontend-h5      (H5 前端)       ├── feature/miniapp          (小程序)       ├── feature/app-ios          (iOS)       └── feature/app-android      (Android)

规则：

• 每个功能模块一个 feature/xxx 分支
• 开发完成后合并到 develop 分支联调
• develop 测试稳定后合并到 main 发布
• 紧急 Bug 从 main 拉 hotfix/xxx 分支修复

5.2 API 协作规范

这是四端项目最容易踩坑的地方。必须从第一天就定好：

1. API 接口文档先行

后端在写任何代码之前，先输出 API 文档（用 Swagger / ApiPost / Postman / Markdown 都行）。

2. 统一返回格式

// 成功{ "code": 200, "message": "success", "data": { ... } }// 失败{ "code": 40001, "message": "参数错误：手机号格式不正确", "data": null }// 分页{ "code": 200, "message": "success", "data": { "list": [], "page": 1, "pageSize": 20, "total": 100 } }

3. 各端用 Mock 数据并行开发

API 文档出来后，各端用 Mock 工具模拟数据，不等待后端写完：

4. API 变更通知机制

API 变更（新增字段、修改字段名、删除接口）必须通知所有端负责人：

• 在项目群发通知 @所有人
• 更新 API 文档版本号
• 变更保留旧字段一段时间的兼容期

5.3 各端之间常见问题

5.4 需求变更管理

项目过程中客户一定会改需求。作为老板，需要一套流程来控制：

客户提出变更    ↓PM 评估影响范围（涉及哪些端、改动量、排期影响）    ↓通知客户变更成本（额外工时 + 延期时间）    ↓客户决策：  ├─ 接受成本 → 走变更流程，调整排期  └─ 不接受 → 推迟到二期    ↓更新需求文档和排期

铁律：

• 小变更（半天内能改的）：记下来，统一到下次迭代做
• 大变更（超过 2 天）：走正式变更流程，跟客户讲清楚影响
• 变更是常态，项目经理每周跟客户同步一次，不要等开发完了才让客户看

六、质量保障

6.1 测试环境

6.2 各端测试策略

6.3 核心测试用例（老板要关注的）

以下测试场景出了问题，直接影响到客户体验和收入：

【支付流程】（优先级最高）  1. 微信支付正常流程：下单→支付→回调→订单状态更新  2. 支付宝正常流程  3. 支付成功但回调失败（人工对账机制）  4. 支付取消/退回  5. 重复支付处理【用户注册登录】  1. 手机号注册 + 验证码  2. 微信授权登录（小程序/App）  3. Token 过期自动刷新  4. 多端登录同一账号【核心业务流程】  1. 搜索线路 → 查看详情 → 下单 → 支付 → 出行  2. 线路库存管理：多人同时下单同一线路  3. 订单取消 / 退款流程

6.4 Bug 管理

推荐用在线项目管理工具（Trello / Tapd / Jira / 飞书项目）：

Bug 提交流程：测试发现 Bug → 提交 Bug 单（优先级 + 截图 + 复现步骤）  → PM 指派给对应开发者 → 开发者修复 → 测试验证关闭Bug 优先级：- P0（紧急）：主流程走不通、支付失败、数据丢失 → 立即停止其他工作修复- P1（高）：功能不能正常使用、核心页面布局错乱 → 当天修复- P2（中）：次要功能异常、非核心页面样式问题 → 本迭代修复- P3（低）：文字错误、样式微调 → 下个迭代修复

七、部署与发布

7.1 发布顺序策略

不能所有端同一天上线。正确的发布顺序：

第一天：后端 API 上线（确保服务稳定）第二天：PC 端上线（发现问题影响最小）第三天：H5 端上线（和 PC 共用部分逻辑）第四天：小程序提审（审核需要 1-3 天）       ├─ 审核通过 → 小程序发布       └─ 审核失败 → 修改重新提交第五天：       ├─ iOS 提审（App Store 审核 1-3 天）       └─ Android 各商店发布（部分商店无需审核）

每个端上线后观察至少半天，确认无异常再继续发下一个端。

7.2 上线 Checklist

上线前，项目经理逐项确认：

□ 核心流程已测试通过（浏览→下单→支付→退款）□ 各端 API 已切换为生产环境地址□ 微信支付/支付宝商户号已配置□ 短信验证码服务已开通□ 域名已备案，SSL 证书已配置□ 数据库备份策略已配置（每日自动备份）□ 服务器监控已配置（CPU、内存、磁盘告警）□ 错误日志收集已配置□ 数据埋点已部署□ 客户已确认验收□ 上线后回滚方案已准备□ 客服/运营已接受到岗通知

7.3 回滚方案

老板必须问团队的问题："上线出问题了怎么办？"

八、项目复盘与运维

8.1 数据埋点

作为老板，你需要关注的数据：

用户行为：

• 各端访问量（PC vs H5 vs 小程序 vs App）
• 线路浏览量、搜索关键词 Top 10
• 下单转化率（从浏览到支付成功的每一步流失率）
• 各端支付转化率对比

业务数据：

• 每日订单量、GMV
• 退款率、取消率
• 热门线路排名
• 用户注册量、活跃度

技术指标：

• API 响应时间（P50/P95/P99）
• 服务器 CPU、内存、磁盘使用率
• 错误率、慢查询数

8.2 问题响应机制

线上问题处理流程：用户/客服反馈问题    ↓PM 判断问题等级    ↓P0/P1 → 拉群（项目经理 + 相关开发 + 测试）→ 紧急修复P2/P3 → 记入 Bug 池 → 下个迭代处理    ↓修复后 → 写事故报告（原因、影响范围、改进措施）    ↓更新测试用例，避免同类问题再次出现

8.3 版本迭代节奏

上线后不代表项目结束。后续建议的迭代节奏：

8.4 项目复盘

每个项目结束后，组织复盘会：

复盘提纲：

1. 项目结果   - 是否按时上线？延期了多久？   - 预算是否超支？超了多少？   - 交付质量如何？线上 Bug 数量？2. 做对了什么（下个项目继续）   - 哪个流程特别顺利？   - 哪个工具或实践有效？3. 做错了什么（下个项目改进）   - 哪里预估不足？   - 哪个环节反复返工？   - 团队沟通出了什么问题？4. 改进措施   - 流程上需要改什么？   - 工具上需要升级什么？   - 团队能力上需要补充什么？

九、风险控制（老板最该关注的）

9.1 常见风险点

9.2 老板必须亲自过问的 5 个问题

在每个关键节点，作为老板问自己这几个问题：

项目启动时：

1. ❓ 客户的核心需求我是否真的理解清楚了？—— 找客户当面过一遍主流程
2. ❓ 团队的人够不够、能力是否匹配？—— 缺人赶紧招，不要等项目开始了才补人

开发中期： 3. ❓ 目前的进度是否跟计划一致？—— 看燃尽图，如果偏差超过 20% 就要干预 4. ❓ 有没有什么风险被忽略了？—— 找项目经理聊，不要只看周报

上线前： 5. ❓ 出了大问题我知道怎么回滚吗？—— 问团队，让他们演示一遍回滚操作

附：老板速查清单

项目关键时间节点

□ 第 1 天：组建团队、申请域名/服务器/商户号□ 第 1 周：需求确认、原型设计启动□ 第 2 周：技术方案评审、数据库设计完成□ 第 3 周：后端开始写 API、各端页面开发启动□ 第 6 周：API 就绪，各端开始联调□ 第 10 周：联调完成，进入测试□ 第 13 周：测试完成，准备上线□ 第 14 周：上线

每周必问项目经理的 3 个问题

1. 进度跟计划有没有偏差？
2. 这周有没有遇到什么风险？
3. 客户那边有没有新的需求或反馈？

上线前必查的 5 件事

□ 支付流程在 PC / H5 / 小程序 / App 各端都测试通过了？□ 数据库有自动备份吗？□ 线上出问题知道怎么回滚吗？□ 客服/运营知道上线后怎么处理用户反馈吗？□ 客户签字确认验收了？

总结

管好一个四端并行的旅游网站项目，核心就三句话：

1. 后端先行，文档驱动——一个后端 API 喂四端，文档就是各端的契约。没有 API 文档就不要开始联调。
2. 并行不悖，联调留足——各端可以并行开发，但联调的时间不能被压缩。联调至少占总工期的 25%。
3. 流程控变，风险预防——需求变更要走流程，关键风险要提前识别。老板的职责不是写代码，是确保项目在正确的轨道上。

老板不需要懂每一行代码，但要知道：

• 谁在做什么、做到哪了、有没有风险
• 核心流程能不能跑通、上线出问题怎么处理
• 客户满不满意、钱能不能收到