一、需求汇总：

1.需求关注

PO、项目名称、优先级、产品内审时间

2.协作关注

（1）本月底，和业务负责人要到下个月阅读规划，确定需求评审时间

（2）提前沟通，push产品，避免突然给到需求、详评时间又很紧急的情况

（3）加入到业务线企业微信群，及时掌握需求动态

（4）和业务线负责人同步PO职责、需求评估标准和分配原则

（5）需求优先级评估标准

• 需求的价值点
• 详情时间

• 开发资源可以及时跟上吗

  常见问题

  （1）如果业务线都说自己优先级很高，需求很多，怎么办？

• 按照优先级往后排

  （2）我们分配后，业务线表示不OK，自己的需求被滞后？

• 和对方宣讲需求评估标准，让业务线之间自己沟通或pk

3.人员分配（业务PO关注）

项目名称、业务线、PO、设计状态、设计师、需求评审时间（谁先释放排给谁）、设计估时、开始时间和完成时间

4.需求评审

（1）提醒产品拉项目群
（2）关注影响设计估时的因素：是否拆迭代、产品需求是否完整
（3）怎么配合，设计稿要完成到什么程度

5.估时

（1）完成时间=开始时间+全力投入天数+其它日常投入时间+其它跟进验收投入时间（精确到0.5）

（2）估时原则

• 估时之前，产品需求一定要是清晰的
• 如果项目有迭代、周期太长，可以拆开计算

• 最好可以准确的说出哪些部分比较耗时，比如“新增了全新的交互”“页面数量多”…

  （3）如何填写

• 填写事实时间，不是预期时间

  （4）延期

• 完成时间标红，并备注原因

  （5）估时同步谁

• 发到项目群@PM和PO

• 只发设计开始和完成时间

• 进度（百分比和风险）是否同步，看需求情况

  6.设计评审

  （1）评审时间

• 设计完成后

  （2）评审人员

• 设计师、产品经理、设计师负责人、技术人员

  （3）评审流程

• 提前确定时间，通知参会人员

• 会前5分钟，介绍项目背景、主要流程和设计目标
• 串一遍交互主流程：使用角色-目标-场景
• 参会人员提问：能当场解决的就定方案，不能当场解决的记录并会后解决，一定要同步到相关人员
• 会议结束前review一边记录的问题

• 时间尽量控制在一小时

  （4）check list

• 产品

避免在评审中讨论产品问题及解决方案，建议提前在需求评审环节和设计环节去确定

• 交互

交互的可用性，会不会阻塞或给用户带来误导
交互的便捷性，能否提高操作效率

• 视觉

组件规范是否使用正确
是否与交互设计相符，不随意更改交互设计

7.技术详细评审

（1）评审时间

• 距离设计评审不超过3天（设计评审后的修改时间ok）

  （2）评审人员

• 产品是主要负责人，设计师建议参加，不强制不参加

  8.验收

  （1）验收时间

• 提测后验收，原则上验收不超过2天

  （2）验收原则

• 影响用户使用、产生歧义、大的视觉错误问题（P0），没有修改完，可以拒绝上线

• 开发坚持上线，要及时同步产品、业务负责人风险

  9.复盘

  （1）复盘时间

• 固定一个周期（每周/每月）

  （2）复盘内容

• 项目背景

• 好的原则和方法、走过的弯路和反思

二、日常全流程（小需求流程）

项目之后遗留的小的需求，通过日常流程来解决