善用三个方法,拒绝靠「想」做需求分析

21 评论 16137 浏览 154 收藏 9 分钟

需求分析不是仅靠“想”就能完成的,还需要依据严谨而科学的分析方法。

网上有很多需求分析的文章,通常它们的需求分析步骤是使用马洛斯需求模型,然后分析用户和场景,最后分析用户期望。这样就完成了需求分析,然后开始做原型PRD。

可是具体怎么分析呢?怎么将用户需求转化可见的原型?相信大家读完也是一知半解。在整个过程中,完全靠产品经理头脑风暴?

我认为这只能算「需求挖掘」。需求分析应该是严谨而科学的,不仅仅是靠「想」。当然,可能这是C端产品业务较为简单的原因。不同于C端需求,B端需求都来至于垂直行业,高度贴合客户业务。所以,B端需求分析,需要有一套结合业务的分析方法。本文主要分享我的B端需求分析方法。

从宏观,我将需求按其生命周期分为用户需求、功能需求和产品需求。用户需求是原生的需求描述,可能仅仅是一句话。比如:“我需要一个客人点餐的功能”。功能需求是我们所要实现产品的具体功能。产品需求则会落实到具体功能如何实现。

从产出上分析,我需求分析个阶段的产出依次分为功能列表、需求功能对照表、功能清单/信息架构。

开始分析之前,我首先会先整理需求。将需求池中需求的来源、优先级标注清楚。B端产品的需求通常来源于客户、老板、竞品和对业务的深度建模分析。优先级,笔者主要划分为高、中、低。

我的需求分析方法,主要分为三步场景分析、角色分析、业务分析。整个分析过程高度依赖UML。下文以餐馆点餐系统举例分析。

一、场景分析

场景分析目的是为角色分析和业务分析打下基础。主要通过与客户沟通,了解清楚用户的需求背景和业务背景,对需求有个明确的理解。除了通过客户沟通外,也可以使用其他的调研或分析方法。如果,机会合适的话,最好深度参与一下用户的业务。我在做商家服务产品时,为了客户的打单发货业务,就曾亲身参与过用户的打单发货。

场景分析过程中,需要整理出场景故事、用户沟通记录等。

以简化版餐馆门店点餐系统为例。假定整理出的场景故事:客户的顾客,到达餐厅后,入座。通过点餐软件,选择菜品。后厨,厨师长获得用户菜单后,安排厨师制作菜品。菜品制作完成,通过服务员为用户上菜。用户用餐完毕后,通过软件付款,并可以评价。

二、角色分析

角色分析的目的是整理出需求中包含的角色,以及明确角色所包含的属性。角色可能是设计出的功能的使用者,也可能是系统的示例数据。在角色分析时,我通常使用ER图来描述角色。该ER图中只表示角色,不用表示其他实例和关联关系。

根据场景故事,我们可以整理出角色:顾客、老板、厨师长、厨师、服务员。这里只是举例说明,只完成核心,所以就只考虑顾客、厨师长(1名)、服务员三种角色。在分析角色的属性时,可以预先考虑将来的扩展。比如服务员将来可以可能会涉及多种分工的服务员,所以可以设计一个类型属性。下面我制作的ER图。

完成角色的分析后,下一步进行业务分析。

三、业务分析

业务分析的目的是,分析用户需求背后的业务流程,理清楚相关的数据结构和操作,为用户需求制定合适的解决方案,并把用户需求转化为实际的建模描述(用UML表示),为功能清单/信息架构制作打下基础。

第一步,分析出角色和系统的关联关系。顾客使用点餐系统完成点餐。厨师长通过点餐系统获得用户的菜单,安排制作后,通过上菜系统传递给服务员。服务员通过上菜系统,给顾客上菜。顾客用餐完毕后,通过结账系统结账,并评价。这里使用用例图来进行分析。这里只进行简单总结,就不细化到系统功能。

完成系统的分析后,用户需求就被转化为了功能需求。我们分析出了需要哪些系统,系统包含哪些功能。下一步是完成系统间的交互分析,明确每个角色行为,在业务内进行的运作。这里采用序列图来进行分析,以点餐到菜品上桌为例。

明确系统的执行顺序后,就可以通过流程图完成描绘出整个业务了。如果是一个流程有多个角色参与,可以使用跨职能的流程图。这里就以普通流程图为例,分析点餐的业务流程。

完成流程图后,就接近分析完成整个需求和业务。但是针对某些一些特殊内容,我们还需要更为深入的分析。比如某些实例的状态。以本文例子中,服务员的状态进行分析。针对状态分析,使用UML的状态图。

业务分析惋惜完成后,我们就完成了需求分析。我们需要产出直观的文档,除了上方分析的文档外,还需要产出功能清单或者信息架构。这里以功能清单举例:通过功能清单,就将功能需求转化成产品需求。下方为一份简单的功能清单。实际我们在制作功能清单时,一定要注重细节的把握,细节体现专业。

完成功能清单后,就完成了需求分析,就可以开始制作原型。原型制作这里就略过了。

四、总结

可能很多产品经理,不认可业务分析就是需求分析的一部分。在B端产品的需求分析中,需求和业务是高度耦合的,没有深入业务层面的需求分析,都是不够客观的。当然,可能在大公司有专门的的业务分析师做业务分析,B端产品经理不一定需要深入分析业务。但对于B端产品经理来说,业务分析能力也是需求分析能力的一部分,不是任何时候都有业务分析师帮助产品经理分析业务。

做B端需求分析,我的原则是:尽可能通过UML的方式,将抽象的业务逻辑转化为可见的数据结构和业务模型。

 

作者:产品小思考,B端产品经理

本文由 @产品小思考 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 挺好~

    回复
  2. 什么场景下、什么人,产生了需求(问题)

    来自上海 回复
  3. 我的文章写了10篇,可以一起努力呀。我是晓庄同学,微信号:znc0520,公众号:小晓庄同学产品笔记 😉

    来自河南 回复
  4. 作为一个b端产品,终于看到了一个实操过的人写的东西,虽然很粗但是看得出来是从实践中总结出来的东西,很赞,订阅了!

    来自上海 回复
    1. 他这个完全可以做一个案例来出来套教程,比那些只会分析理论需求的强太多

      来自北京 回复
  5. 竟然才35订阅,我感觉写得很棒啊。

    回复
    1. 😭

      回复
    2. 😥

      来自四川 回复
  6. 来自北京 回复
  7. 核心三点:解决什么问题,给谁使用,如何实现是最棒的。

    来自上海 回复
    1. 解决什么问题,更深入的说:创造了什么价值

      来自四川 回复
  8. 我也是b 多交流

    回复
    1. 可以 可以

      来自四川 回复
  9. 很实用的方法论。赞!

    来自广东 回复
  10. 不判断一下有没有菜啊?

    来自北京 回复
    1. 简单举了例子,理一下我的方法。要深入下去,业务就很复杂了,不是一篇小文章能写完的了。

      来自四川 回复
  11. 所以有些人在做功能,有些人在做解决方案

    来自浙江 回复
    1. 赞同 😳

      来自四川 回复
    2. 不了解业务考想的做出来的就是功能,这样做出来的功能的复用性也不是特别高,更多的是一次性用品
      了解业务+想做出来功能复用性会很高,承前启后嘛,多个功能汇聚就成了解决方案 哈哈

      来自浙江 回复
    3. 并不仅仅于此,B端需求,如果不做业务分析,极大可能做出的功能,也是废的,不能满足客户需求。

      来自四川 回复
    4. 对啊 没有说这个仅仅针对B端 哈哈

      来自浙江 回复