118 lines
10 KiB
Markdown
118 lines
10 KiB
Markdown
|
---
|
|||
|
|
id: 如何做一次清晰的需求梳理
|
|||
|
|
title: 如何做一次清晰的需求梳理
|
|||
|
|
data: 2022年5月16日
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
作为一名小白产品经理，在工作流程中做的最多的三件事分别是，第一：沟通；第二：需求梳理；第三：写文档。
|
|||
|
|
|
|||
|
|
今天我们不谈论如何沟通，也不交流如何写文档，前者靠奶茶，一杯不够，再来一杯，后者靠熬夜，加班不够，通宵来凑。
|
|||
|
|
|
|||
|
|
今天分享一下作为一名小白产品经理，我是如何来把复杂的需求梳理清楚的。
|
|||
|
|
|
|||
|
|
首先，在我的日常工作中，会接到两类型的需求，一类往往是来自供应链和客服部门，他们提出的需求往往是需求明确且目标清晰，比如供应链同学提出：现在这个商品上架太复杂了，我想要批量上架，比如客服同学提出：现在订单搜索条件缺少了手机号的搜索条件，我们每次通过昵称关键词搜索很麻烦，因为很容易出现同名的情况。
|
|||
|
|
|
|||
|
|
上述的需求对于小白产品经理而言，处理起来是比较顺手的，因为需求非常的明确，需要考虑的点比较少，你只需要按照既定目标去实现就好了，如果想要做的更好一点，可以适当多考虑考虑如何让功能变得更加智能化和自动化，来减少供应链同学和客服同学的操作成本。
|
|||
|
|
|
|||
|
|
这里补充一点：**切记，一切从实际出发，要贴合业务，不要为了酷炫做一些毫无价值的功能。**
|
|||
|
|
|
|||
|
|
那另一类需求往往都来自运营同学或者用户，他们提出的需求往往是不明确且需求范围非常宽泛的，比如A运营同学看到活动数据不好，提出：我们需要新的营销工具，我看到拼多多的拼团可以做裂变，能够拉新，那我们也做个拼团吧。
|
|||
|
|
|
|||
|
|
又比如某个资深用户提出：你们的APP对于我来说，太难用了，我根本就不知道这个旅游线路小朋友适合不适合，能不能给一些判断标准呀。
|
|||
|
|
|
|||
|
|
如果一旦碰上这样的需求，作为我这样的一名小白产品经理，我其实是不太会处理的，因为需求不明确，需要自己来深入挖掘需求，来定义清楚需求范围，那么这个时候就需要一套流程来做需求梳理，来帮助我提高工作效率，快速完成需求范围的确定，以及需求方案的初稿。
|
|||
|
|
|
|||
|
|
当然做需求梳理的前提条件是，你已经确定了这个需求是一个真实且具备价值的需求。
|
|||
|
|
|
|||
|
|
在这里，针对如何判断需求是否真实，以及是否符合当下产品阶段的目标，我们不做过多讨论，可以放在后面再说。
|
|||
|
|
|
|||
|
|
假设，我们现在接到了一个拼团需求，我们通过数据分析和事实推理，得出来结论我们的确是要做这个拼团需求，那么此时就有一个大问题，那就是我们做一个什么样的拼团？如果此时你跑去问A运营同学，那么大概率你会得到一个答案，那就是我们没有什么限制，只要能够实现拼团就好。
|
|||
|
|
|
|||
|
|
这个逻辑非常好理解，如果你问一个人，这件事情他要不要做，如果这件事本身对他没有坏处，那么大概率你得到的答案是他要做，因为人类总是喜欢得到的，而非失去的，不做就意味着失去，哪怕得到没有好处。
|
|||
|
|
|
|||
|
|
就像魂系玩家一样，千辛万苦受尽BOSS虐待得到的武器，真的会用吗？他们不一定会用，他们会高声喊出那句名言：可以不用，但是贵在拥有！
|
|||
|
|
|
|||
|
|
所以，此时作为一名小白产品经理，我们应该发挥主观能动性，来构建一套流程，来面对这样的需求。
|
|||
|
|
|
|||
|
|
**在这里，我将这套流程，分为了三个步骤：**
|
|||
|
|
|
|||
|
|
## 一、梳理流程
|
|||
|
|
|
|||
|
|
以拼团需求为例，我们需要去梳理流程图，这里可以分为两个视角，**用户视角与业务视角。**
|
|||
|
|
|
|||
|
|
**用户视角**即站在用户的角度上去思考，一个用户如果使用拼团的功能，需要完成哪些步骤，需要经过那哪流程。
|
|||
|
|
|
|||
|
|
**业务视角**即站在业务的角度上去思考，这里需要注意的是，业务视角往往是多角色的，因为一个功能很有可能牵涉多个业务角色，所以在思考时，应该针对性的先分散，再结合。先单独梳理清楚一个业务部门的流程，再去将整个涉及的业务部门流程串起来完成整个业务视角流程图。
|
|||
|
|
|
|||
|
|
这里额外提一点，那就是关于流程图颗粒度的问题，我作为一名小白产品经理，我经常会出现颗粒度过大或者过小的问题，导致看流程图的人体验不太好。造成这个问题的原因，就是在画流程图的时候，没有思考清楚看流程图的对象是谁。
|
|||
|
|
|
|||
|
|
在这里我分享一下三个颗粒度：公司层面、部门层面、角色层面。
|
|||
|
|
|
|||
|
|
1. **公司层面：**即你的流程图需要在公司会议上展出，那么这个时候，就需要注意流程图的节点应该具体的部门上面，不要细化到部门里面的角色是如何做的。
|
|||
|
|
2. **部门层面：**即你的流程图需要在部门会议上展出，那么这个时候，就需要注意流程图的节点要细化一点，落实到部门角色是如何做的，但是不要深入某个角色的每一步操作，这样会导致过小的颗粒度。
|
|||
|
|
3. **角色层面：**即你的流程图需要讲解清楚某个角色的流程，那么这个时候，就需要你需要细致到角色是如何操作，细化到一步一步的操作上来。如讲解清楚，供应链退货时，是先需要操作A，再填写B，最后通知C，而不是简单的一个供应链退货就搞定。
|
|||
|
|
|
|||
|
|
那么以这个拼团需求来看，我们用户视角的流程图就会是这样：
|
|||
|
|
|
|||
|
|
A用户——进入活动页面——浏览商品——下单——支付——分享——拼团完成——收货（当然这是举例子，实际情况会复杂一点）。
|
|||
|
|
|
|||
|
|
**业务视角的流程图会是这样：**
|
|||
|
|
|
|||
|
|
**运营部门：**完成拼图商品配置-完成拼团活动配置-完成营销活动页面搭建——发布。
|
|||
|
|
|
|||
|
|
通过两个视角的流程图，你就会得到一个功能是如何流转的，那么现在你就会发现新的问题，我们的功能，目前只有营销活动页面是有的，拼团商品和拼团活动都是没有的，我们需要新增功能。
|
|||
|
|
|
|||
|
|
当然梳理完流程之后，是需要和需求提出方核对流程的，确保大家的认知是一致的，不然就很容易导致返工**。**
|
|||
|
|
|
|||
|
|
这个时候就进入了需求梳理的第二步：套公式列方案。
|
|||
|
|
|
|||
|
|
## 二、套公式列方案
|
|||
|
|
|
|||
|
|
### 1. 公式
|
|||
|
|
|
|||
|
|
**场景——问题——需求——解决方案——影响范围——风险**
|
|||
|
|
|
|||
|
|
我会使用这样的一个方程式，来填写每个字段，最终完成一个需求范围的确定和需求方案的初稿。
|
|||
|
|
|
|||
|
|
还是以上述的拼团功能为例，如果我们套入这个方程就会得到这样的一个答案：
|
|||
|
|
|
|||
|
|
- **场景：**运营（用户）想通过拼团活动完成数据拉升（场景），达到提高用户量的目标（目标）；
|
|||
|
|
- **问题：**现在后台没有配置拼团活动的相关功能；
|
|||
|
|
- **需求：**需要实现拼团商品和拼团活动的配置。
|
|||
|
|
|
|||
|
|
### 2. 解决方案
|
|||
|
|
|
|||
|
|
1. 后台新增拼团商品类目？
|
|||
|
|
2. 后台新增拼团活动模块？
|
|||
|
|
3. 这里需要注意的点是，此时不一定是最终方案，所以我们先给它标识为不确定的，以免来限制自己的思维。
|
|||
|
|
|
|||
|
|
### 3. 影响范围
|
|||
|
|
|
|||
|
|
在影响范围这里，我通常会分为三个方向列：前端、后端、通用。
|
|||
|
|
|
|||
|
|
1. 以拼团为例前端影响的是：订单页面（新增拼团订单状态，来控制拼团成功才能发货这个逻辑）、营销活动页面（新增拼团活动入口）、新增拼团详情页、列表页等等；
|
|||
|
|
2. 后端影响的是：商品管理、营销活动管理、新增拼团活动模块、新增团单管理模块、订单板块等等；
|
|||
|
|
3. 通用影响的是：新的push策略、新的短信提醒策略。
|
|||
|
|
|
|||
|
|
这里需要注意的是，我并没有列出更多细节，其实还是有比较多的细节的，比如在前端-拼团详情页中，各个信息展示的优先级以及排布是如何的？比如后端板块中，团单生成的逻辑是什么？是否有自动成团等功能逻辑，这里我只是列出来大的功能点，真正工作当中是应该继续拆分这些功能点，直至无法拆分为止。
|
|||
|
|
|
|||
|
|
### 4. 风险
|
|||
|
|
|
|||
|
|
- 拼团带来的大量用户，要注意防止羊毛党，所以在功能和技术层面要做防刷以及控制功能：黑名单；
|
|||
|
|
- 大量的支付需要提高活动时间内的服务器承载力。
|
|||
|
|
|
|||
|
|
OK，当完成上述套公式的步骤之后，我们就会得到一个初版的解决方案，这个时候，我们可以拿着方案去找运营A同学核对需求范围和初步方案了，也可以和产品组内同学做一个内部评审，看看自己的逻辑和流程有没有问题，或者是不是会出现其他未知的风险，有没有影响其他的需求。
|
|||
|
|
|
|||
|
|
当然，这里有个建议，那就是再去找运营核对和产品内部评审之前，我们如果有时间最好把上述的工作产物，放一放，这个时候就进入了需求梳理的最后一步。
|
|||
|
|
|
|||
|
|
## 三、放空脑子，避免思维定势带来的错误决策
|
|||
|
|
|
|||
|
|
为什么我们需要放一放需求，放空脑子，因为在处理需求过程中，由于大脑高度集中，每天都花大量时间来思考同一个维度的东西，很容易导致脑子有惯性，认为自己的需求方案是没有问题，因为你的一切思考逻辑在当时那个环境下是符合逻辑的，是顺畅的，这个时候很容易就掩盖住一些问题。
|
|||
|
|
|
|||
|
|
所以如果我们有时间，可以考虑把需求放一放，过一两天再回头看看，看看是不是当初的思考陷入了误区，或者是有更好的处理方案。这样可以拿着一份更完善的需求，去做交付。
|
|||
|
|
|
|||
|
|
## 四、最后
|
|||
|
|
|
|||
|
|
由于我只是一名初入门的小白产品经理，文中的方法和经验只是个人经验，没有什么指导价值和意义，希望读到的同学能够分享更多需求梳理的方法和经验，如果有人能够从中得到任何的帮助，那么就是极好的。
|
|||
|
|
|
|||
|
|
也希望更多的产品小伙伴能够来和我交流，我们一起沟通交流如何做好一个需求，做好一个产品，而不是每天都在思考如何做好一个产品经理。
|