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

关注并标星「人人都是产品经理

每天早07 : 45 按时送达


需求分析不是仅靠“想”就能完成的,还需要依据严谨而科学的分析方法。这篇文章,作者与你分享他在工作中的需求分析思考:

作者:李雨,B端产品经理

微信公众号:产品小思考

题图来自正版图库 图虫创意

全文共 2208 字 6 图,阅读需要 5 分钟


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


可是具体怎么分析呢?怎么将用户需求转化可见的原型?相信大家读完也是一知半解。


——在整个过程中,完全靠产品经理头脑风暴?


我认为这只能算「需求挖掘」。需求分析应该是严谨而科学的,不仅仅是靠「想」。


当然,可能这是C端产品业务较为简单的原因。


不同于C端需求,B端需求都来至于垂直行业,高度贴合客户业务。所以,B端需求分析,需要有一套结合业务的分析方法。本文主要分享我的B端需求分析方法。


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


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


开始分析之前,我首先会先整理需求:


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


我的需求分析方法,主要分为三步场景分析、角色分析、业务分析,整个分析过程高度依赖UML。


下文以餐馆点餐系统举例分析:


一、场景分析


场景分析目的是为角色分析和业务分析打下基础。主要通过与客户沟通,了解清楚用户的需求背景和业务背景,对需求有个明确的理解;除了通过客户沟通外,也可以使用其他的调研或分析方法;如果,机会合适的话,最好深度参与一下用户的业务。


我在做商家服务产品时,为了客户的打单发货业务,就曾亲身参与过用户的打单发货。


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


以简化版餐馆门店点餐系统为例:


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


二、角色分析


角色分析的目的是整理出需求中包含的角色,以及明确角色所包含的属性;角色可能是设计出的功能的使用者,也可能是系统的示例数据。


在角色分析时,我通常使用ER图来描述角色;该ER图中只表示角色,不用表示其他实例和关联关系。


根据场景故事,我们可以整理出角色:顾客、老板、厨师长、厨师、服务员。这里只是举例说明,只完成核心,所以就只考虑顾客、厨师长(1名)、服务员三种角色。


在分析角色的属性时,可以预先考虑将来的扩展。


比如服务员将来可以可能会涉及多种分工的服务员,所以可以设计一个类型属性。


下面我制作的ER图:



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


三、业务分析


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


第一步,分析出角色和系统的关联关系


顾客使用点餐系统完成点餐;厨师长通过点餐系统获得用户的菜单,安排制作后,通过上菜系统传递给服务员;服务员通过上菜系统,给顾客上菜;顾客用餐完毕后,通过结账系统结账,并评价。


这里使用用例图来进行分析,只进行简单总结,就不细化到系统功能。



完成系统的分析后,用户需求就被转化为了功能需求。我们分析出了需要哪些系统,系统包含哪些功能。


下一步是完成系统间的交互分析,明确每个角色行为,在业务内进行的运作。


这里采用序列图来进行分析,以点餐到菜品上桌为例:



明确系统的执行顺序后,就可以通过流程图完成描绘出整个业务了。


如果是一个流程有多个角色参与,可以使用跨职能的流程图。


这里就以普通流程图为例,分析点餐的业务流程:



完成流程图后,就接近分析完成整个需求和业务;但是针对某些一些特殊内容,我们还需要更为深入的分析。比如某些实例的状态。


以本文例子中,服务员的状态进行分析。针对状态分析,使用UML的状态图。



业务分析惋惜完成后,我们就完成了需求分析。


我们需要产出直观的文档,除了上方分析的文档外,还需要产出功能清单或者信息架构。这里以功能清单举例:通过功能清单,就将功能需求转化成产品需求。下方为一份简单的功能清单。


实际我们在制作功能清单时,一定要注重细节的把握,细节体现专业。



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


四、总结


可能很多产品经理,不认可业务分析就是需求分析的一部分。在B端产品的需求分析中,需求和业务是高度耦合的,没有深入业务层面的需求分析,都是不够客观的。


当然,可能在大公司有专门的的业务分析师做业务分析,B端产品经理不一定需要深入分析业务;但对于B端产品经理来说,业务分析能力也是需求分析能力的一部分,不是任何时候都有业务分析师帮助产品经理分析业务。


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


———————— END ————————


每个「在看」,都是一次鼓励 ▼


更多精彩内容