您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
拒绝不靠谱的需求:怎样确定需求才是正确的?
 
作者:@不羁   来源:人人都是产品经理   发布于 2015-11-26
   次浏览      
 

产品经理的工作是围绕着需求来进行的。产品经理日常的工作有:拍脑袋想需求,与用户沟通了解痛点在哪里,进行需求评审,写需求文档、画原型图等等工作。

产品经理一直做着需求相关的工作,那么应该如何正确地处理需求呢?

在产品这条路上,经过多次的挖坑填坑,我认为应该这样处理:

首先,先说明一个问题:一个产品,从前期的需求产生,到最后的产品成型,不管你前期的用户需求把握得多准确,原型图画得多漂亮,最后开发人员开发不出来,那也是白搭。所以,有关需求评审等会议需要有项目经理的参与,项目经理进行技术评估,再确定需求,这样才能保证需求提出后能够很好地实现。

需求的来源:

老板,老板是负责战略层的事务,在确定了产品的方向之后,他会对产品的样子有个大致的想象,有些功能是必须要有的,这时候,他会和大家讨论哪些需求建议加上去。

产品经理,在造就产品的过程中,老板和核心层人员已经把战略确定,接下来就是范围层具体的需求确定。产品经理需要进行基本的竞品分析对比、收集各方面的数据,然后分析得出需求有哪些。

产品运营,产品设计出来是给用户用的,而最接近用户的是产品运营人员。那么,不管是一个产品最初的诞生以及迭代,产品运营人员都应该做用户访谈,去获取用户的痛点,用户用得不爽的地方有哪些,然后列一份需求清单给产品经理进行反馈。

UI、UE、以及开发人员,业内有句话叫做“自己做的产品自己都不想用,用户会用么?”所以既然自身要设计以及开发,那么你肯定希望你的工作是有价值的,希望能尽全力去做好这款产品,如果意见能被采取,那么设计以及开发人员工作起来会积极很多,这样能让产品经理和他们更好地沟通起来,产品也会更完美。

需求的确定:

当老板、用户、产品经理、设计以及开发人员和你提需求的时候,记得给他们一份需求清单,让他们将需求填写上去,然后汇总到产品经理这里,产品经理把以上的需求清单整理在一起列成表格,以便在会议上进行统一探讨。

会议千万记得要求项目经理参加,向产品经理提供需求清单的人也尽量参加,以便更好地探讨。

会议上产品经理作为主持人,在介绍完产品背景以及产品战略上的信息后,就正式进行需求的评审。

评审之前,先在小黑板上画出表格

先列出需求,然后先让提出此需求的人说下提出此需求的原因,然后进行投票:

  • 认同:指的的关于产品需求,这个需求你也想到这个需求,和提出者想的一样

  • 赞同:之前你没想到有这个需求,但是经过他人提出后,你很赞同,在使用这个产品你会需要这个功能。

  • 不赞同:之前你没想到这个需求,虽然经过他人提出,但是你不赞同,在使用这个产品你不需要这个功能。

在思考的过程中,强调给出意见之前,站在你是一个产品小白用户的角度上,你会不会有使用这个功能的需求。

如何投票确定需求,打个比方:

会议共有9个人,有个需求进行投票表决,每个人只能投一票。

  • 认同人数加上赞同人数加起来大于三分之二,那么这个需求就确定必须加。

  • 认同人数加上赞同人数加起来大一三分之一,那么这个需求待确定,参会人员重新进行讨论,站在小白的角度上说出各自的意见,重新进行投票,此刻投票只有赞同以及不赞同两种,赞同人数超过三分之二,确定此需求,反之,则放弃。

  • 认同人数加上赞同人数小于三分之一,那么这个需求直接放弃,大家和需求提出者说下不赞同的看法以及意见。

需求的总结:

会议结束的过程中,需要专门有人在旁做会议记录,把会议过程以及最后的决策记录下来,会议后转发给参会人员,很多时候,记忆总是不如文档来得实在。

汇总的需求在会议上就已经处理好,那么对于老板特意提出的需求,你需要给一些详细的反馈了。

如果老板也一起参加会议,大家可以和老板一起讨论,很多时候老板提的需求会得不到大家的认同,是因为你没有老板的大局观,老板提的需求大部分还是对的(前提是这是经验丰富、靠谱的老板,其他另说),他可以通过他的理解给大家解释,也能说服大家,所以有关老板需求,会议上就能有结论。

如果老板太忙没有参加会议,老板提的需求通过后,在最后的需求确定都会有一份需求总结,抄送给他就可以,如果老板需求没通过,那么你需要在会议上把大家的意见和想法以及论据等等,都一一列举出来,给老板进行解释,为什么这个需求没通过,以及大家的意见都是怎样的。老板认为这个需求很有必要加,但是大家通不过,那么只能再开次会议,速度解决这个需求的决议。

最后一点,就是项目经理在会议的过程中,他是有一票否决权的,在需求的产生后,就已经涉及到了后期的功能开发,如果太过天方夜谭无法实现的需求,项目经理以纯技术的角度,当场就可以进行拒绝,老板需求也可以拒绝,任何一个需求得不到实现,那么这个需求是没有意义的。

经常出现的问题:

1、有时候开发人员对有些需求表示不理解的时候,经常看到有产品经理和开发人员这样解释:这是老板要求加的需求,没办法。

这句话意思是什么?

  • 第一,我也认为这需求不靠谱

  • 第二,他是老板,他要加我也没办法。

这句话突出了一个产品经理的无能,试问一个老板请你来做产品经理,你是专门用来做他的传声筒,还是用自身的经验看法,来用心打磨优化一款产品。

而且,开发人员也会认为你无能,在后期的沟通过程中,势必会有更大的阻力。

2、有时候产品经理拍脑袋想出的需求,然后后果一般是这样的:设计、开发人员在设计的过程中,设计师设计着页面,一边想着,这玩意,给我我也不用,开发人员撸着代码想着,这傻逼功能,谁会用啊,浪费我这么多时间做这种功能,这产品经理...

可想而知,产品经理和设计、开发人员在沟通上,会碰撞出什么样的火花。

需求是产品经理绕不过去的坎,作为产品经理都应该尽力去把需求想好、处理好。

我所举的也只是一个简单的处理方法,有其他更好方法的可以和我交流探讨。

   
次浏览       
 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]
相关文章
需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   
相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践
成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...