江苏龙网

  1. 首页 > 人文 > >

「人人都是产品经理」运营人如何解析需求，准确反馈给产品经理？


运营人工作中的一部分就是将需求反馈给产品经理 ， 并确保需求能够解决当前问题 。 那么如何让产品经理正确理解我们要的需求是什么样的、达到什么效果呢？笔者有两个思路——准确理解需求&准确表达需求 。
「人人都是产品经理」运营人如何解析需求，准确反馈给产品经理？
本文插图
由于目前自己主要从事供给运营方面的工作 ， 主要是配合地面团队 ， 协助商户 ， 共同赋能我们的核心业务 。 这其中免不了经常对接地面团队 ， 承接他们的产品需求 ， 并将这些需求梳理后对接给PM 。 由于之前产品管理方面的经验并不足 ， 这次也算是一个学习的机会 。
以终为始 ， 既然要和PM对清楚需求 ， 那么在我这个工作场景中就存在两个关键点：准确理解需求；准确表达需求 。
一、准确理解需求
地面团队能力模型侧重市场营销 ， 因此他们所提出的需求更多是具体场景下的操作 ， 比如查询XX店过去一年的经营数据并支持导出等 。
这些都是一些碎片化的功能点 ， 是事件 。 我们肯定不能将这些直接转述给PM ， 因为这并不是一个合格的需求 。
为了更好地理解需求 ， 我创建了一个表格 ， 表格中主要分五部分 ， 分别为使用对象、使用场景、需求分类、需求描述、需求详情 。
1. 使用对象
地面团队提出的产品需求 ， 主要分两种 。 一种面向内部协作工具 ， 比如bd后台；一种面向商家运营工具 ， 比如商家中心等 。 两种产品的使用对象是不一致的 ， 前者是内部人员 ， 后者是商家 。
确定使用对象不仅可以协助我们后面思考用户使用场景 ， 还可以帮我们过滤掉一些产品需求 ， 因为有些需求涉及到商家等敏感数据 ， 这类需求要过滤掉 。
2. 使用场景
解决完“对象” ， 下一个就是“问题” 。 使用场景指的就是需求背后所解决的问题 ， 还是刚才的例子 ， “查询XX店过去一年的经营数据并支持导出” ， 这个需求背后的使用场景就是地面团队需要后台提供经营数据查询和导出 。
3. 需求分类
需求分类可以有助于我们快速归纳整理地面团队的需求 。 需求分3类 ， 分别为数据需求 ， 功能需求和交互需求 。 数据需求包括新增/修改字段计算逻辑等 。 功能需求最多 ， 概括起来就是查询、导入、导出 。 注册、文件上传等都属于导入 。 交互需求包括页面功能区分布及功能点（事件）串联逻辑 。
4. 需求描述
描述就是基于使用场景（问题）后给出的解决方案 ， 如新增某某功能点等 。
5. 需求详情
详情即地面团队所反馈给我们的“需求” ， 但是我们需要按照操作流程+功能点（事件）的形式阐述出来 。 这样做是方便PM能够更好地理解我们的需求 。
借助这个梳理结构 ， 我们基本可以快速理清地面团队的产品需求 ， 然后和PM进行对接 。
当然 ， 当我们自身是需求发起方的时候 ， 我们也可以按照这种形式进行梳理 ， 逻辑清楚后写出来的需求文档也更有可读性和实操性 。
二、准确表达需求
关于如何准备表达需求 ， 我想很多朋友和我接下来写的内容一致 ， 那就是写出一份好的需求文档 。 因为我们毕竟不是PM ， 直接输出PRD文档未免有些大题小做 ， 我们倒是可以借助PRD的书写格式和逻辑来规整我们自己的需求文档 ， 以此更好地表达我们的需求 ， 避免增加沟通成本 。
需求文档不同的公司都会有不同的书写要求：以我们公司为例 ， 大家常用的需求文档共分五个部分 ， 分别为需求描述、需求详情、预计收益、优先级备注、开发进度 。
「人人都是产品经理」运营人如何解析需求，准确反馈给产品经理？
本文插图
1. 需求描述
如前文所说 ， 描述就是基于使用场景（问题）后给出的解决方案 ， 如新增某某功能点等 。 这点是为了让PM能够迅速定位自己要做什么 ， 有一定的画面感 ， 接下来的沟通会更效率一些 。


推荐阅读


上一篇：『真诚阿宅』新iPad Pro，释放生产力

下一篇：「智能手机」终端再受冲击无奈砍单 产业链却在危机中迎来转机