第五. 需求评审与产品发布 （承上启下的作用）

一个产品的生命周期：

1.灵感和设计

需求评审

2.开发和实施

产品发布

3.持续运营和迭代

一.需求评审是什么

定义：向各个利益相关解释要做什么，为什么，动员投入，达成一致，开始干活。

三个考量：受到什么影响，会有什么收益，需要什么投入。

利益相关方：开发（工程 &设计）、资源（业务 &财务），用户，关联方。

二.需求评审的目的与形式

目的：清晰定义要做什么；尽可能预计要投入什么；尽然分析会有什么后果。集思广益提出问题，影响和风险，防止产品的局限，把问题插死在早期。

形式：文档，小型沟通会，大型宣讲会。

设计人员：开发、测试、设计、项目管理、业务、用户、财税法、决策人................

产出物：（几乎不太可能）不变的需求文档、项目（初步）计划、预期投入和收益

三.需求评审的过程

1.背景 &现状 &问题

2.演示方案

3.数据指标和期望

4.影响和伤害

5.成本 &计划

1.1 背景 &现状 &问题：

具体的故事

真实的数据

与宏观整体的规划的关系

与其他同级别问题的关系

大概的投入和产出

推荐书籍《满足人性》-克里夫 等 两个人

《绝非偶然》

《孩子王》——马克扎博

《领导梯队》——拉姆查兰 关于职场发展的书 管理

《写给管理者的睡前故事》——明词博客

2.2 演示方案

这是最核心的环节，也是最容易走神的环节

以总分总的推进逻辑来处理

介绍：大致的页面结构，用例列表（总）

表演：具体的功能逻辑，流程方案（分）

回顾：再看页面结构，用例列表（总）

不断吸引问题和疑虑，问题越多越成功

3.3 数据指标和期望

如何证明你对这个东西是深刻理解的？

如何证明这个事情成功或者不成功？

如何证明决策不是拍脑袋？

如何保证逻辑是完善

4.4 影响和伤害

每个人都应该知道自己会为此付出什么，以及会被此影响到什么 风险提前暴露出来

如果不能在此刻收集到可能的负面影响，那项目很可能会出现能盘的风险。

要有决策权限的人来判断，立场之争永无止境。

5.5 成本和计划

大致的评估

至少有不同模块比列

大概可能的时长、步骤、优先级

各种可能的资源投入范围

四.需求评审的一些经验和心得

需求评审是胜利的凯歌，而不是冲锋的号角

提前做好准备，不要把问题集中在一次会议上

诉诸利益，而非沟通

（在需求优秀的前提下）优秀的评审：提前想的完善；大家不走神；讲的明白

态度：专业、投入、自信

需求评审中的对抗抗：牢记目标、认可动机、知错就改、线下讨论

评审后应该有跟进

第二.产品的发布环节

一.需求分析——产品设计——需求评审——（完成施工）——发布上线——（运营迭代）

二.产品发布环节的注意事项及关注点

深入参与开发的发布过程，注意是否有严格步骤和数据迁移前置工作

如果涉及停机，要提前跟用户沟通好；涉及其他系统，也要提前沟通。

准备验证用例，写下来

角色、场景、环境、操作、结果、数据、数据库的表现

所有相关人的联系方式和备份列表

应对可能的失败，准备应对方案

发布后的持续心跳观察

记得有一个郑重的发布通知（和感谢）

血泪史：