产品需求_产品需求分析 - CSDN
精华内容
参与话题
  • 用户需求和产品需求

    千次阅读 2018-12-15 17:25:31
    这句话说出用户需求和产品需求的区别,也说出了产品经理存在的意义: 那就是从用户需求中找到用户真实的需求,转化为产品需求找到解决方案,再提供给用户。   用户需求和产品需求 首先我们先来了解下用户需求和...

    业界内有一句话说:用户跟福特要一匹更快的马,福特却给了用户一辆车。

    这句话说出用户需求和产品需求的区别,也说出了产品经理存在的意义:

    那就是从用户需求中找到用户真实的需求,转化为产品需求找到解决方案,再提供给用户。

     

    用户需求和产品需求


    首先我们先来了解下用户需求和产品需求的概念。

    用户需求:用户自以为的需求,并且经常表达为用户的解决方案;

    产品需求:经过我们的分析,找到的真实需求,并且表达为产品的解决方案。

    所以需求分析的实质就是从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需求的过程。

     

    举一个例子:

    之前项目中有一次客户要求我们把工具栏放到页面的顶部(用户需求),

    其实在我们这类系统里,常规的放置方法是将工具栏以图标形式镂空放置在地图之上,

    更改工具栏的位置工作量上来说并不大,但是很不符合一般人的操作习惯。

    于是我就和他沟通,了解为什么要这么做。

    交流后才知道是他觉得页面顶部没有内容,看起来觉得太空(真实需求),

    后来我联系美工在页面顶部加上LOGO,以及做了一些背景图片,顶部右侧添上用户管理和退出的按钮,(解决方案)

    就这样客户最后也满意了,我们也没必要将系统改成个“反人类”的版本。

     

    这是一个很简单的例子,但也是说明了一个道理:

    我们要听用户的,满足他们的需求,但不是就要照着他们说的做。

    用户在提需求时候,往往会带有他们的解决方案,而这个解决方案因为用户自身的局限性,

    比如用户是个业务专家,但对软件系统不了解;

    比如用户仅从自身角色出发,提出一个适用面很窄的用户需求;

    或者用户本身“审美”就有很大的问题等等。

    此时就应该发挥我们的作用,和用户交流,发现他们的真实需求,

    然后根据真实需求找到解决方案,反馈给用户,

    或者如果我们本身就有相应产品解决方案时候,引导用户采取我们的解决方案。

     

    伟大的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给出更好的解决方案。

     

    项目和产品


    销售人员经常说:用户是为想要的东西买单,而不是需要的。

    换句话说就是用户是为自己提出的解决方案买单,而不是我们的解决方案。

    也就是我们赚的钱是从项目里来,按照客户提出的用户需求来做就行,为啥还需要进行分析呢?

     

    这其实就是项目和产品的区别。

    项目很简单,就是用户有了某个问题需解决,然后我们根据用户要求解决了这个问题,用户给了我们报酬,这就是项目。

    产品源于项目,毕竟做产品也是为了解决用户的需求,但产品需解决的一类用户最核心的需求。

    产品的周期一般来说都很长,成立时候一般都来源于一系列相关项目的整合,

    从某类业务的项目里提取出核心的产品需求,并给出解决方案。

    之后遇到同类项目时候,就从产品出发,根据项目实际情况稍作修改,就能给出项目的解决方案,

    然后再根据项目的情况,不断完善产品的解决方案,使得产品不断迭代、更新,能解决更多、更难的问题。

     

    而项目和产品的区别对企业来说就是一个短期利益和长期利益的区别。

    如果是一锤子买卖,卖出以后又不用售后,那么不妨用户用什么就给他什么,这样他掏钱最爽快,你也省心。

    典型的代表就是各种外包公司,不断地承接各种项目,用户说啥我就做啥,最后按期交工即可。

    这样公司的盈利模式就是线性模式的,一份时间,一套解决方案卖一份得钱。

    而另一类公司的盈利模式则是指数型的,开发一套产品,然后可卖给多个客户,规模化获利。

    比如某云平台厂家,在完成产品研发后,后期主要就是运营推广以及个性化定制服务,

    将一套云平台产品卖给多个用户,自然而然长期利益就更高。

     

    所以对于期望追求长期利益的公司,拥有自己的产品是非常必要的,做产品需求也是非常必要的。

     

    二手需求


    作为一个需求人员,在真实研发过程中,很多时候我们并没办法接触到真实的用户。

    我们参与到的产品可能会是比较成熟的老产品了,而我们的需求来源可能是销售人员,也可能是老板。

    并且提出的需求可能是几句口头上的话或者一封简单的邮件,这中间理解的偏差只能通过我们主动的、反复的沟通来弥补。

    遇到这种情况怎么办呢?

     

    首先我们应当了解需求来源,知道需求提出者是哪个公司的、哪个部门的,什么职位的人。

    因为对于一个产品而言,不同部门、不同职位的人思考的角度是不一样的,我们得把这些信息记录下来方面我们理解为什么用户会提这样的需求。

    比如销售人员,他们考核的指标就是把产品卖出去,卖点越多越好,至于之后的用户用得如何,他们并不关心;

    比如运维人员,他们关心的是产品的运行情况是否稳定,希望产品出的故障越少越好。

     

    然后对于需求的描述,将所有主观修饰的词语去掉,

    需求的描述尽量使用主谓宾的语法结构,对于形容词尽量定量地进行描述。

     

    最后就是站在用户的角色来思考问题。

    不妨拿到需求的时候,假设自己就是用户,然后问自己这样几个问题:

    我是谁?我为什么提这个需求?我在什么时候什么场景下遇到这个需求?我用这个需求解决什么问题?

     

    也就是传说中的5W1H法,

    即弄清楚了5W(who、why、when、where、what),才可能知道怎样(how)去解决这个问题。

    作为产品经理,首先就是要重视用户需求的收集,

    只有在充分理解用的需求之后,才有可能把用户需求转化为产品需求。

    展开全文
  • 文档历史记录 编号 日期 版本 描述 作者 审阅者 ......

     

    文档历史记录

    编号

    日期

    版本

    描述

    作者

    审阅者

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    注:后期所加内容均绿色背景字体标注


     

    1.产品概述 3

    1.1 目标&意义 3

    1.2 领域知识 3

    1.3 思维导图 3

    1.4 业务流程图 3

    2 功能范围 4

    2.1 教师入职 4

    2.1.1 功能说明 4

    2.1.2 用例说明 4

    2.1.2.1 用例图_新增教师 4

    2.1.3 操作流程 5

    2.1.3.1 转正审批流程 5

    2.1.4 界面原型 5

    2.1.4.1 教师管理-教师查询 5

    2.1.5 对应字段 5

    2.1.5.1 基本信息表 6

    2.1.6 相关规则 6

    3 词汇表 6

    4 非功能需求 6

    4.1 规则变更需求 6

    4.2 产品服务需求 6

    4.3 帮助需求 7

    4.4 安全性需求 7

    5 上线时间安排表 7

     


    1.产品概述

    说明:<简单描述项目的背景、意义、目的、目标等,描述领域知识>

      1. 目标&意义

    <项目目标>

     

    <项目意义>

     

      1. 领域知识

    说明:<包括:项目涉及到的业务背景、业务知识、业务词汇解释。>

     

      1. 思维导图

    <整个产品功能思维导图>

    X-MIND

     

      1. 业务流程图

    <整个产品涉及业务的整个流程图>

    泳道

     

    1. 功能范围

    <主要功能描述>

     

      1. 教师入职
        1. 功能说明

    <描述功能的作用>

     

        1. 用例说明

    <编写业务用例,即按照真实的用户业务划分用例,记录人机交互过程,完成用例描述>

     

          1. 用例图_新增教师

    用例概述

    业务描述

     

    需求描述

     

    行为者

     

    前置条件

     

    后置条件

     

    其他说明

     

    业务规则

    序号

     

    1.  

     

    用例

     

        1. 操作流程

    <描述该部分功能的业务流程>

          1. 转正审批流程

     

        1. 界面原型

    <粘贴所有跟该功能相关的界面原型>

          1. 教师管理-教师查询

     

        1. 对应字段

    <描述页面上相关字段,而不是操作字段>

          1. 基本信息表

     

        1. 相关规则

    <描述跟系统实现相关的业务规则>

     

    1. 词汇表

    <定义系统中的词汇,解释词汇含义,整个文档统一词汇名称>

     

    1. 非功能需求
      1. 规则变更需求

    可能变更的系统规则

     

      1. 产品服务需求

    产品设计需要提供的附加人为服务

     

      1. 帮助需求

    需要提供的帮助信息

     

      1. 安全性需求

    需要提供的安全性信息

     

    1. 上线时间安排表

    分解项目任务,制定上线时间

    展开全文
  • 记得自己在学习PRD文档撰写的时候,总希望能找到一份比较全面详细又易懂的模板。如果你也曾有相同的困恼或者尚未遇到满意的答案,或许本文可以提供不错的参考...不同公司、不同团队或产品对PRD文档的要求不同,不同...

    (转自:http://www.chanpin100.com/article/101751

    记得自己在学习PRD文档撰写的时候,总希望能找到一份比较全面详细又易懂的模板。如果你也曾有相同的困恼或者尚未遇到满意的答案,或许本文可以提供不错的参考。

    (往下阅读之前,希望能先思考一下:为什么需要写PRD 文档?欢迎评论讨论)

    惯例,还是先甩图

    不同公司、不同团队或产品对PRD文档的要求不同,不同PM的撰写风格也各有所异,本文力求全面而简洁,仅做简要概括。

    这样写prd,哎哟不错哦

    简书,在我看来长这样

    本文“简书”移动端为例,按照上图的总结写一份简单的PRD文档框架,希望能帮助同为“简书”用户的大家更好地理解。(PM菜鸟一枚,简书新用户,重文档轻分析)。

    1、版本信息

    简书APP版本信息表示意图

    2、文档说明

    2.1 文档简介

    本文档主要描述简书APP的功能需求点及其设计,目的在于清晰地定义各模块的需求细节及逻辑流程。

    2.2 文档读者

    本文档主要面向以下读者:简书APP项目的研发人员、测试人员、产品经理、市场运营人员、管理人员等。

    2.3 专业术语

    可在此提前交代一些专业术语以方便后文理解(通常以表格形式),也可见附录8.4

    目录(略)

    3、产品简介

    3.1 产品定位

    简书致力于提供最好的分享体验,为写作者打造最优秀的写作软件 ,为阅读者打造最优雅的阅读社区。“交流故事,沟通想法”是简书的slogan。

    3.2 产品特色

    简单优雅的设计、良好的交流氛围、丰富的文章主题、Mardown富文本等特色功能

    3.3 用户分析

    主要用户为喜欢分享交流、爱生活拥有文艺气息的年轻人,喜爱文字并想在喧嚣网络中沉淀文字的读写人。

    4、产品架构

    4.1 产品结构图

    此文仅述主要模块,应展开至最小用户可见单元。

    简书APP产品结构图

    4.2 信息结构图

    信息结构以信息为维度,比如用户信息,用户文章信息,用户行为信息等,与产品结构可对应分析,不再陈述。

    4.3 总体流程图

    总体流程可说明产品的基本的用户行为路径,有助产品理解。

    简书APP总体流程图

    5、详细功能说明

    5.1 功能列表

    功能列表作为功能需求说明的总览,可分模块描述。

    简书APP功能列表示意图

    5.2 原型界面

    每一个模块功能的需求说明都应该包含详细的原型界面图及流程图,此作简单示意图(重置密码)。

    简书APP重置密码原型示意图

    5.3 用例流程

    简书APP重置密码流程图

    6、非功能性需求

    6.1 性能需求

    1、前端内容展现应保证用户在WIFI及移动网络下阅读体验流畅;

    2、万级用户在线时后台信息处理稳定且快速等等。

    6.2 系统需求

    兼容Andriod、IOS各系统版本(包括最新版本)

    6.3 运营需求

    用户/内容管理系统开发、用户数据分析系统开发等

    7、项目规划

    有的项目或产品并不包含该部分,但通常要交代产品的风险分析及应对策略。

    8、附录

    大量的相关参考文档可放置附录,以避免篇幅过长影响阅读。通常包括原型/UI文档、MRD/BRD文档、技术文档、专业术语。

    至于,一篇简单的产品需求文档雏形就有了。再次强调本文旨在提供PPR文档模板的一份参考,你对开篇的思维导图有印象就足够了,希望对你有所帮助,可喷可讨论,谢谢~

    *著作权归作者所有,转载请联系作者获得授权。

    展开全文
  • 产品需求

    2018-08-25 17:10:22
    换句话说,从公司的本质出发,一家公司没有理由去做一个没有目标群体没有需求产品,哪怕只是内部的技术预研也是有切实需求推动的,哪怕只是公司年会上用的小程序也是有需求推动的,又哪怕是对用户免费运营的产品也...

    产品从何而来,什么叫产品?

    产品是厂家为了满足目标群体的需求而生产的成品。换句话说,从公司的本质出发,一家公司没有理由去做一个没有目标群体没有需求的产品,哪怕只是内部的技术预研也是有切实需求推动的,哪怕只是公司年会上用的小程序也是有需求推动的,又哪怕是对用户免费运营的产品也是会有需求推动的,因为没有需求就代表没有人会需要,没有需求就代表产品没有生产的价值,没有需求就代表一个产品生命周期的终结。

    个人觉得产品的需求有三种类型:

    显性需求:

    就是客户能够明确告诉你的内容,很经常我们去做需求调研时就是拿着纸和笔记下:XX客户要什么、什么和什么,回头就开工做了。这种在一些简单的场景下可能适用,但随着信息化程度越来越高,客户IT水平和实际要求越来越高的情况下,就需要去挖掘潜在需求。为什么?因为当你还在等着客户说什么你就做什么的时候,你的客户早就投向能够挖掘到他们潜在需求的竞争对手那去了。

    如果只是做到了这点,那么你还远远不够,对客户而言这就是没有创意的公司,因为做什么怎么做都要客户告诉你,没有市场竞争力。

    潜在需求:

    之所以叫潜在,就是它不是由客户告诉你的,而是由你在需求开发过程中挖掘出来的。由于各种原因,潜在需求可能客户自身没有意识到,或者他知道但就是不和你说,所以挖掘潜在需求是个“技术活”。比方说,你问客户“这个系统并发数要多少?”客户:“并发数?那就越大越好吧!”   但换种提问方式呢?“我们” 我们这套系统有多少人需要用,什么部门的人在用,他们分工如何?“这种问题客户就会回答了”有2个部门使用,每个部门大概30号人,A部门负责A业务,B部门负责B业务“,这样我们就可以分析得出:”A、B业务涉及的模块可能需要30的并发量“。(这个例子很丑陋,但主要为了说明这个问题,真要举栗子一天都举不完)。

    如果你总能挖掘好客户的潜在需求,找到用户真实的痛点,那么你的产品将会很对客户的胃口,这将保证你在竞争中保持优势。

    未来的需求:

    关于未来,那是一个谁也不知道会发生什么的领域,甚至客户自己都没有概念,但假设你有能力发现未来可能产生的需求,那么恭喜你,你将引领潮流,带来行业变革,成为行业领先,就像苹果、摩拜单车、淘宝网一样,甚至客户都会成为你的粉丝。但这个很难,除了需要惊人的决策能力、还需要科学家般的思维,毕竟当年只有马车的时候,有几个人能想到未来会有汽车?

    当然,这也不是完全没有可能,像马斯洛需求层次理论说的,人们在满足当前层次需求的时候才会出现个更高级的需求。而我们在当前满足客户需求的条件下,不妨多去想象:下一阶段客户会想要什么,甚至我们能把客户引导成我们想要的样子。

    展开全文
  • RICE/MoSCoW/Kano三种模型,教你如何对需求进行优先级排序。 如何确定优先级是设计产品路线时常见的挑战,如果你已经花费很大精力去做头脑风暴、寻找改进的机会点和收集反馈,你会得到一个充满好主意的产品演进路线...
  • 需求分析师和产品经理的关系

    万次阅读 2018-01-31 16:25:27
    关于需求分析师和产品经理这两个职位,我问过很多人,大家基本上都没有特别清晰的概念。要么就认为产品经理涵盖了需求分析的工作,要么就认为有需求分析就不在需要产品经理。经常浏览招聘网站,也很少看到某公司会...
  • 如何写好一份产品需求文档

    万次阅读 多人点赞 2017-01-24 15:53:00
    如何写好一份产品需求文档 PRD写得好看还不如需求把握得准确,PRD写得好看还不如体验设计得顺畅。 工欲善其事必先利其器。 产品需求文档(以下都简称PRD)对于大多数产品新人来说都并不陌生,它是产品工作中...
  • 业务需求、用户需求和功能需求

    万次阅读 2017-03-06 10:44:42
    我们的软件产品或者项目,其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求 (Business requirement)表示组织或客户高层次的...
  • 需求文档(PRD文档)

    万次阅读 多人点赞 2018-03-05 22:11:21
    产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过...
  • 在软件界来说,好像产品经理天然就是程序员的头号公敌。原因基本上就是需求的变更。产品经理有时候会觉得自己很委屈,因为有些东西是客户要求变更的。对程序员来说,技术只是实现需求的一种手段,需求的实现才是终极...
  • 1 需求管理流程产品需求管理有需求采集、需求分析和需求筛选几个阶段,经过这几个阶段之后才会进入立项的阶段。 需求管理流程图2 用户研究方法需求采集主要是从用户的角度进行需求的采集,横向看,用户有说和做...
  • 软件需求分析——非功能性需求

    万次阅读 多人点赞 2019-05-17 16:41:39
    前言:需求分为功能需求和非功能性需求,常常会因为注重功能需求而忽略了非功能性需求,以下是对常见几类非功能性需求的小小总结,以后再慢慢补充。 非功能性需求 1、定义:软件产品为满足用户业务需求而必须具有...
  • 功能性需求和非功能性需求

    万次阅读 2018-12-05 14:22:18
    功能需求 (functional requirement规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求 (behavīoral requirement),因为习惯上总是用“应该”对...
  • 产品需求文档到底该怎么写?

    万次阅读 2016-05-14 10:33:30
    博主作为一名产品小白,也被产品需求文档折腾的死去活来,网上也难找一个完美的模板。那么,作为产品需求文档,到底该怎么写,才能让设计让开发都能清晰的了解呢? 产品需求文档,主要目的是说明需要开发的产品功能...
  • 需求挖掘的十三种方法

    万次阅读 2018-12-05 19:01:28
    很多刚入门的产品经理都会将大量的时间放在产品原型上面,以为画好原型就能够胜任产品经理的职位了。而我们也经常能够在一些产品经理的招聘中任职要求中写着:“熟悉使用Axure、Mindmanager、Viso,能够单独画产品...
  • 如何做需求分析

    万次阅读 多人点赞 2018-01-31 16:33:57
     需求分析的目标是将产品需求功能梳理,并且用通俗易懂的文字描述,为开发人员和测试人员提供依据。那么需求的分析梳理细化,直至成文这个过程,就是需求分析师的主要工作内容了。 需求一般分为四种
  • 软件工程之需求分析

    万次阅读 2006-09-07 09:53:00
    现在人们越来越认识到软件工程在软件开发中的重要作用。目前国内软件在开发中还没有对软件开发的过程进行明确规定,文档不完整,也不规范,软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。...
  • 我们的软件产品或者项目,其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次 软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求(Business requirement)表示组织或客户高层次...
  • 如何做好需求测试

    万次阅读 2018-02-14 09:57:13
    如何做好需求测试软件行业中什么是需求? 简单的说需求就是产品经理(市场)要求软件必须完成的事务以及必须具备的基本功能。 很多开发会说永远不要相信产品经理 – 其实因为市场在变而不断变动。 所以需求的轨迹...
  • 需求获取的几种方式

    万次阅读 2014-10-17 10:20:30
    日常需要做新的产品或者新的项目的时候,总是愁苦该去哪里获取到足够多的原始需求,闭门造车显然不是最好的方式,那样会使产品带上浓重的个人主义色彩。其实一般有新的项目需要上马,至少总会有个愿景,根据这个再去...
1 2 3 4 5 ... 20
收藏数 719,560
精华内容 287,824
关键字:

产品需求