H1启动会

  1. 目的
  1. 筛选出评审的内容
  1. 同步版本内容和粗排时间
  1. 筛选出风险项

针对风险项提前做计划

确定优先级和进版内容

  1. 形式

1.原因

2.方向

4.流程

1)现行版本筹备阶段流程不顺畅

2)筹备过程中的痛点

策划案的完善性和可落地性

GUI对程序估期和排期的影响

启动会数据和内容的准确性,版本后的可衡量性不足

1)策划

2)美术

3)程序

次数:2次

第一次

1)版本大方向宣导

第二次

1)同步版本内容和粗排数据

团队相信策划同学

2)同步版本开发内容的概念案

3)各部门Leader筛选

❓概念案需要达到什么样的程度

❓不同大小的功能是否有区分

筛选出评审案

不需要评审的会后直接进入粗估

进行评审

评审通过

进行粗估

不通过

重新评审

❓什么样的评审算不通过

a.概念案准备不合格

b.评审过后各Leader投票决定

❓重新评审的次数和时长如何控制

❓太多次或太长时间无法通过评审的案子如何处理

4)全部评审结束后,粗排数据给出

确定版本风险

确定版本内容

2)确定细案和宣讲时间

各部门对版本内容的确认

❓GUI和美术的宣讲时间是否会被推后,是否会影响美术的开发

❓细案是否能在版本开始前宣讲完毕

源头开始梳理

排期的卡点梳理

3)同步本次版本周期节奏

策划概念案准备

第一次启动会

评审

评审结束

第二次启动会

细案宣讲

各部门提供开发线预估量

辅助确定版本内容

开发排期

版本开发

4.理顺版本,承上启下

让版本开发更顺畅

总结回顾

❓参与评审的人的资质需要保障,参与开发的人员是否也需参加

如果不能保证权威性则会导致后期开发中依然会有问题

开发人员参与评审不参与投票,是否能缩短详细案的理解

增加各部门同学的参与感,提升团队的全面性

❓部门leader是否可以对有疑惑的设计案进行挑战,如何控制这个挑战的双方矛盾

预计持续4周(提前量-4)

上一版本开发开始后第一周前3天

上一版本开发后第一周内,最迟后两天

第一次启动会后,持续3周(上一版本开发开始后的第二,三,四周),该时间应该是可浮动的

最后一个评审结束后2-3天整理出第二次启动会的所需要的数据

评审数据出来后1-2天进行第二次启动会

第二次启动会结束后,最迟优化周开始细案宣讲,一周宣讲完成

宣讲完后2天排期同学给出详细人日消耗,PM与排期同学共同完成排期