人人都是产品经理总结 第二章

第二章从需求采集开始讲，一直讲到产品项目需要实现那些对应的需求。

需求从用户中采集，最终又服务于用户，而产品经理在这过程中需要提取用户的需求，并将其转化为公司的产品，另一方面，也可以替用户提需求完善产品。而在这过程中的一个核心思想是“以用户为中心”，这里说的是以用户为核心，而不是以客户，客户一般指购买产品的人，但是不一定是最终使用产品的人，比如某些经销商购买产品，但是他们其实并不使用。

需求分析的具体方法

产品经理需要了解用户，通过不断地接触最终制定出一个“用户画像”，即目标用户需要有的一些基本特点。深入一点的就是用户研究，用户研究可以分为用户的说和做，定性分析与定量分析四个方向。将需求采集与用户研究结合，按以下步骤：明确目标，选择采集方法，制定采集计划，执行采集，资料整理。

一手需求从用户直接产生，可以分为以下几类采集方法：

用户访谈（说+定性）：适合开放式问题，注意用户“说”和“做”不一致的问题，另外需要注意样本采集不要以偏概全，或者在报告中说明样本的采样问题。

调查问卷（说+定量）：适合封闭式问题，作答时间最好不超过10min；需要思考的问题一般放中间；关于被访者个人信息的题目一般放最后；同时需要注意样本偏差、样本过少的问题，还有调查问卷的内容细节问题，例如选项的排列方式等。可以采用灰度发布的方式设计一份调查问卷，即先小规模投放，再修改调查问卷，最终大规模投放。

可用性测试（做+定性）：可用性测试在产品的各个阶段都应该做，而不是到最后才做。

数据分析（做+定量）：数据最能说明问题，但是需要注意的是，在产品设计阶段就需要考虑数据分析的问题，而不是临时抱佛脚。

二手需求可能从其他同事那里产生，可以有以下几种方法：

单项需求卡片，现场调查，AB测试（测试按钮放哪边，先用1000个用户测试，再决定按钮放哪边，类似于灰度发布），日记研究（其他同行的评价，我觉得不如改为同行评价），自己提需求。

产品经理在需求分析中要做的

产品的职责是听用户的并转化为产品需求，而不是满足用户的所有“用户需求”。苏杰觉得需求分析的过程是：树叶-树枝-树干-树干-树枝-树叶的过程，即分-总-分，但是我还是不太明白，可能工作以后会有更多的理解吧。满足一个需求的三种方式：改变现状，降低理想，转移需求，我觉得pm主要还是侧重于改变现状和转移需求两方面吧，尽量达到四两拨千斤的效果。

给需求做一次DNA检测，目的是为了使其对应到产品的具体实现中，即本文第一句话的后半段。本人觉得需求采集过程中的技巧性内容较多，初学者可以学习的较快，而下面才是体现产品经理重要价值的部分。

将需求转化为产品的过程：用户需求转化为产品需求->确定需求基本属性（同时确定需求的种类）->分析需求的商业价值->实现需求的难度->计算性价比

用户需求转化为产品需求：可以用excel做成表格，每一行代表一个需求

需求的基本属性：主要包括编号，提交人*，提交时间，模块*，名称*，描述*，提出者，提出时间，bug编号；一个产品一般有5+-2个模块比较好，网站产品的模块划分会直接影响其导航结构，因此需要特殊注意。标*的一般是必填的。

需求的种类主要包括需求分类和需求层次，分类主要包括：新增功能，功能改进，体验提升，bug修复，内部需求等，需求层次包括：基础，扩展（期望需求），增值（兴奋需求）几类，但是这些划分方式其实没那么决定，很多情况需要酌情处理。

需求的商业价值：不能因为商业价值大就马上做，也不能因为商业价值小就不做，商业价值有以下几个维度：重要性，紧急度，持续时间，商业价值*，一般将这几个维度抽象为一个具体数字代表其具体价值，例如将这些因素抽象为5,4,3,2,1的五个优先级。

实现难度：以XX人天来计算，一般以团队中的瓶颈资源（一般为开发）为标准。

性价比：性价比=商业价值/实现难度（简化为开发量）。

一般利用需求的性价比来确定先做哪方面工作，后做哪方面工作，但是一般也不是说商业价值越高的就先做，价值低的就后做，还取决于其他的很多因素。

将需求放入项目的实现列表中-需求的战场

公司的组织结构方法-按产品线划分和按职能线划分两种。

首先，按产品线划分的方式适合初创团队（貌似是现在我公司的划分方式），以某个产品为主线，产品经理的权力更大，可以按照自己的想法做，资源有保障，产品规划不容易改变。此外，各职能员工之间单线领导，对产品有利。

按职能线划分（即我同事说的，正常的大公司的UED都是横向的，这些资源是多个团队公用的），这种方式对多个产品间的资源共享有利，可以让资源流向更需要的地方，但是单个产品的发展速度会降低，PM和设计师为产品的发展苦苦思索，对公司有利。

在进入产品会议的战场前需要准备的几方面：

1、需求打包，将前述的excel需求列表中基本属性类似的放在一起打包，之后可以将其做成一个界面图（即我实习的时候的那些系统划分图），这样便于讲解也便于理解。

2、在上述需求列表和需求界面图中需要标明相互之间的依赖关系。

3、需求的粒度大小问题，一般需求列表中的任意一行，工作量最好不要超过5人天。

产品会议

某个产品团队亮相的时候，一般要先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大的需求变更，已经发布的项目有什么问题。

之后拿出BRD，每个产品都会拿出2-3个，占满2-3倍的潜在资源。

重头戏：商业需求文档BRD（Business Requirement Document）

BRD包括的内容：项目背景，商业价值（最重要，做出项目以后有什么价值，一定要说到点子上，一般还要预测相关数字的变化），功能需求描述，非功能需求描述，资源评估（第二个重点，决定性价比的第二个因素），风险和对策。

情愿把一般的功能做到尽可能完美也不要把全部的功能都做成半吊子！！（即让既有的作品完美）。

至此，可以得到一个需求的完整DNA：

编号

提交人*

提交时间

模块*

名称*

描述*

提出者

提出时间

bug编号

分类

层次

重要性

紧迫度

持续时间

商业价值*

开发量*

性价比*

状态*

负责pd*

开发工程师

项目名称

发布时间

备注

最后，需求管理的最后，还可以制作出包含以下内容的表格，表明产品设计过程中团队每个人的工作量：

统计每个“提交人”的需求数量、统计“提交时间”、“发布时间”等信息

统计每个模块的需求数量

统计每个分类的需求数量

统计需求的商业价值、性价比变化