一文读懂需求的科学化挖掘流程
2018/9/16 18:00:00 人人都是产品经理
全文共 11047 字 3 图，阅读超过 25 分钟
———— / BEGIN / ————
无论是互联网产品、软件产品、硬件产品或服务，需求就是它们要做的事或要成为的样子。
不论你发现还是没发现，写下来或没写下来，需求都是存在的。
一个需求的形成，期间会经历一个严谨的流程，好的产品需求，能帮助我们准确地反映出用户的需要和想法，能帮助我们做出正确的产品。
本文将从项目启动开始，一步一步给大家带来创建需求的科学流程。
一、确定业务范围
在本阶段，通常会通过一场项目启动会开启我们的项目，在项目启动会上我们会大致了解到产品要实现的目标、产品的大体利益相关者。
在项目启动会上，我们可能会从项目经理那里得到一部分的项目相关资料，当然，大部分的资料还是需要我们自己去挖掘。
在会议上，务必要明确项目的目标，通过一段简短的、定量的陈述，说明产品要做的事，以及产品所带来的业务好处。
这个目标是很有用处的，它能解释为什么我们的业务需要这个项目，也能说明期望实现的业务收益。
它为项目提供了理由，同时也是需求发现过程关注的焦点。
这里有三个关键词：范围、利益相关者和目标
范围是受产品影响的业务领域的部分。因为它确定了真实组织机构的一部分，所以范围会指出一些利益相关者，他们对项目的成功有影响。
利益相关者反过来又决定了产品的目标，即产品使用后期望获得的业务上的完善或改进。
这样就构成了项目前期很重要的：“范围—利益相关者—目标”的三位一体关系链。
1.1 范围，是产品实现的边界
这里的范围指的是产品的工作范围，也就是产品要去改变或改进的那部分工作。只要它涉及一些处理内容和数据，我们就称之为“工作”，而我们必须知道它的范围。
任何一部分工作，都必须至少和另一部分工作有联系；如果没有联系，工作将没有作用，它不会有任何输出。
同理，这项工作内的模块都至少和另一个模块有联系。
了解了这一点，我们就可以分离出相应的模块，即在产品的工作之内的模块。
要完成工作模块的分离，我们要知道一个简单的事实，即所有的模块都是由数据驱动的。
我们刚才提到：模块与其他模块有联系，这种联系就是数据流。
也就是说，每一个模块都会产生某种数据，然后将数据传递给其他的模块。后续的模块收到进入的数据流，触发执行它要做的处理，并生成不同的数据输出，这些输出再次传递给其他模块。因此这些数据流就是模块之间的联系。
通过确定这些数据联系，就能确定工作的边界。
我们可以通过画一条线来代表工作边界，区分类似的、耦合的模块，创造了一个区域，最终包含了所有构成工作的范围。
1.2 利益相关者，是需求的来源
利益相关者包括全部对产品的结果有影响的人。
产品的核心用户是最明显的利益相关者，但是还有其他利益相关者。
这是一个合理的产品目标吗？比如，企业CRM系统，为了实现企业管理、跟进客户关系，开发该系统花费的成本，是否值得？我们可以收集一些数据，比如市面上的CRM系统，在采购半年后，所创造的客户数据大概在多少，我们自己研发一套CRM系统，在半年内要达到这个数据量所涉及的成本是多少，二者是否平衡等。
产品目标是否可行？在项目启动会上，相关的利益相关者可以对此进行评估。比如，经验丰富的技术负责人可以大体评估出产品目标的可行性。
产品目标是否可达到？同样，项目启动会上可以大体评估出产品目标能否达到。
通过以上问题，我们可以总结出关于产品度量的标准：比如，在半年内，通过CRM系统，将公司有效客户数量增加至20000。
综上，我们可以得到一个描述产品目标的模板：
目标：产品要做什么的业务描述。
好处：产品能提供怎样的业务好处。
度量：对产品目标进行度量的数据描述。
合理性：综合考虑全部因素，产品是否有可能实现业务好处。
可行性：考虑到在启动会议上得到的信息，产品能达到度量标准。
可达成性：组织机构是否具备构建该产品的技能。
二、拆解业务用例
在明确了项目的目标之后，接下来要做的就是得到产品中全部的业务用例(用例，用来描述系统与用户之间的交互)。
2.1 业务事件与业务用例
产品的用户在使用产品过程中涉及到的工作或业务，统称为业务事件。
比如，用户在网上买书时，挑选好了需要的书籍，这时可能会有两种情况：
1. 决定做些别的事情，先放弃此次交易；
2. 决定买下这本书。
此时，决定要买这本书就是一个业务事件——当然，只是决定想要这本书还不够，用户必须告诉系统想要买书。
用户点击了购买按钮，提供了手机号、收货地址等信息——此时，用户的操作触发了系统，系统会完成下单，并且快递这本书到用户手中。
从这里我们可以顺带引出业务用例的概念：
在这个例子中，用户决定买书和完成买书的操作就是业务事件；总是有一些数据源自业务事件(触发数据流)，这会调用预先计划的对该事件的响应——这种响应就是业务用例。
(当业务事件发生时，系统通过发起一个业务用例进行响应)
2.2 发现业务事件
业务事件其实就是发生的一些事情，这些事情让系统以某种方式做出反应。
在业务事件发生时，在系统工作中至少会显示一条数据流。
进入或离开系统的每个信息流都会是一个业务事件的结果，外部通信的存在没有其他的理由。
看一下每个信息流，就可以确定引发它的事件。
在某些情况下，可能有多个信息流跟随同一事件。
例如：物流公司派出卡车服务的业务事件
在挖掘业务事件时，有一个需要注意的要点，就是要看到整个业务过程 。
比如，上述物流公司提供物流服务的例子，如果只是站在用户侧，看到的业务事件有可能是“收件人收到发货并登记信息”，可是站在整个业务链侧，业务事件就是“物流公司派送货物”。
2.3 拆解业务用例
上面已经说到，针对每个业务事件，有一个预先计划的对它的响应，被称为业务用例。
业务用例包含一些业务处理的过程，一些被存取的数据，产生的一些输出，发送的一些消息，或是这些事情的组合。换言之，业务用例就是一个功能的单元。
这种单元是编写功能需求和非功能需求的基础。
业务用例 = 业务处理过程 + 存取的数据 + 输出信息
通过找到的业务事件，按照上述公式，可以得到具体的业务用例，通常多个业务用例单元会组成一个完整的功能描述。
研究业务用例，就是要考虑系统要做哪些事以及预期的结果。
在拆解并理解了业务用例的全部工作之后，也就确定了对业务用例贡献最大的产品范围。
三、进行业务调研
在得到了项目启动阶段的输出信息，即系统的范围、项目的目标、系统的业务事件与用例。
启动阶段也确定了项目涉及的利益相关者和潜在用户。
我们接下来就需要进行工作调研，取得对系统的深入理解。
工作调研，可以帮助我们有效地深入了解项目业务的本质。
3.1 建模
建模作为工作调研的一种方式，最好是在需要理解中到大型工作领域，又没有文档时进行。
如果当前的利益相关者很难描述整体工作，也可以采用这种方法。
我们可以利用模型帮助理解系统的工作。要限制在当前系统模型中所展示细节的数量。
理想的模型包含足够让你理解工作的信息。
也就是说：模型要展示当前情况的主要部分。这样的模型允许利益相关者验证它是否足够好地代表了他们工作的实际情况，让我们可以有进一步问问题的基础。
常见的建模方式包括业务流程图、思维导图、UML时序图等，不限于形式，只要能帮助更好地梳理业务事件和业务用例就好。
3.2 现场调研
现场调研对于开发企业内部的B端产品很有用。
现场调研的基本假定是用户正在完成工作，作为产品经理，必须理解他们的工作。
现场调研是一种观察实际工作的很好的方法，有点像以前的“学徒工”。
在这种情况下，产品经理是徒弟，各利益相关者是师父。
产品经理与利益相关者一起坐在他们工作的场所，通过观察，问问题，或者通过在利益相关者指导下完成一些工作来进行学习。
如果用户正在他工作的地方做他的事情，他就能提供连续不断的解说，并提供在其他情况下会遗漏的细节。
所以，如果你想得到工作的准确解释，就要去工作现场，坐在用户身边，在工作发生时获得连续不断的解说。
现场调研可以与建模结合起来。在观察工作和用户的解释时，可以勾勒出每项任务的模型，以及它们与其他任务的联系。在建模时，将它反馈给用户以求得确认。
然后我们会利这种反馈，对所有不确定的地方提出问题。
3.3 利益相关者访谈
利益相关者访谈是最常用的需求收集方法。
几乎每一个项目都离不开利益相关者访谈。在访谈过程中，利益相关者不应该是完全被动的。
相反，应该尽量让他们参与建模(业务事件响应、用例、场景等)的过程中来。
这样我们就和利益相关者之间建立起了一个反馈环，也意味着可以迭代式地测试你听到的东西的准确性。
在利益相关者访谈中，有如下需要注意的要点：
确定好访谈的背景。这样可以有效避免利益相关者和你谈一些无关的问题。
限制访谈的时间。国外有研究表明，超过1小时的访谈，会使访谈逐渐失去焦点。
使用业务用例作为访谈的核心。准备好业务用例，挨个讨论业务用例，这样也会增强访谈的方向性。
问问题、听取回答、然后反馈理解。
画出草图、模型，鼓励利益相关者改正它。及时画出一些能表明谈话内容的原型草图、流程图或用例图，可以有效帮助我们理解每一个处理过程。
了解利益相关者的术语。在访谈中，难免会遇到利益相关者在实际工作中的术语，及时请教他们，理解其含义。
记录笔记，写下所了解到的一切。
总结下来，在利益相关者访谈中，做到两点即可：正确提问，聆听回答。
3.4 快速绘制低保真原型图
原型和草图可以有效地提取需求，基本思路是用草图勾画产品，然后进行逆向工程，从草图导出需求。
这种方式适用于：产品的利益相关者对这种产品或建议的技术没有经验 ；利益相关者很难说出他们的需求；产品经理很难理解需求是什么。
此时，原型为利益相关者提供了一些真实的东西，或者至少是具有真实的外观。
原型让利益相关者感到产品足够真实，从而提出用其他方法可能遗漏的需求。
当利益相关者看到原型所展示的功能时，他们会想到一些其他需求。
用这种方式，通过原型来展示产品雏形，并让利益相关者身临其境的去浏览或使用，就可以捕捉到一些需求，如果不是这样，这些需求可能要到产品开发完真正使用时才能发现。
3.5 录像或照相
录像或照相是记录某些时刻的一种方式，以便稍后能对它们进行研究。
录像或照相可以用于研究业务。
得到乘客的机票或电子客票记录编号。
确定乘客、航班、目的地是否正确。
检查护照有效并属于这名乘客。
记下乘客的编号。
为乘客分配一个座位。
安检行李。
打印登机牌和行李标签，并递给乘客。
祝乘客“旅途愉快”。
4.1 为场景取了一个有意义的名称
业务用例名称：为航班的乘客检票
4.2 为业务用例加入启动机制
启动机制：乘客的机票、电子客票记录编号，或者身份和航班信息
在用场景对系统建模时，应该一直询问自己是否能改进工作。
例如，除了让乘客在值机柜台前面等，是否能在乘客到达之前就开始？例如，他能在家检票，或在来机场的路上，或在排队时？所有这些选择在技术上都是可行的，可能带来一些业务上的好处。
4.3 加前置条件
现在加入一些前置条件，业务用例触发时必须满足这些条件。前置条件表明了工作初始的状态。
通常这意味着有一些业务事件必须已经发生，这个业务事件才有意义：
前置条件：乘客必须已预订航班
4.4 加入影响利益相关者
还可以考虑为场景加入影响利益相关者。这些利益相关者对这个业务用例的结果有影响。
也就是说，他们会受到工作完成方式和工作产生的数据的影响：
影响利益相关者：检票员、市场部门、行李部门、航班预订机构、航班乘客名单系统、安全部门、目的地国的移民局
4.5 主要的利益相关者
主要的利益相关者是完成这个业务用例工作的人或系统。通常，一个主要的利益相关者触发业务用例，然后一个或多个其他的主动利益相关者参与这项工作：
主动利益相关者：乘客(触发者)、检票员
4.6 总结
现在，通过以上的分析，我们可以得到一个具备场景的业务用例描述模板：
业务事件：乘客决定检票。
业务用例名称和编号：为航班的乘客检票，0101。
启动机制：乘客的机票、电子客票、记录编号，或者身份和航班信息。
前置条件：乘客必须已预订航班。
影响的利益相关者：检票员、市场部门、行李部门、航班预订机构、航班乘客名单系统、工作流、安全部门、目的地国的移民局。
主要利益相关者：乘客(触发者)、检票员。
(1)查出乘客的预订信息。
(2)确保乘客身份正确，并确定预定信息。
(3)检查护照有效并属于这名乘客。
(4)记下经常飞行的乘客的编号。
(5)分配一个座位。
(6)询问安全问题并得到正确回答。
(7)检入行李。
(8)打印登机牌和行李标签并递给乘客。
(9)祝乘客旅途愉快。
成果：记录下乘客已检入这次航班，行李分配到这次航班，分配一个座位，乘客拿到登机牌和行李票根。
五、设计解决方案
经历了前面的四个步骤，我们已经明确了产品的全部业务事件、业务用例，现在就要着手设计产品的解决方案了。
设计产品解决方案有很多文章进行讨论，这里只做一些简单的总结。
5.1 再次明确产品的范围
前面说过，业务用例是工作对外界服务请求的响应。所以最好的响应就是以最少的时间、原材料或工作量成本(从企业的视角)，提供最有价值的服务(从用户的视角)。
因此我们打造的产品应该对最好的业务用例做出贡献，即让产品更便宜、更快、更方便，并且能达到我们的项目要实现的其他目标。
5.2 设计产品的用户体验
用户体验设计的理论就不在这里详述了，体验设计的目的是得到一种使用体验，令人满意且令人激动，同时符合用户的文化和期望。
这样的设计更专注于用户对产品的感觉，而不是为产品增加功能。
简单来说：如果你提供了令人满意的体验，用户很享受并愿意重复，那么这些用户就很愿意接受你的产品，并且不要求改变。
5.3 考虑成本、收益和风险
我们有责任得到最有价值的产品，即对拥有者最有价值。
这意味着：解决方案的成本必须与它给拥有者带来的收益相称——花10元钱开发的产品只带来1元钱的收益是没意义的。
风险必须与收益和成本相符。这里的风险包括潜在问题变成真正问题的可能性，以及问题成真所带来的负面的影响。
例如，假定我们建议的解决方案会使用近场通信(NFC)技术。
之前从未用过这种技术，没有内部的专家：风险在于也许不能成功地实现NFC。现在还要加上一项风险：即使这种技术成功地实施，业务客户也可能拒绝使用。
应该将这些风险加起来，与收益进行比较。对于这个级别的风险，我们可能需要一些实质性的收益，才值得去做新产品。如果收益不大，那就应该考虑不同的解决方案。
相反，如果收益巨大，那风险就值得承担。
那如何评价可选的产品边界？这就是要和利益相关者一起花时间的地方，判断哪一种解决方式提供了成本、收益和风险的最佳组合。
六、编写产品需求说明
6.1 功能需求
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行一些动作。
同时，功能需求是产品为了支持工作而必须做的事情——它们的表述应该尽可能独立于实现需求的技术。
比如，登录功能、购物车功能、收藏功能、支付功能等。
在编写功能需求时，要为需求加上理由，说明需求为什么存在——在大多数情况下，这是需求的关键部分。
接着以物流公司那个为例：
需求描述：对于卡车的调度，产品应该记录开始和结束的时间。
需求理由：卡车在24小时内最多被安排20小时，以便进行维护和清理。
这条理由非常重要，如果该需求没有实现，物流公司就会遇到麻烦，车辆的保养就会不及时。
由此可以看到：一条好的需求理由也能决定需求的优先级。
6.2 非功能需求
非功能需求描述了产品必须具备的品质；这些需求让产品有吸引力、易于使用、快速、可靠，或安全。
用非功能需求来指定响应时间，或计算时达到的精度。
如果产品必须具有某种特的外观，或者必须在特定的环境下使用，或者必须遵守适用于业务法律，我们就要编写非功能需求。
把功能需求看成是使产品工作的需求，把非功能需求看成是为工作增加某些特征的需求。
非功能需求是需求规格说明的重要组成部分。如果产品满足了它所要求的功能需求，非功能属性，如可用性、方便性、打动人心，是否得到满足可能造成产品被接受、深受喜欢或无人使用。
用户对产品的看法和感觉大部分来自于非功能需求。
非功能性需求包括如下内容：
1.观感需求
观感需求描述了对产品外观期望的精神实质、情绪或风格。
描述：产品应该避免要求用户重复已输入的数据
理由：为了建立用户对产品的信心
易用性需求源自两个方面，一方面是用户期望产品达到的易用性水平，另一方面是预期用户具有怎样的经验。
自然，用户的特征不同导致他们的期望不同。
作为产品经理，我们必须发现这些特征，并确定怎样的易用性水平将给用户带来舒适有用的体验。
3. 执行需求
如果产品需要在给定的时间，或以特定的精确度来执行某些任务，或者产品需要有一定容量，就要写下执行需求。
考虑用户的法律需求和权利。例如，是否有一些对残障人士的法律是适用的？
相邻系统对保存的数据是否拥有隐私权？是否需要留下交易的证据？是否不能暴露产品拥有的关于某些系统的信息？
是否存在与该产品相关的法律？例如，数据保护、隐私法律、担保、消费者保护、消费者信用、知情权等法律是否适用？
6.3 为需求增加验收标准
如果产品有一项需求，要执行某个功能或具备某种属性，那么测试时必须保证产品确实执行了该项功能，或具备了该项期望的属性。
为了进行这样的测试，需求必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。
测试基准就是验收标准，即需求的量化，它说明了产品必须达到的标准。
1.非功能性需求的验收标准
非功能需求是产品必须具备的品质，诸如易用性、观感、执行特点等。
因此，验收标准是对这些品质进行量化。
比如：
描述：产品首页应该记录涨跌数据
理由：用户需要实时了解交易品的涨跌数据信息
验收标准：首页记录下来的交易品涨跌数据要与国际交易中心的数据一致
3.总结
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。
它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求都符合它的验收标准。
6.4 产品需求模板
综上所述，我们可以得到一个描述需求的模板：
6.5 总结
编写需求规格说明不是一项独立的工作，而是与需求过程的其他部分一起完成的。无论何时，如果产品经理或其他利益相关者有所发现，就写下需求或部分需求。并非所有需求都是同时完成的。
正确地编写需求是很重要的。
一组好的需求能得到数倍的回报：构建工作更精确，维护成本更低，完成的产品更准确地反映用户的需要和想法。
七、排列需求优先级
排列优先级让我们能选择哪些需求在产品的哪些版本中实现。
确定优先级很复杂，因为它们涉及不同的因素，而这些因素彼此之间常常产生冲突。
要排列需求的优先级，可以将它们分成逻辑上的小组。这些小组分别作为一个单元来排列优先级。
一个小组可能是一个业务用例、一个组件、一项功能，或其他需求分组，只要能够作为一个单元来排列优先级，而不用单独处理就行。
影响需求优先级的因素包括：
实现的成本
对用户的价值
实现产品所需的时间
技术实现的容易程度
业务或组织机构实现的容易程度
对业务的好处如何
遵守法律的要求
不是所有因素都适用于每个项目，而且每个因素对每个项目的相对重要性也不一样。
在一个项目中，对不同的利益相关者来说，这些因素的相对重要性也不同。
由于这些复杂性，我们需要对优先级达成一致意见，以提供决策。
八、总结
产品需求从不是拍拍脑袋就想出来的，它也是需要一个缜密、完整的过程。希望本文总结的需求流程能给你带来一些启发。
———— / END / ————
———— / 推荐阅读 / ————
>> 后来，我就再也没乱提过需求
>> 内部分享PPT｜产品狗如何做需求
>> 只是痒点需求的产品，怎么做起来？!
>> AI时代，从需求思维方式到专家系统实例解析
>> 搞定核心用户难吗？只需要把握这8个动机需求!
小班授课+小组学习+模拟训练
BAT产品大咖手把手带你
实战演练体验产品从0到1全过程!
点击“阅读原文”，了解更多信息
http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药