编辑导读：在产品经理的工作中，需求管理无疑是最核心的工作内容之一，但如何做好这项工作呢？本文作者作为B端产品经理，以教研系统为例，分享自己是如何进行需求管理的，希望对你有帮助。

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

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

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

一、需求调研

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

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

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

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

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

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

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

二、需求整理

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

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

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

三、需求分析

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

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

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

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

四、需求评审

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

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

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

五、优先级划分

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

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

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

六、需求变更

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

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

本文由@三只石头 原创发布于人人都是产品经理，未经允许，禁止转载

题图来自Unsplash, 基于CC0协议