需求分析
需求采集
需求来源渠道
- 公司内部（老板，其它部门或同事）
- 产品经理自己（策划、挖掘）
- 公司外部（用户、客户、伙伴）
需求收集表格模板
需求获取方式
- 业务发展的要求
- 用户调查结论
- 用户反馈分析
- 产品数据分析
- 竞品分析
需求池
首先介绍下需求池的组成元素：
序号：需求标识，便于需求管理
需求名称：简单描述需求，清晰并简短
所属模块：建议写产品的一级及二级类目
需求的来源：
包括：用户反馈（包含用户访谈和问卷调研）、市场运营、竞品分析、老板、灵感idea
- 需求的类型：
可以分为：新增功能、功能改进、BUG修复、体验提升（界面设计和交互设计）、内部需求
- 需求描述：
我们要明确用户是在什么场景下，为了完成什么目标而做了什么任务，即要从场景、目标和任务这三方面去具象化需求
提交人：需求提出人
提交时间：需求提出人提出的时间，即进入漏斗的时间
需求状态：每个需求随着项目的进行，会伴随不同的状态
需求优先级：
很多公司用的是紧急四象限的办法进行需求的筛选，即P0紧急重要、P1紧急不重要、P2不紧急重要、P3不紧急不重要。
但是筛选需求优先级别时，要考虑到到需求的受众大小、收入支出效益及近期的产品目标。
优先级判断的一些原则：
受众大，开发成本小的优先做；
受众大，开发成本大的进行排期，以后做；
受众小，开发成本小的根据情况实时插入
受众小，开发成本大的，不做。
需求池思维导图如下：
其次，介绍下需求漏斗常见形态：
需求池的常见形态有：word、excel、思维导图。从我个人来讲，我更喜欢用excel进行需求的整理，因为表格进行展示信息流明显，且容易统计管理。具体格式如下图：
最后，在管理产品需求池时需要注意的事项：
定时对产品需求池进行整理
汇总完需求后，要展开定时展开需求评审会议，进一步去明确需求，删除没有必要的需求
在管理需求池时，要把同一模块的需求进行归类整理，这样在处理该模块时可以一次性解决，提高工作效率
提给技术的需求一次性不要太多，做到敏捷开发
需求分析
需求分类
- 功能类
- 数据类
- 运营类
- 体验类
- 设计类
四象限定位法
- 重要并紧急
- 重要不紧急
- 不重要但紧急
- 不重要也不紧急
需求筛选
这个阶段工作是结合现状对需求进行处理，主要是解决：做不做、做多少、什么时候做的问题。
需求评审的形式主要是团队晨会中展开，邀请领导参与，团队中成员有页面设计师，前端工程师，程序员，测试人员等角色。
通过一次评审，对多个需求进行打包，整理出一个版本（或者子项目）所需的需求点。
对打包好的需求点形成文档，提交由领导复核，确认后进入开发周期。
需求决策
- 战略定位
- 产品定位
- 用户需求
产品定位
- 战略方向更偏向市场
- 产品定位更注重功能定义
用户需求
- 不把需要当成需求
- 不把产品形态当成本质
战略方向
- 起步阶段
- 发展阶段
- 迭代阶段
需求采集
四层需求关系
需求的4层关系; 首先先说是哪4层：
业务需求
用户需求
功能需求
系统需求
看官别着急，单独拉出来一个系统需求是有原因的，如果你不是三五年内的小白产品应该能看懂。
先说业务需求(business requirement)，什么是业务需求? 我觉得是Business Analysis， 就是所谓的 BA吧。不过现在大多数boss或者说创业者不懂这里面具体都是点什么，百度给的定义其实也不是特别的精准，倒是找到一个文库内容，关于业务分析师的定义这里介绍的很精准。好吧，简单的说业务需求是方案范围，经营范围，或者项目范围。业务分析的东西其实就是一种需求的寻找。
举着栗子说： 业务需求就是写出来，我们是做什么的，电商?还是社交?还是其他平台?我们是不是垂直的，线上的还是线下的?我们依赖什么盈利?我们的业务方向怎么发展? 到这里都是业务需求。 业务的需求往往来自boss或者创业的小老板再或者是你们的某个高层领导。专业一些的会有一些大牛给出商业或者业务分析报告给你。更强有力一些。比自己觉得做哪个好要靠谱很多 。当然我现在讲的是互联网，其实很多东西都是通用的。
其次是用户需求(user requirement); 用户需求在互联网中的表现大多是在各种场景下，用户想做某件事情所遇到的问题，或所想满足的欲望。用户需求前期是对比，后期是体验。 在软件中的用户需求则不是，软件用的用户需求是在场景下用户的目标以及能完成的东西是什么。这里需要大量的用例，跟场景描述。 用户需求直白的说就是，你的业务规划，有没有人鸟你，大家对这个事儿咋看，你能帮他们解决啥问题等等。其实还是为了确认project scope 是不是正确的 ，有木有搞头。
然后是功能需求(functional requirement); 功能需求是为了满足业务跟用户而制定的。也就是说，在你的业务需求出来之后，你要满足用户在你这个产品上怎么实现自己的任务。业务需求都包括什么呢?或者说细化到哪一步了呢?
举个栗子：做电商要有购物车，要有商品发布。好的，那购物车里面的功能具体是什么，怎么展示?你可能要细节的写出来，购物车可以批量结账，要有一个单价叠加的计算，如果有打折，可能还有其他的运算; 商品发布，参数都有哪些，发图片、名称、商品描述、颜色、类型等，如果你是一个很有经验的产品人，在这一步你能为前端跟猴子省下很多很多时间。
系统需求(system requirement); 为什么把这个单独拿出来了，是因为在每个需求下都会牵扯到这个系统需求。在软件中是架构师的责任，在互联网中可以是项目经理、产品经理、技术总监共同完成的东西。因为它包含的东西太多了，而且过于繁琐与复杂。那什么是系统需求 ?系统需求是数字控制。还是举栗子说：
在开发过程中，产品时要反复跟各个部门打交道跟交流的，前端、设计、猴子、项目经理、boss。但是有一点，你必须要出的东西其中有一项叫数据字典，这个程序员帮不了你。 比如你的用户名长度，猴子的思维是，我的是string，长度你随意，前端的世界是，正则判断下不要乱七八糟的符号就好了，然后不要超过样式的宽度或者超过了也没事儿我给隐藏了。 那请问，用户名到底要多长? 区间是什么? 这就是系统需求的一部分，因为你要合理的写出来账号，介绍，密码，描述，等等等等之类的一切能键入的规则，你以为这样就完了吗? 再深化一些，你要跟运营部或者市场部，估算出用户成长，在什么时候达到一个什么活跃度等相关数据，以便猴子们可以分库分表或者早点做防备，可能会有人问，为啥当初不分好呢? 要是当初能分好，阿里巴巴就不用去请oracle的团队来架构自己的数据库了，当井喷的时候你根本想不到是什么时间，所以这些必要的措施跟部署也是需要产品人来参与的，这会直接影响到产品跟用户的。 如果你做的不合理，你的规划不好，那用户的体验就没有了。 说案例： 你的社交功能需求跟业务需求写，客户浏览自己个人中心的时候会加载很多推送，这一页的数据加载量很多，有可能认识的，可能感兴趣的之类的，好的。没有什么经验的猴子可能就直接捅给你数据了，功能实现了没错，首页加载慢的要死。如果你能写出来，这里会跨表，跨库，需要一个沉余或者缓存数据表，要不就用分布式部署来解决。那猴子们会不会能完美的解决东西?
有人说，我是个产品经理，我不懂技术。好吧，你大大小小也是个经理不是么?你的任务就是给公司减少难题解决问题的不是么? 经理也是个管理者不是么?你要操心的问题还有很多，你要涉猎的东西还很多，你的知识面也需要很广。这样你才能是一个合格的产品人。