浅谈我对产品需求与软件需求的理解——来源于我的求职面试经历

     今天面试时，被提问对产品需求如何理解，当时我就有点蒙了，心里想产品需求不就是用户想要什么，然后对它进行分析吗？然后我就随性地说了一通，这令面试官很不满意。但是，我确实是凭空理解的，没有深入去思考这个问题。

      回寝后，我一直在想这个问题，上网查找了一些资料，比如人人都是产品经理，才发现原来产品需求分析的知识还是非常深的，而我只是粗浅地认为是分析简单地调研分析，这并没有什么特色。

       我自己重新整理和总结：

       一、需求的理解

       1.需求是什么？

       通俗地说，每当你想到“如果这样就好了”，这便是一个需求。

       比如，你饿了，你脑子里想“要是有饭吃就好了”，这就是一个实实在在的物质需求。

       2.需求分析是什么？

       其实就是对需求的理解或解读，当然跟理解的层次有关，对需求理解不同，导致的结果是不一样的。

       比如：上面饿了想吃饭这个解读，你可以简单理解为饿了想吃米饭，也可以进一步理解：饿了，这个用户是想吃什么样的主食（面条、饺子、玉米、白米饭等），就需要去分析这个用户的出身背景（比如哪个地方的人，当地口味是怎么样的）以及留心他平时的习惯（比如他的口味是什么样的）等。

      用户想要找东西——找到更符合要求的东西——推荐给他他所关注的东西——好东西推荐给好友。

       这边是用户需求逐步深入挖掘的典型案例，由最初的用户想找某一个东西，到最后好东西共享好友，让好友方便找东西，做到信息共享。

       当然用户在提出某一个需求想法的同时，也会提出自己认为正确的解决方案，但是这个方案并不一定就是我们可实现的产品原型。聆听用户需求，深度剖析用户底层需求要点，找准用户痛点，这就是需求分析的精髓。

       二、解读用户

       

         一千个读者眼中有一千个哈姆莱特，用户需求会千奇百怪，而产品不可能大而全的满足所有用户的所有需求，那么找准自己的目标用户群，很关键。怎么来做用户分析，用户分析的要点又是什么？

         （1）根据产品基本定位，明确用户分类；

         （2）不同用户群体的特征：年龄、性别、教育程度、消费能力、城市、共性习惯等；

         （3）不同用户群体想要什么；

         （4）用户想要的我们是否满足。

          案例解析：以蚂蜂窝为例，进行用户分析。

         定位：蚂蜂窝是一家旅游攻略、自助游、自驾游攻略、靠谱旅游社交媒体网站。

        用户群划分：

• •  分享类用户，爱旅游爱分享，喜欢分享各种旅行感受攻略等；
  • 浏览类用户，看旅行攻略和他人游记为主；
  • 旅行赚钱类，如背包客小鹏；
  • 软文推广类，旅行社/公司职员，旅行编辑，写旅行类文案推广；
  • 组队约伴型，组队旅行，顺便预定一个酒店。

       三、需求获取

        

       认识了解用户后，下一步就该了解各用户群体的需求，通过多种途径采集用户需求。我们常用的需求采集方法有：文献调研、用户访谈、问卷调查、竞品分析、运营数据分析及用户模拟（欢迎补充，请在下方评论区留言）。下面抽取几种典型的需求采集方法展开：

      1、文献调研

        查阅历史资料、行业报告、网络资讯等相关讯息，如《年度互联网用户行为分析报告》、《移动APP年度报告》等互联网行业报告，了解判断行业趋势、把脉用户习惯，粗略判别用户需求。PS：艾瑞咨询发布互联网报告较多，当然明确产品相关行业及目标用户后针对性的了解分析更为关键。

      2、用户访谈

       用户访谈分为2种形式，1V1的深度访谈和座谈会形式的焦点访谈。两种用户访谈的方式各有所长。下表对两种不同的访谈形式做详解：

		深度访谈	焦点访谈
访谈对象	随机小白用户（蚂蜂窝的普通注册会员）	代表性用户，每场人数8-10人为宜，相互间是陌生的，排除行业专家（普通注册会员、分享游记的专业驴友、旅游公司职员等几类典型用户）
主持人	提起思考点，引导用户多说，注意观察受访者的表亲、语气等，扮演倾听者的角色	主导话题主线，但保持严格中立，注意追问，注意观察场上各人员，对意见领袖适当冷藏，激活沉默用户多发言，
场地	无要求	专业焦点访谈室，分为前后两个部分，前边为访谈主场，后边为监控室。访谈主场以圆桌为佳，桌上备有少量水果、点心，营造轻松氛围；备有纸笔、录音笔、摄像头等；监控室为观察场上情况，整体把握调整话题方向所用。
访谈提纲	访谈提纲仅作参考，不限定，具体视现场情况访问员/主持人把控。1 验证你心中原定的需求点是否能得到认同；2 用户的心中是否有其他见解；3 开放性的问题多一点，让受访者思考；4问题尽量贴近生活。
优点	1V1深度访谈，获取更多用户信息，实时观察用户表情及特征，为判断需求真伪提供一定依据；场地无要求，易实施。	不同代表性用户，易激发思考。
缺点	难以激发思考，需访问员注意启发式提问	部分受访者易受意见领袖影响；主持人控场要求高。

       说明：（）内以蚂蜂窝为案例

3、问卷调查

       相比用户访谈，问卷调查是一种定量的调研方式，常用于用户访谈之后；通常先通过定性的用户访谈判断基本方向及要点，再通过问卷对各需求关键点进行定量验证，了解其特点后再次通过1V1的深度访谈把脉需求（一般在问卷调研过程中发掘深访对象）。当然视产品的具体情况选择最适合的方法。

      全流程的问卷调查，执行过程中一般会涵盖调研方案（调研时间、地点、主题、投放数量、受访者构成等）、问卷设计（问卷设计完成后，可小范围投放测试）、实际调研（网络、电话、实地）、问卷回收（审核问卷真实性、有效性）、问卷分析（分析调研数据，出具分析报告）几个方面。其中的问卷设计，有几个原则：1）问题通俗化，忌专业术语；2）选择题为主，问题设置由浅入深，逻辑性；3）选择题答案闭合，标准化。

4、运营数据分析

       从运营数据报告中获取需求，一般针对已上线的产品/业务，通过现产品的运营监控，为产品迭代提供一定依据。通常来自于采集运营数据（如UV、PV、浏览轨迹、转化率等）和市场、客服等其他合作部门的建议反馈。

案例解析：蚂蜂窝这一案例中的酒店预定、机票预定功能，如果订单数量很多，但最终完成支付的很少，可以怎么解决？

1、 梳理下订单之后的各个环节，下单成功后，需要什么环节才能成功支付；

2、 分析各个环节的转化率，找到用户流失的关键步骤；

3、 从产品角度考虑产品功能优化，以降低用户流失。

现场简要分析，用户流失可能因为：1）登录注册繁琐；2）支付方式太少；3）页面跳转环节过多等等。针对这几个问题，从用户需求的角度来看，1）简化登录注册，最好可以支持通用的如QQ、微博等社交类帐号；2）丰富支付方式，支持常用网银、支付宝等支付工具；3）简化非必要跳转页面。

市场、客服等合作部门的反馈，因为市场、客服人员是与一线用户直接接触的，对于用户对产品的反馈和建议是能够快速掌握的，有时可能就是用户的一句抱怨，可能会给产品带来很大的价值，因此留意用户，接触用户也是非常关键的。

5、竞品分析

       所谓的竞品分析就是找类似定位的产品，看别人的产品功能、设计，逆推用户需求，发现竞品的闪光点，拿来用在自己的产品上。

        从领域、产品类型、未来规划的方向、相关功能等角度去找竞品；再从竞品的定位，具体功能，战略规划，运营推广等角度去分析。（ps：当今社会创新的成本太高，拿来主义式的微创新也是不错的选择）

        如本篇案例中的蚂蜂窝，竞品分析可对途牛网、悠哉网，去哪儿，酷讯，到到网，驴评网，蝉游记等产品的产品定位、功能结构、产品规划等多维度分析，找到不同产品的优势，然后为我所用，基于此对蚂蜂窝进行优化改造。

6、用户模拟

        用户模拟的目的是在具备产品核心定位后，融入用户角色，再不断的对产品核心理念做修正的一个过程。有两种方式，一种是1S变小白，自己化身用户，思考如果你是用户，你想用这个产品在什么场景下做什么；另外一种方式，代入用户角色，走进目标用户群，去体验感受用户的所有感知。

         四、需求评估

         通过多种需求采集方法收集了大量的用户需求后，在进行产品设计前，会预先对需求进行评估。需求评估的目的在于，对所有需求做评估，做优先级判断，判断哪些需求是必须要满足的，哪些是可以延迟一点满足的，而哪些又是可以不用考虑的。

需求评估考虑的因素有：1）可行性（技术能否实现）、2）成本（人力成本、时间成本）、3）商业风险、4）是不是用户最迫切的需求（紧急性与重要性）。

我们常用的需求评估方法有KANO模型、需求减法、专家评估式：

1、KANO模型

         KANO模型，是需求实现与用户满意度之间的关系模型图，把需求按照需求满足和满意度两个维度把需求划分为基本型需求、期望型需求和兴奋型需求三大类。同时用户的需求类型是随着时间变化的，也许期望型需求变成了基本型需求，兴奋型需求变成了期望型需求，需要重新挖掘用户的兴奋型需求。

对于必须完成的需求，在产品发布时需要完成；同时完成尽可能多的期望型需求；如果时间允许，至少应该确定少量的兴奋点需求优先级，进入研发和发布计划；后续及时跟进用户的需求状态和类型，不断挖掘用户新的兴奋型需求。

KANO模型分析可参见《如何解决“女生喜欢白马王子”的需求》。

2、需求减法

        有时候决定不做什么，比决定做什么更加重要。产品经理或多或少有一些”完美主义“情结，生怕缺少什么，增加不必要的功能。但是从成本、效率等多方面考虑，我们应该倾向于”轻产品“，根据一定的原则做需求减法，适当的砍掉一部分需求。

       需求减法的核心要点依旧是产品定位，围绕产品定位，根据产品价值，定义需求边界，把握核心需求，砍掉需求边界外一些无关紧要的需求。

      如阿里集团旗下的淘宝和阿里巴巴同为电商平台，为何阿里会搭建两个平台来开展电商业务？很清楚的定位，淘宝是2C，阿里巴巴是2B，两者所面向的用户群体不一样，对于不同的买家和卖家的需求都会不一样。

3、专家评估法

       专家评估法，顾名思义就是组织资深产品专家一起评估产品需求，决定做还是不做，是否值得去做，运用群体智慧的力量来决策产品需求。资深专家可以是技术专家、资深市场、资深客服等。

        尤其值得一提的是老板需求，老板作为一个特殊的客户，常常会对产品提出一些自己的设想，老板以他的经验、阅历及对市场的敏感度会做出一定的判断。针对老板需求在不影响整体产品逻辑的前提下可以适当考虑。如果偏离太远，可提供相应理由给老板定夺。

五、需求管理

        在需求采集、需求评估的过程中，如何整体管理这些需求，在整个产品的生命周期里更好的跟踪把控需求进展。公司不同，个人习惯不同，对于需求管理的方法会有所不同，但是目的是一致的，实时把控跟踪需求。下面是几种使用较多的需求管理方式：

需求卡片：描述需求来源、需求内容及需求优先级的需求卡片，一般会用于市场、客服等相关合作部门提交需求所用。

需求矩阵：EXCEL表单的形式记录每条需求，追踪需求动向，包括相应提出人、需求描述、需求优先级、需求评审时间、开发时间、开发人员、测试人员等。

需求文档：把整个产品拆成N个小功能模块，出具相应的需求文档，分阶段提供给开发、测试相关人员，在小公司小的产品中比较适用，但要求产品人员必须非常清楚产品的每个功能点，可以全盘考虑管理。

测试用例：测试用例一般以用户场景的形式描述，使用测试用例的形式来记录需求，管理需求也不失为一种很好的方法。

这便是通常大家提出的产品需求分析整体思路，其中个人理解核心在于：用户的解读和产品的定位。

         由于本人即将从事软件行业，首先需要学习软件需求分析。不难发现，网上这类的资料和书籍也是到处都有，但是真正对于软件需求的深层次的理解，还是比较少的。大部分都是纯粹的一些空洞的语言。

         大体流程是：

首先有用户需求

然后由组织将用户需求转化为业务需求

再由开发者将业务需求转化为功能需求

功能需求映射到系统功能模块

业务需求也有可能是基于的业务发展需要，由组织首先提出来的。

 

     业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
　　功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

什么是用户需求？什么是功能需求？

我觉得：

用户需求针对的是人，描述的是用户想做某件事情所遇到的问题，或所想满足的欲望；

而功能需求针对的是产品，描述是是产品如何解决用户所遇到的问题，或如何满足用户的欲望，是方式、方法；

举个例子：

用户需求：在决定购买之前，用户想方便地比较一下几个同系列商品，以此在选择的时候做出更明智的决定。

功能需求：我们可以让用户把意向购买的商品，都放入“对比栏”，然后用户再点击“去对比”，就会在一个界面同时对比几个产品，就像中关村在线那样的做法。

用户需求是前提条件，功能需求是落下来的产品部分，它是可以交付的。

值得注意的一点是业务需求，有的时候用户需求与业务需求是有矛盾，那么功能需求怎么决定呢？

举个例子：

某个商品界面，我发现我的用户不是为了买最便宜的货，我决定产品不把最便宜的商品都展示出来，因为1、不希望让用户买最便宜货，2、一旦有太便宜的商品，用户就会形成心理落差，觉得贵的商品就不值钱（其实贵的商品的性价比比便宜的商品更高），3、我想提高单笔成交订单额度。

所以我就会只展示出相对贵一点的商品。

让用户减少选择，就有可能购买价值更贵的商品；（业务需要）

如果把最便宜的商品也展示出来，这对于用户需求来说，是有价值的；（用户需要）

但还是坚持了“贵一点”的策略，这就是业务需求主导了功能需求；

业务需求 是什么？

业务需求针对是公司，描述是公司想如何解决用户的问题，如何满足用户的欲望，并将利益最大化。重点是在后面，追求商业可行性与利益最大化。

不过放心，大部分互联网公司，他的业务需求很简单：让功能需求最大化满足用户需求，不断追求用户体验，黏住用户后，再谋求规模化利润（比如：广告）。

        我原来对软件需求的定义或描述更多是偏于对现实世界的定义，而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即：用户需求是对现实世界的定义，而软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。

        从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。

        对于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解。

        上面一步的业务更多的是属于顶层方面的内容，而第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核心，平滑的转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。

       要做好需求的第二步的事情，那么单纯的只有业务背景就不足够的，必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开发，但是只是是做过，通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始，最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑用例建模，去认识到为何要采用这种方式去用例建模，真正理解用例中每个描述点如何影响到最终业务系统的实现。

       没有技术背景很难真正成为一个优秀的软件需求分析师，最多也就是一个业务需求分析师。

        要知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。

         一个优秀的软件需求人员既不应该因为具备技术和开发背景而导致在需求分析和建模中的各种程序员思维，也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设计开发，是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧，各种软技能的要求更是必不可少的，在此不再展开去描述。

       一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题，因为最终真正有用的需求分析的方法论和模式，去理解和熟悉业务和快速形式化描述和建模的方法，有不断的实践总结出来的快速理解业务的能力。