产品经理需求分析报告
打从接触产品管理至今已有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、状态转换图，可帮助设计人员更好的考虑异常，也方便指导开发；
此阶段可提前与业务部门约定，对于业务不清晰、职责不明确的需求，考虑后续迭代
四、需求评审
完成需求内部评审及用户最终确认，这一阶段需要进行需求收敛，切忌发散。
1、召集内部评审，根据评审的结果进行调整；
对于重大变化提前与相关人员确认，预料到的问题不要等到需求确认时再提。评审之前一定要内部达成一致，一定要内部达成一致，一定要内部达成一致，重要的事情说三遍，不要问我怎么知道的。
对于需求/DEMO版本的迭代，内部评审时因为版本太多大家看的不仔细，每版都要描述一下有哪些重点变化。
2、与用户进行最终确认，确定上线要求及是否需要分阶段；
邮件确认的话，时间要预留一周；往往复复的，需要几轮。对于需要分阶段的，不急着给出下阶段时间，因为有些需求，等下阶段再评估的时候很可能已经不合理了。
