Q1:海外是否有货
每周五收集
定义：影响海外用户使用的问题、客户直接的客诉提报和响应：每日及时响应，并同步进度优先级定义：BUG分等级进行提报P0致命级：系统崩溃、无法启动、核心功能完全不可用、WIFI数据丢失安全漏洞，大规模连接问题需立即修复 。P1严重级：主要功能失效但系统能运行，用户需绕过缺陷才能操作，如休眠指令下发失败、关键数据错误 。P2中等/主要级：次要功能异常但不影响主流程，有临时解决方案可绕过 。P3轻微级/微小级：界面错位、错别字、颜色不统一等不影响使用的细节问题 。BUG归属（每周更新一次）未定义BUG：目前未明确是软件/硬件/前端/后端的问题前端BUG、后端BUG、APPBUG、软件BUG、设备BUG、硬件BUG、协同BUG、设计方案BUG
文档核心阐述APP开发团队的团队合作方式，有合作需求的请认真阅读。项目的响应周期（什么时候体需求，什么时候给反馈），由需求分类进行决定项目的资源投入（哪些项目优先开始，哪些后面开始），由优先级的定义决定。
否
按照频次响应，基于优先级判断和工作安排，看需求池哪些事项进入任务池
需求文档
测试联调
每月倒数第三天收集
大规模需求BUG?
支线业务流
需求存在紧急程度、响应周期、资源分配上的不同，下述标准进行需求大类的分类，请大家遵守此方式进行提报和各种大类进行工作的对接。
定义：优化用户体验，可能影响产品使用但不会造成大面积直接的客诉提报和响应：每周五集中收集需求，每周跟进进度并安排排期。按照需求进行开发，若开发过程中出现较大范围的需求变更或新增工作量，需重新提报，并结合当周实际资源重新评估排期优先级定义：默认按照提报的时间进行排序，当遇到资源冲突时，则按照以下维度依次排序：1、用户影响范围与体验痛点严重程度 2、对产品核心指标的预期贡献 3、需求的完备度与清晰度P0：涉及核心体验路径的优化，可显著提升高频用户满意度或关键转化指标，且需求明确、收益可衡量。P1：针对高频但非阻断性功能的易用性提升，或具备明确业务价值的局部优化。P2：界面微调、提示文案优化等长尾体验细节，或需求中存在较多未明确点、暂不具备实施条件的优化。
主线业务流
一、核心内容简化版提炼我们是怎么管理需求和分配资源的
项目管理
评审通过？
BUG提报
测试工程师
提拔需求
定义：未出货新品设备开发优化、在售产品物联网化适配提报和响应：产品/研发同事可以任意时间提报。接受需求时间为每月倒数第三个工作日下班，逾期不接收。按照需求进行开发，若中间存在大批量的新增工作量不在原本需求的范畴，则需要重新提报新需求，结合当月实际工作量进行排期的权衡。优先级定义：默认按照提报的时间进行排序，当遇到资源冲突时。则按照产品的下属维度进行重新排序1、影响面损失 2、排货时间 3、单品货值P0：首批出货资金，已经相关产品的影响面P1：有明确的海运时间，会影响既定船期P2：需求的明确程度，若需求中很有很多暂未明确的点，则不会优先进行开展
07/08 修复 Bug
功能开发
01 待出方案→02 待评审
BUG修复
前端/后端工程师
评审环节
需求池
简化版的判断方式
10 需求完成
【特殊事项】在任务排期外，不能提前计划的工作事项，自上而下的决策。且需要协调其余任务优先级调整的事项
交付物
需求提报
是
环节负责人
开发环节
需求环节
开发中出现大量新增工作量
设备开发
我们是怎么开展工作的APP团队如何开展工作（事项进行哪个环节，出具什么交付物，该环节的第一责任人）APP出于版本迭代管理，则会在每月第一个工作日进行APP版本的更新，特殊事项走特殊事项流程
每日及时响应
09需求方案重构
测试报告
【团队项目】仅在APP的周报中同步部分与APP工作事项。以便大家能知道具体的项目周期
环节
00 需求池定义：需求已由产品、研发或相关同事提交至需求池，等待产品负责人进行初筛和接收。责任人：产品经理（或需求管理员）主要动作：检查需求描述是否清晰、完整，至少包含：背景、目标、期望效果、影响范围。初步判断属于“设备开发/功能开发/BUG”中的哪一类，以便后续匹配响应节奏（BUG每日响应，其余按固定窗口收集）。对信息严重缺失的需求，打回并说明需要补充的内容。退出标准：需求已被确认接收，分配需求编号，流转至“01待出方案”；或明确打回关闭。01 待出方案定义：需求已被接收，等待对应技术负责人输出可行的技术实现方案。责任人：研发负责人（或指定开发工程师）、架构师主要动作：评估是否涉及APP端、固件端、硬件端、云端等多端改动。撰写技术方案，内容包含：实现方式、影响模块、接口定义、工时预估、潜在风险、对现有功能的影响。若涉及跨团队协作，需在方案中明确依赖与接口人。输出物：技术方案文档（可简可详，但至少要写在需求卡片备注中）。退出标准：方案完成，挂载至需求下，流转至“02待评审”。02 待评审定义：技术方案已完成，等待产品、研发、测试等核心角色进行联合评审。责任人：产品经理发起，研发、测试、相关干系人参与主要动作：评审方案是否能满足需求，是否有体验或技术上的遗漏。确认工作量、排期预估是否合理。明确验收标准（功能表现、兼容性、异常处理等）。评审通过后，按照全局优先级（P0-P3）确定是否进入当前迭代及排期顺序。退出标准：评审通过，验收标准明确，需求状态更新为“03待开发”；评审不通过则打回“01待出方案”修改或关闭。03 待开发定义：需求已通过评审，明确排入某个迭代，但开发工作尚未正式启动。责任人：研发经理 / 技术负责人主要动作：将需求分配给具体的开发工程师，确认没有资源冲突。若资源紧张，根据全局优先级（P0>P1>P2>P3）及时间刚性排序拉取需求，紧急事项随时插队。开发人员确认可以启动时，自行将状态变更为“04正在开发”。退出标准：开发人员正式认领，并开始编码/设计，状态变更为“04正在开发”。04 正在开发定义：开发工程师正在进行实际的编码、固件编写、硬件调试、联调等工作。责任人：开发工程师主要动作：按照技术方案和验收标准进行开发与自测。APP与软硬件之间有依赖时，主动对齐联调时间。开发过程中若出现范围蔓延或大量新增工作量，触发变更机制：暂停当前需求，重新评估并可能回退至“00需求待接收”提报新需求。开发自测通过后，根据改动类型分别提测：纯APP改动 → 流转至“05 APP待测”涉及固件/硬件/软硬件协同改动 → 流转至“06 软硬件待测”若两者均涉及，可同时提测，但需分别跟踪。退出标准：开发完成，代码合入对应分支，提供自测报告/提测说明，需求流转至对应待测状态。05 APP待测定义：APP端改动已提交，等待测试工程师进行功能、兼容性、回归测试。责任人：测试工程师主要动作：根据验收标准编写/更新测试用例，执行测试。发现缺陷时，判断是APP端问题还是软硬件协同问题：明确为APP自身bug → 直接标记为APP缺陷，流转至“08 测试修APP bug”怀疑与软硬件相关 → 与软硬件测试协同确认，必要时关联至软硬件bug测试通过且无遗留致命/严重bug，则流转至“09 需求完成”。退出标准：所有APP侧用例通过，或无未关闭的P0/P1级APP缺陷。06 软硬件待测定义：设备固件、硬件或软硬件联调改动已完成，等待进行软硬件集成测试或硬件专项测试。责任人：测试工程师（可能含硬件测试、射频测试等专岗）主要动作：搭建测试环境，执行功能测试、稳定性测试、兼容性测试等。发现缺陷后，定位至软硬件bug或APP协同bug，记录并流转至“07 测试修软硬件bug中”。若需APP配合验证，协同APP测试人员。测试通过后流转至“09 需求完成”（若同时有APP测试，则需二者都通过）。退出标准：所有软硬件侧用例通过，无未关闭的P0/P1级软硬件缺陷。07 测试修软硬件bug中定义：软硬件测试阶段发现了缺陷，研发工程师正在修复固件、硬件或相关底层问题。责任人：相关开发工程师（固件/硬件/嵌入式等）主要动作：认领属于自己模块的bug，进行修复。修复完成后，重新编译版本/提供修复后的硬件，再次转入“06 软硬件待测”进行回归验证。此状态与“06 软硬件待测”可能形成循环，直到所有问题关闭。退出标准：所有软硬件侧缺陷修复并自测通过，需求重新进入“06 软硬件待测”。08 测试修APPbug定义：APP测试阶段发现了缺陷，研发工程师正在修复APP端问题。责任人：APP开发工程师主要动作：认领APP缺陷，修复并自测。修复后重新打包版本，流转回“05 APP待测”进行回归。与软硬件协同的bug，需同步知会相关同事。退出标准：所有APP侧缺陷修复并自测通过，需求重新进入“05 APP待测”。09 需求完成定义：所有测试均验证通过，需求达到可交付或可发布状态。责任人：产品经理最终验收主要动作：测试工程师出具测试报告，确认无遗留问题。产品经理从用户体验/业务角度验收，确认满足评审时的验收标准。关闭需求，根据发布节奏整合进入版本发布计划。退出标准：需求关闭，必要时同步更新知识库或用户手册。
三、我们是怎么开展工作的目前的工作开展主要分为以下十个业务环节
特殊事项走特殊开发事项申请。
00需求池
03 待开发→04 正在开发
需求负责人
验收发现 Bug？
二、我们是怎么管理需求和分配资源的
05/06 测试阶段
tips没有和设备有任何挂钩可以不看Q1特殊事项，请走邮件报备处理
安装包
提报必看清单
