<![CDATA[ PMCAFF互联网产品社区 - 产品经理人气组织 ]]> https://www.pmcaff.com <![CDATA[ PMCAFF互联网产品社区 - 产品经理人气组织 ]]> Mon, 28 Nov 2022 16:22:34 +0800 <![CDATA[ 【万字长文】BIM在家装领域的应用与实践 ]]>

前言

一晃又好多年没有好好更新过文章了,时光如梭,岁月如流啊,翻了一下之前的文章,中途夭折的不计其数哇(其实也就两三篇。。。咳咳~~),每次看到一个半截文章,就感慨,咦,原来我还写过这个,嗯,好像有点印象…只是后面要写啥早忘的一干二净了,为那些文章默哀一分钟~~

不过呢,最近这半年终于在懒中偷忙,整理了之前家装领域的一丢丢经验,可以简单写写,供各位大佬和大神参考。

今天要聊的话题呢,其实就是家装领域中的BIM,怎么说呢,其实行业内研究和发展了挺长时间的了,但是似乎一直没有看到一些特别成功的东西出来,它面向的用户对象是谁,到底解决什么问题,能带来什么价值,到底怎么才能落地执行,似乎每个公司都有每个公司的侧重点和考量,并且每个公司对其的预期也不太一样。

落地过程中呢,也总会遇到各种各样的困难和问题,所以也衍生了一些很奇怪的现象,似乎是大家都认为家装的未来在BIM,但是却没人知道为什么在BIM,到底它有什么用?它到底是不是一块鸡肋,食之无味,弃之可惜呢?

而对于我,作为一个运气比较好一些,有幸落地过BIM,并且稳定运行了几年的产品来说,也希望能通过自己对这件事情的分享,将自己对这件事情的思考和做法分享给大家,如果恰恰能够给大家带来一些新的思路和启发的话,那就最好不过了。

(如果真的有用,记得请我吃饭,哈哈~)

首先,什么是BIM

BIM(Building Information Modeling)技术是一种应用于工程设计、建造、管理的数据化工具,通过对建筑的数据化、信息化模型整合,在项目策划、运行和维护的全生命周期过程中进行共享和传递,使工程技术人员对各种建筑信息作出正确理解和高效应对,为设计团队以及包括建筑、运营单位在内的各方建设主体提供协同工作的基础,在提高生产效率、节约成本和缩短工期方面发挥重要作用。

(该段内容来自百度百科)

BIM,建筑信息模型(Building Information Modeling),其实是从建筑领域来的。只是说在家装领域,室内设计也在行业内逐步的开始由2维的CAD绘图,开始转向3维的工具辅助设计,初期呢,其实只是为了呈现设计效果,用户可以直观的感受自己未来的家会装修成什么样子。后来呢,因为天然是3维的设计,天然有一些数据化的内容,比如房屋户型、空间、面积等信息,基于行业本身的数据化发展的进程,对于算量、计价等也逐渐有了自己的诉求,也就慢慢的开始有了家装领域的BIM。

其实,BIM自身在建筑领域的定义,就已经决定了BIM未来是什么样子,只是在不同的公司,也是各有侧重,这个后续在慢慢细说~

OK,大概了解了BIM的概念之后呢,我们就来看下BIM到底是个什么样的工具。

BIM是一个什么样的工具

这里呢,也就简单介绍一下,大家知道个前因后果,不做深入探讨和分析。(因为一分析就又是一篇巨长巨长的文章了,后续有心情了再写吧,咳咳)

在行业内,目前比较出名的几个软件工具,大概就要数酷家乐,三维家、每平每屋(原躺平)、打扮家等,以及贝壳旗下的一些自研BIM,如视的未来家之类的。

这些工具中,酷家乐,应该是最广为人知,因为它除了面向B端,也同时面向C端开放,这个原因,也促进了它本身的迭代和知名度。

这些工具呢,因为侧重方向不同,大概上能分为下面两种:

工具类型.png

我们来聊一下这些工具的类型,这些工具呢,首先肯定是一个设计工具。因为设计是整个家装的上游,没有设计,就谈不上后面的所有的算量、图纸、交付之类的东西。所以,设计工具在之前一直是这类工具的核心,我不关心之后能不能实现,现在我得先要好看,是吧。所以最初的时候,大家的精力都会在这些工具如何才能更好的促进转化上来。

慢慢的,开始有一部分企业开始思考,既然设计已经数字化了,那设计过程中到底用了哪些材料,材料用了多少,主材多少,辅材多少,这些用量是不是也可以数字化呢,如果这些量可以数字化,那是否意味着可以以BIM中的量为整个工程的计算依据呢?

(要知道,现在整个行业大多数还在手扒CAD,拿计算器算量呢。)

因此慢慢的也开始出现了一些主打交付工具的工具,以算量为核心,主打所有的用量由系统计算得出,减少人工计算的误差和偏差。当然,现在似乎每个工具都会有算量等负责交付的团队,不过底层的不同,也必将会带来上层的不同,某些时候底层结构的缺失,也会导致某些算量完全无法计算。不过这些后续有机会再详细聊好啦。

那对于BIM,它到底应该是个什么样的工具呢?

其实上面聊得已经比较清楚了,根据BIM本身的概念,还有家装行业工具的发展轨迹,BIM的未来大概率上是以算量为核心的一套设计+交付的工具。也就是底层要按照能支持算量的结构搭建,而在应用层,也要能充分支持设计本身,做一个好的设计工具~

工具属性.png

家装业务存在的问题

在聊BIM能解决什么问题之前呢,首先得先聊下在实际的家装业务中存在哪些问题。一般情况下三大问题比较突出一些,分别是人员效率问题,材料成本问题,项目利润问题。

背景问题.png

为什么说有这三块的问题呢,我们分别来看下。(这里也就是简单聊下BIM能解决的问题,不能覆盖所有可能存在的问题)

人员效率问题

目前整个家装行业的报价部分信息需要设计师手动计算和填写,过程较为复杂,用量计算较多,时间消耗大约1-2小时。这还仅仅在报价,还有本身方案的沟通,图纸的绘制等等。设计师是签约的核心转化成员,若系统能让设计师的作业效率提升,也就意味着设计师会有更多的时间接待和转化更多的客户。

材料成本问题

由于装修过程中涉及的材料用量,是完全由人工计算然后录入系统中的。

在这个过程中,对于损耗的预估不同(比如A认为8%的损耗就够,B认为需要12%);对于自身利益的取舍(比如多下点材料,避免后期补货)等等。你会发现,同一个客户,同一套方案,同样的材料,不同的设计师肯定会报出不同的材料用量。

而在某些极限情况下,可能还会存在60平米的屋子,下单200平米的地板;有些工地会出现几百个插座等等材料问题。材料成本极其不可控。即使很多企业中间还有一层中控进行审核,但是依然很难完全避免。而且材料在人工计算无法精准的基础上,后期的退补货也会较多,也会让成本上升更多。

项目利润问题

在整个项目的利润上,大多数项目的毛毛利润率差不多在20%-30%,基本上都会是入不敷出的状态,每年的现金流都很好,到年底一算账,发现不赚钱。咳咳,在流量增量比较可观的时候,可能问题都不太大,毕竟有很优质的现金流,但是一旦出现了增量减少的时候,如何精细化运营,在整个项目中尽可能的减少开支,节约成本就变成了一件很重要的问题。

BIM能解决的问题

那BIM能不能解决上面所说的问题呢,咳咳,估计大家用脚指头都能想到了吧。

嘿嘿,但是还不够。

在仔细研究了BIM工具之后,你会发现在报价层面、算量层面、体验层面和图纸层面都会有完全截然不同的体验提升,而这整套体验,其实带来的是整个设计和交付行为的重大变革。

bim解决的问题.png

报价层面

BIM本身作为3D的设计工具,户型的结构,面积,空间信息,空间中的材料信息一应俱全,那么完全可以从BIM工具直接生成用户的报价单啊。

对了,这里多废句话,现在家装行业的报价功能设计的底层逻辑都是人如何在做报价的时候做的齐全还不缺项漏项。所以所有的顶层设计都会围绕这个底层逻辑在做,你不管看多少家报价体系,都在基于这个底层做事情。当我们接入3D设计工具的时候,是否可以换个视角,设计师是否可以不再做报价单了,而由系统来做。当视角不一样的时候,你就会发现顶层设计就会变的完全不同了。咳咳,这里就暂时不再延展开了。

还有就是,报价单是表格这件事情,咳咳,这个行业都几十年了吧,这都2202年了,是否可以考虑换个形态,比如图文或者什么的。如何更清晰、易懂的向用户传递装修的基础信息,其实可以换个角度来考虑。

怎么做,有多少困难,困难都如何解决,就先不聊了哈,废话扯得有点多了,咳咳,勿怪勿怪。

算量层面

BIM哎,3D设计工具哎,基本上都可以由系统直接计算所有材料用量了和施工用量了。由于完全依据系统规则生成,只要设计方案是准确的,用量也自然会是准确的。完全可以屏蔽人为因素的影响。同时这些数据也完全可以用于后续的发包和下单。

(咳咳,当然,完全一点都不差也不现实,部分小的偏差,瑕不掩瑜,不影响大局。)

体验层面

BIM本身是3D设计工具,即方案完成后,用户可以直接进行3D漫游体验,甚至可通过可穿戴设备进行VR体验,所见即所得。再也不用全靠2D的图纸想象了。

未来你的家如何,是否让自己满意,完全可视可见。对于空间想象能力较弱的用户,这简直就是巨大的福音。

图纸层面

BIM本身也会根据设计师的方案生成全套的施工图纸,可以节省很多CAD绘制的时间。

(这个根据工具的发展阶段不同,有些工具支持,有些工具不支持,有些工具只能支持部分。)

当这些层面都发生变化后,你会发现,这完全就是设计行为、报价行为、发包行为、结算行为等数据产生和传输行为的重大变革。

设计不需要在CAD中进行,用户无需靠自己脑补想象未来家的样子,报价不用做了,系统一键生成,所有的材料用量根据系统规则生成,摒弃了人为因素带来的偏差,施工图纸自动生成,后续的发包,下单依据准确的用量进行,支付和结算也有了相应凭据。

家装行业的产品分层

既然说BIM这么好,到底好在哪里呢,他在家装整条业务线条中,到底处在什么位置,有什么重要作用呢?

再聊位置的之前呢,先聊下整体的家装业务吧,从产品底层来说的话,整体大概可以分为五层,分别为业务层、数据层、预算层、支付层、结算层。

家装业务的五个层次.png

五个层面分别面向不同的问题,提供各自的解决方案,家装整体业务体系也基于这五层进行构建。

业务层

业务层主要提供家装全链条业务侧解决方案,也是最重要的一层,所有的业务流程和逻辑都可以划归进该层。

整体的结构基本包含以下部分:呼叫中心、销售中心、客户中心、智能交付中枢、合同中心,订单中心,交付中心,供应链中心,财务中心,售后中心,智能设备中心等。

基本涵盖了家装行业全链条的业务内容,所有的业务数据都在该层中处理。

业务层数据.png

(哈哈,此处也先卖个关子吧,内容暂时就都打码了,后面应该会有个系列专门说业务层的所有框架和内容。。。咳咳,应该是应该吧,但愿不会再是两年后了~ 咳咳)

数据层

数据层主要指装修项目中的施工数据、材料数据等信息,这部分信息既包括了用户的报价,也包括了向下游的各个端口的发包、订单信息。

(业务层的业务数据在业务层处理,不在该层中处理。)

该层面主要处理从设计开始的所有户型和家装全量数据,包括施工项目数据和材料数据,以及后期所有的变更数据,贯穿了家装过程的始末,而这部分在大多数的公司和企业里面,也是完全需要靠人来处理的。所有用量的计算,报价的计算,施工过程中的变更,后期的退补货,这也是链条中最难控制的部分。略微有点像那种,看起来每个地方都没花什么钱,但是就是钱都花完了的既视感。

而作为BIM工具,也是在这层中发挥自己最大的价值,全部数据由BIM统一输出,下游依照上游数据执行,从最大程度中规避过程中的数据风险。

bim与业务衔接框架.png

预算层

预算层主要用来衡量项目层面的预计收入、预计支出和预算毛利率。算是整体项目预算的最关键的部分了。这个项目到底能不能赚钱,能赚多少钱,毛利率多少,是否能覆盖全部成本,我到底能不能盈利,这些问题,不能等到项目结束才知道,而要提前预测。并且尽可能的让决算与预算相接近,这种情况才能最大程度上节约成本,从而盈利。

这部分主要涉及到项目内容、后台的成本构成,税率关系等内容。需要依据数据层提供的数据进行准确预估。从而达到在项目未开始前,整体项目的收入、成本、增值税、附加成本以及毛利率直接可预见。

这层的准确性依赖于数据层的准确性,所以,能不能搞好数据层的数据,就决定了能不能搞好预算层的数据。

预算层.png

支付层

支付层主要提供用户支付的解决方案,包括微信支付、支付宝支付、POS机支付、现金收款、对公转账等等。

支付链路横跨整个用户生命周期,特别是在家装业务上,项目周期比较长,支付频次(定金款、首期款、变更款、中期款、尾期款)比较多,支付金额比较大(大多数会超越在线支付单次5万的限额),支付方式比较多变(在线支付、POS机支付、转账等),付款逻辑和场景也比较复杂,如何更好的处理用户的支付场景,完美衔接自己的业务体系,就需要更多的花费一些心思。

支付.png

这张图呢,基本上介绍了这个行业支付这块的关键信息,之后应该会有一片专门的文章说这块,这里就不一一展开了。

至于里面为什么微信、支付宝既有线上支付,又有线下支付,这里主要是区分是否能自动线上对账的,如果能线上自动对账,那就算线上,否则的话,即使支付了,也需要重新在线上认款到对应项目中,这个就算线下支付。

(咳咳,感觉这篇文章,直接挖了两个文章的坑啊,不知道填不填得上。。。咳咳~)

结算层

这层相对下游一些,也是狭义的结算,主要提供工程结算、供应商结算的解决方案,也就是主要解决如何向对应的服务者结算的问题。

其实没有太多需要说的,相对比较简单,在上游数据完备的情况下,相对比较好处理,只需要按照结算规则、账期和结算方式落地就行,大多数都是发起结算,审批结算,对账,打款等。

唯一需要考虑的是要尽可能多的覆盖异常场景,这样的话才会形成一个完整闭环,避免某些特殊情况的行为、支出、扣款等导致系统无法进行正常结算。

结算.png

BIM在家装业务中的位置

上面已经清楚的讲了五个层次的基本分法和概念,那么BIM在整个业务中的位置就清晰可见了。

BIM在数据层提供完整的、精确的原始数据,通过业务层产品规则(套餐规则)的转化,形成面向用户的报价单、变更单、同时形成面向施工方的发包单,面向供应商的发包单。贯穿全业务流程,为预算层、支付层和结算层提供准确和完善的数据支撑。

而这些单据,面向用户的代表收入,面向服务商的代表支出,也就同时会产生预算单,也就意味着,在一个装修项目开始的时候,就能很明确的知道项目的收入、成本、利润率,从而为项目后续的进展提供准确的参考依据。

bim在家装业务中的位置.png

聊了这么老久,终于可以开始聊一聊BIM到底是如何应用与实践的了,咳咳,五千字才进入正题,不会被打吧~~

BIM应用的框架结构

上面很详细的聊了家装业务的产品分层,并且也说明了在这套分层结构里面BIM的位置,那么BIM在整套业务体系里面,到底如何规划和落地呢。

其实通过上面的这些内容,可以大概梳理出来,BIM在整个家装业务体系中的数据流转结构。

从BIM中获取基础数据,流转至业务层的套餐规则中,进行转化和输出,输出报价单和发包单。而销售和成本直接的关系依靠底层数据进行拆分和关联。从而将所有收入和支出引入财务体系,完成预算和决算。

整体方案框架.png

BIM框架中的三大难题

在这套结构中,核心会存在三大难点问题:BIM的数据问题、报价规则和发包规则的抽象问题、销售与成本之间的转化关系问题,而这三个问题,恰恰也是整个系统结构流转衔接的关键点,也就是说只要能解决这三个问题,整体的产品方案就能落地。

三大问题.png

那么既然定位了核心问题,那么接下来要做的就是一个一个解决掉它。

BIM的数据问题

BIM的数据问题,决定了BIM将向业务侧传递什么样的数据,业务侧需要接收什么类型的数据。数据的格式如何界定,如何隔离BIM和业务体系,做到低耦合,同时通过数据通道相连。这里面还需要解决两个问题:BIM能提供的数据是什么,业务侧需要的数据是什么格式的。

bim数据问题.png

这里就会涉及到两部分,BIM能提供什么类型的数据,而业务侧需要什么样的数据。

对于业务侧需要什么样的数据,这里解决不了,因为业务侧需要什么样的数据,需要在抽象规则后才能知道。产品实现的过程是由底层数据到上层建筑的过程,但是在产品构思阶段,却是由顶层结构拆分至底层数据的过程。两个完全相反,所以,这个问题会在下一个节点来说。

这次我们就聊聊BIM能提供什么类型的数据。至于BIM工具本身,就不多讲了,一讲起来就又是一篇长篇大论,等以后了,咳咳,我也不会写,工具写起来累人。。。(再说了,emmm,前面已经埋了两个坑了,再挖怕是。。。。不厚道了)

虽然这里不打算讲BIM,但是你怎么才能知道BIM能提供什么样的数据呢,那就需要小小的研究一下了,嘿嘿~

其实也不用研究的很细,就。。。就。。。把它整个功能结构扒下来,基本上你就能大概清楚他的数据结构和底层逻辑是怎么处理的了,咳咳,是不是很简单。

bim结构数据.png

因为工具本身存在了前端应用的结构和管理后台,所以扒的时候不要漏了~

前端结构主要用来了解基础性质的原子数据,后端结构主要用来了解底层的数据支撑和结构,两者都不可或缺。

前端结构的数据和后端结构的数据如下图,具体是哪一家的,就不做细说了,自己看吧。限于结构图太。。。长了,所以只截取一小部分。对全部结构图感兴趣的,可以关注「脚量产品路」微信公众号,发送“BIM”获取脑图源文件~

前端应用.png

后台应用.png

所以,当你扒完BIM工具的整体结构之后,你就会发现,BIM本身提供的是原子化的数据,他可以提供你很精确的底层数据,比如户型的面积,结构,每个空间的名称,空间的长宽高,空间面积、空间周长,门的高宽厚等等原子数据,所以这些数据如何才能变成业务切实可用的数据,就需要依赖于业务侧到底需要什么样结构的数据了。这就是我们下一个问题需要聊的了。

规则的抽象问题

我们前面有聊到,BIM的数据经过规则的转化之后,会转化为报价数据和发包数据,一则面向于用户进行报价,一则面向于下游进行发包。所以,规则的抽象其实就是两套规则的抽象。也就是产品报价规则和向服务者的结算规则抽象。

规则的抽象.png

先聊报价规则吧,报价规则应该算是一块最难啃的骨头,因为这个领域,报价规则,那是手册啊。。厚厚一本。。。

没办法,只能采用老办法,也是笨办法,有可能也是最有效率的办法,将整个手册全部扒下来,然后从一堆规则中去提炼和抽象核心规则。产品手册的规则一般包含几个主要部分,分别是计价规则、主材配置、升级、限量规则、水电点位规则和个性化施工项目规则。

报价规则.png

任何一个复杂的结构里面,底层一定有一条或者几条规则,是整个结构的核心,支撑着整个结构自由运转。而我们要做的就是在复杂的、冗余的、拥有极大干扰的巨量因素里面,去剖开表象,剥离出最本质的几条规则。这也将会是我们突破的核心点,以点才能破面。

具体的过程我就不多描述了,如果感觉体会不深,咳咳,可以联系我,我给你个手册你自己剥离一下尝试一下,不用担心,不要钱,咳咳~

这里就只说结论了,在将所有的规则都扒出来之后,果然发现了最核心的一条规则,这条规则就是产品报价的核心:在XX空间下,XX 材料/施工项是标配的?还是升级的?还是加载的?行业内的同学会不会觉得跟自己现在做的好相似~ 虽然像,但好多事情差之毫厘…希望我的做法能对大家有一些新的启发。

(这里简单解释一下,对于一般家装行业套餐制公司,家装的收费是按照房屋面积收费的,比如999元/平米,所以这里的标配指的是不需要额外花钱的,包含在套餐内的。升级指的是不在套餐内,但是你可以补差价升级,比如你想用更好的地板/瓷砖时,可以补一个差价。加载的话就是指套餐内完全不含,需要付全部费用购买的。)

在这条规则之下,你会发现绝大多数的(80-90%)场景都能覆盖,而且它也将直接决定业务需要的BIM数据是什么格式的。

核心规则.png

在这条核心规则的基础上,并不是所有的规则都能满足,所以还需要一批其他的特殊规则进行补充。包括水电点位规则,门的超高/超宽/超厚规则,垭口超厚规则,窗套超厚规则,地板/铝扣板异形规则等等。而这些规则在一起将支撑整套报价体系自动生成。

全部规则.png

报价规则抽象完了之后呢,就是如何抽象结算规则了,用来决定如何发包,这套规则比较简单,核心其实就是售价和成本的问题,然后对于工程会有一些套餐包的计价,比如施工部分包给工人多少钱这样,相对比较简单一些。

结算规则.png

结算的转化问题

最后来一下结算转化的问题,这个东西主要界定销售和成本之间的关系,看起来比较简单,其实也的确比较简单,咳咳~

只是会有一些特殊场景,所以会跟正常的通过sku管理销售和成本的关系不太一样。举个简单的栗子大家就能明白了。

结算转化关系.png

所以,看完上图也就不难理解,为什么需要独立关系处理了吧,因为转化关系并不完全是同一单位的数据转化,而会是不同单位的数据转化。

聊到了这里,大概就可以理解,为什么在BIM应用的框架结构(不要问框架在哪?往上翻翻,咳咳~)中,会单独拆出来三个库来处理内容了吧。

而对于仓储,因为同样涉及到了出入库的内容和采购的内容并不一定是一一匹配的,所以也将仓储的部分独立拆分了库,进行独立管理。

BIM的落地产品方案

聊了这么多,也说了这么多问题如何解决,那么到底实际的落地方案会是什么样子呢,会不会很好奇,以下将是重磅内容,哈哈,期待一下吧。

上面聊了所有的框架、结构、要解决的问题、以及如何解决,那么接下来就看看到底在系统中如何落地吧~

功能结构图

在开始落地之前呢,肯定还是要大概梳理下功能结构的,虽然上面其实已经聊得差不多了。

核心功能结构.jpeg

数据流程图

然后就是数据传输过程中的流程图,用来更清晰的表现数据过程。

业务流程图.png

BIM的数据方案

上文已经界定了BIM需要提供的数据格式为,空间/施工项、材料/用量,那么BIM工具就需要提供该种类型的核心数据,同时也需要提供BIM的基础空间等信息数据。

  • 基础项目、方案数据

包含基础的项目、方案信息、该户型结构及基础内容。

数据内容结构.jpg

  • 施工、材料数据

详细的施工和材料数据信息,也是最核心的信息。业务规则将依据该部分内容进行相关报价数据和结算数据的生成。

(注:木作数据比较特殊,此处不详细聊,有兴趣的关注公众号之后,加我微信详聊)

详细数据清单.jpg

规则的抽象方案

规则的抽象核心是各种规则的提炼,上面核心规则和分支规则已经聊得差不多了,下面就是具体的产品方案。

规则的抽象和提炼总共分为了8步,分别为:套餐规则管理、套餐商品管理、商品规则管理、附加规则管理、拆除包管理、水电包管理、补充报价管理、发包管理。

套餐的配置.png

  • 套餐规则管理

主要用来管理套餐的基础计价规则,及相关内容介绍。

套餐规则管理.jpg

  • 套餐商品管理

主要用来界定该套餐包含哪些商品。对于纯粹的装企来说,那就是包含所有内容。

如果对于复合型企业来说,比如有自己的大店,有自己的电商,并且与家装业务有明确区分的时候,这里可能需要额外的关注下。

套餐商品管理.png

  • 商品规则管理

主要用来界定最核心的材料和施工项规则,即某个空间是标配的,升级的还是加载的。

商品规则管理.png

  • 附加规则管理

主要用来解决附加规则管理的问题。附加规则上文已经说的很清楚了,这里就不在赘述了。

附加规则.png

  • 拆除包管理

拆除包主要用来定义计价规则和收费内容。

拆除包管理.png

  • 水电包管理

水电包管理主要用来管理水电包的计价规则、水路点位规则、电路点位规则等。

水电基础信息.png

水电水路配置.png

水电电路规则.png

  • 补充报价管理

主要用来兼容部分无法在BIM工具中算量和计价的项目。比如我们之前对接的BIM工具不支持复式、别墅这种多层设计,那么一旦在实际过程中遇到该类户型,就需要采用一些方式,兼容该类特殊设计。

当然,既然作为一个入口,那么一些特殊场景内无法满足的,都可以在这个入口兼容。

  • 发包管理

发包管理主要用来管理施工部分的发包规则,其他材料部分,由关联关系可以直接衍生,但是施工侧会有一些独立发包规则,因此需要独立管理。

施工发包规则.png

结算的转化方案

这个呢,其实就是3个基础库如何进行拆分转化,其实没啥太大难度,基础库需要区分一些类型和属性,比如不同类型的施工库和材料库分开管理,结算库里面要有税率,库存库里面要有库存等等,就不详细赘述了。

转换公式里面有一些需要关注,比如一些基本参数,比如户型面积、损耗系数、库存的尺寸等等可以作为基础参数进行定义。公式的本质是数学运算,所以能提炼的就尽可能提炼就好了。

转换公式.png

前端应用

三大问题解决了,数据可以传输了,规则也已抽象完成,转化关系也已建立,那应用时是如何应用的呢。

  • 获取方案

在BIM工具中完成方案后,只需要一键获取就可以了。

获取BIM方案.png

  • 生成报价

获取后呢,系统根据规则自动生成相应的报价和详情。因为是图文,所以也完全可以在手机上进行呈现,虽然表格呈现信息的组织性和逻辑性很好,但是可读性并不太好,毕竟是给用户看的,所以,看的爽和能看懂才是第一要素,其实也不用过于拘泥于之前的行业方式。

因为报价单本身内容太多了,所以就不展示全部截图了。需要的到时候关注公众号「脚量产品路」输“BIM”获取相关内容吧。

报价信息.png

报价详情.png

Web报价详情

报价详情APP.png

App报价详情

  • 生成发包、预算

根据转化关系自动生成发包和预算,直接获取所有项目的收入、成本和毛毛利率~

预算单.png


OK,整个项目上,基本上到此就打完收工了。。。至于变更怎么做,财务如何处理,这些地方按照自己的业务逻辑和规则处理就好啦~

但是,但是,真的完了么?

PLAN B的必要性

在对接BIM的时候,一定要考虑的一个点,就是一旦BIM跪了,业务怎么办?如果是三方的BIM,业务肯定不能一直等着三方BIM团队来解决问题。(你一个月没法解决,难道我还能等你一个月么,咳咳~)

所以在架构上的拆分就很有必要了,BIM作为数据的输入方,如果BIM一旦跪了,那么就需要有一个路径将数据输入这套体系。

这就是PLAN B了,任何时候要给自己的业务体系留好后门,别过于受其他方掣肘。

至于这个PLAN B是什么样子的,既然你都看到了这里,应该就不用多说了吧,嘿嘿~

当然,这其实也是一个好事,当你考虑到这个点的时候,其实也意味着,你的业务体系就可以接多个BIM工具了,备胎多点,自己的业务体系就会越稳定~而且,你也不用担心某个BIM忽然某天黄了,自己的业务就废了~哈哈~

当然,这里其实也抛出了一个问题,如果没有BIM,这事能不能搞,能不能搞哩?

当然是废话了,没有BIM当然能搞拉,BIM的核心在于提供基础数据,如果有一套体系可以脱离BIM提供基础数据,是不是就~~~~~

这套体系是啥呢,可以自己想想,它的确存在且切实可行,并且我并不打算写,哈哈~(主要是市场上BIM工具还挺多的,着实没有必要~)

数据的对接与维护

任何一个体系总要落地执行吧,所以业务体系和BIM工具,双方数据的统一和维护就需要保持一致和统一。

如果刚好你自己的公司就在搞BIM,那就最方便不过了,直接底层数据打通,用一套数据就好啦。

如果没有自己搞BIM的这个实力,也没关系,这也是件好事,就意味着你可以接市场上所有的BIM,毕竟备胎还是要多来几个的,要不然一旦接的那个BIM工具黄了呢,咳咳~

在这种情况下因为本身在两套体系里面维护数据,为了确保数据在维护层面准确,可以建立一些数据维护的SOP,这样就能很方面相关方维护相关数据啦~

产品的培训与使用

因为这种方式呢,其实跟设计师之前的处理行为截然不同,所以,培训和使用过程必将面临着巨大的难题。所以,公司上层的老板们要考虑好,这件事情到底能带来什么,是否需要付出这种成本,收益到底如何。这将会是一个一把手工程,因为这个在执行层面会遇到极大的阻力。

抛个一定会出现的问题示例一下吧,咳咳。那就是一定会有人反馈,这个算的量不准啊~面积少了,面积多了,量少了,量多了~

这种问题应该是最影响业务运行,也最容易让人恐慌的了,所以这种问题,解决的方式也很简单,拿到设计师原始量房图,从每一条线开始核对户型数据是否准确,从而解决面积误差问题,这个问题很重要,因为涉及到了按平米计价。

对于用量问题,就是查看设计方案,去一点一点扣量是否准确,设计师的操作问题(比如某个地方忘记了铺瓷砖),还是BIM工具问题(比如工具计算错了用量),还是业务体系转化的问题(比如转化公式有问题),然后去解决对应问题。

(其实误差的确天然存在,只要在合理可接受的范围内其实就好~)

BIM工具的落地本来就是个全新的尝试和变革,这个过程中会有各种各样的困难和阻碍出现,所以最好有一个团队可以持续性运营和解决出现的问题(当然,产品其实最合适,咳咳),需要持续一些时间,在走过最开始最艰难的时刻后,后续就会逐渐走的顺畅。

产品的效果和收益

体验上,VR效果的所见即所得效果其实非常好,不过呢,也会遇到一些小小的问题,咳咳,就是用户感觉太爽了,终于不用靠脑补来想象是什么样子了,所以呢,用户就很开心的期望这里换个瓷砖看看,那里换个地板看看,略微微的会影响一丢丢签约转化的时间~~

时效上呢,因为不用再出报价单了,而且图纸方面也不用独立绘制了(部分图纸),所以整体上大约能提升2-3小时的工作时效,设计师们终于可以有更多的时间接待更多的客户了~

结算的毛毛利润率方面的,采用了该种方式的话,毛毛利润率可以提升10%-20%。是不是感觉很震惊,这怎么可能,其实我也很震惊。。。不过这就是事实,所以,也可以看得出来,在之前的那种行为模式下,这个过程中到底有多少的额外支出~~

Emmm,就算你不相信,觉得提升不了这么多,提升个5%是否值得呢,如果按照一年营收10个亿来算的话,这是多少钱来着,手指头有点算不过来。。。

最后想聊的几个小点

第一呢,这一定是一个自上而下的过程,甚至可以说是一把手工程,有些事情是看见所以相信,有些事情是相信所以看见,所以,从上而下达成一致其实很重要。否则任何一丁点的困难都会成为这个事情失败的原因。

一件事情的成功,不仅仅取决于它的规划,同样也取决于它的执行。

第二呢,就是不要老路,新路一起并存,总觉得我额外提供一种新的方式来解决这个问题,但是我依然保留着老的路径。这种情况下,根本不可能成功,因为没有人会走新的路径。这就像当年福特造汽车时,刚开始汽车速度还不如马车的时候,那么他是要回去继续做马车呢,还是迭代和改造汽车?其实道理有点类似,在新的路径上画更多的时间和精力让他更好用,更易用,而不是给大家一个老的路径可以继续使用。这样铁定大家都会回到老的路径上去。。。

(当然,这个嘛,是个人看法,也不一定对)

第三呢,有所选择,有所放弃。如果你想满足现在线下的规则中的每一个字,那我可以很负责任的告诉你,放弃吧~ 别搞了,因为绝对搞不定。所以,如何在线下运行的规则中,找到合理并且合适的规则,放弃掉一些不是那么合理和合适的规则就会显得很重要。

这将会是一个艰难求索的过程,预祝各位能够顺利前行~ 我们下一篇不知道啥时候才会写的文章见~~

]]>
https://coffee.pmcaff.com/article/xvQ3wo1aQW https://coffee.pmcaff.com/article/xvQ3wo1aQW Thu, 22 Sep 2022 11:18:33 +0800
<![CDATA[ 2万字 | 全面剖析需求的挖掘与分析(建议收藏) ]]>

“大家好,我是阿境,人称产品届的吴彦祖,一个沉稳又不沉闷的男人。”

这次比较不同,先抛出大家可能的收获知识点,再聊文章内容。

看完文章,你能够得到什么?

①解决80%有关产品需求的疑问点,包括面试中涉及需求的相关问题

②获得包括《需求挖掘分析pdf完整版》《需求文档范例》《需求自检表》《需求排期表》《需求分析ppt》等多份阿境独家实用文档

③一套完善的需求挖掘与分析的方法论


“阿境,用户想要在动态上加一个话题功能,我们规划一下吧”

“这是用户需求,不是产品需求”

“本质上用户是为了能给自己发表的内容打上标签是吗?”

“是的,并且需要先判断是真实需求还是伪需求,再进行定义,我们也可以通过用户需求,来分析出我们的产品需求,从而确定我们要做的方案

若你是个PM,想必上述对话的场景,屡见不鲜。

需求是一个被互联网人说烂的词,却也是最基础的词,产品说需求、运营也说需求、市场也说需求。

那么有几个问题大家思考下,

他们说的需求是同一类吗?

究竟什么是需求?本质是什么?

什么是产品需求跟用户需求?

真实需求与伪需求怎么辨别?

对于需求分析你有一套明确的思路吗?

需求的来源、管理、优先级排期等你能够侃侃而谈吗?

......

在看过这些问题之后,若你能够在很短的时间内有了明确想法,那阿境觉得可以关闭掉文章,因为这是浪费你的时间。(花个10分钟去炖个排骨享受生活都比看这篇文章值得一些)

如果没有,那么!且听厦门吴彦祖阿境啰嗦一下吧。

产品经理的职责便是在最短时间内最大化地创造价值,那么接触最多的的便是日常处理的需求,而需求分析也是非常关键的一步

如果在看过问题之后,对于部分实施的方法还有疑问,或者是想要系统地进行需求的认知,那么不妨往下看看。

另:

①附上本文导图框架,节约时间。若您感兴趣,可继续深入阅读;若不感兴趣,感谢光临。

②要获得独家需求分析资料,可关注公众号<梦想家阿境>,并回复“需求分析”,有具体获得的方式。

(长得好看的人会啰嗦一些,大家谅解下~)

图片


一、需求基础概述


1、什么是需求?

什么是需求?

百度百科的定义是:需求是在一定时期,在一既定的价格水平下,消费者愿意并且能够购买的商品数量。

这个定义也是基于经济学当中的定义,如果把它套上产品的帽子,那么我们可以转变为:

需求是在一定时期,在一既定的场景下,为了解决某个问题而激发出用户对于某种目标的渴望。

从中,我们可提炼出几个点:时间、场景、提出者、使用者、方案

而在实际工作中,脱离了时间、场景的需求,也往往容易被我们忽视。

综上所述,简单来说,需求就是在特定的场景下,用户所产生的问题。可以用“用户+场景=需求”的方式来理解,也可以说,需求是预期与现状的差值。

2、需求的本质

天主教教义当中,有七宗罪,分别是:傲慢、嫉妒、暴怒、懒惰、贪婪、暴食、色欲。而我们的产品,正是解决人身上所带来的原罪的产物。

而从马斯洛需求模型来看,有自我需求、尊重需求、社交需求、安全需求、生理需求。

从这两个方面上来看,需求源于人,最初的源头在于用户。而用户的存在,必然会遇到这样那样的问题。

图片

一个需求归咎到底,还是满足了用户不同等级的欲望。

需求的本质是对用户欲望的满足,以及消除用户的恐惧感,从而解决用户的实际问题。

一款好的产品一定是能满足人性或者欲望的。

而产品本身是众多需求的集合体,根据不同的组合而成为当前产品的形态,产品功能则是满足了用户的目的,而需求和产品功能是一一对应的。

所以我们说,产品经理在处理需求的时候,所具备的同理心这一特质,才能够更好的洞察需求,洞察需求的过程也是在洞察人性,即洞察需求的本质。

3、用户需求与产品需求

先来看一句话“用户给产品经理提了一个需求,研发评估了下这个需求不能做”

这当中出现了两个“需求”,这两个是同一个意思吗?

很显然不是。(说“是”的,阿境要揍你们了!)

从这个简单的例子可以看出,无论是用户,还是产品经理,还是业务人员,都在谈需求。

而需求被赋予了更多的含义时,就需要引入其他更深层此次的概念加以区分。

比如,上述例子中,前者是用户需求,后者是产品需求。

用户需求主要是指出用户想要怎么做,产品需求则更多的是指导产品需要怎么做。

图片

1)什么是用户需求?

用户需求是用户当前尚未满足,又渴望被满足的欲望,并由此产生的方案。当用户使用得起产品,并且产品并不能够满足用户当前使用时,用户才会对产品产生新的需求,也就是我们所说的用户需求。

用户需求有个较大的特点,不能够指导产品开发,更侧重描述用户想要达到的目的,借此所提出的需求方案(想要的东西),则为用户需求。

2)什么是产品需求?

产品需求是用户需求经过产品经理的“加工”后所诞生的产物,输出具象的产品方案后实现,在实现之后完成产品既定的数据目标,则为产品需求。

产品需求更侧重能够指导产品开发,并且指导产品完成自身的目标(以数据指标作为目标的依据)

3)用户需求如何转化成产品需求?

当我们清楚用户需求与产品需求之后,那么我们如何将用户需求转化成产品需求呢?

作为产品经理,我们需要收集清楚信息,经过严格且缜密的需求分析,才能达到将用户需求转化成产品需求的目的。

4、真实需求与伪需求

要解释真实需求与伪需求的区别,可以看个例子:

做个市场调查,问1千个用户是否喜欢黄金,几乎所有用户都是肯定回答。那么这个时候就认定黄金是当下用户的需求,那么便过于草率了。

因为再深究下去,用户买了黄金干什么?对黄金的了解清楚吗?等等问题,深入了解完一番之后,用户可能就不会买了。

人性是贪婪的,“需要跟购买”是两回事,用户总是“说一套,做一套”。

再举个例子,用户告诉我们他需要钱,如果你不追问,可能只是知道他需要钱,并不清楚拿着钱去做什么。用户告诉我们的是他“想要”的东西,而我们需要知道的是“用户内在的心理预期”,从而了解用户的真实需求。

可以说,某些情况,用户“欺骗”了我们(厦门吴彦祖被欺骗,在线哭泣!)

图片

那么这完全是用户的错吗?

不是的,用户有时候都不知道自己更需要什么,他们更倾向于给出解决方案,当他们描述出他们的意向内容时,作为产品经理的我们,需要去剖析,从“伪需求”的表层下,挖掘出用户的“真实需求”

“伪需求”指的是当前用户并不一定需要,而是根据他们遇到问题所提出的解决方案之一,但并不一定能够完全解决他们当下的问题。

“真实需求”是通过梳理需求提出方当前的情况,遇到的问题所分析出来的结果。


二、需求挖掘与分析


1、用户是如何阐述需求的?

有一句话在产品界流传甚广:

“如果我当初问人们想要什么的话,他们只会告诉我想要更快的马。”

从而我们知道,用户的需求是想要一个比走路更快的交通工具。

这其实是个谬论,交通工具并不是结果,而是过程。

不妨再问一句:然后呢?

可能事实上是利用交通工具去上班,去自驾游等,目标不同,所能满足用户需求的产品也不同

由于阿境处于游戏分发行业,恰逢近期接触到了许多用户的反馈,拿其中一点举个例子:

“我想要更快的游戏速度体验”

在没有深入挖掘之前,我们可能会一股脑地去提升服务器容量、优化游戏代码质量,从而提升游戏速度,但用户是否是真的单纯地想提升游戏速度呢?

做几个假设

“更快的游戏速度体验→在有效的时间内玩到更多的游戏内容”

“更快的游戏速度体验→获得与游戏对手相同的速度→击败对手”

“更快的游戏速度体验→获得成就感”

......

就这几个假设来看,相同的需求描述,是不同的需求点。

A目前遇到的问题是游戏时长少;

B的问题是游戏卡顿引发地对战失败,想要赢得胜利;

C的问题是在游戏中获得成就感;

那么,我们是不是可以这么解决呢?

针对于A,提供个防沉迷账号;

针对于B,提供个游戏加速器;

针对于C,提供相应的成就徽章体系等;

乍一看,毫无毛病,仿佛一下子解决了用户的需求,于是又是一番大刀阔斧地改动优化。

图片

让我们把自身再抽离来看,ABC是否有更隐蔽的点需要我们去挖掘呢?

别忘了,人在描述一件事情的时候,往往会将观点以有利于自身的角度加工并阐述。

A可能是因为家长限制了娱乐的时间,从而无法获得更多的娱乐时间,即使提供了防沉迷的账号,也无济于事;

B可能是自身技术不太好,即使在相同的速度体验下,依然打不过对手;

C可能是对于游戏投入的不够多,导致在游戏当中无法获得更高阶的奖励(物质与名气);

若是如此,那么所应该提供给ABC的功能,可能又是另外一番答案。

从上面几个简单的例子,抽象来看,可以剥离出几个观点

图片

1)对于提出问题,用户更倾向于给出解决方案

人们往往倾向于解决问题的方案,而很少关心问题本身。所以我们常常会得到“我想要一匹马”的这种声音。

并不是用户提出的解决方案对于产品没有建设性,而是往往人在迫切解决自身问题时,提出的观点并不能查观全貌;

且用户并非产品的主导者,仅对部分功能有使用,那么在这个前提下,用户提出的解决方案能够一定程度地解决用户当前遇到的问题,但却可能延伸出更多的问题;

作为产品经理,通过自身对于产品的目标定位及价值理解,重视用户的解决方案,衡量解决方案底下所埋藏的需求的价值,才是重中之重。

2)在描述需求时,用户往往会将自身观点进行或多或少地加工

当用户对自身需求有隐瞒时,我们也就对需求的理解有偏颇,相同的解决方案,可以延伸出不同的需求。

由此,通过设定不同维度的问题,引导用户以描述性的角度,阐述自身的问题,才能够最大化地避免用户对于自身需求的美化加工。

3)需求并不是绝对的,在不同的阶段,用户会给出不同的需求观点

在初入游戏的时候,我们更需要的是一个教程带领我们了解更多的游戏攻略;

在游戏中度用户的时候,我们更需要的是游戏的体验性,攻略、工具等可能是在这个阶段中较为合适的需求。

在成为游戏深度用户的时候,我们更多的是在游戏中得到成就感,游戏成就体系等则应运而生。

由此可见,需求并非千篇一律,不同的阶段,用户提供到的是不同的需求观点。

“小时候我想要一颗糖,长大了我想要一辆跑车”也就是这个道理,需求受制时间的因素影响,也受制自身的发展影响。

2、如何挖掘需求?

这边的挖掘需求更多的是指主动地去挖掘产品需求。

这边有两种方式,一是从用户身上入手,从用户身上了解需求;二是从产品数据上入手,从数据上洞察需求。

图片

1)更好地洞察用户需求

洞察用户的需求本质是还原用户真实的需求,一般会采用直接访谈、问卷的形式,但是用户全靠一张嘴,因为所处的环境、心境的不同,往往得到的结果会有偏颇,在此阿境介绍两个方法。

一是深度访谈的方式,二是真实融入用户场景,通过这两种方式来进行洞察用户需求。

①与用户进行深度访谈

与用户进行访谈,是需求的来源之一。

而由于用户更多地是站在自己的角度上去体验产品,所以难免有些片面。

在访谈的方式,有比较详尽的方法,阿境后面会单独开一篇文章来介绍,这边就简单概括下。

包括①结构性访谈、②非结构性访谈

  • 非结构性访谈:是访谈者提供一个开放性的主题或问题,由报道人自由阐述;

  • 结构性访谈:是访谈者根据研究主题事先设计好的具体问题,系统地访谈研究对象;

这两个的区别是:

非结构性访谈能够通过开放性的问题,了解用户处理某个事情时的方方面面,但需要访谈者记录下全程并且提炼有效信息;

结构性访谈则更多的是根据固定设计好的问题进行,可以理解为问卷调查的线下版,对于访谈问题的设定有一定的要求,否则容易造成无效访谈。

通过这两种访谈方式,收集用户的真实情况:

①用户遇到的问题是什么?

②用户当前在处理问题的时候是怎么做的?

③用户想要的是什么?

在这个过程中,也有几个注意事项

①客观真实很重要,访谈者要剥离开自身的主观想法

②在舒适轻松的环境下进行访谈(最好是用户熟悉的环境)

③掌控整个过程,引导用户表达自身的想法

②真实融入用户所在的场景

通常我们在做访谈的时候,是以“设计者”的思维对“使用者”的采访,得出的结果相对来说有一定的片面性,同时我们作为“设计者”,不一定能够设身处地的作为用户的身份来考虑问题。

这也就是产品经理拥有“同理心”的重要性。

花费一定时间,成为产品的用户,融入到用户的真实场景当中,借此观察用户的在相应场景的行为及感受体验。

在这个过程中,我们可以观察几点元素。

分别是:用户、环境、任务、目标、行为。

用户:用户是怎么去做这件事的?

环境:用户当前所处的环境如何?

任务:用户当前的任务是完成什么事?

目标:这件事完成的目标是什么?

行为:用户用什么方式来完成这件事?

通过真实融入用户所在场景,并且观察这几个元素,来实现“边参与边观察”的目的。同时在这个过程中去真实的感受用户的情感变化,再将情感变化具象化为实际的数据或者描述

2)从产品数据表现发掘需求

做产品,数据是很重要的一环。

往往每个团队会搭建自身产品的数据概览,包括用户行为数据和业务数据。

具体数据不过多展开。

通过产品的数据,包括渗透率、留存率、页面转化等,长期观测,能够结合着察觉到产品数据的变化,而数据变化的背后是用户行为的改变,从而发现用户的需求迁移。

一般看数据,看现状看变化

看现状主要是了解业务距离产品目标的差距,能够加深PM对业务的认识。

看变化主要是养成数据感,通过数据变化,发掘产品问题,从而制定解决方案。

3、需求的基本要素

在拿到手一个需求的时候,如果是一句话需求“在直播tab想要添加一个悬浮球”,那么作为产品经理,没有充足的信息,很难评估该需求是否成立。

那么,作为需求本身,提出的同时,我们需要得知哪些必要信息呢?

包括需求的场景、解决的问题、目标等。

之所以需要理清需求的细节,一是因为有部分需求是伪需求,那么当提出人在梳理需求细节的过程中,可能就会幡然醒悟该需求也许是个伪需求;二是对于产品经理来说,清楚需求的基础信息,才能够更好地去评估需求。

可以看下阿境整理的需求九要素,当这些问题在需求的提出时也能够一起提交,那么便能够比较好地进行需求的评估。

可以关注公众号<梦想家阿境>,并回复“需求分析”,有阿境整理的《需求提交文档范例》《需求九要素》。

图片

1)需求的类型

一般分为两类,政策需求、线上bug需求、线上漏洞需求、合同期限需求、普通需求等。

政策型需求一般是根据国家颁布的法律法规所衍生出的需求,普通需求则为除了政策型需求以外的需求。

之所以需要区分需求的类型,则是因为政策型需求的必要性及严重性,故无需过多的分析,在满足政策的要求下,最小化成本执行即可。

2)需求的场景

根据百度释意,需求的场景是指在一定的时间、空间(主要是空间)内发生的一定的任务行动或因人物关系所构成的具体生活画面。

需求的场景有几个要素:用户(who)、时间(time)、空间(where)、动机(why),行为(what)。

即,什么用户什么时候哪个地方,因为什么动机做了什么事情。

3)需求解决的问题、解决的痛点

在需求对应的场景下,用户遇到了什么问题?在这个问题下,是完全无法进行下一个步骤,还是仅仅是操作不顺畅等。

在描述问题的时候,需要越详细越好。

4)当前针对该需求的解决方案是什么?

针对于遇到的问题,当前是否有其他方式能够解决?

若有,则用户/运营/业务人员等是采用什么方式来进行解决的?解决的具体步骤是什么?需要详细的描述。

5)需求的目标

需求要达到的目标是什么?

一般包括数据性指标(提升多少渗透率/留存等)、优化型目的(eg:用户更好地回到顶部tab)。

通常目标尽量可量化,也需要了解当前的情况是如何,才能确定需求能达到什么样的目标。

6)需求价值判断

需求的价值判断包括需求的频次、覆盖用户、刚需程度,这几个维度主要都作为评估需求优先级的判定标准。

①需求频次

该需求的使用频率是多久?

一个月一次?每天一次?每天多次?不同的触发频率,在评估需求的优先级及选择解决方案的时候会有较大的不同。

②涵盖用户

需求的目标用户群体?

需求涵盖的用户是哪部分用户?该部分用户占据产品的占比是多少?

一般了解需求的用户,主要是清楚需求的涵盖范围,作为需求优先级评估的评定标准之一。

③刚需程度

用户对于需求的需要程度?(如果不做这个需求会怎么样?)

当前需求如果有其他的解决方案,用户是否能够使用?使用的情况如何?

7)需求的优先级如何?

这边的优先级主要指需求提出方基于自身所了解的信息,对于需求的评估。

另外,可以指出对于需求优先级的评估依据,能够更好地帮助产品经理准确判断需求的真实优先级。

8)需求的预期解决方案是什么?

对于需求的提出人(用户/运营/业务方等),针对于上述需求的基本情况,可以简单阐述需求的解决方案。

该方案虽然不一定是最终解决需求的方案,但能够清楚用户对当前问题的预期想法,作为我们做方案的参考依据。

9)其他基本要素

包括提出人、提交日期、期望完成日期。

主要是能够对需求进行溯源及整理。

4、如何进行需求分析?

需求分析,实际上的问题是“如何判断一个需求是否要做?”

在了解了需求的收集、基本要素以及挖掘需求的方式之后,下一步便是进行需求的分析。

但在需求分析之前,除了收集了需求本身的信息,还需要有其他的信息辅助我们做决策,后续才能够对需求进行合理的判断。

1)基础信息整理收集

①当前业务的数据(包括用户行为数据、业务数据)

②当前业务的运营情况

③当前产品对于该业务的规划情况

④竞品分析,了解竞品的情况

⑤用户调研访谈情况(调研问卷、访谈等)

图片

再了解了业务方提供的信息之后,我们往往无法判断需求是否要做,此时结合上述的五部分内容,补充对于需求的了解,由外而内。

“外”指的是竞品对于该需求的处理情况,行业内的解决方案如何。

“内”指的是当前业务的数据、运营情况、自身产品规划、用户调研等。

两者相结合,能够对需求所处的环境有个全面的了解。

2)需求分析八步法

阿境总结了“需求分析八步法”,可以说是本篇文章的精品之精品了,不得不看!(比厦门吴彦祖阿境的脸还精品,你说精品不?)

分别是“析要素、挖场景、推价值、看用户、拆竞品、盯市场、查现状、定规划”,且听吴彦祖给你们一一讲解。

从这八步法分析过后,便能清楚需求是否要做,如何正确地剖析一个需求。

可以关注公众号<梦想家阿境>,并回复“需求分析”,有阿境整理的《需求分析八步法》。

图片

①“析要素”

分析需求基础要素。

上述提到需求要素包括需求的类型、场景、解决问题、目标、需求价值、优先级、预期解决方案等,之所以是”析”,是因为从需求提出方接到需求之后,往往是不完善的,我们需要去剖析直到了解完整且正确的需求内容。

一丝错误的信息,比如目标不清楚,场景不正确等的偏差,都会影响我们对需求的评判。

②“挖场景”



挖掘需求对应的场景。

这其实是需求基础要素当中的其中一个,但之所以单独拎出来谈,是因为脱离了场景谈需求,是不合适的。

用户+场景=需求,场景占据了很大的一个部分。

充分挖掘需求所对应发生的场景,从而了解用户真实的问题,才能够得到合适的解决方案。

③“推价值”

推敲需求价值。

这个需求价值可以以用户、产品、企业三个维度的角度来分析。

对于用户来说,给用户提升了什么价值?也就是用户价值。

对于产品来说,提升了产品的什么功能指标?也就是功能价值。

对于企业来说,提升了企业哪部分的收益?也就是商业价值。

这三部分综合起来便是在分析过程中所应该明白的需求价值。

④“看用户”



看待用户对于该需求的看法,了解以及使用情况,这一步是摸<检查>的预期及日常使用情况,从用户视角看需求。

一般是采用用户问卷调研,用户访谈的方式,通过直接去接触用户,得到最真实的用户感受,当然,在这当中,合理的设计问卷,合理的设计访谈问题,控制访谈的整体节奏,也是重中之重,是能否得到正确且真实的用户感受的前提之一。

⑤“拆竞品”

拆解分析竞品(包括直接竞品、间接竞品)的现状,在明白竞品的用户、商业模式等基础信息的前提下,从竞品的角度去分析对应需求的作用。

借此达到管中窥豹的目的,结合自身产品,明白相似的需求我们能够从中借鉴到什么内容,给予我们什么样的灵感和帮助,同时也了解竞品的不足,在产品设计中能够适当规避。

⑥“盯市场”

紧盯市场动向,对于该需求,摸清市场上的看法以及各大产品各自的发展迭代逻辑,通过市场的反馈及发展,剖析该需求所对应的业务的长久规划。

⑦“查现状”

摸查产品目前现状。也就是产品经理对于当前产品业务的了解程度越高,那么在分析的时候,结合自身产品业务的现状来分析,便能够极大地减少判断错误的概率。

这包括产品当前所处的生命周期,业务的数据情况,业务的运营情况,共三大部分能够概括现状。

⑧“定规划”

确定需求所对应业务的短期、中期、长期规划。

根据规划,了解当前需求解决的问题,处在规划的哪一部分。从整体回归局部,以先总后分的分析思路,理清需求的位置。

3)需求其余条件评估

①需求是否符合当前产品发展的方向规划

②需求对于平台其他业务有什么联动影响吗?

③如果做了这个需求,成本层面与收益层面是否成正比?


三、如何管理需求


1、需求的收集

1)为什么要进行需求的收集及记录?

我们在做版本迭代的时候,往往有一定的需求需要消化,而需求的来源就较重要了。

平时缺少了需求的积累,那么在版本迭代的时候,便会手忙脚乱。

主要的原因有三:

①需求来源众多

②需求并不是当下就需要进行消化

③需求多级传递导致需求歧义

图片

“少壮不努力,老大徒伤悲”,通过平时的需求积累,标注需求的优先级等,能够有效地扩大产品的需求池,从而在适当的时机,通过消化需求,解决用户的真实问题。

2)需求收集的本质及原则

需求收集的本质,在于“收整”及“归纳”。

原则是以用户为中心,以市场为导向,以行业动态为基准,客观地进行需求的收集,同时需要具有远瞻性,当下不符合产品发展的需求,不代表以后不符合。

但一定程度上,用户不一定是需求的来源,目标才是。

图片

3)需求收集方式

需求的收集方式,通常来源于七个:产品规划、内部人员、业务部门反馈、用户反馈、产品数据表现、竞品分析、行业动态。

图片

①来自产品规划

作为产品经理,对产品需要有明确性的规划,清晰自己产品定位所在,产品的规划也是极其重要的。

在产品/业务的不同阶段,产品经理依靠自己的规划,制定不同阶段的目标,从而延伸出相对应的需求。

②来自产品内部人员

产品内部人员包括产品经理、研发、交互、设计、老板等,主要代指产研线上的角色。

一个产品通常有多个产品经理,在日常迭代当中,产品经理有自己对于业务模块的思考,同时经过一系列的调研、数据等,能够发现自身产品的问题,提出需求。

研发、设计、测试等偏研发/设计侧的人员,则是站在自身对于产品的理解所提出的需求,更多的是单独模块,单独功能的优化。如调整主题色、调整客户端接口,优化页面交互方式等。

老板这个角色一般是提出战略性、大方向的议题,不一定是具体的需求。如确定产品的发展方向,从而产品经理经过论证确保可行后,根据方向进行分析拆解成具体的需求。

③来自业务部门反馈

业务部门通常包括运营、售前、售后、商务、市场、客服等。

不论是客服还是运营,这些岗位都是离用户最近的岗位,通常我们所说“倾听用户的声音”,而在客户与用户的沟通过程中,运营在工作的过程中,都能够结合用户的需求,以及产品可优化的部分去提出需求。

④来自用户反馈

用户反馈包括应用意见反馈、用户访谈、社区论坛、主动联系反馈等。

倾听用户的声音对于产品,是很重要的。

由此产品经理对内需要建立完善的用户反馈机制,对外需要搭建用户调研/访谈流程。

其中用户调研包括两种,定性调研和定量调研。

定性调研,主要调研文化背景与生活环境、用户的经验和习惯、探索用户行为背后的原因。最具代表性的是用户访谈。

定量调研,主要调研各个变量之间的关系,是通过各种数据呈现的客观事实。最具代表性的是问卷调查。

在倾听用户声音、用户访谈的过程中,需要注意的是进行信息的解析,也就是根据用户传递的内容,过滤掉失真的那部分,从而得出有效的结果,进而才能够转化成产品需求。

麻省理工大学的心理学家罗伯特·费得蒙研究表明,60%的人在10分钟的交谈中会撒谎2到3次,男人和女人撒谎的频率差不多。

“人们是无法告诉你他们真正想要的是什么,但是可以通过引导让他们说出来。”

准确洞察用户需求的基础是让用户对你说正确的话,有兴趣可以跟阿境单独聊聊,这边不再展开。

⑤来自产品数据表现

“用户会骗人,数据不会骗人”。

可口可乐公司在20世纪80年代,做了一个实验:一款新口味的产品,一款原口味的产品,让实验者挑选,在填写问卷的时候,85%的人选择了新口味的产品。

而真正投入市场后,这85%的人,有90%的人又反水选择了原口味的产品。

从这个试验中可以看出,用户是会骗人的。但是他们的行为数据不会骗人,最大化的还原了用户的心态,选择。

作为产品经理,我们需要根据产品/业务本身的数据表现,发掘问题。从用户层面上来说,在产品当中进行数据埋点,通过用户在产品当中的行为,最大化地了解用户所遇到的问题。

通过宏观数据,查看用户在产品当中的行为;比如渗透率、留存、页面转化、人均次数等行为数据的变化,可以了解并分析用户在产品当中遇到的问题,从而形成需求并解决。

同时,用户的行为表现在数据上,通过这些,能够清楚用户的行为方式,用户的关注内容,当看得多了之后,会抽象出这个群体用户的行为特征,从而帮助产品经理更深入了解不同的用户群体。

ps:下图为脱敏后的一些产品数据图,如渗透、留存、人均次数、打开路径占比。

图片

要注意的是,产品的数据表现,并不能够单独来评判一个需求的启动与否,容易有失偏颇;往往需要结合用户调研,用户访谈,产品内部分析等方式加以评估。

⑥来自竞品分析

《孙子兵法》中提到“知己知彼,百战不殆”。这其中,“知彼”便是了解竞争对手。

竞品做的不一定是对的,但是一定是“行出有因”。

作为产品经理,需要尽量多地汲取外部相关信息、行业信息,以辅助各种判断和决策。为了跟踪竞品动向,以他山之石鉴己之发展,同时也能够与竞争对手进行抗衡,通过竞争分析来提升产品的竞争力。

从产品的战略层面来看,竞品分析能够为产品提供战略、布局规划的参考,同时,在产品设计上取长补短,也能够预警避险。

通过竞品分析,了解到竞品的动向后,也可形成具体的产品需求,从而为产品的后续发展做好提前准备。

一般对于竞品分析,有两个方面可以收集。

1、平时进行竞品的更新检测,了解竞品动向,收集产品需求。

2、针对于个别业务/功能,对竞品进行针对性分析,输出竞品报告,抽象出需求点。

⑦来自行业动态、政策方向

根据行业的政策动向,也会延伸出相应的政策性需求,如 《计算机信息网络国际联网安全保护管理办法》等的颁布,相应的产品就需要履行相关的法律法规。

通常政策性需求的优先级及紧急程度都是最高的,否则产品就会面临下架风险。

4)需求收集的几个要点

1、以用户为中心,而非以产品为中心

2、收集需求时,规范记录,保证信息不失真,且可回溯。

3、需求收集需要主动深入挖掘用户的真实需求,而非反馈的表面问题。

2、需求的记录方式

通常我们把需求的记录称为“需求池”,是产品经理将所有和产品相关的需求信息按一定的规则进行汇总记录的地方。

简单点说,就是一个存放需求的地方。

而需求的信息、类目繁杂,需要有一定的记录方式,才能够使得庞大的需求池多而不乱。

下面会讲讲需求的记录方式,以及需求记录的相应工具。

图片

1)记录方式

①所属板块

一个公司可能有多个产品,一个产品可能有多个端,故当混杂在一起时,需要以板块的字段来区分

范例:wap端、安卓端、ios端、小程序端、客户端、服务端等,根据自己公司业务的情况来划分

②所属业务

标记需求对应的业务模块,主要便于后期能够根据业务来区分需求的归属。

范例:直播、视频、订单、商品、游戏下载等

③需求来源

需求的来源标识一般有:来自用户、竞品调研、产品规划、运营/业务需求、政策要求,共五大类。

具体根据各公司业务的不同标识来源字段略有不同。

④需求状态

状态一般分为:待补充信息、待讨论、需求调研中、需求设计中、开发中、已完成、废弃、暂缓

具体细节从描述中可窥探,这边不过多赘述,主要是描述需求从提出之后到完成/废弃的状态过程的记录。

⑤需求时间

包括开始时间、结束时间

更重要的是结束时间,有个明确的截止时间;一个需求往往有多端参与,包括产品、交互、测试等等,所以在记录这个需求时间的时候,也可以一并考虑不同端人员完成各自任务的时间(涉及到项目管理部分)

⑥需求背景

需求背景描述的是需求当前产生的缘由,在什么条件、什么时间、什么场景、什么资源的情况下所产生的需求,重点描述问题所在。

可以从大环境趋势、行业动向、公司情况、产品/业务现状四个方面上来阐述背景。

⑦预期方案

预期方案主要是根据当前需求的信息(包括需求背景、业务运营情况、数据情况等),所得出的预期方案,但仅仅是当下的思考并记录,不一定合适;

具体的方案还需与设计者(产品/交互/需求提出方)共同协商讨论。

⑧需求价值

需求价值侧面反映需求的重要程度,有的会以“重要”“非常重要”来描述,但太过笼统,并且不能定性分析,故需要再拆分为用户价值及产品价值,来描述需求的重要程度。

用户价值重点阐述问题被解决的程度,站在用户的角度上思考这个需求是否能真正解决用户当下的问题,解决的程度如何。

从俞军老师的理论上来看,用户价值=(新体验-旧体验)-替换成本。

产品价值包括三方面,功能价值、情绪价值、商业价值,阿境简单说下。

功能价值指通过功能给用户提供服务,解决用户的核心问题;从技术壁垒人无我有、创新点人有我优、细节给用户带来惊喜、行业风口上的产品功能规划的方式去考虑功能价值。

情绪价值是产品除了基础功能外,满足用户的心理需求,如成就感、虚荣感等;放大积极情绪、减弱消极情绪是核心点。

商业价值代指产品的吸金能力。且先有的用户价值,再有的商业价值。

总的来看,产品价值以“提升功能价值、增强情绪价值、构建商业价值”三方面来入手分析需求价值。

⑨紧急程度

紧急程度一般分为:不紧急、紧急、非常紧急。

一般根据实际情况调整。

⑩需求难度

需求难度一般分为:高、中、低

偏主观性的一个字段,主要通过前期对需求的了解评估,将其与开发简单评估下,做出的评判。

⑪相关人员

若需求涉及多部门人员,则需要填写需求涉及到的相关人员,便于后期追溯

⑫备注

备注当中一般描述字段以外的自由内容。

可以添加相应与需求有关的材料,比如竞品调研、用户调研、当前业务数据等等,目的是为了更好的给这个需求做决策。

2)记录工具

可以采用excel进行记录、也可以采用teambition等协同工具进行记录,切记,工具只是协助我们进行更好的进行需求梳理。

3)需求记录原则

需求记录原则遵循四个“可”。

需求来源可追溯,需求场景可还原,需求分析可实现,需求推进可持续。

只有在记录的时候达到这四个,才能够保证需求的传递不失真,真实还原需求是需求分析的首要前提。

图片

4)需求池的搭建方法

需求池可以说是需求管理的一剂良方,像是产品经理的“需求记账簿”,但是要搭建一个健康、不冗余且有效的需求池,还是不那么容易的。

一个健康的需求池要达到的几个要素是:容易查找、清楚需求进度、了解需求状态。

①以结构化的思维,根据产品实际情况,划分整体需求业务分类。

②规范各业务方提交需求的需求格式(极其重要!!!),保持需求原始信息的真实记录。

③进行需求规整,对需求原始信息进行补充,分析及加工。

④标记需求状态,进行需求信息的持续完善

⑤及时维护需求池。设定周期时间,在每个周期时间内都整理一下需求池中的需求,及时进行需求状态的变更调整,抛弃无效需求,完善有效需求。

3、需求的分类

当需求池中积攒了许多需求的时候,一团糟,这个时候就需要根据一定的方法进行需求的挑选、标记及分类。

图片

1)需求标注及筛选

①标注

当业务方/运营提需求上来之后,需要进行需求内容的标注,往往会出现需求内容不全面、需求格式不对等问题,这个时候就需要产品经理对应的去与需求提出方进行深度沟通,挖掘需求当前的有效信息。

ps:在提交需求时,产品经理可以提供一份《需求提交规范》给到需求提出方,根据这份指南来走,往往提交上来的需求会相对有效。

可以关注公众号<梦想家阿境>,并回复“需求分析”,有阿境整理的《需求提交规范》。

②筛选

这一步骤主要是“去伪存真”,根据全面且详尽的信息,评估出该需求的真实与否,是否是“伪需求”,若是,则需求需要进一步考虑是否废弃。

且在需求筛选这一步中需要进行优先级的评估,高优先级的筛选出来,在近期的版本中进行迭代优化。

2)需求分类

需求的分类往往是根据业务类型、业务端来区分。

业务端主要是:小程序端、app端、服务端等

业务类型主要是:直播、视频、游戏等,具体看每个产品的业务而定

有的产品较大,一个产品往往多个产品经理负责,那么就需要根据不同的业务分配不同的产品经理进行负责。

4、需求的优先级及排期

为什么要排需求的优先级呢?

因为“这个很重要”“这个很紧急”“这个优先级最高”往往是业务方的口头禅,那么当那么多所谓的“优先级很高”的需求摆在我们面前,“双拳难敌四手”,总需要有个先后处理的顺序。

要记住,需求优先级的本质是“性价比”。

在前面提到的,我们会给需求标注“重要程度”、“紧急程度”两个维度,这两个维度怎么区分呢?

图片

重要:以核心业务、核心用户、商业价值、竞争优势等方面去评估。

紧急:以严重程度、时间对比、需求频率等封面去评估。

清楚了“重要”“紧急”这两个维度后,那么按照时间管理四象限的思维。我们就可以分为四个方向。

  • 重要且紧急:短期内一定要做的需求。通常是产品重大bug,政策需求,重点是“快且好”。

  • 重要不紧急:重要但可以长期做的需求。比如某功能模块的规划等,重点是“有计划”。

  • 不重要但紧急:对产品、用户的作用可能不大,但短时间内一定要完成的需求。

  • 不重要不紧急:时间维度不敏感,且评估后重要性也低的需求。

当然,从四象限模型并不能够完全地解决现实中评估需求优先级的情况,需求优先级的评估需要结合更多的维度。

阿境这边总结几个常见的维度,大家可以综合自身业务情况来考虑。

图片

1)需求的类型

主要包括政策需求、线上bug需求、线上漏洞需求、合同期限等,明确需求的类型主要是为了明确需求的紧急程度,不同类型需求的紧急程度不尽相同。上述提到的需求类型,紧急程度一般是最高的。

2)产品发展方向

一个产品通常在发展的时候,通常会经历四个阶段:导入期、成长期、成熟期、衰退期;根据产品的不同阶段,产品经理会相对做不同的产品规划,也就是确定产品的发展方向。

不同的发展方向,对需求的优先级也有影响。

比如一款产品,核心业务包括社区跟直播,但产品近半年的发展方向是社区的内容,那么同时社区与直播的需求,在其他条件相同的情况下,社区需求的优先级是会更高一些的。

3)业务价值

不同的需求通常涉及不同的业务,业务价值也是需求优先级的一个重点考量因素。

业务价值是产品价值的拆分,与之类似。通常包括两部分:商业价值、功能价值。

商业价值指的是该业务为产品带来的盈利空间;

功能价值则体现在产品的数据指标,如渗透率、留存率,流程转化等,通常是从侧面提升产品整体水平。

不同业务的价值是不同的,其他条件同等情况下,业务价值大的需求>业务价值小的需求

4)影响范围

需求的影响范围包括该需求涉及业务模块的目标用户量,需求被用户使用的频率,这两个指标包括了需求的影响范围。

更细一步进行拆分,则可进行分析目标用户的用户价值。

举个例子:A需求涉及用户1w,B需求涉及用户5w,但1w用户的用户价值远大于5w的用户价值,那么虽然目标用户量A>B,但其他条件同等的情况下,A需求还是优先于B需求。

5)需求成本

需求的成本也是需求复杂度及难度的体现,需求复杂度与需求成本成正比。

需求的成本包括产品成本、研发成本、交互成本、设计成本、测试成本等。

可以理解为一个需求从诞生开始到落地所能够涉及到的所有流程(其中也包括沟通成本等这类无形的成本)

往往我们在估算成本的时候只估算了研发成本,但那只是需求的实现,在实现之前还包括需求的调研、分析及讨论,以及可能涉及跨部门的沟通,这些都是成本之一。

评估需求成本需要全面、完善

综上的五个维度,一般是评估需求“重要”、“紧急”的一些评估因素,结合每个因素,往往我们是去进行定性分析;

但当多方意见有偏颇时,就需要定量分析,大致的思路便是将每个维度进行打分,然后乘以不同维度的权重,再将其相加,从而得出该需求的最终得分。具体的实际操作方式若有疑问也可跟阿境探讨。

另外,需求的优先级不仅仅有上述的方式(ICE分析法),还有KANO模型等。

KANO模型由于其方式在真实工作中实用性较低,这边阿境仅简单介绍。

基本(必备)型质量——Must-be Quality/ Basic Quality

期望(意愿)型质量——One-dimensional Quality/ Performance Quality

兴奋(魅力)型质量—Attractive Quality/ Excitement Quality

无差异型质量——Indifferent Quality/Neutral Quality

反向(逆向)型质量——Reverse Quality

可以通过问卷的形式,获得较为准确的KANO分类,再通过Better-Worse系数确定需求所属的象限,进而判断优先级。

图片

ps:

①优先级是相对的,没有绝对的高优先级需求。

②优先级不是一成不变的,随着时间、产品形态、市场形式的变化,优先级也会随之改变。

5、需求变更

1)为什么存在需求变更?

众所周知,开发小哥往往是听到“需求变更”脸色都变了。

需求变更有外界的因素(eg:对接不当),也有自身的因素(eg:优化策略);针对于这两者,都可能存在需求变更。

需求变更并不是越多越不好,而是一种风险规避的方式,在项目的进展阶段,越早进行变更,则能够将未来发生的风险降到最低,也能够使需求真正达到原本的目的,解决实际的问题。

但需求变更存在项目资源的浪费,所以原则上,能少则少,若有必要,及早变更。

产生需求变更的因素有很多,其中包括一下几点:

信息传递有偏差,一般发生在与业务方对接需求的时候,导致需求方向错误,且没有经过逐次确认。

②产品经理前期对业务思考不足,导致设计出的需求无法解决现有问题。

撰写需求文档时,逻辑性、完整性、合理性等颇有不足,导致文档不符合开发标准。

④评审会上对需求的细节没有讨论到位,排期评估上对需求的评估也有偏差,导致需求在开发当中需要及时调整。

⑤在开发或测试的过程中,当需求涉及到真实数据的时候,发现产品原本的设计方案与预期设想的不同,于是需要进行变更。

业务形态发生变化,当在需求的开发过程中,公司的商业模式或运营模式发生改变,则产品也需要进行及时调整方向。

上述六点需求变更的原因中,除了第五、六点,其他方面基本都是可以通过一定方法来减少需求变更的频次的,第五点的变更原因,则是为了更好地达到原本的需求效果。

2)如何减少需求变更?

①涉及业务方的需求,在前期对接,且需求产出之后,与业务方确认需求方案是否满足业务

加强对自身业务的了解,多查看行业内的报告,了解自身产品实际数据、运营情况,业务发展方向,从而能够更好地对业务需求进行决策。

做需求之前进行充足的需求调研、需求风险评估,需求成本评估等。

④评审会前、评审会中、评审会后三个阶段,产品经理都需要及时的进行需求疑问点的沟通及确认,避免因需求完整性、逻辑性、合理性而产生的问题。

⑤对于需求内容,往往需求撰写者深陷其中,无法直观发现问题,可以内部进行评审/讨论,从而在需求评审前解决掉需求文档本身存在的问题

⑥产品设计中,多留意往常需求变更的原因(例如后台的设计等),灵活总结变更前后特点,做产品需求的设计时多注重灵活性

图片

3)需求变更需要做的事情?

一个需求变更,往往不是一瞬间的事,而是一个过程。

在产品经理察觉到需求需要变更时,则需要做几个步骤

①预先周知项目组该部分内容可能产生变更,若正在开发,则需要及时中止需求,避免投入更多的资源。

②保证需求合理性的情况下,尽量在最短时间内处理变更方案

周知项目组相关人员变更背景,变更内容,变更影响点;同时项目组重新评估需求

做到这三步,才算是需求的变更结束。(往往大家容易遗漏掉第一步,导致部分的项目资源浪费,因为在意识到需求需要变更的时候,距离变更后的方案还需要一段思考及修改方案的时间。)

6、需求评审与开发

需求的评审与开发涉及到项目的流程,这其中涉及项目管理中的项目监控的环节。

包括需求开发过程中的周会,用于监控需求当前的状态;产品需求的验收,用于验证需求是否能达到预期等。

本文主要聊需求的挖掘与分析,开发过程便不再过多赘述。


四、需求自检清单


这边的需求自检并不是指需求文档本身的清单,当然,如果要,阿境这边也有,详见《人手必备的产品自查表》。(厦门吴彦祖没有啥是没有的!)

需求自检清单指的是从需求的萌生后,产品经理所需要考虑的点是否完善且详尽。其诞生的本质是上述文章内容所涵盖的核心点。

1、是否了解了需求的目的、背景、来源等基础信息?

2、是否有对需求进行需求价值的分析?需求的核心用户、发生场景是否了解?

3、针对该需求,所涉及业务模块的数据是否了解?

4、针对该需求,当中涉及到的运营场景及日常运营操作是否清楚?

5、是否有与需求提出方进行完整、详细的了解?

6、对于该需求,其中背后存在的问题,其他竞品是怎么做来解决的?

7、需求完善清楚后,是否有进行需求内容的完整记录?(记录需求池)

8、需求的关键指标(目标)是否清楚?(可采用GSM模型来梳理)

9、需求的业务流程是否清楚?

10、当前情况的流程与需求完善后的流程对比,两者的区别是什么?

11、需求对于平台其他业务有什么联动影响吗?这些逻辑及流程是否了解?

12、现有功能是否能够解决需求所对应的问题?如果能,则还有多少可优化的空间?

13、需求是否符合当前产品发展的方向规划?若符合,处在哪一阶段?

14、如果做了这个需求,成本层面与收益层面是否成正比?

可以关注公众号<梦想家阿境>,并回复“需求分析”,有阿境整理的《需求自检清单》、《最全产品自查表》。


五、一些跟需求相关的tips


1、需求不会改变,但需求的解决方案会随着时间的改变而变化

2、需求需要根据用户的不同、场景的不同、时间的不同来考虑

3、只有较低层次的需求得到满足后,用户才有动力去追求更高层次的需求

4、需求可做大可做小,就看本质是想要达到一个什么样子的目的(不为了做需求而做)

5、需求考虑性价比(如果做3个需求能够满足80%的要求,做20个满足100%的要求,那么选择前者)


六、写在最后

这是阿境近来输出的一篇较为系统性的文章,从需求的概念、本质入手,逐步讲到需求的收集、评估以及分析,从概念理解到落地实践,由浅入深,希望能够对需求分析有疑问的朋友有一个系统的认识。

也相信认真吸收了文章内容之后,一些关于需求的面试题基本都能够解决了。

想说的是,需求分析只是一个思路,但并不是一个固定的框架,用户的需求会变,同样的,需求的分析方式也会随之改变。

“要了解怎么分析,并付诸行动,但不能仅仅局限于条条框框按部就班地分析”

需求分析需要结合自身对市场的洞察,用户的研究,产品的思辨,但同时也需要考虑其他多种维度,比如人性。需要“理性+感性”相结合着来。

毕竟做产品,是为了有趣。

]]>
https://coffee.pmcaff.com/article/qVkVgeW7LO https://coffee.pmcaff.com/article/qVkVgeW7LO Thu, 15 Sep 2022 10:29:21 +0800
<![CDATA[ PRD里面,一个完整的功能模块需求,应该怎么写? ]]>

写PRD是产品经理的基本功,大部分需要做执行的产品经理,都会花很多时间在写PRD上,写好PRD,才能将用户需求更好的转为产品需求,让产品方案落地。

PRD分为很多个模块,一份完整的PRD应该包含如下这些模块:

ee917d67cf829e037fe5b68e0f659cbf-picture

完整PRD模块,可关注公众号『刀哥说』获取模板

在实际的功能中,耗费时间较多,又主要是具体的用例(功能)模块,因为每个产品,都可以拆分成一个个独立的用例,用例的拆分,可以按步骤或者按功能模块,详细的拆分方法,可以看刀哥之前的文章,这里不详述。

本文的重点是分享具体用例的详细写法,把一个个的用例写好,可以极大的提升整个PRD的质量,减少和前后端开发撕逼,减少需求的变更,可以腾出更多的时间去研究行业,研究竞品,研究用户。

产品经理的核心竞争力,一定是对行业、用户的认知,产品的基础工作,花的时间越少越好。

01.用例

在说如何写用例之前,我们先来说一下,什么叫用例。用例是对用户通过系统完成目标的一系列过程的描述。用例是一个逻辑过程,一个标准的用例名称应该是动宾结构,比如登录系统、录入资料、找回密码……

一个完整的用例,我把它分成几个核心部分:1、前置条件/后置条件;2、业务逻辑;3、界面交互。完整的结构如下:

f5623da6713ecbf7cc9a470764ecca7b-picture

一个用例包含的关键要素

用例是UML里的标准术语,在实际和业务或者研发打交道的时候,经常叫做功能模块,功能模块也好,用例也好,产品经理自己一定要清楚这些概念的底层含义。

02. 前置条件/后置条件

需要提醒一点的是,在写具体需求的时候,不一定要按照某种严格的格式去写,除非公司有严格的要求,刀哥也有比较规范的PRD模板,关注公众号『刀哥说』,回复1可以自取。

但是在写的时候一定要按照这个思路,第一步,是先思考前置条件和后置条件,这个部分写的内容并不多,但是通过这部分的描写,就能弄清楚用户在执行完这个功能后,系统处理的结果是怎样的。

前置条件比较常见的就是用户状态、等级和类型等,比如用户要成功登录系统,前置条件是用户状态正常,后置条件是成功登录,进入系统。

比如用户要在系统里面新增一条数据,前置条件是登录状态,具备功能的操作条件,后置条件是完成在系统里面添加条数据,完成数据创建。

前后置条件有时甚至都不用写,比如用Axure写PRD的时候,但是产品经理心里一定要有数。

03.业务逻辑

这个部分,我觉得是最重要的模块,比界面交互还重要,也是产品经理的核心,产品经理的交互能力比较差还可以通过UED团队来弥补,如果业务逻辑差,那真是没得救。

业务逻辑我把它分成几个部分:主流程、分支流程、业务规则。

主流程,是通过活动图的方式,说清楚用户和系统的交互主流程。

分支流程,是在主流程的基础上,梳理各种分支和异常情况。

业务规则,则是流程判断的依据。

我拿一个审核工单的用例为例:

d4391117c18a285f09206e844716497d-picture

审核工单的主流程、分支流程和业务规则

实际梳理业务流程时,可以将分支流程和异常流程也加入到流程图里面去,颗粒度也需要自行掌控,根据团队情况。

这种业务流程图,也叫活动图,是用户和系统的交互过程,也是业务逻辑部分重要的分析工具。

系统在处理或者判断的时候,需要根据一系列的规则来执行,在梳理主流程和分支流程的时候,可以针对具体的流程节点,梳理业务规则。常见的业务规则如排序、数量、状态、顺序、时间。

梳理业务规则的时候可能会用到ER图和状态机图,有兴趣可以刀哥之前关于业务流程的文章。

04.界面交互

按『用户体验的五个要素』来划分,界面交互属于表现层和框架层,界面交互涉及到细节比较多,如果考虑不全的话,会产生很多细节问题。

业务逻辑部分,后端开发更关注,而界面交互部分,前端开发更加关注。

界面交互有几个核心部分:字段规则、界面展示、控件、页面跳转。

aedc8021ac9eeeafe495fa77a18fcc09-picture

界面交互的要素

1)字段规则:字段规则主要是输入类的字段,所有输入的字段,需要考虑输入控件的类型、是否必填、字段规则、提示这几个要素,在写PRD的时候,可以通过表格的方式呈现。

2)控件:界面上有哪些交互控件,控件在不同状态下的展示样式,比如输入框默认状态、失焦状态,输入内容时,是否支持一键清除等,输入错误时,边框是否变红等。

3)页面跳转:点击链接或按钮,跳转到哪个页面,跳转到页面时,是否会带上参数,跳转页面后,再返回,界面上的数据怎么处理。在加载页面时,是否显示loading,加载失败怎么展示,页面404、500等缺省页面是否有准备。

4)展示:数据展示的规则,界面展示的每一个数据的来源是哪里,如果超过长度怎么展示,不同状态下怎么展示,空状态怎么展示。

其他还有一些常见的比如列表排序,数据埋点等,都是属于界面交互的部分。

05.写在最后

之前刀哥写过一篇文章,把做产品当做玩游戏,一共有四关:

3f3b09a4f8a5ec7cc96089ca5af92b3f-picture

只有过了基础的第一关,才能进入第二关,而要过第一关,就需要踏实的基本功,如果基本功不好,永远过不了关,一直在做功能,而不是做产品。

写好PRD还有一个很好的方法是,把写PRD梳理成一个SOP,归纳一套组件库,汇总一份自查清单,有标准模板,也有标准的写作思路,这样就能保证输出高质量的PRD。

组件库、自查清单、PRD模板,刀哥的资料库里,已经有比较详细的了,如果有需要,关注刀哥公众号:刀哥说,回复『1』即可自取。

]]>
https://coffee.pmcaff.com/article/qVkVge3eLO https://coffee.pmcaff.com/article/qVkVge3eLO Mon, 12 Sep 2022 21:02:19 +0800
<![CDATA[ 最重要的两种思维:逻辑思维与结构化思维 ]]>

微信公众号:涵小仙女。文艺女青年一枚,白天工作,晚上码字,爱美、爱跑步、爱旅行,愿我手写我心,余生不将就。



日常工作中,除了时间和精力管理 \ 目标、计划与执行2种方法,还会再谈思维方式。老话说:让你与众不同的不是努力,而是思维方式

思维方式是个很大的话题,在一些营销号上会讲“掌握50个思维模型,建议收藏”。更有著名的查理芒格的100个思维模型。100个门槛太高,今天只讲两个基础版:逻辑思维与结构化思维也是我每天工作反复被调用很多次的两种思维方式

从100个思维模型中专挑这两种花5、6千字来讲,是因为这两种思维方式极其重要,相比于各种方法技能,逻辑思维与结构化思维欠缺是工作混乱的根本原因,是大脑CPU运行的内核

如果你不懂或者没这方面的意识,相当于大脑直接宕机。但是,从你知道到刻意练习并且在工作中真正践行,可以慢慢从混乱中解放出来,与人沟通也会顺畅很多。

在职场上你应该看到过那种初次见面,便感觉到工作能力很强的人。

  • 听他发言,说话非常有条理。短期、中期和长期行动是什么;第一、第二、第三原因是什么;
  • 看他文档,目录层级清晰、各部分内容之间逻辑清晰,看他文档本身变成一种享受;
  • 听他给解决方案。有框架、有依据,直击问题要害。

这种感觉从哪里来的,依托于清晰的逻辑思维与结构化思维

让你可以快速获取到他人想要传达的信息,提高你接受信息愉悦度的,逻辑思维与结构化思维发挥了极大作用

在众多的思维方式中,我首选逻辑思维与结构化思维。其他的思维方式,如批判性思维、创造性思维等也很重要,更多影响你自己如何看待问题。

但逻辑思维和结构化思维核心影响你与他人的关系,影响信息传递效率,影响你的个人影响力,是非常显性化的两种思维方式,是其他思维方式的基础。显性化是你只要刻意练习,你便能习得这项能力,并且很快在工作中应用得到正反馈,提高你的工作效率、加强你的沟通表达能力。

思考和表达没有逻辑与结构,是种灾难核心不是让自己怎样,而是非常浪费别人的时间。大家的时间都很宝贵,你浪费了别人的时间,别人怎么还会有耐心信任你。尤其是对领导,你应该常常想几分钟内还没把事情讲清楚,他就没了耐心。同事之间沟通也如此,你讲了几分钟,对方还听不懂,那么他下次就不再想跟你沟通。

同样一件事情,能有逻辑地结构化思考和表达,可以节省双方更多时间,提高效率。逻辑与结构化思维可以让接受信息的人快速明白你要讲什么,也可以把你想表达的重点传递给到对方,它让我们在沟通交流中提高自身说服力。

职场人首要学习这两种思维方式,逻辑思维提高自身说服力,结构化思维提高信息传递效率。越早期越有这种意识,刻意培养自己,越能较早形成自己的核心竞争力。

如果你说你不知道自己核心竞争力是什么,那么刻意培养的逻辑思维与结构化思维也可以让你在一堆人中脱颖而出。

这些东西我写出来是我经历过那种职场混乱期,所思所悟皆为自己真实工作经历所得。思维方式听起来虽然高深,但是日复一日的复盘、反思、总结,刻意练习均可以习得,关键看你有没有觉醒,知行合一后发现是另外一片天空

本文内容如下:

图片


01  逻辑思维

在产品经理日常工作中,偶尔会发生与开发的争吵。开发怒气冲冲之下可能说:需求逻辑有问题。

抛开主观立场地说:绝大多数确实是产品经理自己没想清楚。开发之所以如此强调逻辑,是开发写代码需要真实一行行代码堆砌而成,缺一个环节代码无法跑通,需要逻辑一环扣一环。产品经理讲述听上去“非常完美”的方案,毕竟是理论,逻辑不严谨到了开发那里无法实现。

虽然逻辑思维是每个职场人必备素质,但是对于产品经理来说应该更佳,逻辑不严谨对于产品经理来讲是种致命的伤害。

逻辑不严谨最终导致功能上线后出现问题,是会真实产生损失的。比如做了新功能改动,但是没兼顾到旧数据,那么使用旧功能的用户可能就没法使用。

逻辑不严谨导致给出的解决方案没法真正解决问题,浪费资源不说,还错过了时间窗口。换句话说,功能做了个寂寞。有时候项目上线后看不到明显的转化,根本原因在一开始分析问题的思路就出错了,问题和解决方案之间没有形成逻辑闭环,你预想的“好”其实是错的。


image.png


在这个case 里可以发现业务想要做的行动跟原因并不匹配。假如真改了文案,退换货满意度就能提升到跟天猫京东一样了吗?如果事先不进行因果关系的纠正,没有想清楚匆忙投入开发,最终导致功能上线了实际问题也没得到解决。

在实际工作中此类问题数不胜数,此类问题皆是逻辑思维不缜密所致,你以为的解决方案不是问题产生真正的原因

什么是逻辑思维


百度百科:逻辑思维(Logical thinking),人们在认识事物的过程中借助于概念、判断、推理等思维形式能动地反映客观现实的理性认识过程,又称抽象思维。

它是作为对认识者的思维及其结构以及起作用的规律的分析而产生和发展起来的。只有经过逻辑思维,人们对事物的认识才能达到对具体对象本质规律的把握,进而认识客观世界。它是人的认识的高级阶段,即理性认识阶段。

这段话挺难懂的,换个白话文来讲。逻辑思维是建立在因果关系之上的反映客观现实的思维方式。在表达上的体现就是,说话有理有据,条理清晰。

逻辑思维强体现在被问及“为什么”的时候,你能够以所有人都能理解、并且具有说服力的方式,来清晰阐明得出结论的原因。或许可以说,让别人去接纳你所断定的结论,正是逻辑思维的职责所在。

逻辑思维十分讲究因果关系,你给出的每个结论,是确切的不是模棱两可的。你得到的每个结论,足够的理由经得起推敲。你给出的论据,是大家熟知的“常事”

提升逻辑思维

工作中大大小小的事情都需要做决策,回答一些问题,给出解决方案。当你尝试给出一个结论时,这个结论尽要符合逻辑。那么,如何去体现你的逻辑思维呢。

// 因果关联

因为(事实)—所以→结论1—所以→结论2……→决策(最终结论)。从最初结论一路倒推到最原始的“事实”,指现实情况和大众普遍接受的道理、原理、原则,这个点无法再产生任何质疑

image.png

世间万物都存在普遍联系,逻辑思维中最重要的就是找准结论与事实之间的因果联系。运用因果逻辑进行推理,一定不要仅停留在单一的因果层次上,必须从多个角度去研究事物发生的原因以及推出的结果。

比如,分析事物之间不同因果联系产生的不同结论。通常情况下,我们在进行因果关系推理时,必须重视因果分析,需要注意的有以下几方面:


① 有明确的结论产生

工作很忌讳给出模糊结论甚至不给结论,是就是,不是就不是,可以做就说可以做,不能做就说不能做。

但是不要回答:也许吧....先看看....不知道结论是什么。再或者出现了问题讲述了一大段原因,但是否产生影响或损失无结论,下一步有无行动也无结论。没有结论的表现就是别人听了你的阐述,像没有听一样,也不知道下步该什么。

讲因果关系时首要明确结论,且结论肯定不模糊。听到结论的人明确知道自己下步要做什么行动。明确得出下步不做什么也是一种结论。


② 分析产生问题的真正原因

有些情况下,原因可以分为很多层次,有些现象在表面上看来是引发结果的原因,但其实不然,因为在它们背后还存在着引发它们的原因。

对于拥有多个引发原因的结果,如果仅停留在某个单一层面上,将这一原因当作引发结果的最终因素,论点就会变得相对肤浅,并且很难将分析的问题理清楚,这样的因果逻辑推理得出的结果所拥有的说服力必然不大。

我们常说的第一性原理是讲此点,从头算起,只采用最基本的事实作为依据,然后再层层推导,得出结论。有经验虽好,但有时候人们由于惯性陷入经验主义,而忘记质疑自己“为什么一定是这样”?

用5W1H多问自己几个为什么。平时工作只知道自己在做什么,那就是What,这样当然是不够的,还要常问自己,再来一遍what(我做这的这个到底是什么?),why(为什么要做,为什么要这么做),how(怎么做比较好),why not(为什么不能那样做呢?)。如果你在尝试得出一个结论时,自己没先在内心先演练一遍,跟他人交流时,很容易受到挑战。

找不到产生问题的真正原因对产品经理来说,就是做需求\项目,等所有功能上线后做了个寂寞,看不到任何价值反馈,十分消耗个人信任度


③ 分析主要原因和次要原因

很多情况下,一种结果的引发原因可能有很多种,这时我们必须分清其中的主次原因,准确抓住主要原因,通过引起结果的最基本因素来进行逻辑推理。

分析主次原因才会懂真正的MVP。MVP高度训练你对问题做拆解的能力,锻炼把一件事儿做成的能力。什么是当下最主要的矛盾,最应该被解决的痛点是什么,为什么是先做A而不是先做B的逻辑依据。如果一个人一上来就要做大而全的解决方案或者想要走捷径去做很容易实现的次要原因,也容易被受到质疑。

MVP 核心用最少的资源去做最应该被解决的问题,前提条件可以拆分得出主次原因,优先解决主要原因的问题

// MECE 原则

因果关系强调纵向思考逻辑,一环扣一环,回答“为什么”,MECE原则强调横向思考逻辑,思考无遗漏。

MECE原则来自《金字塔原理》,指相互独立不重复,完全穷尽无遗漏。

  • 各部分之间相互独立(MutuallyExclusive),没有重叠,有排他性;

  • 所有部分完全穷尽(CollectivelyExhaustive),没有遗漏。

干一件事情之前,我们先把它可能涉及到的要素全部列出来,运用思维导图工具,一层一层剖析到底;将这些要素按相同的性质来进行整理归纳,划分层级,最终呈现在你眼前的思维导图架构就会清晰明了,所有可能触发的点一目了然。


① 时间顺序

时间顺序强调一定要在某个时间节点发生了什么事情对下个时间节点产生影响。有明确时间差的按照时间顺序思考。比如说,过去—现在—未来,阶段1—阶段2—阶段3。


② 流程顺序

按照事物发生的流程顺序思考,先有什么再有什么,什么数据的变动会导致另外一块数据变动,这样避免我们改动了某块功能而遗留另外一块的功能。比如用户在电商网站上下单支付,先后有订单系统和支付系统均要参与这个过程。


③ 结构顺序

做完某件事情一定要所有相关点都能实现,如果一个点遗漏,导致整体无法完成。比如某个支付方式在指定金额区间范围内有效。

小结

逻辑思维是所有思维方式的基础,核心在于如何思考。只有思考有逻辑,表达才会更有逻辑。在第2部分来讲述表达上的结构化思维。


02  结构化思维

  • 同样沟通事情,有的人三句话就能说清楚,而你可能说了10分钟也说不到核心;

  • 同样是做汇报,有的人用5页PPT就能说服对方,而你可能写了20多页还要被反问想表达什么;

  • 同样是阐述解决方案,有的人清晰讲出背景、问题、原因、影响和举措,而你挤牙膏式的回答一句紧接着再被问一句。

如果说一个人沟通表达能力差,情商是一个因素,但还有一个更关键点:结构化思维。如果对方听了半天都不知道你在表达什么,情商再高也失去色彩。

人类大脑在处理信息的时候,有两个规律:

第一,不能一次太多,太多信息会让我们的大脑觉得负荷过大;

第二,喜欢有规律的信息。

人的大脑最多仅记忆7个思想,当处理过多思想的时候需要建立逻辑关系,形成立体结构,完整、清晰地看到每一面和每个点。

表达能力强的人,不是比你更聪明,而是知道大脑这个特点,更懂得通过有效的结构化思维,快速对信息进行归纳和整理进行传递。

大脑容易记住有规律的东西,那么你在信息传递时尽量使用规律的东西来传递。把无序变得有规律的过程即结构化思维。

什么是结构化思维

结构化思维是一种从整体到局部、从框架到细节的思维方式。它要求思考者不先入为主,不会过快地陷入细节,而要经常留意事物的整体框架,在框架的基础上去拓展细节。

先看能够解决问题的关键方面,然后再往下分析,从而实现从总体到局部的鸟瞰,最典型的就是金字塔结构图。

图片

结构化思维渗透在工作的方方面面,是建立在逻辑思维之上的另一种显性化思维方式,不可或缺。结构化思维可以带来显著的工作效率提升,尤其是在沟通中。

为什么在沟通中结构化思维可以发挥巨大作用?

因为人和人之间信息差。结构的越上层,彼此之间信息差越小;结构的越下层,彼此之间信息差越大。如果一上来陷入到最下层的细节之中,对方大概率听不懂时沟通出现低效。

提升结构化思维

如果说逻辑思维一定程度上跟人天生智力水平有关,即我们常说的一个人聪不聪明,那么结构化思维则可以通过刻意训练习得。

结构化思维完全由自己从0到1主动规划所得,就如同有些人可以做出好看的PPT,其实也是懂得了PPT背后的套路。

提到结构化思维,不得不去看的《金字塔原理》一书,主要有4个原则:结论先行,以下统上,归类分组,逻辑递进。


图片

  • 论:结论先行。
  • 证:以上统下。
  • 类:归类分组。
  • 比:逻辑递进。

结构化思维有2种方法:自下向上组结构和自上向下套框架。

// 自下向上组结构

自下向上组结构核心在于这个结构是你自创的。根据你自己对接收到信息的理解,把信息重新组装的过程。比如我写这篇文章的框架结构,你日常整理会议纪要的结构。没有统一标准,你按照一定逻辑重新组合信息。

我的结构化思维正是通过写文章被训练很多年得到提升,到现在工作中有结构化思维已经成为我的个人标签。在我脑海里,日常对大量碎片化信息进行重组,把碎片化的东西像盖房子一样一层一层自下向上组装起来,等到溢出时一篇文章完成。

比如我给领导讲业务数据的PPT,首先会介绍我分析数据的整体框架,其次再给一个实际的数据分析的概览,再往下去细看每块的细分数据,针对每块的数据给出结论和TO DO。

  • 整体数据指标体系(理论)——一页PPT

  • 总体数据指标概览(实际数据)——一页PPT

  • 分模块1数据指标——一页PPT

  • 分模块2数据指标——一页PPT

  • 分模块3数据指标——一页PPT

  • 每页PPT里的结论和TO DO

  • 总结——一页PPT


先框架后细节,先总结后具体,先结论后原因,先观点后建议,先重要后次要。这样,才能让对方第一时间抓住重点信息,知道我们要传递的核心内容。

站在自己视角时,先把所有零散的点穷举,再看点与点之间的关联性连接成面,面最终再成体。概括起来大致分为以下4步:

  • 尽可能列出所有思考的要点

  • 找出关系,进行分类(找出要点间的逻辑关系,利用 MECE 原则归类分组)

  • 总结概括要点,提炼观点

  • 观点补充,完善思路

// 自上向下套框架

如果你是做已存领域的问题解决方案,那通过自上而下找结构:思考一个框架,然后将信息或解决方案放入框架。

比如,提到规划,可以使用五看三定框架;提到制定目标,可以使用SMART原则;提到制定任务计划,可以使用WBS任务拆解。

自上向下套框架依赖我们自身积累了多少种框架,在实际场景中可以随时被调用。

这里就给一些日常的积累。(如果大家需要完整版本的就加我微信获取)


一、学习能力

  • 学习金字塔

  • 费曼技巧

  • 刻意练习

  • RIA阅读法

  • 二八定律


二、思考能力

  • 黄金圈法则

  • 5W1H分析法

  • 思维导图

  • SWOT分析

  • 10/10/10法则

  • 冰山模型


三、创造能力

  • 六顶思考帽

  • 头脑风暴

  • 逆向思维

  • 类比思维

  • SCAMPER创新思维


四、设计能力

  • 设计思维

  • 最小可行性产品(MVP)

  • 峰终定律

  • AARRR漏斗模型

  • 上瘾(HOOK)模型


五、共情能力

  • 五大圈层模型

  • 高效倾听模型

  • 情绪ABC模型

  • 乔哈里视窗

  • 冰山模型


六、演讲能力

  • 故事五要素

  • SCQA模型

  • SRAR模型

  • STORY模型

  • “英雄之旅”模型


七、领导能力

  • 领导力梯队

  • 情景领导力模型

  • GROW教练模型

  • 管理4C模型

  • TOPIC模型


八、整合能力

  • 杠杆思维
  • POA行动
  • 系统思维
  • 整合思维模型
  • 多元思维模型

小结

结构化思维是一个建立清晰、稳定、有序的思考结构,学到这个结构之后,知识体系从零散化到系统化,从无序到有序,从低效到高效。

不断的进行归纳和总结,养成做任何事都进行阶段性总结和复盘的习惯是训练结构化思维的核心。思维如果懒惰任何种方法技能也无济于事。


结语

刚毕业时,因为不懂这最核心的2种思维模式,在工作上举步维艰。后来通过刻意练习提升这2项最核心的思维,找到工作的掌控感。

混沌大学创办人李善友教授说过:成年人学习的目的,应该是追求更好的思维模型,而不是更多的知识,在一个落后的思维模型里,即使增加更再多的信息量,也只是低水平的重复。

逻辑思维与结构化思维本身是专门的学科,并不是本文几千字就可以讲清楚,只是抛砖引玉提出观点建议大家刻意学习提升。一些行业内的通用书籍,如《金字塔原理》、《结构化思维》或《逻辑思维》值得反复阅读并且在日常工作中训练。

思维决定了你的认知水平和成长速度。工作上没有好的思维方式,再努力也是无效努力。思维方式需要主动意识到高价值然后刻意训练习得。愿我们都能拥有更好的思维模型,开启不一样的人生。

]]>
https://coffee.pmcaff.com/article/Oak7Nye3BJ https://coffee.pmcaff.com/article/Oak7Nye3BJ Wed, 07 Sep 2022 09:09:44 +0800
<![CDATA[ 1.5万字讲清楚从0到1搭建电商营销中心(建议收藏) ]]>

f6086938d89d166d51f975ee80bdfc27-picture

《电商产品经理从0到1》系列文章面向从事电商类、交易类产品方向并希望在该方向深耕的产品经理。

本系列文章将详细介绍电商核心系统的产品设计方案,帮助你体系化的认识电商产品。

本文章为《电商产品经理从0到1》系列第 三 篇:电商·营销中心

看完本文,你将对以下问题有所了解:

1. 什么是促销?

2. 促销的作用是什么?

3. 营销中心有哪些核心能力? 

4. 营销中心从0到1如何设计?

    4.1 促销工具

    4.2 促销叠加互斥规则

    4.3 促销命中规则

    4.4 实时价格计算

    4.5 优惠分摊计算

本文除了详细的功能设计说明外,同时也会解释设计背后的思考,非常适合新接触电商营销或者想要体系化掌握电商营销中心的产品同学们,看完本文,相信大家能掌握与营销相关的大部分功能模块的设计思路。

全文15000+字,阅读时间大约需要1.5小时,建议收藏和使用电脑阅读。。



前言

电商产品经理从0到1系列文章第一篇《一文读懂电商产品架构》整体介绍了电商的基本业务、系统流程以及产品架构,通过三张大图初步窥探了电商的基本面貌,了解了一个完整电商系统的核心组成,对电商有了概念层面的全局认知。

那么本文将带来《电商·营销中心》的具体设计思路和方案,深度解析一个大型电商平台的促销系统都有哪些核心模块以及促销系统是如何设计的。

4bf84cb20076ac6ac1c899654c7938de-picture

(图片过大无法正常显示,请用电脑放大查看)

本文将从促销的业务、促销的场景开始,先探讨分析电商为什么需要促销,促销的作用是什么,然后再深入的、体系的介绍电商营销中心各个模块的设计逻辑。


01 促销业务概述

1. 什么是促销?

促销是指卖方通过对消费者提供短期激励,以诱使其购买某种特定商品的过程

促销实质上是一种沟通活动,即营销者发出作为刺激消费的各种信息,包括营造出价格优惠、限时限量等氛围,把信息传递给一个或多个特定目标对象以影响其对商品的态度和行为。


2. 促销的作用是什么?

促销是运营工具,作用是帮助运营者完成其对用户的拉新、转化、促活、留存、传播的目的,完成对商品入市推广、销量提升、客单价提高、滞销库存清理的目的。

促销有别于常态化的销售,它有限时、限量、限消费群体以及优惠等特点。它是业务在运营过程中为了完成某种目标而使用的一种手段。

如业务冷启动阶段,平台通过促销来获取流量,新商品通过促销来快速打开市场。如激活阶段,通过促销来激活用户、提高客单价;如留存阶段,通过促销持续吸引用户购买使平台进入相对稳定的状态,或通过促销来清理尾货滞销库存;当业务进入稳定变现阶段后,通过有节奏的促销来稳定波动的流量和短期的GMV达成等目的。像京东、天猫这样非常成熟的平台也需要不断地通过促销来维持平台的活跃与转化。

稳定增长的流量和长期留存(电商中定义的留存≠登录)是衡量一块电商领域的业务是否健康的标准,而任何业务在达到健康的状态之前都会面临流量的短缺和留存的困难,即使业务进入相对健康的状态下,依旧会面临流量的波动或者留存的不可持续。因此促销就成了帮助业务进入稳定状态或持续处于稳定状态的有力工具。


3. 促销与营销的区别?

在专业概念上,营销有别于促销,营销是为了与消费者建立信任关系进而对企业自身、品牌以及产品进行长期的价值塑造的过程;而促销只是营销的一部分,主要是通过促销活动的方式向消费者提供短期激励促使消费者购买产品的过程;

但是在系统设计层面,营销在很多场合上都等于促销,营销中心只是一个系统命名,其实就是促销系统。当我们说促销或营销时更多的是在说促销活动(而市场部、企划部等专职营销的部门说营销时,就真的是营销了,比如地铁上投放企业广告之类的)。本文的目的主要也是介绍促销功能的设计方案而非科普专业术语,因此本文的营销和促销也都是表达同一个意思。


4. 促销形式与促销场景

电商的促销工具的种类非常多,不同的促销工具能做不同形式的促销活动,常见的有:特价促销、秒杀、满减、满赠、满折、优惠券等(具体分类见下面章节)。前面说过促销是帮助运营完成某种目的的工具,那是不是任意一种形式的促销工具都可以完成任意场景下的运营需求呢?其实不是,一种促销工具一定有它的作用边界。

那电商有哪些促销场景呢?我们可以分别从商品和用户的生命周期进行梳理并抽象:

4d388265ec9f0951c087c2278abc9042-picture

上图就是从商品和用户的生命周期进行拆解梳理的结果,不论是针对商品还是用户,在不同阶段都有不同的促销场景:

生命周期针对商品的促销场景针对用户的促销场景
引入期
新品推广用户拉新
成长期
销量提升转化购买
成熟期
客单价提升复购留存
衰退/流失期
清库存流失召回

那针对特定的促销场景,什么样的促销形式最适合、效果可能最好呢?例如最常见的用户拉新场景中,是选择做满减活动还是发优惠券?

大部分电商平台中,拉新最常见的方式就是发新人券(新人大礼包,包含多张面额不同优惠券),因为对于消费者而言,一张不限品类的低门槛优惠券带来的占便宜心理是最直接的,而满减活动则有凑单的心理认知,凑单意味着门槛,因此从心理上就不如优惠券简单直接。所以为了使促销效果最理想,不同的促销场景也需要不同的促销形式,我们按照场景简单梳理如下:

5145b1ec415d99e21125a45b34c65205-picture

上图是根据促销场景分析出的简单模型,目的是让大家对促销工具和运营之间的联系有一定的认知。从专业角度看,产品经理作为促销工具的设计者,需要知道不同的促销形式(策略)分别适合哪些促销场景,需要有相当程度的业务知识,避免在做产品设计时被需求方牵着鼻子走而成为一个简单的执行者。


02 营销中心概述

1. 营销中心的职责是什么?

营销中心是负责管理与营销活动有关的数据和能力的系统,其主要职责包括:

1. 负责创建和管理营销活动,包括平台活动和店铺活动

2. 负责对前台以及相关系统提供促销价格、促销信息、促销规则等促销能力


2. 营销中心有什么?

2.1 营销工具

大部分人最开始接触促销系统的时候,最先接触的可能是创建营销活动的后台,主要功能是创建营销活动,如创建单品直降、满减、满赠、秒杀、优惠券等活动,这部分功能我们称作营销工具,是营销中心最基础的部分。

6b1721f35df26f39639e2561b122ac1a-picture


2.2 规则中心

当我们上线了创建活动的功能以后,紧接着可能会面临一系列逻辑问题,比如:

Q1:某sku已经参加了一个直降活动,同时段下还能参加另一个直降活动吗?

Q2:某sku已经参加了一个直降活动,同时段下还能参加另一个满减活动吗?

Q3:某sku如果允许同时参加两个直降活动,那用户购买该sku时以哪个直降活动的价格购买?

Q4:某sku如果参加了8折的折扣活动,同时该sku针对学生用户打7.5折,此时一个带有学生标签的用户购买该商品时,到底是以8折价格购买还是以7.5折价格购买呢?如果该sku同时针对粉丝会员用户打7折、针对新人打6折呢?

Q5:如果一个sku允许同时参加秒杀活动、直降活动、满减活动,那用户购买该sku时,最终到手价到底是多少钱?

Q6:如果用户购买了5个不同的sku,而这5个不同的sku分别参加了3个不同的活动,而其中3个sku又用了一张现金券,那每个sku最终的实付金额又是多少呢?如果用户下单后申请其中2个sku退款,平台应该给用户退多少钱呢?

······

以上列举的关键问题引出营销中心的一类核心功能,这些功能没有界面,只是一个个底层服务,这些服务打包在一起,称之为规则中心,是营销中心最为核心的部分。

1ec42310ae3a27db6bcddedeb83b6721-picture

这些功能决定了sku能否同时参与多个活动,决定sku参加了多个活动时应该命中哪个活动,决定参加了多个活动时如何计算sku的实付金额。


2.3 内容管理系统

当我们解决了活动创建、解决了逻辑问题后,运营说要把同一个满减活动下的sku放到一个活动页中,方便用户选购。那活动页从哪来呢?是让研发同学临时开发吗?这里引出另一个非常核心的系统——内容管理系统,它可以通过搭积木的方式实现在线搭建任意样式、功能的页面。

dfc74f2e6620ccd1f6da83da05c5916b-picture


2.4 平台活动管理

如果你负责的是平台型的电商产品,而且平台体量比较大的话,那么发展到一定阶段后很可能会涉及到平台型活动,即由平台官方发起,商家自主报名的这类活动,如淘系的聚划算、天天特价,京东的秒杀、闪购等,这其中又会涉及到提报规则、竞价规则等一系列复杂的系统逻辑。

93736fb8c98954ef4e4155bf73686e3b-picture


2.5 审核与风控

当做完基础系统后,有一个很重要的问题就是风险控制问题,需避免一个sku降价力度过大或恶意套现等问题造成资损风险,因此我们要需要有促销审核功能以及风控系统。

44a26aac7093d9d292eb1bf3a9257696-picture


2.6 营销活动分析

当活动结束后,我们需要分析活动的效果如何,分析活动的投产比,因此需要有对应的数据分析的功能


2.7 对接上游系统

当我们成功创建了活动,解决了逻辑问题,实现了活动页面搭建功能,并且有相应的风控和数据分析功能以后,基本上就完成了营销中心80%的功能了,剩下需要解决问题还有从商品中心获取商品、从价格中心获取基础价格、从用户中心获得用户标签等,这些都是营销中心的上游系统。

54763023465d1e575d197215bb7126ff-picture


最后我们将这些系统或功能按照依赖关系进行组织一下,就能得到营销中心的系统架构图:

2c9b704a85eadcc6247670048105e320-picture

(图片过大无法正常显示,请用电脑放大查看)


营销中心各核心模块能力总结如下:

1. 营销工具:用于创建营销活动、管理营销活动

2. 规则中心:用于控制活动的叠加互斥、命中,提供促销价格计算,提供优惠计算规则等能力

3. 内容管理系统:用于在线搭建促销页面、频道页、公告,装修店铺等

4. 平台活动关系:用户创建、审核和管理平台类活动,平台类活动由提报系统管理

5. 促销审核与风控:用于控制、预警和管理活动风险

6. 营销分析:用于分析营销活动、活动的效果

7. 前台促销能力:提供促销价、促销标签、促销信息展示的能力


当我们知道营销中心有哪些核心模块以后,下面,我们就营销中心的几个核心模块的通用设计方案分别展开说明,详细的介绍每个模块应该如何设计。



03 营销工具设计(基础篇)

~~~如果对营销工具比较熟悉,本章节可跳过。~~~

1. 营销工具(活动)的分类

在促销业务概述中,我们了解到促销活动的本质是优惠,而优惠的形式有很多种,有的促销活动是在商品原价基础上直接降价,有的促销活动需要满足一定的门槛后再进行减免,不同的的促销形式满足的促销场景不同,带来的效果也不同。

不仅在业务层面有促销形式上的区别,在系统设计上也需要区分促销类型,在介绍营销工具的设计方案之前,我们有必要详细了解一下营销工具(促销活动)的分类,对于前端,不同类型的活动有不同的设计侧重,对于后端,规则中心有很多逻辑都与分类有关。

首先我们将营销工具分成两大类,一类是基础工具,一类是衍生类工具,我们主要是针对基础类工具进行分类,根据促销优惠形式的不同,我们将基础类工具分成如下几类:

  1. 单品类:指在商品原价基础上进行直接降价,如:一口价、直降、折扣、秒杀等

  2. 总价类:指在小计金额基础上进行减免,当一个或多个商品的小计金额满足优惠条件后,对小计金额进行减免,如满减、满折、满赠、加价购、套装等

  3. 抵扣类:指在订单应付金额基础上进行抵扣,如优惠券、余额、红包、积分等

  4. 满返类:指在订单实付金额基础上或基于策略进行返还优惠,如满返积分、满返优惠券等

eadf4d7ba8ef54fe52291faf4c14b51a-picture

其中秒杀活动虽然属于单品类活动,但是由于秒杀活动的特殊用户心智,在各大电商平台都处于首页焦点图位置,具有极强的引流效果,因此秒杀活动一般被设计成提报类活动,无法由商家自行创建,属于提报系统的职责。类似的还有淘系的淘抢购、天天特价、聚划算等。

而衍生类工具,如分享有礼、收藏有礼等只是基于基础工具衍生出来的玩法,比如分享有礼一般都是基于优惠券体系的一种裂变营销玩法,即A分享给B,AB都获得优惠券,本质上还是优惠券的一种发放方式,不影响前台设计和规则中心。

促销活动分类对于前台设计以及规则中心的影响请见后面章节。


2.营销工具的设计

营销工具的产品设计大同小异,可抽象成3个关键要素:

5af20597e462bd8601bc62cb377f1829-picture

1. 基本信息:活动名称、活动时间、活动地区、准入用户···
2. 活动商品 :商品池、活动限购、活动限售
3. 优惠规则:如满减活动的阶梯满减、重复满减

这3个关键要素也恰好体现在创建活动的3个步骤中,下面分别以单品类和总价类活动各举一个示例来介绍一下


2.1 单品直降活动

① 步骤一:设置基本信息

29abaf3bb6bf5dc4f09d618f7efdd5f7-picture

单品促销活动一般有多种优惠方式,常见的有一口价、直降、折扣:

  • 一口价指直接设置优惠后的促销价

  • 直降指基于平台原价设置直降力度,促销价=平台价-优惠力度

  • 折扣指基于平台原价设置折扣力度,促销价=平台价*折扣力度

在后台设计上,可以设计成在一个直降工具中,创建活动时可以选择三种不同优惠方式,也可以设计成三种独立的工具,每一种工具就是一种优惠方式。

推广平台指投放的渠道(即架构图中的渠道和终端),在大型电商平台中,由于其业余形态非常多元,因此会有很多不同的销售渠道,如京东除了主站外(京东APP+PC),还有极速版、1号店、微信端等;淘宝有手机淘宝、天猫、淘宝特价版等;不同的渠道有不同的消费群体,因此针对不同渠道有做不同形式或者不同力度活动的需求,甚至有时候在战略上有推广特定渠道的需求(如阿里在2011年提出all in无线战略时,很长一段时间内都采用了APP端价格低于PC端的策略),所以在营销工具中应支持活动定向渠道投放。

活动地区指控制特定地区的用户参与活动,一般采用行政地区,如果需要限制特殊地区用户参与(比如疫情区域用户),则可以结合电子围栏功能给圈定地区下的用户打标即可。

活动用户即准入用户,指允许参与活动的用户,此功能需要调用用户管理中的用户标签功能,如只允许“学生用户”享受活动,则在用户中心给属于学生的用户打上【学生标签】,然后在活动用户设置中选择【学生标签】即可。注意这里一般采用的白名单方式,即被添加了准入的用户可以参与活动。也可以设计黑名单逻辑,即被添加了黑名单的用户不可参与活动,若同时存在黑白名单,则需要定义黑白名单的优先级,具体设计方案根据自己的平台特性和业务需求判断即可。

限购用于控制单个用户的购买数量,设计上分最少购买量和最多购买量。限制最少购买量的目的是销售的更多(如针对滞销品清库存的场景);设置最多购买量的目的则一般是推广目的,为了获取更多流量需要让受众用户尽可能多,避免被同一个用户全部抢光;限购的力度也有多种,如按单笔订单限购(单个用户一笔订单限购xx件)、按活动限购(单个用户一场活动限购xx件),针对单个用户的口径也有不同的定义,如按照用户ID限购、按IP限购等。

活动库存即限售,限售的场景是避免亏本过多。当我们推广新品时或者用爆品引流时,一般会采用降价的方式,由于商品并不是直销库存,为了避免亏本过多,只能拿一部分库存出来做活动,则此时可以设置限售数量,抢完即止,售空后的设计逻辑一般有售空停止销售和售空恢复原价销售。

注:在设置限购限售量时,可以设计成在设置基本信息时填写,设置成功后批量应用到该活动下的所有商品中,也可以设计成在设置商品优惠规则时填写,同一个活动中不同的商品可以设置不同的限购限售数量。

活动宣传语一般是展示到商品详情页的标题下方,主要起到一种广告宣传效果。

在常见的三方后台中,创建单品促销活动第一步需要填写的基本信息差不多就是上图所示的内容了,像一些自营平台需要填写的信息则比三方后台要更复杂一些,比如需要填写费用承担部门、承担比例等。

② 步骤二:添加活动商品

e3de40b9a80dd9d6014472a40efecc01-picture

添加活动商品的方式一般有两种,在线选择和批量导入。

在线选择即在界面中点选商品,需定义可选择的商品范围(如售罄的是否需要漏出),如果是三方后台或者小型自营电商(SKU量级不多),也可以设计快捷选品的方式,如全部商品参与活动、部分商品不参与活动。

Excel批量导入即根据定义好的模板批量导入到系统中,模板中一般以skuID作为唯一主键,支持sku级别导入和spu级别导入。

③ 步骤二:设置优惠规则

730b342ec15e2cdbd75b13835c253313-picture

设置促销价时,需校验促销价必须低于平台价,特殊单品促销活动则需要设计更加严格的价格控制,如京东秒杀或者天猫聚划算提报活动时,活动价需要低于7/15/30天内最低价(为了延续特定活动在用户心中的低价心智)。

上图是常见的单品促销活动的创建流程,下面简单介绍一下总价类活动的设计。


2.2 总价类活动

总价类活动的创建流程与单品直降类活动基本一致,只有在第三步设置优惠规则时不一样,单品直降类活动的优惠规则是设置在单个商品的粒度上,而总价类活动的优惠规则则是设置在活动的粒度上的,以满减活动举例,优惠规则界面如下:

678a46e904c7507a5593c318c1528390-picture

  • 满金额:指活动商品的小计金额满足条件后可享受优惠;

  • 满数量:指活动商品的小计数量满足条件后可享受优惠;

  • 阶梯满减:指活动商品满足不同的阶梯条件时,享受对应的优惠;

  • 重复满减:指活动商品每满足条件一次,就享受一次优惠,如每满1000元,减10元,则当活动商品购满1000元时,减10元,购满2000元时,减20元,以此类推;

以上就是创建活动的功能设计说明,其他营销工具的设计大同小异,关键就是活动三要素:活动基本信息、活动商品、活动规则

营销工具属于营销产品领域中偏基础的部分,也是大部分人比较容易接触到的部分,即使是初学者,通过调研和分析一些主流电商后台的设计,也能比较快的掌握营销工具的设计关键点,进而也能很好的将需求有效落地。

而营销中最关键核心的部分属于底层那些看不到的规则,这些规则没有界面,没有后台,因此初学者想要调研分析也比较难以切入,下面就详细介绍营销中心的核心-规则中心。



04 营销-规则中心(核心篇)

1ec42310ae3a27db6bcddedeb83b6721-picture

规则中心由多个职责不同的、独立的服务组成,这些服务决定了sku能否同时参与多个活动,决定sku参加了多个活动时应该命中哪个活动,决定了sku在前台的促销价格,决定如何计算订单中每个sku的优惠分摊金额、实付金额。


1. 叠加互斥规则

叠加互斥规则的作用是什么?

1. 用于控制同一个sku能否同时参加多个活动 

2. 如果同一个sku参加了多个活动,用于控制购买该sku时可以叠加几个活动优惠

不同类型的活动,其叠加互斥规则不一样,我们根据营销活动的分类,分别简单分析一下:

1.1 单品类活动

单品类活动指在商品原价基础上进行降价,如秒杀、单品直降等。

可以想一想,一个sku如果同时参加了两个单品促销活动,意味着该sku有两个促销价,此时就存在逻辑矛盾了,比如秒杀价90元,特价80元,很显然用户购买这个商品时肯定只能以其中一个价格购买,不可能既享受90元秒杀价又享受80元特价。


因此单品类活动最终只能以其中一个活动生效,所以我们可以给出2种设计方案:

方案1:创建活动时校验一个sku只能参加一个单品直降活动

方案2:创建活动时不限制,即一个sku能同时参加多个单品直降活动,但是控制最终只能以其中一个活动生效,即单品活动与单品活动之间,生效时互斥

进一步分析两种方案的优劣会发现,方案1简单粗暴,虽然保证了逻辑自洽,但是却有很多局限性,比如两个单品活动面向的准入用户完全不同时,此时应该是允许同一个sku参加这两个活动的。因此主流的做法都是创建时允许参加多个活动,购买时互斥


1.2 总价类活动

总价类活动指在小计金额基础上进行减免,如满减、满折、满赠、加价购、套装等。

假如一个sku参加了两个总价类活动,比如活动A满1000-100,活动B满1000送购物袋,从逻辑上讲,理论上购买时是可以叠加的,比如用户购买1000元活动商品时,减100元的同时再赠送一个购物袋。

但是实际上主流的设计方案并没有采用叠加的方式,主要的原因是总价类活动主要满足的是“卖得更多的场景”,因此总价活动在前台体现在购物车环节,故而设计了活动分堆逻辑——即同一个活动下的商品在一个分组中(下图左),方便“凑单”。

15eecbbd32ada0fa6a09cc09779cddeb-picture

因此当同一个sku参加了两个不同的活动时,就会面临一个问题——这个sku应该被分到哪个分组中展示呢?有人说在两个分组中都展示这个sku(上图中),那加减数量的逻辑该怎么设计呢?加减上面的sku,下面sku数量不变吗?所以可见该方案会面临很多逻辑矛盾。

除了上述的前台设计原因外,还有更重要的优惠风险的考虑——即避免优惠力度过大,因此目前主流的设计都是采用互斥的逻辑——即同一个sku在购买时,只能以其中一个总价活动生效。

那这时候就有人会问:“用户购买1000元活动商品,享受减100元的同时再享受赠送一个购物袋”的场景如何满足呢?用过京东的人应该有印象,京东有一个促销活动叫“满减赠”,即满减的同时又赠送赠品,这样的话,对于活动分组而言,同一个sku就不用担心应该在哪个分组中的问题了(对于“京东有满减活动、满赠活动,为什么还要弄一个满减赠活动”的问题是不是就解惑了)。对于参加了多个不同总价活动的sku,用户购买时可以自行选择其中某个活动进行生效(上图右)。

因此我们给出结论:总价类活动,创建时允许参加多个活动,购买时互斥。


1.3、抵扣类活动

抵扣类活动指在订单应付金额基础上进行抵扣,如优惠券、余额、红包、积分等。在逻辑上,这类活动相互之间不存在叠加矛盾,只有运营控制的需要,因此如果没有特殊运营需求(如使用了红包就不能用优惠券),从系统逻辑上讲,抵扣类可设计成:创建时允许参加多个活动,购买时叠加。


1.4、满返类活动

指在订单实付金额基础上或基于策略进行返还优惠,如满返积分、满返优惠券等。满返类活动与抵扣类一样,在系统逻辑上没有叠加矛盾,也只有运营的需要。因此,满返类活动也可设计成:创建时允许参加多个活动,购买时叠加。


1.5、不同类型活动之间的叠加互斥规则

不同类型的活动之间,也不存在逻辑矛盾,如一个sku参加了特价9折促销,同时参加了满1000元-200元满减活动,并且该sku支持使用满500-10元的商品券,很显然这几个活动之间是可以同时享受的,因此不同类型的活动之间:创建时允许同一个sku参加多个不同类型的活动,购买时,多个不同类型的活动之间相互叠加。


各类活动之间的叠加互斥规则总结如下:

1.  单品类活动:创建时可参与多个单品类活动,购买时只能以其中一个生效 

2. 总价类活动:创建时可参与多个总价类活动,购买时只能以其中一个生效

3. 抵扣类活动:创建时可参与多个抵扣类活动,购买时相互叠加生效

4. 满返类活动:创建时可参与多个满返类活动,购买时相互叠加生效

5. 不同类型活动之间:创建时可参与不同类型的多个活动,购买时相互叠加生效

a83bf9f9bfa0b64809cac5394207fadc-picture


以上就是营销中心的第一个核心规则——叠加互斥规则的详细说明,核心在于规避逻辑上的矛盾,对于没有逻辑矛盾的活动,在设计上可叠加也可互斥,甚至可以增加开关控制,完全取决于平台或业务的特性,针对性的设计功能即可。


2.促销命中规则

2.1. 促销命中规则的作用是什么?

在上一小节叠加互斥规则的介绍中,我们知道一个sku存在同时参与了多个同类型和不同类型的活动的情况。叠加互斥规则控制着用户购买该sku时,是叠加生效还是互斥,不论是叠加生效还是只能以其中一个活动生效,那最终享受哪一个或哪几个活动呢?这个时候就需要通过命中规则来控制了,如果说叠加互斥规则决定能不能,那命中规则就决定了谁和谁。


2.2. 促销命中规则如何设计?

首先强调一点:促销命中规则的设计方案完全没有标准答案,纯粹取决于业务的需求,只需要根据业务确认好的逻辑进行设计即可。

与叠加互斥规则一样,不同类型的活动,其命中规则不一样,我们还是以不同类型的活动分别展开说明:

单品类活动:

1. 秒杀活动优先命中,无论价格高低,优先命中秒杀活动;

2. 多个秒杀活动按照价格从底到高排序,价格最低的优先命中;

3. 秒杀价格相同时,则按照创建时间排序,最新创建的活动优先命中;

4. 非秒杀活动按照价格从低到高排序,价格最低的优先命中;

5. 非秒杀活动价格相等时,按照活动创建时间排序,最新创建的活动优先命中;

秒杀活动之所以优先命中,是因为秒杀活动在很多平台中都是平台型活动,平台型活动要么有资源位,要么有平台加权引流,因此平台型活动意味着流量,因此需要优先命中。


总价类活动:

1. 按照活动类型定命中优先级:跨店铺类活动>满减类活动>满折活动>满赠活动>满减赠活动····(完全没有标准,可自行根据活动重要程度或者其他场景设计即可

2. 同一个类型下有多个活动时,按照创建时间排序,最新的活动优先命中。(如有两个满减活动,则根据这两个满减活动的创建时间确认命中顺序


抵扣类活动:

        因为抵扣类活动基本上完全叠加,因此可视为全部命中,其中优惠券的抵扣又有其特殊性,优惠券本身是一个庞大且独立的系统,优惠券又分不同的券类型,因此优惠券本身也存在命中的情况,如同一个sku被挂在了3张不同的优惠券上,并且用户恰好拥有这3张优惠券,当下单使用优惠券时,能使用几张券也有对应的规则,本文暂不展开券系统的设计说明。


其他设计说明:

        ①命中保持指sku命中了某个单品类活动后,如果这个sku的活动库存被抢光了或者超出限购数量了,sku要么不可购买要么恢复原价购买(取决于是否设置售罄库存和售罄后的购买规则),而不是再次计算命中其他单品类活动,只有当命中的活动失效(结束、下线)时,才会重新计算命中。

        ②sku命中与用户准入优先级sku121a2aasku12sku

以上就是命中规则的详细介绍,再次强调命中规则的设计方案没有标准答案,大家根据自身的业务特性确认规则即可。


3.实时价计算与双价格

影响价格的因素非常多,尤其是业务复杂的大型平台,如京东的价格体系中包含采购类价格、前台价格,其中采购类价格分进货价、采购价、仓报价,前台价格分原始京东价、划线价、前台京东价(红字价)等。

当价格体系非常复杂时,前台如何展示价格、用户以哪个价格购买就是很大的挑战,这个时候需要有一个服务来计算实时价格

本章节暂不讨论价格体系的设计,主要说明影响实时价的因素中与营销相关的部分,那么影响实时价格的因素中,与营销相关的主要就是单品促销活动了,前面已经介绍过各类单品促销价的生效规则,那么本章节主要介绍另一种单品价格-用户价


3.1.双价格-用户价

部分电商平台中,有一种较为少见的价格设计形态,即前台会展示两个售价(并非划线价),一个是正常的红字价(即单品优惠后的价格),另一个是其他高亮颜色的价格,当一个sku在前台同时出现两个价格时,也就是所谓的双价格设计了。

其中以其他颜色(非红字价)展示的价格其实是针对特定人群的促销价,即某一个商品在做促销活动时,针对普通用户设定一个促销价,针对特殊用户群设定另一个促销价。因此该价格也称为”用户价”。

如京东平台就经常出现两个价格的情况。在京东体系内,常见的用户价有:plus会员价、学生用户价、山姆会员价、粉丝价、新人专项价、令牌专属价等。该设计背后的逻辑也比较容易理解,即通过更好的服务(更便宜的价格)彰显这类群体的特殊身份,让其有被更好服务的体验,本质上是提升特殊群体的粘性,提供特殊群体对平台的认可度。

a24fd766acbe43181b24d46c62b65dc3-picture

图左(1/2)是plus会员价,图中(3/4)是sam会员价,图右(5/6)是粉丝价


3.2 双价格的设计逻辑

因为双价格的设计主要是为了凸显特定人群的尊贵,通过更优良的价格让其觉得获得了更好的体验,因此双价格中的用户价一定会比前台红字价更便宜,所以对于用户价的创建和前台展示就需要做最基础的价格控制:


用户价的创建控制:

以京东PLUS价格为例,PLUS促销价格的优惠幅度要比非plus促销价高xx%;


用户价的展示控制:

以京东PLUS价为例,PLUS价最低且自营优惠力度大于实时价的xx%,POP的优惠力度需大于实时价xx%时,商详页才会露出展示,否则商详不露出;

其他用户价一般需满足用户价最低且且用户身份符合时才会在前端展示;


当双价格相等时:

同一个sku同时设置了不同的用户价,且用户价相同时,展示规则可根据特殊用户的群体数量从少到多设置优先级,群体越小则特殊性越高越需要凸显重视程度,如京东的逻辑为:企业会员价>新人价> Plus价>山姆价>粉丝价>学生价>令牌价>店铺会员价。


以上说明仅是京东平台的一部分逻辑,可以看出这些逻辑主要是为了控制用户价低于平台价,且在低于平台价的策略上有一定比例的讲究(如果仅仅低于几毛钱,可能就达不到效果了)。需再次强调的是,以上逻辑并非标准或者通用设计,甚至大部分平台都没有这类设计,如果大家所在的平台有类似的场景或者需求,在设计自己的系统时,可以此作为一定程度上的参考。


4. 优惠计算服务

4.1 什么是优惠计算?

我们回顾一下章节2营销中心概述中提的最后两个问题:

Q5:如果一个sku允许同时参加秒杀活动、直降活动、满减活动,那用户购买该sku时,最终到手价到底是多少钱?

Q6:如果用户购买了5个不同的sku,这5个不同的sku分别参加了3个不同的活动,而其中3个sku又用了一张现金券,那每个sku最终的实付金额又是多少呢?如果用户最后申请其中2个sku退款,平台应该给用户退多少钱呢?


通过以上两个问题我们大概能知道优惠计算服务是干什么的了?——即通过计算订单中每个sku的优惠金额,进而计算该sku成单后的最终应付金额,有了实付金额,那我们发生售后退款时就能知道退多少钱了。


所以,优惠计算服务的基本职责可概括为:

1. 计算订单中每一个sku所分摊的每一种促销活动的优惠金额; 

2. 计算订单中每一个sku的实际支付金额; 

3. 计算订单的应付金额

每个商品的优惠分摊金额计算并记录下来以后,我们就可以给到经分去计算每个商品的费用、每个品类的费用,进而能计算出各种口径的利润。而且优惠计算服务的作用远不仅应用于以上场景,当每个sku的每种促销活动的优惠力度可以计算出来后,还可以应用于成单前的很多地方,如在商详页、购物车或其他黄金流程中,系统可调用该服务计算出所有的优惠,进而在前台展示该商品的“预估到手价”,这对于刺激用户购买也有很大的作用。

9276b91db75d4a5584f8d62871d42fbf-picture

如右图,勾选了两件商品后,系统马上计算出这两件商品的预估到手价,实现的原理就是系统根据这两件商品所命中的活动,包括叠加可用的优惠券,计算出最优活动组合,从而根据优惠计算服务计算出每个单品的最终应付金额。


4.2 优惠计算顺序

我们在营销工具的分类章节中介绍过,促销活动可分为单品促销、总价促销、抵扣类、满返类,不同类型的促销在交易流程中体现在不同的环节:

1. 单品促销体现在单个sku上,为最优先体现的促销类型;

2. 其次是总价促销,需要多个商品或多个数量满足条件,一般体现在购物车;

3. 抵扣类一般体现在结算页;

4. 满返类则体现在订单成单后;

当同一个商品参加了以上所有类型的促销时,其享受促销优惠的顺序就是以上顺序,因此我们按照以上顺序作为不同类型促销活动的计算顺序,即:

330a9bf383a8d64e060b7025f5d48f61-picture

也就是说当一个商品参加了所有类型的促销活动时,我们:

  1. 先计算该商品的单品优惠金额

  2. 再计算该商品的总价优惠金额

  3. 然后计算该商品的抵扣优惠金额

  4. 最后计算该商品的满返优惠金额


4.3 递进式与平行式门槛

电商发展至今,主流的优惠门槛计算方案有两种,一种是递进式计算,另一种是平行式计算。


递进式计算规则:

根据优惠计算顺序计算每一层级的优惠金额时,以上一级优惠后的金额来判断是否满足下一级的优惠门槛。


平行式计算规则:

即每一层级的优惠都根据该sku的单品基准价来判断是否符合门槛(单品基准价是指单品优惠后的价格,一般为前台红字价)。


用一个例子说明:

一件商品原价3000元,现参加活动如下:

  • 活动1:8折单品优惠活动

  • 活动2:总价满2000-500元的满减活动

  • 活动3:优惠券1满2000-500元,券2满1500-100元,两券可叠加

  • 活动4:用户账户有可用余额400元

现在用两种优惠计算规则分别计算该商品的最终实付价:

bfab3b5a4a5528aa63732da30cb2bc17-picture


可看出两种计算规则的结果不一样,平行计算规则下的实付金额小于递进式,逻辑更简单。早期各个平台都是递进式的计算规则,随着各平台活动越来越丰富,活动规则越来越复杂,各种活动叠加之后,用户最终已经不知道是否真的占了便宜,为了用户体验使逻辑简化,在2018~2019年期间,淘宝京东相继将优惠计算规则从递进式改为了平行式。相对的,在平行计算规则下,优惠力度会更大,对于商家而言更容易出现资损风险,因此对风控的要求也更高。


4.4 优惠分摊的计算逻辑

这一小章节非常重要,如果分摊计算的逻辑不设计好,极有可能出现商品分摊的优惠金额过大或者摊负的情况,也可能导致单个数量的实付金额与总计对不上的情况等等。

下面介绍一种方案:

1. 按照优惠计算顺序(单总券返)计算所有sku在每一层级的活动中所分摊的优惠;

2. 优先计算基准金额最小的sku,然后按基准金额从小到大逐个计算;

3. 以上一层级优惠后的金额作为下一层级计算权重的分子,第一层级计算权重的基准金额是商品的单品优惠金额,第二层级计算权重的分子是第一层级优惠后的金额,第三层级计算权重的分子是第二层级优惠后的金额,依次类推;

4. 用每个sku的基准金额(有多个数量则以基准金额之和)÷ 该sku命中的活动所适用的所有sku的基准金额之和*该活动的优惠总额;

5. 同一个活动中,最后一个sku的优惠金额=优惠总额 - 其他sku优惠之和

6. 计算过程四舍五入保留6位小数精度,最终需展示的结果四舍五入保留2位小数;


针对以上方案的解释说明:

1、第2点中,当订单中有多个sku时,为什么要按基准金额从小到大的顺序依次计算?——因为如果从大到小计算,当有一个sku的金额过大时,则其权重也过大,在四舍五入的情况下,则有可能将优惠全分摊完了。


2、第3点中,为什么要以类递进式的方式计算权重?——因为如果不按递进式的方式计算金额(与平行计算门槛不冲突),则可能出现摊负的情况,举例说明:

有A、B两个商品,A商品原价3000元,B商品原价100元  

其中A商品参加了直降活动,直降1000元

其中B商品参加了满100-50的满减活动 

用户账户内有一张全品类无门槛优惠券,面值1500元   


假如这个用户购买了A、B两个商品

①如果直接以基准价作为分子计算权重,则结果就会出现摊负的情况:

  • A商品的基准金额=3000-1000=2000元

  • B商品满减优惠=100-50=50元

  • B商品优惠券优惠=100/(2000+100)*1500≈71.43元

  • B的实付金额:100-50-71.43 = -21.43元(此时应付金额为负)


②如果按第三步的逻辑计算权重,则结果如下:

  • A商品的基准金额=3000-1000=2000元

  • B商品满减优惠=100-50=50元

  • B商品优惠券优惠=(100-50)/(2000+50)*1500≈36.58元

  • B的实付金额:100-50-36.58 = 13.42元(此时应付金额为正)


3、第5点,最后一个sku的优惠金额=优惠总额 - 其他sku优惠之和,这是的原因是为了所有使sku分摊到的优惠金额相加等于总优惠,因为在计算过程中如果出现除不尽的情况,加上四舍五入就会出现每个sku分摊的优惠相加小于或大于优惠总金额的情况。

以上就是优惠分摊计算的方案说明,同样的,这个方案也不是标准的、唯一的方案,不论采用什么方案,核心就是不要让金额计算出现摊负、或者对不上的错误结果。


小结:

规则中心就像十字路口的红绿灯和交通管理员,当车辆从四面八方汇集到十字路口时,规则中心就会启动交通管制,指挥所有的车辆按照正确的道路行驶。

规则中心的核心服务包括:叠加互斥规则、命中规则、实时价格计算、优惠分摊计算。这一章节所述的产品一般没有界面或者只有很少的界面,更多的是后端逻辑和策略,对于初学者而言可能需要一定的相关产品设计经验才能比较容易掌握。我们只记住一点,对于偏逻辑的后端产品,产品设计的核心要点是逻辑自洽且符合业务场景,没有实验,主观体验设计少,因此只需要多花一点时间就能摸透。这一章节的内容不仅适用于电商,对于交易类型的产品都会遇到相关的问题,如果大家碰到类似的产品,可以参考一下。


05  其他系统

CMS、前台、平台活动管理、审核与风控、数据分析


5.1 CMS系统

CMS系统(content management system)即内容管理系统,在不同的领域其产品形态不一样,在电商产品领域,cms核心用于创建和管理活动页面、频道页面、店铺装修等,使用过淘宝后台的同学应该见过店铺装修功能:

124f3f1cb6aba3f580b0d28de12bc413-picture

主要的能力就是将页面中常见的功能组件化(类似搭积木),通过拖拽的方式组合成一个完整的页面。京东平台的系统叫通天塔,功能也类似。因为cms系统本身是一个非常庞大的系统,通过一小章节无法讲明白,同时cms相对于营销知识体系较为独立,因此本文不做介绍,后续会单独出一篇文章介绍CMS。


5.2 促销在前台的设计

本文只简单探讨一下电商前台有关促销的设计思想,因为知道why比知道how更重要。我们看一下主流电商平台的交易动线中都有哪些与促销相关的设计元素,看看是否可以从中找寻一些共性,基于这些共性,我们再去分析背后的设计思想。


如京东APP在黄金流程中的促销元素:

9f6674be2f3d07900aa45502ed5a3896-picture

(图片过大无法正常显示,请用电脑放大查看)

可以看到,京东黄金流程中不同的环节体现的促销元素的重心不一样,如商详页主要体现出单品的价格,用红字高亮并且价格区域有很重的氛围设计,这是在明示用户该商品目前在降价。在购物车中,价格的设计就不再是第一位了,因为购物车是展示的多个意向购买商品,这里就不能再强调单品的价值了,而要引导用户“多买“,因此在购物车环节需要加强总价类活动的设计,可以看到大部分电商平台在购物车中都会着重针对凑单进行设计。提单环节需要加强转化,减少“后悔”,因此提单环节就是使用券、积分、余额等各类虚拟币的环节,这里要方便用户直观的知道我有什么券可以用,我可用省多少钱。最后成单后,为了让用户下次再来,我们需要可以告诉用户订单完成后将获得什么奖品,让用户对平台有一个念想。


小结:

这些与营销相关的系统本文暂不做重点介绍,我们只需要知道营销体系中,除了几大核心系统外,还有一些很重要的系统都与营销相关,对于这些系统的设计,后面会单独出文章专门介绍。


06  总结

以上就是营销中心的主要内容了,再回头看看文章开始提的几个问题:

  1. 什么是促销?促销的作用是什么?

  2. 不同的促销形式适用的场景分别是怎样的?

  3. 营销中心有哪些核心能力和模块? 

  4. 如果让你从0到1搭建营销中心,你知道怎么设计吗?

相信大部分认真研读了文章的同学都有自己的答案了,在此一起总结一下:


1. 什么是促销?促销的作用是什么?

  • 促销是指卖方通过对消费者提供短期激励,以诱使其购买某种特定商品的过程。

  • 促销是运营工具,作用是帮助运营者完成其对用户的拉新、转化、促活、留存、传播的目的,完成对商品入市推广、销量提升、客单价提高、滞销库存清理的目的。


2.常见的促销场景有哪些?适合使用哪些促销工具?

  • 从用户的角度看,有:拉新、转化、复购、召回

  • 从商品的角度看,有:新品推广、销量提升、提高客单价、清库存

  • 不同的场景需要针对性的使用不同的促销策略,如多买优惠对提高客单价很有效

3.营销中心有哪些核心模块?如何设计?

我们通过一张全景图来回顾:

1047abfb097d14c0d8d5f1cb3765f85e-picture


最后,还是再强调一下,上述所有有关具体模块的设计方案都不是标准答案,只是在特定历史背景下被验证过可行性。电商发展到现在,形态越来越多样,比如出现了拼多多的无购物车设计、短视频平台的内容电商等,新的业务模式有新的产品形态,新的产品形态也有新的营销玩法和设计逻辑,因此我们的设计思路也应该是发展的、与时俱进的。


如果大家对于拼团模式、新兴的直播电商模式也比较感兴趣,后续可以单独另起文章针对团购或者短视频为主的内容电商做一些分享。


这篇文章大体上涵盖了电商营销系统80%的知识体系,断断续续花了几个周末的时间才写完,写作不易,如果文章对你有启发和帮助,可以收藏点个赞哦~~~8b3547ecb81305b0ce7e8b0793c13242-picture8b3547ecb81305b0ce7e8b0793c13242-picture8b3547ecb81305b0ce7e8b0793c13242-picture



本文由道格森咸鱼王原创发布于PMCAFF,转载请联系作者获得许可,并注明来源。

欢迎关注公众号: @道格森咸鱼王 

]]>
https://coffee.pmcaff.com/article/G2Qdo2ngLZ https://coffee.pmcaff.com/article/G2Qdo2ngLZ Sun, 29 May 2022 19:23:46 +0800
<![CDATA[ 1.5万字深度雄文:这才是实际工作中的竞品分析 ]]>

早上我给产品助理布置了一个任务:跟踪我们的竞品XXX,特别关注XXX功能有没有什么更新,然后写一份分析报告。到了下午,我就看到他在看“艾瑞咨询”,时不时截图粘贴到word里。

不知道从什么时候开始,“先分析市场和用户,再通过用户体验五要素逐层分解,最后总结”成了分析产品的标准格式。你会发现洋洋洒洒几千字中有关产品的各个方面都提到了,但通读下来又感觉没有实质性的收获,这就是这种模板文章的通病——大而全只会浮于表面,在实际工作中也不会这样去分析。而且对于市场和用户的分析,是需要靠实际去调研,靠数据去支撑的,直接摘取行业报告或第三方提供的数据是毫无意义的。

本文是根据笔者多年实际工作经验总结而成的竞品分析方法论,希望能够纠正产品新人对竞品分析的错误认知并且能够为其提供思路指导。全文包括以下六部分内容:

image.png

一、概述

image.png

1、什么是竞品

关于竞品有一个非常广泛地定义,即所有值得参照借鉴的产品都是竞品。比如我们要做线上考试系统,除了选择市面上已有的考试软件,还需要参考试卷、自助阅卷机、金属探测仪、信号屏蔽器等考试相关的产品。所以,竞品不是简单地选择几样相同或类似功能的产品,而是需要透过功能找到用户的本质需求。凡是能满足这类需求的所有产品、实物、服务等,都属于竞品的范畴,需要产品经理进行分析和参考。

2、竞品分析的作用

无论我们处于哪个行业,都要了解一下目前行业内是不是已有类似的产品了,如果有,其现状如何?哪些值得借鉴,哪些需要规避?通过分析,我们可以借鉴成功经验,少走弯路。

对产品来说,竞品分析有助于:

· 通过了解竞争对手的产品和市场动态,为制定产品战略、布局规划提供参考依据

· 通过竞品取长补短,有助于帮助自身产品实现反超


对产品经理来说,竞品分析有助于:

· 对于不熟悉的领域,通过研究竞品的设计方案为我们提供思路指导

· 对于无所措手足的方案,通过研究竞品选择最优策略

· 久而久之能够提高产品规划设计能力,培养产品感

3、竞品分析的一般流程

一般来说,竞品分析的流程包括:

· 竞品收集与选择

· 竞品体验与拆解

· 竞品分析

· 总结报告

竞品分析贯穿产品始终,根据不同的分析目的,拆解和分析过程又可整合为初步竞品分析(细化至功能)和详细竞品分析(细化至逻辑),详见第三四部分内容。虽然文中用了大量的篇幅介绍初步竞品分析,但实际上,详细竞品分析才是产品经理的工作日常。

 

初步竞品分析

☆详细竞品分析

目的

了解竞品动态

了解功能逻辑

场景

1、规划产品战略

2、借鉴功能迭代

3、分析收费方式

1、设计产品功能

2、设计技术方案

 接下来,我会对竞品分析各环节逐一进行详细地讲解。

二、竞品收集与选择

image.png

竞品收集指的是通过各种方法获得可以借鉴的产品及产品信息,该过程包括三个步骤:

· 建立竞品选择框架:通过用户场景方格”对竞品进行分组

· 竞品搜集:通过四种方式获得更多可借鉴的竞品

· 竞品选择:根据不同目的建立竞品选择的维度

· 竞品信息获取:通过各种渠道获取竞品信息

1、建立竞品选择框架

首先我们要树立两个跟竞品相关的正确认知:

· 用户需求是用户和场景结合的产物

· 满足用户需求的所有产品、实物、服务等都是竞品


据此,我总结出了用户场景方格这一框架模型,用来对竞品进行分组,并制定分析策略。

a. 什么是用户场景方格

”用户“和“场景”为维度建立二维矩阵,坐标轴的远近代表重合度的高低,因此可以把矩阵划分为四个方格:

· A核心竞品:竞品的目标用户和使用场景与自身产品高度重合,需要重点关注

· B同类竞品:竞品的使用场景与自身产品高度重合,但目标用户有区别

· C相似竞品:竞品的目标用户与自身产品一致,但使用场景稍有区别

· D参考竞品:竞品的目标用户和用户场景与自身产品重合度较低,可以作为设计参考

image.png

 

PS:”同类竞品“和”相似竞品“仅通过命名不易区分,主要是暂时没想到更好地词语进行描述,读者理解其意即可。

 

b. 怎么使用用户场景方格

前面说了竞品可以是产品、实物或服务,在搜集完竞品后,我们将其放置于对应的方格中,并根据产品形态进行归类,如产品、实物or服务,这样就可以得到一个全面的竞品分布画布以针对大学生的常态化线上考试系统为例,简化的竞品分布如下图所示:

image.png

 

有了这张竞品画布,相当于在战场上有了各敌对势力的兵力分布,即可用于规划战略方向,又可为制定战术计划提供依据。

2、竞品搜集

怎样能够保证画布中不同形式的竞品能被我们全面得搜集到呢?结合以往的工作经验,我总结了以下方法:

a. 通过第三方渠道寻找竞品

· 软件市场:包括APP和PC端应用市场,如Google play、AppStore、小米应用商店、华为应用商店、华军软件园、软件管家等

· 专业网站:聚合优质信息与人群的新媒体平台,如虎嗅、36Kr、芥末堆、果壳网、最美应用、GitHub等

· 行业调查报告:能提供行业数据、行业研究的网站,比如百度数据、七麦数据、艾瑞网等

· 主流搜索引擎:如百度、Google、360搜索等

 

b. 通过用户访谈寻找竞品

如果我们能够接触到用户,可以利用用户访谈的机会向他们了解遇到的问题以及通过什么样的方式或产品解决这些问题的,通过该方式普遍能够快速准确地找到核心竞品。还是以大学生常态化线上考试平台为例,我在跟学校老师沟通时,他们就直接道出了以前接触到的考试软件,并且依次指出了它们的问题,以及期望的需求。

c. 通过分解思维寻找竞品

这种方法指的是先分解业务流程,再以每个分解的结果为原点寻找相关的竞品。如线上考试平台按业务流程大致可分解为”组卷-排考-线上考试-阅卷-成绩公布“五个环节,可以分别对每个环节寻找竞品:

image.png

这种方式的好处是扩大了竞品的选择范围,增加了找到可参考竞品的几率。

d. 通过发散思维寻找竞品

· 发散产品形态:很多时候我们会将竞品限制为一个软件,但实际上任何有借鉴价值的对象(产品、实物、服务等)都应该作为竞品,因此从该维度发散是刻意地帮助我们打破惯性思维,站在更高的视角审视各个形态的竞品

· 发散使用场景:通过扩大用户的使用场景让我们得到不同方向的设计启发,如从”常态化考试场景“发散到”四六级考试、公务员考试、研究生考试“等,从而寻找到更多可借鉴的产品

· 发散目标用户:通过扩大目标用户让我们得到不同方向的设计启发,如从”大学生“发散到”小学生、高中生、职场人士“等

· 发散其他行业:通过寻找其他行业优秀的解决方案,也能够有效地拓展竞品范围,如可以参考驾考行业中身份认证、在线作答、自动批改、成绩公布、补考等一系列成熟的考试方案

 

最后对竞品搜集的常用思路和方法做一个汇总,如下图:

image.png

 

PS:别忘了将搜集到的所有竞品填入竞品选择框架(用户场景方格)中。

3、竞品选择

一般来说,搜集到的竞品都需要产品经理进行了解,但毕竟人的时间和精力有限,我们只能选择部分竞品来深入研究,但是要遵循四个基本原则:

· 所选择的竞品需要涵盖ABCD四类

· 所选择的A类竞品需要涵盖所有形态(产品、服务、实物等)

· 所选择的竞品需要有代表性,在该类中处于领先地位

· 在可能的情况下选择得越多越好

 

除了上述原则,还要根据不同的分析目的,从不同维度挑选排名较前的竞品(为了便于举例,下文专指互联网产品):

a. 目的:了解竞品动态,为战略规划提供决策依据(初步竞品分析)

该目的下,重点关注竞品的发展方向,要挑选行业头部产品进行分析和学习:

· 市场份额:选择市场占有率高的产品,如要研究社交领域,微信是绕不过去的竞品

· 公司背景:有很多后来居上的产品,如当年的百团大战,对商家的扶持、对客户的补贴,都是靠着资本的驱动才能够完成的

· 市场口碑:不一定要选择用户口碑好的产品,竞品口碑不好的点恰恰是我们的机会点,如钉钉和飞书

· 热门程度:如果某个竞品在某段时间突然热度大增,也需要单独拿来研究

除了关注同行业,还要警惕其他行业的竞争者,有句话说得好干掉你的不是同行,而是跨界“,这样的例子在如今的商业环境中比比皆是,小米挑战晨光中性笔,外卖挑战速食方便面、智能手机挑战单反相机、中国邮政挑战星巴克……我们不仅要居安思危,不断提高产品核心竞争力,还要在在危机中育新机,于变局中开新局。

 

b. 目的:了解功能逻辑,为方案设计提供详细参考(详细竞品分析)

除了初步分析需要考虑的四个维度,此目的下还要从功能维度进行筛选:

· 功能匹配度:选择功能匹配度高的竞品。注意不是功能越多越好,而是和我们所需的功能越匹配越好。比如要设计”随机组卷“功能,就要有目的地选择有该功能的竞品

· 功能亮点:是否有特色的功能。如果竞品的功能都千篇一律,那么选择其一即可

4、竞品信息获取

选择好要深入研究的竞品后,接下来就是全面收集有关该竞品的所有信息。

 

理想情况下,可以向公司内同类业务的产品经理请教,获取他们已有的竞品资料。对于大型企业,还会设立专门分析市场情况的部门,比如我的上家公司设立了一个”情报分析部“,需要什么竞品可以直接找该部门申请相关资料,相应地如果遇到了新的值得借鉴的产品,也可以向该部门提出研究需求。

但是大多数情况下,竞品信息获取工作都得靠产品经理自己完成。下文提供我在工作中常用的几种B端产品收集信息的方法,C端产品也同样适用:

a. 寻找官方出品的信息

通过竞品官网、发布会、宣传会、销售材料、QQ群等官方渠道获取信息。这种方式的好处是信息较权威,但要注意甄别水分,很多B端产品为了吸引客户,会包装概念(其实是新瓶装旧酒),或者是虚假宣传(其实还没实现)。

b. 从第三方渠道获取信息

与竞品搜集的方式类似,可以从专业网站、行业调查网站和搜索引擎中进行搜索。另外也可以从竞品的合作客户入手,比如有些企业会将竞品的使用手册、宣传视频等信息发布在公众号内,吸引有关人员查看学习,也有些用户会将竞品信息分享到抖音、小红书等社交平台。

image.png

 

c. 注册/申请试用

有些产品开放注册,可以方便地进行体验。但大多数B端产品都需要申请试用,这时可以伪装成潜在客户与其销售人员沟通,套取一些基本信息,最终目的是能够要到体验账号。当然了,在沟通前一定要做好准备,包括伪装企业的资料及背景、沟通话术等(做好对竞品销售人员的用户研究),要让对方销售相信你是确实遇到问题了,且正在寻找能够解决问题的人。现在销售人员的防范心理都很强,特别是行业头部企业,都会在这方面对售前人员做专门的培训。

PS:关于申请试用竞品的经验,可查看我的另一篇文章《产品经理“骗”取竞品资料的18个套路


d. 向合作客户了解

销售/市场等一线人员在跟客户沟通时往往会获取到竞品的信息,比如客户经常会说”XXX产品有这个功能,你们有吗“,如果是有经验的一线人员会顺着这个问题深入询问”您能详细描述一下这个功能吗,在什么情况下会用到,我好找我们产品中类似的功能给您介绍“,这样一来一回就能摸清个大概。

如果有关系较好的合作客户,也可以利用销售与其的关系拿到竞品资料(因为B端客户不可能只接触一家服务商),甚至可以利用合作客户的身份直接联系竞品获取资料(事后别忘了表示感谢),不过这种方式过于依赖一线人员,属于没有办法中的办法。

image.png

 

至此,我们就完成了竞品的收集与选择,再次总结一下我们的输出:

· 一个全面的竞品分布画布

· 根据分析目的从各方格中挑选出的几个有价值的竞品

· 通过各种方式获取竞品的详细资料

我们永远也不可能将竞品的信息收集全面,但要学会在信息不完整的情况下做出分析。

三、初步竞品分析

image.png

定义:初步竞品分析是对竞品的前情和现状进行研究后做的宏观性分析

目的:了解竞品动态,预测其发展趋势

好处:有利于我们制定有竞争优势的战略计划和产品架构

场景:产品规划

核心研究今天、了解昨天并预测明天


初步竞品分析需要衡量以下方面:

· 产品定位:通过分析竞品的定位,从中找出差异化的竞争机会

· 收费方式:分析竞品靠哪些方式赚钱,有没有值得参考的地方

· 产品架构:逆推竞品的业务流程和产品结构,同时预测变化趋势

· 用户体验:借鉴能提高用户主观感受的设计方式

· 产品功能:做到人无我有,人有我优

image.png

 

1、产品功能

a. 研究今天

最直接有效的方法就是对现有竞品进行功能拆解,即在体验竞品的过程中记录功能列表。下方是一份功能列表的模板,可先按照不同的系统、菜单模块进行区分,再依次罗列所有的功能,期间如果有需要留意的地方,可以将其填到备注中。

image.png

一份完整的功能列表,可以帮助我们了解到功能全貌,最重要的是通过这一过程,我们一定能发现竞品的缺陷或亮点

如果没法体验到竞品,可以通过使用手册、操作视频等资料倒推产品功能。这也是产品经理需要掌握的基础技能之一——看到一个前端功能就能联想到背后一系列的系统支撑。比如一个交易订单的生成是靠商品系统、库存系统、营销系统、风控系统、支付系统等协同完成;一份成绩报告的背后有着组卷系统、阅卷系统、数据服务、考生系统等共同支撑。

其次还需要留意以下两点:

· 基于初步竞品分析的目的,我们只需全面地记录功能即可,不必深究功能背后的规则

· 注意记录功能列表对应的竞品版本,以便后期进行对比

 

b. 了解昨天

功能列表是竞品的”果“,我们还要探究是什么样的”因“造就了这样的果,即了解竞品的历史迭代记录,试图找到一些发展规律。

如果竞品有App的话,可以直接在“七麦数据”中搜索,十分方便。

image.png

 

但如果是B端竞品,还没有一个渠道能汇总历史版本,只能靠产品经理自己记录。而且只有少部分产品会在更新时发布更新内容提示,大部分都没有,这就又增加了难度。面对这种情况,只能尝试从其他资料找到一些蛛丝马迹,如官网的发展历程、用户使用手册的变更、QQ群中的官方消息等。

image.png

假设我们现在已经拿到了竞品的历史迭代信息,接下来就要利用时间轴进行梳理。绘制时间轴的形式不限,可以是excel也可以是图例(建议采用excel,便于后续数据分析),但都需要包含版本、更新时间、更新内容(如果是无意义的更新内容可省去,如修复已知问题,优化体验)。

image.png

 

可别小看了这个迭代记录,我们能够通过它获取很多有用的信息:

 

1)纵向分析:

可以对比同一竞品历年的发版次数、同一模块下功能的更新频率等。以发版次数为例,网易云音乐iOS版本2021年共更新48次,平均每周1次,最多的是6月份更新过6次,2020年共更新38次,平均1.5周一次,最多的是4和9月份更新过6次。我这里只做了数据罗列,其实有很多值得深挖的地方,比如更新频率这么高?4月份因为什么导致两年都更新得频繁?2月份更新的少是因为过年吗?等等这些都需要结合当时的更新内容(体验优化/新增功能/改版)、外部环境因素(政策/节日/公司动态)等进一步分析。

image.png

2)横向分析:

还是以发版次数为例,下图是2021年网易云音乐和QQ音乐iOS版本的更新次数的对比,能看出来QQ音乐明显更新频次要比网易云音乐低,这是为什么呢?为什么7月份QQ音乐会比网易云更新的多?等等这些疑问都需要再次结合当时的更新内容、外部环境因素进一步分析。

image.png

 

PS:写到这我担心由于这个例子太简陋,让大家误认为通过更新次数就能得到有用的分析,其实不然,更新次数只是一个的切入点,就像分蛋糕,可以对半切、可以十字切,也可以根据蛋糕上的草莓分布去切,更新次数就类似于蛋糕上的草莓。当然了,也不是每次分析更新次数就能得到有价值的信息,就像草莓不一定都是有规律的摆放。

image.png

 

c. 预测明天

了解了竞品功能的现状和发展历程,最重要的就是预测竞品的迭代方向。为了便于分析,我们可以将功能列表和迭代时间轴进行整合,形成竞品功能迭代画布,下图是示意图:

image.png

 

有了这个画布,我们就能清晰地看出竞品在某个时间段的关注点,为预测其下一步的计划提供基础。

还是以网易云音乐为例,在17年3月份上线了用户发布短视频的功能,随后的1年中陆续发布了4次有关短视频的优化,另一方面也在鼓励PGC和UGC。彼时,抖音刚成立一年,快手成立六年。

image.png

 

尽管现在复盘属于开了上帝视角,但若时光倒流,我相信还是能嗅出一丝味道:网易云音乐是要将短视频作为下一个发力点。果不其然,在下一个V5.0.0版本时,网易云音乐进行了大改版,将视频模块单独开辟成一个Tab(现在已整合到云村中了),这次改动在当时引起了很多讨论,我还因此写了一段随感:

image.png

image.png

 

PS:QQ音乐好像是到了2018年9月才开始布局短视频的,比网易云晚了一年多(我是通过关键字搜索的,可能不准)

image.png

综上,总结一下对于产品功能层面的初步竞品分析:

1. 通过功能列表了解功能全貌,记录缺陷和亮点

2. 通过更新记录了解功能变迁,以更新频率为切入点寻找原因

3. 通过竞品功能迭代画布预测其下一步方向

 

2、用户体验

俞军老师说过:用户价值=新体验-旧体验-替换成本,那么如何具体描述“体验”呢,我认为用户体验=有用+易用+好用=功能价值+情绪价值在上一步中我们分析了竞品的功能价值,在此步骤中,我们主要分析竞品给用户带来的情绪价值。

 

a. 研究今天

《设计心理学3-情感设计》告诉我们可以从三个层面分析产品的情绪价值,分别是本能层行为层反思层

image.png

· 本能层

本能层上的情感是产品给用户留下的初次印象,包括logo、主题颜色、界面布局、动效、音效等等。每个产品都会有所区别,比如下图,同样是问卷软件,为什么主题颜色都是蓝灰白?为什么腾讯问卷采用的是左右布局,而问卷网采用的是上下布局?腾讯问卷的logo清晰明确,问卷网的logo为什么没有文字描述,像一个用户头像?类似这些,是这个层面应该考虑的问题。

image.png

 

· 行为层

行为层是用户和产品交互时所体验到的可用性和满足感,包括四个要素:

a)功能性:竞品满足用户需求的程度,详见上文。

b)易理解性:竞品对同一个事物的描述或操作,是否容易被用户理解。比如对于创建好问卷后开始使用这件事,问卷网叫“发布并分享”,而腾讯问卷叫“开始回收”,不知道大家怎么看,回收这个词,在我的认知里代表把东西拿回来,开始把问卷拿回来,让我觉得有点歧义——问卷还没发怎么就要回收了。因此,我们要思考竞品和自身产品的设计是否符合不同经验和文化背景的用户认知和习惯。

image.png

c)易用性:遵循以人为本的设计理念,让用户在使用过程中感到舒适好用。比如当用户在编辑问卷时遇到了操作问题,如果使用问卷网,可直接查看使用帮助或联系在线客服,而如果使用腾讯问卷,必须得退出当前的编辑页面,返回首页才可在二级菜单中查看帮助文档。

image.png

image.png

d)真实感受:互联网产品大多是虚拟的,如果能在用户使用过程中感受到更多真实的体验,会使用户感受到亲切,比如网易云音乐的播放器就做成了唱片机的样子。

image.png

· 反思层

反思层是人通过对产品包含的信息、内容、文化和含义的理解与体会而产生的更深层次的反应,类似触景生情。在这方面可以关注竞品中是否有情景故事和人文关怀的元素

a)情景故事:包括产品本身的故事,比如王者荣耀里每个英雄都有故事背景;也包括产品和用户的故事,如看到年度总结里的数据,会勾起人们的回忆;还包括用户和用户的故事,如”网愈云“的评论。

image.png

b)人文关怀:表现在对用户的尊重和关爱,如抖音声音开太大会提醒可能会影响其他人,半夜刷抖音会提醒早睡,还有苹果的旁白功能,展现了对视障用户的关爱。

image.png

b. 了解昨天

大部分产品在用户体验层面的更新都不会准确告知用户,在更新记录中只是用“修复已知问题,优化体验”一句带过,只能靠产品经理持续跟踪来发现。而且用户体验也不是总是往好的方向发展,也有迫于商业化需求变得越来越差的,比如XX网盘的限速。

 

在发现变化后,需要思考为什么要变化?属于哪一层次的哪一类?能够提升哪类用户在什么场景下的体验?相比之前的方式,用户体验真的变好了吗?为什么要在这个时间段优化该体验?……

360导航为例,从本能层看,新版通过颜色将搜索区域进行了区分,比旧版更有层次感,但是下方区域,由于包含不同效果、尺寸的组件,显得比较凌乱,让人抓不住重点;在行为层上,新版弱化了第三方链接入口,突出了图文内容,以吸引更多用户点击,同时做的人性化的一点是保留了新旧版本的切换,让不同使用习惯的用户都能够找到喜欢的方式。

image.png

c. 预测明天

用户体验涵盖的范围很广,其变化往往伴随着功能、定位、商业等其他方面的变动,并需要结合本能层、行为层、反思层综合考虑。这里可以简化为对体验竞品过程中发现的缺陷预测优化方案即可。

 

综上,总结一下对于用户体验层面的初步竞品分析:

1. 通过本能层、行为层、反思层分析竞品体验上的优缺点

2. 通过持续跟踪了解体验变化并分析原因

3. 针对现有缺陷预测优化方案

3、产品架构

a. 研究今天

产品架构不是功能的叠加,而是业务流程和数据流向抽象的一种表现形式,研究竞品的产品架构能够帮助我们梳理产品思路,把握竞品的发展方向

具体的绘制方法可以参考我的另一篇文章《手把手教你用“DDD”的思维构建产品架构》,这里不再赘述。不一样的是,这里是完全通过竞品的功能逆推出的产品架构,甚至有时功能都没有办法体验到,只能通过现有资料去推测“黑盒”的结构,虽然结果肯定不准,但这一步骤绝不能省略。

image.png

 

PS:产品架构和产品功能的关系类似于房型和家具的关系,我们可以回想一下第一次去别人家参观的场景,肯定会先观察几室几厅、面积多大,然后才观察房间中的家具装饰,这符合人类的思维习惯。所以在理解竞品时,不能只着眼于功能,产品架构能够帮助我们更好地理解功能的来龙去脉。

b. 了解昨天

产品架构一般不会进行大的变动,如果进行了升级,说明现有的架构模式已经承载不了未来1-3年的发展,我们要通过这个过程思考竞品升级的WHY、HOW、WHAT:

· 为何升级:架构升级是为了让新架构更符合战略发展,可能是有新的业务场景,可能是现有架构太臃肿不灵活,也可能是新技术的更新迭代

· 如何升级:如何在不影响原有业务正常运行的情况下,逐渐替换老的架构

· 升级了什么:根据不同的升级原因,找到具体的架构变化

 

c. 预测明天

竞品架构难以预测,但可以对竞品的发展动向略窥一二。再前面的内容里,我们都是以局外人的视角看竞品,可以比较客观地评价竞品哪些地方做的好,哪些地方做的不好,而当我们要预测竞品具体要如何发展时,就不能再用局外人的眼光了,因为缺乏共通性”的思考只是我们的YY。应该把自己放在竞品产品经理的位置上,结合已有的分析,设身处地地去想几个问题:

· 产品的核心竞争力是什么,要怎么构建好竞争壁垒(找准内核)

· 现在产品好的方面有哪些,不好的地方有哪些(明确现状)

· 我作为它的产品经理,未来3个月要着手做哪些优化,为什么(近期目标)

· 围绕现有的业务/场景还有哪些可拓展的方向(发现机会)

· 在以后的一年中,我要怎么规划产品的走向(长期目标)

 

根据持续对竞品的追踪来验证以上预测是否正确。通过此方式也可以不断提高产品决策能力,培养战略思维。

综上,总结一下对于产品架构层面的初步竞品分析:

1. 通过产品功能反推产品架构图

2. 思考竞品架构升级的WHY、HOW、WHAT

3. 通过角色扮演预测架构发展

4、收费方式

成熟的收费方式无非几种:C端产品主要是核心功能免费,利用流量变现、虚拟产品、增值服务、抽佣金等方式盈利;B端产品包括定价、分销和交付等方式。最主要的区别还是体现在项目和定价上,需要我们详细了解。以阿里云和腾讯云对象存储服务为例,虽然都是存储服务,但是其中的资源包类型、地域等收费项目和单价各有不同,也就造成了最终价格的不同。

image.png

 

a. 研究今天

收费方式跟产品功能迭代息息相关,比如从抖音开始有直播功能后,打赏就成了新的一种收费方式,所以可以在竞品功能迭代画布上继续完善收费模式信息:

image.png

如果你再研究得深入些,你会发现同样都是收费功能,有的功能是按次收费,有的是根据版本买断,有的是按时间收费,有的是几种方式的结合,同一产品不同功能的收费策略反映了其对成本需求的考量;同时,不同的产品对同一个功能的收费策略也会不一样,比如产品A使用一次该功能收费2元,产品B只收1元,这反映的是竞品之间的差异化定价技术的竞争。

当然收费方式不应局限于功能层面,还要从服务、内容等纬度思考如何扩大商业价值。比如下图是一个线上考试系统的考试内容服务,我之前一直局限于功能收费,看到了这个图才茅塞顿开,重新构建了我们产品+服务+内容的收费方式,同时顺着这个思路还拓展了硬件服务。

image.png

PS:产品的收费方式信息可以参考竞品信息获取那一小节内容。

b. 了解昨天

收费方式不是一成不变的,会根据实际情况作出调整,大到收费方式的新增或更换,小到某一收费策略的变更,都体现出了竞品在一个阶段的价值主张、核心能力、收入来源、成本结构、用户细分和竞争策略,值得深入研究。

· 价值主张:具有用户价值的产品自然拥有商业价值,不过价值也是分高低的,这基于产品的定位,如线上考试系统能给客户带来的最大价值就是能杜绝考试作弊,如果某个产品不具备防作弊功能,哪怕免费也不会有客户用,相反的具有防作弊能力的系统就有极高的议价权

· 核心能力:围绕产品核心竞争力发展更多收费项目,如QQ音乐拿到了周杰伦的版权,就可以要求用户付费听歌;又如公司在全国各地都有办事处,那么就可以发展线下驻地支撑服务

· 收入来源:改变用户的付费方式,如著名的笔记软件Notability由买断制变为订阅制,一方面是为了获取更多利润,另一方面也降低了用户的入门条件,作为Notability的竞品要不要也跟随,还是要根据自身的实际情况分析

· 成本结构:根据成本变化调整价格,如油价上调,腾讯0.01元中标

· 用户细分:根据不同的用户群调整收费方案,如蓝湖根据企业规模分为免费版、初创团队版、企业版、企业内网部署版,假如哪天新增了大型跨国企业版,就说明这类型企业的需求比较特殊,需要单独调研

· 竞争策略:为了在直接竞争中获得优势而进行的临时性调整,如降低单价、增加套餐内次数、买一年送半年等

 

c. 预测明天

收费方式虽不是一成不变,但也不像版本更新那么频繁,预测竞品的收费方式,需要综合考虑内部因素和外部因素。

内部因素包括:

· 企业能力:判断企业是否能长期运营下去,包括企业背书、融资情况、老板影响力等,如美团从百团大战中活下来的大部分原因是资本的支持,使得补贴一直持续,用户一直留存

· 技术实力:技术实力强的团队可以达到降本增效,提高核心竞争力,如摩尔定律

· 产品定位:针对目标用户不同的需求搭配合理的收费方式,如考试星从考试平台升级成了培训考试平台,相应的收费方式也会进行升级

· 运营活动:以往的节日折扣、运营活动,如快到国庆节了,竞品去年打了8折,今年估计也是这个折扣范围

· 功能迭代:功能迭代与收费项目息息相关,如我们上线了一些竞品没有的功能,可以用于收费

image.png

外部因素包括:

· 市场环境:包括政策环境、法律环境、经济环境等,如双减

· 竞对动态:其他竞争对手的动态,如其他竞品普遍降价了5%,预计该竞品也会降价

综上,总结一下对于收费方式层面的初步竞品分析:

1. 通过收集信息了解各竞品收费方式(产品、服务、内容、硬件等)

2. 通过完善后的竞品功能迭代画布深入研究产品功能层面的收费差异

3. 通过比对收费方式的更新内容分析竞品的价值、能力、收入、成本、用户和竞争策略的变化

4. 结合内外部因素综合考虑未来收费方式的变化

 

5、产品定位

a. 研究今天

产品定位就是回答帮助哪些用户在什么场景下解决哪些问题。往往可以从产品slogan、官网、官方资料中总结出。

image.png

 

不过这样还是太笼统,产品定位的核心是找到差异化,用户的差异,场景的差异,解决问题的差异……世界上没有两款一模一样的产品。比如同样都是定位为短视频平台,抖音、快手各有不同;同样都是协同办公软件,企微、钉钉、飞书各有侧重。经过以上对功能、体验、架构、收费的研究,我们能更容易找到竞品独特的地方

 

企微

钉钉

飞书

核心

连接

管理

协同

b. 了解昨天

早先导航网站的定位是“网址簿”,上面汇集着各种类别的网址,随着人们获取信息的渠道不断增多,网址不再是用户最终目的,网址中呈现的信息才是,于是导航网站纷纷从“网址导航”变为“信息导航”,增加了第三方的新闻、小说、游戏、购物等内容。再后来,企业为了吸引、留存、转化流量,开始涉足内容平台,导航网站又一次升级为“内容导航”,为自家内容产品做引流。

image.png

从上述的例子中我们可以看出,产品定位的变化体现出用户需求的升级和商业需求的拓展。通过研究竞品定位的变化,能够帮助我们把握市场需求,避免在发展战略和发展步骤上的失误,降低风险。

 

c. 预测明天

要预测竞品的定位变化,就要了解竞品在该领域下所处的地位:

· 领先者:一方面要巩固现有的核心竞争力,一方面要向客户的潜在需求深入,拓展更多业务场景,比如360导航针对儿童用户推出了少年版,同时还要预防竞争对手的挑战

image.png

· 追随者:寻找市场、用户、服务、价格等空位切入,利用差异化深入人心,比如拼多多之于淘宝、WPS之于office、去哪儿之于携程……

 

综上,总结一下对于产品定位层面的初步竞品分析:

1. 找到竞品的差异化定位

2. 找到定位升级的原因

3. 根据竞品不同的地位采取相应的定位策略

四、详细竞品分析

image.png

定义:详细竞品分析是有目的性地对竞品某些模块进行全方位拆解

目的:了解产品功能和技术设计背后的逻辑

好处:帮助我们少走弯路,弯道超车

场景:产品设计

核心达到能倒推出产品需求文档和技术方案的程度

详细竞品分析是产品经理在进行产品设计时经常使用到的,大到几个功能模块,小到一个逻辑的判断条件,都可以成为详细竞品分析的对象,所以这一部分没有固定的方法,但是有一般的步骤:

1. 设立目标:详细分析的目的是什么

2. 制定计划:怎么样一步一步实现这个目的

3. 物料准备:提前准备好分析所有的材料,包括设备、软件、人员等

4. 功能分析:由产品主导,测试协助实施

5. 技术分析:由研发人员主导实施的逆向工程

 

1、设立目标

设立目标要遵循SMART原则:

· S代表具体的(Specific),目标要清晰明确,所有人都能看懂并达成共识

· M代表可度量(Measurable),目标是可以验证的

· A代表可实现(Attainable),目标不要太高或太低,努努力就能达到最为合适

· R代表相关性(Relevant),要与自身产品契合

· T代表有时限(Time-bound),需要有deadline

比如:在1周内调研竞品的进销存系统,了解并借鉴他们的业务流程和设计逻辑,输出分析报告;利用3天时间深入研究竞品有哪些防作弊功能,并与我们进行对比;花10分钟看看竞品在答题时的保存逻辑,是否可以借鉴;让开发协助调研一下竞品是采用了什么技术来解决上万人同时发卷造成的高并发问题,并给出我们的技术方案。

 

2、制定计划

为了更好地达成目标,需要提前制定好详细的研究计划和步骤。特别是对于B端软件,这一步必不可省,因为很多功能会有使用次数的限制,有可能你只有一次机会用来研究,所以要好好把握。制定计划有点像是制定测试用例,因为我们要通过遍历各种条件才能推测出背后的逻辑规则。

以我熟悉的教育信息化领域为例,目的是为了研究竞品在线作答时的保存逻辑,包括有哪些保存方式,每种保存方式的机制是什么,简答题是如何保存的,刷新、闪退这种异常情况的保存逻辑是什么,等等,都需要提前计划好。拟完初步的计划后,最好再发给测试、设计、开发等相关干系人,看看从他们的角度有没有要补充的。

image.png

 

3、物料准备

a. 人员

安排好相关人员与你一起测试,比如考试场景需要考生和考官共同配合;有些功能需要研究技术方案,可以叫上对应的开发人员。

b. 资料

准备好相关的文档资料,比如帮助手册、使用手册、宣传PPT、收费项目等,便于需要的时候查看。

c. 软件

根据分析的目的准备所用的软件,比如要研究竞品的技术,可以准备好抓包软件;要研究竞品的无网和弱网策略,需要准备好限流软件等。同时还要准备好截屏、录屏等用于留存竞品资料的软件。

d. 设备

根据分析的目的准备所用的设备,比如所需型号的手机、电脑;录像录音设备等。

4、功能分析

a. 体验

接下来就是一步一步地实施计划了,这里没有通用的方法可言,需要耐心仔细地围绕分析目的去体验竞品。在体验过程中可以根据实际情况对原有计划进行新增或调整,有条件的也可以体验多轮,直到搞透业务的流程页面的交互功能的逻辑数据的流转

b. 记录

在深入体验竞品的过程中一定要随时记录关键信息,避免事后遗忘,包括流程图、体验结果、关键页面截图等。

 

c. 分析

设计没有对错,只有适不适合。在详细了解了竞品之后,就要探究竞品为什么要这样设计,有什么优势和劣势,并结合自身的业务决定哪些地方可以借鉴,哪些地方需要摒弃。比如有的竞品在作答时是一个页面展示一道题,在切换题目时触发自动保存,这种方式就值得借鉴,既能清晰展示每道题又保证保存接口不会被调得太频繁(与每选择一个选项就自动保存的方式进行对比);又如有的竞品在考场开始后,还支持修改试卷,对于已经在作答的同学来说试卷不会变动,对于还未作答的同学来说试卷会显示成最新的,这种方式适用于随来随考的场景,但不适合集中考试。

 

5、技术分析

不止产品设计,技术方案的设计同样也需要进行详细分析,因为技术方案在一定程度上会影响产品方案。比如上千人同时发卷,每个考生的试卷都是从题库中随机抽取的,竞品是如何做到在短时间内发完所有人的试卷且不出错的;音视频房间是有路数限制的,竞品是怎样做到同时监考上百人的;录制视频时,是采用本地录制然后上传云端还是直接云端录制,等等。这方面主要由开发人员利用逆向工程进行了解,这里不进行展开。

经过以上的研究和论证,我们能够理解竞品的设计逻辑,同时结合自身业务取长补短,达成分析目的。

五、竞品分析报告

image.png
不管是初步竞品分析还是详细竞品分析,得到的内容都是零散的,需要进行汇编整理,而整理的最好方式就是输出一份分析报告。好的竞品分析报告不仅汇集了整个分析过程的精华内容,还能够给阅读者启示,帮助他们制定决策。

 

1、报告的形式

大多数竞品分析报告都是要给上级或客户汇报的,基于易读性,常以PPT的形式呈现,如果是给自己或者团队内部看,形式就不固定了,也可以是Word、Excel、思维导图等,怎么方便怎么来。

2、报告的结构

不管是初步竞品分析还是详细竞品分析,都建议使用总-分-总的结构:

a. 总

先展示分析报告的概述内容,至少应包含:

· 分析的背景和目的

· 选择的竞品信息,包括竞品的名称、版本、产品形态及选择的原因

· 简要描述分析的过程,如果是初步竞品分析,可以说从哪些方面进行的分析;如果是详细竞品分析,可以展示制定的计划

· 总体结论,遵循结论先行的原则,在开篇就把主题论点阐明出来

b. 分

然后将初步竞品分析或详细竞品分析的体验过程和结果分维度展示出来,并且附上你对各维度的分析结论。需要注意两点:

· 结构化:结论先行、以上统下、归类分组、逻辑递进

· 可视化:能用图表就不要用文字,对重点语句进行标注,忌讳华丽花哨的动效,字体字号保持一致,使用严肃大方的PPT风格等等,如果用于重要的汇报,建议找UI进行美化

c. 总

最后再次总结分析结论,并要结合自身产品形成可落地的行动计划,否则就是纸上谈兵。

3、报告的四要素

a. 对比

前面我们已经纵向对比了竞品的变化,这里着重横向对比多个竞品的不同。呈现对比的元素有很多,比如功能对比图、表格、条形图等。

image.png

 

b. 分析

如果只是单纯的记录体验竞品的过程,那这不是一次有效的分析。竞品分析的真正价值在于产品经理对竞品的思考。为什么要这样设计?如果换成其他方式会怎么样?同一个功能,不同竞品为什么有不同的实现方式?为什么竞品没有做XX业务/功能?为什么竞品最近总是围绕XX模块进行更新?等等这类问题,都需要产品经理透过现象分析问题本质。

c. 结论

光有分析还不够,还要给出结论:经过以上分析,哪些地方要学习,哪些地方要优化,哪些地方要新增,哪些地方要改方案。就像向上汇报时,不能只给领导抛出问题,而是要连同你的解决方案一起告知领导做判断。

d. 计划

有了结论还要再进行深化,针对要改进的方向整理出具体的可落地的计划,比如把这些优化点记录到需求池中,根据优先级安排到某一期迭代中,这样也能够提高产品规划能力。

六、其他要说的话

image.png

1、竞品分析需要持续关注

在产品整个生命周期中都要持续关注竞品,但我们不可能对每个竞品都进行详细地分析,毕竟要考虑成本收益比,那么如何能够花更少的精力获取到更大的分析价值呢?还记得在我们之前建立过的用户场景方格吗,可以根据竞品所在的方格分类管理

· 重点跟踪:从A类挑选出来的竞品必须要重点跟踪,大到产品更新,小到每一个功能逻辑都要把他们研究透彻,只有形成差异化,才能站得更稳

· 定时监督:BC类竞品属于潜在竞争者,尽管有场景/用户的区别,但是如果他们想进入我们所在的领域,也不是特别的难。所以对于这类竞品,需要定期关注,做好防御

· 偶尔关注:在有剩余精力的情况下,可以关注一下D类竞品,说不定能从中寻到一些启发

image.png

 

2、做好资料留存

在整个过程中要留存好有关竞品的所有资料,包括竞品原始资料、分析材料等。又由于竞品分析是一个长期的过程,所以还要注意按时间/版本进行整理。

3、取其精华去其糟粕

在特别深入地了解竞品逻辑后,产品经理在设计功能时很容易就陷入“抄”的误区,尽管可以减少试错成本、降低风险,但还算是要提醒大家一定要结合自身的业务取其精华去其糟粕。拿“题库组卷”功能举例,组好卷后,如果修改题库中的题目信息,试卷里的题目要不要同步更新呢?有的竞品会同步更新,而有的竞品不会同步更新,这取决于各自的考试场景。

同时还可以在抄的基础上做一些微创新。比如将登录验证码融入更有趣的方式,像刮刮卡、拼图等。

image.png

4、关于竞品分析里要不要做市场和用户分析

在日常工作中,分析竞品时确实不会做市场和用户分析,因为市场分析、用户分析、竞品分析是并列的关系,并不是谁包含谁,各自都有一套成熟的分析方法论。而且对于市场分析,其实是超出了产品经理的工作范畴,在大公司有专门的市场研究部门,在小公司要靠管理层敏锐的嗅觉,产品经理能做的贡献甚少,特别是对产品新人,基础都没打牢,就关注顶层的东西,又没有数据支撑,只能摘录第三方的资料,没有什么意义。

 

5、对产品新人说的话

我知道你们需要竞品分析作为敲门砖或是产品思维的练手,因为我曾经也是那样过来的——在大学时候为了入行写过几篇竞品分析报告(产品壹佰上还能搜到:手机K歌哪家强:唱吧&全民K歌竞品分析报告移动电台竞品分析丨蜻蜓FM&喜马拉雅FM&企鹅FM)。但工作后就再没写过,因为我发现工作后的竞品分析远没有那样简单。

作为一个面试官,建议大家不要再套用“先分析市场和用户,再通过用户体验五要素逐层分解”这种大而全的模板了,对我们来说,除了看到你的主观能动性外,没有其他的任何意义。如果实在要写,不如聚焦于某个功能模块做详细分析,比如京东VS淘宝的会员体系分析、有赞VS金蝶关于库存管理的分析,不放过任何细微的区别并找到区别的原因,这样还能提高你的深度思考能力。

七、总结

竞品分析是一件及其费时费力的工作。分析竞品最好的时间是从它的第一版开始,其次是现在。

image.png

全文完。

 

]]>
https://coffee.pmcaff.com/article/gjkyM3N5kM https://coffee.pmcaff.com/article/gjkyM3N5kM Mon, 23 May 2022 10:43:29 +0800
<![CDATA[ B端产品设计流程--如何进行产品架构设计(下) ]]>

前言:

在上篇文章中我们重点讲述了业务调研,业务调研是我们架构设计的基础,只有了解清晰业务形态,整体流程及相互关系之后,才能设计出符合业务形态的产品架构产品架构是将具体的业务功能按照一定规则组装成业务模块,将不同业务模块按照一定规则进行划分和归拢,并用图形或者文字把各模块之间的关系表达出来的逻辑模型接下这篇文章跟大家分享和交流我们如何设计出一份好的产品架构。



1、什么是好的产品架构

一个好的产品架构需要能够助力商业模式、体现公司目标、具备落地性,同时具备抽象能力和扩展能力。抽象能力的适应性体现在其匹配的行业,抽象能力较好的产品架构可以适用于多个行业,支持其横向的覆盖范围。而扩展能力适应性体现在其可以包容接纳的领域,扩展性好的产品架构,各模块之间边界清晰,职能明确,兼容性强,可以在演进的过程中,将更多的领域纳入到自己的架构中,成为整个产品的一部分,并且可以实现接入过程,成本低,时间短,少出错。总的来说产品架构的抽象能力能帮助产品适配多个行业,支持横向覆盖能帮助产品适配更多的领域,支持纵向演进。抽象能力和扩展能力代表了一个产品在不同维度的适应性。

60c103fa7827f_05.jpg



2、产品架构的核心要素

在进行架构设计之前我们需要了解产品架构所包含的要素,通过我们对上文产品架构是什么的理解,我们可以将产品架构拆分成功能、模块、域、层、逻辑关系几个维度。在架构设计过程中将不同的功能汇聚成模块,而模块的划分需要遵循一定的规则,根据角色、场景、交互操作等去进行功能块的聚合。而不同模块可以进一步聚合形成域,域是模块根据某个场景聚拢而形成的,域可以支撑某一个场景下的一系列操作,输出一个闭环的能力。而层则是某几个域和模块的组合,层实现了向下整合或向上支撑的统一化的能力。逻辑关系指层、域、模块之间需要有清晰地逻辑关系,包括输入输出、职能边界等等。产品架构是一个没有标准化量化好坏的东西,在做产品架构设计时不可避免需要考虑多角色诉求,产品经理在设计产品架构时一定要多角度,多维度去综合考虑,达到一个相对平衡的结果,这一点尤为重要;其次产品架构设计时也需要充分考虑商业模式,这一点也至关重要。

同时我们在日常工作中也常听到技术人员说架构,技术架构与产品架构两者是两个层级的东西,产品架构技术架构更上一层的逻辑,是进行技术架构的设计时所必须的业务依据,而技术架构是对产品架构的实现逻辑的反馈,是产品是否可以按照这样进行设计的技术依据,两者之间相辅相成,有依托也有支撑

60c103fa7827f_05.jpg



3、如何保证产品架构的抽象能力

对于SaaS产品来说其面对的客户是相对广泛的,不同的客户所处的发展阶段也不尽相同,甚至我们能够看到同一类型的客户,他们的诉求也会存在一定差别,正因为如此我们需要对服务客户的业务进行抽象,找到自己所面临的的客户群体,找到这些群里存在的共性、差异性。那我们在产品架构设计中如何去解决个性化与标准化共存的问题,而解决这个问题我们需要去做三件事:拆分产品战略、抽象客户业务本质、实现高内聚低耦合。

3.1、拆分产品战略

我们之所以要拆分产品战略,因为产品架构需要体现客户的意志,明确客户想做什么,先做什么,后做什么,那些部分要做到什么程度,战略的拆分是想通过产品架构的设计来表达客户最终想要的样子,以及产品是按照什么路径演进到最终客户想要的样子。整个路径中那些关键节点,而这些关键节点就是我们的里程碑,所以我们才需要去拆分产品战略。

拆分产品战略主要是指拆分企业的业务战略和企业的管理战略。业务战略是以实现营收,节约成本作为目标的,业务战略相对清晰可衡量。而管理战略目标则相对模糊不易衡量,往往涉及企业内部管理。针对业务战略我们通过三表法的方式去分析和拆解,针对管理战略我们场景代入的方法进行拆解,下面跟大家一起看看具体的执行方法

3.1.1、我们通过三表法拆分业务战略;

第一步:拆分内容,进行汇聚;

目标表:要达成什么结果,这些结果哪些小目标组成的,小目标对整体结果贡献度是什么;

策略表:策略表是针对需要实现的目标给出一对一或一对多的落地方案的解答,怎么达到我们预定的结果,分几步进行,每一步的玩法是什么,每一步阶段性成果如何衡量;

资源表:需要什么支持,需要多少,需要多久

第二步:分类汇总,合并归纳;

针对目标表:那些目标是相似的,那些目标是有因果关系的,那些目标是相互依赖或冲突的;

针对策略表:那些策略是相同或者相似的,那些策略是有先后顺序的,那些策略之间是冲突的;

针对资源表:那些资源是共享的,那些资源是独享的,那些资源是相互依赖的;

根据相似相同的内容合并总结共性;无法合并的部分,分析其差异性,根据共性与差异性规划产品的大模块

第三步:建模;

1. 组合产品大模块建立初步模型;

2. 组合职能相近模块,逐步拆分层、域、模块,在架构图中分层着色;

3. 串联模块关系,明确模块内部资源,依赖外部能力输出;

4. 标识整体及小目标,制定roadmap,定各阶段的落地策略

通过上面三步我们就能获得初步的产品架构图,以及这个架构图也能初步体现出产品在不同阶段是什么样子,在之后我们不断反推,不断修正

3.1.2、场景代入法拆分管理战略:

管理战略很多都是重视流程的,因为流程代表了标准化的流程和透明化的进展,以及明确的执行节点和确定的执行结果。所以我们场景代入法来思考。在场景代入法中代入一般会根据特定约束进行假设,比如假我是管理者/操作人,在XX情况下我需要关注那些事情。在之前的文章中我们也提到过流程的五要素:典型场景、关键角色、操作行为、结果分支、数据沉淀。场景代入法则关注流程五要素中的三个要素典型场景(正向场景、逆向场景)、典型角色(管理者的关注点、操作人的关注点)、典型行为(正常的行为、非正常的行为)。在做场景代入法时很多时候我们只考虑了正向场景,而逆向场景会有忽视,同时也会出现遗落不同的关键角色而进行架构设计和规划的情况,所以在做场景代入我们要充分考虑正向与逆向的场景和与之对应的不同角色,尽可能考虑周全

60c103fa7827f_09.jpg3.2、抽象客户业务本质:

在此之前我们分享过如何去做市场分析、产业链分析、商业模式分析,其本质还是回到我们如何去理解客户业务的本质,需要明白客户是什么,他们通过什么去赚钱的,他们的玩法是什么,是需要什么样的产品来支撑他们日常运营管理的

抽象客户本质是一个从现象到建模,再从模型回到业务本身的一个过程。在上一步中我们通过拆分产品战略,将规划的产品模块进行组合,依据客户的商业模式建立符合客户战略的初步产品模型,其中客户的商业模式就是客户业务本质的体现,客户组织架构是管理本质的体现。从业务角度来说产品的架构模型需要满足客户的商业模式,从管理角度来说产品的流程设计要符合行业通用的玩法。而从模型回到业务本身,这个过程是一个推演的过程,毕竟产品是要落地到最终的场景和具体的业务当中去,所以产品的架构要在模型的基础上考虑业务的实际场景,与此同时在产品功能模块设计上要针对客户的痛点。所以抽象客户业务本质我们需要站一定的高度,同时也要接地气,要掌握好两者之间的平衡,这也是衡量一个产品经理产品设计能力好坏的一个标准。

3.3、高内聚低耦合:

高内聚低耦合在产品架构设计中是用来描述产品内部各模块之间的关联关系以及产品模块本身的能力的具备高内聚低耦合的产品架构能够清晰地向客户描述产品是什么样的,也可以告诉技术人员怎么设计技术架构,所以他要衔接技术语言与业务语言图形化的方式。实现高内聚低耦合我们需要在产品架构上做到分层、分域、职能边界明确、输入输出清晰。

分层:

分层是一个功能维度上的概念,可以按照服务的对象不同,分为用户层、业务层、数据层,用户层是将所有面向用户的功能集合在一个层级,用户层需要考虑不同的用户群体所享受的服务存在差异。业务层是将所有的业务处理规则和逻辑,集成在业务层,业务层对用户层有逻辑支撑,业务层在不同的场景下集成的规则和能力都是不同的,向上输出也不尽相同。数据层是将所有的数据沉淀,数据处理集成在了数据层,数据层提供基础的跟数据相关的增删改查服务,这些服务供业务层调用,在不同的场景下沉淀不同格式的数据。分层同时有上下游概念的,比如供应链电商他的产品架构是可以分为交易平台层、供应链层的,交易平台核心在于撮合交易由商品、会员、订单等组成,供应链层则主要负责售前的采购以及售后的履约行为等。

产品架构是对业务分层设计的过程,不同的分层信息展示的侧重点也就不同,比如按照功能维度进行了分层,分成了用户层、业务层、数据层。用户层考虑如何更好的表达业务元素,如何能够更吸引用户的注意力和停留决策,千人千面或千客户千面是这一层想要达到的效果。业务层核心是解决产品核心功能设计问题的,如何高效地完成场景下的业务需求,是这一层关注的重点而数据层是与用户隔离的黑箱,决定了所有业务问题的集合。

分域:

分层之后我们进行分域,分域进一步降低耦合,再提升一部分的内聚。域一般情况下可以考虑按照业务职能进行划分,常规所见的比如ERP域、交易域、流量域等等,与此同时域也可以根据业务线或业务主体进行划分,最常见的比如滴滴租车域、专车域、顺风车域等,这种划分本质也是逐步在扩充我们业务边界,也是产品生态的不断扩容;这种划分主要是有利于企业内部跨主体,跨业务线之的配合,域也可以按照系统的关系来进行划分的,支撑域、集成域、消费域这类划分方式,这种方式划分能够把能力聚合在一起向外提供统一服务。而集成域更像是一种解决方案的聚合。当然我们也能够按照技术职能进行划分的

完成分层分域之后我们整体的架构相当于已经完成了一大半了,整体长什么样子基本清晰了,那么下一步就是我们对这个图进一步进行调整和优化了,确定清晰各职能边界和输入输出。产品架构设计的粒度,从大到小应该是层、域、模块、功能这个顺序,其中分层分域主要解决降低耦合的问题也兼具解决了一部分内聚的问题,而职能边界与输入输出解决高度内聚的问题,同时兼具降低耦合。这两者侧重点是不同的,这也是我们产品设计时需要围绕的设计理念。接下来我们看看如何确认各模块之间的职能边界与输入输出:

60c103fa7827f_05.jpg

保持适当的抽象,满足客户的本质诉求,切莫流于表面,抽象和演绎是一个不断循环的过程,内聚与耦合是一个相互平衡的结果。



4、如何保障产品架构的扩展能力

产品架构并非是一成不变的,需要随着业务的发展,商业模式的变化与时俱进。不断迭代验证,优化更新,所以产品架构需要具备一定的扩展性。其次设计一个产品并不是一开始就将所有的功能模块全部落地,而是有先有后,有主有次的过程。所以产品架构需要考虑演进的路线和实际,也是需要扩展性的。B端产品并非都是从0到1的,而是有可能出现从0.X到1或者是从1到X的情况,需要产品的设计者依托于现在的产品架构,思考如何演进到未来理想中的产品架构,所以才需要我们的产品具备可扩展的能力,不具备扩展能力的产品容易在产品演进的过程中推倒重来,这对企业来说是灾难性的,时间的成本远远大于金钱损失的成本。

确保产品架构的扩展能力我们需要做三件事,第一确认产品架构演进蓝图,第二明确产品架构的三个部分,第三取舍架构模块其中确认产品架构的演进蓝图,是明确产品演进需要走得路,明确路上所需要经历的里程碑;明确产品架构的三个部分是将产品组件化、产品标准化,然后让产品像搭积木一样,有利于在产品演进过程中的拆分和新增重构。取舍架构的模块是确定产品做什么,不做什么,先做什么后做什么。需要做的部分我们要做到什么程度,是做到极致还是取舍平衡。这是考量产品经理格局的非常重要的一个点。

4.1、确认产品架构演进蓝图:

产品架构的演进需要考虑清晰我们产品现在的样子,产品未来的样子,产品每一步的样子。

4.2、明确产品架构的三个部分:

产品架构想要具备扩展性,就需要考虑将产品的模块按照其在架构中可能涉及到的变化频率分为三个类别:

核心层:作为不可变或低频可变的内容,用于设计产品最核心,最具竞争力的部分;大部分产品架构中数据层都是核心层,核心层提供的能力是最内聚的,是产品的底座。

组合层:是指将一些垂直的场景内聚到域当中,域内的能力是相对集中的,通过跨域的组合搭建不同的商业场景,组合层的能力决定了产品的灵活性。

定制层:定制层主要指差异化的部分,差异化的部分是可以进行定制的,定制出来的功能模块需要组合层的支撑,组合层提供的能力越多,那么定制层的定制能力则越强,扩展性就越好。

还要一块边界相对模糊,大多用于模块之间的交互的部分归纳成其他部分,我们常见的比如API层面;这几层之间是会随着业务的发展逐步转化的,比如定制层的业务在某一个方向上他的体量有显著的增长,这时候产品的逻辑会固化起来,那么这些固化的内容就会逐步演变成支撑某些特定的商业场景的组合层,甚至某些组合的能力进一步抽象,抽象出来的部分我们发现变成了低频可变的部分,这个部分就可以下沉到核心层。具备了这三个部分的能力的产品架构,已经具备相当不错的可扩展的能力了,主要体现在大部分业务的特性化诉求,都是可以通过定制层来满足的,少部分具备一定抽象能力的求,可以在组合层中来支持,这样我们核心层基本不动,这样产品改造,新模块进入都是相对比较快的,只有当出现大的技术变革或业务方向发生调整之后,核心层才会发生改变。

4.3、取舍架构模块:

产品架构是用来落地的,所以落地的过程就是要有先有后,不是同时开始的,B端产品的设计需要考虑每一步的样子,所以在明确整体的产品架构以后,就要去想下一步要做什么,我们产品要做的东西那么多,那么在设计时我们一定要做一定的取舍,什么想做是产品设计的大忌。但是产品设计在最初阶段遇到无法取舍,不好取舍,因为看上去每一个模块都是必须要,我不做什么都会产生影响,每一个模块之间都有关联关系,先做谁都不好,基于这种情况给出四个取舍维度:

60c103fa7827f_05.jpg

取舍的原则看上去确实很简单,或者别人告诉你这个需求紧,价值高,关联性强,落地性也好,也都可以去做取舍,但是本质却是如何去判断需求紧不紧,模块价值大不大,关联性强不强,落地难不难。有时候产品经理获取到的信息可能是所有人都说这个需求紧急,价值高需要优先去做,这两个模块之间关联性强应该要两个都做等等,这时候产品经理又该如何去做判断:遇到这种情况也给大家推荐两种取舍方式,正向:这个模块我取,有什么好处,落地难如何?逆向:这个模块我不取,有什么坏处?在这里面逆向的推演需要考虑的东西更多比如这个模块舍弃对整个产品会造成什么影响,不上这个功能之前的解决方案是什么样的,产品不做这个,原有解决方案是不是还能用等等。在很多时候我们可能会有临时替代方案去做产品,但是在做临时方案设想时需要考虑清楚,解决方案的代价如何,是否能够满足一个阶段的运行,另外我们在何时进行临时方案的替代。产品经理在取舍层面需要有自己的产品价值观,需要有自己的坚持和自己的判断。



结尾:

最后我们再一起回顾下通过文章可以了解到,我们如何去做一个好的产架构,以及我们可以通过助力商业模式、体现公司目标、落地性,抽象能力和扩展能力这五个维度去衡量一个架构的好坏,那么我们再串联一下之前的几篇文章,整个产品的架构设计流程我们从最初的市场及产业链分析再到现状与目标客户分析,再到确定模块与场景域,最后进行架构图设计,而产品架构设计的粒度,从大到小应从层、域、模块、功能。到这里B端产品规划设计阶段就结束了。

]]>
https://coffee.pmcaff.com/article/a1LR8Vo8BZ https://coffee.pmcaff.com/article/a1LR8Vo8BZ Thu, 19 May 2022 16:51:51 +0800
<![CDATA[ 【6000字长文】需求评审总是被怼?强烈推荐你试试这三招 ]]>

前段时间和一个合作部门的产品新人沟通需求,结束的时候,他问了我一个问题,“你在产品新人阶段,最害怕做的事情是什么”?

我不假思索的回答说,“需求评审,是曾经最不想面对的环节,甚至在评审之前几个小时就开始心跳加速了。当然这也是产品修炼路上的必经之路,其实只要掌握正确的方法,那你会发现一切尽在掌握中。”

每一次需求评审,可以称得上是对产品经理的一次毒打,心理素质好的产品经理,每次经历完需求评审,都能够客观的面对各方的质疑和挑战、认真反思,逐渐做到游刃有余;而玻璃心的产品经理,会感觉遭遇了一场“人身攻击”,真的有可能萌生退意。

不夸张的说,如果你想劝退一名准备入行的产品经理的话,那就带他去参加一次需求评审会吧。

对于产品新人,或者是刚刚加入一个新团队的产品经理来说,第一次需求评审不仅仅会决定团队对你的第一印象,更能决定你未来评审的过程是否顺利。

我们来想象下这样一个画面,如果你第一次评审准备充足,需求合理,问题对答如流,那研发、UI、测试不但会心甘情愿的满足你这个需求,更是对你的专业能力比较认可,那未来在面对你的需求时候,可能就会更宽容很多。

但如果在评审过程中,需求不合理,解答不清晰,收益不明确,被研发怼的体无完肤,那你在他们心目中的第一印象就不太好了,可想而知后面的日子肯定不好过,要知道改变第一印象是不容易的。

我在经历数十次需求评审之后,从最初面对需求评审的瑟瑟发抖,到现在能够从容的应对各方的“刁难”,这篇文章就和大家分享下我的故事,手把手教你如何准备一场需求评审,让你和大家“和谐相处”,顺利的把需求推进下去。

一、需求评审的意义

为什么有需求评审这个环节呢?需求评审的意义到底是什么呢?

盲人摸象的故事大家都知道,如果没有需求评审,那这个需求就变成了没有经过多方推敲的需求,只是从产品的视角评估的单一维度的需求,很难发现整个需求的全貌。

下面结合了我自己的初入职场的血泪史以及在工作中看到的一些案例,和大家分享两个没有经过评审造成的后果,希望大家不要重蹈覆辙。

第一,双方信息理解不一致,造成二次开发,影响和研发之间的关系。

一般这种不经过评审的需求往往是涉及的联动方不多,或者团队内部可以搞定需求,大家出于能节省时间,所以简单沟通下就行动起来了,但往往这个时候最容易出问题。

产品和研发之间往往是有认知差异的,你传达的信息研发不一定能接收完整且准确,然后就按照自己的理解照做了,到了上线之后,你却发现这不是我想要的呀,而研发说你就是这么说的呢。

这样带来的后果就是,不但没有节约时间,甚至还要返工重做,降低了开发效率,影响了产研同事间的信任关系。

第二,喜提“背锅侠”,在领导心目中的形象大打折扣。

其次,需求重新开发,必定会造成研发资源的调整,那大概率会惊动产研的领导,会被问起为什么会这样,这种情况下,产品的责任自然是最大的,这对你在领导以及业务方心目中的印象会很减分的。

无论都是简单或者紧急的需求,都不要省去需求评审的这个环节,哪怕就是拉上研发,对着文档1V1过一遍细节,就能很大程度上避免“浪费时间、消耗信任、增加隔阂”这类情况发生。

所以,需求评审有以下三点重要意义:

1、能够有效的传递需求准确性和评估需求可行性;

2、在多方之间达成需求的共识,做事留痕,明确权责利,避免背锅和甩锅;

3、能够在开发阶段高效的推进需求,防止相互扯皮,提高需求的开发效率。

那么,如何准备一场好的需求评审呢?下图就是评审前、评审中以及评审后应该注意的要点,接下来从这三方面展开和大家聊聊具体应该怎么做。

f865bb29fbe6c8acadff296a65b0cbad-picture

二、需求评审之前

这里我们主要讨论在业务逻辑上是合理的需求,那理所应当是可以进入到需求池的。那些和产品定位有冲突的需求,如果是这些需求,是需要我们产品提前识别出来,扼杀在萌芽当中,我们对这部分本次不做展开。

凡事预则立,不预则废。所以,在面对一场需求评审的时候,一定要做好充足的准备。

第一要准备一份需求文档,描述清楚这次需求具体要实现哪些功能、达到什么目的。

这里需求文档不需要太复杂,只要描述清晰、重点突出即可,往往不同的公司都有对应的需求文档模板,或者提前和研发沟通,输出让他们看着最舒服的样式即可。

不同类型的需求文档差异还是比较大的,不过一般的需求文档是要包括这六部分内容的,需求背景(现状、问题)、需求目标(预期收益和价值)、业务流程、竞品分析和调研结果、本次具体实现功能以及埋点管理。

第二是要进行需求预沟通

预沟通这个环节非常重要,能够帮助我们再次确认需求理解是否有误、以及需求逻辑和实现上有没有问题。

这里包括两个沟通方,第一个沟通方是业务方,带着需求文档和提需求的业务方进行需求的二次确认,作为过来人,一定要养成习惯,不要漏掉这个过程。

因为我们肯定遇到过这样的情况,需求上线后兴高采烈的给业务方验收,结果业务方生气的说,“这和我提的需求不太一样呀,我要的口径是这样的,你这个是按照那样实现的,不满足我的需求,再重新做一下吧”,然后潇洒的转身离开了,只留下在风中凌乱的你。

很多时候业务觉得他表达清楚了,你也觉得你听懂了,但是毕竟大家的视角不同,认知上有差异。而且业务往往是不懂技术的,只表达自己想要什么。所以一定要把需求以文字的形式展示给需求方,花上几分钟反讲下需求,这几分钟带来的收益,很有可能会给你带来数倍的回报。

另一个沟通方就是约上这次需求的主研发or研发负责人,需要一起明确以下三个问题。

第一是这个需求的逻辑有没有问题。需求的逻辑正确与否,是这个需求到底做不做的决定性因素,如果需求方案很好,但是逻辑上根本行不通,那就是理想很丰满,现实很骨感,这个方案不能实际落地。

举个例子,比如你承接了来自某视频app的用户增长部的一个需求,要求减少视频片头广告时间甚至去掉广告,如果只站在业务方的角度去看没有什么问题,但是这个需求会员部会答应吗?的确减少广告时长或者去掉广告,大概率能够带来一定的用户增长,但是也会大幅的减少收入,显然这个逻辑站在全局的视角来看是行不通的。

第二是这个需求能不能实现。当明确的逻辑没问题之后,要明确需求能不能实现,也就是开发量的问题。比如这个需求确实不错,收益也预计很高,但是研发水平或者人力有限,可能半年都做不完,那就需要考虑下这个需求的ROI了,这时候就需要向上升级,让领导了解基本情况,至于是先实现MVP版本,还是申请额外资源全力开发,这是领导层来决定的问题。

比如需求背景中提到的搭建自动化营销系统,这个需求各方都很认可,但是技术上实现比较复杂,涉及到用户画像的构建、商品的个性化定价以及营销系统性能的提升。

最后也是按照功能的优先级和实现的难易程度,分期完成的。所以一个需求有时候并不能一次性就搞定,毕竟各个方向都是多线并行的,难免有资源的冲突。有了预计能够实现的部分,也要及时同步业务方,让其有个心理预期,千万不要等到交付的时候才告知砍了需求,这是很不职业的行为。

第三是如果实现会不会有什么负面影响或者影响其他方向。在逻辑和实现都没问题的前提下,那也要让研发帮忙评估会有没有负面影响,如果是优化1个问题出现了3个新问题的需求,那也是没必要做的。另外,这个需求也有可能对上下游有潜在的影响,需要多方配合迭代,那就要求我们提前知会相关方,评估需求的影响范围,而不是到了正式评审的时候突然拉着对方来配合,这会让相关方留下对你不好印象,影响后续的合作。

当我们确定好以上三点之后,如果都没有问题,那就可以继续推进需求了,敲定评审时间之后,一定要给各个方向的负责人发会议邀请,至少要提前一天沟通确认会议时间,这样可以让大家有时间准备,可以极大的提高会议效率。

三、需求评审之中

好了,接下来就是进入到正式的需求评审环节了。

那我先问大家一个问题,需求评审这个过程,到底是要参与人员传递哪些信息?仅仅是和相关方同步需求是什么吗?

当然不仅仅是这个,其实这里是有先后逻辑顺序的,需求评审要传递的信息主要是这三个方向,需求的价值和意义、需求具体是什么以及需求如何实现。

不要一上来就说,我要实现什么功能、达成什么目的、这个需求很简单、怎么实现我不管的这类话。

而是在整个评审会过程中,始终释放一个信号,让大家相信这个需求会有收益并且肯定能实现。

那具体怎么做呢?按照这四步走,可以帮助你可以更加从容地面对需求评审会议。

1、明确需求背景

我参与过一些合作部门的需求评审,发现有不少产品同事会忽略这部分,他们会直接进入需求是什么这部分,这并不是一个好习惯,还也会给研发同事一种被支配的感觉。

所以,开场白应该向大家介绍需求的背景是什么,也就是为什么要做这个需求,而且最好有数据说明现状是怎么样的,预计有多少的收益。这会给研发同事传递出信号,他们会感觉“这个需求是认真评估过的,而不是拍脑袋想出来的”。

举一个我最近组织的需求评审开场的例子,"最近我们和商业分析团队合作,定位了用户流失期间的商品转化变化情况,发现如果用户常买品的下单金额降低25%,那这个商户有84%的概率会流失。所以,经过线下的试点实验,把有流失趋势的用户核心品进行个性化促销,经过半个月的投放,数据表明实验组的流失率降低到37%,效果明显。所以接下来我们计划把这个项目推到全国范围,那就需要建设一个能够识别流失用户核心品,自动化投放营销能力"。

你瞧,有背景、有实验、有数据、有结果、有期望,可以说是有理有据,也能让大家知道这件事的来龙去脉了,只要彼此在认知和价值认可上达成一致,那这件事就好做了,毕竟强扭的瓜不甜,靠内驱和靠外界驱动,最终实现的效果可能是天壤之别。

这也就是所谓的“信息差”,产品经理每天和业务接触,会得到丰富的信息,那就可以多维度的来评估这个需求的合理性。而参与评审的其他人,之前是没有这些信息或者只有一部分信息的,就好比盲人摸象一样,从他们的视角来看,很有可能觉得这个需求是不合理的。

所以,介绍背景,补齐大家的认知,对于需求评审来说,十分重要。

另外,即使是老板提出的需求,也别直接说“这是老板让做的”,不仅很多研发都很反感这句话,而且大家也会觉得你这个产品经理能力可能不太行,缺乏自己的思考。所以,遇到这种情况的时候,需要去发掘老板提出需求背后的业务诉求,让大家明白需求有价值。

2、明确需求范围

当和研发同事在认知和价值层面达成一致之后,那就趁热打铁,开始讲述这个需求到底要做什么。

作为需求评审最重要的一环,这里也是非常讲究技巧的,在阐述需求的过程中,要先说从粗到细,先整体流程,再到具体功能,最后才是交互细节。

我相信大家都有同感,很多人都特别爱抠细节,如果一上来就直接说细节,那可能立刻引发多人的讨论了,反而会极大的降低评审的效率,造成了时间不可控的情况。

比如,我参与过几次和其他方向的联合评审,主负责的产品经理和设计同学、前端工程师,对于一个图标或者一种动画形式在会上争论不休,而且一旦开始抠细节,就会陷入怪圈,彼此在众人面前就都不愿妥协了,很难达成一致。

其实,这些只涉及到单方向的细节问题,往往可以会后下来再沟通的,这样既可以节省大家的时间,私下彼此的态度也会缓和很多,更容易换位思考,达成共识。

所以,切记,从粗到细,先让大家在脑海中有了需求整体的蓝图,再慢慢的沟通细节即可,而沟通细节这个环节,就可以放到下一环节了。

比如上文提到“实现自动化营销的能力”,首先需要在数据仓库获取流失的用户-商品关系,接下来把对应的数据传输到营销系统,营销系统根据规则进行适当的降价促销,最后再把数据传输到商城的对应模块,前端实现展示。这就是从整体的流程出发,涉及到数据仓库—营销系统—商城前端,让各个方向相关人员对自己的任务有个认知。

然后再重点和各个方向聚焦对于的细节,比如怎么获取用户-商品关系,按照什么规则进行促销,具体的展示形式是什么样的。

3、Q&A

需求评审往往会遇到很多问题,特别是需要多方合作的这种需求,更是大型"勾心斗角"的场面。有的会提出自己方向很难实现,有的会说需要依赖其他上游,有的会反馈没研发资源,还有那种直接硬刚质疑需求没意义的。

面对提问,首先不要慌张,也不要剑拔弩张。其实需求评审会议和面试很像,你面试的时候总不能硬怼面试官吧。所以,能回答的问题认真回答就好,比如需求的必要性、实现的交互、功能的优先级和必要性,都是可以讨论和评估的,以真诚换真心,那很少有人再继续咄咄逼人的。

同时,这里也要集思广益,如果其他人说的更有道理,那就要积极采纳意见,虚心接受。

对于回答不上来的细节问题,或者一时没想清楚的,那就暂时不回答,毕竟我们还有万能的话术:"你说的有道理,这个问题我没考虑到,下来我思考一下,然后再找你单聊"。

千万不要为了面子,强行编造个说辞,那反而会把自己处于更不利的境地,毕竟大家这个场景下,大家带着自己的诉求,出于完善需求的目的,一旦需求有破绽,同事很容易被盯着不放。

切记,在需求评审过程中,产品经理的职责不仅仅是把需求同步给各个方向,另外你还有一个角色是作为会议的主讲人,也要控制整个流程的节奏,杜绝让会议进入一小部分人抠细节、大部分人围观的状态,更不要让会议跑偏,聊一些不相关的内容。

所以,一旦发现有些同学开始抠细节,要及时制止,记下todo,会后小范围单独讨论。如果是跑通了,那更要及时将大家的注意力拉回到需求上来。

4、达成结论,输出会议纪要

当完成了上面三步之后,如果这个需求没有问题的话,那就要明确以下三点,当面确定好,防止后续扯皮。

第一,哪些事情要做,哪些事情暂时不做;

第二,每个部分的负责人是谁;

第三,大概交付时间是什么时候

同时,在群里或者邮件的形式再次告知大家需求评审会议结论以及待办事项,一般的会议纪要的形式是这样的,大家可以参考下:

会议纪要—关于自动化营销能力搭建的需求评审

时间:2022年5月10日,14:00-16:00

参会人:C罗、本泽马、贝尔、莫德里奇、克罗斯、卡塞米罗....

结论以及todo:

1、离线用户-商品关系数据有数据仓库@C罗提供;

2、营销系统的兼容和规则实现由@本泽马实现;

......

5、关于前端交互形式的细节待 @贝尔@克罗斯讨论后同步,时间在19:00之前;

以上,请各个方向评估产品和技术方案,在5月13日下班前完成内部评审,并同步排期,感谢各位。

四、需求评审之后

整个会议结束之后,算是完成了一场惊心动魄的面试,那到此就结束了吗?显然没有,面试之后你最好复盘和反思下,总结面试经验,思考自己面试过程中的不足,让自己下次能够发挥的更好。

所以,这时你需要处理会上遗留的问题,每一个都要输出个结论,形成闭环,同步给参会人员,因为很有可能这些问题会引发新的问题,那可能还需要进行小范围的二次评审。

直到所有的问题都搞清楚了,多方达成一致了,才能算得上需求评审告一段落了。

但是也不要以为就万事大吉了,需求评审只是整个过程的开始阶段,接下来要和各个方向确定开发和测试的排期,而且产品经理要及时的跟进需求开发进度,一旦遇到了风险要迅速反应,给出解决方案,同时相关人,确保需求能够按照计划正常推进。

说在最后

需求评审,就像是一场面试,不仅在考验我们的知识储备,也非常锻炼我们讲故事和随机应变的能力。

所以,每一场评审,都值得我们认真准备,因为这不仅仅能够让我们更好的深挖需求,了解业务背景,也能够为后续高效推进需求打下坚实的基础。同时也要坚持对每一次需求评审会议进行复盘,找到自己的优势继续发挥,发现自己的不足尽力弥补。

如果你按照上面提到的,评审之前的准备文档和预沟通,评审之中的同步需求背景、明确需求范围、细节讨论和输出结论,以及评审之后的确认遗留问题的流程进行了一场需求评审,那相信这大概率是一次成功的经历。

当你组织一次顺利的需求评审会议后,会让自己的信心倍增,也能积累研发对你的信任。那么久而久之,这个正向的闭环将会不断增强,逐渐你会发现需求评审会议对你来说也就变得不再可怕,而这时候你也就更能明白需求评审会议的价值了。


关于我:Cris,3年经验的生鲜电商数据&策略产品经理,公众号【产品人Cris】,希望链接到优秀的你。

]]>
https://coffee.pmcaff.com/article/pNBlm78mkA https://coffee.pmcaff.com/article/pNBlm78mkA Tue, 17 May 2022 11:48:51 +0800
<![CDATA[ 万字长文 | 十个模型,总结产品经理沟通方法论 ]]>

“大家好,我是阿境,人称产品界的吴彦祖,一个沉稳又不沉闷的男人。”

先问个问题

“作为一名产品经理,你真的懂得沟通吗?”

诶,先别急着回答,看完文章,再重新思考下这个问题。

产品经理在日常工作当中,不夸张地说,沟通几乎是占据了40%的工作内容,与运营沟通,与开发沟通,与用户沟通,与领导沟通等。

学会如何更高效率地沟通,能够使事情事半功倍,也能够有效地推动产品项目的运转。

同时,我们沟通时,会运用到一些方式方法,通常我们会听到“结论先行”“数据佐证”“说清背景”等等的一些方式。

这些具体的出处、来源又是哪里?

作为产品经理,在什么样的场景需要运用什么样的沟通方法?

这么一问,你是否对自己过往的沟通方式开始产生怀疑?究竟是随心而出,还是有一定的方法?

但并不是掌握了方法,就能够沟通无阻,毕竟沟通主要核心是内容,掌握了合适的方法只能够提升效率。

阿境将会先从沟通对于产品经理的作用引入,继而阐述市面上较为科学的沟通模型,再带入产品经理日常工作的沟通对象,与模型相论证,达到“方法+事例”的结合。

①附上本文导图框架,节约时间。若您感兴趣,可继续深入阅读;若不感兴趣,感谢光临。

②文末有阿境绘制的沟通方法论ppt,可公众号回复“沟通方法论”获取。

图片


一、为什么要学会沟通


很多朋友会觉得,不就是沟通吗?每个人都会。

厦门吴彦祖阿境告诉你:不是的。

学会说话不难,学会好好说话很重要,简单谈下为什么要“学会沟通”。

1、好的沟通方式能够节省很多时间。

2、作为团队的“润滑剂”,恰当的沟通方式能够避免许多不必要的冲突

3、有效率的沟通能够提高项目的运转效率。

另外,推荐几本书,不一定有用,但蛮看看总没错。《非暴力沟通》、《金字塔原理》、《影响力》、《关键对话》......

关注公众号:梦想家阿境,找阿境领取这几本书的材料。

但有一点说在前面,沟通的本质还是在于内容,不论是文章中提到的模型还是沟通实例,仅仅是抛砖引玉,套路永远都没办法横跨于优质的内容之上,愿谨记。

当然,如果你是长着一张跟厦门吴彦祖阿境一样好看的脸那就另说了,当这篇文章说的都是废话即可

(潜台词是,要什么沟通方式,有好看的脸就够了,相信阿境的朋友们都是好看的)


二、沟通模型

在市面上有很多关于沟通的方法及模型,阿境挑选出在产品经理日常工作/面试中会运用到的模型,总结了几个,供大家平时运用学习。

同时可关注公众号:梦想家阿境,找阿境领取总结后的这几个模型的ppt内容,加强学习。

产品经理工作当中,主要沟通核心在于“结构化表达”、“说服他人”、“沟通效率”、“沟通逻辑性”、“讲故事的方法”,所以阿境所选的例子也均为这些类型的模型。

要注意的是,阿境仅在该部分列举模型的内容,并不多加展开,在第三部分:产品经理沟通实例在通过具体引用的模型来展开可使用在哪些场景中。

1、PREP原则(结论先行)  


图片P-R-E-P(结论-依据-事例-重述结论)是沟通当中的重大原则。

P代指Point-结论,R代指Reason-依据,E代指Example-事例,最后一个P还是point-重述结论。

Point-结论,结论先行,是沟通当中的黄金法则。不论沟通对象是谁,双方在进行沟通之前,都不一定有明确的背景, 而此时,抛出自身明确的观点/结论至关重要,能够让对方清楚接下来的内容是围绕哪个观点来展开。

Reason-依据,在抛出结论之后,通过有效的数据,有力的事实验证结论的可靠性。通常我们在阐述依据的时候,往往会采用“我觉得”“我认为”“可能”“应该”这类不确定性且个人主观意愿很强的词语来阐述我们的论据,这是站不住脚的,同时也无法使得结论具有信服力。

减少形容词、副词的使用,通过数据、定理、模型等可靠的信息才能够作为可靠的依据。

Examle-事例,通过阐述可靠性的依据,较为枯燥。人脑对于形象的故事、场景类的描述接受度是较高的,通过事例,引起被沟通者的共情及想象。

Point-重述结论,通过事例,引起被沟通者的共情及想象。

通常PREP原则使用在书面沟通、语言沟通中。

2、FIRE模型


图片FIRE模型源于Mark Murphy的《用事实说话》,主要包括,Facts(事实)、Interpretation(解读)、Reacion(反应)、Ends(结果)。

总体来看,是注意到一些事实,并且对事实进行解读,根据解读的结果,经历情绪反应,期望得到我们想要的结果。

Facts(事实):事实是确实存在或发生的事情。它具有五个特点:具体、公正、客观、不带感情色彩和及时。事实是真实谈话的基础,通过事实,保持双方冷静,排除负面情绪所带来的影响。

Interpretation(解读):事件发生时,我们会对事实进行解读,从而得出这一事实的目的或意义。这些解读建立在个人的经验和知识上。有时它会迎合我们的喜好,有时它是带偏见的解释。因为事实和解读之间的差异,大脑不会总能察觉。

Reaction(反应):根据解读结果,我们会产生相应的情绪反应。

Ends(结果):经历情绪反应后,我们就会期望某种结果。

FIRE模型能帮助我们认清哪些是事实,哪些是主观想法。它最大的好处就是,当你听到一个难以入耳的反馈时,它能帮助你平静理性地展开分析,从而得到一个有效的解决方案。

为了更好地聚焦事实,我们脑海中需要有一张完整的FIRE模型,假设有一个表格,包括事实、解读、反应、结果。你看到和听到什么,就填在事实这一栏;对于这些事实,你是怎么想的,填在解读这一栏;你有什么情绪或感受,填在反应这一栏;你需要什么,或者你希望得到什么,就填在结果这一栏。

3、STAR法则


图片STAR法则是《高效培训》一书中所提出的概念,是结构化的一个重要理论,即Situation(情景)、Task(任务)、Action(行动)和Result(结果)。

Situation(情景)是所发生的事情的背景,在所阐述的事实中所发生的背景情况;

Tast(任务)是在背景环境下所承担的角色及所执行的任务,及要达成的目标;

Action(行动)是在任务当中如何去操作与执行任务的,重点是行动过程;

Result(结果)是付诸行动,完成任务后所达到的效果,一般是可量化的指标;

STAR模型代表着一个完整事件的四要素,也是基于此,通常在阐述事情的时候会使用,更注重行为,统筹帷幄,应对情景,是结构化叙事的原则。

通常使用在行为性问题和情境性问题的回答上。往往在面试、写简历等方面都会使用到。

eg: 在什么背景(时间,场所Situation)做过什么样的工作/项目 (Task), 这个工作/项目最好与所应聘工作相关,怎么做的,和谁一起做的,自己在团队中的角色(Action),最后的结果(Result)。

注:把「STAR 法则」当做一种核心思想,不追求生硬的表达,只追求在关键的时候,可以灵活运用

4、RIDE说服模型


图片

RIDE说服模型是指R(risk)风险、I(interest)利益、D(differences)差异、E(effece)影响,通过暴露风险,阐述利益,继而引入差异性及影响,来说服他人,即为RIDE模型。

R(risk)风险:不采纳方案会带来的风险。根据从人的失去心理入手,心理学家卡尼曼提出了“前景理论”:大多数人在面临获得的时候是风险规避的;也就偏保守的选择,而另外不同的是,大多数人在面临损失的时候是风险偏爱的,愿意为此冒险;人们对损失比对获得更敏感。基于此,需要将风险暴露给对方。

I(interest)利益:采纳你的方案会带来的利益。从之前的抛出风险,降低对方心理阈值,继而引入利益点,提高预期,会使对方更好地接受。

D(Differences)差异:自身建议与其他方案的差异之处。与众不同的点能够让对方眼前一亮。

E(Effece)影响:方案本身所能带来的负面影响。太完美的东西反而不真实,小缺点但瑕不掩瑜。

在这个过程中,也有几个注意点:

阐述风险时,可适当放大风险,但切莫过于夸张;

而在利益引诱时,稍微点出采纳了方案可获得的利益即可,让对方自己去对比,无需将利益说的过于肯定,因为此时有了风险与利益的强烈对比,表达便具有了冲击力;

在谈论到建议时,尽量结合事实,增加说服力;

而最后一步,瑕疵是为了避免太过于完美,为了增强信任度,也别阐述太多瑕疵。

还有一些加分要点:例如阐述观点前先认同对方观点;对话时助于多放在“你”上面;创造第三者引述别人观点等等,阿境这里就不再展开了。

整体来说,RIDE说服模型是利用人们心理“趋利避害”的天然潜意识,再加以对比的方式,使得更有说服效果。

5、SCRTV表达模型


图片

SCRTV表达模型是指Scene(情景)、Conflict(冲突)、Reason(原因)、Tractics(策略)、Value(价值);

穿起来则是:表情境-爆冲突-找原因-定策略-塑价值。

Scene:明确问题—是什么?

Conflict:提出疑问—怎么了?

Reason:分析原因—为什么?

Tactics:进行决策—怎么办?

Value:创造价值—成为什么?

通常我们在使用SCRTV模型时,符合人对于事情的体验路径:感观-情感-思考-行为-识别;

而人的思考路径是:是什么-怎么了-为什么-怎么办-成为什么?

思考之后,执行的路径是:分析-判断-推理-决策-评估。

而执行的路径,与SCRTV表达模型的契合度极高,这也就是为什么用SCRTV模型,在汇报工作、讲述方案的时候可以更有条理、更有逻辑叙述的原因。

6、SCQA表达模型


图片

SCQA模型是一个“结构化表达”工具,是麦肯锡资询顾问芭芭拉·明托在《金字塔原理》中提出的。

S(Situation)情景:由大家都熟悉的情景、事实引入。

C(Complication)冲突:实际情况往往和我们的要求有冲突。

Q(Question)疑问:怎么办?

A(Answer)回答:我们的解决方案是什么?

通过陈述场景,由大家熟悉且认同的事,引导大家产生共鸣及代入感,然后引出冲突的内容(往往实际情况与我们的诉求有所冲突及不符),继而从冲突方面提出大家所关心的问题,最后阐述解决方案。

我们在日常使用SCQA中,并不一定非要严格按照“S情景(背景)——C冲突——Q疑问——A回答(解决方案)”结构来进行表达,各个结构是可以调换顺序以显出不同的表达风格和情绪,一般可以分为以下4种模式:

标准式:(SCA)背景-冲突-答案

开门见山式:(ASC)答案-背景-冲突

突出忧虑式(CSA)冲突-背景-答案

突出信心式:(QSCA)疑问-背景-冲突-答案

这边对于这几种方式不过多赘述,有兴趣的可以看看《金字塔原理》这本书。

7、沟通漏斗


图片

沟通漏斗是,心里所想的是100%,由于沟通方式,所表达出来的只有80%,由于过程中的干扰因素,别人听到的只有60%,由于每个人理解能力不同,听懂的只有40%,由于执行力不同,行动的只有20%。

最终,当我们想得到100%的结果,最终实行的结果只有20%。

这也诠释了,沟通保证不失真的重要性。

而我们也可以通过一定的方法保证失真的最小化。

在第一个20%,源于没有记住表达内容的重点,条理混乱等,由此我们需要理清自身所想阐述的内容,无一遗漏且结构性有条理地表达。

第二个20%,源于阐述时有外界干扰,内容过长等,由此需要在这个过程中逐步记录,避免干扰。

第三个20%,源于个人理解能力不同,由此需要不时向对方确认是否听懂,是否有其他想法等,引发对方思考从而得知是否完全理解。

第四个20%,源于没有对过程进行监督,导致执行力无法达到预期值,由此需要建立监督体系,把控任务进度。

8、乔哈里视窗


图片

乔哈里视窗,是由乔瑟夫和哈里在20世纪50年代提出的,是用来改善自我认知与组内个体之间的相互理解。将沟通的信息比作一个窗子,它被分为4个区域:公开区、隐蔽区、盲目区、未知区,人的有效沟通就是这四个区域的有机融合。

公开区:自己知道,他人不知道;往往关系越近、共同信息知晓越多的两个人公开区域会越大。

盲点区:自己不知道,他人知道;在很多情况下,我们都会有盲点区,自身的学识、所出的环境等等都会造成我们与对方所了解的信息不对等。

隐秘区:自己知道,他人不知道;造成隐蔽区的原因在于我们不好意思跟其他人说、忘了对其他人说、没沟通清楚造成误解、误以为别人知道等等原因。

未知区:自己不知道,他人不知道;也被称为“潜能象限”,每个人都有未知的区域等待被发掘。

在这四个区域当中,往往在产品经理岗位中能够得到比较大的启示则是“盲点区”、“隐蔽区”与“公开区”的转化关系。

而简单地说,从乔哈里视窗看来,也有几个在PM沟通中能遇到的问题。

“你所阐述的内容,和别人听到/理解的,很可能不一样”

“增加公开区的面积,学会向上管理,更好的利用资源”

“工作中减少隐蔽区,避免信息不对等”

9、电梯演讲


图片

电梯演讲源于麦肯锡公司检验陈述报告的方法之一,而麦肯锡认为,一般情况下人们记得住一二三,记不住四五六,所以凡事要归纳在3条以内。

而三个步骤分别是:Hook吸引→Mutual Benefit给利→Call to Action收网。

Hook吸引:通过现状、存在问题、现状产生原因、解决方案等吸引对方注意力;

Mutual Benefit给利:提出具体解决方案,让对方意识到你的价值存在;

Call to Action收网:指出上述方法的依据及理由,并留下联系方式;

这是在众多商界当中流传的三个主要步骤

要注意的是,这框架并不是固定的,有典型的“提出问题-产品价值阐述-产品解决方案”的三段式,也有“痛点-解决方案-商业计划”的电梯演讲。

而对于产品经理,在介绍自身的产品,为了说清楚产品本身的价值,有更完整的方式。

为了[目标用户],他们的[痛点或者问题],我们的[产品名称]是一个[产品类型],它能够[产品价值],不同于[竞争对手],我们的产品[竞争优势]。

10、GROW模型


图片

在部分产品经理领域当中,当我们“一不小心”当上了领导,往往在于下属沟通的时候,会不自觉用命令、说教的方式去沟通,反而会得到适得其反的结果。而辅导沟通的方式之一是“用提问代替说教”,这样可以引导对方自己找到问题的解决方法,有效的避免对方产生抵触情绪,达到沟通顺畅,辅导有效的结果。

那么,该如何提问呢?可以采用GROW模型来进行提问。

GROW模型分为四部分,Goal(目标)、Reality(现实)、Option(方案选择)、Will(确认行动)。

Goal(目标):通过提问,探索对方的目标,通过对方的思考跟表达,让对方也清楚自身的目标。因为往往很多人在做事情之前,由于种种原因(思考,岗位,精力等)仅停留在执行层面,没有办法清晰条理地思考。

常见的问题有:这件事/你的目标是什么?如何衡量达到了这个目标?什么时候可以达到这个目标?

题外话:至于目标的阐述,可以采用SMART模型,这边不再过多赘述。

Reality(现实):通过阐述事实情况,了解达到目标/完成事情需要遇到的阻碍及困难点。

常见的提问有:现实情况如何?目前的背景涉及到哪些干系人,有什么态度?目前我们是怎么处理的?

Option(方案选择):通过提问,引导对方自己想办法,通过思考,提出自身的解决方案。相反,不建议直接提建议,对方可能产生抵触情绪,在潜意识容易丢弃解决问题的责任。这个阶段最重要的倾听,需要多加评判,引导对方多思考几个方法。

常见的提问有:要解决这个问题,你觉得如何做呢?还有别的方法吗?这个方案有没有什么优缺点?

Will(确认):最后一步是确认行动,根据前三步的铺垫,已经寻找到了解决方案,但由于种种原因,可能没有办法保证100%的执行。

常见的提问有:你选择哪个上述哪个方案呢?这个方案的时间、目标、准确执行是如何?目标中产生的困难有理清了吗?

由此,通过GROW能够使辅导沟通更加顺畅。切记,抛弃说教,与对方同一角度思考。


三、产品经理沟通实例


首先,了解了产品经理当中我们可以看到,日常要沟通的角色包含但不仅限于运营、技术、测试、客户、老板、下属等,沟通的角色之多,也难免“沟通能力”作为一个软技能,被视为如此重要。

下面就从几个沟通实例,来阐述下与各角色的沟通方式。

注:并不包含所有的场景,仅列举几个高频的沟通场景,再阐述该场景下的相应沟通方式;朋友们可举一反三进行深究。

1、与运营沟通

在于运营沟通的时候,会遇到的问题是:

①运营思维与产品思维不一致,导致思考需求的方向点不同,各有各的立场

②有时候运营提需求无法完善,探讨需求效率较低

......

在互联网中项目中的各岗位,从乔哈里视窗来看,产品与运营的公开区的比重是比较大的,但仍然有部分的盲点区及隐蔽区。

而运营与产品通常与产品的沟通场景是需求沟通较多。

当两者需求沟通意见不一致时,产品经理往往需要让运营更好地接受我们这一侧的想法,可采用SCRTV表达模型

同时,在运营提出需求时,也可引导其采用SCRTV表达模型来进行,从而更好地向产品经理阐述需求:表情境-爆冲突-找原因-定策略-塑价值。

通常更多的是了解对方遇到的问题,常用的沟通语言是:

“你的问题是什么?”

“你的这个方案要解决什么问题呢?”

“如果当前方案无法实行,那么你们是采用什么方式进行处理的?”

......

而当运营提出需求时,针对优先级、紧急程度、需求内容有对立意见时,产品经理并不是一昧地进行反驳,而是用事实,用数据说话,可采用FIRE模型

2、与开发沟通

与开发沟通的过程中,高频的沟通场景是沟通需求,往往会遇到几个问题。

①与开发的思考方式不同,产品经理关注产品发展,开发关注实现方式

②开发说技术语言,产品经理说产品语言,导致理解不同

③需求变更时没有及时周知,导致信息遗漏或滞后

④产品觉得需求简单,开发觉得实现难,知识的不互通导致信息不对称

......

产品与开发这两个岗位是区别较大的,从沟通上来说,符合乔哈里视窗的盲点区与隐蔽区。产品经理与开发的知识域差别较多,容易造成“我理解,你不理解;我不理解,你理解”的这种情况。

为了避免盲点区的越来越大,产品经理应该多了解技术基础知识,但并不是了解技术细节,而是基本的技术点,为了更合理的设计产品产品,也更好地跟技术沟通,但不越俎代庖,干涉技术实现细节,毕竟术业有专攻。

而隐蔽区的形成,源于两者思维方式不同,平时沟通需求时,注意沟通的表达,明确双方所表述的内容是一致的意思。

同时,在跟开发沟通需求/bug的时候,通常我们需要结构化表达,采用SCQA表达模型中标准式(SCA)的沟通方式:背景(S)-冲突(C)-答案(A);

eg:当前帖子加载速度过慢(S),但采用原生化比采用H5形式的成本更高(C),所以我们考虑从拆分接口的方式尝试下(A),你有没有什么更好的建议?我们探讨下

很多产品与技术沟通的时候直接抛出方案,而没有背景,虽然技术是执行者,但如此方式容易造成对方的抵触心理,同时要让开发从心理上认同做事情的价值。

而在抛出需求之后,往往产品经理觉得简单的需求,开发评估觉得难,这时候容易滋生矛盾。这个时候需要使用非暴力沟通的方式:观察-感受-需要-请求。表达感受,尽量不表达情绪跟想法,同时与开发聊需求的背景,优先级及重要程度,请求对方协助,以此达到解决问题的方式。

总结一下:

①减少个人盲点区的范围,多了解技术基础知识;针对于隐蔽区,注意双方沟通表达内容。

②结构化表达,采用SCQA表达模型,把开发当成伙伴而非技术实现工具,与开发探讨合适的方案。

③遇到问题及需求变更分析后再提交给开发,有需求变动及时周知及阐述背景。

④需求变更时,采用非暴力沟通的方式,达到解决问题的目的。

3、与交互/设计/测试沟通

在于交互、设计、测试这类角色的人员沟通时,首先要明确他们与产品经理的关系。

通常都是产品经理是交互、设计、测试的需求方,往往产品提出需求,交互出交互稿,设计出设计稿,测试进行测试功能等。

于是,如何更准确无误地提出需求、验收需求的沟通这两者就是比较高频的沟通场景。

在提出需求的时候,有的PM会直接提出方案让交互、设计师去执行,而不论是原型设计还是UI设计,都是离不开内容的,明确当前存在的用户问题及用户场景是更为重要的。

采用SCQA表达模型,不论是(SCA)背景-冲突-答案,还是(ASC)答案-背景-冲突都是合适的,最主要的是阐述当前存在的问题,用户场景,继而在引出我们个人的方案想法供交互、设计进行参考。

而在我们验收需求的时候,往往无法一次定稿,那么就需要修改。当我们作为外行的角度,进行验收内容时,切忌“外行指导内行”,记得尊重专业,同时可也阐述我们的想法,若想要说服对方,可采用RIDE说服模型,通过我们自身产品的敏锐度对于方案的评估,指出风险及方案的差异,从而阐述影响点,以引导设计师修改出合适的方案。

总结一下:

①提出需求,需结构化表达,从SCQA表达模型出发,阐述问题背景与用户场景,继而才是解决方案。

②针对于方案进行探讨时,尊重专业,也可采用RIDE说服模型,引导对方修改出合适的方案。

4、与老板/领导沟通

在与老板/领导沟通时,我们需要把握对方的预期,同时也会遇到一些问题

①汇报工作时,拖拖沓沓,讲了一大段,但不清楚主题,内容是什么,毫无重点

②讨论需求时,往往对方有自身的考虑及想法,无从下手去进行说服他们改变想法

......

通常在与领导/老板沟通的时候,我们会面临几个高频沟通场景:汇报工作、讨论产品需求、说服领导改变想法等,听阿境娓娓道来。

1)汇报工作

当我们在汇报工作时,通常采用PREP表达方式,也就是结论先行,不论是口头沟通还是书面表达,优先阐述结论,让对方了解事情概况,再通过依据、实例描述内容,最后重述结论。

eg:对于社区的优化,采用帖子新增话题的方案(P),通过数据来看,话题在其他模块的渗透率达到15%,互动情况也占据内容的10%(R),同时从竞品及用户调研来看,话题是用户较为关心的内容(E),所以最终考虑采用了帖子新增话题的方案(P)。

当然,不仅仅是用在与老板/领导沟通的时候,与其他角色沟通方案均可采用PREP表达方式。

2)说服老板/领导改变想法

老板/领导的决策也会有不确定的时候,而作为产品规划者,我们需要指出决策的错误,从而说服老板改变想法,此时可以采用RIDE说服模型与其沟通。

而RIDE说服模型是指通过暴露风险,阐述利益,继而引入差异性及影响,来说服领导。利用趋利避害的潜意识,加以对比提高说服的成功率。

eg:这个方案一的风险可能导致社区的留存率降低5%,用户也会因此大量流失,据评估,这可能导致产品收益降低8%(R),我们可以采用保守点的方案二,虽然无法提升社区的用户数,但可以保证留存率不降低,同时在这个基础上增长产品收益(I),方案二与方案一对比,用户体验会稍微差点,但是我这边有考虑了几个折中的方式可以看下(D),当然,方案二的时间成本也会较高,但影响不大。(E)

总结一下:

①采用PREP表达方式汇报工作,精准描述内容,思路清晰,重点明了

②通过RIDE说服模型与领导进行方案的沟通



5、与下属沟通

当我们摸爬滚打一段时间后,可能在产品团队中作为领导,就避免不了需要与下属长期反复的沟通。通常也是会遇到如下问题:

①领导做决策,下属接到任务及需求,做的不情不愿,一脸蒙圈

②布置任务时,没有背景,没有前因后果,缺少元素(内容,截止时间等),导致完成效果不如预期

③信息传递有递减,导致任务完成效率低

......

由于位置的不同,导致上下级思考的方式也不同。

而在与下属的相处中,布置任务、沟通工作是较为高频的沟通场景。

在引导下属去做某个任务时,避免单方面进行决策,而是与下属一起探讨,而为了有效沟通,我们可以采用GROW模型与下属进行沟通

通过提问了解做需求/任务的目标,引发对方思考,从现实层面入手了解实施的困难点,再提出自身的解决方案,此时需要引导对方多进行方案的思考,最后商量一个合适的方案,进行确认方案的实施,保证有效地进行。

eg:项目的社区模块需要进行改版,你觉得我们改版的目标是什么呢?如果改版成立的话,我们会遇到什么问题嘞?如果这个方案还有缺陷的话,我们再考虑下还有没有其他更优的方案。如果这个方案要实施,你准备怎么做呢?

如果是较为明确的任务,那么在步骤任务的时候,需要说清楚任务的几要素:背景、干系人、当前进度、任务内容、完成时间。

同时,通过沟通漏斗我们可以知道,沟通若断层,效率则减半,在这个过程中需要跟对方确认是否听清楚了任务并且理解,若不理解则需要再阐述清楚。

总结一下:

①让下属得到参与感,通过GROW模型进行引导式沟通

②布置任务说清楚任务要素

③保证信息传递的完整性,同时减少沟通漏斗带来的影响

④保持激励

6、与面试官沟通

与面试官进行沟通时,内容较多,这边仅简单提下,点到为止。后续会用整篇文章来单独阐述。

较多的沟通场景是向面试官展示个人做过的项目,也就是个人过往成就。

我们通常采用的方法是采用STAR法则阐述个人成就,能够更表现自己分析阐述项目的清晰性、条理性和逻辑性。

eg:在什么背景(时间,场所Situation)做过什么样的项目 (Task),怎么做的,和谁一起做的,自己在团队中的角色(Action),最后的结果是什么。(Result)。

在这里面要注意的点是,阐述项目的结果(R),以数据来阐述会有较多说服力。

由于文章仅概述沟通方式,阿境在这边就不过多展开面试的技巧,有兴趣的朋友们可关注阿境公众号:梦想家阿境,一起交流。


四、一些可能有用的Tips

1、明确双方所表达的语义是否一致,掌握好措辞;若不一致需及时了解,打破双方误解。

2、结论先行,也就是PREP原则的核心思想

3、阐述事情先讲背景,再讲内容

4、在沟通之前,明确此次沟通的目的,了解所沟通对象的诉求。

5、不论沟通对象是谁,结构化表达,能让对方更好地理解你说的话。若当面沟通无法阐述清楚,则预先打个腹稿或者以文字形式输出。

6、切莫自己一顿疯狂输出,也记得倾听对方的想法及方案。

7、区分哪些是真正的事实,哪些是对方/自己解读后的观点,基于客观事实和行为模式是寻求真相谈话的基础。

8、前面几点均为“可能有用”,不一定适用于所有人,跟着合适自己的方式走即可;如不适用,将其全部忘记即可。


五、写在最后

作为产品经理,沟通的重要性不言而喻。

而阿境说了这么多,阐述了这么多所谓的“模型”,当你看到这里时,若脑子当中都是生硬的沟通模型,那么其实并没有达到这篇文章的目的。

固然,沟通模型能够让人逻辑清晰,条理通畅,但在沟通的过程中,我们并不需要被困顿于模型当中,而是能够活学活用。

(可公众号回复“沟通方法论”,获取文中的ppt原件。)

本质上,沟通模型也是思维方式。

前期通过刻意地训练“模型”中所要传达的表达方式,从而提升我们思考问题及与人沟通的思维方式,继而加强沟通的效率,节省沟通所付出的时间成本。

张三丰教张无忌太极剑法时有这么一幕场景,起初,张三丰打了一遍,问张无忌,记住了多少。无忌说,记住了八成。又打了一遍,问他,记住了多少?无忌说,忘记了一半。最后一遍,他说全忘记了。张三丰此时说“很好,你已经大彻大悟了”。

恰如其分沟通方式绝不是死记硬背模型所得到的,沟通方式、沟通模型仅仅只是招式,最重要的还是沟通的内容,切勿舍本逐末。

谨记,共勉。

图片

阿境,产品界的吴彦祖,一个沉稳又不沉闷的男人。

野蛮生长,产品汪一枚,做过游戏、电商、医疗、教育行业项目,4399产品经理。

坚信"产品源于生活",欢迎交流。

公众号:梦想家阿境

]]>
https://coffee.pmcaff.com/article/j5L4wzK8kg https://coffee.pmcaff.com/article/j5L4wzK8kg Thu, 12 May 2022 15:25:24 +0800
<![CDATA[ 原型绘制提效技巧分享 ]]>

不管是前台PM还是后台PM,在工作中或多或少都要进行原型设计。原型可以说是产品、开发、测试之间进行交流沟通最重要的文档之一,那么怎么把原型画得又快又好呢?

从设计流程上看,原型设计节点包括但不限于梳理需求大纲、规划页面结构、完善信息结构、绘制原型及进行说明标注。前面三个节点个人有个人的方法,今天主要想和大家分享一下后两个——绘制原型及说明标注的提效小技巧,希望对你有帮助。

一、制作全局说明

通俗地说,全局说明就是那些你懒得写第二次的东西。比如说网络异常/加载失败/没有数据,这些这是任意页面都可能会碰出现的情况,如果分开写,每个页面都要写一次,改的话得同时改很多地方,费事费力而且不利于需求的统一管理。所有,把这些通用性的东西写在一个地方,既可以简洁原型文档,降低开发、测试、设计等人员的阅读成本,又可以少写点字,何乐不为呢(๑•̀ㅂ•́) ✧

全局说明可以是适用于全文档的,也可以是适用于某个迭代的。像是一些和迭代相关度高的名词解释。写在全文档性的说明里就有些冗余,写在迭代内全局说明中就刚刚好(个人见解)。

根据通用性,可以将全局说明分成两种:通用说明和业务说明。通用说明是在大多数产品/页面内都可以通用的,比如页面状态、加载状态、通用手势、弹窗遮罩等;而业务说明则不同,这类说明和业务高度相关,相同内容在不同业务间有较大差异,比如时间展示规则、昵称长度等。下面给大家举几个栗子:

通用说明

移动端全局说明具体可见浪子写的文章,很详细(查看)

1d8e50dd4c843f85773d8c9d770d9fab-picture

业务说明

  • 最近一条消息时间展示规则

图中是微信的展示规则。手动试出来的,不对的地方欢迎指正

bac9894ae74e58682f632da90acbe046-picture

  • 最近一条消息展示规则

图中微信的展示规则。手动试出来的,不对的地方欢迎指正

1f4ff084f72f2d96dccdc7ebf3fba5ea-picture

  • 产品上架/下架/浏览时间展示规则

第一版设计的规则里跨年时间也是带「时时:分分」的,后来因为产品列表地皮实在放不下,就把后面的具体时间砍掉了(都跨年了,具体时间没那么重要了叭)。所以具体的展示规则是和实际系统密切相关的。

a4542ff00111baf6fbaf40e0b11a786e-picture

二、建立字段说明表

可以把用到的数据用表格的形式罗列出来,清晰且一目了然。

09287c77dedd9dbbbbcd72a2a4a839e3-picture

84d178477822bb754915d19150624447-picture

三、取用元件库进行原型绘制

在绘制原型时,有一些控件会被经常用到。如果每次用到都重新制作,不仅无法保证交互效果的统一性,而且会占用很多工作时间。为了咱岌岌可危的发际线,我向大家使用Axure元件库功能。

什么,你说Axure自带的元件库丑?

网上有不少大公司的设计的元件库,找个你喜欢的导入就行。比如蚂蚁金服、饿了么、有赞

什么,你说懒得找?

那我这给大家推荐几个。

Vant 移动端组件库

非常全面的一个组件库,自带交互。除了通用组件,还有带有电商业务组件,用来绘制移动端原型很方便。

设计网站:Zan Design (查看)

资源下载:Zan Design 移动端元件库

094fc0473166d9f9427b4748cecbac7a-picture

Ant Design 移动端组件库

支付宝风格的组件库,组件没有Vant那么多,但是通用性强。

设计网站:Ant Design (查看)

资源下载:Ant Design 移动端元件库

48709540372345de446e66cd727591a4-picture

Ant Design 后台组件库

这个不用多说了吧,后台产品必备。UI 样式可配置,拓展性强,大多数产品风格都能轻松适应。

设计网站:Ant Design (查看)

资源下载:Ant Design 移动端元件库

198061045e5b57cfd1e0d0574aacb3cf-picture

大厂设计的组件库当然不错,但是用起来也会碰到一些问题。比如和自己的设计风格不一致呀,有无用的组件呀,部分组件需要微调等等。所以建议每个PM都自己积累元件并长期更新。不用一次完成,平时工作中碰到新的就维护进去,这样不会占用很多时间,而且可以保证原型整体的视觉统一。

我司后台部分用的是蚂蚁金服组件库,基本不用修改,所以没有制作元件库。APP端因为有些特殊组件,通用组件库里没有就积累了一些,基本是Ant Design 和Vant 的混合版,这里就不献丑了.....((/- -)/

四、建立交互需求说明库

如果系统用的是某个开源的UI项目的话,组件的交互基本都是确定好了的,交互说明文档可以少些甚至不用写。如果没有用开源项目,所有的轮子都是百度或者自己造的话,那交互说明文档就必不可少了。碰到一些常见、使用频率高的组件,可以建立一个“交互说明库”,用到的时候贴一个链接或者copy一下,可以减少开发的理解成本。

PM或多或少会碰到被开发围攻的情况,大部分情形可能都是因为需求描述不准确导致的。如果有一个规则模板参考,是不是就可以减少遗漏的情况呢?

需求说明基本分为三个部分:需求说明、交互说明、交互预览。

  • 需求说明一般包含:前置事件、后置事件、初始化、加载/分页、排序、正常和异常结果等,具体看组件类型;
  • 交互说明一般包含:不同组件的说明会有较大差异,如果想描述得很详细,可以参考开源项目的API文档;
  • 交互预览一般包含:输入状态/选中状态/聚焦状态、禁止状态、加载状态等等。

86aca52cfc7e3690b96cd5e27a978f8e-picture

五、进行交互自查

输出完后先对照交互自查表把每个细节梳理一遍,让原型更加更加全面和缜密。

自查表是之前存的,忘记是哪篇文章了。如果你知道的话欢迎补充~

需求类型

检查模块

自查问题

自查结果
(示例)

辅助理解举例

前端需求
(用户能得见的需求)

前置判断
(进入界面时的判断)

是否考虑不同账号的区别

银行App上【我的】页面:已注册账号与游客账号展示差异

是否考虑不同权限的区别

流程审批的界面,审核者权限有审核与查看按钮;但提交者,只有查看按钮

是否考虑同账号不同时间进入的区别

同一个用户晚上登录自动开启夜间模式,如读书类App

是否考虑同账号不同状态的区别

同一个用户也会有前后状态的差异。如优惠券列表,领券前后;活动页面,达标前后

展示内容

展示逻辑

是否考虑内容为空显示什么?

用户的购物车为空的时候,该如何展示

是否考虑横竖屏问题

微信公众号横屏和竖屏查看情况下的兼容

是有有考虑单位/计量单位/位置的统一

积分商品的价格,是统一用:99元+100积分,还是:¥99+100积分;积分价在前还是在后

是否考虑文字过多的换行或者....

商品列表页,商品名称过长的展示处理方案

是否考虑特殊符号、敏感信息的处理

部分场景,用户手机号展示需要脱敏,如加上***

排序逻辑

是否考虑内容排序的逻辑:时间/热度/相关度

优惠券列表,以用户获取时间还是附近可用的优惠券

是否考虑内容展示方式:翻页/瀑布流

电商商品的为你推荐区,一般使用瀑布流的方式

刷新逻辑

是否考虑刷新方式:是自动刷新还是手动刷新

支付宝首页的信息览,用户可手动下拉刷新

是否考虑刷新数量:一次刷新多少/多久,如何刷更多

交易记录页面,上滑动刷新最多拉取数据库8条信息,最久能够拉取到近3个月的数据

是否考虑刷新异常:当刷不出新内容时提示什么

刷不出内容,页面提示已经到底啦~已经是最新数据啦~等

缓存逻辑

是否考虑页面的缓存数据,存储地方

表单类录入产品,出现返回上一页面操作时,当前页面信息也需要保存

是否考虑缓存触发场景,清理数据逻辑

当下操作场景信息对用户很重要,或对平台校验、分析有用时,需要缓存

用户操作

跳转操作

是否考虑返回:如物理、home键、侧边栏返回

不同的返回按键需要考虑到与用户预期一致

录入操作

是否考虑录入的进度提示

表单填写信息较多时,会给用户展示进度条

是否考虑录入时候的控件变化

输入框,录入时候边框高亮展示

是否考虑录入的结果反馈

录入信息不正确,toast/页面引导用户正确录入

查询操作

是否考虑查询中的状态提示:loading、进度

输入准考证,查询成绩单过程的进度条展示

是否考虑查询结果的展示:查询中/成功/失败

百度搜索查不到相关信息场景下的猜你想查

异常场景

操作异常

是否考虑用户连续操作异常的情况

连续5次输错手势密码要求验证用户身份

是否考虑用户高频操作的禁用逻辑

连续用户连续点击优惠券领取按钮提示:你已经领取过啦/优惠券置灰不可点

网络异常

是否考虑没网场景下的页面提示

支付宝无网络状态下的提示:当前网络不可用,请检查你的网络设置

是否考虑弱网场景下的页面展示

网络太慢,建议用户切换网络

是否考虑网络差,重新加载的按钮

当页面加载不出来,给用户提供重新加载按钮

版本异常

是否考虑新旧版本兼容/强制更新/显示版本更新提示

功能需要最新版本才能体验到,需要引导用户更新版本

接口异常

是否考虑接口异常:查不到数据的情况

服务器挂掉了,功能不可用情况下的页面提示

其他

数据埋点

是否考虑页面埋点,增加操作行为上报

页面的PV/UV,按钮的PV数据上报,方便数据分析

新手引导

是否考虑新手引导,方便新用户了解新功能

人人都是产品经理App上的新功能引导:朕知道了

后端需求

数据处理

新增字段

是否考虑新增字段后,新老数据如何兼容

商品表增加了积分价字段后,在查询时要对老数据进行特殊对兼容处理

系统迁移

是否考虑升级服务器后,老数据如何迁移:全量/增量

系统升级后,用户历史的积分交易数据也需要同步迁移过去,

数据更新

是否考虑数据的更新机制:更新频率/更新方式/更新量

对方系统推数、还是主动拉取,多久更新一次,更新是增量还是全量

系统解耦合

是否考虑单个接口已经包含足够的业务功能

会员查询,应该尽可能将会员相关的信息通过一个接口查询出来

性能保障

是否考虑系统的性能:支持多大的并发量

秒杀功能,订单系统支持多大并发量

权限考虑

是否考虑权限的拆分:查询、编辑、审核等

积分管理后台,业务配置和财务对账区分用户角色

异常场景

是否考虑业务流程异常情况的处理

订单取消后,用户支付已取消订单成功会怎样

数据需求

数据埋点类

必要性

是否以真实的业务分析需求提交埋点位置

不以实际分析需求出发的数据埋点都是不负责任的

完整性

是否包含用户、页面、行为、区域、内容,来源等信息

数据埋点都会把用户的设备信息、操作行为、操作时间、页面、具体位置详尽记录

可追溯

是否埋点之后可以追溯用户的上一级页面来源

无法追溯来源就分析漏斗,难以看出转化效果

数据报表类

数据时效

是否考虑不同表之间数据获取差异而设定跑批时间

过早的跑批时间,会导致有数据依赖的表无法获得数据

数据安全

是否有考虑敏感信息应该脱敏处理

姓名、手机号、身份证号一般会进行加密,如哈希加密

数据获取

是否考虑所需数据字段已经从业务库下传至数据仓库

数据未下传无法满足数据报表需求,因此首先要确认

好了,以上就是个人平时画原型积累的一些技巧和感悟,完全是出于个人习惯和主观经验得来的,可能不太对,如果你有补充或者不一样的看法,欢迎一起探讨~

参考文章
1、浪子,善用Axure写PRD,全局规范一个都不能少

2、交互设计自查表


]]>
https://coffee.pmcaff.com/article/a1LR8D9xBZ https://coffee.pmcaff.com/article/a1LR8D9xBZ Thu, 12 May 2022 09:51:00 +0800