3个步骤,做中后台产品的需求管理

栏目: 编程工具 · 发布时间: 5年前

内容简介:非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。

非技术型产品经理福音来了,和 程序员 不再撕逼,10天在线学习,补齐产品经理必备技术知识。 了解一下

释放双眼,带上耳机,听听看~!

00:00

00:00

在产品经理的工作中,需求管理无疑是最核心的工作内容之一,但如何做好这项工作呢?笔者将为我们 分析 个人怎么做中后台产品需求管理的思路和步骤。

3个步骤,做中后台产品的需求管理

中后台的产品往往是面向企业或者组织的产品。在进行需求管理时,除了要关注产品的实际使用者,还需要关注企业或组织的需求。

我们可以简单地把所要面对的用户进行分类:高层领导、中层管理者、普通员工。其特性分别如下:

  • 高层领导:关注长远期产品价值,希望通过产品能够对公司业务有整体的了解;
  • 中层管理者:关注目标的达成、关心业务流程的顺畅、各个环节的职责,希望对团队中的成员的完成结果有详细的了解;
  • 普通员工:关注自己需要进行的功能操作,及判断其操作的标准。

我们把需求管理划分为如下几个步骤:需求调研、需求分析、需求实现(优先级划分),其他的产品工作环节暂且忽略。

一、需求调研

在做需求调研之前,我们一定要确定调研对象,我们可以通过公司的组织架构,对整体的业务有一个初步的了解。如果已经配合过多次的项目,则要自己整理整体的业务流程中涉及的用户。

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

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

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

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

在会上,我们要尽可能地引导用户把需求描述的更准确,可采用如下固定模式:

(1)你们想在有哪些岗位或者角色?

(2)每个角色有负责有哪些业务?

  • 描述下该业务的流程是要解决一个什么样的问题?
  • 业务中涉及哪几个岗位或角色?
  • 业务的步骤有哪些,并简要描述下。
  • 有没有异常情况,异常情况如何处理?
  • 在管理上有没有什么要求?例如:异常预警;领导查看权限;领导才有的特殊操作;报表。

(3)每个岗位或角色如何进行汇报,有没有相关的报表格式

二、需求分析

通过以上的相关问题,我们可以清晰地了解到公司业务的基本情况,而以岗位或角色为切入点进行需求的调研,会十分方便我们后续进行需求分析。

中后台产品重业务逻辑,而业务逻辑就是通过每一个角色的一个一个操作动作串联起来的。

从收集到的需求中,分辨出来哪些步骤或逻辑能够在系统中实现,哪些不能。这样,能很好地划分系统的边界。

系统最擅长处理计算、存储、查询以及跨地域传输信息的工作,我们不能把所有的业务操作都系统化,系统如果管得过细会加重业务人员的负担。

在需求分析中,我们首先需要根据前面所整理的资料按业务功能建立用例图,用例图一般有三种元素:参与者、用例、系统边界。

用例图的绘制需要注意一下几点:

  • 以一个解决具体事务的流程为视角,一张用例图尽量把一个业务说清楚。
  • 用例图的描述要以用户的角度出发。例如:“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料;“更新员工信息”对于用户来讲又是做什么呢——更改员工资料;“删除员工信息”又是什么呢——员工注销。
  • 用例图也可以有层级,可以有系统级的用例图,也能有功能级的流程图。

我们根据用例图中定义的角色、操作,通过业务流程图按执行的时间顺序或分角色串联起来。

我们需要准确定义顺序、分支、循环等逻辑的判断标准,使其形成完整的业务流程。

在业务流程中,我们需要已明确的图示来区分系统完成和线下完成,且设计好从线下到线上、线上到线下的对接功能。

通常这种从虚拟到现实的对接功能,包含:导出、打印、发送、导入、上传等。在设计这种功能时需要注意相关的校验、去重、个性化定制等特殊的需求。

在需求分析阶段,我们经常会发现一些新的衍生需求,这时我们需要快速找到对应的干系人,与其沟通讨论。

用户在未见到系统之前,其提出的需求都有可能把某一些关键信息遗漏,有些他们习以为常的常识我们做需求分析的人是不知道的。

由于我们进行完需求分析后可能会发现有大量的需求要去实现。如果一次把所有的需求都进行实现,我们付出的成本太高,用户等待的周期过长。而且可能会发生实现的产品与客户的期望差距太远。

为了解决成本、周期、期望的问题,我们需要对需求进行优先级划分,以实现快速迭代逐步交付的目的。

通过快速迭代能够让用户提前接受产品,以矫正前期由于空对空造成的需求缺陷的问题,一般第一个迭代的周期在两个月之内为正常,后续的迭代需要维持在2到4周为最佳。

三、如何进行优先级的划分呢?

有一个基本的原则供大家参考:权利大的优于权利小的,相关度高的优于相关度低的,功能优于报表,正常优于异常。

如果使用原则是有冲突,则找到实际使用者中的业务专家,与其确定优先级,在汇报该权力大且相关度高的领导。

通过基本原则划分后,我们还需要组织相关的需求优先级确认会议,与相关干系人达成共识,让其了解迭代计划的具体情况。

而在每一周,我们均需要对迭代计划执行的情况以邮件的形式进行同步,对于核心干系人则可以在固定周期以汇报的形式同步情况。

本文由 @keeliu原创发布于人人都是产品经理 ,未经许可,禁止转载。

题图来自 unsplash,基于 CC0 协议

3个步骤,做中后台产品的需求管理


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Learning Python, 5th Edition

Learning Python, 5th Edition

Mark Lutz / O'Reilly Media / 2013-7-6 / USD 64.99

If you want to write efficient, high-quality code that's easily integrated with other languages and tools, this hands-on book will help you be productive with Python quickly. Learning Python, Fifth Ed......一起来看看 《Learning Python, 5th Edition》 这本书的介绍吧!

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具