需求调研
2020-02-24 11:04:18 6 举报AI智能生成
ToB业务的需求调研，需要注意的事项
作者其他创作
大纲/内容
系统接口
调研对象：需求接口人/技术负责人
形式：访谈、观摩
调研提纲
有哪些系统和项目本身有关联，比如是否需要对接企业ERP系统或者POS系统
各系统厂家，接口负责人是谁，输入、输出关系，接口方式
接口的数量，对接的系统处于什么阶段，是否需要二次开发
接口资料的提供
注意事项
对有可能影响本项目建设周期的系统对接，要提前了解清楚
依据调研需求按功能照模块罗列问题
报告输出
用户调研背景：主要说明在什么情况下做用户研究，意义如何
用户研究目的：说明本次调研需要达到的期望和目的
确定用户研究方法：调研方法论，采用该方法的目的和意义
设计用户研究内容：主要针对谈话、绘图、业务资料等实际行内容的记录
确定用户研究角色：说明选择调研的用户群体、组织、数量及时间比例
验证用户研究结论：通过数据支撑定量分析，结合用户画像，为研究提供有理论证
解决策略：总结归纳，设计相应的解决方案
其他注意事项
需要针对研究对象、研究内容进行分组，比如调查的内容是基于什么领域，之前有什么解决方案
不能有错误的引导或者语言表述上的歧义、诱导等
需要控制时间，要点总结，针对必须处理的流程做着重调查和探讨，如果业务了解不是很深入尽可能事无巨细，不能遗漏细节导致调查准确度有偏差
针对不同的业务部门单独进行访谈，一对一或焦点小组讨论
尽可能模拟并参与到真实环境中，了解项目背景，可以猜测并模拟用户环境让用户确认流程是否符合操作并提出期望值
缓和情绪，不要急于直接切入主题，可以先聊聊其他部门的事情再延续到当前访谈主题/调研之中
系统要求
技术能力
用户、支付、下单等场景并发量及控制
系统的开放性，与其他系统的对接能力，如erp、第三方系统
系统的开发和拓展能力
安全性和故障率保障
运维服务，系统的监测、稳定等能力
系统功能、交互设计要求
架构能力
底层框架及中台设计能力
是否具备快速拓展和迭代的能力
微服务架构设计
项目背景
调研对象：公司领导、项目决策者、项目负责人
形式：访谈
调研提纲
整个方案的提出是基于战略规划还是用户需求如果是用户需求立足点是什么？如果是战略整体规划如何？
参与到项目建设的组织架构有哪些？需要针对这些组织架构单独设立问题和方案
提出需求的人是谁？是基于什么场景提出的？为何在现在提出？
目标用户群体是哪些？目标市场、目标用户是哪些？
产品目前遇到什么问题？是用户满意度？还是业务流程不全面？还是实际效果不明显？还是不足以提升用户效率？
符合市场预期么？或者需要达到哪些预期？期望值如何？
新建还是迭代？如果是新建原因是什么？如果是迭代是基于什么原因去迭代？
建设周期要求？如有版本/迭代需要如何拆分，任务检查点如何设定，里程碑如何
注意事项
以专业技术、业务方案提出者的角度去了解并调查问题，刨除主观条件的限制，有多大产品改进发挥空间
以聊天的方式，以案例来说明真实意图、建设目标、业务流程等重要内容功能
关注产品起绝对作用的人或者部门，抓住关键人物切入
切忌假大空，需要聚焦业务和规划本身，不要把用户提出的都当成是重要的，需求需要评审
项目业务
调研对象：具体业务负责人
形式：访谈+参照原有系统
调研提纲
业务承载的需求和要点有哪些？
业务特征和性质如何？是什么类型的业务？
面向的内部群体和外部群体？
当前的业务流程是什么样子的？每个业务逐一调研、节点流程和节点处理人是谁？
项目上线后需要对业务流程寻求的改变，如节点处理效率、数据安全性保密性和准确性、节点增删改查
业务涉及的使用角色，如岗位人数、角色在公司的职位、上下级关系、提供该角色的调研对象和时间安排
业务资料收集，如报表、单据、专业术语、产品资料、算法规则、逻辑条件等
注意事项
引导用户已真实案例来展示整个业务流程
关注用户流程中存在的问题和痛点，以及用户的期望
资料收集力求真实，对行业专业度要有所了解
如果有实际参与条件，进行现场观摩或参与，融入场景
需要注意样本的普遍性和代表性，要符合场景使用的用户特征，有针对性分析
项目角色
调研对象：业务代表
形式：访谈、观摩
调研提纲
角色岗位如何，在整个业务流程中处于什么地位，有哪些上下级交集
角色处理该项目业务相关工作内容有哪些，该业务输入、输出是什么，关系如何
业务工作中的依据、资料、表哥
环节中的痛点如何，比如各环节处理耗时、频率等
对项目建设性意见和想法
注意事项
除了收集口头描述，还需要结合实际操作
力求真实，发散型的思维和需求不去关注，着重于业务本身
需要引导业务代表去完成更多维度的思考
0 条评论
下一页
