菜鸟产品人的开始（2）——需求分析

从瀑布到敏捷

        从瀑布交付模型到敏捷交付模型，反映了产品开发交付这个流程随着时代的变更，现在瀑布交付模型已经不再使用了。

        从产品经理的角度看这两个流程，各个阶段交付件产出的区别不大。区别在于瀑布模型时代以文档为核心，目前的敏捷以“人”为核心。其二，为了产品可以快速交付给用户拿到及时的反馈，以Sprint（冲刺/迭代周期）为最小单元的Scrum理念，更加快捷高效。而瀑布模型较长的交付周期，也使它难以适应快节奏迭代的需求。

        （补充：Scrum和敏捷Agile的关系，Scrum是敏捷典型方案的一种，敏捷交付方法发展出来的方案有很多，而其中之一的Scrum使用较为广泛。）

        无论在哪个时代，即使目前文档的作用被弱化了，对于产品经理来说，能够写出高质量的文档输出件也是能力的体现。典型的文档可以概括为BRD、MRD、PRD。简单来说，BRD多用于向上汇报，PRD则是用于和开发的沟通，MRD则面向市场。

需求分析

        需求分析，一端是价值，一端是资源。如果没有前期对需求价值细致的拆分和争取，可能就不会有资源评估了。

        Scrum中使用用户故事（User Story）来整体描述需求，一个好的用户故事包含以下三个因素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

        而把一个整体的需求拆解成的开发点，就称为故事点（Story Point），这也是产品经理和Scrum其他团队成员可以共同完成的任务——工作量评估

        需求资源——工作量评估

        工作量评估也叫敏捷估算，通常使用1人天作为最小单元估算，用来评估需求实现资源和难度。

        评估工作量首先需要产品经理和开发团队合力拆分需求。比如用户故事只是一个模糊的概念，工作量的评估需要明确需求具体的实现步骤。在Scrum里面，这个过程产出叫做Product Backlog，将开发的步骤拆分为最小颗粒度的动作

        需求价值——KANO模型

        作为产品经理重要输出件的PRD文档，必然会需要一个清晰的Excel记录表来罗列需求清单，也可以称为Feature List。《人人都是产品经理》中提供了一种泛化的模板，产品经理也可以根据自己项目的实际情况定义Excel的列名。

模块

子模块

Feature

任务描述

商业价值描述

商业属性

商业优先级

开发量

性价比

备注

        其中需求的优先级排序是必须的，产品经理通常使用KANO模型来判断需求的类型，并通过落位四象限来判断需求的优先级，是一种非常实用的量化需求价值的模型。