马斯洛将人类需求阶梯从低到高按层次分为五种,分别是 生理需求、安全需求、社交需求、尊重需求和自我实现需求。可以概括简洁的需求定义:

产品经理如何正确定义产品需求-鸟人网

需求是一个人,在某个场景下产生的欲望或者是情愫。

 

1、需求来源

作为产品经理,每天都在接触大量的需求,需求来自五湖四海,可能是做运营的、做销售的、做售前的、目前我公司大部分需求是来自业务方,业务方大部分是非产品和技术背景,对很多需求的理解有偏差。

我们的业务方不知如果表达和陈述一个需求,大多数说就抛给我们一句话:“我想做一个商城”或者“你按照滴滴那个软件做个一模一样的多少钱”。(保持冷静,他是掏钱的!)在工作中我会经常问客户,你要不要这个功能,这个功能需要吗?这种沟通方式其实是无效的。作为产品经理要相信自己的产品设计能力,站在业务方的角度去考虑产品,去引导产品的设计。业务方提供的方案仅作为参考。

2、需求判断

拿到产品需求后,首先考虑的不应该是功能,而是为什么是这个需求,实现方式为什么是这种,换一种实现方式可以吗?这个需求解决了在什么场景下帮助了哪些群体解决了什么需求。我们要对业务方提出的需求有辨别真假的能力。有的需求是真的,有的需求就会是伪需求,那么我们怎么识别需求的真假? 举个生活中的列子: 过年我小外甥在我家住了几天,在风和日丽的那一天,我在客厅吃草莓。 我小外甥跑过来给我说“我渴了”, 我记得我姐刚给他倒了水啊! 没喝饱? 其实他的真实需求并不是想喝水,他的真实需求是想吃草莓。细化到不同场景这个表面需求背后的真实需求就是不同的,在产品设计拿到的需求其实也是一样的道理。去分析这个需求,深度去分析挖掘真实需求,来判断这个需求到底是不是个伪需求,如果是伪需求,一般我们会多次与业务方沟通确认需求。

3、需求优先级

当我们确定需求时,我们就会把这些需求按照优先级一件一件的去完成,毕竟鱼和熊掌不可兼得。定义需求优先级的五种方法

1、KANO模型法:基本需求>期望型需求>兴奋性需求

2、矩阵分析法:重要且紧急>重要不紧急>紧急不重要>不重要不紧急

3、满足核心用户需求的优先级(二八原则)

4、满足核心业务的需求

5、投入产出比:花最少的时间、最少的开发资源、最少的预算完成开发功能并获取更多的用户,赚取更多的钱。

在项目中一般会着重考虑这个需求的开发难度、实现方式、开发工期、功能预算多维度去衡量一个需求的优先级(如果遇到拿捏不准的需求难度,会去找相关的技术大哥沟通方案和想法),通过这个需求优先级让我get到一个项目救急处理情况。往往马上到项目交付期了,开发大哥还有很多功能没有完善,一般我也会采用这种方式,先满足基本的业务流程,业务流程可以走通,不能出现重大的BUG。先处理那些重要且紧急的功能,最后再处理细节功能(开发大哥能不能给点力!!!)产品经理如何正确定义产品需求-鸟人网

4、需求评审

需求评审一个神奇的会议,不知多少产品死在了需求评审会议上,需求评审就是一场撕逼大战。噼里啪啦就是一顿怼啊。

参会人员:

产品经理、设计、开发、测试、运营

需求评审目标:

1、明确需求背景和目的,统一思想,听指挥。

2、明确工作任务分工和确定实现方式。

3、合理安排开发进度,做好开发节点,明确项目交付时间。

需求评审常见问题提出:

开发:

这个功能按你说的实现方式实现不了,开发成本太高,可以换个实现方式吗?

你考虑清楚了吗?真的要这样实现?

还有一种情况你考虑到了吗?

你确定你理解客户的需求?怎么听着这么奇葩哪?

设计:

这原型真丑(一句话总结 简单而又扎心)

运营:

等项目上线我再找你(小声嘀咕)

需求评审防怼指南:

1、提前确定好相关的开会人员,确定好会议时间以及会议地点。

2、准备好需求文档、原型等相关资料(可打印带到会议室)。

3、沟通表达一定要到位,先讲需求背景、用户与需求、功能模块。

4、如有技术难点,先去找相关的技术大哥讨论解决方案。这样不会因为一个功能在项目会议上耽误太多的时间。

5、在项目会议中,大家站在的角度不同,看待这个项目的出发点就不一样,技术着重业务流程、数据流向。设计着重用户体验和页面跳转。

6、如存在争议问题,会议中并没有解决一定要记录遗留问题并记录在案。

7、带着刀(生命诚可贵,且行且珍惜啊)

5、需求落地

需求评审完成后就进入开发阶段,在开发阶段我们持续跟进项目进度。不断优化产品方案直到完成项目交付。但并不是所有的项目都是那么顺利完成,往往你拿到的项目和你预期的项目差距很大,这时候就会出现技术和你扯皮,这个功能你当时就是这么要求的,这个流程和你确定过的。 口说无凭没必要的争吵会让人很疲倦,那么这个锅一般都是产品来背。所以在开发期间或者开发前我们会将具体的需求实现落实到具体的开发人员(包括需求实现方式、时间节点、工期)如有需求变更或者改动也会更新记录。这样保住了性命更对项目是一种责任。

以上仅是个人工作和学习记录,肯定会存在问题遗漏或考虑问题不够全面,还恳请各位大佬批评指正。