产品经理需求分析报告.pdf

产品经理需求分析报告

打从接触产品管理至今已有8年了，中间也换过一次行业，深觉一旦掌握基

本技能加之恰当的方法，行业壁垒没有想像中那么大，毕竟都是IT产品相关的

工作，还是大同小异的。我是一直在产品管理的路上乱闯乱跳，工作经验积累的

已经不少，但总是觉着没有任何提升，没有自信就容易否定自己。所以，痛定思

痛，还是沉淀一下，仔细总结总结历往遇到的问题和那些没能完美跨过的坑。没

有总结的人生，永远都是瞎混。所以，先从需求入手，聊一聊需求分析那些事儿。

需求分析可以分这几个阶段：需求收集-需求调研-需求梳理-需求评审。每

个阶段都有不同的思路，也有对应不同的输出物。

一、需求收集

在这一点上，通信、传统IT项目可能有别于传统互联网，需求的产生和提

出，通常会有其发起的业务部门，即业务Owner。业务Owner需要深度参与到

项目中来，要对需求负责，要协调业务流程梳理，要进行业务测试，并决定是否

上线。运营商行业的业务Owner我接触比较多是信息化部、业务支撑部。原则

上讲，业务Owner需要提交一份业务需求，但有时也只是口头传达有个什么样

的需求，具体调研时候再来谈。

1、需求的接收

业务Owner会有哪些需求通常都是提前预知的。打个招呼，会有个什么类

的需求要找你做。可能暂时无法接收，可能业务Owner还没能想好，那么可以

约定相关需求的提交时间。大家都比较忙，作为接收人，要提前排好接收时间，

同时到约定时间前也提前提醒一下对方。

对于项目背景、建设目标、需求提出部门、业务负责人、用户群及使用量，

可以提前做些功课，收集信息，收集的途径可以多方，适当时候也可以收集一下

类似的需求/产品。

如下信息尽量在需求分析前先搞清楚：组织架构、职责、角色、使用人员的

梳理。

2、需求的主动收集

互联网产品往往没有业务Owner，产品做成什么样子，需要产品经理主动

去了解。基于此背景，需求的收集可以有用户访谈、意见收集、问卷调查等等。

这里我经验有限，就不展开来讲了。日常用的最多的就是各种竞品分析，哈哈

二、需求调研

向客户和相关部门开展调研工作：了解业务、现状、痛点、角色责任人等；

1、需求调研需要覆盖如下人员：业务负责人（主要负责整个系统的建设）

以及关键人群（日后使用者，可能包含多部门的多人）；

2、对于业务需求，要发扬刨根问底的精神，了解业务到底要干什么，这么

做到底为什么。

3、如果是系统改造或新建系统与其他系统有关联，以下事项不可或缺：对

本系统或其他系统的影响评估；本系统或其他业务系统的痛点问题分析；

4、不能忽略异常流程、人员组织机构变动的实际情况；

这里重点再说一下第二点，发扬刨根问底的精神。这一点说起来容易做起来

可不容易，跟我们打交道的人都是IT出身，这些技术爱好者们最喜欢干的事儿

就是跳过业务需求，直接告诉你怎么实现，头疼不已，一定不要让他们牵着鼻子

走。可以探讨技术实现，但是一定记住这不是主要目的，业务部门的人立足于当

前的自身需求，考虑的实现一定不是全面的、合理的、满足产品规划的。如果让

业务部门的人直接决定，那要需求分析人员干嘛呢，是不是这个道理？所以，需

求调研时，秉承一个原则，技术实现问题，下阶段再讨论，我们专注于业务。

至此，本阶段结束时，输出物应该有初版的业务需求书。

三、需求梳理

根据客户需求输出系统方案，包括：业务流程、业务规则的确定、系统功能

架构、功能描述，以及与外围系统间关系。这一阶段，是思考和创作的阶段了。

说几个重要的输出物：

1、完整的业务流程图，需要表示出正常和异常流程；

2、需求说明书，功能点业务逻辑写的尽量详细，要保证文档的质量，check

一下原来讨论的结论；

3、页面原型DEMO，提供给业务部门确认，为业务UI的设计提供依据，

对于前台的要求可体现在原型中；

4、列表数据的展现顺序，尽早确认，以免后续频繁调整频繁复测；

5、状态转换图，可帮助设计人员更好的考虑异常，也方便指导开发；

此阶段可提前与业务部门约定，对于业务不清晰、职责不明确的需求，考虑

后续