本文根据作者的房产类项目经验,结合项目中的户型图/房型图模块部分,总结了制定户型图库的三个基础方法。
在房产网站(贝壳、安居客、房多多等)查看房源时,会发现每个小区都有一个户型图/房型图模块展示小区的户型。
在做房源管理系统时,要考虑每个小区都有相似户型的房源,这些房源的户型图可以共用一套,如果建立户型图库,集中管理这些图片,那很多房源的户型图无需重新上传,直接从图库中选用,这样做既解决了户型图重复绘制、效率低下问题,也解决了户型图管理混乱的问题。
系统问题及优化策略
接手项目时,户型图在本地电脑管理,房源用到某户型图时,只能在电脑上翻找,然后上传到房源上(如下图)。
按照常规策略方法进行评估,对户型图库项目做如下分析。
1. 发现问题:
①本地电脑管理户型图,不能共享,查找困难,存在丢失的风险。
②户型图在房源上上传,以独立数据存在,系统不能校重,导致户型图重复。
③不能有效复用户型图。
2. 定义理想态:建立易于管理的标准户型图库,且房源容易调取。
3. 提出解决思路:
②新增、修改房源,增加“选择户型图”功能,直接调用户型图库。
4. 资源支持:
②户型图缺失的户型、朝向、面积等数据从关联小区上取值,补足数据。
③历史重复数据的处理:需要处理房源和户型图库两部分数据,这个需要业务配合处理。
1.0版本的迭代
由于要记录房源上户型图专员的绩效,所以在1.0版本仅增加了户型图库的概念,上传户型图依然在房源上:
房源上保留上传户型图功能,房源上传的户型图进入户型图库,户型图继承当前房源的小区、户型、面积、朝向等信息。
问题:
不能修改、删除户型图。
不能标识户型图是自有、他有类型。
1.1版本的迭代
和业务沟通,户型图专员的绩效不应该放至房源上,可以通过户型图库的新增量去计算他们的绩效,所以在1.1版本解除了户型图库对房源的依赖:
新增户型图,反向关联小区,户型、面积、朝向等信息可灵活配置。
总结
1. 模块松耦合
所谓“耦合”,指将两个模块像链子一样连接在一起,存在依赖关系,若其中一个模块要动,势必引起另一个模块要改。在架构模块的时候,尽量做到松耦合架构,以降低整体复杂性和依赖性。
见下图:
1.0版本,上传户型图放至房源管理模块,导致房源管理和户型图库纠缠在一起,调整户型图功能,需要动房源新增、修改模块。
2. 穷尽业务场景,尽可能找到所有异常分支
异常分支越详尽,解决方案会更优,做B端产品,要尽可能分解业务场景,覆盖所有可能的异常分支。
本案例中,列举所有与户型图库有关系的用户,并用5w3h分析,重点关注当前场景是否为高频场景,是否契合目前的需求。其中一种情况,户型图专员在房源上新增户型图,可以记录绩效他的绩效,通过分析,知道这个是历史原因造成的,不利于模块之间的松耦合。
另外,计算绩效,完全可以从户型图库切入,所以我们果断舍弃这种场景,并提供了更便捷的解决方案。
3. 做数据字典,能配置的数据尽量做成字典
数据字典(data dictionary)是对数据对象或者项目描述的集合,数据字典可以集中管理数据,相同的数据维护一份,系统内统一调用。数据字典的特点是配置灵活,调取方便。户型图库也属于数据字典,有了户型图库,相同户型的房源可以统一调用同一张户型图,无需重复上传;另外户型图的信息在户型图库中完成配置,可以同步至全局。
除了这种图片字典外,我们还会遇到字段数据字典,例如户型、朝向、建筑类型、房证年限等等(见下图)。
户型图库作为楼盘字典的一部分,起至关重要的作用。本文从实践出发,运用策略分析的通用方法论拆解项目,并总结了松耦合、穷尽场景、做数据字典3种通用方法,做B端产品这三种方法非常普遍,几乎贯穿整个系统,请谨记!