2026-06-22 工作日志
项目周会（16:00 - 17:30）
会议讨论了一马当先试点情况、业务数据进展、技术开发进度、遗留问题解决、版本评审计划、散点需求及发版机制等事宜，并听取了市场反馈建议。
业务数据进展
试点与出货情况
- 一马当先试点中，核心费用网点占比达 68.4%，验点费用网点数量不到 60 万家，其中 50 万家费用网点已实现全部覆盖
- 统计 4 月至 6 月 14 日数据，整体出货率为 69%（按国家出货到门店计算），整体签收率为 67%，且签收率阶段性追踪平均水位维持该水平
- 窜货率环比上个月有部分下降
团购与鲜度盘点
- 团购累计出货量可查看相关数据
- 鲜度盘点正在进行 3 月份数据盘点，预计月底盘完
用户与督办单情况
- 上周整体用户数有提升，督办单数量从 68 个增加到 88 个，但整体错误率环比略微下降
- 扫码出货涉及 16 万个门店参与签收，目前数据未更新，宝谦统计完后会按上周格式将售卖基地、签收几率、整体分布等最新数据放到业务数据里
技术开发进度
版本集成测试
- 今日重点进行 6 月底版本的集成测试，先查看各端情况
- 活动中心原 6 月上线计划改为 7 月
- 前端开发进度正常
- 智慧门店正常推进推荐数据层面的盘点和性能相关技术方案，页面监控性能上周盘出批量接口，本周将输出技术方案，目标 7 月 2 号上线
神策埋点工作
- 赵丹负责的神策埋点部分，今天会用原型标注方式对前端从首页到任务中心、"我的"几个入口的一级菜单页面进行标注，并输出第一批范围的最终埋点方案的 PRD 文档
- 同时需将 7 月第一级页面埋点及下一阶段所有功能埋点的排期和里程碑更新上去
数据清理工作
- 考虑先由 SCI 与云商联合清理门店数据，再将明细发给各端，各端自行选择处理方案
- 今日开始对生产数据库做 UD 克隆，在生产环境完成表梳理和 SQL 性能验证后，准备在本周五前完成生产环境的数据清理和归档剥离
遗留问题解决
服务器资源问题
- 老的 SIP Windows 服务器降资源反映出底层云平台计算资源处于紧张临界点，新服务器 7 月中下旬才能就绪，本月若有资源控需求将无资源可划，建议云团队协调周转
- 上周三、周四销售团队中心的门店微服务程序 CPU 打满，30% 用户无法连接，周五关机做更新溯源和处理，问题是历史车舱数量大，涉及 500 万数据查询，前端页面报表导出动作打爆应用服务 CPU，已在程序层面修正并发出报告
遗留问题计划
- 计划在 6 月底版本上线后彻底解决遗留问题，先逐个系统进行信息同步，首先讨论营销活动中心
- 小娜麦有问题，需在 6 月底关闭之前的遗留问题
版本评审计划
730 版本规划
- SIV 账单扫码盘点及提交问题与签收链路优化里的盘点及签收、流向查证及签收有耦合逻辑，优化需求初步版本规划在 7 月 30 号版本
- 由于开发涉及各端联调时间问题，需反馈 730 版本中盘点及签收、流向查证及签收功能能否按时上线的风险
- 目前销售团队中心评估方案改动及三端联调需预留充分时间，要等技术方案评审通过、各端开发排期和测试联调时间确定后，才能给出最终上线时间
- 明确 730 指的是 7 月底版本，具体上线时间需根据各端评估结果确定，也有可能是 8 月初版本
PRD 评审安排
- 7 月底版本按规划里程碑，7 月 7 号完成 PRD 评审，明天内部对齐 PRD 方案
- 若研发判断工作量大，可将评审时间提前，6 月 22 号若明天做 PRD 内审，没必要拖到 7 月 7 号，应尽量提前给开发争取时间
- 盘点及提交、流向查证及签收、盘点及签收这三个场景前端改动量大，需找 Allen 和技术人员在今天与活动中心、SFA、小志和智慧门店端确定最终的 PRD 评审时间
6 月底版本评估
- 6 月底版本要解决之前识别到的产品技术、数据等大部分遗留问题，需站在这个角度评估智慧门店相关有无风险和延期情况
- 目前处于 PRD 阶段，明天参与中台第一波 PRD 评审，涉及扫码盘点及提交、流向查证及签收和盘点期签三个需求
散点需求沟通
补发与流量包问题
- 小娜的补发已完成，相关问题可关掉并自行重调
- 宝谦反馈高德流量包已开通，监控数据发现仍有个别失败情况，需再排查，可能不是流量包问题，确认是调用报错问题
- 今天已安排专人查看，上周江阳已申请额外流量包，若再有报错情况，拉高德技术一对一对接，建立参与和高德的沟通
主数据流向问题
- 业务反馈当天新增门店不能及时判断流向异常，原因是主数据从云商抓取新增门店为一小时一次，传输到活动中心存在时间间隔
- 上周梳理了 2026 年至今的码量并评估了影响，下一步与小拉对齐解决方案与排期
- 初步沟通的解决方案为两部分：一是无门店时主动组织查询，二是前端字段必填；"让主数据查询"的方案已被否决，采用前端必传字段的方式解决
- 今天会拉各端需求评审，因主要涉及 SFA，可能会跟随 SFA 版本，考虑放在 7 月底版本
发版机制讨论
发版时间与方式
- 6 月 25 号营销活动中心有裂控分组小优化，6 月底有报表注释需求上线，当前两个线上问题会随 630 版本解决
- 各端问题解决不与其他端关联，大版本（如 7 月 2 号、7 月 4 号、7 月底）跟着 SFA 各端一起交互走，其余时间各端根据之前定的排期正常上线解决自身问题
- 建议在短时间内合并解决问题，若问题解决不紧迫，不要频繁发布
评审安排与标准
- 625 和 630 按照 T 减 2 节奏进行评审，安排龚总负责，因 625 涉及需求、线上问题及历史数据处理
- 上周已确定 7 月 2 号大版本评审日程，7 月 1 号周三下午进行整体评审，各端在集中测试和运维测试后要及时补充文档，避免最后一天集中补文档
- 营销活动中心单独发版，让小娜安排日程并拉相关同学进行上线评审；7 月 2 号版本内容较多，无法按原计划 6 月 30 号做上线评审，较理想的时间是 7 月 1 号
- 龚总表示希望评审时相关中心人员能齐，若 7 月 1 号测试封板工作能完成则没问题，若检查出重大缺失，2 号上不了线可能要延期
- 提议梳理 625 版本内容作为例子，赵总建议吴老师为项目组制定发版评审标准，如涉及多少需求或需求加 bug 以上需要评审
- 日常小版本若采用 T 减 2 不现实，因 UAT 测试通常在前一天晚上完成且无问题，建议小娜拿出 6.5 版本整体范围，之后单独讨论
- 龚总表示各小组自行把控版本情况，确定 T 加 2、T 加 1、T 减 1 等时间安排；小 bug 解决没必要拉大家评审，建议各组自行判断，bug 不紧急时尽量合并发版，减少发版频次
市场反馈建议
- 尚总反馈上周在兰州拜访经销商，有经销商反映产品使用偶尔卡顿，建议建立收集问题、分析问题和反向反馈的机制
测试同步会
会议讨论了测试安排、问题分析、需求共识、资源协调及业务报表等相关工作事项。
测试安排与进展
- 今日测试涵盖银行互动中心和 SFA，不涉及小智和智慧门店，未参与测试人员不用在线
- 下午开展调拨、扫码加锁和出货产品状态校验测试，包括大宗 BC 日常出货及调拨单提交单据的产品状态校验
- 调拨测试 60 条，已测 26 条，通过 25 条；55 条用例测了 27 条，通过 26 条；合包上午完成，今日能完成合包测试
测试问题与分析
- 部分调拨测试未通过，原因是正常调拨数据无法到达验收入中心，可能是 DMS 与 TTS 数据不通，中间环节有缺失
- 状态校验部分标红，涉及已售和提外码已核销状态，8 条用例无法测试，调拨待签收场景也存在问题
- 针对箱码相关情况，待签收箱码是否存在及提交时是否校验存在不同观点，安排赵文查看并达成共识
- 今日下午有三个 bug 需确认，SIV 账号被挤掉、缓存问题安排张喜查看；界面展示问题开发已修改，改完复测
需求共识与修改
- 决定把小娜和德志叫上来，对提交校验、箱码校验等需求点达成共识
- 最初提供提交时校验和加锁两版方案，最终选择加锁方案，不加产品状态的校验
- 因测试发现问题，需同步修改 PRD 和测试用例，安排小娜 at 德志进行修改
- 提交时不做校验，但待签收、一键转移和一键退货应校验
资源协调与支持
- 明天「一键退货 + 出货单转移」进入集成阶段，目前资源有缺口，建议内部协调
- 赵文明天去展会，无其他测试工作；赵文已和梁岩同步，若资源不够，梁岩明天可参与测试，说话人明天下午也可参与
业务情况与报表
- 签收类有成功和失败数量反馈，出货类（包括调拨）出多少就是成功多少；一键转移和一键退货有相关展示，出货和调拨没有，签收和待签收相关的都有
- 最晚明天需将内容填进报表，提议每次把日报粘上，说话人会查看内容并发送给对方，之后给对方分配权限
- AI coding 由贾云飞负责，业务支撑可能涉及多人，包括战军
- 讨论了出货时不做提交的技术原因，询问表格具体内容的提供方
数据权限需求沟通会
会议讨论了营销活动中心的数据权限需求，明确了需获取扫码人及扫码门店的 5 段信息，并对不同人员类型的 5 段获取方式进行了细化。
小结
1. 数据权限需求
营销活动中心需获取扫码人 5 段及扫码门店 5 段，以实现按人和按店两个维度的数据权限管理。
2. 扫码人 5 段获取规则
- 内部人员（含伊利人）：获取其归属的云商区域 5 段
- 经销商人员：获取其所属经销商的 5 段
- 精工人员：其具体归属待定，需进一步明确
- 智慧门店人员：获取其门店的 5 段信息
3. 扫码门店 5 段获取规则
获取扫码时所选门店的 5 段。
待办
- 需进一步明确精工人员的 5 段获取方式 —— 余建新
- 需确认获取人员 5 段的具体数据来源和方法 —— 余建新