分享

如何做一次清晰的需求梳理

 渐华 2022-06-04 发布于山东
文章图片1

作为一名小白产品经理,在工作流程中做的最多的三件事分别是,第一:沟通;第二:需求梳理;第三:写文档。

今天我们不谈论如何沟通,也不交流如何写文档,前者靠奶茶,一杯不够,再来一杯,后者靠熬夜,加班不够,通宵来凑。

今天分享一下作为一名小白产品经理,我是如何来把复杂的需求梳理清楚的。

首先,在我的日常工作中,会接到两类型的需求,一类往往是来自供应链和客服部门,他们提出的需求往往是需求明确且目标清晰,比如供应链同学提出:现在这个商品上架太复杂了,我想要批量上架,比如客服同学提出:现在订单搜索条件缺少了手机号的搜索条件,我们每次通过昵称关键词搜索很麻烦,因为很容易出现同名的情况。

上述的需求对于小白产品经理而言,处理起来是比较顺手的,因为需求非常的明确,需要考虑的点比较少,你只需要按照既定目标去实现就好了,如果想要做的更好一点,可以适当多考虑考虑如何让功能变得更加智能化和自动化,来减少供应链同学和客服同学的操作成本。

这里补充一点:切记,一切从实际出发,要贴合业务,不要为了酷炫做一些毫无价值的功能。

那另一类需求往往都来自运营同学或者用户,他们提出的需求往往是不明确且需求范围非常宽泛的,比如A运营同学看到活动数据不好,提出:我们需要新的营销工具,我看到拼多多的拼团可以做裂变,能够拉新,那我们也做个拼团吧。

又比如某个资深用户提出:你们的APP对于我来说,太难用了,我根本就不知道这个旅游线路小朋友适合不适合,能不能给一些判断标准呀。

如果一旦碰上这样的需求,作为我这样的一名小白产品经理,我其实是不太会处理的,因为需求不明确,需要自己来深入挖掘需求,来定义清楚需求范围,那么这个时候就需要一套流程来做需求梳理,来帮助我提高工作效率,快速完成需求范围的确定,以及需求方案的初稿。

当然做需求梳理的前提条件是,你已经确定了这个需求是一个真实且具备价值的需求。

在这里,针对如何判断需求是否真实,以及是否符合当下产品阶段的目标,我们不做过多讨论,可以放在后面再说。

假设,我们现在接到了一个拼团需求,我们通过数据分析和事实推理,得出来结论我们的确是要做这个拼团需求,那么此时就有一个大问题,那就是我们做一个什么样的拼团?如果此时你跑去问A运营同学,那么大概率你会得到一个答案,那就是我们没有什么限制,只要能够实现拼团就好。

这个逻辑非常好理解,如果你问一个人,这件事情他要不要做,如果这件事本身对他没有坏处,那么大概率你得到的答案是他要做,因为人类总是喜欢得到的,而非失去的,不做就意味着失去,哪怕得到没有好处。

就像魂系玩家一样,千辛万苦受尽BOSS虐待得到的武器,真的会用吗?他们不一定会用,他们会高声喊出那句名言:可以不用,但是贵在拥有!

所以,此时作为一名小白产品经理,我们应该发挥主观能动性,来构建一套流程,来面对这样的需求。

在这里,我将这套流程,分为了三个步骤:

一、梳理流程

以拼团需求为例,我们需要去梳理流程图,这里可以分为两个视角,用户视角与业务视角。

用户视角即站在用户的角度上去思考,一个用户如果使用拼团的功能,需要完成哪些步骤,需要经过那哪流程。

业务视角即站在业务的角度上去思考,这里需要注意的是,业务视角往往是多角色的,因为一个功能很有可能牵涉多个业务角色,所以在思考时,应该针对性的先分散,再结合。先单独梳理清楚一个业务部门的流程,再去将整个涉及的业务部门流程串起来完成整个业务视角流程图。

这里额外提一点,那就是关于流程图颗粒度的问题,我作为一名小白产品经理,我经常会出现颗粒度过大或者过小的问题,导致看流程图的人体验不太好。造成这个问题的原因,就是在画流程图的时候,没有思考清楚看流程图的对象是谁。

在这里我分享一下三个颗粒度:公司层面、部门层面、角色层面。

  1. 公司层面:即你的流程图需要在公司会议上展出,那么这个时候,就需要注意流程图的节点应该具体的部门上面,不要细化到部门里面的角色是如何做的。

  2. 部门层面:即你的流程图需要在部门会议上展出,那么这个时候,就需要注意流程图的节点要细化一点,落实到部门角色是如何做的,但是不要深入某个角色的每一步操作,这样会导致过小的颗粒度。

  3. 角色层面:即你的流程图需要讲解清楚某个角色的流程,那么这个时候,就需要你需要细致到角色是如何操作,细化到一步一步的操作上来。如讲解清楚,供应链退货时,是先需要操作A,再填写B,最后通知C,而不是简单的一个供应链退货就搞定。

那么以这个拼团需求来看,我们用户视角的流程图就会是这样:

A用户——进入活动页面——浏览商品——下单——支付——分享——拼团完成——收货(当然这是举例子,实际情况会复杂一点)。

业务视角的流程图会是这样:

运营部门:完成拼图商品配置-完成拼团活动配置-完成营销活动页面搭建——发布。

通过两个视角的流程图,你就会得到一个功能是如何流转的,那么现在你就会发现新的问题,我们的功能,目前只有营销活动页面是有的,拼团商品和拼团活动都是没有的,我们需要新增功能。

当然梳理完流程之后,是需要和需求提出方核对流程的,确保大家的认知是一致的,不然就很容易导致返工

这个时候就进入了需求梳理的第二步:套公式列方案。

二、套公式列方案

1. 公式

场景——问题——需求——解决方案——影响范围——风险

我会使用这样的一个方程式,来填写每个字段,最终完成一个需求范围的确定和需求方案的初稿。

还是以上述的拼团功能为例,如果我们套入这个方程就会得到这样的一个答案:

  • 场景:运营(用户)想通过拼团活动完成数据拉升(场景),达到提高用户量的目标(目标);

  • 问题:现在后台没有配置拼团活动的相关功能;

  • 需求:需要实现拼团商品和拼团活动的配置。

2. 解决方案

  1. 后台新增拼团商品类目?

  2. 后台新增拼团活动模块?

  3. 这里需要注意的点是,此时不一定是最终方案,所以我们先给它标识为不确定的,以免来限制自己的思维。

3. 影响范围

在影响范围这里,我通常会分为三个方向列:前端、后端、通用。

  1. 以拼团为例前端影响的是:订单页面(新增拼团订单状态,来控制拼团成功才能发货这个逻辑)、营销活动页面(新增拼团活动入口)、新增拼团详情页、列表页等等;

  2. 后端影响的是:商品管理、营销活动管理、新增拼团活动模块、新增团单管理模块、订单板块等等;

  3. 通用影响的是:新的push策略、新的短信提醒策略。

这里需要注意的是,我并没有列出更多细节,其实还是有比较多的细节的,比如在前端-拼团详情页中,各个信息展示的优先级以及排布是如何的?比如后端板块中,团单生成的逻辑是什么?是否有自动成团等功能逻辑,这里我只是列出来大的功能点,真正工作当中是应该继续拆分这些功能点,直至无法拆分为止。

4. 风险

  • 拼团带来的大量用户,要注意防止羊毛党,所以在功能和技术层面要做防刷以及控制功能:黑名单;

  • 大量的支付需要提高活动时间内的服务器承载力。

OK,当完成上述套公式的步骤之后,我们就会得到一个初版的解决方案,这个时候,我们可以拿着方案去找运营A同学核对需求范围和初步方案了,也可以和产品组内同学做一个内部评审,看看自己的逻辑和流程有没有问题,或者是不是会出现其他未知的风险,有没有影响其他的需求。

当然,这里有个建议,那就是再去找运营核对和产品内部评审之前,我们如果有时间最好把上述的工作产物,放一放,这个时候就进入了需求梳理的最后一步。

三、放空脑子,避免思维定势带来的错误决策

为什么我们需要放一放需求,放空脑子,因为在处理需求过程中,由于大脑高度集中,每天都花大量时间来思考同一个维度的东西,很容易导致脑子有惯性,认为自己的需求方案是没有问题,因为你的一切思考逻辑在当时那个环境下是符合逻辑的,是顺畅的,这个时候很容易就掩盖住一些问题。

所以如果我们有时间,可以考虑把需求放一放,过一两天再回头看看,看看是不是当初的思考陷入了误区,或者是有更好的处理方案。这样可以拿着一份更完善的需求,去做交付。

四、最后

由于我只是一名初入门的小白产品经理,文中的方法和经验只是个人经验,没有什么指导价值和意义,希望读到的同学能够分享更多需求梳理的方法和经验,如果有人能够从中得到任何的帮助,那么就是极好的。

也希望更多的产品小伙伴能够来和我交流,我们一起沟通交流如何做好一个需求,做好一个产品,而不是每天都在思考如何做好一个产品经理。

本文由 @子 原创发布于人人都是产品经理 

题图来自Unsplash,基于CC0协议。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多