您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 需求管理 > 正文

需求是什么与需求收集

发表于:2017-08-07 作者:史蒂分孙 来源:

  前言
  在团队中,发现很多pm把“用户需求”时常挂在嘴边,似乎有了这个词就有了庇护自己所设计的功能的“尚方宝剑”。如果把该“用户需求”单独拿出来看,可能无可厚非,但是否要实现该需求,为什么实现这个需求而不是实现那个需求,又似乎很难有充足的理由。在此我仅把自己所发现的实际团队中的问题做一些不成熟的思考。
  一、“用户需求”不等同于“产品需求”
  “用户需求”我们不应该尽量满足吗?当然应该。但首先应该明确“用户需求”和“产品需求”。“用户需求”是产品可能的目标使用者(可以称为“产品用户”)所提出的任何改善产品的意愿。“产品需求”是产品的关键人(可以称为“产品关键人”)对产品的意愿。比如企业老板、公司大股东、市场部门都是产品关键人。
  比如:需求1:用户提出希望实现产品功能A
  需求2:研发部门评估认为实现功能A需要1个月的周期
  需求3:市场部门希望在2周时间内产品上市
  需求4:老板希望尽可能的降低研发的投入费用
  需求5:销售部门希望产品上市后有足够的竞争力
  很明显,以上的几个需求只有“需求1”是“用户需求”,其它都是“产品关键人”的需求。产品关键人不是产品的直接使用者,但决定这企业资源的投放方向,对产品起到至关重要作用。
  所以,“用户需求”仅仅是“产品需求”的一部分,用户需求和产品需求之间往往是一种相对矛盾的关系,产品经理的工作实质是“在用户的需求和产品需求(企业能提供的资源)间找到一种平衡”。作为产品经理,不是只把“用户需求”挂在嘴边并不计投入的满足,因为是要付出成本的(企业资源),尤其是对于中小企业。那么,哪些需求要满足哪些不满足,这就是涉及到需求收集和需求筛选。
  二、不重视日常需求的收集
  上文提到了“需求收集”,在这个环节,团队中发现的主要问题如下:
  每个产品经理都知道需求收集很重要,但实际工作中又往往不注重记录下获取的各种需求,以便产品设计或迭代时参考。最常见的情况一是认为获取的需求很简单,不值得记录,认为即便不记录在产品设计时也会考虑到该需求。二是认为获取的需求不是产品设计能直接解决的(这种需求往往是非功能性需求,比如对性能、价格、渠道的需求等)。
  以上的两种思想导致把各种可能的需求都漏掉了。作为产品经理应该尽可能全的记录任何需求,首先产品设计和需求记录的不一定是一个人,即便确实是很简单的需求对于产品设计也是有益无弊的。其次产品不是简单的基于功能的技术实现,而是渠道、价格、市场、技术、运营、售后等的综合体现,所以任何需求都是可能影响产品的因素。
  三、不注重阶段性整理需求
  以何种方式记录需求?不少人喜欢以简单的方式进行记录,比如word、txt、excel、脑图等,这些方式都没有问题,但实际情况往往是只图每次记录的便捷,而忽视阶段性的对这些需求进行整理归类,于是在正式需求讨论时面对的是一对各种不同格式、表述模糊(经过一段时间可能自己都回忆不起当时记录的是什么意思)的文档。这极大的浪费了需求筛选的时间和质量。所以一定要定期整理需求,把需求进行归类并把描述不清的需求尽量表述准确。
  在此,仅把个人的记录需求的方式表述如下:
  1、以“单项需求卡”的形式记录各种来源的需求
  需求采集的方法有用户访谈、问卷调查、可用性测试等等,个人习惯于把收集的各种需求以“单项需求卡”的方式进行记录。如下图:

  每一项需求都记录为“单项需求卡片”,文件名后面的“已记录”代表该需求已经记入《产品功能列表》中了。具体内容如下图:

  以上的“问题提出者”和“用户问题描述”用于记录用户提出的问题,问题经过我们的分析记录在“解决方案”中,描述如何解决用户的问题,最后进一步分析出问题所代表的“用户实际需求”。这个“用户实际需求”就是最终要记录在《产品需求列表》中的需求。
  那么为什么不直接把以上的表格转换成Excel的方式进行记录呢?第一、Excel不好记录图片;第二、单项需求卡有利于持续的记录不同老师对同一问题的描述,也就是说以后更容易追溯从“问题->解决方案->用户实际需求”的演化过程。作为产品经理,要尽量能做到有理有据的说明问题,所以要对中间的过程进行必要记录,而不能仅仅为了快捷直接记录结果,而最终导致无据可依,靠打嘴架解决问题。
  2、将“单项需求卡”中的需求汇总为《产品需求列表》中
  单项需求卡片的需求可汇总为《产品需求列表》,如下图:

  其中的“产品需求说明”就是“单项需求卡片”中的“用户实际需求”的内容,“解决方案”就是“单项需求卡片”中的“解决方案”的内容。
  这样持续不断的记录和定期整理需求,最终的《产品需求列表》是后续工作的依据

 相关文章