欢迎来到加倍考研网! 北京 上海 广州 深圳 天津
微信二维码
在线客服 40004-98986
推荐适合你的在职研究生专业及院校
需求分析——需求调研的主要步骤及方法大王反国

需求分析——需求调研的主要步骤及方法

不管是公司安排的软件项目,还是合同项目。我们拿到一个新的软件项目,首先要做的事情就是根据现有的人力资源、技术能力、项目工期合理地制定项目管理计划。如果现有的人力资源或技术能力不能满足项目工期要求,则需要增加人员或提高人员的技术能力。项目管理计划内容可多可少,主要以自己能够管控项目开发为原则。一般说来,项目管理计划包括项目组织架构、工作分解结构、进度管理计划、需求调研计划、配置管理计划、质量管理计划。小规模的软件项目可以只有进度管理计划,进度管理计划将整个软件项目工作分解为不同的阶段,每个阶段的工作又分解为多个子工作,分解的子工作以1周以内完成为宜。进度管理计划的第一个工作任务一般是需求调研工作,需求调研工作的主要任务是调查系统需求、绘制需求模型、编写需求规格说明书。下面这张图给出了需求调研的基本过程和步骤。图 1需求调研的基本步骤需求调研的基本步骤是调查系统需求、编制事件列表、发现系统角色、编制用例模型、编制类图模型、编制界面模型、编制部署模型、最后形成需求规格说明书。需求调研的第一步是调查系统需求,调查系统需求的方法,在前面的课程我们已经讨论过了。在这里主要采用与用户的面谈方式,通过与用户的面谈,找出系统的相关事件,并写出事件列表。需求调研的第二步是依据前面给出的事件列表,归纳和抽象出系统相关角色,建立角色列表。归纳和抽象系统相关角色,要注意角色不是指具体的人和事务,而是表示人或事物在系统中所扮演的角色。需求调研的第三步是建立角色用例图,角色用例图是系统需求的功能模型,描述了角色的行为及角色间的关系。每个用例需要给出用例规约,用例规约描述了用例的用例名称、参与角色、与其它用例间的关系、前置条件、后置条件、操作流程、输入与输出数据项等内容。需求调研的第四步是根据角色和用例模型建立类图模型。一般说来,前面分析的系统角色就是系统中的对象,也称为类。类图模型描述了类的名称、属性及行为,以及类与类之间的关系。需求调研的第五步是依据角色用例和用例规约建立界面模型,需求阶段的界面模型只要给出原型就可以了,不需要考虑界面的美观性。需求界面模型可以使用PowerPoint、Axure RP等工具进行绘制。需求调研的第六步是确定系统的部署需求。部署需求主要由网络环境、硬件环境、软件环境组成的需求。网络一般采用网络拓扑图等模型,给出部署系统所需的网络环境需求;硬件环境给出部署系统所需的硬件环境需求;软件环境给出系统所需的软件支撑环境需求。最后形成完整的需求规格说明书,将前面的文字表格资料、绘制的模型、图片等内容放置到需求规格说明书中。需求调研的成果物除了需求规格说明书外,还有需求跟踪矩阵,编写需求跟踪矩阵主要目的是可以有效跟踪项目需求变更和需求实现,做到在需求和项目之间维护双向可跟踪性。跟踪需求是因为在系统研发期间,需求会由于各种各样的原因而发生变更,因此有效的管理这些需求和需求变更是很重要的,我们有必要去了解每个需求的来源以及对系统的影响。

敢不虚心

项目执行要点(2):项目调研

本文总结了项目调研的各项环节以及其中的要点,希望能给你带来启发,enjoy~一、调研准备甲方行业情况的了解、原网站的分析、同类网站的浏览。要初步明确项目的重点和难点,以及客户可能关注的地方,为实际调研做好准备。调研准备工作应对现有网站及类似项目案例进行分析。项目启动后3个工作日内,项目经理应编制好《项目调研计划》和《项目初步需求调研表》发送给用户,并与用户沟通确认调研计划。准备好初步栏目结构表,便于现场调研时沟通,可参考招标书、投标书、建设方案等中的栏目结构,或同类网站。产出文档:大型项目《项目启动介绍》PPT、《项目调研计划》、《项目初步需求调研表》、初步《栏目结构表》。二、启动阶段结束产生的结果和标志项目经理调研计划及调研文档准备完成,通知客户调研日程,发送《项目初步需求调研表》给用户做前期准备。三、调研阶段需求调研阶段,主要是为了与用户建立联系,弄清项目建设要求,包括:软硬件环境、页面设计、网站栏目、信息审核流程、互动办理流程、用户权限、数据移植、定制开发、上线时间要求等,并制定、确认项目需求说明书和项目计划,为下一步页面设计和实施工作打下基础。1. 调研的参与人员调研人员,一般是项目经理,有定制开发需求的,项目经理需向开发总监/开发副总协调开发人员参与调研。有些项目根据客户要求,还需要美工参与调研。根据项目规模大小,调研人员数量相对适当增减。到达客户处,项目经理需和客户负责人简单介绍一下调研计划(日程安排)及调研人员。2. 现场(调研)启动会大型项目应在项目现场召开项目(调研)启动会。参会项目组人员配备应尽量齐整(如美工、开发、实施),销售一般需要出席。根据情况可考虑协调公司高管出席。项目经理应准备并介绍《项目启动介绍》PPT(含:项目组人员介绍)。启动会完成后,可根据项目调研实际安排,部分人员逐步撤回公司配合后续工作。产出文档:《项目现场启动会会议纪要》。3. 调研的主要内容(1)摸清客户对项目的大体日程要求。(2)根据《项目需求调研表》,同时结合项目本身的内容,如合同、招标书、网站评测标准、客户的实际要求等进行调研并详细记录,并填写完成《需求调研检查单》,完成后一同提交至“OA-项目跟踪”中。(3)对于已有产品模块,通常不需要调研(一般销售前期会演示过产品)。如果客户不了解产品,可安排给用户演示产品,来获取需求。(4)在调研的过程中,客户方会主持召开主题不同的若干次会议。项目经理需要明白以自己为主,以《项目需求调研表》为基本框架,在若干次会议中涵盖《项目需求调研表》所列要点,同时深刻理解客户意图,抓住客户主要关注什么问题和想解决什么问题。如果客户没有主动开会的迹象,或者不知道如何配合我们进行调研,项目经理要主动建议客户分主题进行开会讨论,如日程安排方面、软硬件网络方面、定制开发需求方面、页面设计和栏目结构方面等。如页面设计需多层领导确认,或无法直接与最终确认人沟通,因建议客户采用“首页设计评审会”的方式来确定页面,并明确会议时间编制到计划中。数据移植工作非常重要,用户应提供原数据备份和数据表字段关系说明文档,便于移植。如用户无法提供,则需要签字确认《移植数据风险确认单》。对于定制开发需求方面,特别是较复杂的需求,希望由开发人员全程参与,此点极为重要。部分需求可能无法一次调研清楚,可安排在页面设计阶段过程中继续。如果是产品销售(实施型)项目,用户提出产品定制开发需求,因采用以下处理方式:第一步:先了解用户需求的真实原因,是否能在产品现有功能上变通实现。第二步:如果不行,委婉告知用户目前产品还不支持此功能,如果本次项目中需要定制开发来实现,会涉及一些开发费用(可以评估工作量后由销售来沟通),或者我们可将需求提交产品开发部门,看是否能加入到下一版本中开发。不影响正常使用、网站上线等需求,尽量沟通放入到下一版本开发实现(一般为3个月),签订需求变更单或需求确认单,并注明此需求不影响上线和验收。第三步:若用户坚持需要在本次项目中免费开发、确实影响系统正常使用或项目验收的,则应公司内部讨论后再答复用户。项目经理在调研结束后填写《项目-组件清单》,项目经理组织《项目-组件清单》沟通会,确认项目中采用的标准和组件。说明:计划编制前至少需明确80%-90%的项目需求,页面设计全部确认前项目需求应全部确定,或双方签备忘约定未定需求不作为本项目验收依据,否则不能开展实施工作,考虑项目暂停并撤离资源。产出文档:《用户项目组人员联系表》、《项目-组件清单》、《项目需求调研表》、《需求调研检查单》、《移植数据风险确认单》可选。4. 项目软件需求说明书和项目计划的编制(1)项目软件需求说明书项目调研结束后,由项目经理根据调研时在《项目需求调研表》中记录的具体需求,分类整理到“项目软件需求说明书”相应版块中,完成“项目软件需求说明书”的撰写,并由部门经理、项目总监审核后发给客户确认。针对部分未明确的需求、待确定的方案、超范围需求、项目风险等、应该在项目开工会上面进行讨论确定后,整理到“项目软件需求说明书”中。(2)项目计划如客户需要,可先给出项目计划的初稿(可按阶段划分的初步计划)。项目正式计划应在调研完成后5个工作日以内,由项目经理编制完成,部门经理、项目总监审核后提交DMS,并发给客户确认(发送给客户的项目计划,应该导出html或打印成PDF格式,便于客户查看)。注意事项:编制计划时,应考虑到多任务的并行,页面设计、系统产品部署、信息移植测试、定制开发应安排并行。编制计划时,应考虑用户确认时可能存在的修改、内部审核流程等工作冗余量。有定制内容的定制开发计划,开发完成时间一般应按项目要求在系统试运行前完成开发测试工作,最迟在网站/系统正式切换前必须开发测试完成。项目计划确认时,应与用户沟通解释计划安排,得到用户签字确认。项目计划的编制使用MS Project Professional2010。原则上,立项后15个工作日内应完成项目计划的编制与评审工作。若未完成项目计划活动就需提前实施项目,则必须提交《特批申请表》经分管领导批准后才能执行。但项目组必须在半个月内按要求补齐相关计划内容。产出文档:《项目软件需求说明书》、《特批申请表》、《项目进度计划.mpp》、《项目进度计划.pdf》、《项目计划和项目需求确认函》5. 项目风险管理报告编制大型项目调研结束后,项目经理应该根据项目调研实际情况,结合“风险管理库”中的风险经验,编制“项目风险管理报告”,并在项目开工会上进行讨论确定,最终与项目软件需求说明书、项目计划一同提交部门经理、项目总监审核。项目经理对项目风险进行管理,采取有效措施化解风险。同时,项目经理每周更新风险管理报告,与项目周报同时提交。产出文档:《项目风险管理报告》6.项目开工会前的准备针对大型项目(或项目经理觉得有必要的中小型项目),应召开项目开工会:调研结束后,项目经理需召开项目开工会。会议时间由项目经理决定。项目经理通知项目组全体成员在某时召开会议,必要时可通知分管领导参加。项目经理准备好调研需求、调研成果等相关文档资料,主持会议并和项目组成员讨论项目计划执行。7. 开工会参加人员项目经理、项目组成员,必要时通知分管领导参加。项目经理可以根据项目情况,邀请拥有同类项目经验的项目、美工、开发、售前、部门主管、其他业务或技术专家等人员参加。8. 开工会的会议内容要点项目调研情况沟通。项目范围讨论并确定。项目进度(计划)讨论并确定。硬件需求情况讨论并确定。软件需求的讨论并确定。外购软硬件的讨论并确定。网站结构及页面设计要求的讨论并确定。明确销售人员的承诺。项目风险及缓解措施的讨论并确定。要做会议记录,并在会后提交到OA的“项目跟踪”库中。产出文档:《项目开工会会议纪要》。9.“项目开工会”的几点说明“项目开工会”和“项目启动会”的区别为:前者时间点为“项目调研后”,目的为项目计划和需求内部讨论和明确,项目工作展开。后者时间点为“项目调研前”,目的为“项目调研”的准备和讨论。“项目开工会”和“项目计划和项目软件需求说明书”的关系:后者需要在前者中进行内部讨论和明确,确定后通过审核,并提交客户。“项目开工会”的形式,不要拘泥于会议形式,也可通过RTX、微信、YY语音等网络方式进行。10. 项目调研/项目开工会结束产生的结果和标志“项目计划”确定。“项目软件需求说明书” 确定。“项目软件需求说明书”、“项目计划”为里程碑文档。以上两个文档完成后需发给客户进行签字确认。文档签字确认后才可进行除“页面设计”以外的工作。本文由 @空杯前行 原创发布于人人都是产品经理。未经许可,禁止转载题图来自Unsplash,基于CC0协议

囧男孩

需求调研:掌握7个关键方法,高手都这么做

需求调研是一门非常深的学问,不仅仅要掌握专业知识,更要具备沟通、引导客户的能力。特别是项目调研过程中,遇到一些比较难沟通的客户,还需要我们具备相当高的情商,总之,项目经理或者需求经理,既要会“写”更要会“说”。今天小编和大家分享一些需求调研的经验,希望能够帮助到大家。1、见客户之前,先了解项目情况首先,项目已经到了需求调研阶段,必然经过了立项、投标等过程,所以需求人员要通过咨询立项人员、投标人员了解项目的前期情况,同时,认真阅读投标文件,保证见客户之前,已经有一定的项目基础。其次,通过官方网站,了解一些客户的基本信息及组织机构,确保我们能够对不同级别的用户有不同方向的引导。最后,见客户之前,需求小组内部最后进行一次沟通会议,保证所有掌握的知识是准确的、有用的,尽量不要在客户面前犯错误或者内部意见不一致。2、制定项目的调研计划制定调研计划的好处非常多,比如需求调研能够有序进行、需求人员能够合理安排工作计划、能够提出提出对客户的咨询问题等等,这些都不是我要列出这一章节的目的。个人认为,调研计划的目的就是让用户清楚我们的工作计划,根据工作计划来安排他们的工作时间。做过需求调研的人都清楚,客户的时间是需求调研最大的风险,所以,我们必须给客户强调我们的工作计划,确保客户有时间和我们沟通需求。3、调研过程中收集的内容调研过程中,需求人员会向客户收集一些资料,具体收集什么资料,不同的项目、不同的客户收集的内容是不同的,不再进行说明。这里要强调两个方面的内容:客户资料隐私内容的处理,需求人员向客户收集资料时,一定不要收集客户有隐私数据的资料或者保密数据的资料,一旦收集,后续如果有数据丢失或者泄露的事情,你是脱不了关系的。客户资料的保管,收集到公司的用户资料,在保管的时候,一定要分权限,比如资料通过SVN管理,一定要进行权限的分配,其次,如果收集的资质材料,一定不要乱扔,放到指定的地点。4、挖掘客户需求的方式制作demo,需求人员应该去客户现场前,制作相关的原型(不一定非常完完善,能够说清楚业务过程即可),在客户现场给演示原型,调研的效果会非常好。参与客户的实际工作,需求人员到达现场后,可以通过观察客户的实际工作流程,根据客户的实际工作流程整理客户的需求和问题,,调研的效果会非常好。小编认为,这两种方式是最有效的调研方式,也是常常使用的两种方式。5、换个角度,站在用户的角度考虑问题交流过程中,尽量用专业的词语和用户进行交流一定要考虑到用户的使用便捷性总结以往的实施经验,提出建议总结以往的实施经验,引导需求6、调研过程中,工具的使用功能结构建议使用:XMIND软件流程图建议使用:VISO软件会议纪要和调研报告建议使用:WORD功能矩阵和问题列表建议使用:EXCEL原型设计建议使用:AX图形设计或者界面设计建议使用:PS数据流程设计建议使用:POWERDESIGNER7、调研过程中,需要注意的事项如果客户允许,建议整个沟通过程中使用手机进行录音。沟通过程中,一定要一边沟通一边记录不同的客户,调研不同的需求,避免理解上的差错客户永远是对的(学会聆听,态度决定一切),不要一棒子打死异己的观点,尝试站在他人的立场思考问题,这样会更容易找到满意的答案。拒绝不合理的需求,但是要注意方法定期汇总的成果:什么情况下?什么人?做了什么决定?产出了什么?所有过程文档,能让用户签字的,必须要签字,这个是双方的一个保障。

三畏

B端需求调研:客户访谈操作详解

编辑导语:工欲善其事,必先利其器。在产品设计前需要通过调研详实的了解用户需求,才能设计出符合预期的产品。基于B端和C端的用户主体、使用目标、参与角色等因素的不同,在调研方法的实施中会存在差异。本篇以“用户访谈法”为例,讲述项目制的B端产品在用户调研准备、执行、总结各环节的操作方法及注意事项。一、为什么是“用户访谈”?为了满足我方项目目标以及客户(甲方)需求的双重目标,以及推动下一步工作,充分的需求调研是必不可少的。常用调研方法有很多,每个方法各有优劣。具体方法的选用要结合实际的资源限制情况来确定,比如调研时间、人力资源、调研环境。1. 行业研究说明:通过垂直的行业网站快速了解行业基础情况,包含产业链/供应链组成,业务在链条中所在位置等信息。或者通过研究竞品了解对应产品的构成和逻辑,以此反向解析用户需求;优势:找准信息渠道,能够快速获取相应行业或产品资料;局限:信息相对宏观或模糊,可作为基础储备,指导具体产品设计却不够。2. 调研问卷说明:通过设置一系列基础信息问题、围绕主题的逻辑问题,获取填写人对某事件或行为的观点、偏好等信息;优势:既可以用于定量分析也可以用于定性分析,同时易于大面积推广;局限:问卷篇幅限制,问卷发出后不能修改,回收质量得不到保障。3. 实习轮岗说明:通过调研人员在业务岗位上实际工作,可以深刻了解真实业务运作流程和各项细节点;优势:对该岗位负责的业务了解较为透彻,对业务细节掌握更清晰;局限:实习轮岗所需的时间过长。4. 数据分析说明:可以直观的了解过程数据、结果数据及各项指标等情况,通过数据(及趋势)推演出问题;优势:清晰明了,非常客观,能够做到有据可查;局限:要提前埋点或置入SDK等,才能对过去一段时间数据进行采集。注意数据解读误区。5. 现场访谈说明:是快速了解业务全景的方法,通过和各层级的相关负责人通话,可以直面问题和需求。优势:能够快速掌握主要情况,从战略、执行、经营等多个角度获取信息。局限:访谈的形式对业务细节无法很好掌握,需要后续补充完善。二、调研的“老套路”在实际操作中,调研可以分解成3个步骤:调研准备、调研执行、调研总结。1. 调研准备调研前的准备工作包含了明确调研目标、确认调研方法、选取调研对象、整理调研大纲等。1)明确调研目标在项目执行过程中会出现多次反复的调研,项目不同阶段的调研目标是不一样的。一般来说,项目初期的调研目标是明确项目背景、目标、目的、业务流程等;项目推进阶段会沟通具体的业务场景。如业务范围、业务场景、业务流程。2)确认调研方法我们知道了很多的调研方法,需要根据实际的情况选择恰当的方式。值得注意的是,和受访者建立良好的关系可以很好的帮助后续工作的开展。3)选取调研对象在资源允许的情况下,期望能够对接从领导层到执行层的所有主要干系人。当然,具体人员不是我们能确定的,但是需要拟定参与调研的角色和客户提要求。4)整理调研大纲提前了解客户基本信息,能够帮助我们设置调研大纲,包含调研思路和问题。需提前了解项目相关信息,整理业务场景中的问题;预设的场景会有偏差,要在调研时和客户确认。避免没有框架,造成调研不够全面。也可以准备需求调研表,便于做记录。2. 调研执行访谈式的调研不论参与人数多少,都是通过谈话的方式来进行。在执行中掌握访谈节奏和建立访谈框架是不可缺失的。1)掌握访谈节奏为了保障调研质量,需要稍稍掌控谈话节奏。同时根据客户描述调整自己的框架,提前准备的框架可能存在不恰当或缺失。2)建立访谈框架访谈内容应从整体到细节,从抽象到具体。可以从3个层面来聊:战略、战术、执行。战略:战略重要性不再赘述,调研首先明确项目在公司的战略定位和目标。项目也可能是企业战略的延伸的延伸,但是明确的定位和目标必不可少。战术:较为抽象的描述业务情况,战术决定了产品形态和管理模式。产品形态即产品如何运作,针对什么大场景做什么业务。管理模式即产品的管理策略,集中管理或分权管理,各方(大角色)能够参与什么任务。执行:下沉到业务执行层面,首先明确组织结构和角色配置,其次将角色代入到业务流程中,关注各环节各角色的任务来源,以及执行和交接的操作。3. 调研总结调研结束后一定需要输出完整的调研报告,表现形式不重要,目的在于调研情况的梳理和遗漏点的查找。1)现状梳理可以按照调研的层次,从战略、战术、执行不同层面进行梳理,将内容整理清楚即可。2)问题总结深入到具体业务流程,梳理当前整体及各环节存在的问题,并关注问题的影响面、紧急重要程度。3)总结报告输出报告后除了发送给内部相关人,也要同步给客户。注意和客户确认报告内容的准确性,如业务理解是否有偏差、问题梳理是否全面、问题优先级是否准确(可能因不同角色的关注点不同而出现偏差)等。4)其他补充并不是所有问题都要通过系统来解决,注意实物流和信息流的结合。现有的业务流程也不是一成不变的,而是随着业务发展和问题解决发生对应调整,带着发展的观念看问题。三、温馨的提示每个客户的访谈过程中都是不一样的,我们在访谈中围绕主题之外需要随机应变。基于过往经验,为了访谈顺利有以下几点需要注意:1. 从高级别人员开始访谈在和客户对接需求初期,建议先用高级别人员开始访谈。高级别人员不一定能提供最多的信息,但是能帮助我们从高层、全局的角度来看整个项目。帮助我们更好的把握主次关系,从全局到具体,避免一开始和执行人员对接后就陷入细节。访谈时可进行录音,便于结束后的内容回顾。2. 提前研究调研对象需要提前研究调研对象,是指尽早开始并保持持续关注。包含但不限于行业、企业、项目、关联业务、干系人。在关注项目干系人信息时,了解项目实施对不同干系人的影响,会出现推动力、阻力、或是脱离实际的需求等。因此调研是注意保持警惕,剔除干扰因素,不是客户方说什么就是什么。3. 保持和调研对象的联系访谈结束后需要建立和调研对象保持联系的渠道,便于后续工作中获得更多的帮助。几小时的访谈只能帮助我们大概了解业务的流程及客户的主要需求。后续重新梳理业务和需求时,肯定会出现信息缺失或待明确的内容。需要和客户进行多次沟通。不仅局限在需求澄清,在其他方便也会遇到需要客户帮助和配合的地方。本文由 @耳目不染 原创发布于人人都是产品经理。未经许可,禁止转载。题图来自Unsplash,基于CC0协议

夜与雾

如何制作培训需求调查表和培训效果反馈表?

小琪在顾城的帮助下,顺利完成了员工工资数据分析模板的制作,在年中经营分析会中,小琪的数据展示环节受到了集团上下所有领导的赞扬,顾城这个空降的高管也终于依靠实力在集团站稳了脚跟。年中经营分析会结束后,顾城跟小琪终于有时间休息一下了,两个人约着一起去吃法国大餐。“小琪,你现在可是集团的名人啦!”“顾城哥,别闹了,如果不是有你这个高人指点,哪有我什么事啊?”“还是你用心了,我带过的学生可不只你一个,但你是进步最快的。”顾城笑着说。……酒足饭饱之后,顾城对小琪说:“小琪,经过这个经营分析会,集团上下的领导都认为EXCEL在工作中很重要,希望可以针对EXCEL对公司内部的相关人员进行一下集中的培训。这个工作打算交给你来做。另外,咱们公司目前在培训方面还是还薄弱的,我打算借这个机会把公司培训工作抓起来。”“顾城哥,我行吗?”“没问题,不是还有我这个后盾吗?我会帮助你的!”“好!”听了顾城的话,小琪立刻信心百倍。回到单位,小琪便开始按顾城的要求开始设计培训方式的表格了。她从培训需求入手。由于这份表格没有数据汇总的内容,只有表格的设计与美化,小琪做起来得心应手。Step1:在A1单元格录入“员工培训需求调查表”,然后选择要合并的单元格区域,从A1到K1,在“开始”菜单中,选择“合并后居中”按钮,为表格添加表头(如图 61所示)。图6-1Step2:选择“开始”菜单,对表头的字体以及字号进行设置。在本例中,字体选择“微软雅黑”,字号选择“20” (如图 62所示)。图6-2Step3:将需求调查表的内容录入到表格中(如图 63所示)。图6-3Step4:点击“开始”菜单下的“边框”按钮,选择“所有框线”,为表格添加边框(如图 64所示)。图6-4Step5:在“视图”菜单下,将“网格线”旁默认的对勾去掉,使表格更加整洁(如图 65所示)。图6-5Step6:选择“页面布局”菜单,点击“纸张方向”按钮,选择“横向”(如图 66所示)。图6-6Step7:选择“视图”菜单,点击“分页预览”按钮,可以查看此表格打印的效果(如图 67所示)。图6-7就这样,小琪便将一份培训需求调查表制作完成了。打印好后,下发到各部门进行培训需求统计。接下来,小琪制作了一份员工培训效果反馈表,用来对参训员工进行培训效果跟踪调查。首先,小琪先将表格内容设计好,然后再将对应的单元格进行合并,接下来便开始进行表格的美化工作,比如设置字体,调整字号,并取消了表格中的网格线,为表格加上了边框,最终形成了如下效果(如图 68所示)。图6-8小伙伴们,你们学会了吗?欢迎留言跟小编讨论互动哟!大家还可以在网易云课堂找到孙晨老师的视频课程哟!如果觉得不过瘾,告诉大家一个好消息:顾城与小琪的故事即将在中国铁道出版社出版,书名为《HR精英都是Excel控:人力资源量化管理和数据分析(职场进阶版)》,很快大家就可以在书店里看到顾城与小琪啦!

伊甸园

培训需求调查的8种方法(上)

1 今日话题:1 今日话题:今天与大家分享的是培训需求调查的8种方法。我的小徒弟是今年的应届毕业生,目前我带着他做培训。前几天我们一起在做培训需求调查,他突然问我:“师傅,培训需求调查有那么多种方式,每次用什么方式,你是怎么选择的啊?”我反问他,是否了解这几种常用的方法和他们优缺点,他摇摇头。那么今天就让我们一起来看看这7种培训需求调查的方法。2 问卷法:问卷法是最普遍也最有效的收集资料方法,我们在使用app的时候,经常有提示框询问我们使用这个app的建议,前几年的时候,路边经常有填写调研问卷给小礼物的场景。调研问卷的成本很低,现在的企业只需要通过网络便可以开展大规模的调查。问卷法一个问题只涉及一件事,且多为打分的方式,所以种调查很难收回具体的信息,如果调查的事项过多,篇幅会很长。大规模发放的情况下,回收率也很难把握。一般问卷调查法有5个实施步骤:(1)制定调研计划。明确调研目标及任务,实施周期。(2)编制问卷。通常采用选择题和问答题的方式。比如你对本行业对新知识是否熟悉,有3个选项:非常熟悉、一般、很不熟悉;你需要何种程度的专业知识培训,有3个选项:高、种、低。(3)收集数据。这里包括发放调研问卷(表),并组织回收、整理。在这一步需要剔除无效对问卷,比如你设计的是单选,但是有人多选;或者问卷回答的不全面,一共有10个问题,他只回答了8个。(4)数据处理。我们将统计的数据、问题进行汇总、分析,客观的分析出每个类型的培训需求都有多少人需要。(5)得出结论。在这一步我们会编写出需求调研报告,并把调查结果提交给直接上级。我们的报告中要包含分发问卷的份数,回收的份数以及有效的份数。并且根据调查结果,列出哪几项培训需求比较强烈。3 访谈法:访谈法是通过与被访谈对象直接的对话,我们可以获得大量的信息。访谈法一般是在有一定培训需求方向的情况下才会使用,我们通过与培训对象的上级或者培训对象沟通,希望通过访谈进一步的对我们已有的培训需求进行确定。比如通过调查我们了解到,被培训者希望参加沟通方面的培训,但是沟通的培训有很多种类型,于是我们通过访谈法来确定,他们是需要辅导的沟通培训,还是向上级汇报为的培训。访谈法的优点是比较灵活,但他的缺点是主观性较强,需要我们的访谈者有很高的访谈技巧。如果采用访谈法,一般有以下7个操作步骤:(1)制定访谈计划。在这里我们需要确定访谈目的、准备相关资料,确定相关人员名单。被访谈者的人选直接关系到访谈的结果,所以如果是给有一定工作经验的员工进行培训,被访谈者要选择工作经验丰富的员工,或者这些员工的上级。(2)进行内部的访谈演练。在访谈练习的过程中,我们可以总结经验,发现问题后及时更正。在这一步需要确认访谈的问题,以及判断标准。(3)访谈开始。在这里我们需要介绍访谈对目的,并且营造适合交流的访谈氛围。这一部分的自我介绍和目的介绍很重要,如果员工以为你是为了对某人进行背景调查来进行访谈,或许就不会告知内心的想法。另外,如果员工很忙对时候,也不会有时间与你访谈。(4)收集数据。通过访谈我们获取了很多信息,我用到的基本工具是访谈记录表。其中的问题多为主观题为主,比如:员工特别出色的知识、技能表现在什么方面;员工特别需要学习的知识和技能有哪些。(5)访谈结束。我们与访谈对象确认我们的记录是否有问题。(6)访谈总结。整理访谈记录表,并收集归档。由于都是主观的记录,所以我们整理的时候需要小组成员一起去做。(7)访谈综合。对访谈资料进行总结,综合访谈中的发现及结论。4 现场取样法:现场取样法一般较多使用于服务性行业、生产型企业的培训需求调查(如饭店、操作工等),是通过选取培训对象现场实际工作的部分片段进行分析,以确定培训需求的一种分析方法。这种方法获取的资料十分的直观,但是成本较高,由于采样的时间有限,获取的信息也可能片面,采用的情况不是很普遍。我们一般采用的是通过拍摄或者现场的观察两种形式。在现场取样之前,我们一般会确认我们取样的维度,比如服务态度、必备工作实施情况等。然后根据录音、录像或者观察来确定被观察者的培训需求。5 观察法:观察法多用于生产型或服务性行业,是指到培训对象的实际工作岗位上去了解其工作技能、态度、表现,以及在工作中遇到的主要问题等具体情况的一种方法。通过观察法,我们可以了解到员工的实际工作环境,所取得的资料与培训需求的关联性更高。但是这种方法有可能影响到员工的正常工作,一个人在旁边看着你工作,总会感觉别扭。而且这种方法只能看到员工做了些什么,其中的逻辑并不能确定。观察法一般会有一个详细的记录,这个记录一般是以时间为轴线。比如10:00员工做了哪些工作;10:20员工又做了哪些工作。我们通过多份观察记录,由经验丰富的人员与我们一起去分析哪些方面需要进行培训。

伊戚

企业培训需求调研:如何设计一份好的调查问卷?

企业在制定年度培训计划或者开展一项培训之前,必先需要进行访查员工们的兴趣是什么,他们想要学习的重点等。如果题目设计得不痛不痒,根据无法挖掘出员工真正的兴趣所在,那么这份调研也就失去了其本身的意思。那么,进行企业培训需求调研时,如何设计一份好的调查问卷呢?问卷调查是一项有目的的研究实践活动,从理论指导实践的角度出发进行就是必须的,即设计问卷前必须要做好充足的理论准备,宏观层面上应做到以下两点:明确研究的主题是什么(如用户学习偏好、课程满意度等),以及明确想通过问卷调查获取哪些信息。值得注意的是,调查问卷的目的必须明确,要在开始设计调查问卷的问题的时候就提前想好,没有目的的问卷调查也是没有实际意义的。其次,就是调查对象。对于企业内部的培训来讲,我们调查的对象就是企业的员工,但是员工各部门不同所想要获得的培训需求也是不同,即对于不同的对象该怎么针对性来对样本对象展开调查,才不会因为样本的偏差而导致输出结果的偏差。此外,在问题的设计方面,我们需要遵循以下几个原则:1、可问可不问的坚决不问:要明白我们的问卷容量是有限的,因为填写者的时间有限。理想的问卷设计应是通过最少的问题获取最大的研究信息。2、无关研究目的的不问:时刻谨记一点:你的问卷是为你的研究目的服务的,千万不要本末倒置。3、创造性的设计问题:你的研究目的是抽象而宏观的,而你要设计的问卷则是通过具体的提问将研究目的进行微观层面上的分解,因此如何通过询问一个个背后有理论支撑与研究目的的问题来获取到你想要的信息,就需要你在问题设置上下功夫了。4、尽量多使用量表题:填空题少用,量表是一种比较规范而且简单容易理解,最为关键的是,其可以匹配非常多的研究方法。对于后期结果的分析也是比较容易。现如今的调查方式总体来说,分为网络调查以及线下调查。关于网络调查,在自己做好调查问卷之后,可以通过个人博客、微博、微信、朋友圈、论坛、贴吧等社交工具来进行调查,线下问卷调查则一般会采用纸质的形式,但是这种方式一方面成本高,另一方面回收率相对来说比较低,对于调研成果的转化也是比较难评估的。当然,也有很多企业利用在线学习平台进行问卷调查。就拿问鼎云学习平台来说,可以直接发布线上调研,方便快捷,调研结束系统可直接进行调研的结果分析,大大地节省了人力,培训师也可根据调研结果第一时间进行培训部署。问鼎云学习成立于1996年,23+年深耕企业培训行业,依托领先的研发技术与专业的运营能力,为企业提供体系化和智能化的在线移动学习解决方案!

其天机浅

B端产品需求调研(2):如何确定调研方式、调研问题

在上一篇中,我们明确了如何确定项目目标以及如何确定干系人,在本篇文章中,我们将梳理一下如何确定调研方式以及如何确定调研问题。首先我们再梳理一下B端产品需求调研的基本流程,如下图所示: 01 确定调研方式在实施需求调研之前,我们需要确定需求调研的方式,以便实施后续的需求调研。B端产品的需求调研方式主要有三种,分别为【行业研究】、【深度访谈】、【调研会议】,那么我们应该在怎样的情况下选择哪种具体的调研方式呢?以及每种调研方式应该注意哪些问题呢?下面我将梳理一下这三种调研方式的适用场景和注意事项。1. 行业研究B端项目通常包括企业内部自研项目和企业外部定制化项目,对于企业内部项目,产品经理对该行业已经具备一定的熟悉度,但是对于外部定制化项目,产品经理对客户所在行业的了解度相对较少,所以我们需要对行业做深度研究,并且对核心竞品的相关功能做深度体验;通过研究行业和体验竞品,快速了解行业并且梳理出调研过程中需要对受访者提出的问题。如果不进行行业研究,我们对行业的了解度不够,可能会导致在调研过程中大部分时间需要受访者给我们普及行业基础知识,导致需求调研时间长效率低;所以无论是内部自研项目还是外部定制化项目,行业研究都是产品经理必须要做的需求调研工作。行业研究的方法有以下两种:1.1 针对业务研究经典管理案例线上业务通常都是线下业务场景的映射,所以无论是自研还是定制化项目,我们通常都可以在市场上找到同类型的业务案例进行研究。比如某大型制造行业企业要研发供应链金融平台,由于目前商业信用仍然是货币信用的主力军,所以我们可以在网上找到很多相关的企业之间是如何根据贸易往来产生借贷关系的案例进行研究,以帮忙我们更深入的了解供应链金融的业务形式。1.2 体验市面上同类产品B端产品通常是企业内部管理软件,使用门槛较高,但是市场上仍然存在一些可以免费试用一段时间的B端产品。比如如果我们要体验企业项目管理协同办公软件,可以试用worktile;如果要调研商家管理后台,可以试用淘宝商家端;如果要调研CRM系统,可以试用sales force;另外也可以通过相关产品的专业服务提供商的官网了解其针对特定行业的解决方案。2. 深度访谈深度访谈是针对干系人逐一进行用户访谈的需求调研方式,也是可以最高效的了解需求的调研方式。深度访谈通常适用于受访人较少且受访人时间和空间条件都允许的情况,比如在企业外部定制化项目中,由于空间限制,我们可能无法对干系人进行面对面的深度访谈。在深度访谈准备阶段,我们需要注意以下事项:2.1 了解访谈对象的背景在确定干系人阶段,我们对干系人已经做了职位职级和岗位职责的初步了解,在此基础上还应该尽量对其做更深入的了解,尤其是了解其和其他业务相关方是否存在利益冲突,以避免在产品设计中出现业务各方存在利益纠纷的情况;比如CRM系统中,对KA客户定位不明确,可能导致出现KA销售和中小销售抢客户的情况。2.2 确定访谈对象的访谈顺序在进行深度访谈前,我们还需要明确访谈对象的受访顺序,通常需要按照职位由高到低的顺序进行访谈。因为对需求的了解需要从宏观到微观,从企业战略层到具体的业务形态,而战略层的需求调研对象通常为企业管理层,所以按照职位由高到低进行干系人的访谈,可以帮助我们从战略层到业务层逐层梳理和理解需求。如果不按照特定顺序进行用户访谈,则可能出现需求调研过程中不同调研对象的需求表述出现互斥情况,导致需要对其中一些调研对象反复进行深度访谈。2.3 制定访谈大纲在进行深度访谈之前,我们还需求针对每一位访谈对象制定一个访谈大纲,制定访谈大纲的目的是为了控制访谈节奏,使得我们清晰的明确应该先做什么,再做什么,防止在访谈的过程中出现跑偏导致最终没有达到访谈目标的情况。以下为深度访谈访谈大纲的模板,大家可以进行参考:3. 调研会议调研会议是对干系人集中进行需求调研的调研方式;调研会议较常用于外部定制化项目中,因为在外部定制化项目中,技术服务提供商通常和需求方不在同一地点办公,所以产品经理无法逐一对干系人进行深度访谈。但是为了高效的了解需求,通常会和需求方约定一个合适时间开展需求调研会议。在内部自研项目中,当项目干系人较多且干系人允许的调研时间不符合按照职位由高到低调研的需求时,我们也可以采用调研会议的形式,统一对干系人进行需求调研。在开展调研会议前,需求注意的事项有以下几点:3.1 明确会议目标在开展需求调研会议前需要明确本次会议的目标,明确的目标可以帮助产品经理在需求调研会议中把握会议的节奏和方向,因为需求调研会议可能出现业务方针对某个业务问题深入谈论的情况,会打乱会议节奏延长会议时间,此时产品经理应该以会议目标为原则判断是应该在会上继续讨论该问题还是应该会下另行组织讨论该问题,以保证高效的完成需求调研会议。3.2 制定会议流程调研会议本质上是将所有关键干系人集中起来进行统一调研,在开始调研会议前应该明确好会议流程,确定会议议题分别有哪些以及会议议题的先后顺序,按照层级关系罗列出我们需要问的问题,保证需求调研会议的高效性。02 确定调研问题确定调研方式之后,我们还需要确定调研问题,提前准备好调研问题可以帮助我们在会议过程中井然有序的进行提问,防止在调研过程中出现问题遗漏的情况。首先我们需要明确需求调研的框架,B端产品的需求调研是从【战略层】、【战术层】、【执行层】三个层面进行的;调研问题也应该围绕这三个方面进行准备。1. 战略层战略层是指该项目的战略定位和战略目标,我们需要确定该项目对企业整体战略部署的意义,因为战略层决定了企业的业务方向,明确该项目的战略定位可以帮助我们梳理项目的应用框架,在进行产品的模块和功能设计时,不仅要满足当前需求,也需要基于项目的战略目标考虑产品功能在后期的可扩展性。如果在产品设计前不了解项目的战略目标,那么产品的功能虽然满足本期要求,但是可能在后期会进行较大的功能调整。比如某国家级艺术品交易平台决定在故宫600周年之际联合故宫邀请国家级大师定制一批故宫藏品的高端仿制品,并通过线上渠道进行销售。我们了解到该企业当前的交易模式是通过线下竞拍的方式进行艺术品交易,企业想通过本次故宫600周年之际的艺术品售卖正式打通线上艺术品交易渠道,在产品设计前我们并未了解到该项目的长期战略目标是以国家级艺术品交易平台进行信用背书,打造自营+入驻的垂直线上高端艺术品交易平台,所以产品的整体架构均是以自营平台为前提进行设计的,导致后期引入商家入驻模式时候后端技术对订单、商品、供应商、分销商表都进行了调整。下面我梳理了针对项目的战略目标需要提出的问题供大家参考:2. 战术层了解项目的战术层也就是了解其经营策略,经营策略是指企业的业务模式,比如电商类项目中,项目的经营策略包括其平台模式、目标用户群体、商品来源、供应链策略、渠道策略、定价策略、营销策略等。了解企业的经营策略有助于帮助我们明确当前阶段的企业的应用架构,以及未来一段时间内企业的整体应用架构,并且有助于我们更深入的了解业务细节,以便根据业务细节进行产品设计。如果在产品设计前不了解企业的经营策略会导致产品功能无法满足当前的业务需求,比如在上述的艺术品交易平台案例中,由于没有明确其平台模式,我们的产品设计完全是按照自营模式进行的,后续又按照自营+入驻的销售模式进行了平台化改造。那么针对项目的战术层应该怎样进行需求调研呢,以案例中艺术品交易平台为例,我总结了如下问题:3. 执行层通过战略战术层的调研,我们对项目整体的战略战术布局已经有了较为清晰的认知,接下来要对业务细节进行调研。执行层的调研分为组织架构和业务细节调研。B端产品的实际使用人是企业中的员工,我们需要明确项目涉及的企业组织架构,因为在产品使用过程中,业务流程中的审批流,产品设计中的权限角色等产品都会是基于企业的组织架构进行设计的,而且在产品开始功能设计之前,首先应该明确的就是基于企业的组织架构的权限账号体系,所以在需求调研时,需针对企业架构做深入调研。产品设计是基于企业实际业务场景进行的,所以需求调研的核心也是业务细节的调研。针对业务的调研可以从业务流程、合规风控两方面进行。那么针对项目的执行层应该怎样进行需求调研呢,以案例中艺术品交易平台为例,我总结了如下问题:写在最后明确了调研方式和调研问题后,接下来要做的就是实施需求调研啦,在下一篇中我将以高端艺术品交易平台为例展示需求调研的输出文件,梳理如何输出一篇高价值的《需求调研总结报告》。感谢阅读,期待再见~本文由 @周伯通 原创发布于人人都是产品经理,未经作者许可,禁止转载。题图来自Unsplash,基于CC0协议。2年b端产品初级需求调研给作者打赏,鼓励TA抓紧创作!

君乎

一卡通系统项目业务需求调研

一卡通系统项目业务需求调研对于很多项目所要承载的业务,我们不是简单的把线下的业务流程梳理清楚就OK,而是要通过当前线下业务流程的梳理,找到线下业务存在痛点,然后在形成一卡通系统的线上业务流程时候,如何来更好的优化和调整;一:项目业务调研大纲一卡通系统二:项目业务调研内容1.项目承载的主要业务是什么?2.业务的特征和性质是怎样的?3.当前业务是怎样的?4.项目上线后,对业务流程有哪些改变的要求?5.业务涉及的使用角色说明?6.客户存在的问题和痛点是什么?考勤管理业务1.考勤主要是处理员工出勤情况的考勤系统,需要了解目前客户的考勤情况2.参与考勤的人员类型有哪些?3.参与考勤人员的数量是多少?4.考勤管理的方式使用哪种?(刷卡、指纹、面部以及刷卡、指纹、面部的组合)5.考勤管理需要提供组织结构6.考勤管理需要提供人员的基本信息(工号、姓名、部门等)7.考勤管理需要提供详细的上班时间段8.考勤管理需要提供详细的班制信息9.所有的请假、加班等是否需要审批,是否通过平台?如果通过平台,请提供各种假类的审批流程10.是否存在特殊班志,需要特殊处理的?如果有,请提供名称和相应说明11.对于考勤数据的分析结果,都需要知道哪些内容12.考勤的管理方式及管理流程13.目前由哪个部门负责人员的考勤管理?14.都有哪些业务表单?通道闸业务一卡通系统1.通道闸的数量?2.通道闸安装的位置?3.通道闸通行的人流量?4.通道闸识别的方式?5.通道闸的通行宽度?6.通道闸通行的人员类型?7.人员通行的授权管理部门?8.人员通行的管理流程?停车场业务一卡通系统1.停车场管理系统的数量是多少?2.停车场管理系统安装的位置?3.每个位置的车流量是多少?4.车辆类型有哪些?(公司领导车辆、公司内部车辆、外部车辆、特种车辆、消防车、急救车等)5.车辆类型中一般会通行哪几个位置?6.车辆入场管理流程?7.车辆出厂管理流程?8.车辆管理部门?9.现有的车辆进出厂区的管理流程10.车辆的授权流程?11.车进出权限变更有哪个部门负责?12.需要查看什么报表?,报表应显示什么信息,关注那些数据13.管理要求上还有什么特使内容?消费业务1.明确采用何种卡作为消费媒介2.人员消费的权限从哪里下发?3.相应部门主要负责哪些工作内容?工作流程是什么?4.消费的模式有哪些?(定值、分段定值、金额)5.消费的人员类型有哪些?6.明确对于每类人员的发卡、退卡、挂失、换卡的管理部门?7.是否还存在其它功能,例如:补贴下发等8.消费报表的要求,是否存在财务标准报表?消费报表的内容?访客业务1.访客的管理流程是怎么样?2.哪个部门负责访客的管理?3.要明确管理部门,部门管理范畴、部门职能等

似趼

B端产品案例,剖析需求调研的方法策略

一、后端需求调研二、需求调研的落地方法三、后端需求类型与策略前后端分离的实现方式,使得每一个完整的产品体系都包含了前端和后端部分。相对而言,B端产品更依赖于后端部分的支撑。一些公司也习惯于将这些后端提供支撑的部分,称为“后端产品”。后端产品甚至不具有视觉化,而仅仅是一些中间件等。后端产品如冰山之下,却承担相当重要的幕后工作:支撑、运算、监控、调度、分配、统计分析、决策……由于后端产品部分的复杂性,因此负责这部分的产品经理,需要做更多、更深入的需求调研工作,才能完成方案设计。 一、后端需求调研需求调研,是需求分析的前题。需求分析,是产品方案决策的前题。从需求调研到产品决策,占据了产品经理80%的工作精力。由于调研和分析往往一起完成,所以在本文中我门统一将二者以“需求调研”代替。按通用的模型表达方式,我们可以简单画下:如上图:需求调研是一个过程,其产物是解决方案。后端需求研调,与前端需求调研很大的区别。比如用户的角色化、业务的全还原、场景的穷举、新旧逻辑兼容等。我们简单说下期中的用户、业务和兼容性的话题:1、用户后端产品的用户非最终的价值用户,而是服务人员(如客服、运营)。因此这些用户具有业务垂直性,是格式化的“人”,具有戒色性和行业属性。不同职位不同权重,关心的价值目标、决策权、使用人数不同。不同用户的具体使用场景不同。可以较容易的获取前端产品用户画像,因为我们自身或者所熟悉的人都在扮演着 前 端的角色,也就意味着设计过程中也很容易进行角色代入。而后端用户画像的获取往往艰难得多,最快捷的方式就是和公司的业务层交流,业务部门是最直接与客户打交道的,他们熟知大量的典型客户案例,可以帮助我们快速高效的描绘出用户画像。由于我们自身与后端用户的相剥离性,用户画像的作用显得尤为关键,可以时刻提醒我们是在为谁做设计,每一个关键诉求都在产品设计中有对应的抓手。2、业务业务目标——>诉求——>用户需求。业务手段——>途径——>产品功能。了解业务最好的方法,是轮岗参与业务环节中去。此外,更加便捷快速的方法,是调研访谈。调研之前,最好对业务能有大体的认知,安排好访谈的对象,提前准备好问题,让访谈更加高效。调研方式:访谈、数据分析、问卷调查、头脑风暴、德尔菲、观察,完成用户需求的收集;通过亲和图、提示清单等,整合需求信息。调研目标: 了解业务模式和业务特点 了解业务目标和业务规划 了解当前业务运转方式 挖掘当前问题与痛点对于后端产品,场景往往是很多的,需求的逻辑性大于故事性,需要由远及近规划处业务场景地图,才能勾画出业务架构,最终聚合出产品生态。在这个过程中,可以借助用户故事地图等等手段。通过整个业务的架构,厘清整个平台的用户对象、业务关系,也就确定了整个产品的业务边界范围,确定了整个团队内的业务语言。3、新旧逻辑兼容掌握后端产品逻辑真相的密码通常在开发手里,但是开发常常也需要临时查代码。在这种情况下,所有对旧功能的迭代都充满着风险。于此同时,无论是集成的大系统,还是拆开的烟囱林立服务,各个体系之间总是有逻辑调用。比如接口、公共数据等。后端产品大约60%的bug都是来自于这种牵一发而动全身的逻辑耦合。唯一能确保系统安全的办法就是做深入的可能影响的调研。为了避免空谈,我们结合《后端产品经理宝典》一书,介绍需求调研落地的常用方法,和需求的类型。 二、需求调研的落地方法1、过滤需求的方法做后端系统,要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词,反而是体现后端产品价值判断的基础。过滤需求的方法,就是通过一定的手段判断需求是否是伪需求,应该被过滤掉。(1)用户场景模拟法后端产品的出发点就是帮助业务用户,因此在调研需求的时候要模拟业务的场景,分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户,那么这个需求就可能是伪需求。以下面的案例说明:背景:“货到付款”类型的订单会因为缺货而无法发出,如果超过一定的时间,客服就会跟顾客沟通,帮顾客取消订单。需求:由于这种订单的数量还是蛮多的,逐个取消太费时间,因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析:调研到业务操作场景,是先找到该类缺货订单,然后和顾客沟通,顾客同意删除,才进行删除。也就是逐个沟通确认,再逐个取消订单的,所以“批量取消订单”无法被有效使用。因此,该需求是个伪需求,应该被过滤掉。(2)功能归属分析专门的系统做专职功能,有助于合理的产品体系建设。因此需求调研的时候,可以通过系统的定位,判断需求是否应该在该系统完成。如果不属于该系统范畴,那么直接说服需求方更换方案。以下面的案例说明:背景:CRM系统(顾客关系管理系统)有一个顾客标签生成功能,就是根据顾客的消费行为数据,自动对应关联上标签,如优质顾客、高潜力顾客、欺诈顾客等。需求:业务用户提出需求,除了做上述的基础标签之外,还要做出英语版本的标签(就是把标签文案翻译成英文),这样欧美员工可以在英语版本的系统下使用。分析:调研到翻译之后的标签不是在CRM系统使用的,而是给到SMS(客服系统)使用的。所以应该由SMS根据CMS提供的基础标签数据,自己做二次的衍生。之所以这样,首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求;其次,CRM系统已经完成了“接力赛”的第一棒,创造了基础数据,那么其他系统要特殊化使用,完全可以自行进行特殊化处理,无需耦合回CRM系统。结论:案例的需求本身是真需求,并且实现上也没难度,但是该功能的定位超出了本系统范畴,专门系统做专职功能,化衍生需求应该在下游执行。否则,耦合性过高只会增加系统的复杂程度,难以维护和扩展。2、拆分和聚合的方法(1) 拆分需求法收到的需求,很可能只是短短的一段话。但是不要高兴太早,可能这一句话暗含了很多线索,因此要善于拆分:先找他要解决的核心问题,再围绕核心点,理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研,最后再聚合在一起。以下面的案例说明:背景:订单业务的类型很多,订单退货之后需要创建售后单据,但是因为数量大,所以花费很多人力,且手动创建有出错的风险。需求:业务提出的需求是“增加退货订单自动创建售后单的功能”,这是个一句话需求。分析:该一句话需求,其实包含了多种具体的订单类型和场景,那么我们就要拆分调研,拆分的维度比如:自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等,其中每一个维度就相当于一个小需求。这里不一一展开。(2)聚合需求法拆分法是对单个需求分解成若干小需求进行调研,聚合法相反,是找到许多个相互关联的小需求的共性,然后统筹成一个大需求去完成。例如:由于业务用户分散在不同的部门,各自为政,于是张三、李四可能都对一个业务流程有相同的需求,或者对同一个功能有相同的优化期望,结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划,聚合在一起当作一个需求来调研,最终输出一个整体的需求调研结果。3、利用辅助功能调研需求调研产品现有功能,可以用来确认原有功能的逻辑,或者确定新需求方案是否可行。比如业务用户需要更新一个功能,为了避免更新出错或遗漏,产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例,记录操作方式、状态变化、数据流向等。看看下面的例子:背景:从销售网站获取到OMS系统(订单管理系统)的订单信息中带着顾客的邮箱。顾客下完单,可能会在销售网站修改邮箱,而此时已经获取到OMS的历史订单中的邮箱是不变的。需求:顾客若在销售网站修改邮箱,要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析:需求是很明白的,也有它的意义,但有风险。因为我们知道订单信息贯穿于整个订单流转过程中,牵扯到订单编辑、审核、取消、配货、发货等,而这些环节跳转的触发条件可能就是某个信息更新(这里面就可能包括有邮箱更新)。因此,更新邮箱是否会影响流程中的某些环节,一时间很难准确知道。于是,我们可以采用预测试的方式,设计测试用例,在测试机运行一些订单,观察各个环节邮箱变更的影响,然后收集起来分析对策。测试法就像是探雷一样,主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。4、“拔萝卜带出泥”的方式调研需求调研需求时,产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明:背景:公司入驻到销售平台后,销售平台会对入驻的店铺的违规行为进行罚款。需求:业务用户提出需求,将销售平台的罚款数据抓取到订单系统,关联订单数据,以便进行人工分析。分析:第一步,先拆分需求,确定什么是罚款数据,总共有哪些罚款种类,需要对接哪些罚款种类,罚款数据与订单系统关联方式是什么,是否都能关联到,关联不到怎么办,销售平台是否已经提供了公用的罚款接口,Token(请求权限)如何获取,抓取频率怎么样,数据增长幅度多大,获取之后做哪些展示和搜索,用户权限怎么设置,需要和订单系统做哪些交互,该需求的价值是什么……第二步,挖掘需求:是否需要作分析功能,分析功能的规则是什么;是否需要做监控和预警,是否需要指派负责人;其他业务人员是否也有类似需求,其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式,连带出更多需求点。将上述调研结果重新组装起来,得到一个系统化的完整需求。罗列出需求要点和对应的验收目标,这样使得需求具象化,同时又不会遗漏细节,内部充实,外部闭环,并且进行了价值挖掘,做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能,超出业务的预期。5、需求得分权重法该方法的思路就是将需求质量的维度进行权重,然后对需求进行打分,根据最终得分的多少排列顺序。可以采用五个维度:重要、紧急、收益、成本、风险,其中成本和风险是给予负分,五个维度的分值权重分别为30%、30%、20%、10%、10%。那么一旦对需求打了分,就可以用分数*权重,得到最终得分。注意:负分的要减。并且为了方便计算,分值最好设置0.5-5.0之间,或者0-10之间。这样避免打分的跨度过大出现较大偏差。如表所示,需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5,需求3的得分为-0.1。由此可以判断需求的价值顺序为:需求1>需求2>需求3。对于需求3,可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计,但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从,而只是把它当做一个辅助工具。6、其他需求调研工具需求调研适合核心环节,该过程就会涉及到很多工具或分析方法,以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。 三、需求的类型和态度笔者对B端或泛后台产品需求的一个定性划分:粗浅需求、噱头需求、踢球需求、过剩需求、建设性需求。1、被动的粗浅需求这类需求,属于想当然的需求,不考虑系统的兼容性和业务兼容性的。比如:电商场景中,要求:若库存为0,则果断给予下架;库存变为非0,果断自动上架。这种强制自然是存在极大风险的。并且库存为0也有曝光的价值;非零也有下架的场景。二者不等同。这种情况下实际是“概念偷换”的错谬,无库存=下架。对这类需求,产品可以持保留态度,持续观望,收集更多用户的深层次数据反馈。但不能轻举妄动。2、战略的噱头需求这种很好理解,很多公司其实都是这么玩没的。比如:看到竞争对手有的功能,我们要有;对手无的,我们也要有。这样可以显得产品更强大。或者是强行“组合创新”:一个做医药电商的,你让他做直播带货,且不说是否合规,你能想象药师在店里当着店长的面做网红吗?这种情况下实际是“感觉谬误”。理论上,产品经理需要拿数据论证的。所以产品经理能做的就是慢点做,保留资源。找机会慢慢把意见渗透到高层,试图止损。3、隔壁的踢球需求在多组织的团队中,这种踢来踢去丢需求的情况相当普遍。比如,对医药商品,配置一段免责声明,展示在商城。那么让商品后台在商品维度加字段并传给前端,看似从后端到前端,且商品维度的,似乎没错。但是没必要的。因为,这是共性字段,商品维度几乎不需要重复维护,也没有操作差异性。这类需求,产品经理需要从分工、系统职能、收益考虑,将事情客观表述出来,完成博弈。4、客服的过剩需求这类需求,往往是客服传达来自用户的需求。通常目的很明确,但是对功能设计进行了干涉,可能影响产品的分析。比如,客服传达某O2O用户的需求:要在商品的实际销售价旁边,展示线下零售价格。产品:然后呢?客服:若对比到差异,则修改线上价?产品:怎么修改? 客服:在线下零售价的基础上按公式计算,比如上涨1%,得出线上零售价,然后逐个编辑。产品:是否可以理解为,目的是让线上价格,按自己期望的卖,不取线下零售价? 客服:是 产品:那么为什么不在根源处理呢:创建一组用于线上销售的价格,直接引用不就可以了吗?这类问题,一定是要挖掘到用户的场景的,从用户的场景下寻求同理心,不受制于现有功能的设定。只有这样才能不受局限,找到用户的初心。以解决问题为标准。5、产品经理的建设需求所谓建设性需求,可能是每个产品经理心中都有的夙愿。前提是,产品经理的决策正确。比如:自主优化产品模型,拆分微服务,界面统一等,统筹规划和重构的类的内容。若前四类需求过多,将会挤压产品的建设性需求。产品经理能够腾出手来做一些真正正确的事情,往往能对全局带来增益。都看到这里了,点个关注吧!END