Please enable JavaScript.
Coggle requires JavaScript to display documents.
H1启动会 (目的 (筛选出风险项 (针对风险项提前做计划, 确定优先级和进版内容), 4.理顺版本，承上启下 (让版本开发更顺畅),…
H1启动会
目的
筛选出评审的内容
同步版本内容和粗排时间
筛选出风险项
针对风险项提前做计划
确定优先级和进版内容
4.理顺版本，承上启下
让版本开发更顺畅
形式
次数：2次
预计持续4周（提前量-4）
第一次
1）版本大方向宣导
团队相信策划同学
2）同步版本开发内容的概念案
:question:概念案需要达到什么样的程度
:question:不同大小的功能是否有区分
3）各部门Leader筛选
筛选出评审案
进行评审
评审通过
进行粗估
不通过
重新评审
:question:重新评审的次数和时长如何控制
:question:太多次或太长时间无法通过评审的案子如何处理
:question:什么样的评审算不通过
a.概念案准备不合格
b.评审过后各Leader投票决定
:question:参与评审的人的资质需要保障，参与开发的人员是否也需参加
如果不能保证权威性则会导致后期开发中依然会有问题
开发人员参与评审不参与投票，是否能缩短详细案的理解
增加各部门同学的参与感，提升团队的全面性
:question:部门leader是否可以对有疑惑的设计案进行挑战，如何控制这个挑战的双方矛盾
不需要评审的会后直接进入粗估
4）全部评审结束后，粗排数据给出
确定版本风险
确定版本内容
各部门提供开发线预估量
辅助确定版本内容
第二次
1）同步版本内容和粗排数据
各部门对版本内容的确认
2）确定细案和宣讲时间
:question:GUI和美术的宣讲时间是否会被推后，是否会影响美术的开发
:question:细案是否能在版本开始前宣讲完毕
3）同步本次版本周期节奏
2.方向
1）策划
源头开始梳理
2）美术
排期的卡点梳理
3）程序
1.原因
1）现行版本筹备阶段流程不顺畅
2）筹备过程中的痛点
策划案的完善性和可落地性
GUI对程序估期和排期的影响
启动会数据和内容的准确性，版本后的可衡量性不足
4.流程
策划概念案准备
第一次启动会
评审
评审结束
第二次启动会
细案宣讲
开发排期
版本开发
1 more item...
宣讲完后2天排期同学给出详细人日消耗，PM与排期同学共同完成排期
第二次启动会结束后，最迟优化周开始细案宣讲，一周宣讲完成
评审数据出来后1-2天进行第二次启动会
最后一个评审结束后2-3天整理出第二次启动会的所需要的数据
第一次启动会后，持续3周（上一版本开发开始后的第二，三，四周），该时间应该是可浮动的
上一版本开发后第一周内，最迟后两天
上一版本开发开始后第一周前3天