如何做需求分析
本文通过一个具体的返利项目案例，详细介绍了从项目背景理解到需求澄清、分类、优先级排序、方案设计及评审的全过程。通过系统的需求分析方法，确保项目能够真正解决业务问题，提高产品的市场竞争力和用户满意度。
你是否经历过，业务方跟你提的需求是要一匹马，你也实际给他了一匹马，但是业务又说这匹马不是他想要的。
你又是否经历过去面试的时候，面试官问你“你怎么做需求分析？”你不知道如何回答更好。
出现问题1的原因，主要在于没有定义好需求，其实业务并不是要一匹马，而是要一个能帮他快速到达目的地的工具而已。出现问题2的原因主要在于不够系统的理解需求分析。
接下来我会拿一个我从0到1负责的一个主机厂给经销商返利的一个项目来举例说明。
一、理解项目背景
1. 了解项目愿景
了解项目愿景其实就是了解业务方通过项目实现的长远目标，即解决什么问题？创造什么机会?带来什么价值？
再这个返利项目中，业务方的愿景是希望能通过给经销商提供返利从而提高经销商的积极性，从而提高汽车的销量。
2. 了解项目目标
明确具体的目标。如本返利系统一期的目标是通过系统提高计算返利的速度20%。
二、识别干系人
1. 识别干系人主要包括确定干系人和了解关系人的需求。
确定主要干系人
主要干系人通常包括项目发起部门/人员、受益部门/人员、实际操作部门/人员、后续影响部门/人员。在本项目中项目发起人是财务部门、受益部门和实际操作部门是财务部门计算和发放返利的人、品牌部制定返利政策的人、计算返利的人、后续影响人员是财务部门负责计提和结账的人
校长、教师、学生和家长
2. 了解干系人的关注点和担忧点
分析关注点时，要从两个角度出发：一是他们希望系统解决什么问题、提供什么业务支持‘二是他们希望避免出现什么样的负面影响’。在返利项目中，我们通过和财务部、品牌部沟通，发现他们的关注点有以下两点：
1）能够方便快速的录入返利政策，
2）能快速无误的计算出返利结果
他们的担忧点主要是
每个月的返利政策类型都不一样、形式也不一样，涉及到的指标也不一样。是否能支持每个月的政策的录入？
三、需求收集
需求收集是需求分析的核心，通常需求可能来源于老板、业务方、竞品分析、用户、产品经理自己通过数据分析等手段发现的需求、以及其他同事做其需求时涉及自己配合的需求等，因此我们可以采用访谈、发放问卷调查、观察用户使用类似应用的行为等手段段来收集需求。
四、需求澄清
需求澄清是我认为是需求分析中最核心的部分。
在实际工作中，我们常遇到业务方提出我们需要XX功能，这类需求我们可以定义为解决方案级需求，如果产品经理照做，就有可能出现问题1中出力不讨好的情况，明明实现了业务要的功能，但是还是没有办法解决业务的问题。
因此，我们需要将解决方案级需求重新澄清为问题级需求。
1.如何将解决方案级澄清为问题级需求？
可通过场景分析，一般会从时间、地点、人物、起因、经过、结果几个维度分析
时间：早/中/晚
地点：室内/室
办公室/家里
人物：儿童/青年/老
新用户/老用户
起因：因为什么原因
1）主动
2）被动
2. 多问几个why
可通过几个why,挖掘背后的动机，直到挖掘出用户的行为动机或者心理动机。
我曾经收到运营同学给我提一个功能：增加优惠券申请审批功能。这就是一个典型的方案级需求，我们需要澄清为问题级需求，找到问题。因此我和运营同学有了下面的沟通：
产品：“你为什么需要一个审批功能？”
运营：“因为我们出现了很多次发错优惠券！”
产品：“你为什么会发错优惠券呢？”
运营：“因为我们每个月要发好几次优惠券，每次发放的用户不一样，而我们发放的用户需要通过Excel上传一个白名单，但是有时候忙的时候回上传错名单，又没有办法直接查看名单信息！”
产品：“所以只要防止你发错就可以了吗？”
运营：“是的！”
通过上面提问，我们的需求从”增加优惠券审批功能”重新澄清为”如何防止优惠券发错？”
五、需求分类
将收集到的需求进行分析归类，如功能性需求、非功能性需求、界面需求、数据需求。
功能性需求：简单的可以理解为，为了实现用户的目标，向用户提供有用的功能，系统必须执行的功能。例如返利项目中为了实现返利项目下发的目标，那么需要提供返利规则制定功能、下发政策功能。
非功能性需求：描述系统的性能、安全性、可用性、容错性、扩展型等
界面需求：如界面的设计、色彩搭配、布局等用户视觉需求
数据需求：比如数据获取，数据存储，数据分析。尤其在AI时代，数据需求会变得更多，更加智能化
六、需求优先级排序
对于任何一个项目，都会有很多个需求，而我们的资源有限，所以通常根据需求价值、成本、几个维度评估需求的优先级,通常是需求价值高、成本低、紧急的需求优先做，需求价值低、成本高、不紧急的最后做。
1. 需求价值评估
价值评估是很重要的环节，不管内部需求还是商业化需求，既然要接，一定是有价值的，要不然投入的资源和时间处理，就是浪费。需求价值评估可按以下几个方面评估
战略契合：并不是什么需求都必须做，如果需求与当前战略目标有冲突，即使需求价值再高也不做
市场潜力：相关需求的未来市场有多大？例如iphone面世后，原先全球的手机用户未来将面临更新换代的需求
业务价值：需求落地后，对业务目标和收益的贡献大小
覆盖人群：需求会影响哪些用户，什么量级
功能使用频次：可推测每个用户在一段时间内，适用该功能的次数
是否影响流程、工作：需求是否会影响主流程，如购物，缺少下单功能，流程就走不通
用户满意度：需求对提高用户满意度和用户体验的影响
需求紧急程度：需求满足对时间的敏感程度
依赖程度:需求对其他需求或者项目里程碑的依赖程度
…..
在日常工作中，接到新需求不一定都要考虑这么多因素，可以根据实际情况进行删减。一些小功能需求，稍微考虑“覆盖人群”、“使用频率”、“研发成本”也够了
2. 成本评估
成本评估或者叫工时评估，包括产品、UI设计、前后端技术、测试等都加上，一般几个岗位的工时比例，
产品：设计：前后端技术：测试=1:1：（2-3）:1，也就是技术的工时应该是其他的2-3倍，当然也要看具体的需求。
3. 输出优先级
根据前面的价值和成本评估，我们可以生成一个四象限，可以看到左上角的应该优先级最高，就是价值越高、成本越低的，付出更少的资源成本可以实现更高价值的需求，这个就是最优先的，相反，右下角的就是最低的了。
注意：有的项目中，尤其是乙方项目，还需要把需求优先级和甲方沟通，把排期计划同步给他们。
七、产品方案设计及评审
再排好需求优先级后，就可以跟进优先级高低进行产品方案设计、PRD文档撰写和需求评审。在这里因为不同的项目，产品方案不同，我就不具体阐述了。
八、需求排期
需求评审后，产品和前端、后端、测试、UI设计师（有的需求可能不需要）需要一起定一个具体的排期计划。
九、需求跟进
需求跟进主要包括设计、研发进度跟进；解答设计师或者研发、测试的一些问题
十、需求验证
在这里我觉得分为两步：
第一步：上线前的验证
第二步：上线后的验证，可采用数据分析、用户回访等方式验证。
