接着的就是再次的资源盘点和目标对焦，简要的 recheck 确保补齐。这时 PM 根据各负责角色工作评估做出简要排期和项目需求+参与方核对各方诉求，确定最终版本。这里也会遇到几个问题：
排期时间过长。 解：拆分、加人、分阶段。建议最小工作单元评估最好不要超过2人日 。
其他项目排期冲突。解：分析是产品节奏冲突还是人员(资源)冲突，确认好各自目标再共同协商总体排期。
重要阶段未给足充分时间，如设计阶段、系统联调、冒烟、测试、内测等经常忽略项。解：提前协商沟通好协调。
最后，项目排期要和各参与同学沟通清楚投入度和时间节点。一定要明确几个重要的时间点：设计评审、测分评审时间、提测时间、产品验收时间、发布时间(如果客户端还要根据不同端特殊情况分开列出)。同时排期过程中可能遇到的并行风险、人员资源风险及时对外同步。
★ 设计+测分评审
设计之于项目隐患+后期扩展、测分之于项目质量风险的意义，技术同学想必都是非常清晰明确的。这不仅仅要求项目PM，对于核心的系分、测分设计人员也提出严格要求。务必保证：
1. 重要流程有图、有文字、有用例覆盖。
2. 重要设计方案、测试方案要提前沟通讨论评估风险和影响。
3. 需要考虑资金、安全、性能、风险的，单列 todolist + checklist。
4. 重要设计影响对外同步。
对于技术型的 PM，最好满足：
1.项目中的核心设计者；
2.业务 owner 或核心，其中一项。
这里主要是考虑到技术项目 PM(实在不行要有核心设计人员)对于业务定型、技术定型在业务中后期的影响着实太大。
此阶段开始作为过程跟踪重要手段需要有常规的项目日报和风险提示 了。建议对于工作日小于20人日的项目可以不用每天发项目日报，有风险及时同步即可。超过的最好每日有项目详细进度， 根据项目复杂度不同 粒度可以精确到单人负责的模块 。重要的是过程跟踪+问题及时反馈解决。
★ 研发过程
研发过程中一般大家精力都会集中在各自项目负责模块上。同时对于我们这种互联网公司，变化又是家常便饭。这里有个原则是信息跟踪和同步评估要充分。可能涉及到排期调整的，要及时沟通和调整。也要注意风险和项目范围把控。这时你可能会有如下帮助：
1. 项目空间任务列表(aone有批量功能)
2. 排期进度表(云雀)
3. 需求变更记实录表(云雀)
4. 人员负责表(云雀)
5. 风险跟踪列表(云雀或aone)
6. 过程进度日报：模块进度条百分比、当日工作主要内容、风险同步与处理。
7. 重要逻辑影响对外同步(如表逻辑、业务逻辑变更的，需同步对应使用方)。
★ 冒烟+联调+提测
大家都知道大多数的线上技术问题都可以在测试阶段提前发现。而PM要思考的是测试前我们能做什么？提测前的冒烟、联调包含了必要的单元测试、功能测试和部分集成测试。尤其是对于多系统联动的项目冒烟和联调的质量直接影响到测试效果和线上问题量。这里PM一定要提前沟通评估安排好时间控制和冒烟联调节奏，有必要的话集中闭关+小阶段目标设定可以实行 。同时对于复杂的项目由于整体节奏和工作压力等原因参与人员很容易陷入自我流程和模块逻辑里。 在联调阶段作为PM最好能设计出几个经典业务场景作为联调目标，对项目的整体质量做提早把控 。重要项目特殊建议：
1. 全量(70%+)含凭证冒烟。
2. 流程覆盖设计+测试执行(PM)
3. 闭关联调+分模块分阶段联调半日目标进度。
4. 独立的项目联调环境准备。
5. 关键链路的日志标要求。
无论是作为核心开发还是纯PM，此阶段都需要主动去检查项目的研发交付程度。包含但不限于主业务流程、特殊分支逻辑等 。你可以根据项目重要程度复杂程度来判断是否需要精细化。同时此阶段也很容易暴露缺失或错误逻辑。我个人做法是小型项目自己设计场景 case 走；大型项目联合核心研发测试一起设计场景 case；同时注意对产品交互和 demo。
★ 测试
项目到了测试阶段大部分的开发工作已经基本结束了。我们这里讨论一种场景是开发测试有不同人员执行。测试 bug 要督促做到日清，不能日清的需要有原因跟踪。本阶段一般也是 code review 集中阶段。PM应直接或间接的对于关键链路设计、流程日志记录、编码规范要着重把关 。同时产品发布+回滚方案在本阶段要做准备了。一般来说每个团队发展到2年后都会有比较规范的发布计划模板。这里我们着重提及几点PM要注意的事项：
0. 安排处理好项目测试环境，确保稳定性。
1. 安排各系统CR节奏，并跟踪反馈。
2. 安排发布计划讨论和准备。制定并总结初步发布执行计划(单点对应明确责任人)。
3. 安排讨论确定版本限制兼容方案。
4. 安排准备线上功能开关和灰度方案。
5. 重要项目要有发布预演。
6. 预发和线上不隔离的系统要注意单独考虑预评估发测试风险。有必要的给出操作步骤。
★ 产品验收
一般情况测试完成后就到产品验收环节了。这个过程有些同学可能就直接不问或者任凭产品验收结果做最后的质量兜底。这是极为不可取的，原因是一般的产品验收最多只会跑到整体项目 case 的30%不到，越是大越是复杂的项目这个比率越是低。产品验收的目标是检查产品功能完整性、产品体验，而对C的线上用户几乎会全方位无死角覆盖。所以这次是你
