笔者从事产品工作一年多，在工作以及和产品朋友聊天中发现，很多需求都会受到各方的质疑，其背后不能简单归类为沟通问题，更多的是没有真实用户数据的支撑。虽然他们都知道用户调研的重要性，但受限于资源和环境原因，他们并没有进行过有效的用户调研。
笔者通过学术项目学习过较为系统的用研理论知识，但在经历过实际的从0到1的项目落地工作中发现，产品经理自己就可以一个人用较低的成本进行快速高效的用户研究活动。
现基于自己的用研经历总结出了一套自己的方法论，希望能给到各位帮助和启发。
本文结构如下：
先从工作场景出发，分析需求质疑背后的核心问题以及主要原因，指出了以此导致的项目问题与影响，并提供了解决思路，再基于个人经验介绍一套可用的可自定义敏捷用研方法，最后提出了需要注意的问题。
一、需求质疑1.产品的高血压场景
立项评审会上，到了提问的环节，领导倚靠在椅背上，双手交叉，扫了一眼PPT上的用户画像，漫不经心地朝你问：
产品狗心中：^–^
还不容易你擦着汗熬过了立项，版本需求评审会上，客户端同事和服务端同事对视了一眼，干巴巴对你说：
产品狗：^–^
作为一个产品人，写到这里再回忆一下那时的场景，瞬间低下头看了下手表上的心率，果然变高了。
2.需求质疑的实质
很多人会把这些问题归咎为沟通层面的问题，例如需求的讲解不够简单而详细，没有让领导和开发听懂；又或者说是因为“魅力”的问题（？），让一个妹子产品经理来说可能就更合适了，当然也会有人说是开发的问题，开发就应该老老实实地接需求做事情就行了……
但一年后，两年后，三年后这种情况还会出现难道也是沟通问题吗？
现象反映本质，我们需要看到这类现象背后的实质问题：团队内部对目标用户的认知不统一。
无论是领导、开发、设计还是运营同事，他们尽管会有意识避免自己的主观偏见，但或多或少都会基于自己的经验来解读用户，自然导致对需求理解的不一致。
说的不好听点，他们不信任你的需求结论，甚至有些产品人都无法说服自己相信。
很多中小公司项目所谓的经过分析而得出的需求本身就是畸形的，因为需求结论背后的依据大部分是二手货。
什么是二手货？就是各类行业市场产品报告中的用户画像。
大家的检索能力都不差，拿到同样的报告数据，最后大多沦为主观否定主观之纯凭经验解读，那么作为领导、作为同事凭什么相信你的解读呢？
当这些数据只有少部分人拿到的情况下，数据才是可贵有效的，通过解读可以拿到超额剩余价值，但数据每个人都能拿到的话，那数据就变成了全行业都得到的相对剩余价值了。
之后就是看能否拿到更为详细的一手数据，数据越精确越独立，价值才会越高，解读才会让人信服（又卷起来了哈）。
所以，要保证团队对用户需求认知的一致，就需要保证基础的用户数据是真实有效的，你需要对当前项目的目标用户进行有效的调研。
二、用户研究的无1.无用研的原因
明白了很多人生道理，但还是过不好这一生。
作为产品人，自然知道用户研究的重要性，可实际上由于各种原因，用户研究最终还是不了了之，或者蜻蜓点水而散去。
主要的原因可分为外部和内部。
1）内部原因：产品人的用户意识不强
2）外部原因：公司部门的支持不足
很多的大厂都直接或间接地组建了自己的用户研究团队或用户体验团队，但很多的公司是没有足够的资源去建立用户研究部门或者团队，甚至连用户研究员都没有。
大多数小公司，处于成本的考虑，都可能会让产品经理既要负责交互设计，又要负责产品测试，对于“没有看得见摸得着的产出”的用户研究，公司更不会考虑花钱招人了。
当然了，还有其他一些众多原因，就不再一一列举了，但无论是什么原因，都不是不做用户研究的借口。
2.无用研的影响
1）影响其一：导致立项评审反复修改
2）影响二：开发理解不一致，验收易冲突
在需求评审和技术评估后，项目就进入了开发阶段，虽然开发同事明白功能所要实现的整体效果，但他们如果在前期没有和产品同事保持对功能背后需求的一致的理解，那么很多的细节就会存在问题，因为对于开发来说，“跑通了就问题不大”，若需要修改的东西涉及到底层的架构，那开发分分钟要撕了产品。
3）影响三：运营方案定位存在问题，ROI过高
严格意义上说，运营部门需要在立项的时候就要参与到沟通中，需要了解核心的需求，方便产品开发的时候他们准备方案的制定。
术业有专攻，方案的制定也是耗时耗力，若双方对需求和定位的理解不一致，最后投入的资金和活动必定是竹篮打水一场空，双方又陷入锅谁背的扯皮中。
所以，前期做好用研，保持各方认知一致，能够很大程度上减少后续的沟通成本和资金浪费。
三、敏捷式用研1.解决思路
首先，强化用户意识。
当对某事物的意识不坚定的时候，只要是个人，他就不会主动去付诸行动，哪怕是尝试了，一旦遇到他人的劝说或过程上存在困难，便会轻易放弃。
当你正在准备问卷的时候，同事拿着咖啡走过来看了眼说：“这个我之前做过的，没有什么用，看看报告就行了。”
当你完成一半的访谈的时候，你发现收集的答复非常凌乱，你心中是不是想过：“收集一半差不多了吧，就把这些数据自己优化处理下，作为自己观点的论据就行了。”
如果没有较强的用户意识，很难坚持下去。
其次，避免学术，敏捷处理。
商业产品，不是学术研究项目，不要带有书生气去看待问题，也不要去追求所谓的完美主义。
功能实现不了，那就降低维度换一种方式来实现。
麻雀虽小，但也五脏俱全。
最后，mvp快速试错，及时调整。
任何一种方法论不可能在初期就能一次成功，作为产品经理一定要在出第一版方案后，先找同事进行快速排查流程问题，再邀请小体量用户进行预调研，从中发现关键问题进行优化，再调整后才可大范围投入。
方法论并不是一成不变，一个项目结束后，需要针对性进行复盘，在下一个项目中继续发现问题、优化问题，方法论是随着项目经验的不断增多而越发完善的，会成为产品人的一大笔经验财富。
2.定义敏捷用研
敏捷式开发我们知道，那么什么是敏捷用研呢？
我们先看下传统的用研定义：
用户研究（UserResearch）是指基于以用户为中心的设计理念，为了确定用户需求痛点、提供设计启发与优化，通过各种不同方法调查研究产品潜在用户和现有用户的而开展的研究活动。
用户研究根据研究的重点，可分为态度和行为研究，根据研究方法的性质，可分为定性和定量的研究。其常见的方法类别有访谈法、观察法、问卷法、测试法等。
从上可以看到用户研究方法众多，有的涉及到非常专业的知识，包含了社会学、心理学等等，甚至一些严谨的活动会用到专业级设备，如眼动仪、生理监测等等。
实际上，我们没有必要（实际上没钱没人）做到如此严谨复杂，完全可以根据自己的需要进行方法的改造，主要维持其理念核心（道）不变，方法（术）和工具（器）都可以进行调整，这就是敏捷式用研。
个人将敏捷用户调研定义为：
基于现有项目限制条件下，选取并组合一定比例的结构性方法来对目标用户进行分批次的迭代式研究活动。
核心一：现有项目限制条件。
核心二：选取和组合方法。
核心三：分批次迭代式。
如果符合条件可配合研究的用户有限，可以进行分组，例如原本十人的焦点小组，可以分为两次五人焦点小组，根据前组情况调整下一组的提问内容。
四、QTI法
QTI法是笔者根据自己之前用研经历所使用的方法的总结，也可以说是敏捷用研下的一个方法模板。
QTI由Questionnaires（问卷）+Test（测试)+Interview（访谈）三个部分组成。
1.核心要素
1）要素Q：分为问卷调查和主观体验量表
量表主要用于产品测试后的感受量化工作，通过分数来统计用户的整体感受。
2）要素T：分为可用性测试和协作测试
可用性测试，不仅可用于本项目产品的评估，还可以使用在竞品上，帮助发现一些问题，提前避免。
协作测试，如若存在沉默用户（不发声思考）或涉及到多人配合使用的产品，可以组织多位用户进行测试。
3）要素I：分为个人访谈和多人访谈（焦点小组）
顾名思义，访谈对象是个人和多人（狗头），但一定要分配好活跃用户或意见领袖的比例。
2.举例说明
首先大家要明确一点，没有什么方法是一成不变的，QTI法并不是严格按照顺序进行执行，该方法根据项目的不同情况可进行自由组合和适当增减。
我的一个项目背景：
根据公司战略，负责一个APP从0到1的落地工作，但因为疫情大环境和支持不足原因没有做过用户调研，只是根据报告和竞品完成了1.0版本的功能开发，测试包出来的时候，我需要组织用户调研，一方面就是来挖掘用户需求以便后续迭代规划，另一方面就是发现APP的使用问题。
方法实例：
1）向上级申请许可并要到了一些奖品。
4）抓3位同事进行预先演练，调整内容描述和流程，再邀请2位用户进行预调研，确保流程无问题。
5）先进行个人调研，流程为问卷调查、APP可用性测试、量表填写、问题回顾以及访谈（QTQII）。
7）个人调研结束后，将三组的内容进行整理，提取关键的共同问题和差异点，以此调整后续小组调研的内容，尽快安排开发完成问题修复。
8）将小组人数分成两个焦点小组，流程为问卷调查、访谈讨论、APP可用性测试、量表法以及回顾法（QITQI）。
以上就是我当时处理用研的流程，基本上是按照实际情况进行调整的，例如个人和小组的APP可用性测试环节顺序是不一样的，主要是考虑到焦点小组耗时更长，访谈放在后期不容易进行问题的广泛讨论，放在前期效果更好。
以此类推，假如立项结束，有目标领域报告但无直接竞品，打算调研需求，那么如何处理呢？
方法例：
大家发现了，这里只会用到QI，按照实际情况减去了T的内容。
那么再比如：产品上线了，但使用流程存在问题，已经迭代了一个大版本，需要验证流程可用性，那如何处理？
方法例：Q（产品使用用户）+I（焦点小组收集反馈）+T（可用性测试）+Q（量表），当然严谨还是需要一批未使用过的用户过一遍流程。
3.三个问题
无论大家最后是采用大而全的方法好，还是采取短快的敏捷式也好，在面对用户提出的需求时，都需要注意三个问题：
第一个问题，如果做一个游戏项目，结果招来的人并不是那么热爱游戏，那么这个用户说的话就需要打上一个大大的问号了。
第二个问题，在和用户接触的时候，碍于情面或隐私，用户往往会说出自己认为可能合适的回答，这种回答一旦和产品经理的偏好接近，会直接影响到产品经理的后续判断。
第三个问题，用户反馈的内容，即“我需要一个XX”、“有一个XX功能就更好了”，这种功能上的回答往往都是基于他们的认知所得出的解决方法，就好比他们想要更快的马。
作为产品经理不能将用户所说的需求当作以用户为中心的圣旨，因为作为商业产品，必定是在商业、需求和技术中取得平衡，产品经理要站在更高的纬度去看待产品，而不局限于一些零碎的说法。
五、结尾
本文从需求质疑现象出发，分析了原因以及解决思路，提供了可供参考的QTI敏捷法，希望大家无论做什么产品，都能够切切实实去主动接触自己的目标用户，多一些实事求是与变通，少一些僵化和偏执。
本文由@苹果核原创发布于人人都是产品经理，未经许可，禁止转载