1.需求采集

在实际项目中，采集需求的主要方式有自身产品定位，用户调研，竞品分析，建立用户画像，用户反馈（上线后），产品数据（上线后）。

理论上较全的调研与采集方法，见下图

2.需求分类

可分为：功能类需求，运营类需求，数据类需求，设计类需求。也可细分为如下图：

3.需求分析

从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

筛选不合理需求-----挖掘用户目标-----匹配产品定位------定义优先级

3.1PSP法(P(person)、S(scenes)、P(Paths)，即角色-场景-路径法。）

3.2如何定义优先级

这里还是用最常用的判断方法，紧急重要四象限法则

重要程度大致按这种排序（围绕商业价值和用户价值分析）：

不做会造成严重的问题和恶劣的影响的

做了会产生巨大好处和极佳效果的

跟重要合作对象或投资人有关的

跟核心用户利益有关的

跟大部分用户权益有关的

跟效率或成本有关的

跟用户体验有关的

紧急程度按这个排序：

不做错误会持续发生，造成严重影响

在一定时间内可控，但长期会有糟糕的影响

做了立刻能解决很多问题、产生正面的影响

做了在一段时间后可以有良好的效果

把能考虑到的因素想全，会标上P1 - P4的优先级。

1）第一象限：重要且紧急。首要解决这类事情是毋庸质疑的了，但需要控制好的是该象限的需求数量。以你的重要性标杆为主，需求提出方的标杆为辅，如果本末倒置，就永远跳不出这个坑了。

2）第二象限：重要不紧急。对待这一类的需求，不建议立即开工。比“立即执行”更重要的，是反复评估，尽量确保产品方案的严谨性。等时机成熟，能拿出一个尽量完善的方案支持开发，高效完成，避免反复。

3）第三象限：不重要但紧急。这个类型简直太经常遇到了。“反正是小事顺手做了吧”、“我们很着急用这个功能，帮个忙嘛”……这个时候千万要把持住！不要随口答应！千万记得，再紧急，它也是不重要，既然不重要，就需要好好评估。最可怕的是因为需求提出方着急，自己也跟着急，结果没有想清楚就提了开发需求，最后产品方案也不完善、功能又不重要、还浪费了开发资源，最后出力不讨好。

那么如何处理这个象限的需求呢？

第一，和需求提出方对重要性和紧迫性认知的分歧，需要我们做出进一步的沟通，以判断是否仍然需要你的配合，是否可以转移到其他象限；

第二，如果对方确认仍需要向你提出需求，那就要考虑该需求和自己的其他项目是否有重叠，如果是可以一起开发支持，那就一并放到其他项目中；

第三，如果该需求确认需要你配合，又和其他项目无重叠，又很紧急，那么这时候需要和需求提出方确认下能够接受的时间期限，尽量争取自由度，即便需要临时支持，也要给现行的项目足够的缓冲。

4）第四象限：不重要不紧急。遇到这类的需求，就不要装好人了，该推掉就推掉吧。如果对需求的认知有歧义，那么就帮助需求提出方了解为什么是不重要又不紧急。总之，把你的精力放在其他需求上吧。

4.需求评审

有了确切方案，我们会尽快跟研发的同事做可行性评审。这一步必不可少。出现的「落不了地」和「频繁更改」的问题，要着重在这个步骤里解决。

可行性评审上，完成的是对需求的大致评估，要做的有这么几件事：

4.1.方案本身的可行性

在技术方案上，是不是能够完成？就是让技术部门评估这个问题。

4.2.有没有更好的方案？

一定要跟技术部门灌输清晰的需求背景，让他们也想一些可行的方案。方案未必是完整、准确的，但他们提供的思路，一般是可行性较高的。

4.3.涉及的产品和技术环节有哪些？

这个需要相关的同事仔细讨论。尤其是很多公司产品线比较多，有可能存在牵一发动全身的情况，如果相关的产品同事和技术同事不知情，必然会延期，必然会扯皮，必然会造成麻烦，必然会有各种改动。即便是再小的产品，也要分前后端，让技术的同事来判断有哪些人需要知情和参与评估。

4.4.方案的成本如何？

看方案需要多少人、多少资源、多少时间来完成，也要看方案在技术层面耗费的不太明显的成本，比如服务器成本、带宽成本，给用户造成的流量成本等。

有了这样的讨论，会议输出的，就是比较严谨的可执行方案（或草稿）了。

如果会上遇到各种问题，要确认解决问题的时间节点。

5.花两个月收集的需求资源大放送

百度云盘资源地址：http://pan.baidu.com/s/1eSkBAs6

密码：5buz