本文通过一个具体的返利项目案例，详细介绍了从项目背景理解到需求澄清、分类、优先级排序、方案设计及评审的全过程。通过系统的需求分析方法，确保项目能够真正解决业务问题，提高产品的市场竞争力和用户满意度。
你是否经历过，业务方跟你提的需求是要一匹马，你也实际给他了一匹马，但是业务又说这匹马不是他想要的。
你又是否经历过去面试的时候，面试官问你“你怎么做需求分析？”你不知道如何回答更好。
出现问题1的原因，主要在于没有定义好需求，其实业务并不是要一匹马，而是要一个能帮他快速到达目的地的工具而已。出现问题2的原因主要在于不够系统的理解需求分析。
接下来我会拿一个我从0到1负责的一个主机厂给经销商返利的一个项目来举例说明。
了解项目愿景其实就是了解业务方通过项目实现的长远目标，即解决什么问题？创造什么机会?带来什么价值？
再这个返利项目中，业务方的愿景是希望能通过给经销商提供返利从而提高经销商的积极性，从而提高汽车的销量。
明确具体的目标。如本返利系统一期的目标是通过系统提高计算返利的速度20%。
确定主要干系人
主要干系人通常包括项目发起部门/人员、受益部门/人员、实际操作部门/人员、后续影响部门/人员。在本项目中项目发起人是财务部门、受益部门和实际操作部门是财务部门计算和发放返利的人、品牌部制定返利政策的人、计算返利的人、后续影响人员是财务部门负责计提和结账的人
分析关注点时，要从两个角度出发：一是他们希望系统解决什么问题、提供什么业务支持‘二是他们希望避免出现什么样的负面影响’。在返利项目中，我们通过和财务部、品牌部沟通，发现他们的关注点有以下两点：
他们的担忧点主要是
每个月的返利政策类型都不一样、形式也不一样，涉及到的指标也不一样。是否能支持每个月的政策的录入？
需求收集是需求分析的核心，通常需求可能来源于老板、业务方、竞品分析、用户、产品经理自己通过数据分析等手段发现的需求、以及其他同事做其需求时涉及自己配合的需求等，因此我们可以采用访谈、发放问卷调查、观察用户使用类似应用的行为等手段段来收集需求。
需求澄清是我认为是需求分析中最核心的部分。
在实际工作中，我们常遇到业务方提出我们需要XX功能，这类需求我们可以定义为解决方案级需求，如果产品经理照做，就有可能出现问题1中出力不讨好的情况，明明实现了业务要的功能，但是还是没有办法解决业务的问题。
因此，我们需要将解决方案级需求重新澄清为问题级需求。
可通过场景分析，一般会从时间、地点、人物、起因、经过、结果几个维度分析
1）主动
2）被动
可通过几个why,挖掘背后的动机，直到挖掘出用户的行为动机或者心理动机。
我曾经收到运营同学给我提一个功能：增加优惠券申请审批功能。这就是一个典型的方案级需求，我们需要澄清为问题级需求，找到问题。因此我和运营同学有了下面的沟通：
产品：“你为什么需要一个审批功能？”
运营：“因为我们出现了很多次发错优惠券！”
产品：“你为什么会发错优惠券呢？”
运营：“因为我们每个月要发好几次优惠券，每次发放的用户不一样，而我们发放的用户需要通过Excel上传一个白名单，但是有时候忙的时候回上传错名单，又没有办法直接查看名单信息！”
产品：“所以只要防止你发错就可以了吗？”
运营：“是的！”
通过上面提问，我们的需求从”增加优惠券审批功能”重新澄清为”如何防止优惠券发错？”
将收集到的需求进行分析归类，如功能性需求、非功能性需求、界面需求、数据需求。
对于任何一个项目，都会有很多个需求，而我们的资源有限，所以通常根据需求价值、成本、几个维度评估需求的优先级,通常是需求价值高、成本低、紧急的需求优先做，需求价值低、成本高、不紧急的最后做。
价值评估是很重要的环节，不管内部需求还是商业化需求，既然要接，一定是有价值的，要不然投入的资源和时间处理，就是浪费。需求价值评估可按以下几个方面评估
在日常工作中，接到新需求不一定都要考虑这么多因素，可以根据实际情况进行删减。一些小功能需求，稍微考虑“覆盖人群”、“使用频率”、“研发成本”也够了
成本评估或者叫工时评估，包括产品、UI设计、前后端技术、测试等都加上，一般几个岗位的工时比例，
产品：设计：前后端技术：测试=1:1：（2-3）:1，也就是技术的工时应该是其他的2-3倍，当然也要看具体的需求。
根据前面的价值和成本评估，我们可以生成一个四象限，可以看到左上角的应该优先级最高，就是价值越高、成本越低的，付出更少的资源成本可以实现更高价值的需求，这个就是最优先的，相反，右下角的就是最低的了。
注意：有的项目中，尤其是乙方项目，还需要把需求优先级和甲方沟通，把排期计划同步给他们。
再排好需求优先级后，就可以跟进优先级高低进行产品方案设计、PRD文档撰写和需求评审。在这里因为不同的项目，产品方案不同，我就不具体阐述了。
需求评审后，产品和前端、后端、测试、UI设计师（有的需求可能不需要）需要一起定一个具体的排期计划。
需求跟进主要包括设计、研发进度跟进；解答设计师或者研发、测试的一些问题
在这里我觉得分为两步：
第一步：上线前的验证
第二步：上线后的验证，可采用数据分析、用户回访等方式验证。
本文由 @y先生 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。