洞察业务模式,我们就能理解企业决策的考量因素
把控用户需求,避免被用户牵着鼻子走。
业务模式反映的是企业的业务如何开展。比如如何获取资金、如何盈利,以及如何控制风险等等。
1、业务模式的洞察
对于厂家,往往需要大量运营资金,用于采购固定资产并规模化生产。这使得他们往往是负债经营,拥有较高的资金成本;同时,每个月巨大的现金支出(比如工资和材料采购款),使得生产厂家非常注重坏账的控制:
相对于经营亏损,更大的风险是现金流枯竭。
而经销商大多属于小微企业,仅负责特定区域的商品分销工作,资金需求相对较小;同时,由于顾客大多为合作多年的小店,因此坏账的风险相对较小。但是,市场充分的竞争,使得经销商只能通过低毛利、高周转的方式获得利润,因此经销商对毛利率非常关注。
曾经我在一家快消品SaaS公司担任高级产品经理。有一天,公司提出需要推出微信支付功能,我马上敏锐的意识到,这个功能更适合快消品厂家,但是并不适合经销商。
微信支付虽然降低了现金流的风险(微信收款使得偏远地区的收款更加容易,也避免了业务员持有大量现金),但同时降低了毛利率(对公支付有不高于千分之6的手续费)。最后,通过用户调研,确认了我的判断,这样就避免了研发不必要的功能。
2、用户心理的洞察
用户心理则反映了用户的愿望和担忧。
洞察用户心理,能帮助我们拿下订单,搞定干系人,顺利推进项目!
用一句非常经典的话来总结,就是:买得起、买得到、乐得买。
那么接下来我要说的是:0-1阶段系统架构初步优化性,每一步目的是什么?
一个系统从0-1大致会经历这几个步骤:
一、项目背景
二、商业模式(如果涉及)
三、核心业务流程
四、业务流程
五、涉及到系统
六、涉及到角色
七、涉及到实体
八、涉及到策略
九、系统架构
十、功能清单
十一、规划排期
十二、针对功能细致的流程、功能、原型的设计
一、项目背景
先思考:我们做系统为什么要做项目背景?
1)为了把握方向,别偏了呀
2)理清资源和限制,别超纲
3)思考理清项目的关键点
比如:我们要做一个电商系统,为什么要做电商系统呀?解决什么问题呀?有什么资源呀?有什么限制呀?这个项目如果要成功,那些点是关键点,是必须要要解决的呀?
把整个项目背景捋清楚了,我们做到心里有底。如西游记:我们要去西天取经,为了大唐百姓安康幸福。我们有齐天大圣这个能打的,也有唐僧肉身凡胎,要想把西天的真经取到,就必须解决取经路上的各种各样的妖怪。
二、商业模式
先思考:为什么要做商业模式?
1)比项目背景更细一点的掌握方向,明白我们设计系统的重点。
比如:拼多多,最初的商业模式可能是以廉价的商品去打开下沉市场,让更多对质量和品牌要求不高的人在系统上购买廉价的商品。这样我们就清楚我们在设计系统时的重点放在哪?我们应该减少商品的品牌漏出,突出价格优势,做一些占小便宜的设计等。
三、核心业务流程
先思考:1)为什么要做核心业务流程;2)应该做到什么程度?
明白我们主要是做一件什么事情?其他的工作都是围绕着这个事情做支持和服务的,以这个事情为中心向外延展扩散我们要做的所有的事情,找到一个主的前提。同时也是我们做版本规划的一个依据。
做到什么程度呢?做到可以验证商业模式能不能走得通就可以。
比如:抖音的核心业务流程就是:创造者创造视频-发布-内容消费者观看视频。其他所有的事情都是围绕着这个核心来做。
四、业务流程
先思考:为什么要做业务流程?
1)梳理出我们这个项目要做的所有的事情,定好我们的蓝图;
2)保证我们不会遗漏业务;
3)确定业务流程是正确的,无误的,防止已经开始做了,才发现业务流程错误;
4)为后来我们梳理系统、角色、实体、策略做基础
五、涉及到的系统
先思考:1)为什么要梳理涉及到的系统?2)应该做到什么程度?
1)确定需要的资源,有利于我们后期的工作人员安排
2)梳理整体信息架构
做到什么程度呢?
如果你的项目全部都是新系统,我们只需要罗列出系统以及系统主要承担的责任即可。如果你的项目还设计到原来的老系统,则需要列出我们需要和老系统做什么交互,需要老系统怎么配合?
这里说一个小知识点:如果涉及到的系统不是你负责的,在系统交互的时候,要按照对接第三方的标准去做,思考交互的部分,有没有一些限制?具体的字段,包含字段的限制和格式,是否必填,是整数还是小数。很多时候就是以为是一个公司的没那么认真,上线了就发现各种问题。
六、涉及到角色
先思考:1)为什么要梳理涉及到的角色?2)应该做到什么程度?
1)有助于我们后面按照角色梳理功能
2)分析角色的不同状态,也有助于我们设计系统的时候考虑的更加完善
3)有助于我们设计权限和账户体系
做到什么程度呢?
分析出所有的角色和角色的状态。这一步很多人只是列出来角色和角色承担的主要职责。但是我们列出角色的不同状态也是重要的一个工作。角色的状态分两种,一种是系统状态,比如在职、离职、隐身等。第二种是现实环境状态,角色在使用系统的时候,有没有比较明显的不同的状态。比如呼叫系统的:正常接听、喝水上厕所。
七、涉及到实体
先思考:1)为什么要梳理涉及到的实体?2)应该做到什么程度?
1)梳理实体有助于我们后面做功能梳理
2)有助于我们后面做模块化设计
做到什么程度?
梳理出实体,实体的所有字段,以及实体的状态。
八、涉及到策略
先思考:1)为什么要梳理涉及到的策略?
我们提前把系统中的策略和规则提前写出来,可以在系统研发之前就进入到一个初步判断的阶段。这个策略和规则研发容不容易实现,涉及到的角色和部门是否接受。反正我们闷声干活,到后期研发不可实现,或者系统做出来之后涉及到的角色并不接受,那个时候就难了。
九、系统架构
先思考:1)为什么要画系统架构图?
系统架构,也就是系统蓝图。把我们涉及到的系统,系统之间的关联和系统的主要功能用一张图画出来。有助于我们全面的理解我们的项目。做完这一步,我们脑子中已经有了整体项目的一个框架了,做到了心中有数。有助于我们的版本规划和研发节奏。也能帮助研发做开发的时候做参考,防止研发目前设计的技术机构到后期不适用修改成本过大。
十、功能清单
先思考:1)为什么要做功能清单?
功能清单,按照角色罗列功能清单,把一个角色涉及到的所有功能、每个功能包含的具体的实体,每一个实体的字段都需要罗列清楚,这样有助于我们发现,在所有的角色中那些模块是共同通用的,是可以通过权限配置的。
比如:客服和财务都需要订单模块,只是他们需要看的一些字段和状态不同。或者订单流转的角色可能经常变和不确定,是不是可以做一个订单流转配置模块?系统中有多个审核机制?是不是做一个审核流转机制?或者做添加商品时,目前知道的商品字段10个足以了,但是我们可能马上就要扩品类,那么是不是要做一个商品模版,可以按照商品类别给商品自定义一些字段。
并且把罗列出的功能清单可以给到对应的角色,确定功能是否正确和满足需求。
我们要清楚:在做后台系统的时候,我们虽然是按照角色去梳理功能清单,是因为基于角色梳理,可以方便我们梳理功能,并且不遗漏功能。但是我们的系统设计和研发的时候一定不是基于角色进行,而是基于功能进行,所有的角色都是有若干个功能组合成一个角色。
十一、规划排期
人不可能一口吃下一个大胖子,系统也不可能一次就做到尽善尽美,只能一步一步的走。做版本规划的时候分阶段制定,要清楚每一个阶段的目的是啥,根据阶段的目的和资源制定版本规划。
新的复盘纪要-初创
对整体复盘可以用PDCA,但这个模型被讲烂了,说个新鲜的。
当我们对事件整体复盘时,可以应用ORID,这个模型比较适合经验总结和成熟心态。使用的时候可以把PDCA的PDC放在ORID中O的环节。
Objective 客观:
事件中的人事物有什么?
哪个场景令我印象深刻?
我观察到了什么事实和现象?
Reflection 感受:
我当时的感想是射手那么?
我为什么会情绪波动?产生了什么情绪?
Interpretive 反思:
这件事的意义是什么?
关键转折电视是什么?
Decisional 行动
之后的行动是什么?
ORID区别于PDCA的点在于,不仅仅关注事件本身,可以把成熟心态方法化。
没有什么比时间更具有说服力了因为时间无需通知,我们就可以改变一切
——韩大师