如何做需求分析

标签: 产品设计 产品 分析 需求 | 发表时间:2015-04-06 23:43 | 作者:人人都是产品经理
出处:http://www.woshipm.com

这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到。关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点。

     1:抓核心点,不是所有用户诉求都是需求

我们每做一个项目迭代或者新项目一定有目的,而需求分析阶段,需求采集渠道中的需求往往是零散的、无重点的、逻辑性不强的,所以我们需要从这些离散的需求点中要抓住核心,梳理实际使用场景去分析问题,所有的核心点一定是以最终目的为导向的,不是所有用户诉求都是需求。

以我的项目为例,由于历史原因,自配送人员关系没有进入OA系统,所以配送员工资结算数据只能做进配送系统,相当于是一个简单考勤记录,其实最早之前系统是有这个功能的,但是由于之前没有仔细整理需求,导致这个功能白做了,所以这次我接手几乎从做,我以为这个事情比较简单就让一个产品助理先去整理需求,当把原型图出出来时发现并不能解决结算工资的功能,只是一个简单的排班。

所以,当时我就跟那小兄弟说,你这东西只是完成了排班,然而排班的目的为了结算工资这还不能满足需求。所以我跟他强调,我们做这个需求的目的是为了考勤,诸如请假、值班、加班工时、轮休日加班等数据要能提供出来,他的第一版原型其实没有充分了解到我们为什么要做这个排班功能,所以在了解需求过程中没有抓住核心点,导致需求不明确。

      2:制定规则、改善复杂流程

我的上一家企业做的是互联网电商,其实在我看来电商和O2O有很大的区别点就是电商在当下盛行的情况下已经变的很有规则了,首页、产品列表页、详情页、下单页等等,每个页面展示的信息也大相径庭,而O2O不一样,一方面是O2O差不多13年才兴起,到目前为止(15年)还没有一个标杆行业,另一方面是O2O与日常生活联系的太紧密,落地下来就是很复杂的业务流,这些是to C产品的规则化和流程化,而流程化的东西在to B产品上体现的尤为明显,to B产品最经典的例子就是公司后台系统。

不论是一个to C的产品还是to B的产品,我们都要考虑到用户使用场景,PM需要把自己当作用户,充分考虑各种情况下的用户思维才能设计一个满足用户需求的产品,这里并不是一味的去迎合用户,做互联网的都知道当一个业务不是规则化时很难用产品去满足用户,所以我们有必要制定规则,或者优化不完善、流程复杂的

规则。

下面说说制定规则,其实统一规则有利有弊,举个例子,滴滴打车的订单是抢的,uber打车的订单是系统自动分配的,滴滴那种做法能提高司机积极性、自主性,司机可以选择高金额的订单,但是这种做法也会影响用户体验,比如说万一以后不补贴了,我只是一个起步价,有些司机就不愿意接单,要等待很久;而uber打车制定了自动分配的规则,先分配目前离乘客最近的空闲司机,如果他不接再分配给下一个,这种做法能不能满足用户我不说,我只说这种规则简化了下单流程,司机和乘客只有两个选项,接还是不接,坐还是不坐,司机如果不接,但他并不知道下一单能等到什么时候,订单金额有多大?虽然司机间的积极性和自主性减少,但是对用户来说体验很好。

说完了制定规则,再说一下改善流程,我上面说了这种流程化精简在to B产品上尤为明显,很多人有个看法就是后台系统反正是自己人或者其他企业人员用的,完成功能就行,没必要做的这么便捷和细致,其实不然,优秀的PM在这方面总能善始善终,因为在他们眼里一点点的产品优化或者流程优化能为企业带来很多的效益,这个我有切身的体会。

之前做的多个项目,其中有两个就是我在做需求的时候发现业务部门在实际运营中思维定势或者每日重复做属于他的工作,但是他们并没有发现这样做其实效率很低,在没人观察流程有问题的时候,业务部门已经形成规范,但是这种规范并不是最优的,当PM做需求分析的时候需要细致观察他们部门或者个人的工作内容,想一想为什么这么样做,有没有其他方案能提高其工作效率。

在做数据统计需求的时候我发现业务部门某同事每天要先导出所有新用户电话、订单号、餐厅金额、订单金额等数据用于考察配送员满意度、用户满意度,然而她每天导出的数据其实有另外两个同事也需要用,只是使用目的不一样,但是他们都很死板,他们三个每天导出一份完整数据,然后筛选条件,组合成自己要的数据,这种工作其实很没必要,我们可以每天为他们部门发一份当日订单报表,标注新用户即可。

还有个例子是,财务在结算物流人员工资的时候很多计算公式是相互关联的,比如说A=B+C,D=A*E+B-C,然而他们就计算成D=(B+C)*E+B-C,暂且不说他们部门管理流程怎么样,但是PM在遇到这样业务流程的时候结合产品设计考虑是否可以精简流程,实现产品设计的初衷的同时也能简化流程。

      3:离散需求整合

在和业务部门打交道的时候发现他们的思维逻辑性可能稍微差点,在PM了解需求的时候业务人员或者用户表述的没有前因后果,也就是没有逻辑性,这时如果PM不追问下去自己很容易被带到坑里面,合格的PM应该在这种情况下峰回路转,把问题再阐述一遍,如遇到稍微强势一点的PM,此时应该会指出刚才的表述有错误。

还有的业务部门人员在你去沟通的时候哗啦啦的说了一大推产品改进意见或者新需求想法,此时PM应该细心聆听,记录下需求点,千万不要给他们答复这个功能什么时候做、什么时候上线,因为系统永远是不完善的、需求却永远是数不尽的,而资源是有限的,你给的答复实现不了别人会有不好的看法,优秀的PM需要大局观,能够和团队一起评估需求优先级,规划产品生命周期,这才能推进产品迭代。

        4:技术人员参与需求分析阶段

现在很多互联网公司基本上都是产品驱动,很难说技术驱动,因为产品团队可以知道用户想要什么,我在参与需求分析过程中事业部技术负责人喜欢跟着我一起去了解需求,这在我之前的工作组中没遇到过,现在做需求的时候他参与进来后我发现整个产品需求被乱了,阻碍了我需求分析进度,因为他总是以技术的角度考虑这样实现的难度,由于他是技术负责人,逻辑思维能力很强,每当听到这个数据没有需要新增一个入口去维护时他就站出来说为什么要这样做,然后劝说业务部门说这个数据提供不了,能不能先不做。

但是从产品角度上考虑,既然选择做这个项目那么就该从产品角度去设计好,等一整套产品方案出来之后再去精简功能是一个很好的方法,还有一些情况是当有一个比较好的idea产生时技术人员会首先考虑能不能实现、实现的复杂度,如果有一点困难或者技术可行方案不能当场给出时,这个功能就暂且搁置了,也许就会提出另一个不会错但是并不是最好的方案,所以技术人员参与需求分析阶段最容易把原本一个好的产品扼杀在摇篮之中。综上考虑,我的理解是技术人员在需求分析阶段暂且不要参与进来,等产品团队内部讨论之后技术团队参与审评,这样也许能达到事半功倍的作用。

本文为作者张辉投稿发布,转载请注明来源于人人都是产品经理并附带本文链接


互联网从业者必备微信公众号:woshipm,如果你已经关注了,证明你已经很牛逼了。

相关 [需求分析] 推荐:

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.

需求分析中的产品定位

- Jessica - 所有文章 - UCD大社区
看过《定位》最大的感受就是产品在诞生之前就决定了他是否能存活或成功. 就像走在商场中,面对玲琅满目的产品,你似乎很难找到一两款绝对同质化的大品牌:. 各式的服装,NIKE的衣服是运动的,但也不会和做户外运动的哥伦比亚冲突. 都是做化妆品,Fancl打出“无添加”没有防腐剂也收获了一群喜爱天然的用户…...

框计算中的需求分析概述

- Michael - 搜索研发部官方博客
框计算的目标是为用户提供基于搜索框的一站式搜索服务. 举例来说,当用户在搜索框中输入“非诚勿扰”时,系统就能明确该query有寻求电视节目视频、电影视频、查找影评、参与讨论及查看相关新闻等需求,然后将这些不同的需求分配给最优的内容资源或应用进行处理,最终精准高效地将满足这些需求的结果展现给用户. 图1展示了“框”对query“非诚勿扰”的满足情况.

需求分析挑战之旅——疯狂的订餐系统

- Bloger - 博客园-首页原创精华区
说教性质的需求分析理论,各位看了也白看,所以咱们就来一个真实个案——“订餐系统”体验一下. “订餐系统”貌似简单,但陷阱重重,各种需求分析的经典场景将会一一重现,各位做好准备接受这个挑战没有. 本文文字超过1万1千字,而且有n多图片和思考题,请准备好盒饭边吃边看吧……. 如果觉得看文章麻烦,可看本文对应的视频课程:http://www.cnblogs.com/umlonline/archive/2011/07/20/2111430.html.

产品需求分析:用户的“奶酪”不要碰

- paaboo - 所有文章 - UCD大社区
花了差不多2周时间去研究了卖猪肉的商贩,当和行业内朋友谈及这个形象的范例时,他们满是奇怪表情,因为一个做互联网产品的人,不好好做的你的产品,去研究卖猪肉商贩干什么. 先别急,我们都知道产品需求分析是一个产品经理必修课,其实就是在项目立项之后需要把抽象的产品概念及用户业务核心需和内部的发散性的功能点集中并提炼出来并形成一个具体可见可演示的成果.

互联网社会化系列之网民的需求分析

- - 互联网的那点事
网民的需求是互联网创新的基础,在互联网社会化的大背景下,网民的需求与时俱进,希望能就此背景下得网民需求进行一个框架性的讨论. 互联网在社会化之前,网民获取资讯内容的方式是访问各大门户网站,论坛以及通过搜索引擎,网民们需要主动访问来获取自己所需的资讯内容. 一般是有价值的资讯在哪里,网民就往哪个网站汇集.

2012.5.23微博热报:需求分析、性能调优

- - InfoQ cn
@阿里巴巴中国在 微博中举了一个对设计花瓶的需求分析示例,引起了大家对需求分析技巧的讨论; @左耳朵耗子在 微博中表示性能调优不一定要自己使用缓存,因为许多层面已经设计了缓存机制. @阿里巴巴中国在 微博中举了一个例子:“需求方说:帮我设计一个花瓶. 小A肯定做出了花瓶,但是未必是顾客想要的.

需求分析:挖掘最根本的欲望

- - TECH2IPO创见
心理学上对欲望的解释是由人的本性产生的想达到某种目的的要求. 在这个定义里有两个关键词:本性、目的. 它指出了欲望的源头,是由人的本性产生的,是一种本能,人人皆有. 同时也指出了欲望的产生原因,是为了达到某种目的. 举个例子,吃饭,这是一项最基本的生理欲望,每个人为了生存必须要吃饭. 我们有微波炉,电饭锅等等很多可选择的工具来帮我们做饭,甚至,做特殊的食物有专用的工具提供给我们,比如面包机.

如何开展软件架构之需求分析

- - CSDN博客架构设计推荐文章
如何开展软件架构之需求分析.  在开始讨论如何开展软件架构之前,先让我们来看一张漫画. 相信大家看到这漫画的时候,总会不自主地会心一笑,客户希望得到礼物,我们却给了他一骨头. 一):未进行充分地需求分析. 解析:架构师未能初别用户群及使用环境约束因素,也许在接到项目时,他还在想着上一个为狗开发的项目,在这个项目中自然而然地认为用户是狗.