B端产品需求管理:以教研系统为例

后台产品不像C端产品,它面向的往往都是企业内部人员,以教研系统为例。我们可以将需要面临的用户分进行分类为:高层领导、学院负责人、普通教研人员。其特性分别如下:

  1. 高层领导:关注长远期产品价值,希望通过大数据分析与AI能对公司业务发展有所提升;
  2. 学院负责人:关心业务流程的顺畅、各个环节的职责;
  3. 普通教研人员:关注自己需要进行的功能操作,及判断其操作的标准。

我们把需求管理划分为如下几个步骤:需求调研、需求整理、需求分析、需求评审、优先级划分。

一、需求调研

在进行需求调研之前,首先最重要就是需要确定调研对象,后台产品的使用者均为企业内部人员,所以我们可以根据企业的组织架构,对整体的业务有一个清晰的了解。

案例:公司决定开发是一套以大数据、人工智能等现代信息技术和认知科学为支撑、以线上线下混合式教学模式为驱动的集教学内容、教学资源、教学方法、和信息平台于一体的综合解决方案。而我只是负责其中的一个系统-教研系统。虽然系统使用者为公司总部的教研老师,但教研系统是整个业务中的起点与核心,所以依然需要对公司相关领导、教务老师、讲师进行调研。

在确定了调研对象后,需要组织专门的需求调研会议。会议形式可根据实际情况而定,但一定要通过邮件的形式完成会议邀请和会议纪要。

在需求调研会议上,我们需要对参会人进行一个初步的判断,有两个标准:权利和相关度。

  1. 权力大、相关度高的参会人提出的需求或问题,一定要进行详细地了解,并记录清晰;
  2. 而对于权利大、相关度小的参会人提出的建议,则需要虚心接受,若不能进行实现需要及时说明;
  3. 对于权利小、相关度高的人需要重点关注,在会后可与其进行更多细节性的讨论;
  4. 而对于权利小、相关度低的人则充分听取其意见即可。

以上分类,也是各类用户的需求产生矛盾时解决问题的标准:第一类人的需求最需求优先解决;其次看权利小、相关度大;再次看权利大、相关度小;最后一类视情况进行完成。

在会上,我们要尽可能引导用户把需求描述更准确,该业务涉及到哪些部门或角色,业务的流程的什么样的。

二、需求整理

整理好我们在会上记录好的需求,要让需求更加明晰有据可循。

下面是我对需求整理记录总结的模板:

  • 板块:该产品有多少功能模块。
  • 功能:所属哪个功能,例如课程管理 、资源管理、课包管理等
  • 需求类型:bug类需求、优化类、运营类、战略类等
  • 需求等级:根据需求的重要程度进行等级划分
  • 优先级:解决实现的先后顺序
  • 提出人:谁提的需求,可追溯。
  • 预计时间:预计上线的时间
  • 状态:可以分为未开始、开发中、测试中、已上线

三、需求分析

后台产品重视业务逻辑,而通过我们的需求调研,可以清晰知道业务流程,不同部门与角色的切入点。如教研系统的使用部门为公司教学部,根据角色的权限大小又可分为部门负责人、学院负责人、课程负责人、普通教研老师。涉及到其他产品为教务系统、网校、讲师端、学员端等。

从收集到需求、我们需求分辨出需求是否合理,哪些需求是能通过系统实现,哪些需求系统是不能实现,为系统划分一个边界线。

围绕产品的业务核心进行分析,目的是找到实际要做的需求,按照5W1H1V原则,将需求按照影响力、业务价值、主流程进行划分,评判出需求执行的优先级。

  • What(对象) —— 可以用这个产品或功能能做什么?解决什么问题?
  • Where(场所)——在哪会用这个产品或功能?
  • Why(目的) ——为什么需要这个产品或功能?和其它产品的区别?
  • When(时间) ——在什么时候会用这个产品或功能?
  • Who(人员) ——产品或功能为谁设计?谁来用?
  • How(方法) ——如何使用这个产品或功能?
  • value(价值) ——产品的价值?

四、需求评审

需求评审是各方对需求进行确认的过程,达成统一认知和共识,使需求能够推进实现落地。

在需求评审的过程中,一定要说明清楚需求的背景、价值、意义,而不是纯粹的需求讲解,这样有助于各方对需求的理解。

目前的技术是否能够实现此需求,例如由于目前数据量较小,缺少数据模型,没办法实现全面实现AI,所以当前的能力图谱这块功能暂不能实现。

五、优先级划分

需求分析完成之后,还是会产生很多需求待实现,实现需求的优先级也十分重要。

需求的优先级有很多种原则可以采用,最常用的规则:KANO模型、四象限法则、 ICE排序等。具体的说明就不再在这里进行。

产品经理,产品经理网站

优先级划分时,最重要的是梳理出业务的核心流程,优先完成核心流程的需求,再根据优先级一步步的去实现。如在本项目价值最大的功能就是大数据与AI,但由于技术与数据方面的原因只能排期在后面。

六、需求变更

在产品迭代过程中,需求变更事难以避免的,也是非常考验产品的需求管理能力的。特别是在B端产品中,一个需求往往会涉及到多个系统,甚至有时一个需求发生变更会导致现有的流程发生变化。

如教研系统涉及教务系统、网校、讲师端 、学员端、题库系统等。教研系统的需求发生变化,同步会影响到这些系统。所以遇到需求变更时,需求提升对变更需求的风险关注度。

 

本文作者@三只石头

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部