| 编辑推荐: |
本文来自于人人都是产品经理，我们接下来的需求采集服务的，即如何提升需求采集的效率，如何保证采集回来需求的质量，带着这些问题，让我们进入到本篇文章的中心：如何进行B端产品的需求采集？ |
|
一、需求采集方法综述
在调研的过程中，我们一般会采用定量和定性的方式来采集需求，其中定性方式包括用户访谈和可用性测试，定量方式包括调查问卷和数据分析，数据分析和调查问卷一般用于用户数量庞大的C端产品，B端产品因用户量相对C端来说用户量数量级要少的多，因此从统计学的角度来看利用数据分析来获取用户的需求在B端产品中用到较少，在本人实际参与到B端产品需求采集的过程中，主要是用到调研访谈和可用性测试，下文我将重点阐述在调研实践过程的这两种方法和注意事项。
二、B端产品需求采集实践
1、调研访谈与实践
调研访谈是需求采集方式中最为普遍和有效的方式，接下来我将带大家一起模拟进入到调研访谈的场景中，在实景中去感受，相信会有更深的体会。
场景1：根据与客户定好的调研访谈日期，调研人员李工今天提前半小时来到了会议室，他先打开了窗户，让室内的空气变得清新许多，整理和布置了下现场桌椅，看上去整齐干净许多，几分钟后，需要参加被调研业务流程客户王经理准时来到了会议室，李工主动和王经理微笑并握手致意，顺便愉快的聊了下柜子上的篮球奖状的来由，然后开始正式的会议，在正式访谈前，说明了下本次访谈的目的、范围和所需要的时间，王经理点头表示认可以进入到下一步。
相信大家可能会有疑问了，为什么正式访谈前需要做这些铺垫，其实主要是为了：
（1）营造一个轻松、舒适的访谈环境，一个好的开始，对于后面工作的开展是很有必要的
（2）正式访谈前介绍本次调研的目的、范围和所需要的时间，让被调研人员获悉本次访谈的重点，内容和时间，让调研对象心里有底。
场景2：王经理，为了便于我们后期调研内容的整理，准备了录音设备对本次谈话内容进行录音，您是否同意啊，王经理示意可以，并且希望后期可将资料发送一份给他的意见。随后李工开启第一个提问：王经理，目前供应商的管理主要存在哪些问题？王工回答完毕后，李工追问了线下的供应商资质为何管理困难？接着李工问了其他问题：您希望系统解决哪些问题？介绍下现在线下的业务流程是如何进行的？
这个场景需要注意的方面有：
（3）巧用设备备份调研过程，便于后期整理与回顾
（4）提问应先易后难，循环渐进
（5）针对有疑问的地方，恰当的追问，找到背后真实的需求
场景3：随着调研的深入，王经理强调要采用目前某同行的解决方案来做这个产品，李工询问为什么要采用该解决方案，并强调目前产品方案的功能和特性，王经理因有过软件开发的经历，提问本次产品的技术是否采用MVC架构，李工答道，我们本次的调研访谈的目的是收集供应商证件管理的需求，技术方案将在需求确定后由我们的技术人员与您沟通这个事情。
该场景需要注意的方面有：
（6）用户过于强势，强调解决方案，没有提出本质需求
（7）避免成为用户的记录员和设计师，应该挖掘提出背后的原因
（8）调研人员过于强势，强调产品功能及特性来引导用户，忽略了用户真正的需求
（9）调研环节应避免讨论技术和太过专业的术语
（10）将话题拉回调研主题，避免话题分散
场景4：王经理，您可以举个例子来说明下供应商资质审核的步骤吗？希望您多回忆一下，步骤越清晰越好，您刚刚提到目前审核的瓶颈问题是审核的效率，是说目前的供应商资质的审核是一次只能审核一个导致的效率低吗？如果可以的话，你能否给我演示下操作的过程以及为何需要这样的操作？
该场景需要注意的方面有：
（11）鼓励用户讲故事，这样用户和使用场景会更加形象和具体
（12）重述理解用户的意思，保持对问题理解的一致性
（13）相比用户如何说，更应该关注如何做；相比用户如何做，更应该关注这样做背后的原因
2、可用性测试方法与实践
可用性测试是B端产品验证用户需求、收集需求必要而有效的方式，而验证的方式是多样的，可以是产品、竞品、demo、高保真、低保真、草图原型甚至是一张手绘的草图都可作为测试方法，根据演示环境和用户的角色的不同观察用户使用产品，其本质目的就是验证需求、收集需求。
在这里先说说可用性测试前的准备工作，其大纲如下：
（1）首先应该理清思路，确定测试的目的，用户的角色、特征和使用的业务场景，目标不清晰，思路不对会导致事倍功半。
（2）理清思路后，需要准备演示的相关资料，常用的软件硬件设备有：纸、比、文档、录像设备、演示电脑、相关软件，重点提及一下录像设备，之所以需要录像，其目的是在录音的同时捕捉用户操作过程中的肢体、表情等动作，不同的微表情和动作可以很好的体现出用户当时使用产品的感受，便于调研人员后期的总结和分析。另外需要强调下原型设计，在未确定好业务流程图和页面流程图直接设计原型是存在很多问题的，业务流程的不清晰、用户和使用场景的不清晰、信息架构的不清晰都会影响到原型呈现出产品的定位和用户体验，原型设计的过程本文不做详细的描述，后文会有专文针对产品设计的文章来进行探讨，最后再介绍下测试脚本，其目的是记录用户测试产品过程中的信息，可参考如下表：
表中问题等级可依据实际情况进行设置，至此，准备就绪，可安排相应的用户进行可用性测试了，其注意事项将沿用场景化的描述方式。
场景1：李工在进行完深入的业务流程调研后，以用户+使用场景的方式进行了需求分析，绘制了业务流程图，设计了页面流程图，利用原型软件制作了可实现交互效果的原型demo，暖场之后，介绍了本次测试的目的是产品非用户，李工助理架起了录像设备，李工提出希望采购部张经理在测试的过程中，尽量表达自己的感受和想法，接着张经理开始了测试，当张经理遇到困难时；李工并没有主动引导怎么做，而是在一旁鼓励他，同时很细致地观察着张经理的行为和表情的变化，测试完成后，李工拿着初步整理后的测试用例与张经理进行了确认，并告知会尽快将测试结果及会议纪要已邮件的形式发送。
该场景需要注意的有：
（1）告知用户测试的目的是产品而非人，便于减轻用户的顾虑
（2）鼓励用户说出自己的想法、感受和思考过程，便于需求挖掘
（3）用户测试过程中尽量不要提供帮助，适当给予鼓励，便于发现更多问题
（4）在听用户说的同时观察用户如何使用产品，包括操作过程和脸部情绪，便于需求分析
三、调研报告整理与反馈
在进行完调研访谈和可用性测试之后可不要忘了反馈结果，及时的反馈结果不仅能体现出调研人员的专业性给客户留下好的影响，也能及时发现调研中的遗漏、理解有误和不足的问题，最主要的是能够让双方对解需求采集进度是一致的，如何保证反馈的质量，会议纪要作为双方理解的依据有着很重要的作用，下图是本人会议纪要的大纲，提供给大家参考
可将用户访谈和可用性测试的过程和结果记录于会议内容中，如果有待确认事项，可放在下次会议进行确认。
四、总结
上文就是笔者在进行B端项目需求采集实践过程中所总结的方法和注意事项，主要介绍了调研访谈和可用性测试，当然因行业和经验的差异，可能存在不当或错误之处，希望和大家一起探讨，另外做个小小预告下片文章将讨论如何做需求分析，感谢大家的阅读！
|
