|
|
|
|
|
|
|
由于目前自己主要从事供给运营方面的工作，主要是配合地面团队，协助商户，共同赋能我们的核心业务。这其中免不了经常对接地面团队，承接他们的产品需求，并将这些需求梳理后对接给pm。由于之前产品管理方面的经验并不足，这次也算是一个学习的机会。 以终为始，既然要和pm对清楚需求，那么在我这个工作场景中就存在两个关键点：准确理解需求；准确表达需求。 一、准确理解需求 地面团队能力模型侧重市场营销，因此他们所提出的需求更多是具体场景下的操作，比如查询xx店过去一年的经营数据并支持导出等。 这些都是一些碎片化的功能点，是事件。我们肯定不能将这些直接转述给pm，因为这并不是一个合格的需求。 为了更好地理解需求，我创建了一个表格，表格中主要分五部分，分别为使用对象、使用场景、需求分类、需求描述、需求详情。 1. 使用对象 地面团队提出的产品需求，主要分两种。一种面向内部协作工具，比如bd后台；一种面向商家运营工具，比如商家中心等。两种产品的使用对象是不一致的，前者是内部人员，后者是商家。 确定使用对象不仅可以协助我们后面思考用户使用场景，还可以帮我们过滤掉一些产品需求，因为有些需求涉及到商家等敏感数据，这类需求要过滤掉。 2. 使用场景 解决完“对象”，下一个就是“问题”。使用场景指的就是需求背后所解决的问题，还是刚才的例子，“查询xx店过去一年的经营数据并支持导出”，这个需求背后的使用场景就是地面团队需要后台提供经营数据查询和导出。 3. 需求分类 需求分类可以有助于我们快速归纳整理地面团队的需求。需求分3类，分别为数据需求，功能需求和交互需求。 数据需求包括新增/修改字段计算逻辑等。 功能需求最多，概括起来就是查询、导入、导出。注册、文件上传等都属于导入。 交互需求包括页面功能区分布及功能点（事件）串联逻辑。 4. 需求描述 描述就是基于使用场景（问题）后给出的凯发官网入口的解决方案，如新增某某功能点等。 5. 需求详情 详情即地面团队所反馈给我们的“需求”，但是我们需要按照操作流程 功能点（事件）的形式阐述出来。这样做是方便pm能够更好地理解我们的需求。 借助这个梳理结构，我们基本可以快速理清地面团队的产品需求，然后和pm进行对接。 当然，当我们自身是需求发起方的时候，我们也可以按照这种形式进行梳理，逻辑清楚后写出来的需求文档也更有可读性和实操性。 二、准确表达需求 关于如何准备表达需求，我想很多朋友和我接下来写的内容一致，那就是写出一份好的需求文档。因为我们毕竟不是pm，直接输出prd文档未免有些大题小做，我们倒是可以借助prd的书写格式和逻辑来规整我们自己的需求文档，以此更好地表达我们的需求，避免增加沟通成本。 需求文档不同的公司都会有不同的书写要求：以我们公司为例，大家常用的需求文档共分五个部分，分别为需求描述、需求详情、预计收益、优先级备注、开发进度。 1. 需求描述 如前文所说，描述就是基于使用场景（问题）后给出的凯发官网入口的解决方案，如新增某某功能点等。这点是为了让pm能够迅速定位自己要做什么，有一定的画面感，接下来的沟通会更效率一些。 2. 需求详情 为了更好地讲述需求，我们常通过背景 需求内容的组合阐述。背景解答我们在什么样的场景下诞生了这个需求，而需求内容一定要结合流程和功能点进行描述。 举一个例子： 后台增加回答任务项目，可展示任务详情。这个需求并不明确，首先它不是详情，只是一个描述。详情需要结合功能点来说。正确的表述应该是任务基础信息包括xxx，输入项包括xxx等。 需求详情书写的过程中尽可能配图，这样有助于提升画面感，增设或修改的功能点通过序号1、2标识出来也会更加形象。 3. 预计收益 这点主要是给pm做优先级排序用的，常规下我们任何一个需求都是为了提升核心业务去做的，无论是收入还是利润，无论是短期见效还是长期见效。尽量将预计收益量化出来也有助于我们自身判断需求的合理性。 4. 优先级排序 在我们内部合作的时候，这项是pm给填写的，只不过我们作为需求的发起方也可以给出自己的预估优先级，供pm参考。为了拉齐认知，我们常规用重要性和紧急性进行分配，如重要不紧急、紧急且重要等。 5. 开发进度 同样也是pm来填写的，只不过放在这里有助于我们判断项目进展阶段，把控整体节奏。 需求文档是一个对自身想法梳理加工呈现的过程，它需要沟通，但是是需要带着逻辑和pm沟通，否则怀揣一腔热血盲目去聊，浪费时间且没有效率。 |