保利拍卖APP升级项目工作机制与推进流程 v1.0

一、文档目标

本文件用于明确保利拍卖APP升级项目从“需求提出”到“评审确认、研发开发、测试验收、上线发布、上线复盘”的完整协作机制，减少反复沟通和口径不一致，保证保利团队、产品团队、研发团队、设计运营团队在同一套规则下推进。

本流程适用于以下范围：

• iOS端
• Android端
• 微信小程序端
• 服务端接口与后台配置
• 埋点、数据看板、运营素材与前端展示规范

二、总体原则

三、角色与职责

四、推荐沟通机制

1. 是否都要邮件沟通

不建议所有事情都通过邮件沟通。邮件适合正式结论和对外确认，不适合高频细节讨论。

推荐口径：

• 项目群负责快速沟通；
• 需求池负责记录需求事实；
• 会议纪要负责记录评审过程和结论；
• 邮件负责确认正式版本范围、排期、上线和重大变更；
• 研发任务系统负责开发执行。

五、需求从提出到进入开发的流程

阶段1：需求收集

需求来源包括：

• 保利团队业务诉求；
• 实际使用问题；
• APP截图和体验记录；
• 用户评论、客服反馈、应用商店反馈；
• 研发或测试发现的问题；
• 运营素材配置问题；
• 埋点和上线复盘发现的问题。

处理方式：

1. 需求提出人提交需求描述、截图、页面路径、发生端、期望结果。
2. 产品负责人判断是否为新需求、已有需求补充、缺陷、运营规范问题或埋点问题。
3. 统一写入需求池，分配需求ID。
4. 暂不明确的需求标记为“需补资料”。

阶段2：产品初筛

产品负责人先做初筛，不建议把所有零散需求直接发给研发开发。

初筛内容：

• 是否属于本项目范围；
• 是否已有重复需求；
• 是否影响核心交易链路；
• 是否需要保利补充业务规则；
• 是否需要设计稿；
• 是否需要研发预估；
• 是否需要埋点或后台能力；
• 优先级初判：P0 / P1 / P2；
• 版本建议：V1 / V2 / 待定。

初筛后输出：

• 需求池更新版；
• 待保利确认清单；
• 待研发评估清单；
• 待设计确认清单；
• 待运营补素材或规则清单。

阶段3：需求分发

不建议一开始把所有未整理的需求直接一起发给所有人。建议按阶段分发：

推荐顺序：

1. 先由产品负责人内部整理需求池；
2. 发给保利业务团队确认业务规则和优先级；
3. 同步给研发负责人做初步技术评估；
4. 对需要设计和运营规范的需求，同步给设计和运营；
5. 形成评审版后，再组织多方评审会。

六、需求评审机制

1. 评审前准备

评审前至少提前1个工作日发出：

• 需求池评审版；
• 评审说明；
• 截图索引；
• 运营素材与前端展示规范；
• 埋点方案与事件清单；
• 本次重点讨论清单。

2. 评审会参加人

建议参加人：

• 保利业务负责人；
• 产品/项目负责人；
• 研发负责人；
• iOS、Android、微信小程序、服务端代表；
• 设计负责人；
• 运营负责人；
• 测试负责人；
• 数据/埋点负责人。

不是每次会议都需要所有人参加。若是专项评审，可只邀请相关角色。

3. 评审顺序

第一轮不要从需求1逐条评到需求60，建议按优先级和链路评审：

1. P0交易链路：登录、实名认证、号牌、保证金、出价、支付；
2. P1核心体验：首页、拍卖列表、拍品详情、搜索、提醒、直播；
3. 运营素材与前端展示规范；
4. 埋点与数据复盘；
5. P2长期优化。

4. 每条需求的评审结论

每条需求必须落到以下结论之一：

5. 评审后输出

评审后1个工作日内应输出：

• 更新后的需求池版本；
• 会议纪要；
• V1范围清单；
• 待补资料清单；
• 待研发评估清单；
• 风险与依赖清单。

七、研发评估与任务拆分流程

1. 研发评估内容

研发负责人组织各端评估：

• iOS端改造范围；
• Android端改造范围；
• 微信小程序端改造范围；
• 服务端接口和后台配置；
• 数据库或业务状态调整；
• 埋点SDK和事件上报；
• 设计稿依赖；
• 测试环境和联调环境；
• 风险点和预计工期。

2. 研发任务拆分

需求池中的“进入V1”需求进入研发任务系统，建议拆成：

• 客户端任务；
• 小程序任务；
• 服务端任务；
• 后台配置任务；
• 埋点任务；
• 测试任务；
• 设计走查任务；
• 上线配置任务。

每个研发任务至少包含：

• 对应需求ID；
• 任务标题；
• 负责人；
• 端范围；
• 开始时间和预计完成时间；
• 依赖项；
• 验收标准；
• 测试环境；
• 当前状态。

3. 需求池与研发任务系统的关系

需求池不是研发任务系统。推荐关系如下：

八、开发过程跟进机制

1. 周期性同步

建议节奏：

2. 跟进看板字段

建议研发任务系统或协作表中至少有以下状态：

• 待评估；
• 待设计；
• 待开发；
• 开发中；
• 待联调；
• 测试中；
• 待验收；
• 待上线；
• 已上线；
• 暂缓；
• 关闭。

3. 风险和变更管理

开发过程中出现以下情况，必须回到需求池和会议纪要中记录：

• 需求范围扩大；
• 技术方案变化；
• 工期变化；
• 端范围变化；
• 业务规则变化；
• 保利临时新增高优先级需求；
• 测试发现影响上线的P0/P1缺陷；
• 埋点或数据口径变化。

九、设计、运营、埋点的专项流程

1. 设计流程

1. 产品明确页面流程和状态；
2. 设计输出交互和视觉稿；
3. 保利确认品牌和业务表达；
4. 研发确认组件可实现性；
5. 测试根据设计稿补充验收点；
6. 开发完成后设计走查。

2. 运营素材流程

1. 产品和运营确认信息承载方式：图片承载还是系统承载；
2. 运营按规范制作Banner、列表图、内容封面；
3. 上线前检查安全区、Logo、标题日期、文字对比度；
4. 需要后台配置的素材，先在测试环境预览；
5. 发现遮挡、重复标题、浅色冲突时，不直接上线。

3. 埋点流程

1. 产品确认事件清单和字段字典；
2. 研发确认SDK和接入方式；
3. 各端按统一事件名实现；
4. 服务端补传登录、认证、保证金、出价等关键结果；
5. 测试环境逐条验收事件；
6. 上线后检查数据量级和漏斗是否正常。

十、测试验收流程

1. 测试准备

测试团队根据需求池和研发任务准备：

• 功能测试用例；
• 端兼容测试；
• 异常场景测试；
• 弱网和网络切换测试；
• 支付、保证金、出价等关键链路测试；
• 埋点验收用例；
• 运营素材展示检查清单。

2. 测试分级

3. 验收通过标准

上线前需要满足：

• V1需求均有验收结论；
• P0缺陷全部关闭；
• P1缺陷有处理结论；
• 核心链路测试通过；
• iOS、Android、微信小程序关键路径通过；
• 埋点P0事件通过验收；
• 运营素材展示通过检查；
• 上线和回滚方案确认。

十一、上线发布流程

1. 上线前准备

上线前需要准备：

• 发布范围清单；
• 已完成需求清单；
• 未完成/延期需求清单；
• 缺陷遗留清单；
• 测试报告；
• 埋点验收报告；
• 运营素材检查结果；
• 上线窗口；
• 回滚方案；
• 上线后监控指标。

2. 上线审批

建议上线前组织一次发布评审，确认：

• 是否符合上线条件；
• 是否有阻断缺陷；
• 是否需要灰度发布；
• 是否需要保利确认上线时间；
• App Store、安卓渠道、小程序审核时间是否影响节奏；
• 是否有运营活动或拍卖日程冲突。

3. 发布顺序

建议按以下顺序规划：

1. 服务端和后台能力先上线或灰度；
2. 微信小程序按审核节奏提交；
3. Android按渠道发布计划提交；
4. iOS提交App Store审核；
5. 运营配置和素材在确认后上线；
6. 数据看板在上线当天开始监控。

具体顺序需以研发架构和发布策略为准。

4. 上线后观察

上线后至少观察：

• 启动、崩溃、接口错误；
• 登录成功率；
• 实名认证成功率；
• 号牌办理成功率；
• 保证金支付成功率；
• 出价成功率；
• 首页Banner和直播点击播放情况；
• 用户反馈和客服咨询；
• 运营素材展示是否异常。

十二、上线复盘流程

建议上线后一周内做复盘。

复盘内容包括：

• 本期上线了哪些需求；
• 哪些延期，原因是什么；
• 核心指标变化；
• 用户反馈变化；
• 缺陷数量和严重级；
• 研发、测试、运营协作问题；
• 下一版本建议。

复盘输出：

• 版本复盘报告；
• 下一版需求池；
• 遗留问题清单；
• 数据看板截图或指标摘要；
• 流程改进建议。

十三、容易遗漏但建议提前考虑的事项

十四、推荐固定交付物清单

每个版本建议固定保留以下交付物：

十五、建议的项目节奏

具体日期应根据研发排期、审核周期和保利拍卖活动窗口调整。