业务讲不清需求，需求调研难？这套调研模板值得收藏！
午夜梦回，我总是想不明白——
为什么业务总是说不清需求？
为什么做好的需求也没人用？
直到我回溯了跟业务沟通的一幕幕….
1、【埋头苦干型】
IT：我要悄悄做系统，惊艳所有人
业务：我宁愿用Excel
——缺少需求调研环节，或需求调研不充分，导致新功能对业务产生新的负担，员工逐渐产生抵触情绪
2、【相看两生厌型】
业务：你做的东西不符合实际业务！
IT：可调研的时候你又说不出需求！
——前期需求调研不清，过程中需求一变再变，上线后才发现不能满足实际业务场景
3、【唯唯诺诺型】
业务：诶我看XX的新功能蛮好的，明天给我们加一下吧
IT：好的好的（管他合不合理，先加上）
——缺少明确的需求调研起止点，项目过程中盲目承接需求，导致项目周期过长，开发计划混乱
4、【顾影自怜型】
业务：我们能不能实现一个XX功能
IT：我不行，我做不到
——只评估了用户提出的方案可行性，没有深度挖掘方案背后的使用场景，找到实际使用场景也许会有更好的解决方案
原来，从需求调研的阶段，就埋下了风险的种子。
需求调研作为整个项目的地基，影响着项目是否成功，那么应该如何科学的进行需求调研，才能充分挖掘业务需求呢？又是否有合适的调研模板呢？
一、明确调研目的与调研形式
调研开始之前，我们首先要明确本次调研的主要目标是什么。通常的调研目标有以下几个：
1、找全关键用户
2、获取关键用户的需求，明确需求场景，以及是否为业务痛点
3、初步验证我们预想的解决方案思路，能否解决实际问题
4、尽可能多的提前识别风险
接下来需要确定调研的形式，如：问卷调查、直接沟通等。其他的需求挖掘的方式，比如数据分析、观察法等，由于对数据质量、时间投入有一定要求，此次我们将基于最常用的问卷+直接沟通的调研方式展开。
为了保证调研的质量，能够进行充分的挖掘，我们接下来要对已知的信息进行梳理，并提前准备一些道具，推动此次调研进展更加顺利。
二、准备进行一场深度沟通
1、提前梳理已知信息，初步判断项目风险
通过梳理项目关键信息，可以判断自己对项目的价值是否了解。可以将关键信息梳理成一份项目自检表，如果在项目启动前，可以独立的填写80%以上的信息，说明该项目的价值比较明确，解决思路较为清晰，后续规划以及实施的动作也会更加明确，减少踩坑的可能性。
这里我们提供一份项目自检表，以供参考，可以根据自己的业务情况酌情调整。
1）项目自检表表样：
2）字段说明：
2、准备解决方案思路，解除沟通误区
调研的时候，往往会发现——用户并不知道自己想要什么，所以对需求进行引导是非常关键的一步。由于领导/业务人员与我们的专业背景和知识结构不同，为了更好的传达自己的想法，可以通过demo、案例，甚至手绘草图等形式简洁直观的展现效果，让对方能够跨越专业词汇，快速理解最终效果。
在这个阶段为了更加快速的呈现效果，可以充分利用帆软提供的已有资料：
① 丰富的demo库
② 各行各业的客户案例
③ 提供模板下载复用的模板商城
3、分层准备结构化的调研问题，有针对性的获取有效信息
不同角色的调研对象，对业务的了解深浅、以及视角都有所不同，所以分层调研可以帮助我们更准确的获取关键信息。而提前准备结构化的调研内容，可以避免在调研过程中被业务提出的想法牵着走，业务主导的调研，就会很容易收获五花八门的“解决方案”，却没有挖掘到真正的痛点业务场景。
一般来说，调研对象可以分为：战略层、业务管理层、业务执行层。
1）战略层：老板、高管
如果需求来自战略层，我们与之沟通可以了解到一些宏观信息：
项目需求是谁提出的，便于进一步识别项目干系人，推进项目的顺利落地
是基于什么原因提出的项目需求，以便对需求有全局性的了解，在设计规划阶段有一定的灵活性，能最大程度契合未来业务规划
整个系统需要实现什么样的效果，达成何种预期。对用户期望进行全面了解，拉通不同关键人之间的预期。
是否有已知的同类系统存在，他们在公司或行业内处境如何
2）业务管理层：财务、人事等业务负责人
这一层级的人员，能够清楚业务运作情况，同时能从业务全局协助梳理需求，并识别项目风险。我们从该层级人员的访谈中，需要了解以下内容：
业务部门的组织结构如何，是否存在频繁变动的可能
当前业务中有什么困境，哪些需要此次项目优先解决
业务中可能存在哪些风险
业务中有哪些关键角色
业务平时是如何运作的，每个业务节点，是由哪个岗位角色负责的
业务的流转是否需要审批，审批人员是谁
是否已经在使用其他的替代产品，在解决当前的业务问题中有什么问题？有什么可取之处？
岗位人员变动之后的业务流程、权限、数据等如何处理
说明：往往正向的业务流程梳理相对容易，项目风险通常隐藏在异常业务之中，所以需要重点关注业务管理层提出的一些问题，对后期划分需求的优先级比较有帮助。
3）业务执行层
该层级的人员最为熟悉业务运作细节，但同时对于业务全局缺乏完整认知，所以容易陷入对个性化需求的阐述。我们的需求调研中，针对这类人员需要增加访谈的样本量，避免被影响需求优先级的评估。我们从该层级人员的访谈中，需要了解以下内容：
确认执行层岗位的具体人数，合理规划调研的样本量，避免因样本量过少而调研内容有失客观性
每个角色在业务中的具体工作内容是什么
业务环节开始、流转、完结的标志节点是什么
业务处理的发生频次如何
执行中业务的难点或者处理起来最麻烦的地方是什么，为什么很难处理
过往是否出现过事故，事故原因是什么，后续是如何处理和规避的
了解执行人员希望本次项目能解决的实际问题点
是否已经在使用其他的替代产品，在解决当前的业务问题中有什么问题？有什么可取之处？
说明：哪怕是一样的问题，如果角色不同，我们可以获取的信息也会不一样，所以需要我们信息收集上来之后做合理的整体性评估。有条件的情况下，可以多参与、观察实际业务场景下各个角色的工作流程。
调研模板表样：
三、一些需求调研的技巧，让沟通更加顺畅
1）认真仔细倾听，及时记录。可以使用录音帮助记录。
2）尽量跟业务使用一套语言系统，避免过于技术的专业词汇，适时拿出demo案例或者画草图。
3）根据用户类型应对。以下是部分类型，仅提供一些个人应对建议。
①强势型：强势型业务方经常会提一些比较难实现的需求，可以先进行调研收集，后续规划阶段通过整体评估，以及行业案例、过往数据等客观事实等作为佐证
②随和型：随和型业务方比较好沟通，但可能主动性较差，需要关注挖掘到的需求是否为实际业务痛点诉求
③技术小白型：该类业务大概率很难阐述清楚自己的诉求，可以尽量引导还原业务场景，提供原型等方式辅助沟通
④业务专家型：该类业务会很明确提出自己的想法，甚至是系统实现方式。不能止步于他们提出的功能，要挖掘到原始业务场景，有利于后期给出整体实现方案。
注意：警惕用户直接给出的方案，要还原原始业务场景。多考虑：想要什么？要这干什么用？他为什么这么想？会不会有别的想法？
4）宏观需求很重要，但细节需求也很重要，会影响用户是否愿意使用系统。① 宏观需求◆功能大块：明确用户要通过系统做哪几件事；
◆ 业务场景：每个功能模块都有哪些业务场景；
② 细节需求
◆ 使用习惯
◆ 样式
5）警惕模糊性词汇，比如：我觉得，我估计。这类意见可能成为风险因素，难以明确的可以先进行标注，积累一定样本量后整体性评估。
6）注意需求调研的覆盖面，防止需求不具代表性。
7）明确业务侧关键对接人，在精不在多，通常确定1-2人，便于需求调研后解决疑问或遗漏问题。
8）没有需求如何引导？
① 首先，明确业务部门是不是真的没有需求？往往业务表现出没有需求，都是假象。大概率没有需求是因为：
◆不了解系统可以实现什么样的效果，不清楚哪里还可以优化
◆ 不知道新系统学习成本是不是很高，是不是会增加我的工作难度
② 如何引导？
◆ 已经做过的业务场景讲解，各个部门之前有共同之处可以迁移
◆ 其他外部行业标杆案例宣导，可以复用成功的经验
◆ 产品知识扫盲，减少业务对使用成本增加的担忧
◆提供官方的demo让业务用户去体验，直接感受产品使用
四、明确调研起止点，避免“反复无常”
需求调研结束后，一定要及时总结整理已经完成的调研内容，发给受访人员进行确认。如果有更改或放弃的需求也需要进行标注，并留存历史版本，以便复盘以及产生争议时回顾。
另外如果出现对接人众多，可能也会导致过程中需求频繁变更的问题，针对这类问题我们可以有以下应对措施：
1、 为什么会导致这类问题？
大概率是由于：
◆ 对组织架构不熟悉，找不到关键对接人，最后拉群拉了大几十人；
◆对接人本身不具备统筹权，频繁因为执行层或上级建议变更需求；
◆关键对接人转岗或离职。
2、如何解决？
◆ 首先需要保证自己对公司组织架构清晰，至少能够准确找到部门决策人。当对接人模糊时，可以及时和负责人沟通落实；
◆其次要保证关键对接人是否有确认需求的职能和权力，如果需求汇总并不是当前对接人的主要工作时，需要增加业务执行层的调研样本，以避免调研不够客观；
◆最后如果判断对接人的在岗状态不稳定时（比如只是上级临时安插），此时对于对接人提出的需求，优先级可做适当程度降低。当对接人无法达到对接要求时（不沟通、执行不到位），需要寻找合适时机，和部门负责人进行确认。
立即沟通
