内容简介:非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。
非技术型产品经理福音来了,和 程序员 不再撕逼,10天在线学习,补齐产品经理必备技术知识。 了解一下
释放双眼,带上耳机,听听看~!
00:00
00:00
在产品经理的工作中,需求管理无疑是最核心的工作内容之一,但如何做好这项工作呢?笔者将为我们 分析 个人怎么做中后台产品需求管理的思路和步骤。
中后台的产品往往是面向企业或者组织的产品。在进行需求管理时,除了要关注产品的实际使用者,还需要关注企业或组织的需求。
我们可以简单地把所要面对的用户进行分类:高层领导、中层管理者、普通员工。其特性分别如下:
- 高层领导:关注长远期产品价值,希望通过产品能够对公司业务有整体的了解;
- 中层管理者:关注目标的达成、关心业务流程的顺畅、各个环节的职责,希望对团队中的成员的完成结果有详细的了解;
- 普通员工:关注自己需要进行的功能操作,及判断其操作的标准。
我们把需求管理划分为如下几个步骤:需求调研、需求分析、需求实现(优先级划分),其他的产品工作环节暂且忽略。
一、需求调研
在做需求调研之前,我们一定要确定调研对象,我们可以通过公司的组织架构,对整体的业务有一个初步的了解。如果已经配合过多次的项目,则要自己整理整体的业务流程中涉及的用户。
在确定了调研对象后,需要组织专门的需求调研会议。会议形式可根据实际情况而定,但一定要通过邮件的形式完成会议邀请和会议纪要。
在需求调研会议上,我们需要对参会人进行一个初步的判断,有两个标准:权利和相关度。
- 权力大、相关度高的参会人提出的需求或问题,一定要进行详细地了解,并记录清晰;
- 而对于权利大、相关度小的参会人提出的建议,则需要虚心接受,若不能进行实现需要及时说明;
- 对于权利小、相关度高的人需要重点关注,在会后可与其进行更多细节性的讨论;
- 而对于权利小、相关度低的人则充分听取其意见即可。
以上分类,也是各类用户的需求产生矛盾时解决问题的标准:第一类人的需求最需求优先解决;其次看权利小、相关度大;再次看权利大、相关度小;最后一类视情况进行完成。
在会上,我们要尽可能地引导用户把需求描述的更准确,可采用如下固定模式:
(1)你们想在有哪些岗位或者角色?
(2)每个角色有负责有哪些业务?
- 描述下该业务的流程是要解决一个什么样的问题?
- 业务中涉及哪几个岗位或角色?
- 业务的步骤有哪些,并简要描述下。
- 有没有异常情况,异常情况如何处理?
- 在管理上有没有什么要求?例如:异常预警;领导查看权限;领导才有的特殊操作;报表。
(3)每个岗位或角色如何进行汇报,有没有相关的报表格式
二、需求分析
通过以上的相关问题,我们可以清晰地了解到公司业务的基本情况,而以岗位或角色为切入点进行需求的调研,会十分方便我们后续进行需求分析。
中后台产品重业务逻辑,而业务逻辑就是通过每一个角色的一个一个操作动作串联起来的。
从收集到的需求中,分辨出来哪些步骤或逻辑能够在系统中实现,哪些不能。这样,能很好地划分系统的边界。
系统最擅长处理计算、存储、查询以及跨地域传输信息的工作,我们不能把所有的业务操作都系统化,系统如果管得过细会加重业务人员的负担。
在需求分析中,我们首先需要根据前面所整理的资料按业务功能建立用例图,用例图一般有三种元素:参与者、用例、系统边界。
用例图的绘制需要注意一下几点:
- 以一个解决具体事务的流程为视角,一张用例图尽量把一个业务说清楚。
- 用例图的描述要以用户的角度出发。例如:“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料;“更新员工信息”对于用户来讲又是做什么呢——更改员工资料;“删除员工信息”又是什么呢——员工注销。
- 用例图也可以有层级,可以有系统级的用例图,也能有功能级的流程图。
我们根据用例图中定义的角色、操作,通过业务流程图按执行的时间顺序或分角色串联起来。
我们需要准确定义顺序、分支、循环等逻辑的判断标准,使其形成完整的业务流程。
在业务流程中,我们需要已明确的图示来区分系统完成和线下完成,且设计好从线下到线上、线上到线下的对接功能。
通常这种从虚拟到现实的对接功能,包含:导出、打印、发送、导入、上传等。在设计这种功能时需要注意相关的校验、去重、个性化定制等特殊的需求。
在需求分析阶段,我们经常会发现一些新的衍生需求,这时我们需要快速找到对应的干系人,与其沟通讨论。
用户在未见到系统之前,其提出的需求都有可能把某一些关键信息遗漏,有些他们习以为常的常识我们做需求分析的人是不知道的。
由于我们进行完需求分析后可能会发现有大量的需求要去实现。如果一次把所有的需求都进行实现,我们付出的成本太高,用户等待的周期过长。而且可能会发生实现的产品与客户的期望差距太远。
为了解决成本、周期、期望的问题,我们需要对需求进行优先级划分,以实现快速迭代逐步交付的目的。
通过快速迭代能够让用户提前接受产品,以矫正前期由于空对空造成的需求缺陷的问题,一般第一个迭代的周期在两个月之内为正常,后续的迭代需要维持在2到4周为最佳。
三、如何进行优先级的划分呢?
有一个基本的原则供大家参考:权利大的优于权利小的,相关度高的优于相关度低的,功能优于报表,正常优于异常。
如果使用原则是有冲突,则找到实际使用者中的业务专家,与其确定优先级,在汇报该权力大且相关度高的领导。
通过基本原则划分后,我们还需要组织相关的需求优先级确认会议,与相关干系人达成共识,让其了解迭代计划的具体情况。
而在每一周,我们均需要对迭代计划执行的情况以邮件的形式进行同步,对于核心干系人则可以在固定周期以汇报的形式同步情况。
本文由 @keeliu原创发布于人人都是产品经理 ,未经许可,禁止转载。
题图来自 unsplash,基于 CC0 协议
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
深入浅出WebAssembly
于航 / 电子工业出版社 / 2018-11 / 128.00元
WebAssembly是一种新的二进制格式,它可以方便地将C/C++等静态语言的代码快速地“运行”在浏览器中,这一特性为前端密集计算场景提供了无限可能。不仅如此,通过WebAssembly技术,我们还可以将基于Unity等游戏引擎开发的大型游戏快速地移植到Web端。WebAssembly技术现在已经被计划设计成W3C的标准,众多浏览器厂商已经提供了对其MVP版本标准的支持。在Google I/O ......一起来看看 《深入浅出WebAssembly》 这本书的介绍吧!