H1启动会
- 目的
- 筛选出评审的内容
- 同步版本内容和粗排时间
- 筛选出风险项
针对风险项提前做计划
确定优先级和进版内容
- 形式
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与排期同学共同完成排期