需求评审和产品发布

1. 需求评审

1.1. 需求评审是什么

1.2. 目的与形式

1.3. 需求评审的过程

1.3.1. 背景&现状&问题

1.3.2. 演示方案

1.3.3. 数据指标和期望

1.3.4. 影响和伤害

1.3.5. 成本和计划

1.4. 经验和心得

2. 产品发布

 

1. 需求评审

1.1. 需求评审是什么

1. 定义：向各个利益相关方解释要做什么、为什么，动员投入，达成一致，开始干活。
2. 利益相关方：开发（工程&设计)、资源（业务&财务)、用户、关联方。
3. 核心问题：我们要做什么？需要投入什么？可以获得什么效益？

1.2. 目的与形式

1. 目的
   1. 清晰定义要做什么；
   2. 尽可能预计要投入什么；
   3. 尽可能分析会有什么后果；
   4. 集思广益提出问题、影响和风险，防止产品经理的局限，把问题掐死在早期。
2. 形式：文档、小型沟通会、大型宣讲会。
3. 涉及人员：开发、测试、设计、项目管理、业务、用户、财税法、决策人
4. 产出物：(几乎不太可能)不变的需求文档、项目（初步）计划、预期投入和收益

1.3. 需求评审的过程

1.3.1. 背景&现状&问题

1. 具体的故事
   1. 感性视角，营造画面感，调动大家的感性和注意力
   2. 有些时候故事比数据更具有力量。比如做一个贫困地区的项目，举很多贫困地区的各项数据指标，不如讲具体一个家庭的故事，或者贫困儿童的双眼等的照片
2. 真实的数据
   1. 理性角度去分析
3. 与宏观整体的规划的关系
   1. 为什么做这个事情有助于长期的发展战略
4. 与其他同级别问题的关系
   1. 有那么多事情可以做，为什么选择做这个事情
5. 大概的投入和产出

1.3.2. 演示方案

1. 这是最核心的环节，也是最容易走神的环节
2. 以总分总的推进逻辑来处理
   1. 介绍:大致的页面结构，用例列表（总)
   2. 表演:具体的功能逻辑，流程方案（分)
   3. 回顾:再看页面结构，用例列表（总)
3. 不断吸引问题和疑虑，问题越多越成功
4. 不要只是从头到尾，把原型上的注释带着大家看一遍，要以某些具体的/场景化的流程去讲述，这样更有代入感，也更容易发现问题

1.3.3. 数据指标和期望

1. 如何证明你对这个东⻄是深刻理解的？
2. 如何证明这个事情成功或者不成功？
3. 如何证明决策不是拍脑袋？
4. 如何保证逻辑是完善的

1.3.4. 影响和伤害

1. 每个人都应该知道自己会为此付出什么，以及会被此影响到什么。
2. 如果不能在此刻，收集到可能的负面影响，那项目很可能会出现崩盘的风险。
3. 要有决策权限的人来判断，立场之争永无止境。

1.3.5. 成本和计划

1. 大致的评估
2. 至少有不同模块的比例
3. 大概可能的时长、步骤、优先级
4. 各种可能的资源投入范围

1.4. 经验和心得

1. 需求评审是胜利的凯歌，而不是冲锋的号角
2. 提前做好准备，不要把问题集中在一次「会议」上
3. 诉诸利益，而非「沟通」
4. (在需求优秀的前提下)优秀的评审:提前想得完善、大家不走神、讲得明白
5. 态度：专业、投入、自信
6. 需求评审中的对抗：牢记目标、认可动机、知错就改、线下讨论
7.   评审后应该有跟进

2. 产品发布

1. 深入参与开发的发布过程，注意是否有严格步骤依赖和数据迁移前置工作
2. 如果涉及停机，要提前跟用户沟通好;涉及其他系统，也要提前沟通。
3. 准备验证用例(写下来)
   1. 角色、场景、环境、操作、结果、数据库表现
4. 所有相关人的联系方式和备份列表
5. 应对可能的失败，准备应对方案发布后的持续心跳观察
6. 记得有一个郑重的发布通知(和感谢)