业务讲不清需求,需求调研难?这套调研模板值得收藏!
午夜梦回,我总是想不明白——
为什么业务总是说不清需求?
为什么做好的需求也没人用?
直到我回溯了跟业务沟通的一幕幕....
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、如何解决?
◆ 首先需要保证自己对公司组织架构清晰,至少能够准确找到部门决策人。当对接人模糊时,可以及时和负责人沟通落实;
◆其次要保证关键对接人是否有确认需求的职能和权力,如果需求汇总并不是当前对接人的主要工作时,需要增加业务执行层的调研样本,以避免调研不够客观;
◆最后如果判断对接人的在岗状态不稳定时(比如只是上级临时安插),此时对于对接人提出的需求,优先级可做适当程度降低。当对接人无法达到对接要求时(不沟通、执行不到位),需要寻找合适时机,和部门负责人进行确认。
五、模板包(点击卡片链接下载):
帆软市场market.fanruan.com/template/20000713
项目自检表
战略层调研模板
业务管理层调研模板
业务执行层调研模板
使用工具FineReport:
最后分享一些相关资料: