核心要素1、背景（诞生痛点的原因，提出想法的前提）2、痛点（操作不便利、后继无法推广、一直在损失）3、期望（实现什么效果）
测试
6
9
3
避免口头需求需求背景不清，痛点不明 大概率驳回需求描述避免细节堆砌已排计划避免调整，紧急需求插入走邮件审批
研发&测试
评估项目计划更新《版本纪要》
4
PRD准备
驳回（需求不合理、不明确）
评审
研发
通过业务代表
当前项目计划提测时间前 须完成下一阶段的产品计划评审。评审机制：产品内部评审 -> 相关运营评审
7
2
冒烟
维护需求状态
10
1
需求反馈
每周一须完成上周的需求表清洗（可提前）通过：产品确认核心要素，并给出初定优先级。驳回：给出驳回原因
产品
需求设计
登记《业务需求表》
预警
冒烟 须明确 是否成功，不成功打回。注：后继测试须有测试用例进行支持
当前项目计划提测时间前 完成下一阶段prd内容，并上传文档共享工具。
8
发布
项目计划在需求池充裕情况下会尽量做到如下标准（按研发资源分）1、版本节奏：研发一版，测试一版，储备一版，计划一版。2、版本时效：a、项目版本时间从开发到上线在2周左右。b、优化版本时间从开发到上线在1周左右。
5
当前项目上线前3日 须周知预警。预警方式：邮件形式
方案评审
当前项目计划提测后第 2 或 3 日 完成下一阶段 的 研发评审。注：评审后3日 须有明确的提测、上线日期。
收录《好饭碗需求池》
同步反馈人
发布准备
当前项目 验收日期 组织相关人员进行验收。
需求处理流程
每周二 例会同步项目计划与单一项目流程邮件不冲突。
验收
需求清洗
当前项目培训文档须在上线前2日 周知，并视情况组织 相关人员进行培训。
反馈人
培训
业务代表
