讲师：邱岳
1. 需求评审是什么
- 定义：向各个利益相关方解释要做什么、为什么，动员投入，达成一致，开始干活。
- 三个考量：收到什么影响、会有什么收益、需要什么投入。
- 利益相关方：开发（工程 & 设计）、资源（业务 & 财务）、用户、关联方。
2. 需求评审的目的与形式
- 目的：
☞ 清晰定义要做什么；尽可能预计要投入什么？尽可能分析会有什么后果。
☞ 集思广益提出问题、影响和风险，防止产品经理的局限，把问题掐死在早期。 - 形式：文档、小型沟通会、大型宣讲会、发PRD给相关方看10分钟并标准意见，再做评审（亚马逊、字节跳动）。
- 涉及人员：开发、测试、设计、项目管理、业务、用户、财税法、决策人…
- 产出物：（几乎
不太可能）不变的需求文档、项目（初步）计划、预期投入和收益。
3. 需求评审的过程
3.1. 背景 & 现状 & 问题
- 具体的故事
- 真实的数据
- 与宏观整体的规划的关系
- 与其它同级别问题的关系
- 大概的投入和产出
3.2. 演示方案
- 这是最核心的环节，也是最容易走神的环节。
- 以总分总的推进逻辑来处理：
☞ 介绍：大致的页面结构，用例列表（总）
☞ 表演：具体的功能逻辑，流程方案（分）
☞ 回顾：再看页面结构，用例列表（总） - 不断吸引问题和疑虑，问题越多越成功。
3.3. 数据指标和期望
- 如何证明你对这个东西是深刻理解的？
☞ 卫哲3+1提问：如果这件事情是成功的，数据会有什么变化，能量化和指标化出来么？ - 如何证明这个事情成功或者不成功？
- 如何证明决策不是拍脑袋？
- 如何保证逻辑是完善的？
3.4. 影响和伤害
- 每个人都应该知道自己会为此付出什么，以及会被此影响到什么。
- 如果不能在此刻，收集到可能的负面影响，那项目很可能会出现崩盘的风险。
- 要有决策权限的人来判断，立场之争永无止境。
3.5. 成本 & 计划
- 大致的评估
- 至少有不同模块的比例
- 大概可能的时长、步骤、优先级
- 各种可能的资源投入范围。
4. 需求评审的一些经验和心得
- 需求评审是胜利的凯歌，而不是冲锋的号角。
- 提前做好准备，不要把问题集中在一次【会议】上。
- 诉诸利益，而非【沟通】。
- （在需求优秀的前提下）优秀的评审：提前想得完善、大家不走神、讲得明白。
- 态度：专业、投入、自信。
- 需求评审中的对抗：牢记目标、认可动机、知错就改、线下讨论。
- 评审后应该有跟进。
4.1 产品的发布环节
需求分析 --> 产品设计 --> 需求评审 --> 完成施工 --> 发布上线 --> 运营迭代
5. 产品的发布环节
- 深入参与开发的发布过程，注意是否有严格步骤依赖和数据迁移前置工作。
- 如果涉及停机，要提前跟用户沟通好；涉及其它系统，也要提前沟通。
- 准备验证用例：角色、场景、环境、操作、结果、数据库表现。
- 所有相关人的联系方式和备份列表。
- 应对可能的失败，准备应对方案。
- 发布后的持续心跳观察。
- 记得有一个郑重的发布通知（和感谢）
6. 发布 Checklist
- 业务逻辑可能影响的相关产品或模块有哪些，产品经理 / 开发 是否明确的清楚这次发布以及可能带来的影响？
- 谁有权限批准发布，是否已经清楚这次发布及可能带来的影响？
- 如果需要追加紧急发布，是否需要申请权限，向谁申请，能不能联系到？如果紧急发布了需要同步给谁？
- 是否需要对部分服务链路提前配置，比如广告系统的 host 绑定。
- 是否需要数据库变更，DBA 是否已经清楚发布和变更。
- 是否需要订正或迁移历史数据，数据库变更脚本是否有回滚脚本。
- 是否有代码回退流程，停机会对哪些系统带来影响，系统负责人是否清楚。
- 发布是否需要停机，停机会对哪些系统带来影响，系统负责人是否清楚。
- 是否能影响用户，要不要挂通知。服务部门是否清楚这次发布，Call Center 是否已经有统一说辞。
- 发布是否有不同模块的先后顺序，是否有明确的发布计划。
- 有没有关键人员休假，后备方案是什么？
- 发布通知有没有写好，是否抄送到了所有相关人员。
- 不要在发布通知里加感叹号，别忘了在发布通知中致谢。
- 是否跟钱相关，财务和法务是否需要或已经清楚这次发布。
- 会不会被高，通知公关了吗？
- 依赖什么外部服务，外部服务的接口人是否清楚这次发布。
- 有没有借用别人的服务器，是否会对服务器上的其它服务造成冲击。
- 有没有 UGC，有没有内容风险。
- 不要在周五发布，如果必须在周五发布，要确定周末值班人员。
- 埋点了吗？
- 去测速网站看一下有没有连不上的网络或地区。
团队管理类书籍：
《领导梯队》拉姆·查兰
《格鲁夫给经理人的第一堂课》格鲁夫
《写给管理者的睡前故事》亨利·宁茨伯格